The Open Group Architecture Framework

TOGOF 9.1    

FASE I Introducción

  Página 1 de 670 

TOGOF 9.1          

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

1.1 Estructura del documento TOGAF 

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

  Página 2 de 670 

TOGOF 9.1    

   

Figura 1-1: Estructura del documento TOGAF 

Hay siete partes en el documento de TOGAF:  PARTE I  (Introducción) Esta parte
proporciona una introducción de alto nivel a los conceptos clave de la arquitectura
de la empresa y, en particular, el enfoque TOGAF.Contiene las definiciones de los
términos utilizados en TOGAF y notas de la versión que detallan los cambios entre
esta versión y la versión anterior de TOGAF.  PARTE II  (Arquitectura Método de
Desarrollo) Esta parte es el núcleo de TOGAF. En él se describe la Arquitectura
Método de Desarrollo de TOGAF (ADM) - un enfoque paso a paso para el desarrollo de
una empresa de arquitectura.  PARTE III  (Directrices de ADM y Técnicas) Esta parte
contiene una colección de guías y técnicas disponibles para su uso en la aplicación
de TOGAF y el TOGAF ADM.  PARTE IV  (Marco de Arquitectura de contenido) Esta parte
describe el marco de contenido TOGAF, incluyendo un metamodelo estructurado para
artefactos arquitectónicos, el uso de bloques de la arquitectura de construcción
reutilizables, y una visión general de los entregables arquitectura típica.

    Página 3 de 670 
TOGOF 9.1    
PARTE V  (Enterprise Continuum y Herramientas) Esta parte trata sobre las
taxonomías y las herramientas apropiadas para clasificar y almacenar los resultados
de la actividad de la arquitectura dentro de una empresa.  PARTE VI  (Modelos de
referencia de TOGAF) Esta parte ofrece una selección de los modelos de referencia
de arquitectura, que incluye la Fundación Arquitectura TOGAF y el Integrado de
Información de Referencia Infraestructura Modelo (III-RM).  PARTE VII  (Capability
Framework Architecture) Esta parte se analiza la organización, procesos,
habilidades, roles y responsabilidades necesarias para establecer y operar una
función de la arquitectura dentro de una empresa.  La intención de dividir la
especificación TOGAF en estas partes independientes es permitir que diferentes
áreas de especialización que se considerarán en detalle y potencialmente abordados
de manera aislada. Aunque todas las partes funcionan juntos como un todo, también
es factible seleccionar determinadas partes para su aprobación y se excluyan otros.
Por ejemplo, una organización podría adoptar el proceso de ADM, sino optar por no
utilizar cualquiera de los materiales relacionados con la Arquitectura de
Capacidad.  Como un marco abierto, se recomienda este uso, en especial en las
siguientes situaciones:   Se espera que las organizaciones que son nuevas para
TOGAF y desean adoptar progresivamente conceptos TOGAF para centrarse en
determinadas partes de la especificación para su aprobación inicial, con otras
áreas presentadas para su consideración posterior.  Las organizaciones que ya han
implementado marcos de arquitectura pueden optar por combinar estos marcos con los
aspectos de la especificación TOGAF. 

1.2 Resumen Ejecutivo 

En esta sección se ofrece un panorama general ejecutivo de la arquitectura
empresarial, los conceptos básicos de lo que es (no sólo otro nombre para la
Arquitectura de TI), y por qué es necesario. Proporciona un resumen de los
beneficios del establecimiento de una empresa y la adopción de la arquitectura
TOGAF para lograrlo. 
¿Qué es una empresa? 

TOGAF define la "empresa" tal como cualquier conjunto de organizaciones que tiene
un conjunto de objetivos comunes. Por ejemplo, una empresa podría ser una agencia
del gobierno, toda una corporación, una división de una corporación, un solo
departamento, o una cadena de organizaciones geográficamente distantes unidos entre
sí por la propiedad común.  El término "empresa" en el contexto de la "arquitectura
de la empresa" puede ser utilizado para designar tanto toda la empresa - que abarca
la totalidad de sus servicios de información y tecnología, los procesos y la
infraestructura - y un dominio específico dentro de la empresa. En ambos casos, la
arquitectura cruza múltiples sistemas, y múltiples grupos funcionales dentro de la
empresa.  La confusión surge a menudo de la naturaleza evolutiva del término
"empresa". Una empresa extendida incluye hoy en día con frecuencia socios,
proveedores y clientes. Si el objetivo es la integración de una empresa extendida,
entonces la empresa cuenta con los socios, proveedores y clientes, así como las
unidades de negocio internas. 

  Página 4 de 670 

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

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

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

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

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

  Página 5 de 670 

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

o o 

Más rápido, más sencillo y más barato de adquisiciones:  o Las decisiones de compra
son más simples, ya que la información que rige la contratación está fácilmente
disponible en un plan coherente  El proceso de contratación es más rápido -
maximizar la velocidad de adquisición y flexibilidad sin sacrificar la coherencia
arquitectónica  La capacidad de suministro de los sistemas abiertos heterogéneos de
múltiples proveedores  La capacidad de asegurar las capacidades más económicos 

o
Específicamente, ¿qué me incitaría a desarrollar una empresa de arquitectura? 

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

de cambios en la infraestructura radicales inicia una revisión o desarrollo de
arquitectura empresarial. A menudo las personas clave a identificar áreas de cambio
necesarios para que los nuevos objetivos de negocio que debe cumplir. Estas
personas se conocen comúnmente como las "partes interesadas" en el cambio. El papel
del arquitecto es hacer frente a sus preocupaciones a través de:     La
identificación y el perfeccionamiento de los requisitos que los interesados tienen 
Desarrollo de vistas de la arquitectura que muestran cómo las preocupaciones y
necesidades van a ser tratados  Mostrando las compensaciones que se van a realizar
en la conciliación de los intereses potencialmente conflictivos de las distintas
partes interesadas 

Sin la arquitectura de la empresa, es muy poco probable que todas las inquietudes y
requerimientos serán consideradas y se reunieron. 
¿Qué es un marco de la arquitectura? 

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

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

  Página 6 de 670 

TOGOF 9.1    
¿Por qué necesito TOGAF como marco para la arquitectura de la empresa? 

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

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

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

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

TOGOF 9.1      

2. Conceptos Básicos
A los efectos de TOGAF 9, los conceptos básicos proporcionados en este capítulo se
aplican.

2.1 ¿Qué es TOGAF?

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

2.2 ¿Qué es la arquitectura en el contexto de TOGAF?

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

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

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

2.3 ¿Qué tipo de arquitectura TOGAF ¿El trato con?

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

  Página 8 de 670 

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

2.4 Arquitectura Método de Desarrollo

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

   

  

  Página 9 de 670 

TOGOF 9.1    
 Gestión de Requisitos examina el proceso de gestión de requisitos de arquitectura
en todo el ADM. 

2.5 Entregables, Artefactos y bloques de construcción

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

  Página 10 de 670 

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

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

  Figura 2‐2: Ejemplo ‐ Arquitectura de definición de documento   
Página 11 de 670 

TOGOF 9.1    

Continuum 2.6 Empresa

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

  Figura 2‐3: Empresa Continuum 

  

2.7 Arquitectura Repositorio

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

  Página 12 de 670 

TOGOF 9.1    
Arquitectura. The Enterprise Continuum proporciona un contexto útil para la
comprensión de los modelos arquitectónicos: muestra bloques de construcción y sus
relaciones entre sí, y las limitaciones y requisitos en el ciclo de desarrollo de
la arquitectura. La estructura de la arquitectura TOGAF repositorio se muestra en
la Figura 2-4 .

  Figura 2‐4: TOGAF Arquitectura Estructura del repositorio 

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

  Página 13 de 670 

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

2.8 Establecer y mantener una capacidad de Arquitectura Empresarial

Con el fin de llevar a cabo la actividad arquitectónica con eficacia dentro de una
empresa, es necesario poner en marcha una capacidad de negocio apropiado para la
arquitectura, a través de las estructuras de organización, funciones,
responsabilidades, habilidades y procesos. Una visión general de la capacidad TOGAF
Arquitectura se muestra en la Figura 2-5 .

  Figura 2‐5: Introducción a la arquitectura TOGAF Capability 

 2.9 Establecimiento de la Capacidad de Arquitectura como una

Entidad Operacional
Salvo capacidades de arquitectura creados para apoyar exclusivamente los programas
de prestación de cambio, se reconoce cada vez más que una práctica exitosa de la
arquitectura empresarial debe sentarse sobre una base operativa firme. En efecto,
una práctica de la

  Página 14 de 670 

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

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

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

  Página 15 de 670 

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

Mayores detalles sobre el establecimiento de una capacidad de arquitectura

empresarial se da en la parte VII , 45. Introducción .

2.10 El uso de TOGAF con otros marcos

Dos de los elementos clave de cualquier marco de arquitectura de la empresa son: 
 Una definición de los entregables que la actividad architecting debería producir 
Una descripción del método por el cual esto se debe hacer 

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

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

  Página 16 de 670 

TOGOF 9.1    

3. Definiciones
A los efectos de TOGAF 9, los siguientes términos y definiciones. A. Glosario de
Definiciones complementarias debe ser referido para las definiciones suplementarios
no definidos en el presente capítulo. Collegiate Dictionary de Merriam-Webster debe
ser referido para los términos no definidos en esta sección o A. Glosario de
definiciones complementarias .

3.1 Abstracción
La técnica de proporcionar descripciones resumidas o generalizadas de contenido
detallado y complejo. La abstracción, como en "nivel de abstracción", también puede
significar que proporciona un enfoque de análisis que tiene que ver con un nivel
consistente y común de detalle o la abstracción. Abstracción en este sentido se
utiliza normalmente en la arquitectura para permitir un nivel consistente de la
definición y la comprensión que deben alcanzarse en cada área de la arquitectura
con el fin de apoyar la comunicación eficaz y la toma de decisiones. Es
especialmente útil cuando se trata de arquitecturas grandes y complejas ya que
permite a cuestiones relevantes para ser identificados antes de que se intentó más
detalle.

3.2 Actor
Una persona, organización o sistema que tiene un papel que inicia o interactúa con
las actividades; por ejemplo, un representante de ventas que viaja a visitar a los
clientes.Actores puede ser interno o externo a la organización. En la industria
automotriz, un fabricante de equipo original se considera un actor por un
concesionario de automóviles que interactúa con sus actividades de la cadena de
suministro.

3.3 Aplicación
Un sistema informático desplegado y operativo que soporte las funciones y servicios
a las empresas; por ejemplo, una nómina. Las aplicaciones utilizan los datos y son
apoyados por múltiples componentes de la tecnología, pero son distintos de los
componentes tecnológicos que apoyan la solicitud.

3.4 Arquitectura de la aplicación

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

3.5 Application Platform

  Página 17 de 670 

TOGOF 9.1    
La colección de componentes de tecnología de hardware y software que proporcionan
los servicios utilizados para apoyar las aplicaciones.

3.6 Plataforma de Aplicaciones (API)

La interfaz o conjunto de funciones, entre el software de aplicación y / o de la
plataforma de aplicaciones.

3.7 Estilo arquitectónico

La combinación de características distintivas en que se realiza o se expresa la
arquitectura.

3.8 Arquitectura
1. Una descripción formal de un sistema, o un plan detallado del sistema a nivel de
componente, para orientar su aplicación (fuente: ISO / IEC 42010:2007).  2. La
estructura de los componentes, sus interrelaciones, y los principios y directrices
que rigen su diseño y evolución en el tiempo. 

3.9 Arquitectura Bloque de construcción (ABB)

Un componente del modelo de arquitectura que describe un solo aspecto del modelo
general. Ver también 3.21 Módulo .

3.10 Arquitectura Continuum

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

3.11 Arquitectura Método de Desarrollo (ADM)

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

  Página 18 de 670 

TOGOF 9.1    

3.12 Arquitectura de dominio

. El área arquitectónica está considerando Hay cuatro ámbitos de arquitectura
dentro de TOGAF: de negocio, de datos, de aplicaciones y tecnología.

3.13 Marco de Arquitectura

Una estructura conceptual utilizado para desarrollar, implementar y mantener una
arquitectura .

3.14 Arquitectura de Gobierno

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

3.15 Arquitectura del Paisaje

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

3.16 Principios Arquitectura

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

3,17 Architecture Vision

Una descripción sucinta de la Arquitectura objetivo que describe su valor para el n
egocio y 
los cambios en la empresa, que será el resultado de su implementación exitosa. Sirv
e 

como una visión política y un límite para el desarrollo detallado de la 
arquitectura. 

  Página 19 de 670 

TOGOF 9.1    
Nota:  Fase A (Architecture Vision) se describe en la Parte II , 7. Fase A:
Architecture Vision . 

3.18 Artefacto
Un producto del trabajo arquitectónico que describe un aspecto de la arquitectura.
Ver también 3.21 Módulo .
3.19 Línea de Base
Una especificación que ha sido revisado formalmente y acordado, que a partir de
entonces, sirve como la base para un mayor desarrollo o el cambio y que sólo se
puede cambiar a través de los procedimientos de control de cambios formales o de un
tipo de procedimiento como la gestión de la configuración.

3.20 Flujo de Información sin fronteras

1. Una marca registrada de The Open Group.  2. Una representación abreviada de
"acceso a la información integrada para apoyar mejoras
en los procesos de negocio", que representan un estado deseado de la
infraestructura de una empresa específica a las necesidades de negocio de la
organización.  Una infraestructura que ofrece sin fronteras Flujo de Información
cuenta con componentes estándares abiertos que ofrecen servicios en la empresa
extendida que de un cliente:   Nota:  La necesidad de flujo de información sin
fronteras se describe en la Parte VI , 44. Integrado de Información de Referencia
Infraestructura Modelo .  Combine múltiples fuentes de información  Segura entregar
la información cuando y donde sea necesario, en el contexto adecuado para las
personas o sistemas que utilicen dicha información. 

3.21 Módulo
Representa un (potencialmente reutilizable), componente de negocio, TI, o la
capacidad de la arquitectura que se puede combinar con otros bloques de
construcción para ofrecer arquitecturas y soluciones.

  Página 20 de 670 

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

3.22 Arquitectura de Negocios

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

3.23 Función de Empresas

Proporciona capacidades de negocio estrechamente alineadas a una organización, pero
no necesariamente gobernadas de forma explícita por la organización.

3.24 Gobierno de Empresas

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

3.25 Servicios de Negocio

Soporta capacidades de negocio a través de una interfaz definida explícitamente y
se rige explícitamente por una organización.

3.26 Capacidad
Una habilidad que una organización, persona o sistema posee. Las capacidades se
expresan normalmente en términos generales y de alto nivel y por lo general
requieren una combinación de organización, personas, procesos y tecnología para
alcanzar. Por ejemplo, marketing, contacto con el cliente o telemarketing.

3.27 Capacidad de Arquitectura

Una descripción muy detallada de la propuesta de arquitectura para darse cuenta de
una solución particular o una solución de aspecto.

  Página 21 de 670 

TOGOF 9.1    

Incremento de 3,28 Capacidad

Una porción discreta de una arquitectura de capacidad que ofrece un valor
específico. Cuando todos los incrementos se han completado, la capacidad ha sido
realizada.

3.29 Comunicaciones y Gestión de las partes interesadas

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

3.30 Las preocupaciones

Los intereses dominantes que son de crucial importancia para las partes interesadas
en un sistema, y determinan la aceptabilidad del sistema. Las preocupaciones pueden
referirse a cualquier aspecto de funcionamiento, el desarrollo o el funcionamiento
del sistema, incluyendo consideraciones tales como el rendimiento, la fiabilidad,
la seguridad, la distribución, y capacidad de evolución. Ver también 3.68
Stakeholder .

3.31 Restricción
Un factor externo que impide que una organización de la búsqueda de enfoques
particulares para cumplir sus objetivos. Por ejemplo, los datos del cliente no está
armonizada dentro de la organización, regional o nacional, lo que limita la
capacidad de la organización para ofrecer un servicio al cliente eficaz.

3.32 Arquitectura de Datos

Una descripción de la estructura y la interacción de los principales tipos de la
empresa y las fuentes de datos, los activos de datos lógicos, los activos físicos
de datos y recursos de gestión de datos. Nota:  Arquitectura de datos se describe
en la Parte II , 10. Fase C: Arquitecturas de Sistemas de Información -
Arquitectura de Datos . 

3.33 Disponible
Un producto de la obra arquitectónica que se especifica y, a su vez revisado
formalmente, de acuerdo, y firmado por las partes interesadas contractualmente.
Entregables representa la salida de los proyectos y los resultados que se tenga en
forma de documentación normalmente se

  Página 22 de 670 

TOGOF 9.1    
archiva en la finalización de un proyecto, o de transición a un repositorio de
arquitectura como un modelo de referencia, estándar o instantánea de la
arquitectura del paisaje en un punto en el tiempo.
3.34 Empresa
El nivel más alto (por lo general) de la descripción de una organización y por lo
general cubre todas las misiones y funciones. Una empresa a menudo abarcar varias
organizaciones.

Continuum 3.35 Empresa

Un mecanismo útil para la clasificación de la arquitectura y la solución
artefactos, tanto internos como externos a la arquitectura de repositorio, a medida
que evolucionan a partir de genéricos Arquitecturas Fundación a las arquitecturas
Organización específicas de categorización. Ver también 3.10 Arquitectura Continuum
y 3.67 Soluciones Continuum .

3.36 Fundación Arquitectura

Bloques genéricos de construcción, sus interrelaciones con otros bloques de
construcción, junto con los principios y directrices que proporcionan una base
sobre la que las arquitecturas más específicas se pueden construir.

3.37 Marco
Una estructura para el contenido o proceso que se puede utilizar como una
herramienta para estructurar el pensamiento, asegurando la consistencia e
integridad.

3.38 Gap
Una declaración de la diferencia entre los dos estados. Utilizado en el contexto
del análisis de las lagunas, donde se identifica la diferencia entre la línea de
base y Arquitectura Target. Nota:  El análisis de brechas se describe en la Parte
III , 27. Análisis Gap . 

3.39 Gobierno
La disciplina de controlar, gestionar y dirigir un negocio (o IS / paisaje IT) para
entregar los resultados de negocio requiere. Ver también 3.14 Arquitectura
Gobernabilidad , Gobernanza 3.24 Negocios y A.60 Gobierno Operacional en A.
Glosario de definiciones complementarias .

  Página 23 de 670 

TOGOF 9.1    

3.40 Información
Cualquier comunicación o representación de hechos, datos u opiniones, en cualquier
medio o forma, incluyendo textual, numérico, gráfico, cartográfico, la narrativa, o
formas audiovisuales.

3,41 Tecnología de la Información (IT)

1. La gestión del ciclo de vida de la información y la tecnología relacionada
utilizado por una organización.  2. Un término general que incluye todas o algunas
de las materias relacionadas con la
industria de la computación, tales como la Continuidad del Negocio, Negocio
Interfaz IT, Business Process Modeling y Gestión, Comunicación, Cumplimiento y
Legislación, Informática, Gestión de Contenidos, Hardware, Gestión de la
Información, Internet , Offshoring, Redes, Programación y Software, Asuntos
Profesionales, Gestión de Proyectos, Seguridad, Estándares, almacenamiento, voz y
comunicaciones de datos. Varios países e industrias emplean otros términos paraguas
para describir esta misma colección. 

3. Un término comúnmente asignada a un departamento dentro de una organización

encargada de aprovisionamiento de algunos o todos los dominios descritos en (2)
anteriormente. 

4. Los nombres alternativos comúnmente adoptadas incluyen Servicios de Información,

Gestión de la Información, et al. 

3.42 Interoperabilidad
1. La capacidad de compartir información y servicios.  2. La capacidad de dos o más
sistemas o componentes para intercambiar y utilizar la información.  3. La
capacidad de los sistemas para ofrecer y recibir servicios de otros sistemas y para
utilizar los servicios de manera intercambiada para que puedan funcionar juntos de
manera efectiva. 

3.43 Lógico
Una definición independiente de la implementación de la arquitectura, a menudo
agrupar entidades físicas relacionadas en función de su finalidad y estructura. Por
ejemplo, los productos de múltiples proveedores de software de infraestructura
pueden ser agrupados de forma lógica como plataformas de servidor de aplicaciones
Java.

  Página 24 de 670 

TOGOF 9.1    

3.44 Metadatos
Los datos acerca de los datos, de cualquier tipo en cualquier medios de
comunicación, que describe las características de una entidad.

3.45 Metamodel
Un modelo que describe cómo y con qué la arquitectura se describirá de una manera
estructurada.

3.46 Método
Un enfoque repetible definida para hacer frente a un tipo particular de problema.
Ver también 3.47 Metodología .

3.47 Metodología
A definido, serie repetible de medidas para abordar un determinado tipo de
problema, que por lo general se centra en un proceso definido, pero también puede
incluir la definición de los contenidos. Ver también Método 3,46 .

3.48 Modelo
Una representación de un tema de interés. Un modelo proporciona una escala más
pequeña y simplificada, y / o representación abstracta de la materia. Un modelo se
construye como un "medio para un fin". En el contexto de la arquitectura de la
empresa, el tema es un todo o parte de la empresa y el final es la capacidad de
construir "vistas" que aborden las preocupaciones de los grupos de interés
particulares; es decir, sus "puntos de vista" en relación con el tema en cuestión.
Ver también 3.68 Stakeholder , 3.75 Vista , y 3.76 Viewpoint .

3.49 Modelado
Una técnica a través de la construcción de modelos que permite a un sujeto para ser
representados en una forma que permite el razonamiento, perspicacia y claridad en
cuanto a la esencia de la materia.

3.50 Objetivo
Un hito de tiempo limitado para que una organización utiliza para demostrar el
progreso hacia una meta; por ejemplo, "Aumentar la utilización de la capacidad en
un 30% a finales de 2009 para apoyar el aumento previsto en el mercado de la cuota
".

  Página 25 de 670 

TOGOF 9.1    

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

3.52 Gestión del Rendimiento

El seguimiento, control y reporte de la ejecución práctica de la arquitectura
empresarial. relacionados también con la mejora continua.

3.53 Física
Una descripción de una entidad del mundo real. Elementos físicos en una empresa de
arquitectura todavía puede abstraerse considerablemente de Arquitectura de la
solución, diseño, o puntos de vista de implementación.

3.54 Plataforma
Una combinación de productos de infraestructura de tecnología y componentes que
establece que los requisitos para albergar software de aplicación.

3.55 Plataforma de Servicios

Una capacidad técnica que se requiere para proporcionar la infraestructura que
permite que apoya la entrega de aplicaciones.

3.56 Principio 3.57 Modelo de Referencia (RM)

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

  Página 26 de 670 

TOGOF 9.1    

3.58 Repositorio
Un sistema que gestiona todos los datos de una empresa, incluidos los modelos de
proceso de datos y la información de la empresa y otra. Por lo tanto, los datos de
un repositorio es mucho más extensa que la de un diccionario de datos, que por lo
general sólo define los datos que componen una base de datos .

3.59 Requisito
Una declaración de la necesidad que debe ser satisfecha por una arquitectura o
paquete de trabajo en particular.

3.60 Hoja de Ruta

Un plan abstracto para el cambio de negocios o tecnología, por lo general operan a
través de múltiples disciplinas largo de varios años. Normalmente se utiliza en las
frases Technology Roadmap, Arquitectura Roadmap, etc

3.61 Papel
1. La función habitual o esperado de un actor, o la parte que alguien o algo juega
en una acción o evento en particular. Un actor puede tener una serie de funciones. 
2. La parte de un individuo desempeña en una organización y la contribución que
hacen a través de la aplicación de sus habilidades, conocimientos, experiencia y
habilidades. 

3.62 Segmento de Arquitectura

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

3.63 Servicio de Orientación

Una manera de pensar en términos de servicios y el desarrollo basado en el servicio
y los resultados de los servicios.

Arquitectura Orientada a Servicios 3.64 (SOA)

. Un estilo arquitectónico que apoya la orientación al servicio Tiene las
siguientes características distintivas:

  Página 27 de 670 

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

  

3.65 Arquitectura de la solución

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

3.66 Solución Módulo (SBB)

Una solución candidata que se ajusta a la especificación de una Arquitectura Bloque
de construcción (ABB).

3.67 Soluciones Continuum

Una parte del Continuum Enterprise. Un repositorio de soluciones reutilizables para
los futuros esfuerzos de aplicación. Contiene implementaciones de las definiciones
correspondientes en la Arquitectura Continuum.

3.68 Stakeholder
Un individuo, equipo u organización (o clases de los mismos) con intereses en, o
preocupaciones en relación con el resultado de la arquitectura. Diferentes actores
con diferentes roles tienen diferentes preocupaciones.

3.69 Normas de Información de Base (SIB)

Una base de datos de normas que se pueden utilizar para definir los servicios
particulares y otros componentes de una arquitectura de organización específica.

  Página 28 de 670 

TOGOF 9.1    

3.70 Arquitectura Estratégica

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

3.71 Arquitectura Target

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

3.72 Taxonomía de Arquitectura Vistas

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

3.73 Tecnología de Arquitectura

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

3.74 Transición Arquitectura

Una descripción formal de un estado de la arquitectura en un punto de vista
arquitectónico significativa en el tiempo. Uno o más arquitecturas de transición
puede ser usado para describir la progresión en el tiempo desde la línea base hasta
la arquitectura destino.

3.75 Ver
La representación de un conjunto relacionado de preocupaciones. Un punto de vista
es lo que se ve desde un punto de vista. Una vista de la arquitectura puede ser
representado por un modelo de demostrar a las partes interesadas de sus áreas de
interés en la arquitectura. Un punto de vista no tiene por qué ser visual o gráfica
en la naturaleza.

3.76 Punto de vista

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

3.77 Paquete de Trabajo

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

  Página 30 de 670 

TOGOF 9.1       

4. Notas de la versión
A los efectos de TOGAF 9, las notas de la versión se proporcionan en este capítulo
se aplican.

4.1 ¿Qué hay de nuevo en TOGAF 9?

En esta sección se ofrece un panorama general de las principales características
nuevas en TOGAF 9.
Estructura Modular

Uno de los focos de TOGAF 9 desarrollo ha sido asegurar que el contenido de la

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

Una importante adición de nuevos contenidos a la especificación TOGAF es el marco

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

TOGOF 9.1    
arquitecturas. La existencia de esta norma permite a los proveedores de
herramientas, proveedores de productos y proveedores de servicios para que adopten
formas consistentes de trabajo, que a su vez se traducirá en una mayor coherencia
entre las herramientas de arquitectura, una mejor interoperabilidad de
herramientas, arquitecturas de referencia más coherentes y mejor comparabilidad
entre las arquitecturas de referencia relacionados .

Orientación extendido en adopción TOGAF dentro de una empresa

Dentro de las organizaciones más grandes, la práctica de la arquitectura de la

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

Consideración explícita de estilos arquitectónicos, incluyendo SOA y Arquitectura

de Seguridad

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

  Página 32 de 670 

TOGOF 9.1    
 Los diversos tipos de desarrollo de la arquitectura necesarios dentro de una
empresa y cómo se relacionan entre sí 

Detalle adicional ADM

Esta versión de la especificación TOGAF incluye información más detallada apoyo a
la ejecución de la ADM. áreas particulares de mejora son:  La fase preliminar, que
cuenta con una guía extendida en el establecimiento de un marco de arquitectura de
la empresa y la planificación para el desarrollo de la arquitectura. La Fase
Preliminar extendido también ofrece consejos para la definición de un modelo de
gobernanza para la realización arquitectura beneficio y también analiza la
vinculación entre TOGAF y otros marcos de gestión.  Las Oportunidades y fase
Soluciones y planeamiento de migración de fase, que cuentan con un método más
detallado y sólido para la definición y planificación de transformación de la
empresa, con base en los principios de la planificación basada en la capacidad. 

4.1.1 Los cambios aplicados en esta edición

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

   

  Página 33 de 670 

TOGOF 9.1    
       Texto introductorio adicional sobre los estilos arquitectónicos se ha
añadido en la Parte III , 18. Introducción .  Pequeños cambios se han hecho para el
capítulo de la arquitectura de seguridad ( Parte III , 21. Arquitectura de
Seguridad y el ADM ) para mantener la coherencia con el ADM.  Se han realizado
correcciones a metamodelo diagramas.  Las correcciones se han aplicado a los
aspectos del metamodelo.  En el ejemplo de bloques de construcción se ha
eliminado.  La categorización de modelo de documento se ha eliminado.  Duplicar
texto en varios lugares ha sido reemplazado con una referencia adecuada:  o
Análisis de brechas en las fases B, C y D ahora referencia a la Parte III , 27.
Análisis Gap .  Gestión de Requisitos en varias fases ahora hace referencia la
parte II , 17.2.2 Requisitos para el Desarrollo en la fase de gestión de
requisitos. 

o 
Algunos de los artefactos han sido renombrados para reflejar mejor su uso:  o o
Matriz System / Data se convierte en matriz de aplicaciones / datos  Diagrama de
clases ha sido reemplazado con el diagrama conceptual de datos y el diagrama de
lógica de datos  Matriz del sistema / Organización convierte matriz Aplicación /
Organización  Matriz de Papel / System convierte matriz Papel / Aplicación  Matriz
de Sistema / Función convierte en matriz de Aplicación / Función  Diagrama
Realización de proceso / sistema convierte diagrama Realización de proceso /
aplicación  Diagrama del sistema de casos de uso se convierte en el diagrama de
casos de uso de aplicaciones  Matriz del sistema / tecnología se convierte en
matriz de Aplicación / Tecnología 

o o o o

o 

La descripción de la arquitectura de principios ahora los divide en dos únicos

tipos Enterprise y Arquitectura -, mientras que antes de que llamaran a los
Principios de TI por separado. IT Principios ahora son vistos como sólo una parte
de los Principios Empresariales.  El Stakeholder Mapa incorporado en el capítulo de
gestión de los interesados ( Parte III , 24. Gestión de los grupos de interés ) que
ahora se hace referencia explícita a modo de ejemplo, la tabla se ha puesto de
relieve para referirse a las preocupaciones de las partes interesadas, y la lista
de objetos para cada grupo de interés actualizada. 

  Página 34 de 670 

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

  

4.2 Los beneficios de TOGAF 9

TOGAF 9 proporciona un conjunto amplio de revisiones de la especificación TOGAF.
Cuando se combinan, estas ediciones buscan lograr un conjunto de objetivos para
mejorar el valor del marco TOGAF.
Mayor usabilidad

Una serie de mejoras dentro de TOGAF 9 apoyo mayor facilidad de uso de la

especificación general. En primer lugar, la estructura modular de la especificación
hace que sea más fácil para un arquitecto para que considere la posibilidad de un
aspecto específico de la Capacidad de Arquitectura. En todas las áreas, la
especificación pretende agregar el detalle y la claridad por encima y más allá de
las versiones anteriores TOGAF.
Más de enfoque sobre el cambio de empresa Holística

TOGAF tiene una sólida historia en la arquitectura de TI, teniendo en cuenta las
formas en que se puede apoyar el cambio de empresa. Sin embargo, como TOGAF ha
crecido en profundidad y madurez se ha convertido en un marco para la gestión de
todo el espectro de los cambios necesarios para transformar una empresa hacia un
modelo operativo de destino. TOGAF 9 continúa esta evolución e incorpora una
perspectiva más amplia de cambio que permite a la arquitectura empresarial que se
utiliza para especificar la transformación a través de los dominios de negocio,
datos, aplicaciones y tecnología.
Más Consistencia de salida

Las versiones anteriores de TOGAF centran en proporcionar un proceso coherente para

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

  Página 35 de 670 

TOGOF 9.1    

4.3 Mapeo de la Estructura TOGAF 8.1.1 a TOGAF 9

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

La parte de la especificación Introducción TOGAF 8.1.1 se ha utilizado como base

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

La esencia de la TOGAF 8.1.1 ADM se ha conservado en TOGAF 9. Parte II:

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

El TOGAF 8.1.1 Empresa Continuum ha visto un importante grado de cambio. El

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

La base de recursos no está incluido en esta versión de TOGAF. Algunos elementos de

la base de recursos han quedado en desuso a partir de la especificación TOGAF, pero
todavía estará disponible en forma de Libro Blanco. Otros elementos de la base de
recursos se han trasladado a otras zonas de la especificación.

  Página 36 de 670 

TOGOF 9.1    
La siguiente tabla ilustra donde ahora se puede localizar TOGAF 8.1.1 Contenido
base de recursos.

 
TOGAF 8.1.1 Recursos Architecture Board Arquitectura Cumplimiento Arquitectura
contratos Arquitectura de Gobierno Modelos de Madurez Arquitectura Arquitectura
Patrones Principios Arquitectura Arquitectura Skills Framework Desarrollo
Arquitectura Vistas Bloques de Construcción Vistas Dominio de procesos de negocio
Escenarios empresariales Estudios de caso Glosario Otras Arquitecturas y Marcos
Herramientas para el Desarrollo de la Arquitectura ADM y el Marco Zachman Ubicación
actual Trasladado a la Parte VII: Arquitectura del marco de Capacidad Trasladado a
la Parte VII: Arquitectura del marco de Capacidad Trasladado a la Parte VII:
Arquitectura del marco de Capacidad Trasladado a la Parte VII: Arquitectura del
marco de Capacidad Trasladado a la Parte VII: Arquitectura del marco de Capacidad
Trasladado a la Parte III: Directrices y Técnicas de ADM Trasladado a la Parte III:
Directrices y Técnicas de ADM Trasladado a la Parte VII: Arquitectura del marco de
Capacidad Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de
contenido Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de
contenido Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de
contenido Trasladado a la Parte III: Directrices y Técnicas de ADM Eliminado.
Estudios de caso estarán disponibles en el sitio web Open Group. Trasladado a la
Parte I: Introducción Eliminado. Este material estará disponible en el sitio web de
Open Group como un Libro Blanco. Trasladado a la Parte V: Empresa Continuum y
Herramientas Eliminado. Este material estará disponible en el sitio web de Open
Group como un Libro Blanco.

4.4 Mapeo de TOGAF 9 Estructura de TOGAF 8.1.1

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

  Página 37 de 670 

TOGOF 9.1    
9 Fase C: Arquitecturas de Sistemas de Información 10 Fase C: Arquitectura de Datos
11 Fase C: Arquitectura de aplicaciones 12 Fase D: Architecture Tecnología 13 Fase
E: Oportunidades y Soluciones 14 Fase C: planeamiento de migración 15 Fase G:
Gobernanza Aplicación 16 Fase H: Gestión Arquitectura Cambio 17 ADM Arquitectura
Gestión de Requisitos Parte III: Directrices y Técnicas de ADM 18 Introducción 19
La aplicación de la ADM a través de la Arquitectura del Paisaje 20 La aplicación de
la ADM en los diferentes niveles de la empresa 21 Arquitectura de Seguridad y el
ADM Material revisado; basado en el Capítulo 7 Material revisado; basado en el
Capítulo 8 Material revisado; basado en el Capítulo 9 Material revisado; basado en
el capítulo 10 Material revisado; basado en el capítulo 11 Material revisado;
basado en el Capítulo 12 Material revisado; basado en el capítulo 13 Material
revisado; basado en el capítulo 14 Ningún cambio material; mapas del capítulo 15
Nuevo capítulo Nuevo capítulo Nuevo capítulo

Nuevo capítulo; derivado del Libro Blanco de Seguridad (W055) 22 Usando TOGAF para
definir y Gobierno SOAs Nuevo capítulo 23 Principios Arquitectura Ningún cambio
material; mapas del capítulo 29 24 Gestión de las partes interesadas Nuevo capítulo
25 Arquitectura Patrones Ningún cambio material; mapas del capítulo 28 26
Escenarios empresariales Ningún cambio material; mapas para el Capítulo 34 27
Análisis Gap Nuevo capítulo; derivado del análisis de las deficiencias 28 Técnicas
de Planificación Migración Nuevo capítulo 29 Requisitos de interoperabilidad Nuevo
capítulo 30 Evaluación de la preparación de Nuevo capítulo transformación de
negocios 31 Gestión de Riesgos Nuevo capítulo 32 Planificación de Capacidad basada
en Nuevo capítulo Parte IV: Marco de Arquitectura de contenido 33 Introducción
Nuevo capítulo 34 Metamodel contenido Nuevo capítulo 35 Architectural Artifacts
Derivado del capítulo 31, además de nuevo material 36 Arquitectura Entregables
Revisado; era Capítulo 16 37 Bloques de Construcción Revisado del capítulo 32 Parte
V: Empresa Continuum y Herramientas 38 Introducción Nuevo capítulo 39 Continuum
Empresarial Derivado de los capítulos 17 y 18 con las revisiones sustanciales 40
Arquitectura Particiones Nuevo capítulo 41 Arquitectura Repositorio Nuevo capítulo
42 Herramientas para el Desarrollo de la Derivado del Capítulo 38, con las
directrices de Arquitectura evaluación eliminados. Parte VI: Modelos TOGAF
Referencia 43 Fundación Arquitectura: Técnico Ningún cambio material; Los mapas de
los Capítulos 19 Modelo de Referencia y 20 44 Integrado de Información
Infraestructura Ningún cambio material; mapas del capítulo 22 Modelo de Referencia
Parte VII: Arquitectura del marco de Capacidad 45 Introducción Nuevo capítulo 46
Establecer una capacidad de Arquitectura Nuevo capítulo

  Página 38 de 670 

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

4.5 Utilizar TOGAF

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

4.5.2 ¿Cuánto cuesta TOGAF?

The Open Group opera como un consorcio sin fines de lucro comprometida con la
entrega de una mayor eficiencia de las empresas, reuniendo a compradores y
proveedores de sistemas de información para reducir las barreras de la integración
de las nuevas tecnologías en la empresa. Su objetivo es hacer realidad la visión de
Flujo de información sin fronteras. TOGAF es una parte clave de su estrategia para
lograr este objetivo, y The Open Group quiere TOGAF que deben abordarse y se
utiliza en los proyectos de arquitectura prácticos y la experiencia de su uso
realimenta a ayudar a mejorarlo. Por tanto, el Open Group publica TOGAF en su
servidor web público, y permite y alienta la reproducción y el uso libre de cargo
por cualquier organización que desee utilizarlo internamente para desarrollar una
arquitectura empresarial. (Existen restricciones para su explotación comercial, sin
embargo, ver 4.5.1 Condiciones de uso .)

4.5.3 Descargas
Descargas de la documentación TOGAF, incluyendo un archivo PDF para imprimir, están
disponibles bajo licencia desde el sitio web la información TOGAF
(consultewww.opengroup.org / Arquitectura / togaf ). La licencia es libre para
cualquier organización que desee utilizar TOGAF exclusivamente para fines internos
(por ejemplo, para desarrollar una empresa de arquitectura para su uso dentro de la
organización).

  Página 39 de 670 

TOGOF 9.1    

4.6 ¿Por qué unirse The Open Group?

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

  Página 40 de 670 

TOGOF 9.1       
PARTE II Método Arquitectura Desarrollo
 

  Página 41 de 670 

TOGOF 9.1        

5. Introducción
En este capítulo se describe el ciclo de Arquitectura Método de Desarrollo (ADM),
la adaptación de la ADM, alcance la arquitectura, y la integración de la
arquitectura.

5.1 Descripción general de ADM

El TOGAF ADM es el resultado de continuos aportes de un gran número de
profesionales de la arquitectura. En él se describe un método para desarrollar y
gestionar el ciclo de vida de una empresa de arquitectura, y constituye el núcleo
de TOGAF. Integra elementos de TOGAF descritos en este documento, así como otros
activos arquitectónicos disponibles, para cumplir con el negocio y las necesidades
de TI de una organización.

5.1.1 El ADM, Enterprise Continuum, y Arquitectura Repositorio

The Enterprise Continuum ofrece un marco y un contexto para apoyar el
apalancamiento de los activos de arquitectura relevantes en la ejecución de la ADM.
Estos activos pueden incluir descripciones de arquitectura, modelos y patrones
tomados de una variedad de fuentes, como se explica en la Parte V: Empresa
Continuum y Herramientas . The Enterprise Continuum categoriza material de origen
arquitectónico - tanto los contenidos de la de la organización propios repositorios
empresariales y el conjunto de modelos de referencia disponibles relevantes y los
estándares de la industria. La aplicación práctica de la Empresa Continuum
normalmente tomará la forma de un depósito de Arquitectura (véase la Parte V , 41.
Arquitectura Repositorio ) que incluye arquitecturas de referencia, modelos y
patrones que han sido aceptados para su uso dentro de la empresa, y la obra
arquitectónica real realizado previamente dentro de la empresa. El arquitecto
trataría de volver a utilizar la mayor cantidad posible del Repositorio
Arquitectura que era relevante para el proyecto en cuestión. (Además de la
colección de material original de la arquitectura, el repositorio contendrá también
un trabajo en progreso en el desarrollo de la arquitectura.) En los lugares
pertinentes de toda la ADM, hay recordatorios a tener en cuenta que, en su caso,
los activos de arquitectura de la arquitectura de repositorio del arquitecto deben
utilizar. En algunos casos - por ejemplo, en el desarrollo de una arquitectura de
tecnología - esto puede ser la Fundación Arquitectura TOGAF (ver Parte VI: Modelos
de referencia TOGAF ). En otros casos por ejemplo, en el desarrollo de una
arquitectura de negocios - que puede ser un modelo de referencia para el comercio
electrónico tomada de la industria en general. Los criterios para la inclusión de
los materiales básicos de la arquitectura de repositorio de una organización
típicamente formarán parte del proceso de gobernanza de arquitectura empresarial.
Estos procesos de gobernanza deben considerar los recursos disponibles, tanto
dentro como fuera de la empresa con el fin de determinar si los recursos generales
se pueden

  Página 42 de 670 

TOGOF 9.1    
adaptar a las necesidades específicas de la empresa y también para determinar donde
las soluciones específicas se pueden generalizar a apoyar en general la
reutilización. Durante el uso de la ADM, el arquitecto está desarrollando una
instantánea de las decisiones de la empresa y sus implicaciones en puntos concretos
de tiempo. Cada iteración del ADM rellenará un paisaje específico de la
organización con todos los activos de arquitectura identificados y ha movilizado a
través del proceso, incluida la arquitectura específica de la organización
definitiva entregada. Arquitectura desarrollo es un proceso continuo y cíclico, y
en la ejecución de la ADM repetidamente en el tiempo, el arquitecto añade
gradualmente más y más contenido a la Arquitectura del repositorio de la
organización. Aunque el objetivo principal de la ADM está en el desarrollo de la
arquitectura específica de la empresa, en este contexto más amplio de la ADM
también puede ser visto como el proceso de poblar propia arquitectura de
repositorio de la empresa con bloques de construcción reutilizables pertinentes
tomadas de la "izquierda ", el lado más genérico de la Empresa Continuum. De hecho,
la primera ejecución de la ADM a menudo será la más difícil, ya que los activos de
arquitectura disponibles para su reutilización serán relativamente escasos.Incluso
en esta etapa de desarrollo, sin embargo, habrá capital arquitectura disponibles de
fuentes externas tales como TOGAF, así como la industria de TI en general, que
podrían ser aprovechados para apoyar el esfuerzo. Ejecuciones posteriores serán más
fáciles, ya que cada vez más activos arquitectura identificarse, se utilizan para
rellenar Arquitectura Repositorio de la organización, y por tanto están disponibles
para una futura reutilización.

5.1.2 El ADM y la Architecture Foundation

La ADM también es útil para rellenar la Architecture Foundation de una empresa. Los
requerimientos del negocio de una empresa pueden ser utilizados para identificar
las definiciones y las selecciones necesarias en la Architecture Foundation. Esto
podría ser un conjunto de modelos comunes reutilizables, definiciones de políticas
y de gobierno, o incluso lo más específico anulando selecciones tecnológicas (por
ejemplo, si el mandato de la ley). Población de la Architecture Foundation sigue
principios similares como para una empresa de arquitectura, con la diferencia de
que los requisitos para el conjunto de una empresa están limitadas a las
preocupaciones globales y por lo tanto menos completa que para una empresa
específica. Es importante reconocer que los modelos existentes de estas diversas
fuentes, cuando se integra, pueden no necesariamente resultar en una coherente
arquitectura de la empresa. "Integrabilidad" de las descripciones de la
arquitectura se considera en 5.6 Arquitectura de Integración .

5.1.3 ADM y lineamientos que apoyen y Técnicas

Parte III: Directrices y Técnicas de ADM es un conjunto de recursos - directrices,
plantillas, listas de verificación y otros materiales detallados - que la
aplicación de soporte del TOGAF ADM. Las directrices y las técnicas individuales se
describen por separado en la Parte III: Directrices y Técnicas de ADM para que
puedan ser referenciados desde los puntos relevantes en el ADM como sea necesario,
en lugar de tener el detalle desorden de texto de la descripción de la propia ADM.

  Página 43 de 670 

TOGOF 9.1    

5.2 Arquitectura del Ciclo de Desarrollo

5.2.1 Puntos clave
Los siguientes son los puntos clave de la ADM:  El ADM es iterativo, sobre todo el
proceso, entre las fases, y dentro de las fases (véase la Parte III , 19. La
aplicación de iteración para el ADM ). Para cada iteración de la ADM, una nueva
decisión debe tomarse en cuanto a:  o o o La amplitud de la cobertura de la empresa
a definir  El nivel de detalle que se define  La extensión del período de tiempo
destinado a, incluyendo el número y extensión de cualquier periodos de tiempo
intermedios  Los activos de arquitectura para ser movilizados, entre ellos:    
Activos creados en versiones anteriores del ciclo de ADM en la empresa  Activos
disponibles en la industria en otras partes (otros marcos, modelos de sistemas,
modelos industriales verticales, etc) 

Estas decisiones deberían basarse en una evaluación práctica de los recursos y la

disponibilidad de la competencia, y el valor que de manera realista se puede
esperar que obtuviera la empresa del ámbito elegido de la obra de arquitectura. 
Como un método genérico, el ADM está destinado a ser utilizado por empresas en una
amplia variedad de diferentes geografías y se aplica en diferentes tipos de
sectores verticales / industria. Como tal, puede ser, pero no necesariamente tiene
que ser, adaptado a las necesidades específicas. Por ejemplo, puede ser utilizado
en conjunción con el conjunto de entregables de otro marco, cuando éstos han sido
considerados para ser más apropiado para una organización específica. (Por ejemplo,
muchas agencias federales de Estados Unidos han desarrollado marcos individuales
que definen los entregables específicos para sus necesidades del servicio en
particular.) 

Estas cuestiones se examinan en detalle en 5.3 Adaptación de la ADM .

5.2.2 Estructura básica

La estructura básica de la ADM se muestra en la Figura 5-1 .

  Página 44 de 670 

TOGOF 9.1    
A lo largo del ciclo de ADM, es necesario que haya validación frecuente de
resultados contra las expectativas originales, tanto los de todo el ciclo de ADM, y
aquellos para la fase particular del proceso.

Figura 5‐1: Arquitectura Ciclo de Desarrollo   
Las fases del ciclo de ADM se dividen además en pasos; por ejemplo, los pasos
dentro de las fases de desarrollo de la arquitectura (B, C, D ) son los siguientes:
     Seleccione los modelos de referencia, puntos de vista, y herramientas 
Desarrollar Arquitectura de referencia Descripción  Desarrollar Arquitectura Target
Descripción  Realizar análisis de las deficiencias  Definir los componentes de la
hoja de ruta candidatos 

  Página 45 de 670 

TOGOF 9.1    
    Resolver los impactos en la Arquitectura del Paisaje  Llevar a cabo una
revisión formal de las partes interesadas  Finalizar la Arquitectura  Crear
Arquitectura Definición de documento 

La fase de gestión de requisitos es una fase continua que asegura que cualquier
cambio en los requisitos son manejados a través de los procesos de gobernanza
adecuadas y reflejadas en todas las demás fases. Una empresa puede optar por grabar
todos los nuevos requisitos, incluidos los que están en el ámbito de la declaración
actual de Arquitectura de Trabajo a través de un repositorio de requisitos
individuales. Las fases del ciclo se describen en detalle en los siguientes
capítulos dentro de la Parte II . Tenga en cuenta que la salida se genera durante
todo el proceso, y que la salida en una fase temprana puede ser modificado en una
fase posterior. El control de versiones de salida se gestiona a través de los
números de versión. En todos los casos, el esquema de numeración de ADM se
proporciona como un ejemplo. Debe ser adaptado por el arquitecto para satisfacer
las necesidades de la organización y trabajar con las herramientas de arquitectura
y bases empleadas por la organización. En particular, una convención de numeración
de versiones se utiliza dentro de la ADM para ilustrar la evolución de la línea de
base y objetivo Arquitectura Definiciones. Tabla 5-1 describe cómo se utiliza esta
convención.

 
Fase A: Architecture Vision Entregable Arquitectura Visión Contenido Negocios
Arquitectura Datos Arquitectura Aplicación Arquitectura Tecnología de Arquitectura
B: Arquitectura de Negocios C: Sistemas de Información Arquitectura Arquitectura
Definición Documento Arquitectura Definición Documento Negocios Arquitectura Datos
Arquitectura Aplicación Arquitectura Tecnología de Versión Descripción 0.1 Versión
0.1 indica que un esquema de alto nivel de la arquitectura está en su lugar. 0.1
Versión 0.1 indica que un esquema de alto nivel de la arquitectura está en su
lugar. 0.1 Versión 0.1 indica que un esquema de alto nivel de la arquitectura está
en su lugar. 0.1 Versión 0.1 indica que un esquema de alto nivel de la arquitectura
está en su lugar. 1.0 Versión 1.0 indica una revisión formal, la arquitectura
detallada. 1.0 Versión 1.0 indica una revisión formal, la arquitectura detallada.
Versión 1.0 indica una revisión formal, la arquitectura detallada. Versión 1.0
indica una revisión formal, la

1.0 1.0

D: Architecture

Arquitectura

  Página 46 de 670 

TOGOF 9.1    
Tecnología Definición Documento Arquitectura arquitectura detallada.

Tabla 5‐1: Convención de Numeración ADM Version 

5.3 Adaptación de la ADM

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
adaptarse a necesidades específicas. Una de las tareas antes de aplicar la ADM es
revisar sus componentes para la aplicabilidad y, a continuación, adaptarlos según
convenga a las circunstancias de la empresa individual. Esta actividad también
puede producir un ADM "específica de la empresa". Una de las razones para querer
adaptar el ADM, lo que es importante destacar, es que el orden de las fases de la
ADM es hasta cierto punto depende de la madurez de la disciplina de arquitectura
dentro de la empresa. Por ejemplo, si el caso de negocio para hacer arquitectura en
absoluto no es bien reconocido, a continuación, crear una visión de la Arquitectura
es casi siempre esencial; y una detallada arquitectura de negocio a menudo tiene
que venir a continuación, con el fin de apuntalar la Architecture Vision, detalle
el caso de negocios para el trabajo restante arquitectura, y asegurar la
participación activa de los principales interesados en que el trabajo. En otros
casos puede ser preferido un orden ligeramente diferente; por ejemplo, un
inventario detallado del entorno de línea de base se puede hacer antes de emprender
la Arquitectura Empresarial. El orden de las fases puede definirse también por los
principios de la arquitectura y los principios de negocio de una empresa. Por
ejemplo, los principios empresariales pueden dictar que se preparará a la empresa a
ajustar sus procesos de negocio para satisfacer las necesidades de una solución
empaquetada, para que pueda implementarse rápidamente para permitir una respuesta
rápida a los cambios del mercado. En tal caso, la arquitectura de negocio (o al
menos la realización de la misma), así pueden seguir a la finalización de la
Arquitectura de Sistemas de Información o de la Tecnología de la Arquitectura. Otra
razón para querer adaptar el ADM es si TOGAF se va a integrar con otro marco
empresarial (como se explica en la Parte I , 2,10 Uso de TOGAF con otros
marcos ).Por ejemplo, una empresa puede desear usar TOGAF ADM y su genérico en
relación con el Marco conocido Zachman, u otro entorno de arquitectura empresarial
que tiene un conjunto definido de prestaciones específicas para un sector vertical,
en particular: Gobierno, Defensa, e-Business , Telecomunicaciones, etc El ADM se ha
diseñado específicamente con este potencial de integración en la mente. Otras
posibles razones para querer adaptar el ADM incluyen:  El ADM es uno de los muchos
procesos empresariales que conforman el modelo de gobierno corporativo. Es
complementario a, y de apoyo a otros procesos de gestión de los programas estándar,
tales como los de autorización, gestión de riesgos, la planificación empresarial y
la presupuestación, la planificación del desarrollo, desarrollo de sistemas, y las
adquisiciones.  El ADM se encargó para su uso por un contratista principal o el
plomo en una situación de la contratación externa, y debe adaptarse para alcanzar
un compromiso adecuado entre las prácticas existentes del contratista y los
requisitos de la empresa contratante. 

  Página 47 de 670 

TOGOF 9.1    
 La empresa es una empresa pequeña y mediana, y desea utilizar un método "cut-
down" más en sintonía con el nivel reducido de recursos y la complejidad del
sistema típico de dicho entorno.  La empresa es muy grande y complejo, que
comprende muchas "empresas" independientes, aunque interrelacionados dentro de un
marco general de colaboración de negocios, y el método de la arquitectura debe
adaptarse a reconocer esto. Diferentes enfoques para la planificación y la
integración se pueden utilizar en tales casos, incluyendo las siguientes
(posiblemente en combinación):  o La planificación de arriba hacia abajo y el
desarrollo - el diseño del conjunto de meta-empresarial interconectado como una
sola entidad (un ejercicio que normalmente se extiende a los límites del sentido
práctico)  Desarrollo de una arquitectura o "genérico" de "referencia", típico de
las empresas dentro de la organización, pero que no representan ninguna empresa
específica, que a su vez se espera que las empresas individuales de adaptación con
el fin de producir una "instancia" arquitectura adaptada a la empresa de que se
trate .  Replicación - el desarrollo de una arquitectura específica para una
empresa, implementar como una prueba de concepto, y luego tomar que como una
"arquitectura de referencia "para ser clonado en otras empresas. 

En un entorno de varios proveedores o de producción, una arquitectura genérica para

una familia de productos se refiere a menudo como una "Línea de Arquitectura ",y el
proceso análogo al descrito anteriormente se denomina "(basado en la arquitectura)
Línea de productos de ingeniería". El ADM se dirige principalmente a los
arquitectos en las empresas usuarias de TI, sino una organización de proveedores
cuyos productos se basan IT-bien podría desear para adaptarlo como un método
genérico para un desarrollo Línea de Producto Arquitectura. 
5.4 Arquitectura de Gobierno
El ADM, ya sea adaptada por la organización o se utiliza como documentado aquí, es
un proceso clave para ser gestionados de la misma manera que otros artefactos
arquitectura clasifican mediante la Empresa Continuum y se mantienen en la
arquitectura de repositorio. La Junta de Arquitectura debe estar convencido de que
el método se está aplicando correctamente en todas las fases de una arquitectura de
desarrollo iteración. El cumplimiento de la ADM es fundamental para la gobernanza
de la arquitectura, para asegurar que todas las consideraciones se hacen y se
producen todos los entregables requeridos. La gestión de todos los artefactos
arquitectónicos, la gobernanza y los procesos relacionados debe apoyarse en un
entorno controlado. Normalmente, esto se basa en uno o más repositorios de soporte
de objeto con versiones y control de procesos y el estado. Las principales áreas de
información que gestiona un repositorio de gobierno deben contener los siguientes
tipos de información:  Datos de referencia (garantía de los propios repositorios
de la organización / empresa Continuum, incluyendo los datos externos, por ejemplo,
COBIT, ITIL): Se utiliza para la orientación y la instrucción durante la ejecución
del proyecto. Esto incluye los detalles de la

  Página 48 de 670 

TOGOF 9.1    
información antes mencionados. Los datos de referencia incluye una descripción de
los propios procedimientos de gobierno.   Estado de proceso : Toda la información
sobre el estado de todos los procesos de gobernanza será administrado; ejemplos de
ello son las solicitudes pendientes de cumplimiento, solicitudes de dispensa, y
evaluaciones de cumplimiento investigaciones.  Auditoría de la información : Esto
grabará todas las acciones del proceso de gobernanza completados y se utilizará
para apoyar:  o Las decisiones clave y el personal responsable para cualquier
proyecto de arquitectura que ha sido sancionado por el proceso de gobernanza  Una
referencia para la futura evolución del proceso arquitectónico y el apoyo,
orientación y prioridad 

Los artefactos de gobierno y el proceso son ellos mismos parte de los contenidos de
la Arquitectura Repository.

5.5 La determinación del alcance de la Arquitectura

Hay muchas razones para restringir (o restringir) el alcance de la actividad
arquitectónica a realizar, la mayoría de los cuales se relacionan con 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 que deben
abordarse dentro de la arquitectura  La disponibilidad de las personas, las
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 eficaz. Esto requiere de un conjunto de particiones alineadas
"arquitectura" que aseguran los arquitectos no están trabajando en actividades
duplicadas o contradictorias.También se requiere la definición de reutilización y
de cumplimiento relaciones entre las particiones de arquitectura. La división de la
empresa y su actividad relacionada con la arquitectura-se analiza con más detalle
en el 40. Arquitectura de particionamiento . Cuatro dimensiones se suelen utilizar
para definir y limitar el alcance de una arquitectura :  Amplitud : ¿Cuál es la
magnitud de la empresa, y qué parte de esa medida será esta arquitectura de acuerdo
con el esfuerzo?  o Muchas empresas son muy grandes, que comprende de manera
efectiva una federación de unidades organizativas que válidamente podría
considerarse 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 borrosa de
la empresa comercial tradicional combinado con proveedores, clientes y socios. 

  Página 49 de 670 

TOGOF 9.1    
 Profundidad : ¿En qué nivel de detalle debe ir el esfuerzo architecting? ¿Cuánto
arquitectura es "suficiente"? ¿Cuál es la adecuada delimitación entre el esfuerzo
de la arquitectura y otras actividades relacionadas (diseño de sistemas, ingeniería
de sistemas, sistemas de desarrollo)?  Período de tiempo : ¿Cuál es el período de
tiempo que debe ser articulada para la Architecture Vision, y ¿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 es así, ¿cuántos Arquitecturas Transición
se han de determinar, y cuáles son sus periodos de tiempo?  Arquitectura Dominios :
Una descripción completa de arquitectura empresarial debe contener los cuatro
dominios de la arquitectura (de negocios, datos, aplicaciones, tecnología), pero la
realidad de los recursos y las limitaciones de tiempo a menudo significan que no
hay tiempo suficiente, la financiación o los recursos para construir una de arriba
hacia abajo , todo incluido descripción de la arquitectura que abarca las cuatro
áreas de arquitectura, aunque el alcance de la empresa es elegida para ser menor
que el alcance total de la empresa en general. 

Por lo general, el alcance de una arquitectura se expresa en primer lugar en

términos de amplitud, profundidad y tiempo. Una vez que se comprendan estas
dimensiones, una combinación adecuada de los dominios de arquitectura se puede
seleccionar, apropiadas para el problema que se aborde. Las técnicas para el uso de
la ADM para desarrollar una serie de arquitecturas relacionadas se discuten en 20.
Aplicando la ADM a través de la arquitectura del paisaje . Las cuatro dimensiones
del alcance arquitectura se exploran en detalle a continuación. En cada caso, en
particular en entornos de gran escala donde arquitecturas se desarrollan
necesariamente de una manera federada, existe el peligro de arquitectos
optimización dentro de su propio alcance de la actividad, en lugar de en el nivel
de la empresa global. A menudo es necesario sub-optimizan en un área en particular,
con el fin de optimizar a nivel de empresa. El objetivo debe ser siempre de buscar
el mayor grado de comunalidad y centrarse en los módulos escalables y reutilizables
con el fin de maximizar la reutilización a nivel de empresa.

5.5.1 Amplitud
Una de las decisiones más importantes es el foco de los esfuerzos de la
arquitectura, en cuanto a la amplitud de la actividad general de la empresa para
cubrir (que sectores empresariales específicos, funciones, organizaciones, zonas
geográficas, etc.) A menudo es necesario contar con una serie de diferentes
arquitecturas existentes en una empresa, se centró en los plazos determinados,
funciones de negocios, o los requerimientos del negocio. Para las grandes empresas
complejas arquitecturas federados - desarrollados de forma independiente,
mantenidos y administrados arquitecturas que se integran posteriormente dentro de
un marco de integración - son típicos. Dicho marco especifica los principios de
interoperabilidad, la migración, y la conformidad. Esto permite que las unidades de
negocio específicas que tienen arquitecturas desarrolladas y reguladas como
proyectos de arquitectura independientes. Información adicional y orientación sobre
cómo especificar los requisitos de interoperabilidad para las diferentes soluciones
se pueden encontrar en la Parte III , 29. Requisitos de interoperabilidad .

  Página 50 de 670 

TOGOF 9.1    
La viabilidad de una única arquitectura de toda la empresa para cada función de
negocio o propósito puede ser rechazada por ser demasiado complejo y difícil de
manejar.En estas circunstancias, se sugiere que un número de diferentes
arquitecturas empresariales existen en una empresa. Estas arquitecturas
empresariales se centran en los plazos determinados, segmentos de negocios o
eventos, y los requisitos específicos de la organización. En tal caso, tenemos que
crear la arquitectura de la empresa global como una "federación" de estas
arquitecturas empresariales. Una manera eficaz de gestionar y explotar estas
arquitecturas empresariales es adoptar un modelo de publicación y suscripción que
permite a la arquitectura para ser puesto bajo un marco de gobernanza. En este
modelo, los desarrolladores de arquitectura y arquitectura consumidores en los
proyectos (los lados de la oferta y la demanda de trabajo de la arquitectura) se
inscriben para un marco de beneficio mutuo de gobierno que garantice que:  
Material arquitectónico es de buena calidad, hasta a la fecha, aptas para esta
finalidad, y publicado (examinó y aprobó que se hagan públicos).  El uso de
material de la arquitectura puede ser monitoreada, y el cumplimiento de las normas,
modelos y principios se puede exhibir, a través de:  o Un proceso de evaluación de
la conformidad que describe lo que el usuario está suscribiendo, y evalúa su nivel
de cumplimiento  Un proceso de dispensación que pueden conceder dispensas de
adhesión a las normas de arquitectura y directrices en casos específicos (por lo
general con un fuerte imperativo de negocio) 

Publicación y suscripción técnicas se están desarrollando como parte de generales

de gobierno de TI y específicamente para el ámbito de Defensa.

5.5.2 Profundidad
Se debe tener cuidado al juzgar el nivel de detalle adecuado para ser capturado,
basado en el uso previsto de la arquitectura de la empresa y las decisiones que se
tomen con base en ella. Es importante que un nivel constante e igual de profundidad
puede completar en cada dominio de la arquitectura (negocio, los datos, la
aplicación, la tecnología) incluido en el esfuerzo de la arquitectura. Si se omite
detalle pertinente, la arquitectura no puede ser útil. Si se incluye un detalle
innecesario, el esfuerzo de la arquitectura puede exceder el tiempo y los recursos
disponibles, y / o la arquitectura resultante puede ser confuso o desordenado.
Desarrollo de arquitecturas en diferentes niveles de detalle dentro de una empresa
se analiza en más detalle en la 20. Aplicando la ADM a través de la arquitectura
del paisaje . También es importante para predecir los futuros usos de la
arquitectura de modo que, dentro de las limitaciones de recursos, la arquitectura
puede ser estructurado para dar cabida a la adaptación futura, la extensión o la
reutilización. La profundidad y el detalle de la arquitectura de la empresa tiene
que ser suficiente para su propósito, y no más. Iteraciones de la ADM se basarán en
los artefactos y las capacidades creadas durante la iteración anterior. Hay una
necesidad de documentar todos los modelos en una empresa, con el nivel de detalle
apropiado a la necesidad del ciclo de ADM actual. La clave es entender el estado de
los trabajos de arquitectura de la empresa, y lo que de manera realista se puede
lograr con los recursos y las competencias disponibles y, a continuación, centrarse
en la identificación y la entrega del valor que

  Página 51 de 670 
TOGOF 9.1    
se puede lograr. Valor de los interesados es un elemento clave: un alcance
demasiado amplio puede disuadir a algunas partes interesadas (sin retorno de la
inversión).

5.5.3 Período de tiempo

El ADM se describe en términos de un único ciclo de Architecture Vision, y un
conjunto de arquitecturas objetivo (de negocios, datos, aplicaciones, Tecnología )
que permiten la aplicación de la visión. En tales casos, una visión más amplia se
puede tomar, por lo que una empresa está representada por varias instancias
diferentes de arquitectura (por ejemplo, estratégica, segmento, capacidad), cada
uno en representación de la empresa en un momento determinado en el tiempo. Un
ejemplo de arquitectura representará al estado actual de la empresa (el "tal cual",
o línea de base). Otro ejemplo de arquitectura, tal vez definida sólo parcialmente,
representará a la última meta de estado final (la "visión"). En el medio,
intermedio o instancias "Arquitectura de Transición" puede definirse, comprendiendo
cada uno su propio conjunto de arquitectura objetivo Descripciones. Un ejemplo de
cómo esto puede lograrse se da en la Parte III , 20. Aplicando la ADM a través de
la arquitectura del paisaje . Por este método, el trabajo Arquitectura objetivo se
divide en dos o más etapas diferenciadas:

1. En primer lugar, el desarrollo de arquitectura objetivo Descripciones para el

sistema en su
conjunto (a gran escala), lo que demuestra una respuesta a los objetivos y las
preocupaciones de los interesados durante un período de tiempo relativamente
distantes (por ejemplo, un período de seis años). 

2. A continuación, desarrollar una o más descripciones de "Arquitectura de

Transición", como
incrementos o mesetas, cada uno de acuerdo con y convergen en las Descripciones de
Arquitectura de destino, y la descripción de los detalles del incremento en
cuestión.  En este enfoque, las arquitecturas de destino son de carácter evolutivo,
y requieren una revisión periódica y actualización de acuerdo con la evolución de
las necesidades y la evolución de la tecnología de la empresa, mientras que las
arquitecturas de transición son (por diseño) incremental en la naturaleza, y, en
principio, no deberían evolucionar durante el fase de aplicación del incremento, a
fin de evitar el síndrome del "blanco móvil". Esto, por supuesto, sólo es posible
si el calendario de aplicación está bajo un estricto control y relativamente corta
(por lo general menos de dos años). Las Arquitecturas objetivo siguen siendo
relativamente genérico, y debido a que son menos vulnerables a la obsolescencia de
las arquitecturas de transición. Ellos encarnan sólo las decisiones arquitectónicas
estratégicas clave, que deben ser bendecidos por los interesados desde el
principio, mientras que las decisiones arquitectónicas detalladas en las
arquitecturas de transición están deliberadamente pospusieron la medida de lo
posible (es decir, justo antes de la aplicación) a fin de mejorar la capacidad de
respuesta frente a vis las nuevas tecnologías y productos. La empresa evoluciona
mediante la migración a cada una de estas arquitecturas de transición a su vez.
Como se implementa cada Arquitectura Transición, la empresa logra un estado
coherente, operativo en el camino a la visión final. Sin embargo, esta visión sí se
actualiza periódicamente para reflejar los cambios en el entorno empresarial y la
tecnología, y en efecto puede en realidad

  Página 52 de 670 

TOGOF 9.1    
nunca puede lograr, como se describe en un principio. Todo el proceso se prolonga
durante todo el tiempo que la empresa existe y continúa cambiando. Esta ruptura de
la descripción de la arquitectura en una familia de productos de arquitectura
relacionados de curso requiere una gestión eficaz del conjunto y sus relaciones.

5.5.4 Arquitectura Dominios

Una arquitectura completa empresa debe abordar las cuatro áreas de arquitectura
(negocio, datos, aplicaciones, tecnología), pero la realidad de las limitaciones de
tiempo de recursos y, a menudo significa que no hay tiempo suficiente, la
financiación o los recursos para construir una de arriba hacia abajo, todo incluido
descripción de la arquitectura que abarca los cuatro dominios de la arquitectura.
Descripciones Arquitectura normalmente se construyen con un propósito específico en
mente - un conjunto específico de factores de negocio que impulsan el desarrollo de
la arquitectura - y clarificación de la cuestión específica (s) que la descripción
de la arquitectura tiene la intención de ayudar a explorar, y las preguntas que se
espera que Ayuda respuesta, es una parte importante de la fase inicial de la ADM.
Por ejemplo, si el objetivo de un esfuerzo particular arquitectura es definir y
analizar las opciones tecnológicas para lograr una capacidad particular, y los
procesos fundamentales de negocio no están abiertos a la modificación, a
continuación, un completo Business Architecture bien puede no estar justificada.
Sin embargo, debido a que las arquitecturas de datos, aplicaciones y Tecnología
Construir sobre la arquitectura de negocio, la arquitectura de negocio todavía
necesita ser pensado y entendido. Si bien las circunstancias a veces pueden dictar
la construcción de una descripción de la arquitectura no contiene todos los cuatro
dominios de arquitectura, debe entenderse que tales una arquitectura no puede, por
definición, una arquitectura completa de la empresa. Uno de los riesgos es la falta
de consistencia y, por tanto, la capacidad de integrar. Integración o bien tiene
que venir más tarde - con sus propios costos y riesgos - o los riesgos y las
ventajas comparativas asociadas al no desarrollar una necesidad arquitectura
completa e integrada para ser articulado por el arquitecto, y comunicada y
comprendida por la gestión de la empresa.

5.6 Arquitectura de Integración

Arquitecturas que se crean para hacer frente a un subconjunto de temas dentro de
una empresa requieren un marco coherente de referencia para que puedan ser
considerados como un grupo, así como prestaciones de punto. Las dimensiones que se
utilizan para definir el límite ámbito de una única arquitectura (por ejemplo,
nivel de detalle, la arquitectura de dominio, etc) suelen ser las mismas
dimensiones que deben abordarse al examinar la integración de muchas
arquitecturas . Figura 5-2 ilustra cómo diferentes tipos de arquitectura tienen que
coexistir. En la actualidad, el estado de la técnica es tal que la integración
arquitectura puede llevarse a cabo sólo en el extremo inferior del espectro de
integrabilidad. Los factores clave a considerar son la granularidad y el nivel de
detalle en cada artefacto, y la madurez de las normas para el intercambio de
descripciones arquitectónicas.

  Página 53 de 670 

TOGOF 9.1    

 
  Figura 5‐2: Integración de la Arquitectura Artefactos 

Como las organizaciones a abordar temas comunes (como la Arquitectura Orientada a

Servicios (SOA), y la infraestructura de información integrada), y modelos de datos
universales y estructuras de datos estándar surgir, se facilitará la integración
hacia el extremo superior del espectro. Sin embargo, siempre habrá la necesidad de
una gobernanza normas efectiva para reducir la necesidad de manual de coordinación
y resolución de conflictos.

5.7 Resumen
El TOGAF ADM define una secuencia recomendada para las diferentes fases y pasos a
seguir en el desarrollo de una arquitectura, pero no se puede recomendar un alcance
- esto tiene que ser determinada por la propia organización, teniendo en cuenta que
la secuencia recomendada de desarrollo en el proceso de ADM es iterativo, con la
profundidad y amplitud de alcance y los resultados aumentan con cada iteración.
Cada iteración se sumará recursos para Arquitectura Repositorio de la organización.
Mientras que un marco completo es útil (de hecho, esencial) para tener en cuenta
como el último objetivo a largo plazo, en la práctica no es una decisión clave que
hacerse en cuanto al alcance de un esfuerzo de la arquitectura empresarial
específica. Siendo este el caso, es vital para comprender la base sobre la cual se
toman las decisiones de alcance están realizando, y para establecer expectativas
adecuado para lo que es el objetivo del esfuerzo. La directriz principal es
centrarse en lo que crea valor para la empresa, y para seleccionar el alcance
horizontal y vertical, y los períodos de tiempo, en consecuencia. Si es o no es la
primera vez, entender que este ejercicio se repetirá, y que las iteraciones futuras
se basarán en lo que se está creando en el esfuerzo actual, añadiendo mayor anchura
y profundidad.

  Página 54 de 670 

TOGOF 9.1      

6. Fase Preliminar
En este capítulo se describen las actividades de preparación e iniciación
necesarias para cumplir la directiva de negocio para una nueva arquitectura de la
empresa, incluyendo la definición de un marco de la Organización de una
arquitectura específica y la definición de principios.

  Figura 6‐1: Etapa Preliminar    Página 55 de 670 

TOGOF 9.1    

6.1 Objetivos
Los objetivos de la fase preliminar son los siguientes:

1. Determinar la capacidad Arquitectura deseada por la organización: 

o Revisar el contexto de la organización para la realización de la arquitectura
empresarial  Identificar y el alcance de los elementos de las organizaciones
empresariales afectadas por la Capacidad de Arquitectura  Identificar los marcos
establecidos, métodos y procesos que se cruzan con la capacidad de Arquitectura 
Establecer destino Capability Maturity 

2. Establecer la Capacidad de Arquitectura: 

o o Definir y establecer el modelo de organización de la Arquitectura Empresarial 
Definir y establecer el proceso detallado y recursos para la gobernanza de la
arquitectura  Seleccionar y aplicar herramientas que apoyan la capacidad
Arquitectura  Definir los principios de la arquitectura 
o o

6.2 Enfoque
Esta Fase Preliminar trata de definir "dónde, qué, por qué, quién, y cómo lo
hacemos arquitectura" en la empresa de que se trate. Los principales aspectos son
los siguientes:        Definición de la empresa  La identificación de
factores clave y elementos en el contexto de la organización  Definición de los
requisitos para la obra de arquitectura  Definición de los principios de la
arquitectura que informen de cualquier obra de arquitectura  Definir el marco para
ser utilizado  Definición de las relaciones entre los marcos de gestión  La
evaluación de la madurez de arquitectura empresarial 

La arquitectura de la empresa ofrece una visión estratégica de arriba hacia abajo

de una organización para que los ejecutivos, planificadores, arquitectos, e
ingenieros coherentemente coordinar, integrar y llevar a cabo sus actividades. El
entorno de arquitectura empresarial proporciona el contexto estratégico de este
equipo para operar dentro.

  Página 56 de 670 

TOGOF 9.1    
Por lo tanto, el desarrollo de la arquitectura de la empresa no es una actividad
solitaria y los arquitectos de la empresa tiene que reconocer la interoperabilidad
entre sus marcos y el resto de la empresa. Objetivos y aspiraciones de negocio
estratégicas, provisionales, y tácticas se deben cumplir. Del mismo modo, la
arquitectura de la empresa debe reflejar este requisito y permitir el
funcionamiento de la arquitectura de la disciplina en los diferentes niveles de la
organización. Dependiendo de la escala de la empresa y el nivel de compromiso
presupuestario para la empresa de arquitectura la disciplina, una serie de enfoques
puede ser adoptado a subdividir o arquitectura partición equipos, procesos y
resultados. Enfoques para la arquitectura de partición se analizan en la Parte V ,
40. Arquitectura de particionamiento. La Fase Preliminar se debe utilizar para
determinar el enfoque que se desea para la partición y establecer las bases para el
enfoque elegido para ser puesto en práctica. La Fase Preliminar podrá ser revisada,
de la fase Architecture Vision (ver Parte III , 19. Aplicando la iteración a la ADM
), con el fin de garantizar que la arquitectura de Capacidad de la organización es
adecuada para hacer frente a un problema de arquitectura específica.

6.2.1 Empresa
Uno de los principales retos de la arquitectura de la empresa es la de ámbito
empresarial. El ámbito de la empresa, y si es federado, determinará las partes
interesadas que se derivarán mayor beneficio de la Capacidad de la arquitectura
empresarial. Es imperativo que un patrocinador es nombrado en esta etapa para
garantizar que la actividad resultante tiene los recursos para continuar y el claro
apoyo de la gestión empresarial. La empresa puede abarcar muchas organizaciones y
los deberes del patrocinador deben velar por que todas las partes interesadas se
incluyen en la definición, establecimiento y utilizando la capacidad de
Arquitectura.

6.2.2 Contexto Organizacional

Con el fin de tomar decisiones efectivas e informadas sobre el marco para la
arquitectura para ser utilizado dentro de una empresa particular, es necesario
entender el contexto que rodea el marco de la arquitectura. Las áreas específicas a
tener en cuenta serían:  Los modelos comerciales para la arquitectura de la
empresa y los planes presupuestarios para la actividad de la arquitectura
empresarial. Cuando no existan tales planes, la Etapa Preliminar se debe utilizar
para desarrollar un plan de presupuesto.  Los grupos de interés para la
arquitectura de la empresa; sus problemas y preocupaciones clave.  Las intenciones
y la cultura de la organización, como se refleja en las directivas empresariales
bordo, los imperativos de negocio, estrategias de negocios, principios de negocio,
objetivos de negocio, y los impulsores del negocio.  . Los procesos actuales que
apoyan la ejecución de los cambios y el funcionamiento de la empresa, incluyendo la
estructura del proceso y también el nivel de rigor y formalidad aplicada dentro de
la organización Áreas de enfoque deben incluir: 

 

  Página 57 de 670 

TOGOF 9.1    
o o o o o o o o   Los métodos actuales para la descripción de la arquitectura 
Marcos y métodos de gestión de proyectos actuales  Marcos y métodos de gestión de
los sistemas actuales  Procesos y métodos de gestión de la cartera de proyectos
actuales  Procesos y métodos de gestión de la cartera de aplicaciones actuales 
Procesos y métodos de gestión de la cartera de tecnología actuales  Procesos y
métodos de gestión de carteras de información actuales  Sistemas de diseño y
desarrollo de esquemas y métodos actuales 

El paisaje Arquitectura de referencia, incluyendo el estado de la empresa y también

cómo el paisaje se representa actualmente en forma de documentación.  Las
habilidades y capacidades de la empresa y las organizaciones específicas que se
adopta el marco. 

Revisión del contexto de la organización debería establecer requisitos valiosos

sobre cómo adaptar el marco de arquitectura en términos de:     Nivel de
formalidad y el rigor que se aplicará  El nivel de sofisticación y los gastos
necesarios  Puntos de contacto con otras organizaciones, procesos, roles y
responsabilidades  Enfoque de la cobertura de contenidos 

6.2.3 Requisitos para la Arquitectura de Trabajo

Los imperativos de negocio detrás de la obra de arquitectura empresarial en coche
de los requisitos y parámetros de rendimiento de la obra de arquitectura. Deben ser
lo suficientemente clara para que esta fase puede alcance los resultados del
negocio y las necesidades de recursos y definir las necesidades de información de
negocios de la empresa de esquema y estrategias asociadas de la obra de
arquitectura empresarial por hacer. Por ejemplo, estos pueden incluir:     
Los requerimientos del negocio  Aspiraciones culturales  Los intentos de la
Organización  El propósito estratégico  Necesidades financieras de previsión 

Los elementos significativos de estos deben ser articulados de manera que el

patrocinador puede identificar todos los tomadores de decisiones y actores clave
involucrados en la definición y el establecimiento de una capacidad de
Arquitectura.

  Página 58 de 670 

TOGOF 9.1    
6.2.4 Principios
La Fase Preliminar define los principios de la arquitectura que formarán parte de
las limitaciones de cualquier obra de arquitectura realizada en la empresa. Los
desafíos de este se explican en la Parte III , 23. Arquitectura Principios . La
definición de la arquitectura de principios es fundamental para el desarrollo de
una empresa de arquitectura. Trabajo Architecture es informado por los principios
de negocio, así como Arquitectura Principios. Los Principios de Arquitectura mismos
también están normalmente basados en parte en los principios de negocio. Definición
de los principios laborales normalmente queda fuera del ámbito de la función de la
arquitectura. Sin embargo, dependiendo de cómo se definen y se promulgaron estos
principios dentro de la empresa, puede ser posible que el conjunto de Arquitectura
Principios de reexpresar también, o intersectoriales se refieren a un conjunto de
principios de actuación, los objetivos de negocio, y los conductores de negocios
estratégicos definidos en otros lugares dentro la empresa. Dentro de un proyecto de
arquitectura, el arquitecto normalmente necesitará asegurarse de que la definición
de estos principios de negocio, las metas y los conductores estratégicos están al
día, y para aclarar cualquier área de ambigüedad. La cuestión de la gobernanza
arquitectura está estrechamente ligada a la de Arquitectura Principios. El
organismo responsable de la gobernanza también normalmente se encargará de aprobar
los Principios de Arquitectura, y para resolver los problemas de la arquitectura.
Los desafíos de la gobernabilidad se explican en la Parte VII , 50.Arquitectura de
Gobierno .

6.2.5 Marcos de gestión

La Arquitectura Método de Desarrollo de TOGAF (ADM) es un método genérico,
destinado a ser utilizado por las empresas en una amplia variedad de tipos de
industrias y geografías. También está diseñado para su uso con una amplia variedad
de otros marcos de arquitectura de la empresa, si es necesario (aunque se puede
utilizar perfectamente en su propio derecho, sin adaptación). TOGAF tiene que
coexistir con y mejorar las capacidades operativas de otros marcos de gestión que
están presentes dentro de cualquier organización, ya sea formal o informalmente.
Además de estos marcos, la mayoría de las organizaciones tienen un método para el
desarrollo de soluciones, la mayoría de los cuales tienen un componente de TI. La
importancia de los sistemas es que reúne a los diversos dominios (también conocidas
como Personas, Procesos y Materiales / Tecnología) para ofrecer una capacidad de
negocio. Los principales marcos sugeridas para coordinarse con TOGAF son:  Gestión
de Capacidad de Empresas (Dirección de Operaciones y Planificación) que determina
lo que se requieren capacidades laborales para entregar valor de negocio que
incluye la definición de rendimiento de la inversión y de las medidas de control /
rendimiento requeridos.  Métodos de gestión de cartera / del proyecto que
determinan cómo una empresa gestiona sus iniciativas de cambio.  Métodos de gestión
de operaciones que describen cómo una empresa gestiona sus operaciones del día a
día, incluyendo IT. 

 

  Página 59 de 670 

TOGOF 9.1    
 Métodos de desarrollo de soluciones que formalizan la forma en que los sistemas
de negocio se entregan de acuerdo con las estructuras creadas en la arquitectura de
TI. 

Como se ilustra en la Figura 6-2 , estos marcos no son discretas y haya amplias
coincidencias entre éstos y la Administración de la capacidad del negocio. Este
último incluye la entrega de rendimiento medido el valor del negocio. El
significado general es que el arquitecto de la empresa la aplicación de TOGAF no se
centran casi exclusivamente en la implementación de TI, sino que debe tener en
cuenta el impacto que la arquitectura tiene en toda la empresa.

  Figura 6‐2: Marcos de gestión para coordinar con TOGAF 
Así, la fase preliminar consiste en hacer cualquier trabajo necesario adaptar la
ADM para definir un marco específico de la organización, ya sea utilizando los
entregables TOGAF o las entregas de otro marco. Los desafíos de este son discutidos
en 5.3 Adaptación de la ADM .

6.2.6 Relacionar los marcos de gestión

La Figura 6-3 ilustra un conjunto más detallado de dependencias entre los diversos
marcos y la actividad de planificación de negocios que incorpora el plan y la
dirección estratégica de la empresa. La arquitectura de la empresa se puede
utilizar para proporcionar una estructura para

  Página 60 de 670 

TOGOF 9.1    
todas las iniciativas empresariales, el Marco de Gestión de la cartera se puede
utilizar para entregar los componentes de la arquitectura, y el Marco de Gestión de
Operaciones apoya la incorporación de estos nuevos componentes dentro de la
infraestructura corporativa. Los planificadores de negocios están presentes en todo
el proceso y están en condiciones de apoyar y reforzar la arquitectura mediante la
retención de la aprobación de los recursos en las diversas etapas de la
planificación y el desarrollo. La metodología de desarrollo de la solución se
utiliza dentro del marco de gestión de cartera para planificar, crear y entregar
los componentes arquitectónicos se especifican en la cartera de proyectos y
charters. Estas prestaciones incluyen, pero no son exclusivamente, IT; por ejemplo,
un edificio nuevo, un nuevo conjunto de habilidades, el equipo de producción,
contratación, marketing, etc. Arquitectura empresarial potencialmente proporciona
el contexto para todas las actividades de la empresa. Se requiere que los marcos de
gestión para complementarse entre sí y trabajar en estrecha armonía por el bien de
la empresa.

  Figura 6‐3: Interoperabilidad y relaciones entre los marcos de gestión 
La planificación empresarial a nivel de estrategia proporciona la dirección inicial
de la arquitectura empresarial. Actualizaciones en el nivel anual de planificación
proporcionan un mayor nivel de orientación permanente. Planificación basada en la
capacidad es una de las muchas técnicas populares para la planificación de
negocios. Estructuras de arquitectura de la empresa la planificación de la
actividad en un marco integrado que considera la empresa como un sistema o sistema
de sistemas. Este enfoque integrado validará el plan de negocios y puede
proporcionar información valiosa para los planificadores de las empresas. En
algunas organizaciones, los arquitectos de la empresa se han movido o trabajar muy
de cerca con los grupos de dirección estratégica. TOGAF proporciona un marco para
la arquitectura empresarial. Gestión de la cartera / del proyecto es el marco de
administración que recibe la dirección estructurada y detallada que les permita
planificar y construir lo que se requiere, a sabiendas de que cada entrega será
asignado en su contexto (es decir, la pieza del rompecabezas que ofrecen servicio a
domicilio se ajusta a la rompecabezas corporativa que es la arquitectura de la
empresa). A menudo, este marco se basa en el Project Management Institute o la
oficina del Reino Unido de Comercio Gubernamental (PRINCE2) metodologías de gestión
de

  Página 61 de 670 

TOGOF 9.1    
proyectos. Arquitecturas de proyectos y detallada fuera del contexto de diseño
suelen estar basadas en metodologías de diseño de sistemas. Gestión de operaciones
recibe los entregables y luego integra y los sostiene dentro de la infraestructura
corporativa. A menudo, los servicios de gestión de servicios de TI se basan en ISO
20000 o BS15000 (ITIL).
6.2.7 Planificación de la Arquitectura Empresarial / Cambio de negocios Evaluación
de madurez
Modelos de Madurez de Capacidad (detallados en la Parte VII , 51. Arquitectura de
Madurez Modelos ) son formas útiles de evaluación de la capacidad de una empresa
para ejercer diferentes capacidades. Modelos de Madurez de Capacidad suelen
identificar factores seleccionados que se requieren para ejercer una capacidad. La
capacidad de una organización para ejecutar factores específicos proporciona una
medida de la madurez y puede ser usado para recomendar una serie de pasos
secuenciales para mejorar una capacidad. Es una evaluación que proporciona a los
ejecutivos una visión de mejorar pragmáticamente una capacidad. Un buen modelo de
madurez de la arquitectura empresarial cubre las características necesarias para
desarrollar y consumir arquitectura empresarial. Las organizaciones pueden
determinar sus propios factores y obtener los modelos de madurez adecuadas, pero se
recomienda tomar un modelo existente y personalizarlo según sea necesario. Existen
varios modelos de buenas, incluyendo NASCIO, y el Departamento de Comercio de
Arquitectura Capability Maturity Model EE.UU.. El uso de Modelos de Madurez de
Capacidad se detalla en la Parte VII , 51. Arquitectura de Madurez Modelos . Otros
ejemplos incluyen el Modelo de Madurez de EE.UU. Federal Enterprise Architecture. A
pesar de que los modelos son originarios de gobierno, son igualmente aplicables a
la industria.

6.3 Entradas
Esta sección define las entradas a la Etapa Preliminar.

6.3.1 Materiales de Referencia Externa a la Empresa  TOGAF 

 Otro marco (s) de la arquitectura, si es necesario 

6.3.2 Entradas para no Arquitectónicos  Estrategias de la Junta y los planes

de negocios a bordo, estrategia de negocio, estrategia de TI, los principios de
negocio, objetivos de negocio, y los conductores de negocios, cuando se pre-
existente 
 Marcos importantes que operan en el negocio; por ejemplo, la cartera / de gestión
de proyectos 

  Página 62 de 670 

TOGOF 9.1    
   Gobernanza y marcos legales, incluyendo la estrategia de gobierno
arquitectura, cuando pre-existente  Capacidad de Arquitectura  Los acuerdos de
asociación y de contrato 

6.3.3 Entradas de arquitectura

. Modelos pre-existentes para el funcionamiento de una capacidad de arquitectura
empresarial puede ser utilizado como una base para la Etapa Preliminar Entradas
incluiría:  Modelo de organización de Arquitectura Empresarial (véase la Parte
IV , 36.2.16 Modelo de Organización de Empresa de Arquitectura ), incluyendo:  o o
o o o  Ámbito de las organizaciones afectadas  La evaluación gestacional, lagunas,
y el enfoque de resolución  Roles y responsabilidades de equipo de arquitectura
(s)  Necesidades presupuestarias  Gobernabilidad y estrategia de apoyo 

Marco de arquitectura existente, en su caso, incluyendo:  o o o o o Método de

Arquitectura  Contenido de Arquitectura  Herramientas de configurar e implementar 
Principios Arquitectura  Arquitectura Repositorio 

6.4 Pasos
El TOGAF ADM es un método genérico, destinado a ser utilizado por una amplia
variedad de diferentes empresas, y en conjunción con una amplia variedad de otros
marcos de arquitectura, si es necesario. Así, la fase preliminar consiste en hacer
cualquier trabajo necesario para iniciar y adaptar la ADM para definir un marco
específico de la organización. Los desafíos de la adaptación del ADM a un contexto
organizativo concreto se analizan en detalle en 5.3 Adaptación de la ADM . El nivel
de detalle abordado en la Etapa Preliminar dependerá del alcance y los objetivos
del esfuerzo global de la arquitectura. El orden de los pasos de la Etapa
Preliminar (véase más adelante), así como el momento en que se inician formalmente
y completaron deben adaptarse a la situación en cuestión de acuerdo con el gobierno
arquitectura establecida. Los pasos dentro de la fase preliminar son los
siguientes:

  Página 63 de 670 

TOGOF 9.1    
      6.4.1 Alcance de las organizaciones empresariales impactado  6.4.2
Marcos Confirmar Gobernabilidad y Apoyo  6.4.3 Definir y establecer la arquitectura
empresarial Equipo y Organización  6.4.4 Identificar y establecer Arquitectura
Principios  6.4.5 Tailor TOGAF y, en su caso, Otros arquitectura marco seleccionado
(s)  6.4.6 Implementar herramientas de arquitectura 

6.4.1 Alcance de las organizaciones empresariales impactado  Identificar empresa

de la base (unidades) - aquellos que son los más afectados y lograr mayor valor de
la obra 
    Identificar empresariales blandos (unidades) - los que se ven el cambio a
su capacidad y trabajar con unidades básicas, pero son de otra forma no
directamente afectados  Identificar empresa extendida (unidades) - las unidades
fuera de la empresa de ámbito que se verán afectados en su propia arquitectura de
la empresa  Identificar las comunidades implicadas (empresas) - las partes
interesadas que se verán afectados y que están en los grupos de las comunidades 
Identificar gobierno involucrados, incluidos los marcos jurídicos y geografías
(empresas) 

6.4.2 Marcos Confirmar Gobernabilidad y Apoyo

El marco de la arquitectura será la piedra angular para el sabor (centralizada o
federada, ligero o pesado, etc) de la organización de la gobernanza arquitectura y
directrices que necesitan ser desarrolladas. Parte de la salida principal de esta
fase es un marco para la gobernanza de la arquitectura. Necesitamos entender cómo
se lleva material arquitectónico (normas, directrices, modelos, informes de
cumplimiento, etc) bajo el gobierno; es decir, qué tipo de características del
repositorio de gobierno van a ser necesarios, lo que las relaciones y la grabación
de estado son necesarios para determinar qué proceso de gobernanza (dispensación,
el cumplimiento, para llevar adelante, la jubilación, etc) tiene la propiedad de un
artefacto arquitectónico. Es probable que los modelos de gobierno y de apoyo
existentes en una organización tendrá que cambiar para apoyar el marco de
arquitectura recién adoptado. Para gestionar tendrá que ser evaluado para entender
su forma general y el contenido del cambio organizacional necesario para adoptar el
nuevo marco arquitectónico, el gobierno de la empresa actual y modelos de apoyo.
Además, tendrá que ser consultado sobre los posibles impactos que podrían ocurrir a
los patrocinadores y las partes interesadas para la arquitectura. Una vez
finalizado este paso, los puntos de contacto con la arquitectura y los impactos
probables deben ser entendidos y acordados por las partes interesadas pertinentes.

6.4.3 Definir y establecer la arquitectura empresarial Equipo y Organización 

Determinar la capacidad de la empresa y el negocio existente 

  Página 64 de 670 

TOGOF 9.1    
    Llevar a cabo una evaluación de la madurez de la empresa de arquitectura /
cambios en el negocio, si se requiere  Identificar las lagunas en las áreas de
trabajo existentes  Asignar roles y responsabilidades para la gestión de la empresa
Arquitectura capacidad y la gobernanza  Definir las solicitudes de cambio a los
programas y proyectos de negocio existentes:  o Informar existente arquitectura
empresarial y la arquitectura de TI de trabajo de las necesidades de las partes
interesadas  Solicitud de evaluación de impacto en sus planes y el trabajo 
Identificar áreas de interés común  Identifique las diferencias críticas y
conflictos de interés  Producir las solicitudes de cambio a las actividades de las
partes interesadas 

o o o o   

Determine las restricciones sobre el trabajo de arquitectura empresarial  Revise y

estoy de acuerdo con los patrocinadores y junta  Evaluar las necesidades
presupuestarias 

6.4.4 Identificar y establecer Arquitectura Principios

Arquitectura Principios (véase la Parte III , 23. Arquitectura Principios ) se
basan en los principios de negocio y son fundamentales en la creación de las bases
para la gobernanza de la arquitectura. Una vez que se entiende el contexto de la
organización, definir un conjunto de Principios de Arquitectura que es adecuado
para la empresa.

6.4.5 Tailor TOGAF y, en su caso, Otros arquitectura marco seleccionado (s)

En este paso, determinar lo que la adaptación de TOGAF se requiere. Considerar la
necesidad de:  Terminología Sastrería : Arquitectura practicantes deben usar
terminología que se entiende en general en toda la empresa. Adaptación debería
producir una terminología acordado fijar para la descripción de contenido
arquitectónico.  Adaptación del proceso : El TOGAF ADM proporciona un proceso
genérico para la realización de la arquitectura. La adaptación del proceso ofrece
la oportunidad de eliminar las tareas que ya se llevan a cabo en otras partes de la
organización, añadir tareas específicas de la organización (por ejemplo, los
puestos de control específicas) y alinear los procesos de ADM a los marcos de
procesos externos y puntos de contacto. puntos de contacto clave para ser dirigida
incluiría:  o o o Enlaces a los procesos de gestión de carteras de proyectos (y de
servicios)  Enlaces a ciclo vital del proyecto  Enlaces a los procesos de traspaso
de las operaciones 

  Página 65 de 670 

TOGOF 9.1    
o Enlaces a los procesos de gestión de operaciones (incluyendo la gestión de
configuración, gestión de cambios y gestión de servicios)  Enlaces a los procesos
de contratación 

o 

Contenido Sastrería : Usando el TOGAF Arquitectura del marco de contenido y Empresa

Continuum como base, la adaptación de la estructura del contenido y enfoque de
clasificación permite la adopción de marcos de contenido de terceros y también
permite la personalización del marco de apoyo a los requisitos específicos de la
organización. 

6.4.6 Implementar herramientas de arquitectura

El nivel de formalidad se utiliza para definir y gestionar contenidos arquitectura
será altamente dependiente de la escala, la sofisticación y la cultura de la
función de la arquitectura dentro de la organización. Con una comprensión de la
aproximación deseada a la arquitectura, es posible seleccionar herramientas de
arquitectura apropiados para apoyar la función de la arquitectura. El acercamiento
a las herramientas puede basarse en el uso relativamente informal de aplicaciones
de productividad de oficina estándar, o puede estar basada en una implementación
personalizada de herramientas de arquitectura especializados. Dependiendo del nivel
de sofisticación, la implementación de herramientas puede variar de una tarea
trivial para una actividad de aplicación del sistema más complicado. Problemas en
las herramientas de estandarización se analizan en la Parte V , 42. Herramientas
para el desarrollo de la arquitectura .

6.5 Salidas
Las salidas de la Fase Preliminar pueden incluir, pero no se limitan a:  Modelo de
organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de
Organización de Empresa de Arquitectura ), incluyendo:  o o o o o o  Ámbito de las
organizaciones afectadas  La evaluación gestacional, lagunas, y el enfoque de
resolución  Roles y responsabilidades de equipo de arquitectura (s)  Las
restricciones sobre el trabajo de arquitectura  Necesidades presupuestarias 
Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Arquitectura Principios
(ver la Parte IV , 36.2.4 Principios de Arquitectura ) 

  Página 66 de 670 

TOGOF 9.1    
o   Herramientas de configurar e implementar 

Arquitectura repositorio inicial (ver la Parte IV , 36.2.5 Arquitectura del

repositorio ), poblada de contenidos marco  Reformulación de, o referencia a los
principios de negocio, objetivos de negocio, y los conductores de negocios (véase
la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los
impulsores del negocio )  Solicitud de Arquitectura de trabajo (opcional) (véase la
Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo )  Arquitectura Governance
Framework (véase ( Parte VII , Governance Framework 50.2 Arquitectura ) 

 

Las salidas pueden incluir algunos o todos de los siguientes:  Catálogos:  o

Catálogo de Principios 

  Página 67 de 670 

TOGOF 9.1    

. 7 Fase A: Architecture Vision

En este capítulo se describe la fase inicial del desarrollo de métodos Arquitectura
(ADM). Incluye información acerca de la definición del alcance, la identificación
de las partes interesadas, la creación de la arquitectura de la Visión, y la
obtención de las aprobaciones.
  Figura 7‐1: Fase A: Architecture Vision 

7.1 Objetivos
Los objetivos de la Fase A son:   Desarrollar una visión aspiracional de alto
nivel de las capacidades y el valor del negocio para ser entregados como resultado
de la arquitectura de la empresa propuesta  Obtener la aprobación de una
Declaración de Arquitectura Trabajo que define un programa de trabajos para
desarrollar e implementar la arquitectura se indica en el Architecture Vision 

7.2 Enfoque
  Página 68 de 670 

TOGOF 9.1    
7.2.1 Generalidades
Fase A se inicia con la recepción de una Solicitud de Trabajo de Arquitectura de la
organización patrocinadora para la organización de la arquitectura. Los desafíos de
garantizar el adecuado reconocimiento y aprobación de la gestión empresarial, y el
apoyo y compromiso de la gerencia de línea, se analizan en la Parte VII, 50.1.4 IT
Governance . Fase A también define lo que es y lo que está fuera del alcance de los
esfuerzos de la arquitectura y las limitaciones que deben ser tratados. Decisiones
scoping deben hacerse sobre la base de una evaluación práctica de los recursos y la
disponibilidad de la competencia, y el valor que de manera realista se puede
esperar que obtuviera la empresa del ámbito elegido de obra de arquitectura. Los
desafíos de este son discutidos en 5.5 Alcance de la Arquitectura . Cuestiones
scoping abordan en la fase Architecture Vision estará restringido a los objetivos
específicos de este ciclo de ADM y se verá limitado dentro de la definición del
alcance global de la actividad de la arquitectura como establecido en la Fase
Preliminar y encarnado en el marco de la arquitectura. En situaciones en que el
marco de arquitectura en su lugar no es apropiado para lograr el deseado
Architecture Vision, revisar la Etapa Preliminar y ampliar el marco general de la
arquitectura de la empresa. Las restricciones serán normalmente informadas por los
principios de negocio y Arquitectura Principios, desarrollado como parte de la
Etapa Preliminar (véase 6. Fase Preliminar ). Normalmente, los principios de
negocio, objetivos de negocio, y los conductores estratégicos de la organización ya
están definidas en la empresa en otros lugares. Si es así, la actividad en la Fase
A está relacionado con garantizar que las definiciones existentes están al día, y
la aclaración de cualquier área de la ambigüedad. De lo contrario, se trata de la
definición de estos elementos esenciales para la primera vez. Del mismo modo, los
principios de la arquitectura que forman parte de las restricciones sobre el
trabajo de la arquitectura normalmente se han definido en la Etapa Preliminar
(véase 6. Fase Preliminar ). La actividad en la Fase A se ocupa de garantizar que
las definiciones de los principios existentes están al día, y la aclaración de
cualquier área de ambigüedad. De lo contrario, implica la definición de los
Principios de la configuración por primera vez, como se explica en la Parte III ,
23. Principios de Arquitectura .

7.2.2 Creando la Visión Arquitectura

El Architecture Vision ofrece el patrocinador con una herramienta clave para vender
los beneficios de la capacidad de propuesta a las partes interesadas y los
responsables dentro de la empresa. Architecture Vision describe cómo la nueva
capacidad se reunirá con los objetivos de negocio y los objetivos estratégicos y
atender las preocupaciones de los interesados en su aplicación. Aclarar y acordar
el propósito del esfuerzo arquitectura es una de las piezas clave de esta
actividad, y el propósito debe reflejarse claramente en la visión que se
crea.Proyectos de arquitectura a menudo se llevan a cabo con un propósito
específico en mente - un conjunto específico de factores de negocio que representan
el retorno de la inversión para las partes interesadas en el desarrollo de la
arquitectura. Aclarar ese propósito, y la demostración de la forma

  Página 69 de 670 

TOGOF 9.1    
en que se logrará mediante el desarrollo de la arquitectura propuesta, es el punto
central de la Architecture Vision. Normalmente, los elementos esenciales de la
Visión Arquitectura - como la misión de la empresa, la visión, la estrategia y los
objetivos - se han documentado como parte de alguna estrategia de negocio más
amplio o de la actividad de planificación empresarial que tiene su propio ciclo de
vida dentro de la empresa. En tales casos, la actividad en la Fase A se refiere a
la verificación y la comprensión de la estrategia y los objetivos de negocio
documentados, y posiblemente puente entre la estrategia empresarial y los
objetivos, por un lado, y la estrategia y los objetivos implícitos en la actual
arquitectura de la realidad. En otros casos, poco o ningún trabajo Arquitectura
negocios puede haber sido hecho hasta la fecha. En estos casos, habrá una necesidad
de que el equipo de arquitectura para investigar, verificar y obtener un buy-in de
los objetivos clave del negocio y los procesos que la arquitectura es apoyar. Esto
se puede hacer como un ejercicio independiente, ya sea desarrollo de la
arquitectura anterior, o como parte de la fase de iniciación de ADM (Fase
Preliminar). El Architecture Vision proporciona un primer corte, descripción de
alto nivel de la línea de base y Target Arquitecturas, que abarca los dominios de
negocio, datos, aplicaciones y tecnología. Estas descripciones de contorno se
desarrollan en fases posteriores. Escenarios de negocios son una técnica apropiada
y útil para descubrir y documentar los requerimientos del negocio, y para articular
una visión de la Arquitectura, que responda a esas necesidades. Escenarios de
negocio se describen en la Parte III , 26. Escenarios empresariales y objetivos de
negocio . Una vez que una visión de la Arquitectura está definido y documentado en
la Declaración de Arquitectura Trabajo, es fundamental utilizarlo para construir un
consenso, como se describe en la Parte VII , 50.1.4 IT Governance . Sin este
consenso es muy poco probable que la arquitectura final será aceptado por la
organización en su conjunto. El consenso está representado por la organización
patrocinadora que firma la Declaración de Arquitectura Obra.

7.2.3 Escenarios empresariales

El ADM tiene su propio método (un "método-dentro-de-método") para la identificación
y articulación de los requerimientos de negocio implicados en nueva capacidad 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", y se
describe en la Parte III , 26. Escenarios empresariales y objetivos de la empresa .
La técnica puede ser usada de forma iterativa, a diferentes niveles de detalle en
la descomposición jerárquica de la Arquitectura Empresarial.

7.3 Entradas
Esta sección define las entradas a la Fase A.

7.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 

  Página 70 de 670 

TOGOF 9.1    
7.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo
(véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 
 Principios de Actuación, los objetivos de negocio, y los conductores de negocios
(véase la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los
impulsores del negocio ) 
7.3.3 Entradas de arquitectura  Modelo de organización de Arquitectura
Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o o o o o o o  Ámbito de las organizaciones afectadas  La evaluación
gestacional, lagunas, y el enfoque de resolución  Roles y responsabilidades de
equipo de arquitectura (s)  Las restricciones sobre el trabajo de arquitectura 
Requisitos de reutilización  Necesidades presupuestarias  Las solicitudes de
cambio  Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Principios Arquitectura
(ver la Parte IV , 36.2.4 Principios Arquitectura ), incluidos los principios de
negocios, al pre-existente  Herramientas de configurar e implementar 

o 

Poblado Arquitectura repositorio (véase la Parte IV , 36.2.5 Arquitectura

Repositorio ) - la documentación existente de arquitectura (descripción marco,
descripciones arquitectónicas, las descripciones de línea de base, Abs, etc) 

7.4 Pasos
El nivel de detalle abordado en la Fase A dependerá del alcance y los objetivos de
la Solicitud de Arquitectura Trabajo o el subconjunto de alcance y los objetivos
asociados a esta iteración del desarrollo de la arquitectura. El orden de los pasos
en la Fase A (véase más adelante), así como el momento en que se inician
formalmente y completaron deben adaptarse a la situación en cuestión de acuerdo con
el gobierno arquitectura establecida.

  Página 71 de 670 

TOGOF 9.1    
Los pasos en la Fase A son como sigue:            7.4.1 Establecer el
Proyecto de Arquitectura  7.4.2 Identificar los grupos de interés, las
preocupaciones y los Requerimientos del Negocio  7.4.3 Confirmar y Empresariales
elaborada Objetivos, controladores de Negocios y restricciones  7.4.4 Evaluar las
capacidades empresariales  7.4.5 evaluar la preparación para la Transformación de
Negocios  7.4.6 Definir el alcance  7.4.7 Confirmar y Arquitectura elaborar
principios, incluidos los Principios de Actuación  7.4.8 Desarrollar Architecture
Vision  7.4.9 Definir el objetivo Arquitectura propuestas de valor y los
indicadores clave de rendimiento  7.4.10 Identificar los riesgos de transformación
empresarial y Mitigación Actividades  7.4.11 Desarrollar el Enunciado de
Arquitectura de Trabajo; Aprobación Secure 

7.4.1 Establecer el Proyecto de Arquitectura

Ejecución de los ciclos de ADM debe llevarse a cabo dentro del marco de gestión de
proyectos de la empresa. En algunos casos, los proyectos de arquitectura será
autónomo. En otros casos, las actividades de arquitectura serán un subconjunto de
las actividades dentro de un proyecto más amplio. En cualquier caso, la actividad
de la arquitectura debe ser planeadas y manejadas con prácticas aceptadas para la
empresa. Llevar a cabo los trámites necesarios para obtener el reconocimiento del
proyecto, la aprobación de la gestión social, y el apoyo y compromiso de la
gerencia de línea es necesario. Incluye referencias a otros marcos de gestión en el
uso dentro de la empresa, explicando cómo este proyecto se relaciona con esos
marcos.

7.4.2 Identificar los grupos de interés, las preocupaciones y los Requerimientos

del Negocio
Identificar las partes interesadas clave y sus preocupaciones / objetivos, y
definir los requisitos empresariales clave que se abordarán en el compromiso de la
arquitectura.Participación de los interesados en esta etapa se pretende lograr tres
objetivos:   Para identificar los componentes y los requisitos para ser probados
como Architecture Vision visión candidatos se desarrolla  Para identificar los
límites de alcance candidatos para el compromiso de limitar el alcance de la
investigación arquitectónica requerida 

  Página 72 de 670 

TOGOF 9.1    
 Para identificar las preocupaciones de las partes interesadas, los problemas y
los factores culturales que darán forma a cómo se presenta la arquitectura y
comunicados 

El principal producto resultante de esta etapa es un mapa de las partes interesadas

para el compromiso, que muestra que las partes interesadas participen con el
compromiso, su nivel de participación y sus principales preocupaciones (ver Parte
III , 24.3 Pasos en el proceso de gestión de los grupos de interés y 24,4 Plantilla
Stakeholder Mapa ). El mapa de las partes interesadas se utiliza para apoyar las
diversas salidas de la fase Architecture Vision, e identificar:   Las
preocupaciones y puntos de vista que son relevantes para este proyecto; esto se
refleja en la arquitectura de la visión (ver la Parte IV , 36.2.8 Architecture
Vision )  Los actores que están involucrados con el proyecto y, en consecuencia
constituyen el punto de partida para un plan de comunicaciones (ver la Parte IV ,
36.2.12 Plan de Comunicaciones )  Las funciones y responsabilidades clave en el
proyecto, que debe ser incluido en el Estado de Arquitectura de trabajo (ver la
Parte VII , 36.2.20 Declaración de Arquitectura de Trabajo ) 

Otra tarea clave será tener en cuenta que es necesario desarrollar para satisfacer
las diversas necesidades de los interesados vistas de arquitectura y puntos de
vista. Como se describe en la Parte III , 24. Gestión de los grupos de interés , la
comprensión en esta etapa que los interesados y el que las opiniones se deben
desarrollar es importante para establecer el alcance del trabajo. Durante la fase
de Architecture Vision, nuevos requerimientos generados para los futuros trabajos
de arquitectura en el ámbito de los requisitos seleccionados han de estar
documentados dentro de la arquitectura de Especificación de Requisitos, y las
nuevas necesidades que están fuera del alcance de los requisitos seleccionados
deben ser introducidos a los requisitos del repositorio de gestión a través del
proceso de gestión de requisitos.

7.4.3 Confirmar y Empresariales elaborada Objetivos, controladores de Negocios y

restricciones
Identificar los objetivos de negocio y los conductores estratégicos de la
organización. Si estos ya han sido definidos en otros lugares dentro de la empresa,
garantizar que las definiciones existentes son actuales, y aclarar cualquier área
de ambigüedad. De lo contrario, volver a los autores de la Declaración de
Arquitectura de trabajo y trabajar con ellos para definir estos elementos
esenciales y asegurar su aprobación por parte de la gestión empresarial. Definir
las restricciones que deben ser tratados, incluidas las limitaciones de toda la
empresa y las limitaciones específicas de cada proyecto (tiempo, calendario,
recursos, etc.) Las restricciones en toda la empresa pueden ser informados por la
empresa y Arquitectura principios desarrollados en la Fase Preliminar y aclararlas
en el marco de la Fase A.
7.4.4 Evaluar las capacidades empresariales
Es valioso para entender un conjunto de capacidades dentro de la empresa. Una parte
se refiere a la capacidad de la empresa para desarrollar y consumir la
arquitectura. La segunda parte se refiere a la línea de base y el nivel de
capacidad objetivo de la empresa.

  Página 73 de 670 

TOGOF 9.1    
Las lagunas identificadas en el Capability Arquitectura requieren iteración entre
Architecture Vision y la Fase Preliminar para asegurar que la capacidad de la
arquitectura es adecuada para abordar el alcance del proyecto de arquitectura (ver
Parte III , 19. Aplicando la iteración a la ADM ). Las lagunas o limitaciones, que
se identifican en la capacidad de la empresa para ejecutar el cambio informarán al
arquitecto en la descripción de la arquitectura destino y sobre la aplicación y el
Plan de Migración (véase la Parte IV , 36.2.14 Implementación y Plan de Migración )
creado en la Fase E y Fase F. Este paso busca entender las capacidades y los deseos
de la empresa a un nivel adecuado de abstracción (ver 20. Aplicando la ADM a través
de la Arquitectura del Paisaje ). Consideración de la brecha entre la línea base y
la capacidad objetivo de la empresa es fundamental. Mostrando las capacidades de
referencia y objetivos en el contexto de la empresa en general puede ser apoyado
por la creación de diagramas de cadena de valor que muestran la vinculación de las
capacidades relacionadas. Los resultados de la evaluación se documentan en una
Evaluación de Capacidad (véase la Parte IV , Evaluación de Capacidad de 36.2.10 ).

7.4.5 evaluar la preparación para la Transformación de Negocios

Una Evaluación de la preparación de transformación de negocios se puede utilizar
para evaluar y cuantificar la disposición de la organización para experimentar un
cambio.Esta evaluación se basa en la determinación y el análisis / calificación de
una serie de factores de preparación, como se describe en el 30. Evaluación de la
preparación de transformación de negocios . Los resultados de la evaluación de la
preparación se deben agregar a la evaluación de la capacidad (véase la Parte IV ,
Evaluación de Capacidad de 36.2.10 ). Estos resultados se utilizan para dar forma
al ámbito de la arquitectura, para identificar las actividades necesarias en el
proyecto de arquitectura, y para identificar las áreas de riesgo que abordar.

7.4.6 Definir el alcance

Definir lo que está dentro y lo que está fuera del alcance de los esfuerzos de
Arquitectura de referencia y arquitectura objetivo, entendiendo que la línea de
base y el objetivo no necesitan ser descritos en el mismo nivel de detalle. En
muchos casos, la línea de base se describe en un nivel de abstracción más alto, por
lo que hay más tiempo disponible para especificar el destino con suficiente
detalle. Los desafíos de este son discutidos en 5.5 Alcance de la Arquitectura . En
particular, definir:     La amplitud de la cobertura de la empresa  El nivel de
detalle requerido  Las características de la partición de la arquitectura (véase la
Parte V , 40. Arquitectura de particionamiento para más detalles)  Los dominios
específicos de arquitectura para ser cubiertos (negocio, datos, aplicaciones,
tecnología) 

  Página 74 de 670 

TOGOF 9.1    
  La extensión del período de tiempo destinado a, más el número y el alcance de
cualquier período de tiempo intermedio  Los activos de arquitectura para ser
apalancadas, o considerados para su uso, de la empresa Continuum de la
organización:  o o Activos creados en versiones anteriores del ciclo de ADM en la
empresa  Activos disponibles en la industria en otras partes (otros marcos, modelos
de sistemas, modelos industriales verticales, etc) 

7.4.7 Confirmar y Arquitectura elaborar principios, incluidos los Principios de

Actuación
Revise los principios bajo los cuales la arquitectura se va a desarrollar.
Arquitectura principios se basan normalmente en los principios desarrollados en el
marco de la Etapa Preliminar. Se explican, y un ejemplo determinado conjunto, en la
Parte III , 23. Principios de Arquitectura . Asegúrese de que las definiciones
existentes son actuales, y aclarar cualquier área de ambigüedad. De lo contrario,
vuelva a la entidad encargada de la gobernanza arquitectura y trabajar con ellos
para definir estos elementos esenciales, por primera vez y asegurar su aprobación
por parte de la gestión empresarial.

7.4.8 Desarrollar Architecture Vision

Sobre la base de las preocupaciones de los interesados, los requisitos de capacidad
empresarial, alcance, restricciones y principios, cree una vista de alto nivel de
la línea de base y Target Arquitecturas. El Architecture Vision general cubre la
amplitud de alcance definido para el proyecto, en un nivel alto. Técnicas
informales son a menudo empleados. Una práctica común es dibujar un diagrama de
concepto de la solución simple que ilustra en forma concisa los principales
componentes de la solución y cómo la solución se traducirá en beneficios para la
empresa. Escenarios de negocios son una técnica apropiada y útil para descubrir y
documentar los requerimientos del negocio, y para articular una visión de la
Arquitectura, que responda a esas necesidades. Escenarios de negocios también se
pueden usar en los niveles más detallados de la obra de arquitectura (por ejemplo,
en la Fase B) y se describen en la Parte III , 26. Escenarios empresariales y
objetivos de negocio . Este paso genera las primeras definiciones, muy de alto
nivel de los entornos de referencia y objetivos, desde una perspectiva empresarial,
los sistemas de información y tecnología, según se describe en 7.5 Salidas . Estas
versiones iniciales de la arquitectura se deben almacenar en el repositorio
Arquitectura, organizados de acuerdo a las normas y directrices establecidas en el
marco de la arquitectura.

7.4.9 Definir el objetivo Arquitectura propuestas de valor y los indicadores clave

de rendimiento  Desarrollar el caso de negocio para las arquitecturas y los
cambios necesarios 
   Producir la propuesta de valor para cada uno de los grupos de interesados 
Evaluar y definir los requisitos de contratación  Revisar y acordar las propuestas
de valor con los patrocinadores y las partes interesadas 

  Página 75 de 670 

TOGOF 9.1    
  Definir las métricas y las medidas que se construirán en la arquitectura de la
empresa para satisfacer las necesidades empresariales de rendimiento  Evaluar el
riesgo de negocios (véase la Parte III , 31. Gestión de Riesgos ) 

Los resultados de esta actividad se deben incorporar en el Estado de Arquitectura

de Trabajo para que el rendimiento sea seguido en consecuencia.

7.4.10 Identificar los riesgos de transformación empresarial y Mitigación

Actividades
Identificar los riesgos asociados con la Architecture Vision y evaluar el nivel de
riesgo inicial (por ejemplo, catastrófica, crítico, marginal o insignificante) y la
frecuencia potencial asociado a él. Asignar una estrategia de mitigación para cada
riesgo. Un marco de gestión de riesgos se describe en la Parte III , 31. Gestión de
Riesgos . Hay dos niveles de riesgo que deben ser considerados, a saber:   Nivel
Inicial del Riesgo : categorización del riesgo antes de determinar e implementar
acciones de mitigación.  Nivel Residual de Riesgo : categorización del riesgo
después de la implementación de medidas de mitigación (si los hay). 

Actividades de mitigación de riesgos deben ser considerados para su inclusión en el

Estado de Arquitectura Obra.

7.4.11 Desarrollar el Enunciado de Arquitectura de Trabajo; Aprobación Secure

. Evaluar los productos de trabajo que se requieren para producir (y cuándo) contra
el conjunto de requisitos de rendimiento de negocio Esto implicará asegurar que: 
 Las mediciones de rendimiento se construyen en los productos de trabajo. 
Productos de trabajo relacionados con el rendimiento específicos están
disponibles. 

Luego, las actividades serán las siguientes:   Identificar nuevos productos de

trabajo que tendrá que ser cambiado  Proporcionar dirección en la que tendrá que
ser cambiado productos de trabajo existentes, incluyendo bloques de construcción, y
garantizar que todas las actividades y dependencias de éstos se coordinan 
Identificar el impacto del cambio en otros productos de trabajo y la dependencia de
sus actividades  Con base en el propósito, enfoque, alcance y limitaciones,
determinan que se deben desarrollar los dominios de arquitectura, hasta qué nivel
de detalle, y que vistas de arquitectura deben construirse 

 

  Página 76 de 670 

TOGOF 9.1    
 Evaluar las necesidades de recursos y disponibilidad para llevar a cabo la obra
en el plazo requerido; esto incluirá la adhesión a los métodos de planificación de
la organización y los productos de trabajo para producir los planes para la
realización de un ciclo de la ADM  Estimar los recursos necesarios, desarrollar un
plan de trabajo y un calendario para el desarrollo propuesto, y documentar todos
estos en la Declaración de Arquitectura Trabajo  Definir las métricas de
rendimiento que deben cumplir durante este ciclo de la ADM por el equipo de
arquitectura de la empresa  Desarrollar el Plan y programa específico de
arquitectura empresarial Comunicaciones dónde, cómo, y cuando los arquitectos de la
empresa se comunicará con las partes interesadas, incluidos los grupos y las
comunidades de afinidad, sobre el avance de los desarrollos de arquitectura
empresarial  Revisar y acordar los planes con los patrocinadores, y garantizar la
aprobación formal de la Declaración de Arquitectura Obra bajo los procedimientos de
gobierno que resulten  Obtener el cierre de sesión de patrocinador para proceder 

  

 

7.5 Salidas
Las salidas de la Fase A pueden incluir, pero no se limitan a:  Declaración
aprobada de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de
Arquitectura de Trabajo ), incluyendo, en particular:  o o o  Arquitectura
Descripción y alcance del proyecto  Descripción general de Arquitectura Visión 
Plan de la configuración y programación del proyecto 

Declaraciones refinadas de los principios de negocio, objetivos de negocio, y los

conductores de negocios (véase la Parte IV , 36.2.9 Principios de Actuación,
objetivos de negocio, y los impulsores del negocio )  Principios Arquitectura (ver
la Parte IV , 23. Arquitectura Principios )  Evaluación de capacidades (véase la
Parte IV , 36.2.10 Evaluación de Capacidad )  Tailored Architecture Framework
(véase la Parte IV , 36.2.21 Tailored Architecture Framework ) (para la
contratación), incluyendo:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

  

Architecture Vision (véase la Parte IV , 36.2.8 Architecture Vision ), incluyendo: 

o Descripción del problema 

  Página 77 de 670 

TOGOF 9.1    
o o o o  Objetivo de la Declaración de Arquitectura de Trabajo  Vistas de resumen 
Escenario empresarial (opcional)  Requisitos clave refinados de interesados de alto
nivel 

Proyecto de Arquitectura de definición de documento, incluyendo (cuando alcance): 

o o o o o o o o Línea de base de Empresas Arquitectura, Versión 0.1  Línea de Base
Tecnológica de Arquitectura, Versión 0.1  Arquitectura de datos de línea de base,
versión 0.1  Línea de base de arquitectura de aplicaciones, versión 0.1  Objetivo
Negocio Arquitectura, Versión 0.1  Tecnología Target Arquitectura, Versión 0.1 
Arquitectura de datos de destino, Versión 0.1  Objetivo de Arquitectura de
aplicaciones, Versión 0.1 

  Nota: 

Plan de comunicación (ver la Parte IV , 36.2.12 Plan de Comunicaciones )  Contenido

adicional poblar el repositorio de Arquitectura (ver la Parte IV , 36.2.5
Arquitectura Repositorio ) 

Escenarios de negocios múltiples pueden ser usados para generar una única
arquitectura Visión.  Las salidas pueden incluir algunos o todos de los siguientes:
 Matrices:  o  Matriz de los grupos de interés Mapa 

Diagramas:  o o Diagrama de la cadena de valor  Diagrama conceptual de soluciones 

  Página 78 de 670 

TOGOF 9.1       

8 Fase B:. Arquitectura de Negocios

En este capítulo se describe el desarrollo de una arquitectura de negocios para
apoyar una Architecture Vision acordado.

  Figura 8‐1: Fase B: Arquitectura de Negocios 

8.1 Objetivos
Los objetivos de la Fase B son:  Desarrollar la arquitectura destino de negocios
que describe cómo la empresa necesita para operar para lograr los objetivos de
negocio y responder a los conductores estratégicos establecidos en el Architecture
Vision, de una manera que se dirige la solicitud de Arquitectura Trabajo y
preocupaciones de los interesados  Identificar los componentes de la Hoja de Ruta
Arquitectura candidatos sobre la base de las brechas entre la línea de base y
objetivo de negocio Arquitecturas 


  Página 79 de 670 

TOGOF 9.1    

8.2 Enfoque
En resumen, la arquitectura de negocio describe el producto y / o estrategia de
servicios, y los aspectos organizativos, funcionales, procesos, información y
aspectos geográficos del entorno empresarial.

8.2.1 Generales
El conocimiento de la arquitectura de negocio es un requisito previo para el
trabajo de la arquitectura en cualquier otro dominio (datos, aplicaciones,
tecnología), y por lo tanto es la primera actividad de la arquitectura que debe
llevarse a cabo, si no atendidos ya en otros procesos organizativos (planificación
empresarial, la planificación estratégica de negocios, proceso de reingeniería de
negocios, etc.) En términos prácticos, la arquitectura de negocio es a menudo
necesaria como medio de demostrar el valor de negocio de la obra de arquitectura
con posterioridad a las principales partes interesadas, y el retorno de la
inversión a los interesados de apoyar y participar en el trabajo posterior. El
alcance de los trabajos en la Fase B dependerá en gran medida del entorno
empresarial. En algunos casos, los elementos clave de la arquitectura de negocios
se pueden hacer en otras actividades; por ejemplo, la misión de la empresa, la
visión, la estrategia y los objetivos pueden documentarse como parte de alguna
estrategia de negocio más amplio o de la actividad de planificación empresarial que
tiene su propio ciclo de vida dentro de la empresa. En tales casos, puede haber una
necesidad de verificar y actualizar la estrategia y los planes de negocio
actualmente documentado, y / o para puentear entre los conductores de alto nivel de
negocio, estrategia de negocio, y objetivos, por un lado, y las necesidades
específicas de negocio que son relevante para este esfuerzo de desarrollo de la
arquitectura. La estrategia de negocio normalmente define lo que para alcanzar -
los objetivos y los conductores, y las métricas de éxito pero no cómo llegar hasta
allí. Ese es el rol de la Arquitectura Empresarial. En otros casos, poco o ningún
trabajo Arquitectura negocios puede haber sido hecho hasta la fecha. En estos
casos, habrá una necesidad de que el equipo de arquitectura para investigar,
verificar y obtener un buy-in de los objetivos clave del negocio y los procesos que
la arquitectura es apoyar. Esto se puede hacer como un ejercicio libre de pie, ya
sea anterior desarrollo de la arquitectura, o como parte de la Fase A. En ambos
casos, la técnica de escenario de negocios (véase la Parte III , 26. Escenarios
empresariales y objetivos de la empresa ) Del TOGAF ADM, o cualquier otro método
que ilumina los requisitos clave de negocio e indica los requisitos técnicos
implícitos para la arquitectura de TI, se puede utilizar. Un objetivo clave es
reutilizar el material existente tanto como sea posible. En ambientes
arquitectónicamente más maduros, habrá Definiciones Arquitectura existentes, que
(con suerte) se han mantenido desde el último ciclo de desarrollo de la
arquitectura. Cuando existen descripciones de arquitectura, éstos se pueden
utilizar como punto de partida, y se verifican y se actualizan si es necesario;
véase la Parte V , 39.4.1 Arquitectura Continuum .

  Página 80 de 670 

TOGOF 9.1    
Recopilar y analizar únicamente la información que permite tomar decisiones con
conocimiento de causa relevante para el alcance de este esfuerzo de la
arquitectura. Si este esfuerzo se centra en la definición de (posiblemente) nuevos
procesos de negocio, a continuación, la fase B necesariamente implicará una gran
cantidad de trabajo detallado. Si la atención se centra más en las arquitecturas
objetivo en otros dominios (datos / información, sistemas de aplicaciones,
infraestructura) para soportar una arquitectura de negocio esencialmente existente,
entonces es importante para construir una imagen completa en la Fase B, sin entrar
en detalles innecesarios.

8.2.2 El desarrollo de la línea de base Descripción

Si una empresa ha descripciones arquitectura existente, se deben utilizar como base
para la descripción de línea de base. Esta entrada puede haber sido utilizado ya en
la Fase A en el desarrollo de una arquitectura de visión, e incluso puede ser
suficiente en sí mismo para la descripción de línea de base. Cuando no existan
tales descripciones, la información deberá ser recogida en el formato que viene a
mano. La aproximación normal al desarrollo Arquitectura objetivo es de arriba hacia
abajo. En la descripción de línea de base, sin embargo, el análisis de la situación
actual a menudo se tiene que hacer de abajo hacia arriba, sobre todo cuando existen
activos de arquitectura poco o nada. En tal caso, el arquitecto simplemente tiene
que documentar los supuestos de trabajo sobre arquitecturas de alto nivel, y el
proceso es una de reunir pruebas para convertir las hipótesis de trabajo en
realidad, hasta que la ley de los rendimientos decrecientes establece pulg Los
procesos de negocio que no son trasladables tienen ningún valor intrínseco. Sin
embargo, cuando el desarrollo de descripciones de línea de base en otros ámbitos de
arquitectura, componentes arquitectónicos (principios, modelos, estándares y el
inventario actual) que no son trasladables todavía puede tener un valor intrínseco,
y puede ser necesario un inventario con el fin de entender el residual valor (si la
hay) de esos componentes. Sea cual sea el enfoque, el objetivo debe ser volver a
utilizar los materiales existentes tanto como sea posible, y para recopilar y
analizar únicamente la información que permite tomar decisiones con conocimiento de
causa en relación con la Arquitectura de Negocios Target. Es importante construir
una imagen completa, sin entrar en detalles innecesarios.

8.2.3 Modelado de Negocios

Los modelos de negocios deben ser extensiones lógicas de los escenarios de negocio
de la Architecture Vision, por lo que la arquitectura puede ser mapeado a partir de
los requerimientos de negocio de alto nivel hasta los más detallados. Una variedad
de herramientas y técnicas de modelado se puede emplear, si se considera apropiado
(teniendo en cuenta la precaución por encima de no entrar en detalles
innecesarios). Por ejemplo:  Modelos de actividad (también llamados Modelos de
Procesos de Negocio ) describen las funciones relacionadas con las actividades de
la empresa de negocios, los datos y / o información intercambiada entre las
actividades (intercambios internos), y los datos y / o información intercambiada
con otras actividades que están fuera del alcance de el modelo (intercambios
externos). Modelos de actividad son de naturaleza jerárquica. Capturan las

  Página 81 de 670 

TOGOF 9.1    
actividades llevadas a cabo en un proceso de negocio, y los del ICOM (insumos,
controles, productos y mecanismos / recursos utilizados) de esas actividades.
Modelos de actividad se pueden anotar con declaraciones explícitas de las reglas de
negocio que representan las relaciones entre los ICOM. Por ejemplo, una regla de
negocio puede especificar quién puede hacer qué en determinadas condiciones, la
combinación de entradas y controles necesarios, y los productos resultantes. Una de
las técnicas para la creación de modelos de actividad es la IDEF (Integrated
Computer Aided Manufacturing (ICAM) Definición) técnica de modelado.  El Object
Management Group (OMG) ha desarrollado el Business Process Modeling Notation
(BPMN), un estándar para el modelado de procesos de negocio que incluye un lenguaje
con el que especifique los procesos de negocio, sus tareas / pasos, y los
documentos aportados.  Modelos de casos de uso para describir cualquiera de los
procesos de negocio o funciones de los sistemas, según el enfoque del esfuerzo de
modelado. Un modelo de casos de uso se describen los procesos de negocio de una
empresa en términos de casos de uso y actores correspondientes a los procesos de
negocio y los participantes de la organización (personas, organizaciones, etc.) El
modelo de casos de uso se describe en los diagramas de casos de uso y
especificaciones de casos de uso.  Modelos de clase son similares a los modelos de
datos lógicos. Un modelo de clase describe la información estática y de relaciones
entre la información. Un modelo de clase también se describen los comportamientos
informativos. Como muchos de los otros modelos, también se puede utilizar para
modelar diversos niveles de granularidad. Dependiendo de la intención de la modelo,
un modelo de clases puede representar entidades de dominio empresarial o sistemas
de clases de implementación. Un modelo de dominio de negocio representa la
información clave del negocio (clases de dominio), sus características (atributos),
sus comportamientos (métodos u operaciones) y las relaciones (a menudo referida
como la multiplicidad, que describe el número de clases por lo general participan
en la relación), y cardinalidad ( describe la participación requerida u opcional en
la relación). Especificaciones información más elaborada y detalle que no se puede
representar en el diagrama de clases. 

  Figura 8‐2: Diagrama de clases UML Negocios 
Los tres tipos de modelo de arriba pueden ser representados en el Lenguaje
Unificado de Modelado (UML), y una variedad de herramientas existen para la
generación de este tipo de modelos.

  Página 82 de 670 

TOGOF 9.1    
Ciertos sectores de la industria tienen las técnicas de modelado específicos para
el sector de que se trate. Por ejemplo, el sector de Defensa utiliza los siguientes
modelos.Estos modelos deben ser utilizados con cuidado, especialmente si la
ubicación y realización de los procesos de negocio se verán alterados en el
visionario Arquitectura Empresarial.  El Diagrama de conectividad de nodo se
describen los lugares de negocios (nodos), los "needlines" entre ellos, y las
características de la información intercambiada. Conectividad de nodo se puede
describir en tres niveles: conceptuales, lógicos y físicos. Cada needline indica la
necesidad de algún tipo de transferencia de información entre los dos nodos
conectados. Un nodo puede representar un papel (por ejemplo, un CIO), una unidad
organizativa, un lugar de negocios o instalación, y así sucesivamente. Una flecha
que indica la dirección del flujo de información se anota para describir las
características de los datos o información - por ejemplo, su nivel de contenido,
los medios de comunicación, la seguridad o la clasificación, la puntualidad, y los
requisitos de interoperabilidad del sistema de información.   El Intercambio de
Información Matrix documenta los requisitos de intercambio de información para una
empresa de arquitectura. Requisitos de intercambio de información expresan las
relaciones a través de tres entidades básicas (actividades, nodos de negocios y sus
elementos, y el flujo de información), y se centran en las características del
intercambio de información, como el rendimiento y la seguridad. Identifican que
intercambia la información con quién, por qué es necesaria la información, y de qué
manera.  

Aunque originalmente desarrollado para su uso en el sector de la Defensa, estos

modelos están encontrando cada vez mayor uso en otros sectores del gobierno, y
también pueden ser considerados para su uso en entornos no-gubernamentales.

8.2.4 Arquitectura Repositorio

Como parte de la fase B, el equipo de arquitectura tendrá que considerar lo que
están disponibles en el repositorio de recursos Arquitectura Arquitectura
Profesiones pertinentes (véase la Parte V , 41. Arquitectura Repositorio ), en
particular:  Modelos de negocio genéricos relacionados con el sector de la
industria de la organización. Estos son "Arquitecturas Industria", en términos de
la Empresa Continuum. Se llevan a cabo en la Biblioteca de la arquitectura de
repositorio (véase la Parte V , 41,3 Reference Library ). Por ejemplo:  o El Grupo
de Gestión de objetos (OMG) - www.omg.org - tiene una serie de grupos de trabajo de
dominio de los modelos de negocio en desarrollo verticales relevante para dominios
verticales específicos como la salud, Transporte, Finanzas, etc  El TeleManagement
Forum (TMF) - www.tmforum.org - ha desarrollado modelos de negocio detallados
relevante para la industria de las Telecomunicaciones.  Departamentos y agencias
gubernamentales de los diferentes países tienen modelos y marcos de referencia
obligatorios para el uso, la intención de promover la integración entre
departamentos y la interoperabilidad. Un ejemplo es el modelo de negocio de
referencia Federal Enterprise Architecture, que es un marco de la función de guiado
para la descripción de las operaciones comerciales de la independiente del Gobierno
Federal de los organismos que los realizan. 

  Página 83 de 670 

TOGOF 9.1    
 Los modelos de negocio relacionados con los dominios de negocio de alto nivel
comunes. Por ejemplo:  o El modelo de negocio de recursos-Event-Agente (REA) fue
creado originalmente por William E. McCarthy (consulte www.msu.edu/user/mccarth4 )
de la Universidad Estatal de Michigan, principalmente para el modelado de sistemas
de contabilidad. Ha demostrado ser tan útil para una mejor comprensión de los
procesos de negocio que se ha convertido en uno de los principales marcos de
modelos, tanto para las empresas tradicionales y los sistemas de comercio
electrónico.  El Marco de STEP (estándar para el intercambio de datos del modelo
del producto) se ocupa de diseño de producto y el interfuncionamiento cadena de
suministro. STEP es un estándar ISO (ISO 10303). La aplicación de la norma STEP ha
sido liderado por algunos grandes fabricantes aeroespaciales, y también se ha
tenido en otras industrias que tienen una necesidad de complejos datos gráficos y
de proceso, tales como la industria de la construcción.  RosettaNet -
www.rosettanet.org - es un consorcio creado por las empresas líderes en el
ordenador, componentes electrónicos, semiconductores y las cadenas de suministro de
fabricación. Su misión es desarrollar un conjunto completo de los procesos de
negocio electrónico estándar para estas cadenas de suministro, y promover y apoyar
su adopción y uso. 

 

Bloques de construcción específicas de la empresa (componentes de procesos, reglas

de negocio, descripciones de puestos, etc.)  Normas aplicables. 
8.3 Entradas
Esta sección define las entradas a la Fase B.

8.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio )  8.3.2 Entradas
para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte
IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 
 Principios de Actuación, los objetivos de negocio, y los conductores de negocios
(véase la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los
impulsores del negocio )  Evaluación de capacidades (véase la Parte IV , 36.2.10
Evaluación de Capacidad )  Plan de comunicación (ver la Parte IV , 36.2.12 Plan de
Comunicaciones ) 

 

8.3.3 Entradas de arquitectura  Modelo de organización de Arquitectura

Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o Ámbito de las organizaciones afectadas 

  Página 84 de 670 

TOGOF 9.1    
o o o o o  La evaluación gestacional, lagunas, y el enfoque de resolución  Roles y
responsabilidades de equipo de arquitectura (s)  Las restricciones sobre el trabajo
de arquitectura  Necesidades presupuestarias  Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

   

Declaración aprobada de Arquitectura de trabajo (véase la Parte IV , 36.2.20

Declaración de Arquitectura de Trabajo )  Principios Arquitectura (ver la Parte
IV , 36.2.4 Principios Arquitectura ), incluidos los principios de negocios, al
pre-existente  Continuum Empresarial (véase la Parte V , 39. Empresa Continuum ) 
Arquitectura repositorio (véase la Parte IV , 36.2.5 Arquitectura del
repositorio ), incluyendo:  o o o o Bloques de construcción reutilizables  Modelos
de referencia disponibles al público  Modelos de referencia específicos de la
organización  Normas de la Organización 

Architecture Vision (véase la Parte IV , 36.2.8 Architecture Vision ), incluyendo: 

o o o o o Descripción del problema  Objetivo de la Declaración de Arquitectura de
Trabajo  Vistas de resumen  Escenario empresarial (opcional)  Requisitos clave
refinados de interesados de alto nivel 

Proyecto de Arquitectura de definición de documento, incluyendo (cuando alcance): 

o o Línea de base de Empresas Arquitectura, Versión 0.1  Línea de Base Tecnológica
de Arquitectura, Versión 0.1 

  Página 85 de 670 
TOGOF 9.1    
o o o o o o Arquitectura de datos de línea de base, versión 0.1  Línea de base de
arquitectura de aplicaciones, versión 0.1  Objetivo Negocio Arquitectura, Versión
0.1  Tecnología Target Arquitectura, Versión 0.1  Arquitectura de datos de destino,
Versión 0.1  Objetivo de Arquitectura de aplicaciones, Versión 0.1 

8.4 Pasos
El nivel de detalle abordado en la Fase B dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura. Los nuevos procesos de negocio que se están
introduciendo en el marco de este esfuerzo tendrá que ser definido en detalle
durante la Fase B. procesos de negocio existentes y que se incorporen y apoyados en
el entorno de destino pueden ya han definido adecuadamente en el trabajo
arquitectónico anterior; pero, si no, ellos también tendrán que ser definidos en la
Fase B. El orden de los pasos en la Fase B (véase más adelante), así como el
momento en que se inician formalmente y completaron deben adaptarse a la situación
en cuestión, de acuerdo con el gobierno arquitectura establecida. En particular,
determinar si en esta situación, es oportuno proceder a línea de base o
Arquitectura objetivo el desarrollo en primer lugar, como se describe en la Parte
III , 19. Aplicando la iteración de la ADM . Todas las actividades que se han
iniciado en estos pasos deben estar cerradas durante el paso Finalizar la
Arquitectura de Negocios (ver 8.4.8 Finalizar la Arquitectura de Negocios ). La
documentación generada a partir de estas medidas debe ser publicada oficialmente en
la Arquitectura paso Crear definición de documento (ver 8.4.9 Crear Arquitectura
Definición de documento ). Los pasos en la fase B son los siguientes:       
 8.4.1 Selección de modelos de referencia, puntos de vista y Herramientas  8.4.2
Desarrollar basal Arquitectura Descripción  8.4.3 Desarrollar Target Arquitectura
Descripción  8.4.4 Realizar análisis de brechas  8.4.5 Definir candidatos
Componentes Hoja de Ruta  8.4.6 Impactos Resolver Across the Landscape
Architecture  8.4.7 Revisión de Conducta de las partes interesadas Formal  8.4.8
Finalizar la Arquitectura de Negocios 

  Página 86 de 670 

TOGOF 9.1    
 8.4.9 Crear Arquitectura Definición de documento 

8.4.1 Selección de modelos de referencia, puntos de vista y Herramientas

Seleccionar los recursos pertinentes Arquitectura Profesiones (modelos de
referencia, patrones, etc) desde el repositorio de Arquitectura, sobre la base de
los impulsores del negocio, y los grupos de interés y preocupaciones. Seleccione
los puntos de vista pertinentes Arquitectura empresarial (por ejemplo, operaciones,
gestión, financiera); es decir, los que le permitirán al arquitecto para demostrar
cómo se están abordando las preocupaciones de los interesados en la arquitectura de
negocio. Identificar las herramientas y las técnicas que se utilizarán para la
captura, modelado y análisis, en asociación con los puntos de vista seleccionados
apropiados.Dependiendo del grado de sofisticación se justifica, éstos pueden
comprender documentos u hojas de cálculo simples o herramientas de modelado más
sofisticadas y técnicas, como los modelos de actividad, los modelos de procesos de
negocio, modelos de casos de uso, etc
8.4.1.1 Determinar Proceso general Modeling

Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de
vista específico necesario, utilizando la herramienta o método seleccionado.
Asegúrese de que todas las preocupaciones de los interesados están cubiertos. Si no
es así, crear nuevos modelos para abordar las preocupaciones no están cubiertos, o
aumentar los modelos existentes (véase 8.2.3 Modelado de Negocios ). Escenarios de
negocios son una técnica muy útil para descubrir y documentar los requerimientos
del negocio, y se pueden utilizar de forma iterativa, a diferentes niveles de
detalle en la descomposición jerárquica de la Arquitectura Empresarial. Escenarios
de negocio se describen en la Parte III , 26. Escenarios empresariales y objetivos
de negocio . Se mencionan los modelos de actividad, los modelos de casos de uso, y
los modelos de la clase anterior como técnicas que permitan la definición de la
arquitectura de negocio de una organización. En muchos casos, los tres enfoques
pueden ser utilizados en secuencia para descomponer progresivamente un negocio. 
Análisis Estructurado : Identifica las funciones clave de negocio en el ámbito de
la arquitectura, y los mapas de aquellas funciones en las unidades de la
organización dentro de la empresa.  Use caso Análisis : El detalle de las funciones
de nivel empresarial a través de actores y organizaciones permite que los actores
de una función para ser identificados y permite una interrupción en los servicios
de apoyo / entrega de esa capacidad funcional.  Modelado de Procesos : El detalle
de una función o servicio de negocio a través de la modelización de procesos
permite que los elementos del proceso de ser identificados, y permite la
identificación de los servicios a las empresas de menor nivel o funciones. 

El nivel y el rigor de la descomposición necesaria varía de una empresa a otra, así

como dentro de una empresa, y el arquitecto deben tener en cuenta los objetivos de
la empresa, los objetivos, el

  Página 87 de 670 

TOGOF 9.1    
alcance y propósito del esfuerzo arquitectura de la empresa para determinar el
nivel de descomposición.
8.4.1.2 Identificar Requerido granularidad de nivel de servicio, Límites, y
Contratos

El marco de contenido TOGAF diferencia entre las funciones de una empresa y los
servicios de una empresa. Servicios a empresas son las funciones específicas que
tienen límites explícitos, definidos que se rigen de manera explícita. Con el fin
de permitir la flexibilidad arquitecto para definir los servicios de negocio a un
nivel de granularidad que sea apropiado para y manejable por el negocio, las
funciones se dividen de la siguiente manera: las funciones de nivel micro, tendrán
límites definidos explícitas, pero no pueden ser gobernados de forma explícita .
Del mismo modo, las funciones de negocio de macro pueden ser gobernados de manera
explícita, pero no pueden tener, límites definidos explícitos. Por tanto, la fase
de arquitectura de negocio necesita identificar qué componentes de la arquitectura
son funciones y cuáles son los servicios. Los servicios se distinguen de las
funciones a través de la definición explícita de un contrato de servicios. Cuando
se están desarrollando arquitecturas de referencia, puede darse el caso de que no
existan contratos explícitos y por lo tanto sería a discreción del arquitecto para
determinar si hay mérito en el desarrollo de este tipo de contratos antes de
examinar cualquier Arquitecturas objetivo. Un contrato de servicio cubre la
interfaz de negocio / funcional y también la interfaz de tecnología / datos.
Arquitectura Negocio definirá el contrato de servicios en el / nivel funcional de
negocios, que se ampliará en la aplicación y Arquitectura Tecnología fases. La
granularidad de los servicios de negocio se debe determinar de acuerdo con los
impulsores del negocio, las metas, los objetivos y las medidas para esta área de
negocio.Servicios de grano-Finer permiten la administración más cercana y la
medición (y se pueden combinar para crear servicios más gruesos de grano), pero es
necesario un mayor esfuerzo para gobernar. Directrices para la identificación de
los servicios y la definición de sus contratos se encuentran en la parte III , 22.
Usando TOGAF para definir y Gobierno SOAs .
8.4.1.3 Identificar Catálogos requeridos de Negocio Building Blocks

Catálogos capturan los inventarios de los principales activos de la empresa. Los

catálogos son de naturaleza jerárquica y capturan la descomposición de un bloque de
construcción, y también a través de descomposiciones bloques de construcción
relacionados (por ejemplo, la organización / actor). Catálogos constituyen la
materia prima para el desarrollo de matrices y puntos de vista y también actúan
como un recurso clave para la gestión de la cartera de negocios y capacidad de TI.
Los siguientes catálogos deben ser considerados para el desarrollo dentro de una
arquitectura de negocios:    Catálogo de Organización / Actor  Conductor /
Meta / Objetivo catálogo  Catálogo de funciones 

  Página 88 de 670 

TOGOF 9.1    
    Catálogo de servicios de negocios / Función  Ubicación catálogo  Proceso /
Evento / Control / Catálogo de productos  Catálogo Contract / Medida 

La estructura de catálogos se basa en los atributos de las entidades metamodelo,

según se define en la Parte IV , 34. Metamodel contenido .
8.4.1.4 Identificar Matrices requeridos

Matrices muestran las relaciones básicas entre las entidades del modelo
relacionado. Las matrices son la materia prima para el desarrollo de puntos de
vista y también actúan como un recurso clave para la evaluación del impacto,
realizado como parte del análisis de brecha. Las siguientes matrices deben ser
considerados para el desarrollo dentro de una arquitectura de negocios:   Matriz
de interacción de negocios (mostrando la dependencia y la comunicación entre las
organizaciones y actores)  Matriz Actor / papel (mostrando los roles asumidos por
cada actor) 

La estructura de las matrices se basa en los atributos de las entidades metamodelo,

según se define en la Parte IV , 34. Metamodel contenido .
8.4.1.5 Identificar los diagramas requeridos

Diagramas presentan la información Arquitectura de Negocios de un conjunto de

diferentes perspectivas (puntos de vista) de acuerdo a los requisitos de las partes
interesadas. Los siguientes diagramas deben ser considerados para el desarrollo
dentro de una arquitectura de negocios:         Diagrama de Huella de
negocios  Diagrama de Business Service / Information  Diagrama de descomposición
funcional  Meta / Objetivo diagrama / Servicio  Diagrama de casos de uso 
Organización diagrama de descomposición  Diagrama de Flujo del Proceso  Eventos
diagrama 

  Página 89 de 670 

TOGOF 9.1    
La estructura de los diagramas se basa en los atributos de las entidades
metamodelo, según se define en la Parte IV , 34. Metamodel contenido .
8.4.1.6 Identificar los tipos de Requisito para ser Collected

Una vez que los catálogos de Arquitectura de Negocios, matrices y diagramas han
sido desarrollados, modelado de arquitectura se completa mediante la formalización
de los requerimientos de negocio centrada en la implementación de la arquitectura
destino. Estos requisitos pueden:    Se relacionan con el ámbito empresarial 
Proporcionar los requisitos de entrada en las arquitecturas de datos, aplicaciones
y Tecnología  Proporcionar orientaciones detalladas que se refleja en el diseño e
implementación para asegurar que la solución satisface los requisitos de
arquitectura originales 

En este paso, el arquitecto debe identificar los requisitos que deben ser cumplidos
por la arquitectura (ver Desarrollo 17.2.2 Requisitos ). En muchos casos, la
definición de la arquitectura no se pretende dar prescripciones detalladas o
generales para una solución (ya que pueden ser abordados a través de una mejor
disciplina general de gestión de requisitos). El alcance previsto de contenido
requisitos debe establecerse durante la fase de Visión Arquitectura y documentado
en la Declaración de Arquitectura de Trabajo aprobado. Cualquier requisito o cambio
en la exigencia de que está fuera del ámbito definido en el pliego de Arquitectura
de Trabajo deben ser presentadas a los requisitos de repositorio para la gestión a
través del proceso de gestión de requisitos gobernados.

8.4.2 Desarrollar basal Arquitectura Descripción

Desarrollar una descripción de línea de base de la arquitectura de negocio
existentes, en la medida necesaria para apoyar la Arquitectura de Negocios Target.
El alcance y el nivel de detalle que se ha definido dependerá de la medida en que
los elementos de negocio existentes tienden a ser arrastrada en la arquitectura de
negocios de destino y de si existen descripciones de la arquitectura, como se
describe en 8.2 Enfoque . En la medida de lo posible, identificar los bloques de
construcción de arquitectura de negocios pertinentes, aprovechando la arquitectura
de repositorio (véase la Parte V , 41. Arquitectura del repositorio ). Cuando los
nuevos modelos de arquitectura deben ser desarrollados para satisfacer las
preocupaciones de las partes interesadas, utilice los modelos identificados en el
paso 1 como una guía para la creación de nuevos contenidos arquitectura para
describir la arquitectura de línea de base.

8.4.3 Desarrollar Target Arquitectura Descripción

Desarrollar una descripción Meta para la Arquitectura de Negocios, en la medida
necesaria para apoyar la Architecture Vision. El alcance y el nivel de detalle que
se ha definido dependerá de la

  Página 90 de 670 

TOGOF 9.1    
pertinencia de los elementos de negocio a alcanzar el Objetivo Architecture Vision,
y de si existen descripciones arquitectónicas. En la medida de lo posible,
identificar los bloques de construcción de arquitectura de negocios pertinentes,
aprovechando la arquitectura de repositorio (véase la Parte V , 41. Arquitectura
del repositorio ). Cuando los nuevos modelos de arquitectura deben ser
desarrollados para satisfacer las preocupaciones de las partes interesadas, utilice
los modelos identificados en el paso 1 como una guía para la creación de nuevos
contenidos arquitectura para describir la arquitectura destino.

8.4.4 Realizar análisis de brechas

Verifique los modelos de arquitectura para la coherencia y la precisión interna: 
   Realizar análisis de trade-off para resolver conflictos (si los hay) entre
los diferentes puntos de vista  Validar que los modelos son compatibles con los
principios, objetivos y limitaciones  Nota cambios en el punto de vista
representado en los modelos seleccionados desde el repositorio de Arquitectura, y
el documento  Modelos de arquitectura de prueba para la integridad frente a los
requisitos 

Identificar las brechas entre la línea base y de destino, utilizando la técnica de

análisis de carencias como se describe en la Parte III , 27. Análisis Gap .
8.4.5 Definir candidatos Componentes Hoja de Ruta
Después de la creación de una arquitectura de referencia, Arquitectura objetivo y
los resultados de análisis de carencias, se requiere un plan de negocios para dar
prioridad a las actividades en las próximas fases. Esta hoja de ruta inicial
Business Architecture se utilizará como materia prima para apoyar definición más
detallada de un plan de trabajo interdisciplinario consolidado dentro de las
Oportunidades y fase Solutions.

8.4.6 Impactos Resolver Across la Arquitectura del Paisaje

Una vez que la arquitectura de negocio se ha finalizado, hay que entender cualquier
impacto o implicaciones más amplias. En esta etapa, otros artefactos de
arquitectura en la arquitectura del paisaje deben ser examinados para identificar:
   ¿Crea esta arquitectura de negocio un impacto en las arquitecturas
preexistentes?  ¿Se han hecho los cambios recientes que impactan en la Arquitectura
de Negocios?  ¿Hay oportunidades para aprovechar el trabajo de esta arquitectura de
negocio en otras áreas de la organización? 

  Página 91 de 670 

TOGOF 9.1    
  ¿Impacta esta arquitectura de negocio otros proyectos (incluidos los previstos,
así como los actualmente en curso)?  ¿Será este negocio Arquitectura verse afectado
por otros proyectos (incluidos los previstos, así como los actualmente en curso)? 

8.4.7 Revisión de Conducta de las partes interesadas Formal

Compruebe la motivación original para el proyecto de la arquitectura y la
Declaración de Arquitectura de Trabajo contra la propuesta de arquitectura de
negocio, preguntando si es apto para el propósito de apoyar el trabajo posterior en
los otros dominios de la arquitectura. Refinar la propuesta de arquitectura de
negocio sólo si es necesario.

8.4.8 Finalizar la Arquitectura de Negocios  Seleccione estándares para cada

uno de los bloques de construcción, reutilizando la mayor cantidad posible de los
modelos de referencia seleccionados del repositorio Arquitectura 
  Documentar completamente cada bloque de construcción  Realizar última
comprobación cruzada de la arquitectura global contra objetivos de negocio;
documento de justificación de la construcción de las decisiones del bloque en el
documento de la arquitectura  Documento Final informe requisitos de trazabilidad 
Documento de asignación definitiva de la arquitectura dentro del Repositorio de
Arquitectura; de los bloques de construcción seleccionados, identificar las que
podrían ser re-utilizado (las prácticas de trabajo, roles y relaciones de negocio,
descripciones de puestos, etc), y publican a través del Repositorio de
Arquitectura  Finalice todos los productos de trabajo, tales como los resultados de
análisis de carencias 

 

8.4.9 Crear Arquitectura Definición de documento  Justificación del

documento para la construcción de bloquear decisiones en la definición de documento
Arquitectura 
 Preparar las secciones de negocios de la definición de documento de Arquitectura,
que comprende una parte o todos los siguientes:  o La huella de la empresa (una
descripción de alto nivel de la gente y los lugares que participan en las funciones
clave del negocio)  Una descripción detallada de las funciones de negocio y sus
necesidades de información  La huella de la gestión (mostrando ámbito de control y
rendición de cuentas)  Normas, reglas y directrices que muestran prácticas de
trabajo, legislación, medidas financieras, etc  Una matriz de habilidades y un
conjunto de descripciones de puestos 

o o

  Página 92 de 670 

TOGOF 9.1    
En su caso, utilizar los informes y / o gráficos generados por las herramientas
para demostrar puntos de vista clave de la arquitectura de modelado. Pase el
documento para su revisión por las partes interesadas pertinentes, e incorporar la
retroalimentación.

8.5 Salidas
Los resultados de la Fase B pueden incluir, pero no se limitan a:  Las versiones
refinadas y actualizadas de los entregables de la fase Arquitectura Visión, en su
caso, entre ellos:  o Declaración de Arquitectura de trabajo (véase la Parte IV ,
36.2.20 Declaración de Arquitectura de Trabajo ), actualizado en caso necesario 
Validado principios de negocio, objetivos de negocio, y los conductores de negocios
(véase la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los
impulsores del negocio ), actualizadas si es necesario  Principios Arquitectura
(ver la Parte IV , 36.2.4 Principios de Arquitectura ) 

o 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o Línea de base de
Empresas Arquitectura, Version 1.0 (detallado), si procede  Objetivo Negocio
Arquitectura, Version 1.0 (detallado), incluyendo:          Estructura de
la organización - la identificación de lugares de negocios y relacionándolos con
las unidades organizativas  Los objetivos de negocio y objetivos - para la empresa
y cada unidad organizativa  Funciones de negocio - un detallado paso, recursivo
implica sucesiva descomposición de las principales áreas funcionales en
subfunciones  Servicios de negocio - los servicios que la empresa y cada unidad de
la empresa proporciona a sus clientes, tanto internos como externos  Los procesos
de negocio, incluidas las medidas y resultados  Las funciones de negocio,
incluyendo el desarrollo y la modificación de las necesidades de competencias 
Modelo de datos de negocios  La correlación de la organización y funciones - se
relacionan las funciones de negocio a las unidades organizativas en la forma de un
informe de matriz 

Vistas correspondiente a los puntos de vista seleccionados abordar las principales

preocupaciones de las partes interesadas 

  Página 93 de 670 

TOGOF 9.1    
 Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6
Arquitectura especificación de requisitos ), incluyendo dichos requisitos y efectos
Arquitectura Profesiones como:  o o Los resultados del análisis de Gap  Requisitos
técnicos - Identificar, categorizar y priorizar las implicaciones para el trabajo
en los ámbitos de arquitectura restantes; por ejemplo, por una matriz de
dependencia / prioridad (por ejemplo, guiando el comercio entre la velocidad de
procesamiento de transacciones y de seguridad); una lista de los modelos
específicos que se esperan a producirse (por ejemplo, expresado como primitivas del
Marco Zachman)  Requisitos de negocio actualizados 

o 

Componentes de la arquitectura de negocios de una Arquitectura Roadmap (ver la

Parte IV , 36.2.7 Arquitectura Roadmap ) 

Las salidas pueden incluir algunos o todos de los siguientes:  Catálogos:  o o o o

o o o  Catálogo de Organización / Actor  Conductor / Meta / Objetivo catálogo 
Catálogo de funciones  Catálogo de servicios de negocios / Función  Ubicación
catálogo  Proceso / Evento / Control / Catálogo de productos  Catálogo Contract /
Medida 

Matrices:  o o Matriz de interacción de negocios  Matriz Actor / Rol 

Diagramas:  o o o o o o Diagrama de Huella de negocios  Diagrama de Business

Service / Information  Diagrama de descomposición funcional  Diagrama del ciclo de
vida del producto  Meta / Objetivo diagrama / Servicio  Diagrama de casos de uso 

  Página 94 de 670 

TOGOF 9.1    
o o o Organización diagrama de descomposición  Diagrama de Flujo del Proceso 
Diagrama de eventos 

  Página 95 de 670 

TOGOF 9.1       

9 Fase C:. Arquitecturas de Sistemas de Información

En este capítulo se describen las arquitecturas de los sistemas de información para
un proyecto de arquitectura, incluyendo el desarrollo de datos y aplicación de
arquitecturas.

  Figura 9‐1: Fase C: Arquitecturas de Sistemas de Información 

9.1 Objetivos
Los objetivos de la Fase C son:  Desarrollar los sistemas de información del
objetivo (datos y aplicaciones) Arquitectura, describiendo cómo los Sistemas de
Información Arquitectura de la empresa permitirá a la Arquitectura de Negocios y el
Architecture Vision, de una manera que se dirige la solicitud de Arquitectura
Trabajo y preocupaciones de los interesados  Identificar los componentes de la Hoja
de Ruta Arquitectura candidatos sobre la base de las brechas entre las
arquitecturas de referencia y sistemas de información del objetivo (Application
Data y) 

9.2 Enfoque
  Página 96 de 670 

TOGOF 9.1    
Fase C implica una combinación de datos y arquitectura de aplicaciones, en
cualquier orden. Existen defensores de ambas secuencias. Por ejemplo, Enterprise
Architecture Planning de Steven Spewak (EAP) recomienda un enfoque impulsado por
los datos. Por otro lado, los sistemas principales aplicaciones - como los de
planificación de recursos empresariales (ERP), Gestión de relaciones con clientes
(CRM), etc - a menudo, ofrecen una combinación de la infraestructura de la
tecnología y la lógica de la aplicación empresarial, y algunas organizaciones toman
una aplicación impulsada enfoque, por el que se reconocen determinadas aplicaciones
clave como formando el fundamento básico de los procesos de negocio de misión
crítica, y toman la implementación e integración de las aplicaciones básicas como
el foco principal de los esfuerzos de arquitectura (los problemas de integración a
menudo constituyen un reto importante).

9.3 Entradas
Esta sección define las entradas para la fase C.

9.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio )  9.3.2 Entradas
para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte
IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 
  Evaluación de capacidades (véase la Parte IV , 36.2.10 Evaluación de
Capacidad )  Plan de comunicación (ver la Parte IV , 36.2.12 Plan de Comunicaciones
) 

9.3.3 Entradas de arquitectura  Modelo de organización de Arquitectura

Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o o o o o  Ámbito de las organizaciones afectadas  La evaluación gestacional,
lagunas, y el enfoque de resolución  Roles y responsabilidades de equipo de
arquitectura (s)  Las restricciones sobre el trabajo de arquitectura  Necesidades
presupuestarias  Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

  Página 97 de 670 

TOGOF 9.1    
     Principios de la aplicación (ver la Parte III , 23.6.3 Principios de
Aplicación ), si existe  Principios de datos (véase la Parte III , 23.6.2 Datos
Principios ), si existe  Declaración de Arquitectura de trabajo (véase la Parte
IV , 36.2.20 Declaración de Arquitectura de Trabajo )  Architecture Vision (véase
la Parte IV , 36.2.8 Architecture Vision )  Arquitectura repositorio (véase la
Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo:  o o o  Bloques de
construcción reutilizables  Modelos de referencia específicos de la organización 
Normas de la Organización 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o o o o o Línea de base
de Empresas Arquitectura, Version 1.0 (detallado), si procede  Objetivo Negocio
Arquitectura, Version 1.0 (detallado)  Arquitectura de datos de línea de base,
versión 0.1  Arquitectura de datos de destino, Versión 0.1  Línea de base de
arquitectura de aplicaciones, versión 0.1  Objetivo de Arquitectura de
aplicaciones, Versión 0.1 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo:  o o Los resultados del
análisis de Gap (de Arquitectura Empresarial)  Requisitos técnicos pertinentes que
se aplicarán a la fase C 

Componentes de la arquitectura de negocios de una Arquitectura Roadmap (ver la

Parte IV , 36.2.7 Arquitectura Roadmap ) 

9.4 Pasos
Pasos detallados para la Fase C se dan por separado para cada dominio de la
arquitectura:   . 10 Fase C: Arquitecturas de Sistemas de Información -
Arquitectura de Datos  . 11 Fase C: Arquitecturas de Sistemas de Información -
Arquitectura de la aplicación 

9.5 Salidas
  Página 98 de 670 

TOGOF 9.1    
Los principales resultados de la Fase C son:  Las versiones refinadas y
actualizadas de los entregables de la fase Arquitectura Visión, en su caso, entre
ellos:  o  Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20
Declaración de Arquitectura de Trabajo ), actualizado en caso necesario 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o o o o Arquitectura de
datos de línea de base, versión 1.0  Arquitectura de datos de destino, Versión 1.0 
Línea de base de arquitectura de aplicaciones, versión 1.0  Objetivo de
Arquitectura de aplicaciones, versión 1.0  Puntos de vista de arquitectura de datos
correspondientes a los puntos de vista seleccionados abordar las principales
preocupaciones de las partes interesadas  Vistas Arquitectura Aplicación
correspondientes a los puntos de vista seleccionados abordar las preocupaciones de
interés clave 

o 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo dichos requisitos de
Sistemas de Información Arquitectura como:  o o Los resultados del análisis de Gap 
Requisitos técnicos pertinentes que se aplicarán a esta evolución del ciclo de
desarrollo de la arquitectura  Las restricciones en la Arquitectura de Tecnología a
punto de ser diseñados  Requisitos de negocio actualizados, en su caso 

o o 

Componentes de los sistemas de información de una Arquitectura Roadmap (ver la

Parte IV , 36.2.7 Arquitectura Roadmap ) 

  

  Página 99 de 670 
TOGOF 9.1       

. 10 Fase C: Arquitecturas de Sistemas de Información - Arquitectura de Datos

En este capítulo se describe la parte Arquitectura de datos de la Fase C.

10.1 Objetivos
Los objetivos de la parte Arquitectura de datos de la Fase C son:  Desarrollar la
arquitectura de datos de destino que permite a la Arquitectura de Negocios y el
Architecture Vision, al dirigirse a la Solicitud de Arquitectura Trabajo y
preocupaciones de los interesados  Identificar los componentes de la Hoja de Ruta
Arquitectura candidatos sobre la base de las brechas entre la línea de base y datos
de destino Arquitecturas 

10.2 Enfoque
10.2.1 Consideraciones clave para la Arquitectura de Datos
10.2.1.1 Gestión de Datos

Cuando una empresa ha optado por realizar la transformación arquitectónica gran

escala, es importante para comprender y abordar los problemas de gestión de datos.
Un enfoque estructurado y global de la gestión de datos permite el uso eficaz de
los datos para sacar provecho de sus ventajas competitivas. Las consideraciones
incluyen:   Una definición clara de lo que los componentes de aplicación en el
paisaje servirán como el sistema de registro o de referencia para los datos
maestros de la empresa  ¿Habrá un estándar en toda la empresa que todos los
componentes de la aplicación, incluyendo los paquetes de software, tienen que
adoptar (en los paquetes principales pueden ser preceptivo sobre los modelos de
datos y no puede ser flexible)?  Entender claramente cómo las entidades de datos
son utilizados por las funciones de negocio, procesos y servicios  Entender
claramente cómo y cuando las entidades de datos de empresas se crean, almacenan,
transportan, e informó  ¿Cuál es el nivel y la complejidad de las transformaciones
de datos requeridas para apoyar las necesidades de intercambio de información entre
las aplicaciones?  ¿Cuál será el requisito para el software en el apoyo a la
integración de datos con los clientes de la empresa y los proveedores (por ejemplo,
el uso de herramientas de ETL

   

  Página 100 de 670 

TOGOF 9.1    
durante la migración de datos, los datos de perfiles de herramientas para evaluar
la calidad de datos, etc)? 
10.2.1.2 migración de datos

Cuando se sustituye una aplicación existente, habrá una necesidad crítica para
migrar datos (master, transaccionales y de referencia) para la nueva aplicación. La
Arquitectura de Datos debe determinar las necesidades de migración de datos y
también proporcionar indicadores sobre el nivel de la transformación, la escarda, y
la limpieza que se requiere para presentar los datos en un formato que cumpla con
las exigencias y limitaciones de la aplicación de destino. El objetivo es que la
aplicación de destino tiene datos de calidad cuando está poblado. Otra
consideración clave es asegurarse de que una definición común de datos en toda la
empresa se estableció para apoyar la transformación.
10.2.1.3 Data Governance
Consideraciones de gobernabilidad de datos asegurarse de que la empresa tiene las
dimensiones necesarias en el lugar para permitir la transformación, de la siguiente
manera:  Estructura : Esta dimensión se refiere a si la empresa tiene la
estructura organizativa necesaria y los organismos de normalización para gestionar
aspectos de entidad de datos de la transformación.  Sistema de Gestión : Aquí las
empresas deben tener el sistema de gestión necesarias y los programas relacionados
con los datos para gestionar los aspectos de la gobernanza de las entidades de
datos a lo largo de su ciclo de vida.  Gente : Esta dimensión aborda cuáles son las
habilidades y roles de la empresa relacionadas con los datos requiere para la
transformación. Si la empresa carece de este tipo de recursos y competencias, la
empresa debe considerar o bien la adquisición de esas habilidades críticas o
capacitación de los recursos internos existentes para satisfacer las necesidades a
través de un programa de aprendizaje bien definidos. 

10.2.2 Arquitectura Repositorio

Como parte de esta fase, el equipo de arquitectura tendrá que considerar qué
recursos están disponibles arquitectura de datos pertinentes en la arquitectura de
repositorio de la organización (véase la Parte V , 41. Arquitectura Repositorio ),
en particular, los modelos de datos genéricos relacionados con la industria de la
organización "vertical" sector. Por ejemplo:   ARTES ha definido un modelo de
datos para la industria al por menor.  Energistics ha definido un modelo de datos
para la industria petrotécnicos. 

10.3 Entradas
Esta sección define las entradas a la Fase C (Arquitectura de Datos).

10.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 

  Página 101 de 670 

TOGOF 9.1    
10.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo
(véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 
  Evaluación de capacidades (véase la Parte IV , 36.2.10 Evaluación de
Capacidad )  Plan de comunicación (ver la Parte IV , 36.2.12 Plan de Comunicaciones
) 

10.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura

Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o o o o o  Ámbito de las organizaciones afectadas  La evaluación gestacional,
lagunas, y el enfoque de resolución  Roles y responsabilidades de equipo de
arquitectura (s)  Las restricciones sobre el trabajo de arquitectura  Necesidades
presupuestarias  Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

   

Principios de datos (véase la Parte III , 23.6.2 Datos Principios ), si existe 

Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de
Arquitectura de Trabajo )  Architecture Vision (véase la Parte IV , 36.2.8
Architecture Vision )  Arquitectura repositorio (véase la Parte IV , 36.2.5
Arquitectura del repositorio ), incluyendo:  o Bloques de construcción
reutilizables (en particular, las definiciones de los datos actuales)  Modelos de
referencia disponibles al público  Modelos de referencia específicos de la
organización  Normas de la Organización 

o o o 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo: 

  Página 102 de 670 

TOGOF 9.1    
o o o o o Línea de base de Empresas Arquitectura, Version 1.0 (detallado), si
procede  Objetivo Negocio Arquitectura, Version 1.0 (detallado)  Arquitectura de
datos de línea de base, Versión 0.1, si está disponible  Arquitectura de datos de
destino, Versión 0.1, si está disponible  Línea de base de arquitectura de
aplicaciones, versión 1.0 (detallada) o Versión 0.1 (Vision)  Objetivo de
Arquitectura de aplicaciones, versión 1.0 (detallada) o Versión 0.1 (Vision)  Línea
de Base Tecnológica de Arquitectura, Version 0.1 (Vision)  Tecnología Target
Arquitectura, Version 0.1 (Vision) 

o o 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo:  o o Los resultados del
análisis de Gap (de Arquitectura Empresarial)  Requisitos técnicos pertinentes que
se aplicarán a esta fase 

Componentes de la arquitectura de negocios de una Arquitectura Roadmap (ver la

Parte IV , 36.2.7 Arquitectura Roadmap ) 

10.4 Pasos
El nivel de detalle abordado en la Fase C dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura. Nuevos bloques de construcción de los datos que
se introducen como parte de este esfuerzo tendrá que ser definido en detalle
durante la Fase C. existentes bloques de construcción de datos y que se incorporen
y apoyados en el entorno de destino ya se hayan definido de manera adecuada en la
obra arquitectónica anterior; pero, si no, ellos también tendrán que ser definidos
en la Fase C. El orden de los pasos de esta fase (véase más adelante), así como el
momento en que se inician formalmente y completaron deben adaptarse a la situación
en cuestión de acuerdo con el gobierno arquitectura establecida. En particular,
determinar si en esta situación, es conveniente llevar a cabo Descripción de línea
de base o desarrollo Arquitectura objetivo primero, como se describe en la Parte
III , 19. Aplicando la iteración de la ADM . Todas las actividades que se han
iniciado en estos pasos deben estar cerradas durante el paso Finalizar la
Arquitectura de Datos (ver 10.4.8 finalizar la Arquitectura de Datos ). La
documentación generada a partir de estas medidas debe ser publicada oficialmente en
la Arquitectura paso Crear definición de documento (ver 10.4.9 Crear Arquitectura
Definición de documento . Los pasos en la Fase C (Arquitectura de datos) son los
siguientes:  10.4.1 Selección de modelos de referencia, puntos de vista y
Herramientas 

  Página 103 de 670 

TOGOF 9.1    
        10.4.2 Desarrollar Arquitectura de datos de línea de base
Descripción  10.4.3 Desarrollar Arquitectura de Datos de Blanco Descripción  10.4.4
Realizar el Análisis Gap  10.4.5 Definir candidatos Componentes Hoja de Ruta 
10.4.6 Impactos Resolver Across the Landscape Architecture  Conducta 10.4.7
Stakeholder Formal Comentario  10.4.8 Finalizar la Arquitectura de Datos  10.4.9
Crear Arquitectura Definición de documento 

10.4.1 Selección de modelos de referencia, puntos de vista y Herramientas

Opina y validar (o generar, si es necesario) el conjunto de principios de datos.
Estos normalmente formarán parte de un conjunto global de principios de
arquitectura.Lineamientos para elaborar y aplicar los principios y un conjunto de
muestras de los principios de datos, se presentan en la Parte III , 23. Principios
de Arquitectura . Seleccionar los recursos pertinentes Arquitectura datos (modelos
de referencia, patrones, etc) sobre la base de los impulsores del negocio, de los
interesados, preocupaciones y Arquitectura Empresarial. Seleccione los puntos de
vista pertinentes Arquitectura datos (por ejemplo, las partes interesadas de los
datos - Los organismos reguladores, usuarios, grupos electrógenos, temas,
auditores, etc, una variedad de dimensiones de tiempo - en tiempo real, el período
de presentación de informes, impulsado por eventos, etc; lugares, los procesos de
negocio ); es decir, los que le permitirán al arquitecto para demostrar cómo se
están abordando las preocupaciones de los interesados en la arquitectura de datos.
Identificar las herramientas y técnicas (incluyendo formas) que se utilizarán para
la captura de datos, el modelado, y el análisis, en asociación con los puntos de
vista seleccionados apropiados. Dependiendo del grado de sofisticación se
justifica, éstos pueden comprender documentos u hojas de cálculo simples, o
herramientas de modelado más sofisticadas y técnicas tales como modelos de gestión
de datos, modelos de datos, etc Ejemplos de técnicas de modelado de datos son:  
Diagrama entidad-relación  Los diagramas de clases 

10.4.1.1 Determinar Proceso general Modeling

Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de
vista específico necesario, utilizando la herramienta o método seleccionado.

  Página 104 de 670 

TOGOF 9.1    
Asegúrese de que todas las preocupaciones de los interesados están cubiertos. Si no
es así, crear nuevos modelos para abordar las preocupaciones no están cubiertos, o
aumentar los modelos existentes (véase más arriba). El proceso recomendado para el
desarrollo de una Arquitectura de datos es la siguiente:   Recoger los modelos
relacionados con los datos de Business Architecture existente y materiales de la
arquitectura de aplicaciones  Racionalizar los requisitos de datos y se alinean con
ningún catálogo de datos empresariales existentes y modelos; esto permite el
desarrollo de una relación de inventario de datos y de la entidad  Actualizar y
desarrollar matrices a través de la arquitectura, relacionando los datos de
servicio de negocio, función empresarial, los derechos de acceso, y la aplicación 
Elaborar vistas Arquitectura de datos mediante el examen de cómo se crean los
datos, distribuida, emigrado, asegurado, y se archivan 

 
10.4.1.2 Identificar Catálogos requerido de datos Bloques de Construcción

Inventario de datos de la organización se captura como un catálogo dentro de la

arquitectura de repositorio. Los catálogos son de naturaleza jerárquica y capturan
una descomposición de una entidad metamodelo y descomposiciones en todas las
entidades del modelo relacionado (por ejemplo, el componente lógico de datos ->
componente físico de datos ->] entidad de datos). Catálogos constituyen la materia
prima para el desarrollo de matrices y diagramas, y también actúan como un recurso
clave para la gestión de la cartera de negocios y capacidad de TI. Durante la fase
de arquitectura de negocio, un diagrama de Servicios de Negocio / Información fue
creado que muestra las entidades de datos clave requeridos por los principales
servicios de oficina. Este es un requisito previo a las actividades de arquitectura
de datos con éxito. El uso de la trazabilidad desde la solicitud hasta la función
empresarial de entidad de datos inherentes al marco de contenido, es posible crear
un inventario de los datos necesarios para estar en el lugar para apoyar la
Architecture Vision. Una vez que los requisitos de datos se consolidan en un solo
lugar, es posible refinar el inventario de datos para lograr la coherencia
semántica y para eliminar las lagunas y las superposiciones. Los siguientes
catálogos deben ser considerados para el desarrollo dentro de una Arquitectura de
Datos:  Catálogo de Entity Data / componente de datos 

La estructura de catálogos se basa en los atributos de las entidades metamodelo,

según se define en la Parte IV , 34. Metamodel contenido .
10.4.1.3 Identificar Matrices requeridos

Matrices muestran las relaciones básicas entre las entidades del modelo
relacionado.

  Página 105 de 670 

TOGOF 9.1    
Las matrices son la materia prima para la elaboración de diagramas y también actúan
como un recurso clave para la evaluación del impacto. En esta etapa, una entidad a
la matriz de aplicaciones podría ser producido para validar este mapeo. ¿Cómo se
crea de datos, mantienen, transforman y pasan a otras aplicaciones, o utilizados
por otras aplicaciones, ahora comenzará a ser entendido. Lagunas evidentes, tales
como las entidades que nunca parecen ser creado por una aplicación o de datos
creada pero nunca utilizado, deben observarse para el análisis de brecha más tarde.
El inventario de datos racionalizada se puede utilizar para actualizar y refinar
los diagramas de arquitectura de cómo los datos se refiere a otros aspectos de la
arquitectura. Una vez realizados estos cambios, puede ser adecuado para caer en un
corto iteración de Arquitectura de aplicaciones para resolver los cambios
identificados. Las siguientes matrices deben ser considerados para el desarrollo
dentro de una Arquitectura de Datos:    Entity Data / Función comercial (que
muestran qué datos apoyan que funciona y qué función negocio posee qué datos) 
Servicios de Negocio / Información (desarrollada durante la fase de Arquitectura
Empresarial)  Aplicación / datos (desarrollado a través de las fases de la
arquitectura de aplicaciones y arquitectura de datos) 

La estructura de las matrices se basa en los atributos de las entidades metamodelo,

según se define en la Parte IV , 34. Metamodel contenido .
10.4.1.4 Identificar Diagramas requeridos

Diagramas presentan la información Arquitectura de datos a partir de un conjunto de

diferentes perspectivas (puntos de vista) de acuerdo a los requisitos de las partes
interesadas. Una vez que las entidades de datos se han refinado, un diagrama de las
relaciones entre las entidades y sus atributos se puede producir. Es importante
señalar en este momento que la información puede ser una mezcla de los datos a
nivel de empresa (de los proveedores de servicios del sistema y la información el
proveedor del paquete) y los datos de nivel local celebradas en bases de datos
personales y hojas de cálculo. El nivel de detalle el modelo debe evaluarse
cuidadosamente. Existirán Algunos modelos de datos físicos del sistema a un nivel
muy detallado; otros sólo tendrán las entidades centrales modelados. No todos los
modelos de datos se han guardado hasta al día como las aplicaciones se modificaron
y extendieron en el tiempo. Es importante lograr un equilibrio en el nivel de
detalle (por ejemplo, la reproducción del sistema detallados esquemas de datos
físicos existentes o presentar los mapas de procesos de alto nivel y las
necesidades de datos, destacar los dos puntos de vista extremos).

  Página 106 de 670 

TOGOF 9.1    
Los siguientes diagramas deben ser considerados para el desarrollo dentro de una
Arquitectura de Datos:       Diagrama conceptual de datos  Diagrama de lógica
de datos  Diagrama de Divulgación de Datos  Diagrama del ciclo de vida de datos 
Diagrama de seguridad de datos  Diagrama de migración de datos 

10.4.1.5 Identificar los tipos de Requisito para ser Collected

Una vez que los catálogos de arquitectura de datos, matrices y diagramas han sido
desarrollados, modelado de arquitectura se completa mediante la formalización de
los requisitos de datos enfocada para la implementación de la arquitectura destino.
Estos requisitos pueden:    Se relacionan con el dominio de datos  Proporcionar
los requisitos de entrada en la aplicación y Tecnología Arquitecturas  Proporcionar
orientaciones detalladas que se refleja en el diseño e implementación para asegurar
que la solución satisface los requisitos de arquitectura originales 

En este paso, el arquitecto debe identificar los requisitos que deben ser cumplidos
por la arquitectura (ver Desarrollo 17.2.2 Requisitos ).

10.4.2 Desarrollar Arquitectura de datos de línea de base Descripción

Desarrollar una descripción de línea de base de la arquitectura de datos
existentes, en la medida necesaria para apoyar la Arquitectura de Datos de Blanco.
El alcance y el nivel de detalle que se ha definido dependerá de la medida en que
es probable que sean transferidos a los de Arquitectura de Datos de Blanco
elementos de datos existentes, y de si existen descripciones arquitectónicas, como
se describe en 10.2 Enfoque . En la medida de lo posible, identificar los bloques
de construcción de la arquitectura de datos pertinentes, aprovechando la
arquitectura de repositorio (véase la Parte V , 41. Arquitectura del repositorio ).
Cuando los nuevos modelos de arquitectura deben ser desarrollados para satisfacer
las preocupaciones de las partes interesadas, utilice los modelos identificados en
el paso 1 como una guía para la creación de nuevos contenidos arquitectura para
describir la arquitectura de línea de base.

  Página 107 de 670 

TOGOF 9.1    
10.4.3 Desarrollar Arquitectura de Datos de Blanco Descripción
Desarrollar una descripción Meta para la Arquitectura de datos, en la medida
necesaria para apoyar la Arquitectura Meta y visión de Arquitectura Empresarial. El
alcance y el nivel de detalle que se ha definido dependerá de la pertinencia de los
elementos de datos a la consecución de la arquitectura destino y de si existen
descripciones arquitectónicas. En la medida de lo posible, identificar los bloques
de construcción de la arquitectura de datos pertinentes, aprovechando la
arquitectura de repositorio (véase la Parte V , 41. Arquitectura del repositorio ).
Cuando los nuevos modelos de arquitectura deben ser desarrollados para satisfacer
las preocupaciones de las partes interesadas, utilice los modelos identificados en
el paso 1 como una guía para la creación de nuevos contenidos arquitectura para
describir la arquitectura destino.

10.4.4 Realizar el Análisis Gap

Verifique los modelos de arquitectura para la coherencia y la precisión interna: 
   Realizar análisis de trade-off para resolver conflictos (si los hay) entre
los diferentes puntos de vista  Validar que los modelos son compatibles con los
principios, objetivos y limitaciones  Nota cambios en el punto de vista
representado en los modelos seleccionados desde el repositorio de Arquitectura, y
el documento  Modelos de arquitectura de prueba para la integridad frente a los
requisitos 

Identificar las brechas entre la línea base y de destino, utilizando la técnica de

análisis de carencias como se describe en la Parte III , 27. Análisis Gap .

10.4.5 Definir candidatos Componentes Hoja de Ruta

Después de la creación de una arquitectura de referencia, Arquitectura objetivo y
análisis de brechas, se requiere un plan de datos para dar prioridad a las
actividades en las próximas fases. Esta hoja de ruta inicial Arquitectura de datos
se utilizará como materia prima para apoyar definición más detallada de un plan de
trabajo interdisciplinario consolidado dentro de las Oportunidades y fase
Solutions.

10.4.6 Impactos Resolver Across la Arquitectura del Paisaje

Una vez que la Arquitectura de Datos ha finalizado, es necesario entender los
impactos o repercusiones más amplias. En esta etapa, otros artefactos de
arquitectura en la arquitectura del paisaje deben ser examinados para identificar:
  ¿Crea esto Arquitectura de Datos un impacto en las arquitecturas
preexistentes?  ¿Se han hecho los cambios recientes que impactan la Arquitectura de
Datos? 

  Página 108 de 670 

TOGOF 9.1    
   ¿Hay oportunidades para aprovechar el trabajo de esta arquitectura de datos
en otras áreas de la organización?  ¿Impacta esta arquitectura de datos de otros
proyectos (incluyendo los previstos, así como los actualmente en curso)?  ¿Esto
Arquitectura de Datos verse afectado por otros proyectos (incluidos los previstos,
así como los actualmente en curso)? 

Conducta 10.4.7 Stakeholder Formal Comentario

Compruebe la motivación original para el proyecto de la arquitectura y la
Declaración de Arquitectura de Trabajo contra la arquitectura de datos propuesto.
Llevar a cabo un análisis de impacto para identificar las áreas donde las
arquitecturas empresariales y de aplicaciones (por ejemplo, prácticas de negocios)
puede que tenga que cambiar para atender a los cambios en la arquitectura de datos
(por ejemplo, cambios en las formas o procedimientos, aplicaciones o sistemas de
base de datos). Si el impacto es significativo, esto puede justificar las
Arquitecturas Empresariales y de aplicación está revisando. Identifique las áreas
en las que la arquitectura de la aplicación (si se generan en este punto) puede
tener que cambiar para atender a los cambios en la arquitectura de datos (o para
identificar las limitaciones en la arquitectura de la aplicación a punto de ser
diseñados). Si el impacto es significativo, puede ser apropiado para caer en una
breve versión de la arquitectura de aplicaciones en este punto. Identificar las
posibles limitaciones de la arquitectura de la tecnología a punto de ser diseñados,
el perfeccionamiento de la Arquitectura de Datos propuesta sólo si es necesario.
10.4.8 Finalizar la Arquitectura de Datos  Seleccione estándares para cada uno de
los bloques de construcción, reutilizando la mayor cantidad posible de los modelos
de referencia seleccionados del repositorio Arquitectura 
  Documentar completamente cada bloque de construcción  Realizar última
comprobación cruzada de la arquitectura general de los requerimientos del negocio;
documento de justificación de la construcción de las decisiones del bloque en el
documento de la arquitectura  Documento Final informe requisitos de trazabilidad 
Documento de asignación definitiva de la arquitectura dentro del Repositorio de
Arquitectura; de los bloques de construcción seleccionados, identificar las que
podrían ser reutilizados, y publicar a través del Repositorio de Arquitectura 
Finalice todos los productos de trabajo, tales como análisis de las deficiencias 

 

  Página 109 de 670 

TOGOF 9.1    
10.4.9 Crear Arquitectura Definición de documento
Justificación del documento para la construcción de bloquear decisiones en la
definición de documento Architecture. Preparar arquitectura de datos de secciones
de la definición de documento Arquitectura, que comprende algunos o todos de:   
   Modelo de datos de negocios  Modelo de datos lógicos  Modelo de proceso de
gestión de datos  Entity Data / matriz de funciones de negocios  Requisitos de
interoperabilidad de datos (por ejemplo, el esquema XML, las políticas de
seguridad)  En su caso, utilizar los informes y / o gráficos generados por las
herramientas para demostrar puntos de vista clave de la arquitectura de modelado;
direccionar el documento para su examen por los interesados, e incorporar la
retroalimentación 

10.5 Salidas
Los resultados de la Fase C (Arquitectura de datos) pueden incluir, pero no se
limitan a:  Las versiones refinadas y actualizadas de los entregables de la fase
Arquitectura Visión, en su caso:  o Declaración de Arquitectura de trabajo (véase
la Parte IV , 36.2.20 Declaración de Arquitectura de Trabajo ), actualizado en caso
necesario  Principios datos validados (véase la Parte III , 23.6.2 Datos Principios
), o nuevos principios de datos (si se generan aquí) 

o 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o Arquitectura de datos
de línea de base, la versión 1.0, en su caso  Arquitectura de datos de destino,
Versión 1.0      o Modelo de datos de negocios  Modelo de datos lógicos 
Modelos de procesos de gestión de datos  Entity Data / matriz de funciones de
negocios 

Vistas correspondiente a los puntos de vista seleccionados abordar las principales

preocupaciones de las partes interesadas 

  Página 110 de 670 

TOGOF 9.1    
 Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6
Arquitectura especificación de requisitos ), incluyendo dichos requisitos
arquitectura de datos como:  o o o Los resultados del análisis de Gap  Requisitos
de interoperabilidad de datos  Requisitos técnicos pertinentes que se aplicarán a
esta evolución del ciclo de desarrollo de la arquitectura  Las restricciones en la
Arquitectura de Tecnología a punto de ser diseñados  Requisitos de negocio
actualizados, en su caso  Requisitos de las aplicaciones actualizadas, en su caso 

o o o 

Componentes de la arquitectura de datos de una Arquitectura Roadmap (ver la Parte

IV , 36.2.7 Arquitectura Roadmap ) 

Las salidas pueden incluir algunos o todos de los siguientes:  Catálogos:  o 

Catálogo de Entity Data / componente de datos 

Matrices:  o o Entity Data / matriz de funciones de negocios  Aplicación / matriz

de datos 

Diagramas:  o o o o o o Diagrama conceptual de datos  Diagrama de lógica de datos 

Diagrama de Divulgación de Datos  Diagrama de seguridad de datos  Diagrama de
migración de datos  Diagrama del ciclo de vida de datos 

  Página 111 de 670 

TOGOF 9.1       

. 11 Fase C: Arquitecturas de Sistemas de Información - Arquitectura de la

aplicación
Contenido del capítulo 
11.1 Objetivos  |  11.2 Enfoque  |  11.3 entradas  |  11.4 Pasos  |  11.5 Salidas 

En este capítulo se describe la parte Arquitectura de la aplicación de la Fase C.

11.1 Objetivos
Los objetivos de la parte Arquitectura de la aplicación de la Fase C son: 
Desarrollar la Arquitectura de aplicación de destino que permite a la Arquitectura
de Negocios y el Architecture Vision, al dirigirse a la Solicitud de Arquitectura
Trabajo y preocupaciones de los interesados  Identificar los componentes de la Hoja
de Ruta Arquitectura candidatos sobre la base de las brechas entre la línea de base
y objetivo de aplicación de arquitecturas 

11.2 Enfoque
11.2.1 Arquitectura Repositorio
Como parte de esta fase, el equipo de arquitectura tendrá que considerar qué
recursos están disponibles arquitectura de aplicaciones relevantes en la
arquitectura de repositorio (véase la Parte V , 41. Arquitectura del repositorio ).
En particular:  Modelos de negocio genéricos relacionados con la industria del
sector "vertical" de la organización; por ejemplo:  o El TeleManagement Forum (TMF)
- www.tmforum.org - ha desarrollado modelos detallados aplicaciones relevantes para
la industria de las Telecomunicaciones.  El Grupo de Gestión de objetos (OMG) -
www.omg.org - tiene una serie de grupos de trabajo de dominio de los modelos de
software en desarrollo verticales relevante para dominios verticales específicos
como la salud, Transporte, Finanzas, etc 

o


Modelos de aplicación pertinentes a las funciones de negocio de alto nivel comunes,

tales como el comercio electrónico, gestión de la cadena de suministro, etc 

The Open Group cuenta con un modelo de referencia para la Información Integrada de
Infraestructura (III-RM) - véase la parte VI , 44. Integrado de Información
Infraestructura Modelo

  Página 112 de 670 

TOGOF 9.1    
de referencia - que se centra en los componentes de nivel de aplicación y servicios
necesarios para proporcionar una infraestructura de información integrada.

11.3 Entradas
Esta sección define las entradas a la Fase C (Arquitectura de la aplicación).

11.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio )  11.3.2 Entradas
para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte
IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 
  Evaluación de capacidades (véase la Parte IV , 36.2.10 Evaluación de
Capacidad )  Plan de comunicación (ver la Parte IV , 36.2.12 Plan de Comunicaciones
) 

11.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura

Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o o o o o  Ámbito de las organizaciones afectadas  La evaluación gestacional,
lagunas, y el enfoque de resolución  Roles y responsabilidades de equipo de
arquitectura (s)  Las restricciones sobre el trabajo de arquitectura  Necesidades
presupuestarias  Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

   

Principios de la aplicación (ver la Parte III , 23.6.3 Principios de Aplicación ),

si existe  Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20
Declaración de Arquitectura de Trabajo )  Architecture Vision (véase la Parte IV ,
36.2.8 Architecture Vision )  Arquitectura repositorio (véase la Parte IV , 36.2.5
Arquitectura del repositorio ), incluyendo:  o Bloques de construcción
reutilizables 

  Página 113 de 670 

TOGOF 9.1    
o o o  Modelos de referencia disponibles al público  Modelos de referencia
específicos de la organización  Normas de la Organización 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o o Línea de base de
Empresas Arquitectura, Version 1.0 (detallado), si procede  Objetivo Negocio
Arquitectura, Version 1.0 (detallado)  Arquitectura de línea de base de datos,
versión 1.0 (detallados), o la Versión 0.1 (Vision)  Arquitectura Meta Data,
versión 1.0 (detallados), o la Versión 0.1 (Vision)  Línea de base de arquitectura
de aplicaciones, Versión 0.1, si está disponible adecuado y si  Objetivo de
Arquitectura de aplicaciones, Versión 0.1, si está disponible  Línea de Base
Tecnológica de Arquitectura, Version 0.1 (Vision)  Tecnología Target Arquitectura,
Version 0.1 (Vision) 

o o

o o o 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo:  o Los resultados del
análisis de Gap (de Arquitectura de Negocios y Arquitectura de datos, si está
disponible)  Requisitos técnicos pertinentes que se aplicarán a esta fase 

o 

Los componentes empresariales y arquitectura de datos de una hoja de ruta de la

Arquitectura, en su caso (véase la Parte IV , 36.2.7 Arquitectura Roadmap ) 

11.4 Pasos
El nivel de detalle abordado en la Fase C dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura. Nuevos bloques de construcción de aplicaciones
que se están introduciendo en el marco de este esfuerzo tendrá que ser definido en
detalle durante la Fase C. Existentes bloques de construcción de aplicaciones y que
se incorporen y apoyados en el entorno de destino ya se haya definido de manera
adecuada en la obra arquitectónica anterior; pero, si no, ellos también tendrán que
ser definidos en la Fase C. El orden de los pasos de esta fase (ver a continuación,
así como el momento en que se inician formalmente y completaron debe adaptarse a la
situación en cuestión de acuerdo con el gobierno arquitectura establecida. En
particular, determinar si en esta situación, es apropiado realizar Descripción
Línea de Base o desarrollo Arquitectura objetivo primero, como se describe en la
Parte III , 19. Aplicando la iteración de la ADM .

  Página 114 de 670 

TOGOF 9.1    
Todas las actividades que se han iniciado en estos pasos deben estar cerradas
durante el paso Finalizar la Arquitectura de la aplicación (ver 11.4.8 finalizar la
Arquitectura de la aplicación ). La documentación generada a partir de estas
medidas debe ser publicada oficialmente en la Arquitectura paso Crear definición de
documento (ver 11.4.9 Crear Arquitectura Definición de documento ). Los pasos en la
Fase C (Arquitectura de aplicaciones) son las siguientes:          11.4.1
Selección de modelos de referencia, puntos de vista y Herramientas  11.4.2
Desarrollar Línea Base Application Architecture Descripción  11.4.3 Desarrollar
Target Application Architecture Descripción  11.4.4 Realizar el Análisis Gap 
11.4.5 Definir candidatos Componentes Hoja de Ruta  11.4.6 Impactos Resolver Across
the Landscape Architecture  Conducta 11.4.7 Stakeholder Formal Comentario  11.4.8
Finalizar la arquitectura de aplicaciones  11.4.9 Crear Arquitectura Definición de
documento 

11.4.1 Selección de modelos de referencia, puntos de vista y Herramientas

Opina y validar (o generar, si es necesario) el conjunto de principios de
aplicación. Estos normalmente formarán parte de un conjunto global de principios de
arquitectura.Lineamientos para elaborar y aplicar los principios y un conjunto de
muestras de los principios de aplicación, se dan en la Parte III , 23. Principios
de Arquitectura . Seleccionar los recursos pertinentes Arquitectura de aplicaciones
(modelos de referencia, patrones, etc) desde el repositorio de Arquitectura, sobre
la base de los impulsores del negocio, las partes interesadas y sus preocupaciones.
Seleccione los puntos de vista pertinentes Arquitectura de aplicaciones (por
ejemplo, las partes interesadas de las aplicaciones - puntos de vista relevantes
para los usuarios funcionales e individuales de las aplicaciones, etc); es decir,
los que le permitirán al arquitecto para demostrar cómo se están abordando las
preocupaciones de los interesados en la arquitectura de la aplicación. Identificar
las herramientas y las técnicas que se utilizarán para la captura, modelado y
análisis, en asociación con los puntos de vista seleccionados
apropiados.Dependiendo del grado de sofisticación se justifica, éstos pueden
comprender documentos simples u hojas de cálculo, o herramientas de modelado más
sofisticadas y técnicas. Considere el uso de descripciones independientes de la
plataforma de la lógica de negocio. Por ejemplo, Model Driven Architecture del OMG
(MDA) ofrece una aproximación a las arquitecturas de modelado de aplicaciones que
conserva la lógica de negocio de los cambios en la plataforma subyacente y la
tecnología de aplicación.

  Página 115 de 670 

TOGOF 9.1    
11.4.1.1 Determinar Proceso general Modeling

Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de
vista específico necesario, utilizando la herramienta o método seleccionado.
Asegúrese de que todas las preocupaciones de los interesados están cubiertos. Si no
es así, crear nuevos modelos para abordar las preocupaciones no están cubiertos, o
aumentar los modelos existentes (véase más arriba). El proceso recomendado para el
desarrollo de una Arquitectura de la aplicación es la siguiente:  Comprender la
lista de aplicaciones o componentes de aplicaciones que se requieren, sobre la base
de la línea de base del portafolio de aplicaciones, cuáles son los requisitos, y el
alcance de arquitectura empresarial  Simplifique aplicaciones complejas mediante la
descomposición en dos o más solicitudes  Asegúrese de que el conjunto de
definiciones de aplicación es internamente coherente, mediante la eliminación de la
funcionalidad duplicado medida de lo posible, y la combinación de aplicaciones
similares en uno  Identificar las aplicaciones lógicas y las aplicaciones físicas
más adecuadas  Desarrollar matrices a través de la arquitectura, relacionando
aplicaciones al servicio de negocios, evento de negocios, datos, procesos, etc 
Elaborar un conjunto de puntos de vista de arquitectura de aplicaciones mediante el
examen de cómo funcionará la aplicación, la captura de la integración, la
migración, el desarrollo y las preocupaciones operacionales 

 

  

El nivel y el rigor de la descomposición necesaria varía de una empresa a otra, así

como dentro de una empresa, y el arquitecto deben tener en cuenta los objetivos de
la empresa, los objetivos, el alcance y propósito del esfuerzo arquitectura de la
empresa para determinar el nivel de descomposición. El nivel de granularidad debe
ser suficiente para permitir la identificación de brechas y el alcance de los
paquetes de trabajo candidatos.
11.4.1.2 Identificar Catálogos obligatorios de aplicación Bloques de Construcción

Cartera de Aplicaciones de la organización se captura como un catálogo dentro de la

arquitectura de repositorio. Los catálogos son de naturaleza jerárquica y capturan
una descomposición de una entidad metamodelo y descomposiciones en todas las
entidades del modelo relacionado (por ejemplo, el componente lógico de aplicación -
> componente de aplicación física ->] servicio del sistema de información).
Catálogos constituyen la materia prima para el desarrollo de matrices y diagramas,
y también actúan como un recurso clave para la gestión de la cartera de negocios y
capacidad de TI. La estructura de catálogos se basa en los atributos de las
entidades metamodelo, según se define en la Parte IV , 34. Metamodel contenido .

  Página 116 de 670 

TOGOF 9.1    
Los siguientes catálogos deben ser considerados para el desarrollo dentro de una
arquitectura de aplicaciones:   Catálogo de la cartera de aplicaciones  Catálogo
de interfaz 

11.4.1.3 Identificar Matrices requeridos

Matrices muestran las relaciones básicas entre las entidades del modelo
relacionado. Las matrices son la materia prima para la elaboración de diagramas y
también actúan como un recurso clave para la evaluación del impacto. Una vez que la
línea de base de carteras de aplicaciones ha sido montado, es necesario mapear las
aplicaciones para su propósito en el apoyo de la empresa. La asignación inicial
debe centrarse en los servicios de negocio dentro de la arquitectura de negocio, ya
que este es el nivel de granularidad donde es más probable que se necesiten
decisiones de gran importancia arquitectónica. Una vez que las aplicaciones se
asignan a los servicios a las empresas, sino que también será posible hacer
asociaciones de las aplicaciones a los datos, a través de los esquemas de negocio
de información desarrollados en Arquitectura Empresarial. Si disponible, los
modelos de datos de aplicaciones de línea de base pueden ser utilizados para
validar la arquitectura de negocios y también para identificar qué datos se lleva a
cabo a nivel local y la que se accede de forma remota. La fase de Arquitectura de
datos se centrará en estos temas, por lo que en este punto puede ser apropiado para
caer en un corto iteración de Arquitectura de datos si se considera que es valioso
para el alcance de la participación de la arquitectura. El uso de la información
existente en el catálogo de aplicaciones de línea de base, la arquitectura de la
aplicación debe identificar el usuario y las dependencias organizativas de
aplicaciones. Esta actividad apoyará la futura planificación de estado mediante la
determinación de las comunidades de usuarios afectados, así como facilitar la
agrupación de aplicación según el tipo de usuario o la ubicación del usuario. Una
comunidad de usuarios clave a considerar en concreto es la organización de apoyo
operacional. Esta actividad debe examinar las dependencias de aplicación de las
capacidades de operaciones compartidas y producir un diagrama de la forma en que
cada aplicación es operado y administrado de manera efectiva. Considerando
específicamente las necesidades de la comunidad operacional puede identificar los
requisitos de capacidades nuevas o ampliadas de gobierno y aplicaciones. Las
siguientes matrices deben ser considerados para el desarrollo dentro de una
arquitectura de aplicaciones:  Aplicación de la matriz / Organización 

  Página 117 de 670 

TOGOF 9.1    
   Matriz de Papel / Aplicación  Matriz de interacción Aplicación  Matriz de
Aplicación / Función 

La estructura de las matrices se basa en los atributos de las entidades metamodelo,

según se define en la Parte IV , 34. Metamodel contenido .
11.4.1.4 Identificar Diagramas requeridos
Diagramas presentan la información Arquitectura de la aplicación de un conjunto de
diferentes perspectivas (puntos de vista) de acuerdo a los requisitos de las partes
interesadas. Una vez conocida la funcionalidad deseada de una aplicación, es
necesario realizar una evaluación interna de cómo debe estructurarse la aplicación
para satisfacer sus necesidades. En el caso de aplicaciones empaquetadas, es
probable que sea el caso de que la aplicación es compatible con una serie de
opciones de configuración, módulos adicionales, o los servicios de aplicaciones que
se pueden aplicar a la solución. Para las aplicaciones desarrolladas a medida, es
necesario identificar la estructura de alto nivel de la aplicación en términos de
módulos o subsistemas como base para organizar la actividad de diseño. Los
siguientes diagramas deben ser considerados para el desarrollo dentro de una
arquitectura de aplicaciones:         Diagrama de comunicaciones de la
aplicación  Aplicación y usuario diagrama Ubicación  Diagrama de administración de
Enterprise  Diagrama Realización de proceso / aplicación  Diagrama de Migración de
aplicaciones  Diagrama de distribución de software  Software diagrama de
Ingeniería  Esquema de aplicación de casos de uso 

La estructura de los diagramas se basa en los atributos de las entidades

metamodelo, según se define en la Parte IV , 34. Metamodel contenido .
11.4.1.5 Identificar los tipos de Requisito para ser Collected

Una vez que los catálogos de arquitectura de la aplicación, matrices y diagramas

han sido desarrollados, modelado de arquitectura se completa mediante la
formalización de los requisitos de las aplicaciones enfocadas para la
implementación de la arquitectura destino. Estos requisitos pueden:

  Página 118 de 670 

TOGOF 9.1    
   Se relacionan con el dominio de aplicación  Proporcionar los requisitos de
entrada en las arquitecturas de datos y tecnología  Proporcionar orientaciones
detalladas que se refleja en el diseño e implementación para asegurar que la
solución satisface los requisitos de arquitectura originales 

En este paso, el arquitecto debe identificar los requisitos que deben ser cumplidos
por la arquitectura (ver Desarrollo 17.2.2 Requisitos ).

11.4.2 Desarrollar Línea Base Application Architecture Descripción

Desarrollar una descripción de línea de base de la arquitectura de aplicaciones
existentes, en la medida necesaria para apoyar la arquitectura de aplicaciones de
destino. El alcance y el nivel de detalle que se ha definido dependerá de la medida
en que es probable que sean prorrogados en la arquitectura de aplicación de destino
aplicaciones existentes, y de si existen descripciones de la arquitectura, como se
describe en 11.2 Enfoque . En la medida de lo posible, identificar los bloques de
construcción de arquitectura de aplicación pertinentes, aprovechando la
arquitectura de repositorio (véase la Parte V , 41. Arquitectura Repositorio ). Si
no está ya existentes dentro de la arquitectura de repositorio, definir cada
aplicación de acuerdo con el catálogo de la Cartera de Aplicaciones (ver Parte IV ,
34. Metamodel contenido ). Cuando los nuevos modelos de arquitectura deben ser
desarrollados para satisfacer las preocupaciones de las partes interesadas, utilice
los modelos identificados en el paso 1 como una guía para la creación de nuevos
contenidos arquitectura para describir la arquitectura de línea de base.

11.4.3 Desarrollar Target Application Architecture Descripción

Desarrollar una descripción Meta para la arquitectura de la aplicación, en la
medida necesaria para apoyar la Architecture Vision, Target Arquitectura negocios y
Arquitectura de datos de destino. El alcance y el nivel de detalle que se ha
definido dependerá de la pertinencia de los elementos de las aplicaciones a la
consecución del Objetivo Architecture Vision, y de si existen descripciones
arquitectónicas. En la medida de lo posible, identificar los bloques de
construcción de arquitectura de aplicación pertinentes, aprovechando la
arquitectura de repositorio (véase la Parte V , 41. Arquitectura del repositorio ).
Cuando los nuevos modelos de arquitectura deben ser desarrollados para satisfacer
las preocupaciones de las partes interesadas, utilice los modelos identificados en
el paso 1 como una guía para la creación de nuevos contenidos arquitectura para
describir la arquitectura destino.

11.4.4 Realizar el Análisis Gap

Verifique los modelos de arquitectura para la coherencia y la precisión interna: 
 Realizar análisis de trade-off para resolver conflictos (si los hay) entre los
diferentes puntos de vista  Validar que los modelos son compatibles con los
principios, objetivos y limitaciones 

  Página 119 de 670 

TOGOF 9.1    
  Nota cambios en el punto de vista representado en los modelos seleccionados
desde el repositorio de Arquitectura, y el documento  Modelos de arquitectura de
prueba para la integridad frente a los requisitos 

Identificar las brechas entre la línea base y de destino, utilizando la técnica de

análisis de carencias como se describe en la Parte III , 27. Análisis Gap .

11.4.5 Definir candidatos Componentes Hoja de Ruta

Después de la creación de una arquitectura de referencia, Arquitectura objetivo y
análisis de brechas, se requiere un plan de aplicación para dar prioridad a las
actividades en las próximas fases. Esta hoja de ruta inicial Arquitectura de la
aplicación se utilizará como materia prima para apoyar definición más detallada de
un plan de trabajo interdisciplinario consolidado dentro de las Oportunidades y
fase Solutions.

11.4.6 Impactos Resolver Across la Arquitectura del Paisaje

Una vez que la arquitectura de la aplicación se finaliza, es necesario entender los
impactos o repercusiones más amplias. En esta etapa, otros artefactos de
arquitectura en la arquitectura del paisaje deben ser examinados para identificar:
     ¿Crea esta arquitectura de aplicaciones un impacto en las arquitecturas
preexistentes?  ¿Se han hecho los cambios recientes que impactan la arquitectura de
aplicaciones?  ¿Hay oportunidades para aprovechar el trabajo de esta arquitectura
de aplicaciones en otras áreas de la organización?  ¿Impacta esta arquitectura de
aplicaciones de otros proyectos (incluyendo los previstos, así como los actualmente
en curso)?  ¿Esta arquitectura de aplicaciones verse afectado por otros proyectos
(incluidos los previstos, así como los actualmente en curso)? 

Conducta 11.4.7 Stakeholder Formal Comentario

Compruebe la motivación original para el proyecto de la arquitectura y la
Declaración de Arquitectura de Trabajo contra la propuesta de arquitectura de
aplicaciones. Llevar a cabo un análisis de impacto, para identificar las áreas
donde las arquitecturas empresariales y de datos (por ejemplo, prácticas de
negocios) puede que tenga que cambiar para atender a los cambios en la arquitectura
de la aplicación (por ejemplo, cambios en las formas o procedimientos, aplicaciones
o sistemas de base de datos). Si el impacto es significativo, esto puede justificar
el negocio y los datos Arquitecturas está revisando. Identificar las posibles
limitaciones de la arquitectura de la tecnología (especialmente la infraestructura)
a punto de ser diseñado.

  Página 120 de 670 
TOGOF 9.1    
11.4.8 Finalizar la arquitectura de aplicaciones  Seleccione estándares para
cada uno de los bloques de construcción, reutilizando la mayor cantidad posible de
los modelos de referencia seleccionados del repositorio Arquitectura 
  Documentar completamente cada bloque de construcción  Realizar última
comprobación cruzada de la arquitectura general de los requerimientos del negocio;
documento de justificación de la construcción de las decisiones del bloque en el
documento de la arquitectura  Documento Final informe requisitos de trazabilidad 
Documento de asignación definitiva de la arquitectura dentro del Repositorio de
Arquitectura; de los bloques de construcción seleccionados, identificar las que
podrían ser reutilizados, y publicar a través del Repositorio de Arquitectura 
Finalice todos los productos de trabajo, tales como análisis de las deficiencias 

 

11.4.9 Crear Arquitectura Definición de documento  Justificación del

documento para la construcción de bloquear decisiones en la definición de documento
Arquitectura 
 Prepare secciones arquitectura de la aplicación de la definición de documento
Arquitectura; en su caso, utilizar los informes y / o gráficos generados por las
herramientas para demostrar puntos de vista clave de la arquitectura de modelado;
direccionar el documento para su examen por los interesados, e incorporar la
retroalimentación 

11.5 Salidas
Los resultados de la Fase C (Arquitectura de la aplicación) pueden incluir, pero no
se limitan a:  Las versiones refinadas y actualizadas de los entregables de la
fase Arquitectura Visión, en su caso:  o Declaración de Arquitectura de trabajo
(véase la Parte IV , 36.2.20 Declaración de Arquitectura de Trabajo ), actualizado
en caso necesario  Principios de aplicación validados, o nuevos principios de
aplicación (si se generan aquí) 

o 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o Línea de base de
arquitectura de aplicaciones, la versión 1.0, en su caso  Objetivo de Arquitectura
de aplicaciones, versión 1.0     Modelo de sistemas de proceso  Modelo de
sistemas Place  Tiempo modelo de sistemas 

  Página 121 de 670 

TOGOF 9.1    
 o  Modelo de sistemas Gente 

Vistas correspondiente a los puntos de vista seleccionados, abordar las

preocupaciones de interés clave 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo dichos requisitos
arquitectura de aplicaciones como:  o o o Los resultados del análisis de Gap 
Aplicaciones requisitos de interoperabilidad  Requisitos técnicos pertinentes que
se aplicarán a esta evolución del ciclo de desarrollo de la arquitectura  Las
restricciones en la Arquitectura de Tecnología a punto de ser diseñados  Requisitos
de negocio actualizados, en su caso  Requisitos de datos actualizadas, en su caso 

o o o 

Componentes de la arquitectura de aplicación de una Arquitectura Roadmap (ver la

Parte IV , 36.2.7 Arquitectura Roadmap ) 

Las salidas pueden incluir algunos o todos de los siguientes:  Catálogos:  o o 

Catálogo de la cartera de aplicaciones  Catálogo de interfaz 

Matrices:  o o o o Aplicación de la matriz / Organización  Matriz de Papel /

Aplicación  Matriz de Aplicación / Función  Matriz de interacción Aplicación 

Diagramas:  o o o o o Diagrama de comunicaciones de la aplicación  Aplicación y

usuario diagrama Ubicación  Esquema de aplicación de casos de uso  Diagrama de
administración de Enterprise  Diagrama Realización de proceso / aplicación 

  Página 122 de 670 

TOGOF 9.1    
o o o Software diagrama de Ingeniería  Diagrama de Migración de aplicaciones 
Diagrama de distribución de software 

  Página 123 de 670 

TOGOF 9.1       

. 12 Fase D: Architecture Tecnología

En este capítulo se describe el desarrollo de una arquitectura de tecnología para
un proyecto de arquitectura.

  Figura 12‐1: Fase D: Architecture Tecnología 

12.1 Objetivos
Los objetivos de la Fase D son:  Desarrollar la Arquitectura Tecnológica Objetivo
que permite la aplicación lógica y física y los componentes de datos y el
Architecture Vision, dirigiéndose a la Solicitud de Arquitectura Trabajo y
preocupaciones de los interesados  Identificar los componentes de la Hoja de Ruta
Arquitectura candidatos sobre la base de las brechas entre la tecnología objetivo
Arquitecturas de referencia y 

12.2 Enfoque
  Página 124 de 670 

TOGOF 9.1    
12.2.1 Arquitectura Repositorio
Como parte de la fase D, el equipo de arquitectura tendrá que considerar qué
recursos están disponibles Arquitectura Tecnología relevantes en la arquitectura de
repositorio (véase la Parte V , 41. Arquitectura del repositorio ). En particular:
   Servicios de TI existentes tal como se documenta en el repositorio de IT o
catálogo de servicios de TI  TOGAF Modelo Referencia técnica (TRM)  Modelos
tecnológicos genéricos relacionados con la industria del sector "vertical" de la
organización  Por ejemplo, el TeleManagement Forum (TMF) - www.tmforum.org - ha
desarrollado modelos de tecnología detallados relacionados con la industria de las
Telecomunicaciones.  Modelos de tecnología relevante para los sistemas comunes
Arquitecturas  Por ejemplo, The Open Group cuenta con un modelo de referencia para
la Información Integrada de Infraestructura (III-RM) - véase la parte VI , 44.
Integrado de Información Infraestructura Modelo de referencia - que se centra en
los componentes de nivel de aplicación y servicios básicos necesarios para
proporcionar una infraestructura de información integrada.

12.3 Entradas
Esta sección define las entradas para la Fase D.

12.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 
 Información del producto en productos candidatos 

12.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo

(véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 
  Evaluación de capacidades (véase la Parte IV , 36.2.10 Evaluación de
Capacidad )  Plan de comunicación (ver la Parte IV , 36.2.12 Plan de Comunicaciones
) 

12.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura

Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o Ámbito de las organizaciones afectadas  La evaluación gestacional, lagunas, y
el enfoque de resolución 

  Página 125 de 670 

TOGOF 9.1    
o o o o  Roles y responsabilidades de equipo de arquitectura (s)  Las
restricciones sobre el trabajo de arquitectura  Necesidades presupuestarias 
Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

   

Principios Tecnología (ver Parte III , Principios Tecnológicos 23.6.4 ), si existe 

Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de
Arquitectura de Trabajo )  Architecture Vision (véase la Parte IV , 36.2.8
Architecture Vision )  Arquitectura repositorio (véase la Parte IV , 36.2.5
Arquitectura del repositorio ), incluyendo:  o o o o Bloques de construcción
reutilizables  Modelos de referencia disponibles al público  Modelos de referencia
específicos de la organización  Normas de la Organización 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o o o o o o o Línea de
base de Empresas Arquitectura, Version 1.0 (detallado)  Target Business
Architecture Version 1.0 (detallado)  Arquitectura de datos de línea de base,
versión 1.0 (detallado)  Arquitectura de datos de destino, Versión 1.0 (detallado) 
Línea de base de arquitectura de aplicaciones, versión 1.0 (detallado)  Objetivo de
Arquitectura de aplicaciones, versión 1.0 (detallado)  Línea de Base Tecnológica de
Arquitectura, Versión 0.1 (la visión)  Tecnología Target Arquitectura, Versión 0.1
(la visión) 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo: 

  Página 126 de 670 

TOGOF 9.1    
o Los resultados del análisis de Gap (de negocios, datos, y aplicación de
arquitecturas)  Requisitos técnicos pertinentes de las fases anteriores 

o 

Los componentes empresariales, datos y arquitectura de la aplicación de una

Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap ) 

12.4 Pasos
El nivel de detalle abordado en la Fase D dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura. Bloques de construcción nueva tecnología que se
introducen como parte de este esfuerzo tendrá que ser definido en detalle durante
la Fase D. existente bloques de construcción de tecnología para ser admitidos en el
entorno de destino pueden tener que redefinirse en la Fase D para garantizar la
interoperabilidad y adaptarse a sus fines dentro de esta arquitectura tecnología
específica. El orden de los pasos en la Fase D (véase más adelante), así como el
momento en que se inician formalmente y completaron deben adaptarse a la situación
en cuestión de acuerdo con el gobierno arquitectura establecida. En particular,
determinar si en esta situación, es conveniente llevar a cabo Descripción de línea
de base o desarrollo Arquitectura objetivo primero, como se describe en la Parte
III , 19. Aplicando la iteración de la ADM . Todas las actividades que se han
iniciado en estos pasos deben estar cerradas durante el finalizar el paso
Arquitectura Tecnología (ver 12.4.8 finalizar la Arquitectura de Tecnología ). La
documentación generada a partir de estas medidas debe ser publicada oficialmente en
la Arquitectura paso Crear definición de documento (ver 12.4.9 Crear Arquitectura
Definición de documento ). Los pasos en la Fase D son como sigue:         
12.4.1 Selección de modelos de referencia, puntos de vista y Herramientas  12.4.2
Desarrollar Línea de Base Tecnológica Arquitectura Descripción  12.4.3 Desarrollar
Tecnología Target Arquitectura Descripción  12.4.4 Realizar el Análisis Gap  12.4.5
Definir candidatos Componentes Hoja de Ruta  12.4.6 Impactos Resolver Across the
Landscape Architecture  Conducta 12.4.7 Stakeholder Formal Comentario  12.4.8
Finalizar la Arquitectura Tecnología  12.4.9 Crear Arquitectura Definición de
documento 

  Página 127 de 670 

TOGOF 9.1    
12.4.1 Selección de modelos de referencia, puntos de vista y Herramientas
Revisar y validar el conjunto de principios tecnológicos. Normalmente, éstas
formarán parte de un conjunto global de principios de arquitectura. Lineamientos
para elaborar y aplicar los principios y un conjunto de muestras de los principios
de la tecnología, se dan en la Parte III , 23. Arquitectura Principios .
Seleccionar los recursos pertinentes Arquitectura Tecnología (modelos de
referencia, patrones, etc) de la arquitectura de repositorio (véase la Parte V ,
41. Arquitectura Repositorio ), sobre la base de los impulsores del negocio, las
partes interesadas y sus preocupaciones. Seleccione los puntos de vista pertinentes
arquitectura tecnológica que permitan al arquitecto para demostrar cómo se están
abordando las preocupaciones de los interesados en la arquitectura de la
tecnología. Identificar las herramientas y las técnicas que se utilizarán para la
captura, modelado y análisis, en asociación con los puntos de vista seleccionados
apropiados.Dependiendo del grado de sofisticación requerido, éstos pueden
comprender documentos y hojas de cálculo simples, o herramientas de modelado más
sofisticadas y técnicas.
12.4.1.1 Determinar Proceso general Modeling

Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de
vista específico necesario, utilizando la herramienta o método
seleccionado.Asegúrese de que todas las preocupaciones de los interesados están
cubiertos. Si no es así, crear nuevos modelos para hacer frente a ellos, o aumentar
los modelos existentes (véase más arriba). El proceso para desarrollar una
arquitectura de tecnología incorpora los siguientes pasos:      Definir una
taxonomía de los servicios de la plataforma y componentes tecnológicos lógicas
(incluidas las normas)  Identificar lugares pertinentes en que se despliega la
tecnología  Llevar a cabo un inventario físico de la tecnología desplegada y
abstracto hasta encajar en la taxonomía  Mira las aplicaciones y de negocios
requisitos para la tecnología  ¿Es la tecnología en el lugar apto para el propósito
de cumplir con los nuevos requisitos (es decir, no se cumplen los requisitos
funcionales y no funcionales)?  o o   Refinar la taxonomía  Selección de
productos (incluidos los productos dependientes) 

Determinación de la configuración de la tecnología seleccionada  Determinar el

impacto:  o Dimensionamiento y cálculo de costos 

  Página 128 de 670 

TOGOF 9.1    
o o La planificación de capacidad  Impactos Instalación / governance / migración 

En las primeras fases de la ADM, ciertas decisiones que se toman en torno a la

granularidad de servicio y los límites del servicio tendrán implicaciones en el
componente de la tecnología y el servicio de la plataforma. Las áreas en las que
pueden verse afectadas la Arquitectura Tecnología incluirán lo siguiente: 
Performance : La granularidad del servicio tendrá un impacto en los requisitos de
servicio de la plataforma. Servicios de grano grueso contienen varias unidades de
funcionalidad potencialmente con diferentes requisitos no funcionales, por lo que
el rendimiento de plataforma debe ser considerado. Además, los servicios de
granularidad gruesa a veces puede contener más información de la que realmente se
requiere por el sistema solicitante.  Capacidad de mantenimiento : Si granularidad
servicio es demasiado gruesa, entonces la introducción de cambios en los que el
servicio se hace difícil y afecta el mantenimiento del servicio y de la plataforma
en la que se entrega.  Localización y Latencia : Servicios pueden interactuar entre
sí a través de enlaces a distancia y la comunicación entre los servicios tendrán
latencia en-construido.Dibujo límites de los servicios y el establecimiento de la
granularidad de servicio debe considerar el impacto de plataforma / ubicación de
estas comunicaciones entre los distintos servicios.  Disponibilidad : invocación
Servicio está sujeto a la red y / o deficiencia en el servicio. Así que la alta
disponibilidad de comunicación es una consideración importante en la descomposición
de servicio y la definición de un servicio granular 




Los procesos de selección del producto pueden ocurrir dentro de la fase de

Arquitectura Tecnológica donde se reutilizan los productos existentes, se está
agregando capacidad incrementales o de las decisiones de selección de productos son
un obstáculo durante la iniciación del proyecto. Cuando la selección de productos
se aparta de las normas existentes, implica un esfuerzo significativo, o tiene
impacto amplio, esta actividad debe ser marcado como una oportunidad y se dirigió a
través de las Oportunidades y fase Solutions.
12.4.1.2 Identificar Catálogos requeridos de Tecnología Building Blocks

Los catálogos son los inventarios de los principales activos de la empresa. Los
catálogos son de naturaleza jerárquica y capturan una descomposición de una entidad
metamodelo y descomposiciones en todas las entidades del modelo relacionado (por
ejemplo, servicio de plataforma -> componente de tecnología lógica ->] componente
de tecnología física). Catálogos constituyen la materia prima para el desarrollo de
matrices y diagramas, y también actúan como un recurso clave para la gestión de la
cartera de negocios y capacidad de TI. La arquitectura de tecnología debe crear
catálogos de tecnología de la siguiente manera:  Sobre la base de los catálogos
existentes en tecnología y análisis de las solicitudes realizadas en la fase de
Arquitectura de la aplicación, se recoge una lista de los productos en uso. 

  Página 129 de 670 

TOGOF 9.1    
 Si los requisitos identificados en la arquitectura de la aplicación no se cumplen
por los productos existentes, ampliar la lista de productos por los productos que
examinan disponibles en el mercado que proporcionan la funcionalidad y cumplir con
los estándares requeridos.  Clasifica los productos contra el TOGAF TRM en su caso,
la extensión del modelo según sea necesario para ajustarse a la clasificación de
los productos de la tecnología en uso.  Si los estándares de tecnología están
actualmente en vigor, se aplican estos para el catálogo de componentes de
tecnología para obtener una visión de línea de base del cumplimiento de los
estándares tecnológicos. 

 

Los siguientes catálogos deben ser considerados para el desarrollo dentro de una
Arquitectura de Tecnología:   Los estándares tecnológicos  Cartera de Tecnología 

La estructura de catálogos se basa en los atributos de las entidades metamodelo,

según se define en la Parte IV , 34. Metamodel contenido .
12.4.1.3 Identificar Matrices requeridos

Matrices muestran las relaciones básicas entre las entidades del modelo
relacionado. Las matrices son la materia prima para la elaboración de diagramas y
también actúan como un recurso clave para la evaluación del impacto. La siguiente
matriz se debe considerar para el desarrollo dentro de una Arquitectura de
Tecnología:  Matriz de Aplicación / Tecnología 

12.4.1.4 Identificar Diagramas requeridos

Diagramas presentan la información Tecnología de la Arquitectura de un conjunto de

diferentes perspectivas (puntos de vista) de acuerdo a los requisitos de las partes
interesadas. Esta actividad proporciona un vínculo entre los requisitos de
plataforma y necesidades de alojamiento, ya que puede necesitar una sola aplicación
que se encuentra físicamente en varios ambientes para apoyar el acceso local, los
ciclos de vida de desarrollo y necesidades de alojamiento. Para las principales
aplicaciones de línea de base o las plataformas de aplicación (donde múltiples
aplicaciones se alojan en la misma pila de infraestructura), producir un diagrama
de pila que muestra cómo el hardware, sistema operativo, software de
infraestructura y aplicaciones empaquetadas combinan. En su caso, ampliar los
diagramas de arquitectura de aplicaciones de distribución de software para mostrar
como un mapa de aplicaciones en la plataforma tecnológica.

  Página 130 de 670 

TOGOF 9.1    
Para cada medio ambiente, producir un diagrama lógico de la infraestructura de
hardware y software que muestra los contenidos del medio ambiente y las
comunicaciones lógicas entre los componentes. Cuando esté disponible, recopilar
información sobre la capacidad de la infraestructura desplegada. Para cada entorno,
producen un diagrama físico de la infraestructura de comunicaciones, tales como
routers, switches, firewalls, y los enlaces de red. Cuando esté disponible,
recopilar información sobre la capacidad de la infraestructura de comunicaciones.
Los siguientes diagramas deben ser considerados para el desarrollo dentro de una
Arquitectura de Tecnología:      Ambientes y zonas diagrama  Diagrama de
descomposición Plataforma  Diagrama de Procesamiento  Diagrama de Red Informática /
Hardware  Ingeniería de Comunicaciones diagrama 

La estructura de los diagramas se basa en los atributos de las entidades

metamodelo, según se define en la Parte IV , 34. Metamodel contenido .
12.4.1.5 Identificar los tipos de Requisito para ser Collected

Una vez que los catálogos de arquitectura tecnológica, matrices y diagramas han
sido desarrollados, modelado de arquitectura se completa mediante la formalización
de los requisitos de la tecnología centrada en la implementación de la arquitectura
destino. Estos requisitos pueden:   Se relacionan con el dominio de la
tecnología  Proporcionar orientaciones detalladas que se refleja en el diseño e
implementación para asegurar que la solución satisface los requisitos de
arquitectura originales 

En este paso, el arquitecto debe identificar los requisitos que deben ser cumplidos
por la arquitectura (ver Desarrollo 17.2.2 Requisitos ).
12.4.1.6 Seleccione Servicios

Las carteras de servicios son combinaciones de los servicios básicos de las

categorías de servicios en el TOGAF TRM que no entren en conflicto. La combinación
de los servicios son más probado para asegurar el apoyo a las aplicaciones. Este es
un requisito previo a la etapa posterior de la definición de la arquitectura
completamente. Los requisitos previamente identificados pueden proporcionar
información más detallada sobre:

  Página 131 de 670 

TOGOF 9.1    
   Requisitos para los elementos específicos de la organización o de las
decisiones preexistentes (según corresponda)  Elementos de organización
preexistentes e invariables (según corresponda)  Limitaciones del entorno externo
hereditarias 

Cuando los requisitos exigen definición de servicios especializados que no son

identificados en TOGAF, debe considerarse la posibilidad de cómo podrían ser
reemplazados si los servicios normalizados estarán disponibles en el futuro. Para
cada bloque de construcción, construir una descripción del servicio cartera como un
conjunto de servicios que no son contradictorias. El conjunto de servicios debe ser
analizada para asegurarse de que la funcionalidad proporcionada cumple con los
requisitos de aplicación.

12.4.2 Desarrollar Línea de Base Tecnológica Arquitectura Descripción

Desarrollar una descripción de línea de base de la arquitectura de la tecnología
existente, para apoyar la tecnología de Arquitectura de destino. El alcance y el
nivel de detalle que se ha definido dependerá de la medida en que es probable que
sean prorrogados en el Target Tecnología Arquitectura de componentes de tecnología
existentes, y de si existen descripciones arquitectónicas, como se describe en 12.2
Enfoque . Identificar los componentes básicos Arquitectura Tecnología pertinentes,
aprovechando cualquier artefacto, celebrada en la arquitectura de repositorio. Si
nada existe dentro de la arquitectura de repositorio, definir cada solicitud en
línea con el catálogo Cartera Tecnológica (véase la Parte IV , 34. Metamodel
contenido ). Comience por la conversión de la descripción del ambiente existente en
los términos de la Fundación de Arquitectura de la organización (por ejemplo, la
TRM de la Fundación Arquitectura TOGAF). Esto permitirá que el equipo de desarrollo
de la arquitectura de adquirir experiencia con el modelo y entender sus
componentes. El equipo puede ser capaz de tomar ventaja de una definición
arquitectónica anterior, pero se supone que alguna adaptación puede ser requerido
para que coincida con las técnicas de definición de arquitectura que se describen
como parte de este proceso. Otra tarea importante es establecer una lista de
preguntas clave que se pueden utilizar más adelante en el proceso de desarrollo
para medir la eficacia de la nueva arquitectura. Cuando los nuevos modelos de
arquitectura deben ser desarrollados para satisfacer las preocupaciones de las
partes interesadas, utilice los modelos identificados en el paso 1 como una guía
para la creación de nuevos contenidos arquitectura para describir la arquitectura
de línea de base.

12.4.3 Desarrollar Tecnología Target Arquitectura Descripción

Desarrollar una descripción Meta para la Tecnología de la Arquitectura, en la
medida necesaria para apoyar la Architecture Vision, Target Business Architecture,
y Target Information Systems Architecture. El alcance y el nivel de detalle que se
ha definido dependerá de la pertinencia de los elementos de la tecnología para el
logro de la arquitectura destino y de si existen descripciones arquitectónicas. En
la medida de lo posible, identificar los bloques de construcción de arquitectura de
la tecnología pertinentes, aprovechando la arquitectura de repositorio (véase la
Parte V , 41. Arquitectura del repositorio ).

  Página 132 de 670 

TOGOF 9.1    
Un proceso clave en la creación de un amplio modelo de arquitectura del sistema de
destino es la conceptualización de los bloques de construcción. Arquitectura
Bloques de Construcción (Abs) describen la funcionalidad y la forma en que pueden
ponerse en práctica sin el detalle presentado por la configuración o diseño
detallado. El método de definición de bloques de construcción, junto con algunas
pautas generales para su uso en la creación de un modelo arquitectónico, se
describe en la Parte IV , 37.3 Bloques de Construcción y de la ADM . Cuando los
nuevos modelos de arquitectura deben ser desarrollados para satisfacer las
preocupaciones de las partes interesadas, utilice los modelos identificados en el
paso 1 como una guía para la creación de nuevos contenidos arquitectura para
describir la arquitectura destino.

12.4.4 Realizar el Análisis Gap

Verifique los modelos de arquitectura para la coherencia y la precisión interna: 
   Realizar análisis de trade-off para resolver conflictos (si los hay) entre
los diferentes puntos de vista  Validar que los modelos son compatibles con los
principios, objetivos y limitaciones  Nota cambios en el punto de vista
representado en los modelos seleccionados desde el repositorio de Arquitectura, y
el documento  Modelos de arquitectura de prueba para la integridad frente a los
requisitos 

Identificar las brechas entre la línea base y de destino, utilizando la técnica de

análisis de carencias como se describe en la Parte III , 27. Análisis Gap .

12.4.5 Definir candidatos Componentes Hoja de Ruta

Después de la creación de una arquitectura de referencia, Arquitectura objetivo y
análisis de brechas, una hoja de ruta tecnológica es necesaria para dar prioridad a
las actividades en las próximas fases. Esta hoja de ruta inicial Arquitectura
Tecnología será utilizado como materia prima para apoyar definición más detallada
de un plan de trabajo interdisciplinario consolidado dentro de las Oportunidades y
fase Solutions.

12.4.6 Impactos Resolver Across la Arquitectura del Paisaje

Una vez que la Tecnología de la Arquitectura está finalizado, es necesario entender
los impactos o repercusiones más amplias. En esta etapa, otros artefactos de
arquitectura en la arquitectura del paisaje deben ser examinados para identificar:
  ¿Crea esto Arquitectura Tecnológica un impacto en las arquitecturas
preexistentes?  ¿Se han hecho los cambios recientes que impactan la Arquitectura de
Tecnología? 

  Página 133 de 670 

TOGOF 9.1    
   ¿Hay oportunidades para aprovechar el trabajo de esta Arquitectura Tecnología
en otras áreas de la organización?  ¿Impacta esta Arquitectura Tecnológica otros
proyectos (incluidos los previstos, así como los actualmente en curso)?  ¿Esto
Arquitectura Tecnología verse afectado por otros proyectos (incluidos los
previstos, así como los actualmente en curso)? 

Conducta 12.4.7 Stakeholder Formal Comentario

Compruebe la motivación original para el proyecto de la arquitectura y la
Declaración de Arquitectura de Trabajo contra la Arquitectura de Tecnología
propuesto, preguntando si es apto para el propósito de apoyar el trabajo posterior
en los otros dominios de la arquitectura. Refinar la Arquitectura de Tecnología
propuesto sólo si es necesario.

12.4.8 Finalizar la Arquitectura Tecnología  Seleccione estándares para cada

uno de los bloques de construcción, reutilizando la mayor cantidad posible de los
modelos de referencia seleccionados del repositorio Arquitectura 
  Documentar completamente cada bloque de construcción  Realizar última
comprobación cruzada de la arquitectura global contra objetivos de negocio;
documento de justificación de la construcción de las decisiones del bloque en el
documento de la arquitectura  Documento Final informe requisitos de trazabilidad 
Documento de asignación definitiva de la arquitectura dentro del Repositorio de
Arquitectura; de los bloques de construcción seleccionados, identificar las que
podrían ser re-utilizado (las prácticas de trabajo, roles y relaciones de negocio,
descripciones de puestos, etc), y publican a través del Repositorio de
Arquitectura  Finalice todos los productos de trabajo, tales como análisis de las
deficiencias 

 


12.4.9 Crear Arquitectura Definición de documento
Documentar las razones para la creación de bloquear decisiones en la definición de
documento Architecture. Preparar las secciones de tecnología de la definición de
documento de Arquitectura, que comprende una parte o todos los siguientes:    
Funcionalidad y atributos Fundamental -, incluyendo la capacidad de seguridad sin
ambigüedades semánticas y manejabilidad  Bloques de construcción dependientes con
la funcionalidad requerida y llamado interfaces  Interfaces - conjunto elegido,
suministrado (APIs, formatos de datos, protocolos, interfaces de hardware,
estándares)  Mapa de negocios / entidades organizativas y políticas 

  Página 134 de 670 

TOGOF 9.1    
En su caso, utilizar los informes y / o gráficos generados por las herramientas
para demostrar puntos de vista clave de la arquitectura de modelado. Pase el
documento para su revisión por las partes interesadas pertinentes, e incorporar la
retroalimentación.

12.5 Salidas
Los resultados de la Fase D pueden incluir, pero no se limitan a:  Las versiones
refinadas y actualizadas de los entregables de la fase Arquitectura Visión, en su
caso:  o Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20
Declaración de Arquitectura de Trabajo ), actualizado en caso necesario  Principios
tecnológicos validados, o nuevos principios tecnológicos (si se generan aquí) 

o 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o Tecnología Target
Arquitectura, Version 1.0 (detallado), incluyendo:    Componentes tecnológicos y
sus relaciones con los sistemas de información  Las plataformas tecnológicas y su
descomposición, que muestra las combinaciones de tecnología necesarios para hacer
realidad una tecnología de "pila" en particular  Entornos y localizaciones - una
agrupación de la tecnología necesaria en entornos de computación (por ejemplo,
desarrollo, producción)  Carga de procesamiento esperado y la distribución de la
carga entre los componentes de tecnología  (Red) de las comunicaciones físicas  Las
especificaciones de hardware y de red 

    o o 

Línea de Base Tecnológica de Arquitectura, Version 1.0 (detallado), si procede 

Vistas correspondiente a los puntos de vista seleccionados abordar las principales
preocupaciones de las partes interesadas 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo dichos requisitos
Arquitectura Tecnología como:  o o o Los resultados del análisis de Gap  Requisitos
de salida de las fases B y C  Requisitos tecnológicos actualizados 

  Página 135 de 670 

TOGOF 9.1    
 Componentes Arquitectura de Tecnología de la Arquitectura Roadmap (ver la Parte
IV , 36.2.7 Arquitectura Roadmap ) 

Las salidas pueden incluir algunos o todos de los siguientes:  Catálogos:  o o 

Catálogo de Normas de Tecnología  Catálogo Cartera Tecnológica 
Matrices:  o Matriz de Aplicación / Tecnología 

Diagramas:  o o o o o Ambientes y zonas diagrama  Diagrama de descomposición

Plataforma  Diagrama de Procesamiento  Diagrama de Red Informática / Hardware 
Ingeniería de Comunicaciones diagrama 

12.6 PostScript
La elección del ámbito de un ciclo de desarrollo de la arquitectura cuidadosamente
acelerará la amortización. Por el contrario, es poco probable que conduzca a la
implementación exitosa de un alcance excesivamente grande.

  Página 136 de 670 

TOGOF 9.1       

. 13 Fase E: Oportunidades y Soluciones

En este capítulo se describe el proceso de identificación de los vehículos de
reparto (proyectos, programas o portafolios) que cumplir efectivamente con la
arquitectura destino identificado en las fases anteriores.

  Figura 13‐1: Fase E: Oportunidades y Soluciones 

13.1 Objetivos
Los objetivos de la Fase E son para:  Generar la versión completa inicial de la
Hoja de Ruta de la Arquitectura, en base al análisis de las deficiencias y
candidatos Arquitectura componentes Hoja de ruta de las fases B, C y D  Determinar
si se requiere un enfoque gradual, y si es así identificar las arquitecturas de
transición que ofrecer un valor empresarial continuo 

    Página 137 de 670 

TOGOF 9.1    

13.2 Enfoque
Fase E se concentra en la forma de entregar la arquitectura. Se tiene en cuenta el
conjunto de brechas entre el Blanco y Arquitecturas de referencia en todos los
ámbitos de arquitectura, y agrupa de forma lógica se transforma en paquetes de
trabajo dentro de las carteras de la empresa. Este es un esfuerzo para construir
una hoja de ruta que mejor se adapta que se basa en los requisitos de los
interesados, la disposición de la empresa de transformación de negocios,
oportunidades y soluciones identificadas, y las limitaciones de ejecución
definidas. La clave está en centrarse en el objetivo final, mientras que la
realización de valor de negocio incrementales. Fase E es el paso inicial en la
creación de la aplicación y el Plan de Migración, que se completa en la Fase F.
Proporciona la base de una implementación bien considerado y Plan de Migración que
se integra en la cartera de la empresa en la fase F. Los siguientes cuatro
conceptos son clave para la transición de desarrollo para la entrega de una
Arquitectura de destino:     Arquitectura Roadmap  Paquetes de Trabajo 
Arquitecturas de transición  Implementación y Plan de Migración 

La Arquitectura Roadmap enumera los paquetes de trabajo individuales en una línea

de tiempo que se dará cuenta de la arquitectura destino. Cada paquete de trabajo
identifica un grupo lógico de los cambios necesarios para darse cuenta de la
arquitectura destino. Una arquitectura de transición se describe la empresa en un
estado de gran importancia arquitectónica entre la línea de base y Target
Arquitecturas. Arquitecturas de transición proporcionan arquitecturas objetivo
intermedio sobre el cual la organización puede converger. La aplicación y el Plan
de Migración ofrece un calendario de los proyectos que realizarán la arquitectura
destino.

13.3 Entradas
Esta sección define las entradas para la fase E.

13.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 
 Información sobre producto 

13.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo

(véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 

  Página 138 de 670 

TOGOF 9.1    
   Evaluación de capacidades (véase la Parte IV , 36.2.10 Evaluación de
Capacidad )  Plan de comunicación (ver la Parte IV , 36.2.12 Plan de Comunicaciones
)  Metodologías de planificación 

13.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura

Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o o o o o  Ámbito de las organizaciones afectadas  La evaluación gestacional,
lagunas, y el enfoque de resolución  Roles y responsabilidades de equipo de
arquitectura (s)  Las restricciones sobre el trabajo de arquitectura  Necesidades
presupuestarias  Gobernabilidad y estrategia de apoyo 

Los modelos de gobernanza y los marcos para:  o o o o o Planificación Ejecutiva 

Arquitectura Empresarial  Portafolio, Programa, Gestión de Proyectos  Desarrollo de
Sistemas / Ingeniería  Operaciones (Servicio) 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

  

Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de

Arquitectura de Trabajo )  Architecture Vision (véase la Parte IV , 36.2.8
Architecture Vision )  Arquitectura repositorio (véase la Parte IV , 36.2.5
Arquitectura del repositorio ), incluyendo:  o o o Bloques de construcción
reutilizables  Modelos de referencia disponibles al público  Modelos de referencia
específicos de la organización 

  Página 139 de 670 

TOGOF 9.1    
o  Normas de la Organización 
Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3
Arquitectura de definición de documento ), incluyendo:  o o o o o o o o Línea de
base de Empresas Arquitectura, Version 1.0 (detallado)  Objetivo Negocio
Arquitectura, Version 1.0 (detallado)  Arquitectura de datos de línea de base,
versión 1.0 (detallado)  Arquitectura de datos de destino, Versión 1.0 (detallado) 
Línea de base de arquitectura de aplicaciones, versión 1.0 (detallado)  Objetivo de
Arquitectura de aplicaciones, versión 1.0 (detallado)  Línea de Base Tecnológica de
Arquitectura, Version 1.0 (detallado)  Tecnología Target Arquitectura, Version 1.0
(detallado) 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo:  o o Requisitos
arquitectónicos  Los resultados del análisis de Gap (de negocios, datos,
aplicaciones, y Arquitectura de Tecnología)  Requisitos de gestión de servicios de
TI 

o  

Solicitudes de cambio para los programas y proyectos de negocios existentes (véase

la Parte IV , 36.2.11 Solicitud de cambio )  Arquitectura Candidato componentes
Hoja de ruta de las fases B, C y D 

13.4 Pasos
El nivel de detalle abordado en la Fase E dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura. El orden de los pasos en la Fase E (véase más
adelante), así como el momento en que se inician formalmente y completaron deben
adaptarse a la situación en cuestión de acuerdo con el gobierno arquitectura
establecida. Todas las actividades que se han iniciado en estos pasos deben estar
cerradas durante el paso de crear la Arquitectura Roadmap e Implementación y Plan
de Migración (ver 13.4.11 Crear la Hoja de Ruta de Arquitectura e Implementación y
Plan de Migración ). Los pasos en la Fase E son como sigue:  Principales cambios
corporativos Atributos 13.4.1 Determinar / Confirmar 

  Página 140 de 670 

TOGOF 9.1    
          13.4.2 Determinar restricciones comerciales para la
Implementación  13.4.3 Revisar y consolidar Análisis Gap Resultados de las Fases B
a D  13.4.4 Requisitos revisión consolidada en todas las funciones de negocio
relacionadas  13.4.5 Consolidar y conciliar las exigencias de interoperabilidad 
13.4.6 Afinar y Validate Dependencias  13.4.7 Confirmar la Preparación y el riesgo
para la Transformación de Negocios  13.4.8 Formular Implementación y Estrategia de
migración  13.4.9 Identificar y Grupo de Trabajo de los principales paquetes 
13.4.10 Identificar Arquitecturas de transición  13.4.11 Cree la Arquitectura
Roadmap e Implementación y Plan de Migración 

Principales cambios corporativos Atributos 13.4.1 Determinar / Confirmar

Este paso determina la forma en la arquitectura de la empresa puede ser mejor
implementado para aprovechar de la cultura empresarial de la organización. Esto
debe incluir la creación de una evaluación de la instrumentación Factor y la matriz
de la deducción (véase la Parte III , Evaluación Factor 28.1 Implementación &
Matrix Deducción ) para servir como un repositorio de implementación de la
arquitectura y las decisiones de migración. El paso también incluye la evaluación
de las capacidades de transición de las unidades de la organización involucrados
(incluyendo la cultura y habilidades) y las evaluaciones de la empresa (incluyendo
la cultura y los conjuntos de habilidades). Los factores resultantes de las
evaluaciones se deben documentar en la evaluación de la instrumentación Factor y la
matriz de deducción. Para las organizaciones donde la arquitectura de la empresa
está bien establecida, este paso puede ser simple, pero la matriz tiene que ser
establecido para que pueda ser utilizado como archivo y registro de las decisiones
tomadas.

13.4.2 Determinar restricciones comerciales para la Implementación

Identificar los factores de negocio que limitarían la secuencia de ejecución. Esto
debe incluir una revisión de los planes de negocio y estratégicos, tanto a nivel
corporativo y de línea de negocio, y una revisión de la Evaluación de Madurez de
Arquitectura Empresarial.

13.4.3 Revisar y consolidar Análisis Gap Resultados de las Fases B a D

Consolidar e integrar los resultados del análisis de brecha de los Negocios,
Sistemas de Información y Tecnología Arquitecturas (creados en las Fases B a D) y
evaluar sus implicaciones con respecto a las posibles soluciones e
interdependencias. Esto debe hacerse mediante la creación de un Lagunas
consolidados, soluciones, y la matriz de dependencias, como se muestra en la parte
III , 28,2 Brechas consolidados, soluciones, y la matriz de dependencias , lo que
permitirá la identificación de las soluciones de Bloques de Construcción (SBB) que
potencialmente podrían abordar uno o más huecos y sus asociados Bloques
Arquitectura Edificios (Abs).

  Página 141 de 670 

TOGOF 9.1    
Revise la Fase B, C, y D gap resultados de los análisis y consolidarlas en una sola
lista. Las lagunas deben ser consolidados, junto con las posibles soluciones a las
deficiencias y dependencias. Una técnica recomendada para la determinación de las
dependencias es el uso de conjuntos de puntos de vista tales como la matriz de
interacción de negocios, la matriz de funciones de Entity Data / de negocios, y la
matriz de Uso / función de relacionar completamente elementos de diferentes
dominios de la arquitectura. Racionalizar las brechas consolidados, soluciones, y
la matriz de dependencias. Una vez que todos los espacios se han documentado, re-
organizar la lista hueco y coloque los objetos similares juntos. Al agrupar los
vacíos, consulte la evaluación de la instrumentación Factor y la matriz de
deducción y revisar los factores de implementación.Cualquier factores adicionales
deben añadirse a la evaluación de la instrumentación Factor y la matriz de
deducción.

13.4.4 Requisitos revisión consolidada Across Funciones comerciales relacionadas

Evaluar las necesidades, las carencias, las soluciones y los factores para
identificar un conjunto mínimo de requisitos cuya integración en paquetes de
trabajo daría lugar a una aplicación más eficiente y eficaz de la arquitectura
destino a través de las funciones de la empresa que están participando en la
arquitectura. Esta perspectiva funcional conduce a la satisfacción de múltiples
necesidades a través de la provisión de soluciones y servicios compartidos. Las
implicaciones de esta consolidación de los requisitos con respecto a los
componentes de la arquitectura pueden ser significativos en relación con la
provisión de recursos. Por ejemplo, varios requisitos planteados por varias líneas
de negocio se pueden resolver a través de la provisión de un conjunto de servicios
de oficina y servicios de información del sistema compartida dentro de un paquete
de trabajo o proyecto.

13.4.5 Consolidar y conciliar las exigencias de interoperabilidad

Consolidar los requisitos de interoperabilidad identificados en las fases
anteriores. La Arquitectura Meta y visión Arquitecturas, así como la evaluación de
la instrumentación Factor y la matriz de deducción y Lagunas consolidados,
Soluciones, y la matriz de dependencias, se deben consolidar y crítica para
identificar las limitaciones en materia de interoperabilidad exigidos por el
conjunto potencial de las soluciones. Un resultado clave es reducir al mínimo los
conflictos de interoperabilidad, o para asegurar este tipo de conflictos se tratan
en la arquitectura. Re-Solution utilizan bloques de construcción (SBB), Commercial
Off-The-Shelf (COTS), y los proveedores de servicios de terceros normalmente
imponen requisitos de interoperabilidad que entran en conflicto. Tales conflictos
deben abordarse en la arquitectura, y los conflictos deben ser considerados en
todos los dominios de arquitectura (Negocio, Aplicaciones, Datos y Tecnología). Hay
dos enfoques básicos para los conflictos de interoperabilidad; o bien crear un
bloque de construcción que transforma o convierte entre bloques de construcción en
conflicto, o hacer un cambio a la especificación de los bloques de construcción en
conflicto.

13.4.6 Afinar y Validate Dependencias

Refinar las dependencias iniciales, asegurando que se identifican las posibles
limitaciones en la aplicación y los planes de migración. Hay varias dependencias
clave que deben tenerse en cuenta, como las dependencias en las implementaciones
existentes de servicios de oficina y servicios de información del sistema o cambios
en ellos.Dependencias deben utilizarse para determinar la

  Página 142 de 670 

TOGOF 9.1    
secuencia de la ejecución y la identificación de la coordinación necesaria. Un
estudio de las dependencias deberían agrupar actividades, la creación de una base
para proyectos que se establezcan. Examinar los proyectos pertinentes y ver si los
incrementos lógicos de entregables pueden ser identificados. Las dependencias
también ayudará a identificar cuando los incrementos señalados pueden ser
entregados. Una vez terminado, una evaluación de estas dependencias debe
documentarse como parte de la Hoja de Ruta de la Arquitectura y las arquitecturas
de transición necesarios. Abordar dependencias sirve de base para la mayor parte de
planificación de la migración.

13.4.7 Confirmar la Preparación y el riesgo para la Transformación de Negocios

Revise los resultados de la Evaluación de la preparación de transformación de
negocios realizado previamente en la Fase A y determinar su impacto en la Hoja de
Ruta de la Arquitectura y la aplicación y estrategia de migración. Es importante
identificar, clasificar y mitigar los riesgos asociados con el esfuerzo de
transformación. Los riesgos se deben documentar los boquetes consolidados,
soluciones, y la matriz de dependencias.

13.4.8 Formular Implementación y Estrategia de migración

Crear una aplicación global y estrategia de migración que guiará la implementación
de la arquitectura destino, y estructurar las arquitecturas de transición. La
primera actividad consiste en determinar un enfoque estratégico global para la
implementación de las soluciones y / o aprovechamiento de las oportunidades. Hay
tres enfoques básicos como sigue:    Greenfield: Una completamente nueva
implementación.  Revolucionario: Un cambio radical (es decir, cambiar ,
Desactivar).  Evolutiva: una estrategia de convergencia, como correr en paralelo o
en un enfoque por fases para introducir nuevas capacidades. 

A continuación, determine un enfoque para la dirección estratégica general que

tratar y mitigar los riesgos identificados en las lagunas consolidados, soluciones,
y la matriz de dependencias. Las metodologías de implementación más comunes son: 
  Victoria rápida (instantáneas)  Metas alcanzables  Método de la cadena de
valor 
Estos enfoques y las dependencias identificadas deberían ser la base para la
creación de los paquetes de trabajo. Esta actividad termina con un acuerdo sobre la
aplicación y estrategia de migración para la empresa.

13.4.9 Identificar y Grupo de Trabajo de los principales paquetes

Los principales interesados, los planificadores y los arquitectos de la empresa
deben evaluar las capacidades de negocio que faltan identificados en la
Architecture Vision y Arquitectura Target.

  Página 143 de 670 

TOGOF 9.1    
Uso de las Lagunas consolidados, soluciones, y la matriz de dependencias, junto con
la evaluación de la instrumentación Factor y la matriz de deducción, lógicamente
agrupar las diversas actividades en paquetes de trabajo. Rellene la columna
"Solución" los boquetes consolidados, Soluciones, y la matriz de dependencias para
recomendar los mecanismos de solución propuestos. Indique para cada hueco /
actividad si la solución debe orientarse hacia un nuevo desarrollo, o basarse en un
producto ya existente, y / o el uso de una solución que se puede comprar.Un sistema
existente puede resolver el requisito con mejoras de menor importancia. Para nuevos
desarrollos este es un buen momento para determinar si el trabajo debe llevarse a
cabo dentro de la empresa oa través de un contrato. Clasifique cada sistema actual
que se está considerando como:    Mainstream: Parte de un futuro sistema de
información.  Contener: Se espera que sea reemplazado o modificado en el horizonte
de planificación (próximos tres años).  Vuelva a colocar: Se sustituirá en el
horizonte de planificación. 

Apoyar a los paquetes de trabajo de nivel superior deben, a su vez descomponerse en

incrementos de entregar los incrementos de capacidad. Analizar y perfeccionar estos
paquetes de trabajo, o incrementos con respecto a sus problemas de transformación
empresarial y el enfoque estratégico de implementación. Por último, el grupo de los
paquetes de trabajo en las carteras y proyectos dentro de una cartera, teniendo en
cuenta las dependencias y el enfoque estratégico de implementación.

13.4.10 Identificar Arquitecturas de transición

Si el ámbito del cambio para implementar la Arquitectura objetivo requiere un
enfoque incremental, entonces una o más arquitecturas de transición pueden ser
necesarios.Estos proporcionan la capacidad de identificar objetivos claros a lo
largo de la hoja de ruta para la realización de la arquitectura destino. Las
arquitecturas de transición deben proporcionar un valor comercial mensurable. El
lapso de tiempo entre las arquitecturas de transición sucesivos no tiene que ser de
duración uniforme. Desarrollo de Transición Arquitecturas debe basarse en el
enfoque de implementación preferida, las Lagunas consolidados, soluciones, y la
matriz de dependencias, el listado de proyectos y carteras, así como la capacidad
de la empresa para crear y absorber el cambio. Determine donde las actividades son
difíciles, y salvo que existan razones de peso, aplicarlas después de que otras
actividades que proporcionan más fácilmente la capacidad faltante.

13.4.11 Cree la Arquitectura Roadmap e Implementación y Plan de Migración

Consolidar los paquetes de trabajo y transición Arquitecturas en la Hoja de Ruta de
la Arquitectura, Versión 0.1, que describe una línea de tiempo de la progresión de
la Arquitectura de referencia para la arquitectura destino. La línea de tiempo
informa a la aplicación y el Plan de Migración. La Arquitectura Roadmap enmarca la
planificación de la migración en la Fase F. Identificado Transición Arquitecturas y
paquetes de trabajo deben tener un claro conjunto de resultados. La

  Página 144 de 670 
TOGOF 9.1    
Hoja de Ruta de la Arquitectura debe demostrar cómo la selección y el calendario de
transición Arquitecturas y paquetes de trabajo se da cuenta de la arquitectura
destino. El detalle de la Arquitectura Roadmap, Versión 0.1 debe expresarse en un
nivel de detalle similar a la definición de documento Arquitectura desarrollado en
las fases B, C y D. Cuando se requiere el detalle adicional significativa antes de
la implementación de la arquitectura es probable que la transición a un nivel
diferente . Ver Parte III , 19.Aplicando la iteración de la ADM y 20. Aplicando la
ADM a través de la Arquitectura del Paisaje de técnicas para manejar la iteración y
los diferentes niveles de detalle. La aplicación y el Plan de Migración deben
demostrar la actividad necesaria para darse cuenta de la Arquitectura Roadmap. La
aplicación y el Plan de Migración es la base de la planificación de la migración en
la Fase F. El detalle de la aplicación y el Plan de Migración, Versión 0.1 debe
estar alineado con el detalle de la hoja de ruta de la Arquitectura y ser
suficiente para identificar los proyectos necesarios y los recursos necesarios para
realizar la hoja de ruta. Al crear la aplicación y el Plan de Migración hay muchos
enfoques a tener en cuenta, como una secuencia basada en datos, donde los sistemas
de aplicación que crean datos se aplican en primer lugar, a continuación, las
aplicaciones que procesan los datos. Se requiere una comprensión clara de las
dependencias y del ciclo de vida de SBB en el lugar para una aplicación efectiva y
el Plan de Migración. Finalmente, actualice la Architecture Vision, Arquitectura
Definición de documento, y Arquitectura Requisitos Especificación con ningún
resultado pertinentes adicionales de esta fase.

13.5 Salidas
Los resultados de la Fase E pueden incluir, pero no se limitan a:  Versión
refinada y actualizada de los entregables de la fase Arquitectura Visión, en su
caso, entre ellos:  o Architecture Vision, incluyendo la definición de los tipos y
grados de interoperabilidad  Declaración de Arquitectura de trabajo (véase la Parte
IV , 36.2.20 Declaración de Arquitectura de Trabajo ), actualizado en caso
necesario 

o 

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o o o o Línea de base de
Empresas Arquitectura, versión 1.0 actualiza si es necesario  Objetivo Negocio
Arquitectura, versión 1.0 actualiza si es necesario  Arquitectura de datos de línea
de base, versión 1.0 actualiza si es necesario  Arquitectura de datos de destino,
versión 1.0 actualiza si es necesario  Línea de base de arquitectura de
aplicaciones, la versión 1.0 actualiza si es necesario 

  Página 145 de 670 

TOGOF 9.1    
o o Objetivo de Arquitectura de aplicaciones, la versión 1.0 actualiza si es
necesario  Línea de Base Tecnológica de la Arquitectura, la versión 1.0 actualiza
si es necesario  Tecnología Target Arquitectura, versión 1.0 actualiza si es
necesario  Arquitectura de transición, el número y el alcance que sea necesario 
Vistas correspondiente a los puntos de vista seleccionados abordar las principales
preocupaciones de las partes interesadas 

o o o 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo:  o Brechas consolidados,
soluciones y Dependencias de Evaluación 

Evaluaciones de capacidad, entre ellos:  o o Evaluación de la capacidad del

negocio  Evaluación de Capacidad de TI 

Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap ), incluyendo: 

o Cartera Paquete de trabajo:           o Trabajo descripción del paquete
(nombre, descripción, objetivos)  Requisitos funcionales  Dependencias  Relación
con la oportunidad  Relación a la Arquitectura de definición de documento y
Arquitectura Especificación de Requisitos  Relación con cualesquiera incrementos de
capacidad  El valor del negocio  Evaluación Factor Implementación y Matrix
Deducción  Impacto 

Identificación de Transición Arquitecturas, en su caso, incluyendo:   Relación a

la Arquitectura de definición de documento 

Recomendaciones para la implementación:    Criterios de valoración de la

eficacia  Riesgos y problemas 

  Página 146 de 670 

TOGOF 9.1    
  Bloques de Solución de construcción (SBB)  Implementación y Plan de Migración,
Versión 0.1, incluyendo:  o Implementación y Estrategia de migración 

Las salidas pueden incluir algunos o todos de los siguientes:  Diagramas:  o o

Diagrama de Contexto del Proyecto  Diagrama de Beneficios 

  Página 147 de 670 

TOGOF 9.1       

14 Fase F:. Planeamiento de migración

Este capítulo se ocupa de la planificación de la migración; es decir, cómo pasar de
la línea de base para las arquitecturas objetivo al finalizar una implementación
detallada y Plan de Migración.

  Figura 14‐1: Fase F: planeamiento de migración 

14.1 Objetivos
Los objetivos de la Fase F son para:   Finalizar la Arquitectura Hoja de Ruta y
la aplicación de soporte y Plan de Migración  Asegúrese de que la aplicación y el
Plan de Migración se coordina con el enfoque de la empresa para la gestión y la
implementación de cambios en la cartera de cambio general de la empresa  Asegúrese
de que el valor para el negocio y el costo de los paquetes de trabajo y transición
Arquitecturas Se entiende por las partes interesadas clave 

  Página 148 de 670 
TOGOF 9.1    

14.2 Enfoque
El objetivo de la Fase F es la creación de un Plan de Implementación y Migración,
en cooperación con la cartera y los directores de proyectos. Fase E proporciona una
hoja de ruta de la Arquitectura incompleta e Implementación y Plan de Migración que
se ocupan de la Solicitud de Arquitectura Obra. En la Fase F esta hoja de ruta y la
aplicación y el Plan de Migración se integran con otras actividades de cambio de la
empresa. Las actividades incluyen la evaluación de las dependencias, los costos y
beneficios de los diversos proyectos de migración en el contexto de de la empresa
cualquier otra actividad. La Hoja de Ruta de la Arquitectura, Versión 0.1 e
Implementación y Plan Migración, Versión 0.1 de la Fase E formarán la base de la
aplicación final y plan de migración que incluya la cartera y el detalle a nivel de
proyecto. El ciclo de desarrollo de la arquitectura debe entonces ser completado y
lecciones aprendidas documentadas para permitir la mejora continua del proceso.

14.3 Entradas
Esta sección define las entradas para la fase F.

14.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio )  14.3.2 Entradas
para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte
IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 
  Evaluación de capacidades (véase la Parte IV , 36.2.10 Evaluación de
Capacidad )  Plan de comunicación (ver la Parte IV , 36.2.12 Plan de Comunicaciones
) 

14.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura

Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o o o o o  Ámbito de las organizaciones afectadas  La evaluación gestacional,
lagunas, y el enfoque de resolución  Roles y responsabilidades de equipo de
arquitectura (s)  Las restricciones sobre el trabajo de arquitectura  Necesidades
presupuestarias  Gobernabilidad y estrategia de apoyo 

Los modelos de gobernanza y los marcos para:  o Planificación Ejecutiva 

  Página 149 de 670 

TOGOF 9.1    
o o o o  Arquitectura Empresarial  Portafolio, Programa, Gestión de Proyectos 
Desarrollo de Sistemas / Ingeniería  Operaciones (Servicio) 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

  

Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de

Arquitectura de Trabajo )  Architecture Vision (véase la Parte IV , 36.2.8
Architecture Vision )  Arquitectura repositorio (véase la Parte IV , 36.2.5
Arquitectura del repositorio ), incluyendo:  o o o o Bloques de construcción
reutilizables  Modelos de referencia disponibles al público  Modelos de referencia
específicos de la organización  Normas de la Organización 


Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o o o o o o o o o Línea de
base de Empresas Arquitectura, Version 1.0 (detallado)  Objetivo Negocio
Arquitectura, Version 1.0 (detallado)  Arquitectura de datos de línea de base,
versión 1.0 (detallado)  Arquitectura de datos de destino, Versión 1.0 (detallado) 
Línea de base de arquitectura de aplicaciones, versión 1.0 (detallado)  Objetivo de
Arquitectura de aplicaciones, versión 1.0 (detallado)  Línea de Base Tecnológica de
Arquitectura, Version 1.0 (detallado)  Tecnología Target Arquitectura, Version 1.0
(detallado)  Arquitecturas de transición, si los hay 

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos ), incluyendo: 

  Página 150 de 670 

TOGOF 9.1    
o o Requisitos arquitectónicos  Los resultados del análisis de Gap (de negocios,
datos, aplicaciones, y Arquitectura de Tecnología)  Requisitos de gestión de
servicios de TI 

o  

Solicitudes de cambio para los programas y proyectos de negocios existentes (véase

la Parte IV , 36.2.11 Solicitud de cambio )  Arquitectura Roadmap, Versión 0.1
(véase la Parte IV , 36.2.7 Arquitectura Roadmap ), incluyendo:  o o o
Identificación de los paquetes de trabajo  Identificación de transición
Arquitecturas  Evaluación Factor Implementación y Matrix Deducción 

Evaluación de capacidades (véase la Parte IV , Evaluación 36.2.10 Capability ),

incluyendo:  o o Evaluación de la capacidad del negocio  Evaluación de Capacidad de
TI 

Implementación y Plan de Migración, Versión 0.1 (véase la Parte IV , 36.2.14

Implementación y Plan de Migración ), incluyendo la aplicación de alto nivel y la
estrategia de migración 

14.4 Pasos
El nivel de detalle abordado en la Fase F dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura. El orden de los pasos en la Fase F (véase más
adelante), así como el momento en que se inician formalmente y completaron deben
adaptarse a la situación en cuestión de acuerdo con el gobierno arquitectura
establecida. Todas las actividades que se han iniciado en estos pasos deben estar
cerradas durante las clases completar el ciclo de desarrollo de la arquitectura y
documentar paso aprendido (ver 14.4.7 completar el ciclo de desarrollo de la
arquitectura y de documentar las lecciones aprendidas ). Los pasos en la Fase F son
como sigue:    14.4.1 Confirmar Management Framework Interacciones para la
Aplicación y el Plan de Migración  14.4.2 Asignar un valor de negocio para cada
paquete de trabajo  14.4.3 Requisitos de Recursos de Estimación, Proyecto
sincronizaciones, y la disponibilidad / vehículo Entrega 
  Página 151 de 670 

TOGOF 9.1    
    14.4.4 Dar prioridad a los proyectos de migración a través de la
realización de una evaluación costo / beneficio y Validación de Riesgos  14.4.5
Confirmar Arquitectura Roadmap y Actualización Arquitectura Definición de
documento  14.4.6 Generar la aplicación y el Plan de Migración  14.4.7 Completar el
Ciclo de Desarrollo de Arquitectura y documentar las lecciones aprendidas 

14.4.1 Confirmar Management Framework Interacciones para la Aplicación y el Plan de

Migración
Este paso es sobre la coordinación de la aplicación y el Plan de Migración con los
marcos de gestión dentro de la organización. En general, existen cuatro marcos de
gestión que tienen que trabajar en estrecha colaboración para la Aplicación y el
Plan de Migración para tener éxito:   Planificación de Negocios que concibe,
dirige y provee los recursos para todas las actividades necesarias para lograr los
objetivos de negocio / resultados concretos.  Arquitectura Empresarial que
estructura y da contexto a todas las actividades de la empresa la entrega de los
resultados del negocio de concreto principalmente, pero no exclusivamente, en el
dominio de TI.  Portafolio / Gestión de Proyectos que coordina, diseña y construye
los sistemas de negocio que ofrecen los resultados de negocio concretos.  Gestión
de Operaciones , que integra, opera y mantiene las prestaciones que ofrecen los
resultados de negocio concretos. 

 

La aplicación y el Plan de Migración tendrán un impacto en los resultados de cada

uno de estos marcos y en consecuencia se tiene que reflejar en ellos. En el curso
de este paso, entender los marcos dentro de la organización y asegurar que estos
planes están coordinados y se insertan (en forma de resumen) dentro de los planes
de cada uno de estos marcos. El resultado de este paso muy posible que la
aplicación y el Plan de Migración podría ser parte de un plan diferente producido
por otro de los marcos con la participación de la arquitectura empresarial.

14.4.2 Asignar un valor de negocio para cada paquete de trabajo

Establecer y asignar valores de negocio para todos los paquetes de trabajo. La
intención es establecer primero lo constituye el valor del negocio dentro de la
organización, ¿cómo se puede medir el valor, y luego aplicar esto a cada uno de los
proyectos y los incrementos de los proyectos. Si la planificación de capacidades
basada se ha utilizado, a continuación, los valores de negocios asociados con las
capacidades y los incrementos de capacidad asociados deben ser utilizados para
asignar los valores de negocio para entregar. Hay varias cuestiones a abordar en
esta actividad:

  Página 152 de 670 

TOGOF 9.1    
   Criterios de evaluación de rendimiento son utilizados por la cartera y la
capacidad de los gestores para aprobar y supervisar el progreso de la
transformación de la arquitectura.  Retorno de la Inversión Criterios tienen que
ser detallado y firmado por las distintas partes interesadas ejecutivos.  Valor de
negocio tiene que ser definido, así como las técnicas, tales como la cadena de
valor, que se van a utilizar para ilustrar el papel en el logro de los resultados
de negocio tangibles. El valor del negocio será utilizada por la cartera y la
capacidad de los gestores para asignar recursos y, en los casos en los que hay
recortes, el valor del negocio en relación con el retorno de la inversión se puede
utilizar para determinar si un esfuerzo avanza, se retrasa o se cancela.  Factores
Críticos de Éxito (CSF) se deben establecer para definir el éxito de un proyecto
y / o incremento de proyectos. Esto proporcionará los administradores y ejecutores
con un medidor de lo que constituye una implementación exitosa.  Medidas de
Efectividad (MOE) a menudo son los criterios de rendimiento y muchas empresas los
incluyen en los MCA. Cuando se les trata de forma discreta, debe ser clara en
cuanto a cómo estos criterios se deberán agrupar.  Fit Estratégico basado en la
arquitectura de la empresa en general (todos los niveles) será el factor clave para
permitir a la aprobación de cualquier nuevo proyecto o iniciativa y para la
determinación del valor de cualquier entrega. 

Utilice los paquetes de trabajo como base de la identificación de proyectos que

estarán en la aplicación y el Plan de Migración. Los proyectos identificados se
desarrollarán plenamente en otras etapas de la Fase F. Los proyectos, y los
incrementos de los proyectos, puede requerir el ajuste de la definición de
documento Hoja de Ruta de Arquitectura y Arquitectura. Los riesgos deben ser
asignados a los proyectos y los incrementos de los proyectos mediante la agregación
de los riesgos identificados en las lagunas consolidados, soluciones, y la Matriz
de dependencias (de la Fase E). Estimar el valor de negocio para cada proyecto que
utilice la técnica de evaluación de valor de negocio (véase la Parte III , 28,5
Business Value Técnica de Evaluación ).

14.4.3 Requisitos de Recursos de Estimación, Proyecto sincronizaciones, y la

disponibilidad / vehículo Entrega
Este paso determina los recursos y tiempos requeridos para cada proyecto y sus
incrementos y proporciona las previsiones iniciales de costos. Los costes deben
desglosarse en capital (para crear la capacidad) y las operaciones y mantenimiento
(para ejecutar y sostener la capacidad). Las oportunidades deben ser identificados,
donde los costos asociados con la entrega de nuevos y / o mejores capacidades
pueden ser compensados por el desmantelamiento de los sistemas existentes. Asignar
los recursos necesarios para cada actividad y agregarlos al incremento de los
proyectos y de los proyectos.

  Página 153 de 670 

TOGOF 9.1    
14.4.4 Dar prioridad a los proyectos de migración a través de la realización de una
evaluación costo / beneficio y Validación de Riesgos
Dar prioridad a los proyectos por parte de la determinación de su valor comercial
contra el costo de la entrega de ellos. El enfoque consiste en determinar en primer
lugar, lo más claramente posible, el beneficio neto de todos los dispositivos SBB
entregados por los proyectos, a continuación, compruebe que los riesgos se han
mitigado y factor in Posteriormente efectivamente, la intención es ganar el
requisito de consenso para crear una lista priorizada de proyectos que servirán de
base para la asignación de recursos. Es importante descubrir toda costa, y para
asegurar que los tomadores de decisiones a entender el beneficio neto en el tiempo.
Revise los riesgos para asegurar que los riesgos para las entregas del proyecto se
han mitigado tanto como sea posible. La lista de proyectos se actualiza con los
comentarios relacionados con el riesgo. Haga que los grupos de interés de acuerdo
en un orden de prioridad de los proyectos. Criterios de importancia utilizarán
elementos identificados en la creación del proyecto de Arquitectura Roadmap en la
Fase E, así como los relativos a las agendas de los grupos de interés individuales.
Tenga en cuenta que es posible que un proyecto para ganar una alta prioridad si
proporciona un entregable crítico en el camino a algunos grandes beneficios,
incluso si el beneficio inmediato del proyecto en sí es pequeño. Formalmente
revisar la evaluación de riesgos y revisarlo si es necesario garantizar que exista
una plena comprensión del riesgo residual asociado con el establecimiento de
prioridades y la línea de financiación proyectada.

14.4.5 Confirmar Arquitectura Roadmap y Actualización Arquitectura Definición de

documento
Actualización de la Hoja de Ruta de la Arquitectura incluidas las arquitecturas de
transición. Revisar el trabajo hasta la fecha para evaluar lo que los lapsos de
tiempo entre la arquitectura de transición deben ser, teniendo en cuenta los
incrementos en el valor del negocio y la capacidad y otros factores, como el
riesgo. Una vez que los incrementos de capacidad se han finalizado, la
consolidación de los entregables por proyecto. Esto resultará en una Arquitectura
Hoja de Ruta revisada. Esto es necesario con el fin de coordinar el desarrollo de
varias instancias simultáneas de las diversas arquitecturas. Una transición
Arquitectura Estado Tabla Evolution (ver Parte III , 28,4 Transición Arquitectura
Estado Tabla Evolution ) se puede utilizar para mostrar el estado propuesto de las
arquitecturas de dominio en distintos niveles de detalle. Si el enfoque de
ejecución ha cambiado como resultado de la confirmación de los incrementos de
aplicación, actualice la definición de documento Architecture. Esto puede incluir
la asignación de los objetivos del proyecto y la alineación de los proyectos y sus
entregables con las arquitecturas de transición para crear una definición de
Arquitectura Incrementos tabla (ver la Parte III , 28,3 Arquitectura Definición
Tabla Incrementos ).

  Página 154 de 670 

TOGOF 9.1    
14.4.6 Generar la aplicación y el Plan de Migración
Generar la aplicación completada y el Plan de Migración. Muchos de los detalles
para el plan ya ha sido reunida y este paso trae todo junto usando la planificación
aceptado y técnicas de gestión. Esto debería incluir la integración de todos los
proyectos y actividades, así como las dependencias y los efectos del cambio en un
plan de proyecto. Cualquier Arquitecturas transición actuarán como hitos de la
cartera. Todas las dependencias externas deben ser capturados y se incluyen, y la
disponibilidad general de los recursos evaluados. Los planes del proyecto pueden
ser incluidos dentro de la aplicación y el Plan de Migración.

14.4.7 Completar el Ciclo de Desarrollo de Arquitectura y documentar las lecciones

aprendidas
Este paso transiciones de gobierno a partir del desarrollo de la arquitectura a la
realización de la arquitectura. Si el vencimiento de las órdenes de Arquitectura de
capacidad, un Modelo de Gobierno La implementación puede ser producido (véase la
Parte IV , 36.2.15 Implementación Modelo de Gobierno ). Las lecciones aprendidas
durante el desarrollo de la arquitectura deben estar documentados y capturados por
el proceso de gobernanza adecuada en la Fase H como insumos para la gestión de la
capacidad de Arquitectura. El detalle de la hoja de ruta de la Arquitectura y la
aplicación y el Plan de Migración debe expresarse en un nivel de detalle similar a
la definición de documento Arquitectura desarrollada en las fases B, C y D. Cuando
se requiera el detalle adicional significativo para la próxima fase de la
arquitectura es probable la transición a un nivel diferente.Dependiendo del nivel
de la arquitectura seleccionada y ejecución y el Plan de Migración puede ser
necesario para repetir otro ciclo de ADM en un nivel más bajo de detalle.Ver Parte
III , 19. Aplicando la iteración de la ADM y 20. Aplicando la ADM a través de la
Arquitectura del Paisaje de técnicas para manejar la iteración y los diferentes
niveles de detalle.
14.5 Salidas
Los resultados de la Fase F pueden incluir, pero no se limitan a:  Implementación
y Plan de Migración, Versión 1.0 (véase la Parte IV , 36.2.14 Implementación y Plan
de Migración ), incluyendo:  o o Implementación y Estrategia de migración 
Proyectos y Distribución de la cartera de la aplicación:     Asignación de los
paquetes de trabajo para proyectar y de cartera  Capacidades entregados por
proyectos  Relación a la Arquitectura de destino y cualquier Arquitecturas de
transición 

  Página 155 de 670 

TOGOF 9.1    
  o Hitos y calendario  Estructura de desglose del trabajo 

Cartas del proyecto (opcional):        Paquetes de trabajo relacionados  El

valor del negocio  Riesgo, problemas, hipótesis, dependencias  Las necesidades de
recursos y los costes  Beneficios de la migración  Estimación de los gastos de las
opciones de migración 

Finalizada Arquitectura definición de documento (ver la Parte IV , 36.2.3

Arquitectura de definición de documento ), incluyendo:  o Arquitecturas transición
finalizados, en su caso 

     

Arquitectura Requisitos Finalizada la especificación (véase la Parte IV , 36.2.6

Arquitectura especificación de requisitos )  Finalizado Arquitectura Roadmap (véase
la Parte IV , 36.2.7 Arquitectura Roadmap )  Reutilizables Arquitectura Bloques de
construcción (véase la Parte IV , 36.2.1 Arquitectura Building Blocks )  Las
solicitudes de Arquitectura de trabajo (ver la Parte IV , 36.2.17 Solicitud de
Arquitectura de Trabajo ) para una nueva iteración del ciclo de ADM (si los hay) 
Implementación Modelo de Gobierno (si las hubiera) (véase la Parte IV , 36.2.15
Implementación Modelo de Gobierno )  Solicitudes de cambio para la capacidad de la
arquitectura que surge de las lecciones aprendidas 

  Página 156 de 670 

TOGOF 9.1       

. 15 Fase G: Gobernanza Aplicación

Este capítulo proporciona una supervisión de arquitectura de la aplicación.

  Figura 15‐1: Fase G: Gobernanza Aplicación 

15.1 Objetivos
Los objetivos de la Fase G son para:   Asegurar la conformidad con la
arquitectura destino por los proyectos de implementación  Realizar funciones de
arquitectura de gobernanza adecuadas para la solución y cualquier arquitectura de
solicitudes de cambio de aplicación impulsada 

15.2 Enfoque
Es aquí que toda la información para la gestión exitosa de los diversos proyectos
de implementación se unió. Tenga en cuenta que, en paralelo con la fase G, está la
realización de un proceso de desarrollo organizacional específica, donde ocurre el
desarrollo real.
  Página 157 de 670 

TOGOF 9.1    
Para habilitar la rápida obtención de valor para el negocio y los beneficios, y
para minimizar el riesgo en el programa de transformación y la migración, el
enfoque preferido es el despliegue de la arquitectura destino como una serie de
transiciones. Cada transición representa un paso más hacia el objetivo, y cada uno
ofrece un beneficio empresarial en su propio derecho. Por lo tanto, el enfoque
global de la Fase G es:      Establecer un programa de aplicación que permita
la entrega de las arquitecturas de transición acordado para la implementación
durante la fase de planeamiento de migración  Adoptar un programa de implementación
por fases que refleja las prioridades de la empresa contenidos en la Hoja de Ruta
de la Arquitectura  Siga estándar de la organización para las empresas,
informática, arquitectura y gobierno  Utilice establecido enfoque de gestión de
cartera / programa de la organización, siempre que exista  Definir un marco de
operaciones para garantizar una larga vida útil de la solución implementada 

Fase G establece la conexión entre la arquitectura y la organización de la

ejecución, a través del Contrato de Arquitectura. Detalles del proyecto se
desarrollan, entre ellas:      Nombre, descripción y objetivos  Ámbito de
aplicación, prestaciones y limitaciones  Medidas de efectividad  Los criterios de
aceptación  Riesgos y problemas 

Gobernabilidad ejecución está estrechamente vinculada a la gobernanza arquitectura

general, que se discute en la Parte VII , 50. Arquitectura de Gobierno . Un aspecto
clave de la Fase G es garantizar el cumplimiento de la arquitectura definida (s),
no sólo por los proyectos de implementación, sino también por otros proyectos en
curso dentro de la empresa. Las consideraciones que participan en este se explican
en detalle en la Parte VII , 48. Arquitectura de Cumplimiento .

15.3 Entradas
Esta sección define las entradas para la fase G.

15.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 

  Página 158 de 670 

TOGOF 9.1    
15.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo
(véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 
 Evaluación de capacidades (véase la Parte IV , 36.2.10 Evaluación de Capacidad ) 

15.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura

Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o o o o o  Ámbito de las organizaciones afectadas  La evaluación gestacional,
lagunas, y el enfoque de resolución  Roles y responsabilidades de equipo de
arquitectura (s)  Las restricciones sobre el trabajo de arquitectura  Necesidades
presupuestarias  Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 
  

Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de

Arquitectura de Trabajo )  Architecture Vision (véase la Parte IV , 36.2.8
Architecture Vision )  Arquitectura repositorio (véase la Parte IV , 36.2.5
Arquitectura del repositorio ), incluyendo:  o o o o Bloques de construcción
reutilizables  Modelos de referencia disponibles al público  Modelos de referencia
específicos de la organización  Normas de la Organización 

 

Arquitectura de definición de documento (ver la Parte IV , 36.2.3 Arquitectura de

definición de documento )  Arquitectura Especificación de Requisitos (véase la
Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo:  o
Requisitos arquitectónicos 

  Página 159 de 670 

TOGOF 9.1    
o      Los resultados del análisis de Gap (de negocios, datos, aplicaciones y
arquitecturas tecnológicas) 

Arquitectura Roadmap (véase la Parte IV , 36.2.7 Arquitectura Roadmap )  Gobierno

Modelo de Implementación (véase la Parte IV , 36.2.15 Implementación Modelo de
Gobierno )  Arquitectura Contrato (estándar) (véase la Parte VII , 49. Contratos de
Arquitectura )  Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17
Solicitud de Arquitectura Trabajo ) identificados durante las fases E y F 
Implementación y Plan de Migración (véase la Parte IV , 36.2.14 Implementación y
Plan de Migración ) 

15.4 Pasos
El nivel de detalle abordado en Fase G dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura. El orden de los pasos en la Fase G (véase más
adelante), así como el momento en que se inician formalmente y completaron deben
adaptarse a la situación en cuestión de acuerdo con el gobierno arquitectura
establecida. Los pasos en la Fase G son como sigue:       15.4.1 Confirmar
alcance y las prioridades para la implementación con la Gestión del Desarrollo 
15.4.2 Identificar recursos de implementación y Habilidades  15.4.3 Guía de
desarrollo de la implementación de soluciones  15.4.4 Realizar revisiones
Arquitectura Empresarial de Cumplimiento  15.4.5 Implementación de Negocios y
Operaciones de TI  15.4.6 Realizar Revisión Post-Implementación y Cierre la
Implementación 

15.4.1 Confirmar alcance y las prioridades para la implementación con la Gestión

del Desarrollo  Revise los resultados de planificación de migración y producir
recomendaciones sobre la implementación 
    Identificar las prioridades de arquitectura empresarial para los equipos de
desarrollo  Identificar los problemas de implementación y hacer recomendaciones 
Identificar los bloques de construcción para la sustitución, actualización, etc 
Realizar análisis de las deficiencias en la arquitectura institucional y de
soluciones 

  Página 160 de 670 

TOGOF 9.1    
Las lagunas en el marco de soluciones empresariales existentes necesitan ser
identificadas y las soluciones de Bloques de Construcción específicos (SBB)
necesarios para llenar estos vacíos serán identificados por los arquitectos de
soluciones. Estos dispositivos SBB pueden tener un uno-a-uno o muchos-a-uno la
relación con los proyectos. Los arquitectos de soluciones tienen que definir
exactamente cómo se hará. Es posible que haya otros proyectos que trabajan en estas
mismas capacidades y los arquitectos soluciones deben garantizar que puedan
aprovechar mejor el valor de estas inversiones.  Producir un informe de análisis
de brecha 

15.4.2 Identificar recursos de implementación y Habilidades

Los recursos del proyecto se incluyen los recursos de desarrollo que tendrán que
ser educados en los entregables de arquitectura empresarial en general y
expectativas de los proyectos de desarrollo y de implementación específicos. Las
siguientes consideraciones deben ser abordados en este paso:  Identificar los
métodos de desarrollo de sistemas necesarios para el desarrollo de soluciones 
Nota:  Hay una serie de métodos y herramientas disponibles para los equipos de
proyectos de desarrollo de sistemas. El método ideal debería ser capaz de
interoperar con las salidas de la arquitectura; por ejemplo, generar código desde
artefactos arquitectura entregadas hasta la fecha. Esto se podría lograr mediante
el uso de lenguajes de modelado utilizadas para el desarrollo de la arquitectura de
la empresa que pueden ser capturadas como insumos para los sistemas de herramientas
de desarrollo y por lo tanto reducen el costo de desarrollo de soluciones.  

Asegúrese de que el método de desarrollo de sistemas permite retroalimentación al

equipo de arquitectura en diseños 

15.4.3 Guía de desarrollo de la implementación de soluciones  Formular

recomendación proyecto 
Para cada proyecto de implementación y despliegue independiente, haga lo siguiente:
o o Alcance del documento de proyecto individual en el análisis del impacto 
Documentar las necesidades estratégicas (desde el punto de vista arquitectónico) en
el análisis de impacto  Las solicitudes de cambio de documento (como el soporte
para una interfaz estándar) en el análisis de impacto  Reglas del documento para la
conformidad en el análisis del impacto  Requisitos de la línea de tiempo del
documento de hoja de ruta en materia de análisis de impacto 

o o

  Página 161 de 670 

TOGOF 9.1    
 Arquitectura de documento de contrato  o       Obtenga la firma de
desarrollo de las organizaciones y el patrocinio de toda la organización 

Directorio Enterprise Update Continuum y el repositorio de soluciones  Guía de

desarrollo de negocio y de TI modelos operativos para los servicios  Proporcionar
los requisitos de servicio derivadas de la arquitectura empresarial  Definición
Guía de negocios y de TI requisitos operativos  Llevar a cabo análisis de brechas
entre la arquitectura de soluciones y operaciones  Producir Plan de Implementación 

15.4.4 Realizar revisiones Arquitectura Empresarial de Cumplimiento  Revise la

gobernanza aplicación en curso y la arquitectura de cumplimiento para cada bloque
de construcción 
  Una vez puestos en desarrollo  Cerrar desarrollo parte de los proyectos de
implementación 

15.4.5 Implementación de Negocios y Operaciones de TI  Llevar a cabo los

proyectos de implementación, incluyendo: servicios de TI la implementación del
parto; aplicación la prestación de servicios empresariales; el desarrollo de
competencias y la implementación de capacitación; publicación de documentación
comunicaciones 
 Publicar nuevas arquitecturas de referencia para la arquitectura de repositorio y
actualizar otros repositorios afectadas, tales como tiendas de gestión de la
configuración operativa 

15.4.6 Realizar Revisión Post-Implementación y Cierre la Implementación  Una

vez puestos en ejecución 
 Publicar comentarios y proyectos cercanos 

Cierre de Fase G será cuando las soluciones están totalmente desplegados una vez.

15.5 Salidas
Las salidas de Fase G pueden incluir, pero no se limitan a:    Arquitectura
contrato (firmado) (véase la Parte VII , 49. Arquitectura de Contratos ), como se
recomienda en las arquitecturas implementadas compatible con arquitectura  Las
evaluaciones de cumplimiento (ver la Parte IV , Evaluación del Cumplimiento 36.2.13
)  Solicitudes de cambio (véase la Parte IV , 36.2.11 Solicitud de cambio ) 

  Página 162 de 670 

TOGOF 9.1    
 Soluciones de arquitectura compatible desplegado incluyendo:  o El sistema
implementado una arquitectura compatible 

Nota:  El sistema implementado es en realidad una salida del proceso de desarrollo.

Sin embargo, dada la importancia de esta salida, se indica aquí como una salida de
la ADM. La participación directa del personal de la arquitectura en la aplicación
variará de acuerdo con la política de la organización, como se describe en la Parte
VII, 50. Arquitectura de Gobierno .  o o o o o o o

Poblado Repositorio Arquitectura  Recomendaciones Arquitectura de cumplimiento y

dispensas  Recomendaciones sobre los requisitos de prestación de servicios 
Recomendaciones sobre las medidas de rendimiento  Acuerdos de Nivel de Servicio
(SLAs)  Architecture Vision, posterior a la ejecución de actualización 
Arquitectura Definición de documento, posterior a la ejecución de actualización 
Modelos operativos de TI y de negocios de la solución implementada 

  Página 163 de 670 

TOGOF 9.1       

16 Fase H:. Gestión Arquitectura Cambio

Este capítulo se centra en el establecimiento de procedimientos para la gestión del
cambio a la nueva arquitectura.

  Figura 16‐1: Fase H: Gestión Arquitectura Cambio 

16.1 Objetivos
Los objetivos de la Fase H son:    Asegúrese de que se mantiene la arquitectura
del ciclo de vida  Asegúrese de que se ejecute el Marco de Gobierno Arquitectura 
Asegúrese de que la capacidad de la empresa Arquitectura cumple los requisitos
actuales 
  Página 164 de 670 

TOGOF 9.1      

16.2 Enfoque
El objetivo de un proceso de gestión del cambio arquitectura es garantizar que la
arquitectura alcanza su valor de negocio objetivo original. Esto incluye la gestión
de cambios en la arquitectura de una manera coherente y con arquitectura. Este
proceso suele asegurar el seguimiento continuo de las cosas tales como las
solicitudes de gobierno, los nuevos desarrollos en la tecnología y los cambios en
el entorno empresarial. Cuando se identifican los cambios, la gestión del cambio
determinará si ha de iniciar formalmente un nuevo ciclo de la evolución de la
arquitectura. Además, el proceso de gestión de cambios de arquitectura tiene como
objetivo establecer y apoyar la arquitectura de la empresa implementa como una
arquitectura dinámica; es decir, uno que tiene la flexibilidad para evolucionar
rápidamente en respuesta a cambios en el entorno de la tecnología y de negocios.
Monitoreo de crecimiento del negocio y la decadencia es un aspecto crítico de esta
fase. El uso de la arquitectura de la empresa es la parte más importante del ciclo
de desarrollo de la arquitectura. Con demasiada frecuencia, el negocio se ha
quedado con una arquitectura empresarial que trabaja para la organización de ayer,
pero no puede dar vuelta la capacidad suficiente para satisfacer las necesidades de
la empresa de hoy y del mañana. En muchos casos, la arquitectura sigue en forma,
pero las soluciones que subyacen en ellas no puede, y se requieren algunos cambios.
El arquitecto de la empresa tiene que ser consciente de estos requisitos de cambio
y lo considera una parte esencial de la renovación constante de la arquitectura.
Medición y recomendaciones para la planificación de la capacidad es un aspecto
clave de esta fase. Mientras que la arquitectura se ha construido para ofrecer una
arquitectura de negocios en estado estacionario con capacidad acordada durante el
ciclo de vida de esta arquitectura de la empresa, el crecimiento o la disminución
en el uso es necesario evaluar continuamente para asegurar que se consigue el
máximo valor empresarial. Por ejemplo, algunos Solution Architectures no se prestan
para ser escalable en un factor grande digamos 10 - o soluciones alternativas puede
ser más económico cuando se escala hacia arriba. Mientras que las especificaciones
de la arquitectura no pueden cambiar, las soluciones o su contexto operativo pueden
cambiar. Si la gestión y la información de rendimiento se ha incorporado en los
productos de trabajo a través de las fases anteriores, a continuación, esta fase se
trata de garantizar la efectividad de los mismos. Si es necesario que haya
supervisión o informes adicionales, entonces esta fase se encargará de los cambios.
El proceso de gestión del valor y el cambio, una vez establecido, determinará: 
Las circunstancias en que la arquitectura de la empresa, o parte de ella, se le
permitirá cambiar después de la implementación, y el proceso por el cual que va a
pasar 

  Página 165 de 670 

TOGOF 9.1    
 Las circunstancias bajo las cuales se iniciará de nuevo el ciclo de desarrollo de
arquitectura para desarrollar una nueva arquitectura 

La gestión del cambio arquitectura proceso está muy estrechamente relacionado con
los procesos de gobernanza de la arquitectura de la empresa, y para la gestión del
Contrato de Arquitectura (véase la Parte VII , 49. Contratos de Arquitectura )
entre la función de la arquitectura y los usuarios de negocio de la empresa. En la
Fase H es fundamental que el órgano de gobierno a establecer criterios para juzgar
si una solicitud de cambio garantiza sólo una actualización arquitectura o si
amerita iniciar un nuevo ciclo del Método de Desarrollo de Arquitectura (ADM). Es
especialmente importante evitar la "elegancia progresiva", y el órgano de gobierno
debe continuar para buscar cambios que se relacionan directamente con el valor del
negocio. Un informe de Cumplimiento Arquitectura debe indicar si el cambio es
compatible con la arquitectura actual. Si es no conforme, una exención puede
concederse con fundamento válido. Si el cambio tiene un alto impacto en la
arquitectura, a continuación, una estrategia para gestionar su impacto debe ser
definido. Directrices para el establecimiento de estos criterios son difíciles de
establecer, ya que muchas empresas aceptan el riesgo de manera diferente, pero como
el ADM seejerce, el nivel de madurez del órgano de gobierno van a mejorar, y los
criterios se pondrán de manifiesto para necesidades específicas.

16.2.1 Drivers for Change

El objetivo principal para el desarrollo de la arquitectura de la empresa hasta
ahora ha sido la dirección estratégica y la arquitectura de arriba hacia abajo y la
generación de proyectos para lograr las capacidades empresariales. Sin embargo, la
arquitectura de la empresa no opera en el vacío. Por lo general, una
infraestructura y negocio existente que ya está proporcionando valor. Hay también,
probablemente, los impulsores del cambio que a menudo son de abajo hacia arriba, en
base a la modificación de la infraestructura existente para mejorar la
funcionalidad. Arquitectura empresarial cambia este paradigma de un enfoque
estratégico de arriba hacia abajo en un grado, aunque la entrega de los incrementos
hace que la ecuación más compleja. Hay tres formas de cambiar la infraestructura
existente que tiene que estar integrados:    De arriba hacia abajo Cambio
estratégico, dirigido a mejorar o crear nuevas capacidades (capital)  Cambios de
abajo hacia arriba para corregir o mejorar la capacidad (operación y mantenimiento)
para la infraestructura bajo la gestión de operaciones  Experiencias con los
incrementos de los proyectos entregados previamente en el cuidado de la gestión de
operaciones, pero aún siendo entregada por los proyectos en curso 

Gobierno tendrá que manejar la coordinación de estas solicitudes para el cambio,

además es necesario que haya un proceso de lecciones aprendidas para que si hay
problemas con los incrementos entregados recientemente por resolver y los cambios
realizados en el Arquitecturas Target está diseñado y planificado.

  Página 166 de 670 

TOGOF 9.1    
Un lecciones aprendidas proceso asegura que los errores se hacen una vez y no se
repiten. Ellos pueden venir de cualquier parte y cualquier persona y para abarcar
cualquier aspecto de la arquitectura de la empresa a todos los niveles
(estratégico, definición de arquitectura empresarial, la transición, o proyecto). A
menudo, una lección relacionada con la arquitectura de la empresa puede ser un
resultado indirecto de una lección aprendida en la organización en otro lugar. La
Junta de Arquitectura (véase la Parte VII , 47. Architecture Board ) evalúa y
aprueba las solicitudes para el Cambio (RFC). Un RFC es típicamente en respuesta a
problemas conocidos, pero también puede incluir mejoras. Un reto para el Consejo de
Arquitectura de la manipulación de un RFC es para determinar si se debe aprobar o
si un proyecto en una Arquitectura Transición resolverá el problema. Cuando la
evaluación de proyecto o solución de ajuste en la arquitectura, también puede ser
el caso cuando una solución innovadora o RFC impulsa un cambio en la arquitectura.
Además, hay muchos conductores relacionados con la tecnología para la arquitectura
solicitudes de cambio. Por ejemplo:     Informes Nueva tecnología  La reducción
de costes de gestión de activos  Retirada Tecnología  Las iniciativas de
estandarización 

Este tipo de solicitud de cambio es normalmente manejable principalmente a través

de la gestión de cambios de una empresa y los procesos de gobernanza de la
arquitectura. Además, hay factores de negocio para el cambio de arquitectura,
incluyendo:      Business-as-usual desarrollos  Excepciones empresariales 
Innovaciones empresariales  Innovaciones tecnológicas de negocios  El cambio
estratégico 

Este tipo de solicitud de cambio a menudo resulta en una re-desarrollo completo de

la arquitectura, o al menos en una iteración de una parte del ciclo de desarrollo
de la arquitectura, como se explica a continuación.

16.2.2 Arquitectura Empresarial Proceso de Gestión del Cambio

El proceso de gestión de cambios de arquitectura empresarial necesita determinar
cómo los cambios han de ser administrado, qué técnicas se deben aplicar, y qué
metodologías utilizadas. El proceso también tiene una función de filtro que
determina qué fases del proceso de desarrollo de la

  Página 167 de 670 

TOGOF 9.1    
arquitectura se ven afectados por los requisitos. Por ejemplo, los cambios que
afectan sólo a la migración pueden ser de interés en las fases de desarrollo de la
arquitectura. Hay muchos enfoques válidos para el cambio de gestión, y de diversas
técnicas y metodologías que se pueden utilizar para gestionar el cambio de gestión;
por ejemplo, los métodos de gestión de proyectos como PRINCE2, métodos de gestión
de servicios, tales como ITIL, los métodos de consultoría de gestión, como
catalizador, y muchos otros. Una empresa que ya cuenta con una gestión de cambio
proceso en su lugar en un campo distinto de la arquitectura (por ejemplo, en el
desarrollo de sistemas o la gestión de proyectos) puede muy bien ser capaz de
adaptarlo para su uso en relación con la arquitectura. A continuación se describe
un enfoque para la gestión del cambio, dirigido especialmente a la ayuda de una
arquitectura empresarial dinámico, que puede ser considerado para su uso si hay un
proceso similar existe en la actualidad. El enfoque se basa en la clasificación de
cambios en la arquitectura requeridos en una de tres categorías:   Simplificación
del cambio : Un cambio simplificación normalmente se puede manejar a través de
técnicas de gestión del cambio.  Cambio incremental : Un cambio incremental puede
ser susceptible de ser manejado a través de técnicas de gestión del cambio, o puede
requerir una reestructuración de parcial, dependiendo de la naturaleza del cambio
(ver 16.2.3 Directrices para Mantenimiento frente Arquitectura Rediseño de
directrices).  Re-arquitectura de cambio : Un cambio re-arquitectura de requiere
poner toda la arquitectura a través del ciclo de desarrollo de la arquitectura de
nuevo. 

Otra forma de ver estas tres opciones es decir que un cambio de la simplificación
de la arquitectura es a menudo impulsada por una necesidad de reducir la inversión;
un cambio incremental es impulsado por un requisito para obtener un valor adicional
de la inversión existente; y un cambio re-arquitectura de es impulsado por una
necesidad de aumentar la inversión con el fin de crear un nuevo valor para la
explotación. Para determinar si un cambio es la simplificación, incremental o una
reestructuración de, se realizarán las siguientes actividades:

1. Registro de todos los eventos que puedan afectar a la arquitectura  2. La

asignación de recursos y la gestión de las tareas de arquitectura  3. El proceso o
función responsable de recursos de arquitectura tiene que hacer balance de lo que
se debe hacer  4. Evaluación de los impactos 
16.2.3 Directrices para Mantenimiento frente Arquitectura Rediseño
Una buena regla empírica es:

  Página 168 de 670 
TOGOF 9.1    
   Si los efectos del cambio de dos o más grupos de interés, entonces es
probable que requiera un rediseño arquitectura y el reingreso a la ADM.  Si los
impactos del cambio sólo una de las partes interesadas, entonces es más probable
que sea un candidato para la gestión del cambio.  Si el cambio se puede permitir
bajo una dispensación, entonces es más probable que sea un candidato para la
gestión del cambio. 

Por ejemplo:  Si el impacto es significativo para la estrategia de negocio,

entonces puede haber una necesidad de rehacer toda la arquitectura de la empresa -
por lo tanto un enfoque de una reestructuración de.  Si una nueva tecnología o
normas surgen, entonces puede haber una necesidad de actualizar la arquitectura de
Tecnología, pero no toda la arquitectura de la empresa - por lo tanto un cambio
incremental.  Si el cambio se encuentra en un nivel de infraestructura - por
ejemplo, diez sistemas reducidos o modificados a un sistema - esto puede no cambiar
la arquitectura por encima de la capa física, sino que va a cambiar la descripción
de línea de base de la arquitectura de la tecnología. Esto sería un cambio
simplificación manejado a través de técnicas de gestión del cambio. 

En particular, un ciclo de refresco (re-Architecting parcial o completa) puede ser

necesario si:    La Fundación de Arquitectura tiene que ser re-alineado con la
estrategia de negocio.  Se requiere un cambio sustancial a los componentes y las
directrices para el uso en el despliegue de la arquitectura.  Normas significativas
utilizadas en la arquitectura del producto se cambian los cuales tienen un impacto
significativo para el usuario final; por ejemplo, los cambios regulatorios. 

Si hay una necesidad de un ciclo de refresco, a continuación, una nueva solicitud

de Arquitectura de trabajo deberá expedirla (para pasar a otro ciclo).

16.3 Entradas
Esta sección define las entradas para la Fase H.

16.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia

Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio )  16.3.2 Entradas
para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte
IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 

  Página 169 de 670 

TOGOF 9.1    
16.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura
Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de
Arquitectura ), incluyendo: 
o o o o o o  Ámbito de las organizaciones afectadas  La evaluación gestacional,
lagunas, y el enfoque de resolución  Roles y responsabilidades de equipo de
arquitectura (s)  Las restricciones sobre el trabajo de arquitectura  Necesidades
presupuestarias  Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 
  

Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de

Arquitectura de Trabajo )  Architecture Vision (véase la Parte IV , 36.2.8
Architecture Vision )  Arquitectura repositorio (véase la Parte IV , 36.2.5
Arquitectura del repositorio ), incluyendo:  o o o o Bloques de construcción
reutilizables  Modelos de referencia disponibles al público  Modelos de referencia
específicos de la organización  Normas de la Organización 

 

Arquitectura de definición de documento (ver la Parte IV , 36.2.3 Arquitectura de

definición de documento )  Arquitectura Especificación de Requisitos (véase la
Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo:  o Los
resultados del análisis de Gap (de negocios, datos, aplicaciones y arquitecturas
tecnológicas)  Requisitos arquitectónicos 

o  

Arquitectura Roadmap (véase la Parte IV , 36.2.7 Arquitectura Roadmap )  Solicitud

de cambio (véase la Parte IV , 36.2.11 Solicitud de cambio ), - los cambios
tecnológicos: 

  Página 170 de 670 

TOGOF 9.1    
o o o o  Informes Nueva tecnología  Iniciativas de reducción de costes de gestión
de activos  Informes de abstinencia Tecnología  Las iniciativas de estandarización 

Solicitud de cambio (véase la Parte IV , 36.2.11 Solicitud de cambio ), - los

cambios del negocio:  o o o o o Evolución de los negocios  Excepciones
empresariales  Innovaciones empresariales  Innovaciones tecnológicas de negocios 
Desarrollos del cambio estratégico 

    

Solicitud de cambio (véase la Parte IV , 36.2.11 Solicitud de cambio ), - a partir

de las lecciones aprendidas  Gobierno Modelo de Implementación (véase la Parte IV ,
36.2.15 Implementación Modelo de Gobierno )  Arquitectura contrato (firmado) (véase
la Parte VII , 49. Contratos de Arquitectura )  Las evaluaciones de cumplimiento
(ver la Parte IV , Evaluación del Cumplimiento 36.2.13 )  Implementación y Plan de
Migración (véase la Parte IV , 36.2.14 Implementación y Plan de Migración ) 

16.4 Pasos
El nivel de detalle abordado en la Fase H dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura. El orden de los pasos en la Fase H (véase más
adelante), así como el momento en que se inician formalmente y completaron deben
adaptarse a la situación en cuestión de acuerdo con el gobierno arquitectura
establecida. Los pasos en la Fase H son los siguientes:     16.4.1 Establecer
proceso de realización del valor  16.4.2 Para desplegar Herramientas de Monitoreo 
16.4.3 Administrar Riesgos  16.4.4 Proporcionar Análisis de Arquitectura de Gestión
del Cambio 

  Página 171 de 670 

TOGOF 9.1    
   16.4.5 Desarrollar cambiar los requisitos para cumplir los objetivos de
rendimiento  16.4.6 Administrar Proceso Gobernanza  16.4.7 Activar el proceso para
implementar el cambio 

16.4.1 Establecer proceso de realización del valor

Influencia proyectos empresariales de explotación de la arquitectura de la empresa
para la realización de valor (resultados).

16.4.2 Para desplegar Herramientas de Monitoreo

Herramientas de garantizar un seguimiento se implementan y aplican para permitir lo
siguiente:        Monitorear los cambios tecnológicos que podrían afectar la
arquitectura de línea de base  Vigilar los cambios del negocio que podrían afectar
la arquitectura de línea de base  Seguimiento de valor de negocios; por ejemplo, el
método de evaluación de la inversión para determinar las métricas de valor para los
objetivos de negocio  Monitorear la empresa Arquitectura Capability Maturity 
Seguimiento y evaluación de los programas de gestión de activos  Seguimiento de las
actuaciones de calidad de servicio y el uso  Determinar y localizar las necesidades
de continuidad de negocio 

16.4.3 Administrar Riesgos

Gestione la arquitectura riesgos de la empresa y proporcionar recomendaciones para
la estrategia de TI.

16.4.4 Proporcionar Análisis de Arquitectura de Gestión del Cambio

Proporcionar un análisis de la gestión de cambios de arquitectura:    Analizar
el rendimiento  Llevar a cabo revisiones de desempeño de la empresa con la
arquitectura de gestión de servicios  Evaluar las solicitudes de cambio y
presentación de informes para garantizar que se cumplan la realización valor
esperado y el Acuerdo de Nivel de Servicio (SLA) expectativas de los clientes 
Llevar a cabo un análisis de las deficiencias de la actuación de la arquitectura de
la empresa 

  Página 172 de 670 

TOGOF 9.1    
 Asegúrese de solicitudes de administración de cambios se adhieren a la
gobernabilidad de arquitectura empresarial y el marco 

16.4.5 Desarrollar cambiar los requisitos para cumplir los objetivos de rendimiento
Hacer recomendaciones sobre requisitos de cambio para cumplir los objetivos y el
desarrollo de condiciones de actuar de rendimiento.

16.4.6 Administrar Proceso Gobernanza

Gestione proceso de gobernanza y un marco para la arquitectura:   Organizar
reuniones de Junta de Arquitectura (u otro Consejo de Gobierno)  Celebrar una
reunión de la Junta de Arquitectura con el objetivo de la reunión para decidir
sobre los cambios de manejo (la tecnología y los negocios y dispensaciones) 

16.4.7 Activar el proceso para implementar el cambio

Activar el proceso de arquitectura para implementar el cambio:   Producir una
nueva Solicitud de Arquitectura Trabajo y solicitar a la inversión  Asegurar los
cambios implementados en esta fase son capturados y documentados en el Repositorio
de Arquitectura 

16.5 Salidas
Los resultados de la Fase H pueden incluir, pero no se limitan a:      
Actualizaciones Arquitectura (para cambios de mantenimiento)  Modificaciones del
marco de arquitectura y los principios (por cambios de mantenimiento)  Nueva
Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17 Solicitud de
Arquitectura Trabajo ), para pasar a otro ciclo (para cambios importantes) 
Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de
Arquitectura de Trabajo ), actualizado en caso necesario  Arquitectura contrato
(véase la Parte IV , 49. Contratos de Arquitectura ), actualizado en caso
necesario  Evaluaciones de cumplimiento (véase la Parte IV , Evaluación del
Cumplimiento 36.2.13 ), actualizado en caso necesario 

  Página 173 de 670 

TOGOF 9.1       

17. Arquitectura ADM Gestión de Requisitos

Este capítulo se centra en el proceso de gestión de requisitos de arquitectura en
todo el ADM.

  Gestión de ADM Arquitectura Requisitos: Figura 17‐1 

17.1 Objetivos
Los objetivos de la fase de gestión de requisitos son los siguientes:   
Asegúrese de que el proceso de gestión de requisitos es sostenido y funciona para
todas las fases pertinentes de ADM  Gestione requisitos de arquitectura
identificadas durante cualquier ejecución del ciclo ADM o una fase  Asegúrese de
que los requisitos de arquitectura relevantes están disponibles para uso de cada
fase que se ejecuta la fase 

17.2 Enfoque

  Página 174 de 670 

TOGOF 9.1    
17.2.1 general
Como se indica por el círculo "Gestión de Requisitos" en el centro de la gráfica
ADM, el ADM es impulsado continuamente por el proceso de gestión de requisitos. Es
importante señalar que el círculo de Gestión de Requisitos denota no un conjunto
estático de requisitos, sino un proceso dinámico mediante el cual se identifican
los requisitos de arquitectura de la empresa y los cambios posteriores de los
mismos que, almacenan, y se introducen en y fuera de las fases de ADM pertinentes,
y También entre los ciclos de la ADM. La capacidad para hacer frente a cambios en
las necesidades es crucial. La arquitectura es una actividad que por sus ofertas
propia naturaleza con la incertidumbre y el cambio - la "zona gris" entre lo que
los actores aspiran y qué se puede especificar y diseñado como una solución.
Requisitos de arquitectura son, por tanto, siempre sujeto a cambios en la práctica.
Por otra parte, la arquitectura a menudo se ocupa de los conductores y las
limitaciones, muchas de las cuales por su propia naturaleza están más allá del
control de la empresa (cambio de las condiciones del mercado, las nuevas
legislaciones, etc), y que puede producir cambios en los requisitos de forma
imprevista. Tenga en cuenta también que el proceso de gestión de requisitos en sí
no dispone de, dirección, o priorizar los requisitos; esto se hace dentro de la
fase correspondiente de la ADM. No es más que el proceso de gestión de requisitos
en todo el ADM general. Se recomienda que un repositorio de requisitos (véase la
Parte IV , 41.6.1 Requisitos Repositorio ) se utiliza para registrar y administrar
todos los requisitos de arquitectura. A diferencia de la Especificación de
Requerimientos Arquitectura, y los requisitos de evaluación de impacto, los
requisitos de depósito puede contener la información de múltiples ciclos de ADM.
Desarrollo 17.2.2 Requisitos
Los primeros requisitos de alto nivel se articulan como parte de la arquitectura de
la Visión, generado mediante el escenario de negocios o una técnica similar. Cada
fase de la ADM, de preliminar a la fase H, debe seleccionar los requisitos
aprobados para esa fase que se celebró en el repositorio y Arquitectura Requisitos
de Especificación de Requisitos. A la finalización de la fase de la situación de
estos requisitos tiene que ser actualizado. Durante la ejecución de fase nuevas
necesidades generadas para el futuro trabajo de arquitectura en el marco de la
Declaración de la corriente de Arquitectura de Trabajo han de estar documentados
dentro de la arquitectura de Especificación de Requisitos, y las nuevas necesidades
que se encuentran fuera del ámbito de aplicación de la Declaración de la corriente
de Arquitectura Trabajo deben introducirse a los requisitos de depósito para la
gestión a través del proceso de gestión de requisitos. En cada fase correspondiente
de la ADM el arquitecto debe identificar los tipos de requisitos que deben ser
cumplidos por la arquitectura, incluyendo aplicable:   Requisitos funcionales 
Requisitos no funcionales 

En la definición de los requisitos del arquitecto debería tener en cuenta:

  Página 175 de 670 

TOGOF 9.1    
       Supuestos para requisitos  Restricciones para los requisitos 
Principios de dominio específico que impulsan requisitos  Las políticas que afectan
los requisitos  Normas que deben cumplir los requisitos  Directrices de la
Organización para los requisitos  Las especificaciones para los requisitos 

Entregas en fases posteriores de ADM también contienen asignaciones a los

requisitos de diseño, y también pueden generar nuevos tipos de requisitos (por
ejemplo, los requisitos de conformidad, tiempo ventanas para la implementación).

17.2.3 Recursos
El mundo de la ingeniería de requisitos es rico con las recomendaciones emergentes
y procesos para la gestión de requisitos. TOGAF no exige ni recomienda ningún
proceso o herramienta específica; que se limita a establecer lo que es un proceso
de gestión de requisitos efectiva debe lograr (es decir, los "requisitos de los
requisitos", si se quiere).
17.2.3.1 Escenarios empresariales

Una técnica efectiva que se describe en sí mismo es TOGAF escenarios de negocio,

que son una técnica apropiada y útil para descubrir y documentar los requerimientos
del negocio, y para articular una visión de la Arquitectura, que responda a esas
necesidades. Escenarios de negocio, se describen en detalle en la Parte III ,
26.Escenarios empresariales y objetivos de negocio .
17.2.3.2 Requisitos Herramientas

No es un gran y creciente número de Commercial Off-The-Shelf (COTS) herramientas

disponibles para el apoyo de la gestión de requisitos, aunque no necesariamente
diseñado para requisitos de arquitectura. El sitio web Volere tiene una lista muy
útil de las principales herramientas de requisitos (ver www.volere.co.uk /
tools.htm ).

17.3 Entradas
Las entradas a la fase de gestión de requisitos son:   Un poblado Arquitectura
repositorio (véase la Parte IV , 36.2.5 Arquitectura del repositorio ),  Modelo de
organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de
Organización de Empresa de Arquitectura ), incluyendo:  o Ámbito de las
organizaciones afectadas 

  Página 176 de 670 

TOGOF 9.1    
o o o o o  La evaluación gestacional, lagunas, y el enfoque de resolución  Roles y
responsabilidades de equipo de arquitectura (s)  Las restricciones sobre el trabajo
de arquitectura  Necesidades presupuestarias  Gobernabilidad y estrategia de apoyo 

Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:  o o o Método de arquitectura adaptada  Adaptado
contenido de la arquitectura (entregables y artefactos)  Herramientas de configurar
e implementar 

   

Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de

Arquitectura de Trabajo )  Architecture Vision (véase la Parte IV , 36.2.8
Architecture Vision )  Requisitos de arquitectura, que pueblan una especificación
de Arquitectura requisitos (ver la Parte IV , 36.2.6 Arquitectura especificación de
requisitos )  Requisitos de Evaluación de Impacto (véase la Parte IV , 36.2.18
Requisitos de Evaluación de Impacto ) 

17.4 Pasos
Los pasos en la fase de gestión de requisitos se describen en la siguiente tabla:
Pasos de Gestión de Requisitos Paso 1 Paso Requisitos de referencia: 2 a. Determine
las prioridades que surgen de la fase actual de ADM  b. Confirme los interesados
buy-in a las prioridades resultantes  c. Registros Requisitos prioridades y lugar
en ADM Fase Pasos Identificar los requisitos / documentos - utilizar escenarios de
negocios, o una técnica análoga

  Página 177 de 670 

TOGOF 9.1    
Requisitos Repositorio  Paso Monitorear los requisitos básicos 3 Paso 4

Identificar requisitos modificados: a. Retire o re-evaluar las prioridades  b.

Añadir requisitos y reevaluar las prioridades  c. Modificar los requisitos
existentes 

Paso Identificar requisitos modificados y prioridades de 5 registros: a.

Identificar requisitos modificados y garantizar las exigencias son priorizados por
el arquitecto (s) responsables de la fase actual, y por las partes interesadas  b.
Registre las nuevas prioridades  c. Asegúrese de que los conflictos son
identificados y gestionados a través de las fases de una conclusión exitosa y
priorización  d. Generar Requisitos Declaración de Impacto (ver 36.2.18 Requisitos
de Evaluación de Impacto ) para dirigir el equipo de arquitectura  Notas

Requisitos modificados pueden entrar a través de cualquier vía. Para asegurarse de

que los requisitos se evalúan adecuadamente y se priorizan, este proceso necesita
dirigir las fases de ADM y registrar las decisiones relacionadas con los
requisitos.  La fase de gestión de requisitos es necesario para determinar la
satisfacción de las partes interesadas con las decisiones. Donde hay
insatisfacción, la fase sigue siendo responsable de garantizar la resolución de los
problemas y determinar los próximos pasos.  a. Evaluar el impacto de las nuevas
exigencias de la fase actual (activo)  b. Evaluar el impacto de las nuevas
exigencias en las fases anteriores  . c Determinar si se debe implementar el
cambio, o diferir el ciclo ADM después; si la

Paso 6

  Página 178 de 670 

TOGOF 9.1    
decisión es implementar, evaluar Cronograma de implantación de gestión del cambio 
d. Declaración de Impacto Requisitos Edición, Versión n 1   Paso 7 Implementar los
requisitos derivados de la Fase H La arquitectura se puede cambiar a través de su
ciclo de vida por la fase de Arquitectura de Gestión del Cambio (Fase H). El
proceso de gestión de requisitos asegura que las nuevas o cambiantes necesidades
que se derivan de la Fase H son manejadas en consecuencia. Paso Actualizar el
repositorio Requisitos con información 8 relativa a los cambios solicitados,
incluyendo opiniones de los interesados afectados Paso Implementar el cambio en la
actual fase 9 Paso Evaluar y revisar el análisis de las deficiencias en las 10
fases anteriores El análisis de las deficiencias en las fases de ADM B a D
identifica las brechas entre la línea de base y Target Arquitecturas. Ciertos tipos
de brecha puede dar lugar a necesidades brecha. El ADM se describen dos tipos de
brecha:

Algo que está presente en la línea de base, pero no en el de destino (es decir,
eliminado - por accidente o diseño)  Algo no está en la línea de base, pero
presente en el objetivo (es decir, nuevo) 

Un "requisito brecha" es cualquier cosa que ha sido eliminado por accidente, por lo
que requiere un cambio en la arquitectura destino. Si el análisis de la brecha
genera requisitos brecha, este paso se asegurará de que sus destinatarios,
documentados y registrados en el Repositorio de Requisitos, y que la Arquitectura
objetivo se revisó en consecuencia.

  Página 179 de 670 

TOGOF 9.1    

17.5 Salidas
Los resultados del proceso de gestión de requisitos pueden incluir, pero no se
limitan a:   Evaluación de Impacto 36.2.18 Requisitos  36.2.6 Arquitectura
Especificación de Requisitos , si es necesario 

El Repositorio de Requisitos se actualizará como parte de la fase de gestión de

requisitos y debe contener toda la información de los requisitos. Cuando surgen
nuevas necesidades, o las existentes se cambian, se genera una Declaración de
Impacto Requisitos, que identifica las fases de la ADM de que es necesario revisar
el hacer frente a los cambios. La declaración continúa a través de diversas
iteraciones hasta que la versión final, que incluye todas las implicaciones de los
requisitos (por ejemplo, costos, plazos, y métricas de negocio) en el desarrollo de
la arquitectura. Una vez que los requisitos para el ciclo actual de ADM se han
finalizado entonces la Arquitectura especificación de requisitos debe ser
actualizada.

  Página 180 de 670 

TOGOF 9.1                

PARTE III Directrices y Técnicas  de ADM

     

  Página 181 de 670 

TOGOF 9.1    

18. Introducción
Este capítulo proporciona una visión general de los contenidos de la parte III .

18.1 Pautas para adaptar el proceso de ADM

El proceso de Arquitectura Método de Desarrollo (ADM) se pueden adaptar para hacer
frente a una serie de diferentes escenarios de uso, incluyendo diferentes estilos
de proceso (por ejemplo, el uso de la iteración) y también las arquitecturas
especializadas específicas (como la seguridad). Directrices incluidos dentro de
esta parte de TOGAF son los siguientes:  La aplicación de la iteración a la ADM
(véase 19. Aplicando la iteración a la ADM ) discute el concepto de iteración y
muestra las posibles estrategias para la aplicación de conceptos iterativos a la
ADM.  La aplicación de la ADM a través de la arquitectura del paisaje (ver 20.
Aplicando la ADM a través de la Arquitectura del Paisaje ) discute los diferentes
tipos de participación de arquitectura que pueden ocurrir en diferentes niveles de
la empresa. Esta sección también discute a continuación, cómo el proceso de ADM se
puede enfocar para soportar diferentes tipos de compromiso.  Arquitectura de
Seguridad y la ADM (véase 21. Arquitectura de Seguridad y el ADM ) proporciona una
visión general de las consideraciones específicas de seguridad que deben tenerse en
cuenta durante las diferentes fases de la ADM.  Usando TOGAF para definir y
Gobierno SOAs (ver 22. Uso TOGAF para definir y Gobierno SOAs ) muestra cómo los
conceptos de SOA pueden ser apoyadas por el marco TOGAF y las consideraciones SOA
específicos para las diferentes fases de la ADM. 

18.2 Técnicas para el Desarrollo de la Arquitectura

Las siguientes técnicas se describen en la Parte III: Directrices y Técnicas de ADM
para apoyar tareas específicas dentro de la ADM:  Arquitectura Principios (ver 23
Arquitectura Principios. ) - los principios para la utilización y el despliegue de
los recursos de TI en toda la empresa - Describe cómo desarrollar el conjunto de
normas y directrices para la arquitectura se desarrolla en general.  Gestión de los
interesados (véase 24. Gestión de las partes interesadas ) describe la
Administración de los interesados, una disciplina importante que los profesionales
de la arquitectura de éxito puede utilizar para ganar apoyo para sus proyectos. 
Arquitectura Patrones (ver 25. Arquitectura Patrones ) proporciona orientación
sobre el uso de patrones de arquitectura.  Escenarios empresariales (véase 26.
Escenarios empresariales y objetivos de la empresa ) se describe la técnica de
escenarios empresariales, un método para derivar los requisitos de negocio para la
arquitectura y los requisitos técnicos implicados. 


 

  Página 182 de 670 

TOGOF 9.1    
 Análisis de Vacíos (ver 27. Análisis Gap ) describe la técnica conocida como
análisis de brechas. Es ampliamente utilizado en el TOGAF ADM para validar una
arquitectura que se está desarrollando.  Técnicas de Planificación Migraciones (ver
Técnicas de Planificación 28. Migración ) describe una serie de técnicas para
apoyar la planificación de la migración en las fases E y F.  Requisitos de
interoperabilidad (véase 29. Requisitos de interoperabilidad ) describe una técnica
para determinar los requisitos de interoperabilidad.  Evaluación de la preparación
de transformación de negocios (véase 30. Empresas Evaluación de la preparación de
Transformación ) describe una técnica para la identificación de problemas de
transformación empresarial.  Gestión del Riesgo (ver 31. Gestión de Riesgos )
describe una técnica para la gestión de riesgos durante un proyecto de
transformación de la arquitectura / negocio.  Capacidad basada en Planificación
(ver 32. Planificación de Capacidad basada ) describe la técnica de la
planificación basada en la capacidad. 

 

 

18.3 Uso de TOGAF con diferentes estilos arquitectónicos

TOGAF está diseñado para ser flexible y puede ser utilizado con diversos estilos
arquitectónicos. Esta parte de TOGAF incluye dos capítulos que pretenden ser
ejemplos útiles.   Arquitectura de Seguridad y la ADM (véase 21. Arquitectura de
Seguridad y el ADM )  Usando TOGAF para definir y Gobierno SOAs (ver 22. Uso TOGAF
para definir y Gobierno SOAs ) 

Los estilos arquitectónicos se diferencian en términos de enfoque, la forma, las

técnicas, los materiales, el asunto y el período de tiempo. Algunos estilos pueden
ser considerados como de moda, otros se centraron en aspectos particulares de la
arquitectura empresarial. TOGAF es un marco genérico y destinado a ser utilizado en
una amplia variedad de entornos. Es un marco flexible y extensible que se puede
adaptar fácilmente a un número de estilos arquitectónicos. Arquitectura del Paisaje
de una organización se puede esperar para contener obra de arquitectura que se
desarrolla en diversos estilos arquitectónicos. TOGAF asegura que las necesidades
de cada grupo de interés se abordan adecuadamente en el contexto de otras partes
interesadas y la Arquitectura de Referencia. Al usar TOGAF para apoyar un estilo
arquitectónico específico el profesional debe tener en cuenta la combinación de
características distintivas en que se realiza o se expresa la arquitectura. Como
primera medida, los rasgos distintivos de un estilo deben ser identificados. Por
ejemplo, la definición de Open Group para SOA identifica las siguientes
características distintivas:  Se basa en el diseño de los servicios - que reflejan
las actividades empresariales del mundo real - que comprenden la empresa (o entre
empresas) los procesos de negocio. 

  Página 183 de 670 

TOGOF 9.1    
 Representación del Servicio utiliza descripciones empresariales para proporcionar
el contexto (es decir, los procesos de negocio, meta, regla, política, interfaz de
servicio, y el componente de servicio) e implementa servicios utilizando la
orquestación de servicios.  Coloca los requisitos únicos de la infraestructura -,
se recomienda que las implementaciones utilizan estándares abiertos para darse
cuenta de la interoperabilidad y la transparencia de ubicación.  Las
implementaciones son favorables al medio específico - se ven limitados o
habilitadas por el contexto y deben ser descritas dentro de ese contexto. 

El segundo paso es determinar cómo se abordarán estas características distintivas.

Dirigiéndose a un estilo distintivo no debe pedir cambios significativos en TOGAF;
sino que debe ajustar los modelos, puntos de vista y las herramientas utilizadas
por el profesional. En la fase B, fase C y la fase D se espera que el practicante
para seleccionar los recursos arquitectura pertinentes, incluidos los modelos,
puntos de vista y herramientas, para describir adecuadamente el dominio
arquitectura y demostrar que las preocupaciones de los interesados se dirigen (ver
Parte II , 8.4.1 Seleccionar modelos de referencia, puntos de vista y las
herramientas , 10.4.1 Selección de modelos de referencia, puntos de vista y las
herramientas , 11.4.1 Selección de modelos de referencia, puntos de vista y las
herramientas , y 12.4.1 Selección de modelos de referencia, puntos de vista y
herramientas ). Dependiendo de las características distintivas, diferentes estilos
arquitectónicos añadirán nuevos elementos que se hará una descripción, resalte los
elementos existentes, ajuste la notación utilizada para describir la arquitectura,
y el enfoque del arquitecto en algunos grupos de interés o preocupación de las
partes interesadas. Dirigiéndose a los rasgos distintivos suele incluir extensiones
al Metamodel Arquitectura de contenidos y el uso de la notación específica o
técnicas de modelado y la identificación de puntos de vista. Si el estilo es
dominante determinará si es necesario volver a examinar la Etapa Preliminar y
realizar cambios en la capacidad de Arquitectura o si el apoyo a la característica
distintiva es posible en el ámbito de la selección se espera dentro de un solo
ciclo de ADM. Modelos de referencia-estilo específico y modelos de madurez son
herramientas que apoyan a un practicante de uso común. Con el tiempo se espera que
los nuevos estilos arquitectónicos que surjan para abordar los problemas clave que
enfrentan los practicantes. Algunos estilos estarán transitoria, algunos se
aguantan en un nicho, y algunos se funden en la corriente principal. Existen los
Foros Open Group y Grupos de Trabajo para abordar los desafíos que enfrenta la
industria. Estos organismos producen una amplia gama de material que sea útil a una
practicante interesado en adaptar TOGAF, o un ciclo de ADM en particular, a un
estilo arquitectónico particular para los materiales actuales, incluyendo libros
blancos y normas aplicables (ver www.opengroup.org/ togaf_docs ).

           Página 184 de 670 

TOGOF 9.1    

19. La aplicación de iteración para el ADM 19.1 Información general

La representación gráfica de la TOGAF ADM, como se muestra en la Figura 5-1 , y la
descripción de las fases de ADM discretamente en orden en la Parte II , se puede
leer que implica una metodología de cascada determinista. Este método se
proporciona de presentación para el propósito de comunicar rápidamente los
conceptos básicos de desarrollo de la arquitectura y la arquitectura del ciclo de
vida. En la práctica, dos conceptos clave se utilizan para gestionar la complejidad
del desarrollo de una empresade arquitectura y gestión de su ciclo de vida - la
iteración y los niveles (véase . 20 La aplicación de la ADM a través de la
arquitectura del paisaje .) Los dos conceptos están estrechamente vinculados. El
ADM es compatible con una serie de conceptos que se caracterizan como iteración. En
primer lugar, la iteración describe el proceso tanto de la descripción de un
Arquitectura del Paisaje integral a través de múltiples ciclos de ADM sobre la base
de iniciativas individuales ligados al ámbito de la Solicitud de Arquitectura Obra.
En segundo lugar, la iteración describe el proceso integrado de desarrollo de una
arquitectura en la que las actividades descritas en las diferentes fases de ADM
interactúan para producir una arquitectura integrada. Con el fin de describir de
manera concisa la actividad y salidas, esta última iteración se describe en
términos secuenciales. En tercer lugar, la iteración describe el proceso de gestión
del cambio a la Arquitectura de Capacidad de la organización. Iteración para
desarrollar una arquitectura de paisaje integral:  Proyectos ejercerán a través de
todo el ciclo de ADM, comenzando con la Fase A. Cada ciclo de la ADM estará
obligado por una Solicitud de Arquitectura Obra. La salida de la arquitectura
rellenará la Arquitectura del Paisaje, ya sea ampliando el panorama descrito, o
cambiando el paisaje en el que se requiera.  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. Normalmente,
esto se usa 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 Obra. 

 

La iteración dentro de un ciclo de ADM (iteración Arquitectura Desarrollo):  Los

proyectos pueden operar múltiples fases ADM simultáneamente. Normalmente, esto se
utiliza para gestionar la interrelación entre la arquitectura de negocio, Sistemas
de Información Arquitectura, Arquitectura y Tecnología.  Proyectos puede realizar
un ciclo entre las fases de ADM, en ciclos planificados abarcan múltiples fases.
Normalmente, esto se usa para converger en una arquitectura detallada Target cuando
la arquitectura de alto nivel no existe para proporcionar 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. Normalmente, esto se
usa

  Página 185 de 670 

TOGOF 9.1    
para converger en un ejecutable Arquitectura Roadmap o Ejecución y Plan de
Migración, cuando los detalles de la implementación y el alcance del cambio
desencadenan un cambio o re-priorización de necesidades de los interesados. 
Iteración para gestionar la Arquitectura Capability (Capacidad Arquitectura
iteración):  Los proyectos pueden requerir una nueva iteración de la Fase
Preliminar (re) establecer los aspectos de la capacidad Arquitectura identificados
en la Fase A a dirigir una solicitud de Arquitectura Obra.  Los proyectos pueden
requerir una nueva iteración de la Fase Preliminar para ajustar Arquitectura
Capacidad de la organización como resultado de la identificación de requisitos
nuevos o modificados para Arquitectura capacidad como resultado de una solicitud de
cambio en la Fase H. 

19.2 Iteración Ciclos

Los ciclos de iteración sugeridas para el TOGAF ADM se muestran en la Figura 19-1 ,
y se pueden utilizar de manera efectiva a los grupos relacionados con actividades
de arquitectura para lograr un propósito específico. Estos ciclos de iteración se
hace referencia en 19.3 Clases de Arquitectura de compromiso y 19,5 iteración
Consideraciones .

Figura 19‐1: ciclos de iteración   

Página 186 de 670 

TOGOF 9.1    
 Arquitectura Capacidad iteraciones apoyan la creación 1 y la evolución de la
capacidad Arquitectura necesario. Esto incluye la movilización inicial de la
actividad de la arquitectura para un propósito o una arquitectura de tipo de
compromiso dado al establecer o ajustar el enfoque de la arquitectura, los
principios, el alcance, la visión y la gobernabilidad.  Arquitectura de Desarrollo
iteraciones permiten la creación de contenido de la arquitectura por el ciclismo a
través de, o integrar, Negocios, Sistemas de Información y Tecnología de la
Arquitectura fases. Estas iteraciones asegurar que la arquitectura se considera
como un todo. En este tipo de comentarios de las partes interesadas iteración son
típicamente más amplio. A medida que las iteraciones convergen en un objetivo,
extensiones en las oportunidades y soluciones y las fases de planeamiento de
migración de asegurar que aplicabilidad de la arquitectura se considera que la
arquitectura está finalizado.  Planificación de Transición iteraciones apoyan la
creación de hojas de ruta del cambio formales para una arquitectura definida. 
Arquitectura de Gobierno iteraciones apoyar la gobernabilidad de la actividad de
cambio avanzar hacia una Arquitectura objetivo definido. 

 

19.3 Clases de Arquitectura de compromiso

Una función o servicios de organización de la arquitectura puede ser llamado para
ayudar a una empresa en una serie de contextos diferentes, como las arquitecturas
desarrolladas pueden variar de resumen al detalle, amplia cobertura estrecha, y el
estado actual de estado futuro. En estos contextos, el concepto de iteración se
debe utilizar en el desarrollo de la arquitectura. Por lo general, hay tres áreas
de participación para los arquitectos:  Identificación de Cambio Requerido : Fuera
del contexto de cualquier iniciativa de cambio, la arquitectura puede ser utilizado
como una técnica para proporcionar la mayor visibilidad de la capacidad de TI con
el fin de apoyar la toma de decisiones y la alineación de la ejecución
estratégica.  Definición de Cambio : ¿Dónde se ha identificado la necesidad de
cambiar, la arquitectura puede ser utilizado como una técnica para definir la
naturaleza y el alcance de los cambios de una manera estructurada. Dentro de las
iniciativas de cambio gran escala, las arquitecturas pueden ser desarrollados para
proporcionar información detallada Arquitectura Definición de las iniciativas de
cambio que están delimitadas por el ámbito de un programa o cartera. 
Implementación del Cambio : Arquitectura en todos los niveles de la empresa puede
ser utilizado como una técnica para proporcionar la gobernabilidad de diseño para
cambiar iniciativas, proporcionando visibilidad panorama general, el suministro de
las limitaciones estructurales, y la definición de los criterios sobre los que
evaluar las decisiones técnicas. 


Figura 19-2 y la tabla siguientes muestran las clases de arquitectura de la
participación de la empresa.

  Página 187 de 670 

TOGOF 9.1    

  Figura 19‐2: Clases de arquitectura empresarial de compromiso 
Cada uno de estos tipos de compromiso de la arquitectura se describe en la
siguiente tabla.
Área de Compromiso Identificación de Cambio Requerido Arquitectura Compromiso Apoyo
a Estrategia de Negocios Descripción Como las estrategias de negocio, objetivos,
metas y de cambio de conductores, es necesario para que la empresa cambie con el
fin de mantener la alineación. La creación de nuevas estrategias de negocio puede
ser apoyado por la arquitectura empresarial a través de:

  
Architectural Gestión de la cartera del Paisaje

Proporcionar visibilidad de las oportunidades de cambio  Proporcionar elaboración

en los impactos prácticos de una elección estratégica particular,  Ofrecer pruebas
sobre la viabilidad o la viabilidad de una dirección estratégica particular, 

Es una práctica común en las grandes organizaciones para una organización de

gestión de servicios para proporcionar información operativa y de gestión de la
cartera de TI. Arquitectura empresarial puede añadir una nueva dimensión a los
informes de gestión de servicios, mediante el apoyo a la vinculación entre el
rendimiento operativo y la necesidad estratégica de TI. Uso de la trazabilidad
entre TI y el negocio inherente a la arquitectura empresarial, es posible evaluar
la cartera de TI

  Página 188 de 670 

TOGOF 9.1    
frente a los datos de rendimiento operacional y las necesidades del negocio (por
ejemplo, el coste, la funcionalidad, la disponibilidad, la capacidad de respuesta)
para determinar las áreas donde está ocurriendo la desalineación y el cambio tiene
que tener lugar. Es una práctica común en las grandes organizaciones para una
organización de gestión de programas para proporcionar información operativa y de
gestión de la cartera de cambio. Arquitectura empresarial puede añadir una nueva
dimensión a los informes de gestión de cartera de proyectos, mediante el apoyo a la
vinculación entre el alcance del proyecto, el impacto arquitectónico y el valor del
negocio. Factores arquitectónicos se pueden añadir a otros factores cuantitativos
de proyectos para apoyar la toma de decisiones estratégicas en la prioridad del
proyecto y los niveles de financiación. Definición de Cambio Architectural
Definición de Iniciativas de cambio fundacionales son los esfuerzos de
Fundacionales iniciativas de cambio que tienen un objetivo conocido, pero no son
cambio estrictamente cuyo ámbito o delimitadas por una visión o requisitos
compartida. En las iniciativas de cambio fundamentales, la prioridad inicial es
comprender la naturaleza del problema y de una estructura a la definición del
problema. Una vez que el problema se entiende de manera más eficaz, es posible
definir soluciones apropiadas y para alinear las partes interesadas en torno a una
visión y un propósito común. Iniciativas de cambio delimitadas son los esfuerzos de
cambio que por lo general surgen como el resultado de una estrategia antes de
arquitectura, la evaluación o la visión.
Architectural Gestión de Cartera de Proyectos

Architectural Definición de Iniciativas de Cambio delimitadas

En las iniciativas de cambio acotadas, el resultado deseado ya está entendido y

acordado. El foco de los esfuerzos de arquitectura en esta clase de compromiso es
elaborar eficazmente una solución de línea base que responda a las necesidades
identificadas, problemas, los controladores y las restricciones. Implementación del
Gobernanza arquitectónico Una vez que un modelo de solución arquitectónica ha sido
Cambio de Cambio Implementación definida, proporciona una base para el diseño y la
implementación. Con el fin de garantizar que los objetivos y el valor de la
arquitectura definida se realizan adecuadamente, es necesario para la continuación
de la gobernanza arquitectura del proceso de implementación para facilitar la
revisión del diseño, la arquitectura refinamiento, y el problema de ampliación.

  Página 189 de 670 

TOGOF 9.1    
Las diferentes clases de participación arquitectura en diferentes niveles de la
empresa requerirán atención en áreas específicas, como se muestra a continuación.
Ciclos de Enfoque Alcance iteración Focus Apoyo a Estrategia de Negocios
Arquitectura Amplio, consideración superficial dado a la arquitectura del
Capability paisaje a fin de abordar una cuestión estratégica específica y definir
los términos de los esfuerzos más detallados de arquitectura para hacer frente a la
estrategia de realización. Arquitectura Desarrollo (Línea de base primero)
Architectural Gestión de la cartera Arquitectura del Paisaje Capability Tipo de
compromiso

Arquitectura Desarrollo (Línea de base primero) Architectural Gestión de Cartera

Planificación de la Centrarse en los proyectos, las dependencias del proyecto, y
los impactos paisajísticos de alinear secuenciación proyecto de Proyectos
Transición de manera que se optimiza arquitectónicamente. Arquitectura de Gobierno
Arquitectura Capability Arquitectura Desarrollo (Línea de base primero)
Planificación de la Transición Centrarse en la elaboración de la meta de satisfacer
una Architectural Definición de Arquitectura visión previamente definido y
acordado, el alcance, o un Iniciativas de Cambio delimitadas Desarrollo (Target
primero) conjunto de restricciones. Use el destino como una base para el análisis
para evitar la perpetuación de la línea de Planificación de la base, arquitecturas
sub-óptimos. Gobernanza arquitectónico de Cambio Implementación Transición
Arquitectura de Gobierno Utilice la Architecture Vision, limitaciones, principios,
requisitos, Arquitectura Target definición, y un plan de transición para asegurar
que los proyectos se dan cuenta de su beneficio previsto, están alineados entre sí,
y están alineados con las necesidades de negocio más amplio.

Centrarse en la evaluación física de las aplicaciones de línea de base y de la

infraestructura de tecnología para identificar oportunidades de mejora, por lo
general dentro de las limitaciones de mantenimiento de los negocios como de
costumbre.

Architectural Definición de Fundacionales iniciativas de cambio

Centrarse en la elaboración de una visión a través de la definición de la línea de

base e identificar lo que debe cambiar para hacer la transición de la línea base a
la meta.

19.4 Enfoques para el Desarrollo de la Arquitectura

Dos enfoques se pueden adoptar dentro de la ADM para el desarrollo de
arquitecturas:  Línea de Base Primera : En este estilo, se utiliza una evaluación
del paisaje de referencia para identificar las áreas problemáticas y oportunidades
de mejora. Este proceso es más adecuado cuando la línea de base es compleja, no se
entiende claramente, o que

  Página 190 de 670 

TOGOF 9.1    
convengan. Este enfoque es común en el que las unidades de organización han tenido
un alto grado de autonomía.   Objetivo Primero : En este estilo, la solución
objetivo se elabora en detalle y luego asigna de nuevo a la línea de base, con el
fin de identificar la actividad de cambio. Este proceso es adecuado cuando un
estado de destino está de acuerdo en un nivel alto y cuando la empresa desea hacer
la transición eficazmente a la modelo de destino. 

Típicamente, si la línea de base se entiende en líneas generales un valor más alto

será obtenido se centra en el objetivo primero y luego la línea de base en la
medida necesaria para identificar los cambios. En términos prácticos, un equipo de
la arquitectura siempre dará consideración informal a la línea de base en el
análisis de la meta (y viceversa ). En situaciones donde se espera que la línea de
base y el objetivo a considerar en paralelo por los interesados, se recomienda que
el equipo de arquitectura se centra prioritaria en un Estado con el fin de mantener
el enfoque y la coherencia de la ejecución.

19.5 Iteración Consideraciones

Algunos ciclos de iteración puede ser ejecutado una vez, mientras que otros tienen
un número mínimo natural de los ciclos. Para algunos ciclos de iteración, cada
iteraciónsigue el mismo proceso; donde hay más de una iteración dentro de un ciclo,
el proceso difiere ligeramente para cada una de las iteraciones. Cuando se
considera el uso de ciclos de iteración, también es necesario considerar dónde
colocar los puntos de control apropiados dentro del proceso. Si el nivel esperado
de participación de los interesados es alto, puede ser razonable para llevar a cabo
los puntos de control muy frecuentes pero informales para garantizar que el proceso
se está moviendo en la dirección deseada. Si las partes interesadas no están tan
estrechamente involucrados, entonces los puntos de control pueden ser menos
frecuentes pero más formal. Los puestos de control en la finalización de cada ciclo
de iteración, o al final de varios ciclos de iteración, son comunes.

19.5.1 La iteración entre Ciclos ADM

Cada iteración completa un ciclo de ADM en un solo nivel de descripción de la
arquitectura. Este enfoque de la ADM utiliza la Fase F (Migration Planning) para
iniciar nuevos proyectos más detallados de desarrollo de la arquitectura. Este
enfoque se ilustra en la Figura 19-3 . Este tipo de iteración destaca la necesidad
de una arquitectura de alto nivel para orientar y limitar la arquitectura más
detallada. También destaca que la arquitectura del paisaje completo ha sido
desarrollado por múltiples iteraciones ADM.

  Página 191 de 670 

TOGOF 9.1    

   
  Figura 19‐3: Una Jerarquía de ADM Procesos Ejemplo 
19.5.2 La iteración dentro de un ciclo de ADM
Cada ciclo de iteración pase por varias fases TOGAF ADM. Las siguientes tablas
muestran a un alto nivel que las fases se deben completar para que el ciclo de
iteración, que muestra la actividad que es el núcleo (es decir, el enfoque
principal de la iteración), actividad que es la luz (es decir, el objetivo
secundario de la iteración), y actividad que puede llevarse a cabo de manera
informal (es decir, algún tipo de actividad puede llevarse a cabo, pero no se
menciona explícitamente en el ADM).

  Página 192 de 670 

TOGOF 9.1    

   
  Figura 19‐
4: Actividad por iteración de Línea de Base Primera Arquitectura Definición 

   
 

  Página 193 de 670 

TOGOF 9.1    

  Figura 19‐5: Actividad por iteración para Target Primera Arquitectura Definición 
Los ciclos de iteración sugeridas asignados a las fases TOGAF se describen en la
siguiente tabla:
La iteración Iteración Propósito del ciclo Arquitectura Iteración Definir la
Arquitectura de Desarrollo 1 Referencia. (Línea de base primero) Descripción Esta
iteración comprende un paso a través de la arquitectura de negocios, Sistemas de
Información Arquitectura y Arquitectura Tecnología fases de la ADM, centrándose en
la definición de la línea de base.

Oportunidades, soluciones y planes de migración también se consideran para sacar el

foco para el cambio y la viabilidad de prueba. Iteración Definir la arquitectura
destino Esta iteración comprende un paso a 2 y las lagunas. través de la
arquitectura de negocios, Sistemas de Información Arquitectura y Arquitectura
Tecnología fases de la ADM, centrándose en la definición de los objetivos y
análisis de brechas en contra de la línea de base. Oportunidades, soluciones y
planes de migración también se consideran para probar la viabilidad. Iteraciones
Arquitectura de desarrollo posteriores intentan corregir y

Iteraciónn Refinar la línea de base, el objetivo, y las lagunas.

  Página 194 de 670 

TOGOF 9.1    
perfeccionar el objetivo de lograr un resultado que sea beneficioso, factible y
viable. Esta iteración comprende un paso a través de la arquitectura de negocios,
Sistemas de Información Arquitectura y Arquitectura Tecnología fases de la ADM,
centrándose en la definición de la meta. Oportunidades, soluciones y planes de
migración también se consideran para sacar el foco para el cambio y la viabilidad
de prueba. Esta iteración comprende un paso a través de la arquitectura de
negocios, Sistemas de Información Arquitectura y Arquitectura Tecnología fases de
la ADM, centrándose en la definición de los espacios de referencia y análisis
contra el objetivo.
Arquitectura Desarrollo (Target primero)

Iteración Definir la arquitectura 1 destino.

Iteración Definir la Arquitectura y las 2 lagunas de línea de base.

Oportunidades, soluciones y planes de migración también se consideran para probar

la viabilidad. Iteraciónn Refinar la línea de base, el Iteraciones Arquitectura de
desarrollo objetivo, y las lagunas. posteriores intentan corregir y perfeccionar el
objetivo de lograr un resultado que sea beneficioso, factible y viable.
Planificación de Iteración Definir y acordar una serie de La primera iteración de
la planificación la Transición 1 oportunidades de mejora, de la transición busca
ganar buy-in a alineados contra una una cartera de oportunidades con arquitectura
provisional de soluciones para las Oportunidades y transición. Soluciones fase de
ADM. Esta iteración también ofrece un plan de migración provisional. Iteraciónn
Acordar la arquitectura de Iteraciones posteriores de planificación transición, el
de la transición tratan de perfeccionar perfeccionamiento de las el plan de
migración, la alimentación oportunidades de mejora de los números anteriores en las
identificadas para adaptarse. oportunidades y soluciones para la fase de
refinamiento. Arquitectura de Iteración Movilizar gobernabilidad La arquitectura de
la gobernanza Gobierno 1 arquitectura y cambiar los iteración inicial establece un
proceso procesos de gestión. para la gobernanza del cambio y también pone en su
lugar a las personas adecuadas, procesos ytecnología para apoyar el acceso
controlado a y el cambio de la arquitectura definida. Iteraciónn Llevar a cabo la
Iteraciones posteriores de la Arquitectura enfoque de ciclo de gobernabilidad y la
Gobierno en la revisión periódica de arquitectura de control de las iniciativas de
cambio para resolver cambios. los problemas y garantizar su cumplimiento. Los
resultados de una

  Página 195 de 670 

TOGOF 9.1    
solicitud de cambio pueden desencadenar otra fase a ser revisado; por ejemplo, la
alimentación de nuevo un nuevo requisito para la Etapa Preliminar para mejorar la
Capacidad de Arquitectura, o un nuevo requisito para la arquitectura en las fases
de desarrollo de la arquitectura.

19.6 Conclusiones
Todas estas técnicas son aplicaciones válidas de la ADM. Combinado juntos,
representan cómo el ADM se puede utilizar en la práctica. El ADM siempre se debe
utilizar en un proceso iterativo. . ¿Cómo se ejerce este proceso depende de
factores organizativos factores particulares a considerar incluyen:  La formalidad
y la naturaleza de los puestos de control de procesos establecidos dentro de la
organización. ¿El mandato de la organización de que ciertos grupos de actividades
se llevan a cabo entre los puestos de control? ¿Tiene el mandato de la organización
de que ciertas actividades deben finalizarse antes de que otras actividades se
puede realizar?  El nivel de participación de los interesados se esperaba dentro
del proceso. Están interesados esperando a participar estrechamente en el
desarrollo de una solución, o están a la espera de ver un conjunto completo de
prestaciones para su revisión y aprobación?  El número de equipos participantes y
de las relaciones entre los diferentes equipos. Es toda la arquitectura está siendo
desarrollado por un equipo específico, o hay una jerarquía de equipos con las
relaciones de gobierno entre ellos?  La madurez del área de la solución y la
cantidad esperada de la reanudación y el refinamiento necesario para llegar a una
solución aceptable. ¿Se puede lograr la solución en un solo paso, o requiere un
extenso trabajo de prueba de concepto y prototipos para evolucionar un resultado
adecuado ?  Actitud hacia el riesgo. ¿Reacciona la cultura organizacional
negativamente a parcialmente los productos de trabajo completas se distribuyen?
¿Requiere la cultura organizacional soluciones que deben probarse en un entorno de
prueba antes de que puedan ser implementadas por la aplicación general?  La clase
de compromiso. ¿Cuál es el contexto para el desarrollo de la arquitectura de la
empresa? 

  

  Página 196 de 670 

TOGOF 9.1       

20. Aplicando la ADM a través de la Arquitectura del Paisaje 20.1 Información

general
En una empresa típica, muchas arquitecturas se describirán 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 abordar detalle;
Algunos pueden ofrecer una gran imagen. Para hacer frente a esta complejidad TOGAF
utiliza los conceptos de niveles y Enterprise Continuum para proporcionar un marco
conceptual para la organización de la Arquitectura del Paisaje. Estos conceptos
están estrechamente vinculados con la organización de contenido real en la
arquitectura de repositorio y cualquier partición de arquitectura se discuten en la
Parte V .

20.2 Arquitectura del Paisaje

Niveles proporcionan un marco para dividir la arquitectura del paisaje en tres
niveles de granularidad:

1. Arquitectura Estratégico proporciona un marco de organización de la actividad

operativa y el cambio y permite la configuración de dirección a nivel ejecutivo. 
2. Arquitectura Segmento proporciona un marco de organización de la actividad
operativa y
el cambio y permite la configuración de la dirección y el desarrollo de los planes
de trabajo de arquitectura eficaces a nivel de programa o cartera. 

3. Arquitectura Capability ofrece un marco organizativo para la actividad de cambio

y el
desarrollo de planes de trabajo eficaces arquitectura realizando incrementos de
capacidad.  La Figura 20-1 muestra un resumen del modelo de clasificación de
Arquitectura Paisajes.

  Página 197 de 670 

TOGOF 9.1    

  Figura 20‐1: Resumen Clasificación Modelo de Arquitectura Paisajes 
La Arquitectura Continuum proporciona un método de dividir cada nivel de la
arquitectura del paisaje (ver 39.4.1 Arquitectura Continuum ) por la abstracción.
Ofrece una forma coherente de definir y entender las reglas genéricas, las
representaciones y las relaciones en una arquitectura , incluyendo las relaciones
de trazabilidad y de derivación. La Arquitectura Continuum muestra las relaciones
de elementos de cimentación a la arquitectura específica de la organización, como
se muestra en la Figura 20-2 . La Arquitectura Continuum es una herramienta útil
para descubrir en común y eliminar la redundancia innecesaria.

  Figura 20‐2: Resumen de Arquitectura Continuum 
Los niveles y la Continuum Arquitectura proporcionan un mecanismo amplio para
describir y clasificar la Arquitectura del Paisaje. Estos conceptos pueden ser
usados para organizar la arquitectura del paisaje en un conjunto de arquitecturas
relacionadas con:  Complejidad manejable para cada arquitectura o solución
individual 

  Página 198 de 670 

TOGOF 9.1    
   Agrupaciones definidas  Jerarquías definidas y estructuras de navegación 
Procesos adecuados, roles y responsabilidades adjuntas a cada agrupación 

No existe un modelo de organización definitiva de la arquitectura, ya que cada

empresa debe adoptar un modelo que refleje su propio modelo de funcionamiento.

20.3 Organización de la Arquitectura del Paisaje para comprender el estado de la

Empresa
Las siguientes características se utilizan normalmente para organizar la
Arquitectura del Paisaje:  Amplitud : El área de amplitud (objeto) es por lo
general la característica de organización primaria para la descripción de una
arquitectura del paisaje. Arquitecturas están funcionalmente descomponerse en una
jerarquía de áreas o segmentos de materias específicas.  Profundidad : Con áreas
más amplias, se necesita menos detalle para asegurar que la arquitectura tiene un
tamaño y una complejidad manejable. Áreas temáticas más específicas, generalmente
permitir (y requerirá) arquitecturas más detalladas.  Tiempo : Para una amplitud y
profundidad específica de una empresa puede crear una arquitectura de referencia y
un conjunto de arquitecturas objetivo que se extienden hacia el futuro.
Arquitecturas más amplios y menos detallados serán generalmente válidas por
períodos más largos de tiempo y pueden proporcionar una visión de la empresa, que
se extiende más hacia el futuro.  Fecha reciente : Finalmente, cada vista de la
arquitectura va a progresar a través de un ciclo de desarrollo donde aumenta la
precisión hasta que finalmente aprobado. Después de la aprobación, una arquitectura
comenzará a disminuir en precisión si no se mantiene activa. En algunos casos de
experiencia reciente se puede utilizar como un factor de la organización para las
arquitecturas históricas. 

Utilizando los criterios anteriores, las arquitecturas se pueden agrupar en, por
segmentos y niveles de Arquitectura de la capacidad estratégica, tal como se
describe en la Figura 20-1 .

20.4 Desarrollo de arquitecturas en diferentes niveles

Las secciones anteriores han identificado que se requieren diferentes tipos de
arquitectura para estudiar las distintas necesidades de los interesados en los
diferentes niveles de la organización. Cada arquitectura típicamente no existe de
manera aislada y por lo tanto debe sentarse dentro de una jerarquía de gobierno.
Amplio, arquitecturas de síntesis que figura la dirección para arquitecturas
estrechas y detalladas. . Un número de técnicas se puede emplear para utilizar el
ADM como un proceso que apoya tales jerarquías de arquitecturas Esencialmente hay
dos estrategias que se pueden aplicar:

  Página 199 de 670 

TOGOF 9.1     1. Arquitecturas en los diferentes niveles se pueden desarrollar a

través de iteraciones dentro de un solo ciclo del proceso de ADM.  2. Arquitecturas
en los diferentes niveles se pueden desarrollar a través de una jerarquía de
procesos de ADM, ejecutado simultáneamente. 
En los extremos de la escala, cualquiera de estas dos opciones se pueden adoptar
plenamente. En la práctica, un arquitecto es probable que tenga que combinar
elementos de cada uno para adaptarse a los requisitos exactos de su Solicitud de
Arquitectura Obra. Cada uno de estos enfoques se describe en 19. La aplicación de
iteración para el ADM .

  Página 200 de 670 

TOGOF 9.1       

21. Arquitectura de Seguridad y el ADM 21.1 Información general

El objetivo de este capítulo es explicar las consideraciones de seguridad que deben
ser abordados durante la aplicación del Método de Desarrollo de Arquitectura TOGAF
(ADM).

21.2 Introducción
Métodos de desarrollo de la arquitectura son herramientas en las manos del
practicante de seguridad que se utilizarán para crear las mejores prácticas y la
capacidad de seguridad específicas de cada organización. La orientación que se
incluye aquí es ayudar a los dos arquitectos de la empresa y los profesionales de
seguridad para evitar la pérdida de los problemas de seguridad críticos. En este
capítulo se informa a la empresa artífice de lo que necesitará el arquitecto de
seguridad para llevar a cabo durante los trabajos de arquitectura de seguridad. A
menudo, la arquitectura de seguridad es tratado como un dominio de la arquitectura
independiente dentro de la arquitectura de la empresa, mientras que necesitan ser
integrados plenamente en el mismo. El enfoque del arquitecto de seguridad es la
ejecución de las políticas de seguridad de la empresa, sin inhibir valor.
Arquitecturas de seguridad generalmente tienen las siguientes características:  
    Arquitectura de seguridad tiene su propia metodología de seguridad
discreto.  Arquitectura de seguridad compone sus propias opiniones y puntos de
vista diferenciados.  Arquitectura de seguridad se ocupa de los flujos no
normativos a través de sistemas y entre las aplicaciones.  Arquitectura de
seguridad presenta sus propios flujos normativos a través de sistemas y entre las
aplicaciones.  Arquitectura de seguridad presenta, componentes de una sola función
única en el diseño.  Arquitectura de seguridad requiere su propio conjunto único de
habilidades y competencias de la empresa y los arquitectos de TI. 

21.3 Orientación de Seguridad para los Dominios Arquitectura

Los problemas de seguridad son omnipresentes en todo los ámbitos de la arquitectura
y en todas las fases del desarrollo de la arquitectura. Seguridad es declarado out
por separado debido a que es una infraestructura que no suele ser visible a la
función empresarial. Su propósito fundamental es proteger el valor de los sistemas
y activos de información de la empresa. Con frecuencia, la

  Página 201 de 670 
TOGOF 9.1    
naturaleza de la seguridad en la empresa es que se considera exitoso si bien no
ocurre nada es visible para el usuario u otro observador, y / o no hay daños o
pérdidas ocurren a la empresa. Por ejemplo, los datos en una base de datos de los
registros de clientes no se filtraron o dañados - o un tema intangible, como el
nombre de la empresa aparece en un artículo en las noticias diciendo que sus
sistemas de datos habían sido comprometidos. La arquitectura de seguridad tiene sus
propios componentes de un solo uso y se experimenta como una cualidad de los
sistemas en la arquitectura. El punto de vista de Seguridad Empresarial de la
arquitectura tiene sus propios bloques únicos de construcción, colaboraciones, y
las interfaces. Estos elementos de seguridad-única deben interconectar con los
sistemas de negocio de una manera equilibrada y rentable, a fin de mantener las
políticas de seguridad de la empresa, aún no interferir con las operaciones del
sistema y funciones. Es menos costoso y más eficaz para planificar y ejecutar
funciones específicas de seguridad en la arquitectura de destino lo antes posible
en el ciclo de desarrollo para evitar la costosa adaptación o reelaborar porque los
bloques de construcción necesarios para la seguridad no se añadieron o se utilizan
durante el desarrollo de sistemas y despliegue . El enfoque del arquitecto de
seguridad en cuenta no sólo el flujo normal de la aplicación, sino también los
flujos anormales, modos de falla, y las formas de los sistemas y las aplicaciones
pueden ser interrumpidos y fallan. Todos los grupos de partes interesadas en la
empresa se tienen 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, la
orientación se ofrecerá en la información específica de la seguridad que deben ser
reunidos, los pasos que se deben tomar, y los artefactos que se deben crear.
Arquitectura decisiones relacionadas con la seguridad deben realizarse de
conformidad con las decisiones comerciales 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 la 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 se han utilizado de acuerdo 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 de
acontecimientos anormales o maliciosos.  Protección de Activos : La protección de
los activos de información de la pérdida o divulgación no intencional, y los
recursos de un uso no autorizado y no deseado.  Administración : La capacidad de
agregar y cambiar las políticas de seguridad, agregar o cambiar cómo se implementan
las políticas de la empresa, y añadir o cambiar las personas o entidades vinculados
a los sistemas.  Gestión de Riesgos : actitud y tolerancia al riesgo de la
organización. (Esta gestión del riesgo es diferente de la definición especial que
se encuentra en los mercados financieros

  

  Página 202 de 670 

TOGOF 9.1    
y las instituciones de seguros que cuentan con departamentos formales de gestión de
riesgo.)  Típicos artefactos arquitectura de seguridad se incluyen:      Las
reglas de negocio con respecto al manejo de los activos de datos / información 
Política de seguridad Escrito y publicado  Datos codificados / información de
propiedad y custodia de activos  Documentación de análisis de riesgos 
Documentación política de clasificación de datos 

Gestión Arquitectura 21,4 ADM Requisitos

La política de seguridad y las normas de seguridad se convierten en parte del
proceso de gestión de requisitos empresariales. La política de seguridad se
establece en un nivel ejecutivo de la empresa, es de larga duración y resistente al
cambio caprichoso. La política de seguridad no está ligado a ninguna tecnología
específica. Una vez que se establecen las políticas de seguridad, pueden ser
referidos como requisitos para todos los proyectos de arquitectura. Las normas de
seguridad cambian con más frecuencia y las preferencias tecnológicas estatales
utilizados para apoyar las políticas de seguridad. Las nuevas tecnologías que
apoyan la implementación de políticas de seguridad de una mejor manera se pueden
adoptar, según sea necesario. Las mejoras pueden estar en la reducción de costos o
el aumento de los beneficios. Las normas de seguridad se manifestarán como bloques
de construcción relacionados con la seguridad en la Empresa Continuum. Patrones de
seguridad para el despliegue de estos bloques de construcción relacionadas con la
seguridad se hace referencia en la Guía de Seguridad para la Fase E. Nuevos
requisitos de seguridad surgen de muchas fuentes:

1. Un nuevo mandato estatutario o reglamentario  2. Una nueva amenaza se dio cuenta

o experimentado  3. Una nueva iniciativa de la arquitectura de TI descubre nuevas
partes interesadas y / o nuevos requerimientos 
En el caso en que 1. y 2. arriba ocurren, estos nuevos requisitos serían los
conductores para la entrada al sistema de gestión del cambio discutido en la Fase
H. Una nueva iniciativa de la arquitectura podría ser lanzado para examinar la
infraestructura y las aplicaciones existentes para determinar el alcance de los
cambios necesarios para satisfacer las nuevas demandas. En el caso de 3. arriba ,
un nuevo requisito de seguridad entrará en el sistema de gestión de requisitos.
Es nuestra buena seguridad?

Esta pregunta surge inevitablemente de la administración para el arquitecto de

seguridad. No hay medidas de seguridad son siempre perfecto, y existe la
posibilidad de que la cantidad de dinero y

  Página 203 de 670 

TOGOF 9.1    
esfuerzo realizado para llegar a ser muy grande para poca rentabilidad adicional.
Pruebas de control de seguridad debe estar en su lugar para que los sistemas de
seguridad se pueden medir para asegurarse de que se mantienen las políticas de
seguridad para el que fueron diseñados. Auditorías de políticas de seguridad deben
mantenerse y puede ser obligatorio por ley o reglamento. Estas auditorías de
seguridad y los posibles cambios en las políticas de seguridad son la razón exacta
por la separación de la aplicación de la política del código de la aplicación es
tan fuertemente enfatizado.
Nada útil se puede decir de una medida de seguridad fuera del contexto de una
aplicación o de un sistema y su entorno

La eficacia de una medida de seguridad se considera en relación con el riesgo que

mitiga. Una empresa no puede determinar cuánto va a estar dispuesto a gastar en la
obtención de un activo hasta que se comprende el valor de los activos. Por ejemplo,
el uso de ese activo en una aplicación y el riesgo concomitante el activo está
expuesto a como resultado, determinará los verdaderos requisitos para la seguridad.
Además, la tolerancia de la organización para el riesgo es un factor. En otras
palabras, la pregunta que no debería ser: "¿Está seguro?" sino más bien: "¿Es lo
suficientemente seguro?" Este último es en última instancia una pregunta que debe
responderse mediante el análisis de riesgos.

21.5 Fase Preliminar

Alcance de las organizaciones empresariales afectadas por la arquitectura de
seguridad

  

Identificar empresa de la base (unidades) - aquellos que son los más afectados y
lograr mayor valor de los trabajos de seguridad  Identificar empresariales blandos
(unidades) - los que se ven el cambio a su capacidad y trabajar con unidades
básicas, pero son de otra forma no directamente afectados  Identificar
empresariales extendidas (unidades) - aquellas unidades fuera de la empresa de
ámbito que necesitará para mejorar su arquitectura de seguridad para fines de
interoperabilidad  Identificar las comunidades implicadas (empresas) - las partes
interesadas que se verán afectados por las capacidades de seguridad y que se
encuentran en los grupos de las comunidades  Identifique la gobernanza de la
seguridad involucrados, incluidos los marcos jurídicos y geografías (empresas) 

Si el modelo de negocio de la organización hace abarcar federación con otras

organizaciones, en la medida de la federación de seguridad debe establecerse en
este punto en el proceso. Acuerdos de federación contractuales deben ser examinados
por sus implicaciones y acuerdos de seguridad. Puede que sea necesario establecer
reuniones arquitectura conjuntas con otros miembros de una federación para
establecer interfaces y protocolos para el intercambio de información de seguridad
relacionada con la identidad federada, autenticación y autorización.
Definir y documentar los requisitos reglamentarios y de política de seguridad
aplicables

El marco y los principios rara vez cambian, por lo que las implicaciones de
seguridad llamados en los objetivos de esta fase debería ser bastante sencillo. Una
política de seguridad por escrito de la

  Página 204 de 670 

TOGOF 9.1    
organización debe estar en su lugar, y no debe haber notificación regular y la
educación establecidos para los empleados. ISO / IEC 17799:2005 es un buen lugar
para comenzar la formación de una política de seguridad, y se puede utilizar para
evaluar la disposición de seguridad de una organización. Sin una política de
seguridad por escrito y publicado, su aplicación es difícil. Las políticas de
seguridad se refieren a muchos aspectos de la seguridad de la organización - como
la seguridad locales físicos - que son remotamente relacionadas con la seguridad de
los sistemas y aplicaciones. La política de seguridad debe ser examinada para
encontrar secciones pertinentes, y se actualiza si es necesario. Arquitectura
limitaciones establecidas en la política de seguridad deben ser comunicados a los
demás miembros del equipo de arquitectura. De manera similar, puede haber
requisitos reglamentarios que especifican las obligaciones del sistema debe cumplir
o acciones que se deben tomar. Si el sistema estará sujeto a la regulación
dependerá de la funcionalidad del sistema y los datos recogidos o mantenidas.
Además, la jurisdicción donde se despliega el sistema o servicio, donde residen los
usuarios, o en virtud de la cual la entidad está desplegando fletados o
incorporados informará de esta decisión. Puede ser aconsejable obtener
asesoramiento legal con respecto a estas obligaciones al inicio de las actividades.
Definir la capacidad de seguridad requerido como parte de la arquitectura de
Capacidad

Acuerdo sobre el papel del arquitecto de seguridad en el proceso de arquitectura de

la empresa y en la arquitectura y el gobierno de TI también deben establecerse. Las
consideraciones de seguridad pueden entrar en conflicto con consideraciones
funcionales y se requiere un defensor de la seguridad para garantizar que todas las
cuestiones se abordan y los conflictos de intereses no impiden la consideración
explícita de temas difíciles. Decisiones políticas ejecutivas deben establecerse en
este punto acerca de lo que las políticas de seguridad puede ser negociable y qué
políticas deben hacerse cumplir por razones reglamentarias o estatutarias.
Implementar herramientas de arquitectura de seguridad

El nivel de formalidad utilizado para definir y gestionar la seguridad de

contenidos arquitectura será altamente dependiente de la escala, la sofisticación y
la cultura de la función de la arquitectura de seguridad. El acercamiento a las
herramientas de seguridad puede estar basado en el uso relativamente informal de
aplicaciones de productividad de oficina estándar, o puede estar basada en una
implementación personalizada de herramientas de arquitectura de seguridad
especializadas y técnicas.

21.5.1 Entradas de seguridad  La política de seguridad por escrito 

  Estatutos pertinentes  Lista de las jurisdicciones aplicables 

Las salidas de seguridad 21.5.2  Lista de los reglamentos aplicables 

  Lista de las políticas de seguridad aplicables  Equipo de seguridad roster 

  Página 205 de 670 

TOGOF 9.1    
 Lista de los supuestos de seguridad y condiciones de frontera 

21.6 Fase A: Architecture Vision

Las consideraciones de seguridad tienen un impacto en las Fases A a H del TOGAF
ADM. Las siguientes especificaciones de seguridad adecuadas para la arquitectura de
seguridad deben abordarse en cada fase, además de las actividades de eliminación de
genéricos. Las etapas de la fase de Visión Arquitectura son aplicables a garantizar
que los requisitos de seguridad se abordan en las fases posteriores de la ADM. Las
consideraciones de seguridad tendrán un efecto en la empresa de tal manera que todo
el desarrollo de la arquitectura empresarial debe ser informada y utilizar la
política de seguridad, las limitaciones, la gobernanza, los artefactos, y bloques
de construcción. Después de establecer cualquier proyecto de arquitectura de la
empresa, las siguientes actividades relacionadas con la seguridad específicas deben
llevarse a cabo. Definición de los grupos de interés y de descubrimiento
pertinentes de sus preocupaciones y objetivos requerirá el desarrollo de un
escenario de alto nivel. Requisitos de negocio clave También se establecerán a
través de este trabajo de escenarios temprano. El proceso de escenario empresarial
TOGAF ADM puede ser útil aquí y en etapas posteriores.
Obtener el apoyo de la gestión de las medidas de seguridad

En forma similar a obtener el reconocimiento y la gestión de aval para el proyecto

en general la arquitectura, así también la aprobación de los aspectos relacionados
con la seguridad de las actividades de desarrollo de arquitectura debe ser
obtenido. Reconocimiento de que el proyecto podría tener el desarrollo y el impacto
de infraestructuras que no son fácilmente visibles por mirar únicamente a los
sistemas en cuestión debe quedar claro. Examinar a fondo y la mitigación de los
problemas relacionados con el riesgo y la seguridad pueden ser percibidos como un
desperdicio de recursos y de tiempo; el nivel de apoyo a la gestión debe entenderse
y comunicarse en todo el equipo.
Definir gestión hitos sign-off en materia de seguridad necesarias de este ciclo de
desarrollo de la arquitectura

La trazabilidad de decisiones de arquitectura relacionados con la seguridad debe

ser documentado y los ejecutivos apropiados y gestión de la línea que necesitan
para estar informado de los aspectos relacionados con la seguridad del proyecto
deben ser identificados y la frecuencia de los informes debe ser establecido. Se
debe reconocer que existe la tensión entre la entrega de la nueva función
empresarial y la ejecución de políticas de seguridad, y que un proceso para
resolver tales disputas que surjan deben establecerse al principio del proyecto.
Estas tensiones tienen a menudo el resultado de poner el arquitecto de seguridad
aparentemente "en la forma de completar el proyecto." Se necesita ser entendido por
la dirección y los demás arquitectos involucrados que el papel del arquitecto de
seguridad es el de salvaguardar los activos de la empresa.
Determinar y documentar la recuperación de desastres y continuidad de negocio
aplicable planes / requisitos

Cualquier recuperación de desastres existentes y los planes de continuidad de

negocio deben ser comprendidas y su relación con el sistema de planificación
definidos y documentados.

  Página 206 de 670 

TOGOF 9.1    
Identificar y documentar el / / ambiente anticipado física negocio regulatorio (s)
en que se implementará el sistema (s)

Todas las decisiones de arquitectura deben hacerse en el contexto de los entornos

en los que el sistema se puede colocar y operar. Entornos físicos que deben ser
documentados pueden incluir entornos de batalla, ambientes comerciales, ambientes
al aire libre, los entornos móviles y similares. De manera similar, el entorno
empresarial se debe definir. Entornos empresariales potenciales pueden incluir
diferentes supuestos sobre los usuarios y las interfaces de usuarios, y éstos o
interfaces pueden llevar la carga de los entornos regulatorios en que debe operar
el sistema (usuarios de menores de trece años en los EE.UU., por ejemplo).
Determinar y documentar la criticidad del sistema: safety-critical/mission-
critical/non-critical

Establecer sistemas de seguridad crítica vive en peligro en caso de avería o mal

funcionamiento. Establecer sistemas de dinero de misión crítica, la cuota de
mercado, o el capital en riesgo en caso de fallo. Los sistemas no críticos tienen
pocas o ninguna consecuencia en caso de fracaso.

21.6.1 Entradas de seguridad  Lista de las políticas de seguridad aplicables 

  Lista de las jurisdicciones aplicables  Planes de recuperación de desastres
completa y la continuidad del negocio 

Las salidas de seguridad 21.6.2  Declaración entorno de seguridad física 

      Declaración entorno de seguridad de negocios  Declaración Entorno
regulatorio  Carta de la política de seguridad firmado por el consejero delegado o
delegada  Lista de los puntos de control de desarrollo de la arquitectura de
seguridad de cierre de sesión  Lista de los planes de recuperación de desastres y
continuidad de negocio aplicable  Declaración Sistemas criticidad 

21.7 Fase B: Arquitectura de Negocios

Determinar quiénes son los actores legítimos que interactuarán con el producto /
servicio / proceso
Elaboración de los escenarios de negocio y posteriores de alto nivel casos de uso
del proyecto en cuestión traerá a la atención de las personas protagonistas y
actores del sistema implicados. Muchos ulteriores decisiones sobre la autorización
se basará en una sólida comprensión de los presuntos usuarios, administradores y
operadores del sistema, además de sus capacidades y características esperadas. Se
debe tener en cuenta que los usuarios pueden no ser

  Página 207 de 670 

TOGOF 9.1    
los seres humanos; aplicaciones de software pueden ser los usuarios legítimos. Los
que cuidaban a las necesidades administrativas, tales como operadores de copia de
seguridad, también deben ser identificados, ya que los usuarios deben límites
externos de confianza, tales como los clientes basados en Internet.
Evaluar y los procesos de negocio específicos de seguridad de línea de base
actuales (mejora de objetivo existente)

El proceso de negocio con respecto a cómo los actores son investigados ya que los
usuarios adecuados del sistema debe documentarse. También se debe hacer para los
actores de fuera de la organización que son usuarios propios del sistema. Las
entidades externas se determinarán a partir de los escenarios de alto nivel
desarrollados como parte de la Fase A.
Determinar los cuales / cuánto es aceptable para inconveniente en la utilización de
medidas de seguridad

Las medidas de seguridad, si bien son importantes, pueden imponer una carga sobre
los usuarios y el personal administrativo. Algunos responderán a esa carga mediante
la búsqueda de formas de burlar las medidas. Algunos ejemplos son los
administradores de encontrar maneras de crear "puertas traseras" o los clientes que
eligen un competidor para evitar la carga percibida de la infraestructura. Las
compensaciones pueden requerir equilibrar las ventajas de seguridad en contra de
ventajas comerciales y exigir una elección juiciosa informado.
Identificar y documentar los sistemas de interconexión más allá del control del
proyecto

Cada sistema cibernético o negocio debe basarse en los sistemas existentes más allá
del control del proyecto. Estos sistemas tienen ventajas y desventajas, riesgos y
beneficios. Los ejemplos incluyen el sistema de nombres de dominio (DNS) que
resuelve nombres de equipos y de servicios a las direcciones de Internet, o el
papel moneda emitido por la Tesorería local. La dirección devuelta por el anfitrión
o el servicio DNS no siempre puede ser digno de confianza; papel moneda no siempre
puede ser genuina, y el recurso varía en la eficacia entre las jurisdicciones.
Estas interfaces deben ser entendidos y documentados.
Determinar los activos en riesgo, si algo sale mal - "¿Qué estamos tratando de
proteger?"

Activos no siempre son tangibles y no siempre son fáciles de cuantificar. Algunos

ejemplos son: la pérdida de la vida, la pérdida de la buena voluntad del cliente,
la pérdida de una calificación de bonos AAA, la pérdida de cuota de mercado.
Determinar el costo (tanto cualitativa como cuantitativa) de la pérdida de
activos / impacto en casos de insuficiencia

Hay que recordar que dichos activos más difíciles de cuantificar pueden ser el más
valioso y no debe ser descuidado. Incluso las estimaciones cualitativas resultar
útiles en la evaluación de los riesgos comparativos.
Identificar y documentar la propiedad de los activos
Los activos pueden ser propiedad de entidades externas, o por entidades de su
interior. Dentro entidades pueden ser propiedad de los individuos o de las
organizaciones.Determine:

  Página 208 de 670 

TOGOF 9.1    
   ¿Dónde se supone que la confianza  ¿Cómo se establece  ¿Cómo se comunica 

Siempre rastrearlo con el mundo real; es decir:   Evaluación (búsquedas de

crédito, que dé fe personal)  Responsabilidad civil (daños monetarios, penas de
cárcel, sanciones) 

Todas las decisiones de seguridad se basan en la confianza que se ha establecido de

alguna manera. No hay supuestos fiduciarios tienen ningún valor si no pueden tener
sus raíces en la evaluación y la responsabilidad en el mundo real. En la mayoría de
los entornos de negocio, la confianza se establece a través de contratos que
definen la responsabilidad cuando se rompe la confianza. La responsabilidad de la
evaluación de la confianza es la responsabilidad de los que decidan entrar en los
contratos y sus abogados. Es importante tener en cuenta que la tecnología (por
ejemplo, certificados digitales, SAML, etc) no puede crear confianza, pero sólo se
puede transmitir en el mundo de la electrónica de la confianza que ya existe en el
mundo real a través de las relaciones comerciales, acuerdos legales y consistencias
de política de seguridad .

Determinar y documentar los procesos forenses de seguridad apropiado

Para ser capaces de hacer cumplir las políticas de seguridad, infracciones de

seguridad deben ser adecuadamente capturados por lo que la determinación de
problemas y posibles políticas o acciones legales se pueden tomar contra la entidad
que causa el incumplimiento. Prácticas forenses adecuados para proporcionar
evidencia en su caso la necesidad de ser establecida y documentada. El personal de
seguridad deben estar capacitados para seguir los procedimientos forenses y
material de capacitación sobre la necesidad de reunir pruebas debe ser considerado
para la educación de seguridad estándar proporcionada a los trabajadores.
Identificar la criticidad de la disponibilidad y el correcto funcionamiento del
servicio en general

Los riesgos asociados con la pérdida de la disponibilidad pueden ya han sido

adecuadamente considerados en la evaluación mission-critical/safety-critical
anterior.
Determinar y documentar cuánta seguridad (coste) se justifica por las amenazas y el
valor de los activos en riesgo

Un análisis de riesgos (la comprensión del valor de los activos en riesgo y la

probabilidad de las amenazas potenciales) proporciona una guía importante para las
inversiones en estrategias de mitigación para las amenazas identificadas.
Vuelva a evaluar y confirmar las decisiones Architecture Vision

  Página 209 de 670 

TOGOF 9.1    
El análisis de negocios implica una serie de ejercicios de pensamiento riguroso y
puede poner en cuestión los supuestos iniciales identificadas en el Architecture
Vision.
Evaluar la alineación o conflicto de las políticas de seguridad identificados con
los objetivos empresariales
Las políticas de seguridad identificadas en la Fase Preliminar pueden tener
disposiciones que son difíciles o imposibles de conciliar con los objetivos de
negocio a la luz de los riesgos identificados. Las posibles respuestas incluyen la
alteración de los aspectos del entorno empresarial, la modificación de la población
de usuarios prevista, o técnico de mitigación de riesgos (tratados en la Fase C).
Determinar "lo que puede salir mal?"

Realizar un análisis de las amenazas que identifica las amenazas de alto nivel que
influyan en el sistema y su probabilidad.

21.7.1 Entradas de seguridad  Declaraciones de negocios y el medio ambiente de

seguridad reglamentario inicial 
  Lista de los planes de recuperación de desastres y continuidad de negocio
aplicable  Lista de las políticas y normas de seguridad aplicables 

Las salidas de seguridad 21.7.2  Lista de los procesos forenses 

            Lista de los nuevos requisitos de recuperación de desastres
y continuidad del negocio  Declaraciones de negocios y de entorno regulatorio
validados  Lista de las políticas y normas de seguridad validadas  Lista de los
procesos de seguridad de destino  Lista de los procesos de seguridad de línea de
base  Lista de los actores de la seguridad  Lista de los sistemas de interconexión 
Declaración de la tolerancia de seguridad para cada clase de agente de seguridad 
Lista de activos con los valores y los propietarios  Lista de rutas de confianza 
Declaración de impacto Disponibilidad (s)  Matriz de análisis de amenazas 

21.8 Fase C: Arquitecturas de Sistemas de Información

  Página 210 de 670 

TOGOF 9.1    
Evaluar y elementos de referencia actuales de seguridad específicas de la
arquitectura (de mejora de objetivo existente)

Un inventario completo de los elementos de la arquitectura que implementan

servicios de seguridad debe ser compilado en la preparación de un análisis de
brecha.
Identificar acciones predeterminadas seguras y estados de fallo

Cada cambio de estado en cualquier sistema se precipita por algún disparador. Por
lo general, un conjunto enumerado de los valores esperados de ese gatillo inicia un
cambio en el estado. Sin embargo, hay probablemente otras entradas de disparo
potenciales que deben ser acomodados en los casos no normativas. Además, un fallo
del sistema puede tener lugar en cualquier momento en el tiempo. Acciones
predeterminadas seguras y modos de falla deben ser definidas para el sistema
informado por el estado actual, el entorno empresarial, las políticas aplicables y
obligaciones reglamentarias. Modos predeterminados de seguros para un automóvil a
velocidad cero ya no sean aplicables a toda velocidad. Estados de insuficiencia de
seguros para los dispositivos médicos difieren notablemente de los estados de fallo
de seguridad para la electrónica de consumo.
Identificar y evaluar las directrices y normas reconocidas aplicables

Las normas son justamente acredita para la reducción de costes, la mejora de la

interoperabilidad, y el aprovechamiento de la innovación. Desde el punto de vista
de seguridad, protocolos estándar, bibliotecas de objetos estándares e
implementaciones estándar que han sido examinados por expertos en sus campos ayudan
a asegurar que los errores no encuentran su camino en las implementaciones. Desde
un punto de vista de la seguridad, los errores son las vulnerabilidades de
seguridad.
Revisar las suposiciones relativas a los sistemas de interconexión más allá del
control del proyecto

A la luz de las evaluaciones de riesgos realizadas, supuestos relativos a los

sistemas de interconexión puede ser necesario modificar.
Determinar y documentar el nivel de sensibilidad o de la clasificación de la
información almacenada / creado / usado

La información almacenada, creado o manipulado por el sistema puede o no puede ser

objeto de una clasificación oficial que define su sensibilidad y las obligaciones a
las que el sistema y sus propietarios están sometidas. La ausencia de una
clasificación oficial no exime necesariamente la responsabilidad en el
mantenimiento de la confidencialidad de los datos. La consideración se debe hacer
para los diferentes carga legislativa que pueda sostener la jurisdicción sobre el
sistema y los datos almacenados.
Identificar y custodia de documentos de los activos

Todos los activos de valor sean conservados y mantenidos en nombre del propietario.
Las personas u organizaciones específicas encargadas de esta responsabilidad deben
ser identificados.
Identificar la criticidad de la disponibilidad y el correcto funcionamiento de cada
función

  Página 211 de 670 

TOGOF 9.1    
Es de suponer que, en caso de fallo del sistema o la pérdida de funcionalidad,
algún valor se pierde a los interesados. El costo de esta pérdida de oportunidad
debe ser cuantificada, si es posible, y se documenta.
Determinar la relación del sistema en fase de diseño de los planes de negocios de
desastres / continuidad existentes

Planes de desastre en el negocio / de continuidad existentes pueden acomodar el

sistema considerado. Si no, algunos análisis se llama para determinar la brecha y
el costo si esa brecha se va sin llenar.
Identificar qué aspectos del sistema debe ser configurable para reflejar los
cambios en el control de la política de medio ambiente / negocio / acceso

Sin medio ambiente es estática y sistemas debe evolucionar para adaptarse a los
cambios. Sistemas con arquitectura de listo reconfiguración se reflejan mejor que
el cambio y el resultado en un menor costo durante la vida útil del sistema. La
seguridad se mejora cuando los cambios relacionados con la seguridad se pueden
implementar a bajo costo y son, por lo tanto, no dejados de lado. La seguridad
también se ve reforzada cuando los cambios no requieren cambios en el código;
cambios en el código introducen insectos y bichos introducir vulnerabilidades de
seguridad.
Identificar la vida útil de la información utilizada según la definición de las
necesidades del negocio y los requisitos reglamentarios

La información mantenida más allá de su vida útil representa un desperdicio de

recursos y, potencialmente, las decisiones de negocio basadas en datos
subóptimos.Reglamento, sin embargo, a veces obliga el calendario de mantenimiento
de la información como datos de archivo.
Determinar los enfoques para hacer frente a los riesgos identificados:

   

Mitigar  Aceptar  Transferencia  Evitar 

Hay varias formas estándar para hacer frente a los riesgos identificados y
cuantificados. La lista anterior no pretende ser exhaustiva de todos los enfoques.
Identificar las acciones / eventos que merecen el registro para su posterior
revisión o desencadenar procesos forenses

Acciones anómalas y estados superarán en número a las acciones y los estados

previstos. Estas transiciones se justifica la tala de reconstruir cadenas de
eventos, facilitar el análisis de la causa raíz, y, posiblemente, establecer
pruebas para la acción civil o penal. Hay que tener en cuenta que los registros
deben ser revisados regularmente para ser introducido como evidencia en una corte
de la ley en algunas jurisdicciones.

  Página 212 de 670 

TOGOF 9.1    
Identificar y los requisitos de documentación para demostrar el rigor en la
precisión de los eventos registrados (no repudio)

Desde manipulación malintencionada de los sistemas comúnmente se acompaña de

alteración de los datos registrados para frustrar la investigación y de la
aprehensión, la capacidad de proteger y establecer la veracidad de los registros a
través de métodos criptográficos eliminará la incertidumbre de las investigaciones
e impulsar los casos en los procedimientos judiciales.

Identificar potenciales probables vías de ataque /

Pensar como un adversario preparará el arquitecto para la creación de un sistema

robusto que resiste la manipulación maliciosa y, providencialmente, mal
funcionamiento derivado de error aleatorio.
Determinar "lo que puede salir mal?"

21.8.1 Entradas de seguridad  Matriz de análisis de amenazas 

     El análisis de riesgos  Procesos forenses Documentados  Políticas y
regulaciones comerciales validados  Lista de los sistemas de interconexión  Nuevos
requisitos de recuperación de desastres y continuidad del negocio 

Las salidas de seguridad 21.8.2  Evento de la matriz y los requisitos de

nivel de registro 
      Estrategia de gestión de riesgos  Definiciones de ciclo de vida de
datos  Lista de los elementos del sistema configurables  Lista básica de los
elementos relacionados con la seguridad del sistema  Elementos nuevos o aumentados
relacionados con la seguridad del sistema  Seguridad modelos de casos de uso:  o o
 Los modelos normativos  Los modelos no normativos 

Relación de normas de seguridad aplicables: 

  Página 213 de 670 

TOGOF 9.1    
o o o       Protocolos  Bibliotecas de objetos  Otros ... 

Lista del sistema interconectado Validado  Informe de clasificación Información 

Lista de los depositarios de activos  Instrucción Function criticidad  Planes de
recuperación de desastres y continuidad del negocio revisado  Matriz de análisis de
amenazas refinado 
21.9 Fase D: Architecture Tecnología
Evaluar y tecnologías específicas de seguridad actuales de referencia (mejora de
objetivo existente) Revisar las suposiciones relativas a los sistemas de
interconexión más allá del control del proyecto Identificar y evaluar las
directrices y normas reconocidas aplicables Identificar los métodos para regular el
consumo de los recursos

Cada sistema se basará en los recursos que puede estar agotada en los casos que
pueden o no pueden preverse en el punto de diseño del sistema. Los ejemplos
incluyen el ancho de banda de red, carga de la batería, espacio en disco, la
memoria disponible, y así sucesivamente. Como se utilizan los recursos que se
acerca el agotamiento, la funcionalidad puede verse afectada o puede fallar por
completo. Pasos de diseño que identifican los recursos no renovables, métodos que
pueden reconocer el agotamiento de recursos, y las medidas que pueden responder a
través de la limitación de los factores causales, oa través de la limitación de los
efectos del agotamiento de los recursos a la funcionalidad no crítica, pueden
mejorar la fiabilidad y la disponibilidad generales de la sistema.
Diseñar un método por el cual se medirá la eficacia de las medidas de seguridad y
se comunica de forma continua

Dado que los sistemas se despliegan y operan en entornos dinámicos, las medidas de
seguridad funcionan según distintos grados de eficacia que surgen amenazas
inesperadas y como amenazas esperados cambian en el medio ambiente. Un método que
facilita la evaluación continua del valor de las medidas de seguridad informará a
los cambios en curso en el sistema en respuesta a las cambiantes necesidades de los
usuarios, patrones de amenaza y los problemas encontrados.
Identificar la confianza (holgura) nivel de:

 

Todos los usuarios del sistema  Todos los administradores del sistema 

  Página 214 de 670 

TOGOF 9.1    
 Todos los sistemas de interconexión más allá del control del proyecto 

Los requisitos reglamentarios, los niveles de clasificación de la información, y

las necesidades empresariales de los propietarios de activos influirán el nivel
requerido de confianza que se necesitarán todas las entidades interactivas que
cumplir para calificar para el acceso a datos o servicios.
Identificar los privilegios mínimos necesarios para cualquier entidad para lograr
un objetivo técnico o empresarial

La concesión de las capacidades de radicales a cualquier usuario, aplicación, u

otra entidad puede simplificar finalización transacción exitosa a costa de
complicar o que impiden el control y la auditoría eficaz. Muchas obligaciones
reglamentarias son más difíciles de demostrar el cumplimiento donde los privilegios
están barriendo y los controles están sueltos.
Identificar las medidas de mitigación de seguridad, cuando esté justificado por la
evaluación de riesgos

Este objetivo es donde los servicios de seguridad clásicos de identificación,

autenticación, autorización, confidencialidad de datos, integridad de los datos, no
repudio, la seguridad y la auditoría se ponen en juego, después de que se determine
su aplicabilidad y la relación costo / valor de la protección de su identificación.
Determinar "lo que puede salir mal?"
21.9.1 Entradas de seguridad  Lista de elementos relacionados con la seguridad
del sistema 
       Lista de los sistemas interconectados  Relación de normas de
seguridad aplicables  Lista de los actores de la seguridad  Estrategia de gestión
de riesgos  Políticas de seguridad validadas  Requisitos reglamentarios validados 
Políticas de negocio validados relacionados con la confianza requisitos 

Las salidas de seguridad 21.9.2  Lista básica de las tecnologías de

seguridad 
    Lista de sistemas interconectados Validado  Lista de las normas de
seguridad seleccionadas  Plan de conservación de recursos  Métricas de seguridad y
plan de monitoreo 

  Página 215 de 670 

TOGOF 9.1    
   Las políticas de autorización del usuario  Plan de gestión de riesgos  La
confianza del usuario requisitos (despacho) 

21.10 Fase E: Oportunidades y Soluciones

Identificar los servicios de seguridad existentes disponibles para su reutilización

A partir de la arquitectura de seguridad de línea de base y la empresa Continuum,

habrá infraestructura de seguridad existente y bloques de construcción de la
seguridad que se puede aplicar a las exigencias derivadas de este compromiso el
desarrollo de la arquitectura. Por ejemplo, si existe el requisito para el control
de acceso de la aplicación externa a una aplicación en desarrollo, y ya existe un
sistema de este tipo, que puede ser utilizado de nuevo. Los requisitos legales o
reglamentarios pueden exigir la separación física de los dominios que puede
eliminar la posibilidad de volver a utilizar la infraestructura existente. Los
productos conocidos, herramientas, bloques de construcción, y los patrones se
pueden utilizar, aunque de reciente aplicación.
Medidas de mitigación que aborden Ingeniero riesgos identificados

Habiendo determinado los riesgos susceptibles de mitigación y evaluado la inversión

apropiada en que la mitigación en lo que respecta a los activos en riesgo, las
medidas de mitigación deben ser diseñados, implementados, desplegados y / u
operados.
Evaluar software de seguridad reutilizables y recursos del sistema de seguridad
probado y

Desde el diseño, código, y los errores de configuración son las raíces de muchas
vulnerabilidades de seguridad, aprovechando cualquier solución de problemas ya
diseñada, revisados, probados y probados en campo reducirá la exposición a la
seguridad y mejorar la fiabilidad.
Identificar nuevos códigos / recursos / activos que son apropiados para la
reutilización

Rellenar el repositorio Arquitectura con nuevos bloques de construcción de la

seguridad.
Determinar "lo que puede salir mal?"

21.11 Fase F: planeamiento de migración

Evaluar el impacto de las nuevas medidas de seguridad sobre otros componentes
nuevos o sistemas apalancados existentes

En una aplicación gradual de los nuevos componentes de seguridad son generalmente

parte de la infraestructura en la que se implementa el nuevo sistema. La
infraestructura de seguridad tiene que estar en una primera fase o principios para
apoyar adecuadamente el proyecto.
Implementar métodos de supervisión mediante las cuales se medirá la eficacia de las
medidas de seguridad y comunicada en forma permanente

  Página 216 de 670 

TOGOF 9.1    
Durante las fases de operación, mecanismos son utilizados para monitorear el
desempeño de muchos aspectos del sistema. Su seguridad y la disponibilidad no son
una excepción.
Identificar parámetros correctos seguras de instalación, las condiciones iniciales
y las configuraciones

La seguridad de cualquier sistema que no depende del diseño y puesta en práctica

por sí sola, sino también después de la instalación y el estado operativo. Estas
condiciones deben ser definidas y controladas no sólo en la implementación, sino
también en toda la operación.
Implementar la recuperación de desastres y planes de continuidad del negocio o
modificaciones Determinar "lo que puede salir mal?"

21.12 Fase G: Gobernanza Aplicación

Establecer artefacto arquitectura, el diseño, y las revisiones de código y definir
los criterios de aceptación para la implementación exitosa de los hallazgos

Muchas vulnerabilidades de seguridad se originan como diseño o errores de código y

el método más simple y menos costosa para localizar y encontrar estos errores es
generalmente una pronta revisión por pares con experiencia en el oficio.
Localización de tales errores, por supuesto, es el primer paso y la aplicación de
correcciones a un punto apropiado en el ciclo de vida de desarrollo es necesaria
para beneficiarse de la inversión. Seguimiento de las inspecciones o revisiones de
aceptación formalizados puede justificarse en entornos de alta seguridad o de
seguridad críticos.
Implementar métodos y procedimientos para revisar las pruebas aportadas por el
sistema que refleja la estabilidad operativa y la adhesión a las políticas de
seguridad

Si bien es necesario que todos los aspectos de una empresa exitosa planificación y
especificación, son insuficientes ante la ausencia de pruebas y auditoría para
garantizar el cumplimiento de que la planificación y especificación tanto por su
despliegue y operación. Entre los métodos que se deben ejercer son: 
Configuraciones del sistema de revisión con impacto en la seguridad que pueden ser
modificados para garantizar los cambios de configuración no se han puesto en
peligro la seguridad del diseño  Auditar el diseño, la implementación y las
operaciones contra las políticas de seguridad  Auditar el diseño, la implementación
y las operaciones contra objetivos de negocio  Ejecutar casos de prueba en contra
de sistemas que garanticen los sistemas de seguridad se han implementado tal como
fue diseñado  Ejecute las pruebas de recuperación de desastres  Ejecute las pruebas
de continuidad de negocio 

    

Implementar la capacitación necesaria para asegurar la implementación correcta, la

configuración y el funcionamiento de los subsistemas y componentes relevantes para
la seguridad; garantizar la

  Página 217 de 670 
TOGOF 9.1    
formación de la conciencia de todos los usuarios y los operadores no privilegiados
del sistema y / o sus componentes

La formación no es necesario simplemente para impedir vulnerabilidades introducidas

a través de operaciones y error de configuración, aunque esto es crítica para
corregir el rendimiento seguro en curso. En muchas jurisdicciones, una formación
adecuada debe realizarse y documentarse para demostrar la debida diligencia y
justificar las medidas correctivas o sanciones en los casos en que explota o los
objetivos de negocio de compromiso de error o para absolver a la responsabilidad
contributiva para los eventos que provocan un daño o lesión.
Determinar "lo que ha ido mal?"

El propósito mismo de la gobernanza es el establecimiento de un sistema de

retroalimentación que determina la eficacia de la ejecución del plan y aplica
correcciones, cuando se requiera. Hay que tener en cuenta que las imperfecciones en
los planes ejecutados están arraigadas tanto en los procesos humanos y los procesos
cibernéticos.

21.13 Fase H: Gestión Arquitectura Cambio

Como se indica en la Parte II , 17. Arquitectura ADM Requisitos de gestión (gestión
de requisitos), el cambio se debe a las nuevas necesidades. Los cambios en los
requisitos de seguridad son a menudo más perjudicial que una simplificación o
cambio incremental. Los cambios en la política de seguridad pueden ser conducidos
por el estatuto, reglamento, o algo que se ha hecho mal. Los cambios en las normas
de seguridad son por lo general menos perjudicial desde el trade-off para su
adopción se basa en el valor de cambio. Sin embargo, los cambios en estándares
también pueden ser obligatorias. Enfoques similares a estos cambios, como se
menciona más arriba son buenas reglas de oro para la seguridad también. Sin
embargo, los cambios de seguridad son a menudo los cambios de infraestructura, y
pueden tener un mayor impacto. Un cambio aparentemente pequeño requisito de
seguridad puede provocar fácilmente un nuevo ciclo de desarrollo de la
arquitectura.
Determinar "lo que ha ido mal?"

Buenas prácticas forenses de seguridad en conjunto con una política de seguridad

publicada por escrito hacen determinación de lo que ha ido mal posible. Además,
hacen que la aplicación sea posible. A medida que la orientación anterior sugiere,
pequeños cambios se pueden hacer en el contexto de la gestión del cambio y los
principales cambios requerirán un nuevo esfuerzo de la arquitectura.
Incorporar los cambios pertinentes a la seguridad para el medio ambiente en los
requisitos para la futura mejora (mejora de objetivo existente)

Los cambios que surgen como consecuencia de un problema de seguridad o una nueva
tecnología de seguridad se utilizarán en el proceso de gestión de requisitos.

21,14 Referencias
 NIST 80018: Guía para el desarrollo de Planes de Seguridad para Sistemas
Informáticos 

  Página 218 de 670 

TOGOF 9.1    
  NIST 80027: Principios de Ingeniería de Tecnologías de Seguridad Informática
(una línea de base para el logro de la seguridad)  NIST 80030: Guía para la Gestión
de Riesgos de Sistemas Informáticos 
  Página 219 de 670 

TOGOF 9.1       

22. Uso de TOGAF para definir y Gobierno SOAs 22.1 Información general
En este capítulo se describen:    Service-Oriented Architecture (SOA) como un
estilo arquitectónico  Factores relacionados con la adopción y la implementación de
SOA en la empresa  Usando el TOGAF Arquitectura Método de Desarrollo (ADM) para
desarrollar su SOA 

En este capítulo, en su caso, se incluyen referencias a las Normas Técnicas y Guías

desarrolladas por el Grupo de Trabajo SOA Open Group.

22.2 Introducción
A medida que el ambiente de negocios se vuelve más sofisticada, los desafíos que
enfrentan las organizaciones están pasando de cuestiones de eficiencia y
automatización hacia las cuestiones de la gestión de la complejidad y la agilidad
del negocio. Redes complejas de aplicaciones e interfaces existentes crean paisajes
de gran complejidad donde el cambio se vuelve más y más difícil y los impactos del
cambio se vuelven más difíciles de predecir y entender. El concepto de SOA ofrece
un estilo arquitectónico que se destina específicamente para simplificar el negocio
y la interoperación de diferentes partes de ese negocio. Al estructurar la
capacidad de los servicios significativos, granulares en oposición a, unidades de
negocio silo'ed opacos, se hace posible identificar rápidamente las capacidades
funcionales de una organización, evitar la duplicación de funciones similares a
través de la organización y de montar rápidamente nuevas capacidades. Al
estandarizar el comportamiento y la interoperabilidad de los servicios, es posible
limitar los efectos del cambio y también para entender por adelantado la cadena de
probabilidades de impactos. Desde una perspectiva de desarrollo de software, SOA se
centra en las aplicaciones de la estructuración de una manera que facilita la
flexibilidad del sistema y la agilidad - Una necesidad en el entorno complejo y de
rápido movimiento de hoy del negocio. SOA pretende romper los silos de aplicaciones
tradicionales en las carteras de servicios más granulares que operan en formas
abiertas e interoperables, mientras que la extracción de la capacidad de los
productos básicos en una plataforma de infraestructura virtual de los servicios
públicos reutilizables compartidos.

  Página 220 de 670 

TOGOF 9.1    

22.3 SOA Definición

Nota:  Esta sección se proporciona para conveniencia del lector. Parte I , 3.
Definiciones deberían remitirse a las definiciones formales.  Arquitectura
Orientada a Servicios (SOA) es un estilo arquitectónico que apoya la orientación a
servicios. La orientación a servicios es una manera de pensar en términos de
servicios y el desarrollo basado en el servicio y los resultados de los servicios.
Un servicio es una representación lógica de una actividad de negocio repetible que
tiene un resultado específico (por ejemplo, verificación de crédito del cliente,
proporcionar datos meteorológicos, consolidar los informes de perforación, etc) y:
   Es autónomo  Puede estar compuesto de otros servicios  Es un "recuadro negro"
para los consumidores del servicio 

Un estilo arquitectónico es la combinación de características distintivas en que se

realiza o se expresa la arquitectura.

22.4 Características de SOA

SOA se basa en el diseño de los servicios - que reflejan las actividades
empresariales del mundo real - que comprenden la empresa (o entre empresas) los
procesos de negocio. Representación del Servicio utiliza descripciones
empresariales para proporcionar el contexto (es decir, los procesos de negocio,
meta, regla, política, interfaz de servicio, componente de servicio, etc.) SOA
coloca requisitos únicos de la infraestructura. Debido a esto, se recomienda que
las implementaciones utilizan estándares abiertos para darse cuenta de la
interoperabilidad y la transparencia de ubicación. Por ejemplo, la disponibilidad
de servicios de alguna manera debe ser documentado en un lugar de fácil acceso en
las que requieren el uso de esos servicios. Un servicio de directorio en SOA
específico y un Enterprise Service Bus (ESB) son dos ejemplos de implementaciones
de tecnología que requieren la adhesión a los estándares abiertos relevantes para
la interoperabilidad que SOA promete. Las implementaciones son específica del
entorno de la empresa - que se ven limitados o habilitadas por el contexto y deben
ser descritas dentro de ese contexto. Teniendo en cuenta que, SOA requiere un
gobierno fuerte de la representación de servicios y la ejecución.

22.5 Arquitectura Empresarial y SOA

  Página 221 de 670 

TOGOF 9.1    
Arquitectura Enterprise proporciona marcos, herramientas y técnicas para ayudar a
las organizaciones en el desarrollo y mantenimiento de sus SOAs. Algunos de los
beneficios clave que la arquitectura empresarial ofrece son:   Abstracciones
coherentes de estrategias de alto nivel y las prestaciones de apoyo a la
planificación y el análisis  Vinculación de las diferentes perspectivas a un
problema de negocio único (por ejemplo, los negocios, los sistemas de información,
la tecnología, la amplitud, la profundidad, el nivel de detalle, etc) que
proporcionan un modelo coherente para hacer frente a diversos dominios y pruebas de
integridad  Identificación de las hojas de ruta claras para lograr el estado
futuro  Trazabilidad que las TI y otros activos se vincula a los negocios que
apoyan  El apoyo a la evaluación del impacto, análisis de riesgo / valor, y la
gestión de carteras  Principios identificados y documentados, las limitaciones, los
marcos, patrones y normas  Los marcos de gobernanza y procesos que aseguren la
autoridad competente para la toma de decisiones 

    

Arquitectura empresarial se convierte en una base para el servicio-orientar una

organización, porque vincula partes interesadas, asegurando que las necesidades de
cada comunidad de partes interesadas que se cumplan y que cada comunidad de
interesados es consciente del contexto apropiado. Esta vinculación es la base para
la interoperabilidad y la reutilización. A través de su vinculación al contexto
empresarial para TI, arquitectura empresarial permite identificar con facilidad y
proporciona justificación para el costo de los programas de cambio en relación con
el valor de negocio que se derivan de la pena. Arquitectura empresarial puede
proporcionar las capacidades de contexto y análisis de:    Mostrar cómo las
soluciones de SOA pueden con arquitectura eficaz para apoyar las capacidades
empresariales  Mostrar que los servicios deben ser construidos y que se debe volver
a utilizar  Mostrar cómo los servicios deben ser diseñados 

Sin arquitectura de la empresa, los efectos negativos pueden incluir uno o más de
los siguientes:       Agilidad Limited  Dificultad para la identificación y
la orquestación de servicios SOA  La expansión de servicios  Crecimiento
exponencial desafíos de la gobernanza  Limited interoperabilidad de servicios SOA 
SOA servicio de reutilización limitada 
  Página 222 de 670 

TOGOF 9.1    
  Múltiple silo'ed SOAs  Dificultad evolucionando y cambiando las
implementaciones de SOA 

22.6 SOA y Niveles

El tamaño y la complejidad de una empresa afecta a la forma en que la EA desarrolla
su arquitectura. Donde hay muchos diferentes modelos organizativos y empresariales,
no es práctico para integrarlos dentro de una única arquitectura. Hay muy pocos
elementos de la infraestructura, con la excepción de la Internet y la World Wide
Web, quese pueden aplicar en la totalidad de una gran organización. Incluso éstos
sólo proporcionan un nivel básico de apoyo a los procesos de negocio. En general,
puede no ser apropiado para desarrollar un único SOA integrada para una empresa
grande y compleja. Para tal empresa, asumiendo una arquitectura del paisaje como se
muestra en la Figura 20-1 , el arquitecto debe buscar primero en el desarrollo de
una arquitectura estratégica que da un resumen descripción formal de la empresa,
proporcionando un marco de organización de la actividad operativa y el cambio, y un
ejecutivo nivel, visión a largo plazo para el ajuste de la dirección. Esto podría,
por ejemplo, identificar segmentos particulares donde se debe utilizar SOA, y la
convocatoria de uso de los servicios para la interacción entre los segmentos, pero
es muy poco probable para especificar determinados servicios o grupos de servicios,
o para prescribir una infraestructura detallada para SOA. El arquitecto podría
entonces desarrollar arquitecturas de segmentos, cada uno de los cuales da una
descripción detallada y formal de las áreas dentro de una empresa, que se utiliza a
nivel de programa o de una cartera de organizar y alinear la actividad de cambio.
Cada una de estas arquitecturas segmento podría ser un único, SOA integrada. Para
una empresa pequeña y menos compleja cuyo negocio operaciones puede compartir una
infraestructura común, puede usar TOGAF para crear una SOA integrada con grupos de
servicios de apoyo a las actividades empresariales. A partir de aquí se supone que
el alcance sea una empresa de este tipo. Podría ser autopermanente o de un segmento
de una empresa más grande.

22.6.1 Nivel de detalle de Especificación de Implementación

¿Cómo se debe por completo la arquitectura de definir lo que para poner en
práctica? En un extremo, se podría especificar el futuro de la empresa, y definir
todos los cambios para alcanzar el objetivo, incluidos los proyectos que producirán
los cambios, y un plan detallado de tiempo. En el otro extremo, sólo puede indicar
áreas donde se necesita trabajo, y sugerir prioridades para abordarlos.
Arquitectura desarrollo podría caer en cualquier lugar entre estos dos extremos.
Para el tipo de SOA empresarial que estamos considerando aquí, es probable que se
especificaría la infraestructura y definir los proyectos para su ejecución, con un
plan detallado de tiempo. Usted puede hacer lo mismo para todas o algunas de las
soluciones. Por otra parte, en particular cuando la agilidad es importante, es
posible identificar las soluciones, y tal vez especifica las versiones iniciales de
los mismos, pero permiten soluciones adicionales para ser identificados más tarde,
y para los proyectos de implementación para desarrollar más versiones de las
soluciones sin tener que pedir cambios en el arquitectura.

  Página 223 de 670 

TOGOF 9.1    
22.6.2 Actividades de SOA en los diferentes niveles
En el ámbito de la arquitectura estratégica de la cuestión básica de SOA es
identificar si necesita SOA y en la que los segmentos. En la arquitectura
estratégica que identifique:         Las relaciones de alto nivel y los
límites dentro de la organización  (Se necesita qué información y funcionalidad a
través de segmentos) los requisitos de capacidad SOA Cross-segmento  Entre las
principales funcionalidades mejor tratadas por SOA  Las capacidades clave
necesarias para SOA  Segmentos mejor abordados por SOA  Principios y patrones de
desarrollo de los servicios SOA y la descripción, que pueden ser definidas a nivel
de segmento y la capacidad  Las funciones, responsabilidades, procesos y
herramientas de gobierno de SOA  La Arquitectura de referencia específica de la
organización 

A nivel de segmento la cuestión básica de SOA describe la estructura de la

arquitectura SOA. En las Arquitecturas Segmento definimos:      ¿Qué
capacidades utilizarán SOA como un estilo de la arquitectura  (Se necesita qué
información y funcionalidad a través de capacidades) relaciones cruzadas de
capacidad  (Se necesita qué información y funcionalidad a través de segmentos)
relaciones más detalladas segmentación cruzada  Servicios SOA Cross-capacidad de
las posibilidades de reutilización  Principios y patrones de desarrollo de los
servicios SOA y la descripción, que pueden ser definidos en el Plan Estratégico y
los niveles de capacidad; es más común para definir estos como parte de la
arquitectura del Segmento 

Para Arquitectura Capability la cuestión básica de SOA es que los servicios estarán
disponibles. En las arquitecturas de capacidad describiremos:      Los
requisitos funcionales y no funcionales de la capacidad  Requisitos de servicio SOA
Cross-capacidad  Servicios SOA que permiten cruzada capacidad de reutilización 
Servicios SOA que permiten la capacidad  Principios y patrones de desarrollo de los
servicios SOA y la descripción, que pueden ser definidos a nivel estratégico y de
segmento 

  Página 224 de 670 

TOGOF 9.1    
Independientemente del nivel de ser perseguido arquitectura es posible identificar
soluciones SOA que mejor servicio de las necesidades de la empresa.

22.7 Uso de TOGAF para SOA

En esta sección se describe, para cada fase del TOGAF ADM, lo que debe considerarse
cuando se busca aplicar el principio de la orientación a servicios, y cómo esto
afecta a la fase. Esto no pretende ser una descripción autónomo y debe leerse en
conjunción con otras secciones de este documento.

22.7.1 Fase Preliminar

La fase preliminar es cuando la capacidad Arquitectura está adaptado para soportar
SOA. Los resultados clave de esta fase son los principios, la estructura
organizativa, la gobernanza y el contenido inicial de la arquitectura de
repositorio.
22.7.1.1 Principio de la Orientación a Servicios

El punto de partida para el desarrollo de SOA con TOGAF es que la empresa adopta la
orientación a servicios, como principio la arquitectura (véase el Principio 6:
Servicio de Orientación ). Una empresa que desee utilizar TOGAF para SOA debe
incluir este principio, ya sea en su forma actual o con modificaciones, en su
conjunto de principios de arquitectura. Si el arquitecto es la introducción de
TOGAF a una empresa que ya está comprometido con SOA, o que es parte de una empresa
más grande que se ha tomado la decisión estratégica de utilizar SOA, a
continuación, la adopción del principio de la orientación a servicios es sencillo.
Si, por el contrario, SOA se está introduciendo a una empresa que no esté
comprometido con él, entonces la decisión de adoptar este principio no debe tomarse
a la ligera. El éxito de SOA depende en parte de la disposición de la empresa para
convertirse orientada a servicios. La organización puede llevar a cabo una
evaluación de la madurez de SOA en la fase preliminar, utilizando el Modelo de
Madurez de Integración de Servicios Open Group (OSIMM) como parte de la revisión
del contexto de la organización para la realización de la arquitectura empresarial.
Esto ayudará a establecer los fundamentos de la empresa a adoptar el principio de
la orientación a servicios. A pesar de que una empresa puede estar comprometida con
SOA, no siempre es conveniente utilizar el estilo SOA para hacer frente a todos los
problemas de la arquitectura. A medida que la sección sobre los niveles
identificados segmentos específicos o capacidades pueden ser mejor servidos por SOA
en una organización de otra manera no comprometida; o segmentos o capacidades
específicas pueden no ser adecuados para SOA en una organización comprometida con
SOA. A partir de aquí se supone que se adopta el principio de la orientación a
servicios.
22.7.1.2 Gobernabilidad y estrategia de apoyo

Una revisión debe ocurrir de los procedimientos de gobierno existentes, lo que

confirma que son apropiadas para SOA. Si no lo son, entonces se deben hacer
recomendaciones para el cambio para que sean apropiadas.

  Página 225 de 670 

TOGOF 9.1    
The Open Group cuenta con un marco de gobernanza estandarizado que se centra en la
SOA y puede ser utilizada para mejorar los marcos de gobernanza existentes (ver El
Gobierno Open Grupo SOA Framework Norma Técnica). Esto proporciona un modelo de
referencia de alto nivel de cómo se extiende el gobierno de SOA y es compatible
tanto con la arquitectura empresarial y de gobierno de TI. También incluye un
método de vitalidad Gobernabilidad SOA (SGVM) que se puede utilizar para definir un
régimen específico de gobierno de SOA adaptado a la visión de la organización de la
gobernanza.

  Figura 22‐1: El Marco de Gobernabilidad SOA Open Grupo 
22.7.1.3 Particiones y Centros de Excelencia

Diferentes equipos trabajarán en los diferentes elementos de la arquitectura al

mismo tiempo. Las particiones permiten a grupos específicos de los arquitectos a
poseer y desarrollar elementos específicos de la arquitectura. Se sugiere que el
equipo se inicia con una iniciativa enfocada antes de implementar en una amplia
escala. El equipo responsable de SOA inicialmente debe estar estructurado como un
Centro de Excelencia (CoE). Un éxito CoE tendrá varios atributos clave:  Una clara
definición de la misión del Consejo de Europa: por qué existe, de su ámbito de
responsabilidad, y lo que la organización y la práctica de la arquitectura debe
esperar del Consejo de Europa.  Metas claras para el Consejo de Europa, incluyendo
mediciones e indicadores clave de rendimiento (KPI). Es importante asegurarse de
que las medidas y KPI del Consejo de Europa no conducen la selección inadecuada de
SOA como el estilo de la arquitectura.  El CoE ofrecerá la "prueba de fuego" de un
buen servicio.  El CoE difundirá los conocimientos, experiencia y capacidades del
Centro de SOA para el resto de la práctica de la arquitectura. 

 

  Página 226 de 670 

TOGOF 9.1    
  Identificar cómo los miembros del Consejo de Europa, y otros profesionales de
la arquitectura, serán recompensados por el éxito.  El reconocimiento de que, al
comienzo, es poco probable que la organización va a tener las habilidades
necesarias para crear un Centro de Excelencia en pleno funcionamiento. Las
habilidades y la experiencia necesarias deben ser cuidadosamente identificados, y
donde no están presentes, adquirieron. Una habilidad fundamental para destacados
profesionales dentro del Consejo de Europa es la capacidad de guiar a otros
profesionales de la transferencia de conocimientos, habilidades y experiencia. 
Primer plan de cuenta cuando el Consejo de Europa ha cumplido su propósito. 

   
22.7.1.4 Arquitectura Repositorio

. Hay una serie de recursos SOA que se debe considerar cuando inicialmente poblar
el repositorio de Arquitectura como se describe en la arquitectura de referencia
SOA Open Group (véase La SOA Source Book Open Group) Estos incluyen:   Los
ladrillos de la SOA , que describe un conjunto de ABBS que representan los
elementos clave de SOA  Una perspectiva de alto nivel de la arquitectura de
referencia de SOA , lo que da una visión general de las nueve capas de la
arquitectura de referencia, con ejemplos y razones que describen las principales
responsabilidades de las capas y sus bloques de construcción primarios  Detalladas
bloques de construcción de la arquitectura de referencia de SOA , que presenta
modelos detallados que muestran cómo algunas de las características de SOA se puede
implementar utilizando la arquitectura de referencia  Infraestructura para SOA ,
que describe Arquitectura Bloques de Construcción (Abs) que corresponden a los
productos de infraestructura que están disponibles hoy para apoyar las aplicaciones
orientadas a servicios  Industria Normas de SOA , como el marco de integración de
TeleManagement Forum 

Un gráfico de alto nivel que se describe la arquitectura de referencia SOA Open

Group sigue:

  Página 227 de 670 

TOGOF 9.1    

  Figura 22‐2: La arquitectura de referencia SOA Open Group 
22.7.2 Fase A: Architecture Vision
La descripción de alto nivel se produce en la fase A reflejará la naturaleza
orientada al servicio de la arquitectura que se preveía. Una diferencia obvia entre
una descripción de la arquitectura SOA y una descripción de una arquitectura de
otro estilo es el idioma. La descripción SOA utiliza un lenguaje diferente, con
palabras tales como "política", "composicion", y "tarea", y cuenta con diferentes
modelos, tales como matrices que muestran el uso de los servicios por parte de los
procesos de negocio y el uso de aplicaciones de servicios. The Open Group SOA
ontología proporciona una taxonomía y ontología para SOA. En un proyecto de SOA es
importante para garantizar que las partes interesadas comprendan las implicaciones
de SOA y se preparan para el impacto de la organización de los servicios de SOA
componibles. Este impacto es aplicable si los servicios de SOA están disponibles
como aplicaciones heredadas envueltos, utilizando los servicios expuestos a los
productos comprados, servicios a medida, Cloud Computing Software as a Service
(SaaS), etc
22.7.2.1 Las partes interesadas, inquietudes y requerimientos de negocio

Los interesados que consulten los requisitos para hacer frente, y los modelos,
artefactos y puntos de vista para el desarrollo varían de un compromiso de la
arquitectura a otra. Existen algunas preocupaciones que son específicos de SOA, o
que son más propensos a surgir en la evolución de SOA. Las preocupaciones de los
interesados direccionamiento en SOA sección de la SOA Source Book Open Group es un
buen recurso para hacer frente a este tema.

  Página 228 de 670 

TOGOF 9.1    
22.7.3 Arquitectura de Desarrollo: Fases B, C, y D
En esta sección se considera el impacto de SOA en las fases B, C y D, los dominios
de desarrollo de arquitectura. La siguiente gráfica de los TOGAF identifica el
contenido Metamodel (señalados en rojo) las entidades que son clave para SOA.

  Figura 22‐3: Entidades de SOA en el Metamodel contenido 

  
Personas clave incluyen:      Evento  Proceso  Servicios de Negocio  Es el
servicio  Plataforma de servicios 

  Página 229 de 670 

TOGOF 9.1    
          Lógico Aplicación y Tecnología de componentes  Aplicación y
Tecnología Componente Físico  Entidad de datos  Papel  Calidad de Servicio 
Contrato  Ubicación  Información de contacto (no en el metamodelo)  Lógico
Componentes de la información (no en metamodelo)  Reglas de Negocio (no en el
metamodelo) 

Extensiones del metamodelo son típicamente necesarios para apoyar plenamente SOA.
Lo que sigue para cada dominio es una descripción de los artefactos que son
apropiados para el desarrollo de la empresa del arquitecto de una SOA.
Fase B: Arquitectura de Negocios

El punto de partida de los artefactos que se desarrollan en esta fase es el

conjunto de requisitos empresariales clave identificadas en la Fase A. Para el tipo
de SOA empresarial que estamos discutiendo aquí, los siguientes artefactos deben
ser considerados para SOA, ya que contribuyen a la definición de bloques de
construcción de SOA en la fase C y la fase D.
Artefacto Business Service Interaction Diagrama Propósito Entidades Metamodel

Este diagrama muestra todos los Servicios comerciales, contratos, servicios a las
empresas en el alcance información de negocios y sus relaciones y de la información
que fluye entre los servicios de (Business Information es mencionado en la oficina.
Se indicará cuáles son los Fase B, pero no hay una entidad servicios de negocio son
comúnmente metamodelo.) reutilizados por otros servicios de negocios que indica las
oportunidades para su posible reutilización de apoyo a los servicios de SI.

El diagrama también se utiliza para definir los procesos de negocio y las

relaciones entre los procesos de negocio, ya que cada proceso está compuesto por un
subconjunto de este modelo. Diagrama de Procesos Se trata de un conjunto de
diagramas de Negocio que muestran los procesos de negocio y su descomposición, sus
interacciones, así como la información con la que se refiere.
Subconjunto de Servicio Modelo de Negocio que muestra los servicios de negocios y
contratos involucrados en los procesos y la información de la empresa pasó entre
las Empresas de Servicios.

  Página 230 de 670 

TOGOF 9.1    
Catálogo de vocabulario Esta es una lista de los principales Esta es una lista de
elementos de de negocios términos utilizados en la descripción de información de
negocios y las los procesos de negocio y la descripciones de los elementos.
información. Es importante que la fase de la arquitectura de negocios (Business
Information es mencionado en la establece el contexto de información Fase B, pero
no hay una entidad para los servicios de software, según metamodelo.) se describe
en la Arquitectura de la Información para SOA sección del libro Fuente Open Group,
y un catálogo de términos de negocios es una parte importante de este contexto. El
vocabulario de negocios puede derivarse mientras que el desarrollo del modelo de
servicio de negocio. Servicios comerciales Esta es una lista de los servicios de
Listado de Empresas de Servicios y sus catálogo negocio de la empresa y sus
requisitos calidades de servicio no funcionales. Se utiliza para analizar los
requisitos no funcionales. Business Service / Para entender de dónde los servicios
Business Service, Ubicación Location Catálogo empresariales deben ser ejecutados.
Catálogo Evento / Para entender qué proceso se ejecuta Listas de eventos y sus
negocios efectuada Proceso en relación con un evento. Proceso Catálogo Calidad Para
entender las propiedades no Listas de contratos y sus calidades de contrato /
servicio funcionales de un contrato. servicio pertinentes Business Service Para
mostrar las relaciones entre los Servicios comerciales en ambos ejes y Interaction
Matrix servicios empresariales. Contratos en el punto de cruce Business Service /
Para mostrar cómo los elementos de Servicios comerciales y elementos de Matrix
Información información son utilizados por Servicios Información Empresarial (CRUD)
comerciales y de encontrar fallas en ese modelo. (Business Information es
mencionado en la Fase B, pero no hay una entidad actual metamodelo TOGAF.) Para
definir la estructura lógica de la Elementos de información de negocios,
información en la organización. Puede Componentes de la información lógica y ser
utilizado como insumo para el sus relaciones modelo de intercambio de definir las
entradas y salidas de los servicios (Ninguno de ellos existe en el metamodelo SOA.
actual.)

Información de los componentes del modelo

Los puntos de vista apropiados se deben producir para poder demostrar a las partes
interesadas sobre cómo se tratan sus preocupaciones en SOA específicos relacionados
con la Arquitectura Empresarial. Al hacer esto, el arquitecto se ocupa de las
necesidades que pueden ser satisfechas por la Arquitectura Empresarial. Los
requisitos de arquitectura restantes se abordarán en la fase C y la fase D.
Fase C: Arquitecturas de Sistemas de Información

La fase se divide en dos sub-fases, Arquitectura de datos y aplicaciones de

arquitectura. SOA hace poca diferencia a la sub-fase de Arquitectura de datos, pero
tiene un impacto importante en la arquitectura de aplicaciones. Además de afectar
los artefactos que se desarrollan, las vistas que se producen, las preocupaciones
que se discuten, y los requisitos que se identifican, SOA afecta la manera en que
el arquitecto hace el análisis de la brecha entre la línea de base y las
arquitecturas objetivo en la Fase C.

  Página 231 de 670 

TOGOF 9.1    
Con SOA, las aplicaciones de software tradicionales se sustituyen por conjuntos de
servicios débilmente acoplados. Las aplicaciones existentes todavía deben
describirse, como deberían las nuevas aplicaciones de las especies tradicionales
que se requieren, y estas aplicaciones deben ser incluidos en la cartera de
aplicaciones. Además, se deben identificar las áreas de funcionalidad de las
aplicaciones que están cubiertos por los servicios. Estos serán (probablemente como
parte de la implementación) pueden descomponer en los servicios, que se incluirán
en la cartera de servicios. Pero SOA no es sólo acerca de los servicios, es también
las soluciones creadas mediante el uso de combinaciones de servicios. Estas
soluciones se suelen estructurarse utilizando los procesos de negocio y servicios
de negocio definidos en la Fase B.
Fase C artefactos SOA específico Artefacto Es el servicio de Interacción Diagrama
Propósito Uso Metamodel Entidad Esto muestra los requisitos para los servicios Son
los servicios y los contratos entre potenciales de SOA (IS Services) y las ellos
interacciones entre ellos, y su uso de la información. Se utiliza para mostrar el
conjunto Los contratos indican lo Business completo de los requisitos para la
solución y Information es las relaciones entre los requisitos.
comunicado.Preferiblemente, la entidad

de Calidad de Servicio para los dos es el de servicios y los contratos se deriva de

las actividades empresariales y sus contratos y las calidades de servicio
relacionados. Business Process / IS Esta matriz muestra la relación entre cada uno
Procesos de Negocio y su relación con el Matrix Servicio de Procesos de Negocio y
de los servicios es servicio IS (s) apoyar el proceso. Se utiliza para mostrar el
conjunto completo de los requisitos para los servicios de SOA para un negocio
determinado proceso. ES Catalog Service El catálogo muestra todos es el de
servicios, Lista de servicios de SI y sus calidades de Contract sus contratos, y
las calidades de servicio servicio relacionados relacionados para permitir el
análisis de los requisitos no funcionales (por ejemplo, la Además, son los
contratos de servicio seguridad, el rendimiento, la carga, la para cada uno es el
servicio están disponibilidad, políticas, etc) para los posibles incluidos.
servicios SOA. Este catálogo es un insumo importante para el proceso de la Cartera
de Servicios de Gestión en la gobernabilidad de SOA. Es el servicio / Este catálogo
se conecta es el de servicios Es el servicio (s), Contratos relacionados,
aplicación de catálogo (potenciales servicios SOA), Contratos, y y calidades de
servicio relacionados con (existente) calidades de servicio con las aplicaciones
tal y como son componentes de aplicación existentes (tal cual Física componentes de
la física aplicación). Se utiliza para especificar los escenarios envolventes en
las aplicaciones existentes y analizar los requisitos no funcionales. ES Servicio /
Data Esta matriz muestra qué datos está a cargo de ES Services y sus entidades de
datos Matrix Entidad los posibles servicios SOA (es el de relacionados servicios).
Se utiliza para identificar potenciales de tratamiento de datos Servicios de SOA.
Lógico SOA Matriz de Esta matriz muestra la relación entre la SOA Es el de
servicios, Logical componentes

  Página 232 de 670 

TOGOF 9.1    
componentes componentes lógicos (Logical componentes de de aplicación, y los
principios y Drivers aplicación) y los potenciales servicios SOA (es negocios
(utilizadas para encontrar el de servicios). Se utiliza para estructurar los
criterios que realiza una agrupación) componentes lógicos de los requisitos. Un SOA
componentes lógicos (componente de aplicación de lógica), sería un candidato para
un servicio en arquitecturas SOA a nivel de capacidad. Este diagrama muestra las
relaciones entre los Componentes y Contratos aplicación componentes lógicos de SOA
(componentes lógica y sus calidades de servicio de la aplicación lógica) y otras
soluciones lógicas (Logical componentes de la Componentes tecnológicos lógicas y su
aplicación). Se utiliza para mostrar y analizar asignación a los contratos se
utilizan para los requisitos funcionales y no funcionales de los mecanismos de
interfaz. las interfaces entre las soluciones. Esta matriz muestra los servicios
distribuidos Es el servicio, Logical componente de en ubicaciones físicas para
satisfacer el aplicación, Física componente de requisito legal o de otro tipo. El
objetivo es aplicación, y ubicación mostrar y analizar si existen requisitos de
ubicación en servicios. Esto se puede hacer en cualquiera de estos casos los
servicios o componentes de aplicación lógicos.

Lógico SOA Solution Diagrama

Matriz de distribución de Servicio

El uso de los artefactos, el arquitecto debe desarrollar puntos de vista que

muestran a los interesados cómo se tratan sus preocupaciones en SOA específicos
relacionados con la Arquitectura de Aplicaciones. Los modelos que permitan la
discusión de las preocupaciones relacionadas con la Arquitectura de datos también
deben desarrollarse como parte de la Fase C. Estos son similares a los modelos que
se desarrollarían de una arquitectura tradicional basada en las aplicaciones de
software. Al hacer esto, esto responde a las necesidades que pueden ser satisfechas
por los sistemas de información Arquitecturas. Los requisitos de arquitectura
restantes se abordarán en la Fase D: Architecture Tecnología. En cada una de las
fases B, C, y D un análisis de brechas se debe realizar entre la línea de base y
Target Arquitecturas para determinar lo que hay que hacer para pasar de la línea de
base a la meta. Para las fases B y D, y la sub-fase Arquitectura de datos de la
Fase C, esto no se ve muy afectado por la SOA. Para las aplicaciones Arquitectura
subfase de la Fase C, sin embargo, SOA hace una diferencia en la forma en que se
realiza el análisis de las lagunas. Los ABBS definidos en la Fase C se incluyen
aplicaciones y grupos de servicios que cubren las áreas de funcionalidad de las
aplicaciones tradicionales. Ambos tipos de bloque de construcción deben ser
incluidos en el análisis de las lagunas. Sin embargo, puede ser la intención de que
un grupo de servicios puede implementar como una "envoltura" sobre las aplicaciones
existentes. Esta situación, que es especial para SOA, debe indicarse en el análisis
de las deficiencias, así como las situaciones en que han de ser removido o
sustituido, o nuevas aplicaciones se vayan a añadir aplicaciones antiguas.
Fase D: Architecture Tecnología

Para SOA, la arquitectura de la tecnología define el software y la infraestructura

de hardware necesaria para apoyar la cartera de servicios. Un punto de partida para
la Tecnología de la

  Página 233 de 670 

TOGOF 9.1    
Arquitectura es la arquitectura de referencia SOA Open Group, que contiene la
mayoría de los servicios posibles plataformas para una infraestructura SOA.Cada
organización tendrá que personalizar la arquitectura de referencia de SOA a sus
necesidades.
Artefactos Fase D-SOA específico Artefacto Propósito Uso Metamodel Entidad
Tecnología Lógica Este esquema se utiliza para mostrar y Servicio de Plataforma
(Capability), Diagrama de la analizar el caso de la arquitectura de Logical
Componente Tecnología (ABB) arquitectura referencia SOA Open Group. Contendrá todos
ABBS y capacidades que se consideren necesarias para la solución SOA. Lógico
Aplicación y Esta matriz se utiliza para mostrar y analizar Componentes aplicación
lógica y sus Tecnología Matrix las relaciones entre los componentes de relaciones
con los componentes lógicos aplicación lógicos y los componentes de tecnología,
incluyendo derivaciones tecnológicos lógicas para asegurar el de las calidades de
servicio arquitecto entienda lo que la tecnología se utilizará para los componentes
de aplicación lógicos. También se utiliza para obtener y validar los requisitos no
funcionales para los componentes tecnológicos.

The Open Group ha producido información adicional relativa a la adaptación de la

infraestructura de una organización para la orientación a servicios, incluida la
infraestructura orientada a servicios Open Group (SOI) Modelo de referencia
(consulte El SOA Source Book Open Group para guía). El uso de los artefactos y SOI
modelo de referencia, el arquitecto debe desarrollar puntos de vista que muestran a
los interesados cómo se tratan sus preocupaciones en SOA específicos relacionados
con la Tecnología de la Arquitectura. Al hacer esto, el arquitecto añade requisitos
adicionales a los identificados en las Fases A, B y C, y se ocupa de las
necesidades que pueden ser satisfechas por la Arquitectura de Tecnología. Todos los
requisitos de arquitectura deberían haber sido abordados por el final de esta fase.
Si todavía hay requisitos de arquitectura pendientes, entonces es necesario volver
a la Fase B o Fase C para hacerles frente. Requisitos para la aplicación serán
abordados por los proyectos que se han identificado en la Fase E.
Fase E: Oportunidades y Soluciones

La identificación de soluciones SOA es una tarea clave para SOA. Las preguntas de
qué soluciones SOA de la empresa tendrá, y cómo van a ser gestionados, deben ser
considerados en esta fase. Opciones de entrega de soluciones se consideran
normalmente como parte de esta fase. Una opción de la entrega que se debe
considerar en particular para SOA es el uso de los servicios prestados por empresas
externas, en comparación con el desarrollo de los servicios en la empresa o la
adquisición de productos de software que realizan los servicios.
Fase artefactos SOA específico E Artefacto Física SOA Solution Matrix Propósito Uso
Metamodel Entidad Esta matriz muestra la relación entre las SE Services,
componentes de aplicación soluciones físicas SOA (Física lógica, física componentes
de la aplicación

  Página 234 de 670 

TOGOF 9.1    
componentes de la aplicación) y la lógica y los principios y Negocio Drivers (usado
SOA Componentes. Se utiliza para definir para encontrar criterios que hacer la
estructura física de la solución de SOA. estructuración) Física Solución Este
diagrama muestra las relaciones Componentes y Contratos aplicación física Diagrama
de SOA entre la solución SOA física (Physical y sus calidades de servicio
componentes de aplicación) y otras soluciones (componentes de la aplicación
Tecnología Física Componentes y su física). Se utiliza para mostrar y analizar
correlación con los contratos se utilizan los requisitos funcionales y no para los
mecanismos de interfaz. funcionales de las interfaces entre las soluciones.
Servicio de Física Esta matriz muestra que se vuelven a ES Servicios, Física
componentes de Matrix Solution utilizar los servicios existentes, que aplicación
(tal y como son los servicios de servicios pueden ser proporcionados por SOA para
su reutilización), otra aplicación los servicios externos (SaaS), y que los física
Componentes (nuevos y existentes servicios deben desarrollarse como aplicaciones
que pueden envolver), y envolturas de nuevas aplicaciones / nuevos componentes de
aplicación física existentes y cuales necesitan ser (nuevos servicios a ser
desarrollados o desarrolladas. adquiridos externamente) Se trata de una
contribución al proceso de Gestión de la cartera de servicios de Gobierno SOA.
Pautas de Este documento proporciona directrices aplicación sobre cómo desarrollar
soluciones y servicios SOA. Sugerencias de posibles directrices se pueden encontrar
en el Apéndice A del marco de gobernanza Open Grupo SOA. Tecnología Física Este
diagrama se utiliza para mostrar y Plataforma de Servicios, Tecnología Diagrama de
la analizar la solución técnica física para la Componente lógico, Tecnología
arquitectura infraestructura SOA. Componente Físico Aplicación y Esta matriz se
utiliza para mostrar y Componentes de aplicaciones físicas y sus Tecnología Física
analizar la infraestructura física se utiliza relaciones con Componentes tecnología
Matrix para ejecutar la aplicación física y para física, incluyendo derivaciones de
las garantizar que los requisitos no calidades de servicio funcionales son
derivados adecuadamente y entendidas. Catálogo Cartera Esta es una lista de
productos y tipos de Física componentes de aplicación y su Tecnológica productos
que se utilizarán en la relación con calidades de servicio ejecución, incluida la
infraestructura de SOA en tiempo de ejecución, entorno de desarrollo de SOA, la
tecnología de componentes de servicio, y la interfaz de servicio (portal, el canal,
etc) la tecnología. También incluirá los requisitos no funcionales. Directrices
Este documento proporciona directrices Tecnología sobre el uso de la
infraestructura SOA.Sugerencias de posibles directrices se pueden encontrar en el
Apéndice A del marco de gobernanza Open Grupo SOA.

Los proyectos de implementación que se identifican, y la estrategia de

implementación y migración, dependerán de las decisiones tomadas en el nivel de
detalle de la especificación de implementación, cuando el equipo de arquitectos de
ámbito del desarrollo de la arquitectura en la Fase A.

  Página 235 de 670 

TOGOF 9.1    
Fase C: planeamiento de migración

El modelo de gobierno de aplicación se revisa en la Fase F con el fin de asegurarse

de que esté en su lugar antes de la siguiente fase - Gobierno Implementación -
comienza. SOA requiere de reglas y procedimientos de gobierno en particular. La
estrategia de gobierno y el apoyo se revisa en la Etapa Preliminar. Si necesita ser
actualizado para SOA, entonces esto debe hacerse antes de que comience la
ejecución. Esto debería utilizar los mismos recursos identificados en 22.7.1.2
Gobernabilidad y Estrategia de apoyo .
Fase G: Gobernanza Aplicación

Las actividades que se realizan en la fase de implementación de Gobierno dependerá

en parte de las decisiones tomadas en el nivel de detalle de la especificación de
implementación, cuando el equipo de arquitectos de ámbito del desarrollo de la
arquitectura en la Fase A. Durante la fase de implementación de Gobierno, la parte
control de la SGVM debe ser poner en funcionamiento para asegurar que las
actividades de gobierno de SOA se realizan en el nivel correcto.
Fase H: Gestión Arquitectura Cambio

Es en este punto que el arquitecto debe determinar si es necesario revisar la Etapa

Preliminar para ajustar la capacidad de la Arquitectura. Dónde SOA previamente no
se ha utilizado dentro de una empresa, la Fase H de un desarrollo de la
arquitectura es una oportunidad para evaluar la contribución que podría hacer SOA,
y para considerar la adopción del principio de la orientación a servicios.

22.8 Resumen
Hay una serie de métodos de SOA, herramientas y materiales de referencia
disponibles para ayudar al Enterprise Architect desarrollar SOA. Se sugieren las
normas y publicaciones Open Group. Algunos se centran directamente en SOA - como el
Source Book SOA, OSIMM o la SGVM otros no están directamente enfocados pero
regularmente útiles, tales como salidas de El Foro de Seguridad de Open Group. .
Usando TOGAF para crear SOA requiere la adaptación de TOGAF para atender las
exigencias de un estilo particular Abordar un estilo requerirá:     La
identificación de las entradas clave metamodelo  La identificación de extensiones
al metamodelo contenido  La identificación de los artefactos clave  La
identificación de los materiales de referencia de estilo específico y modelos de
madurez 
La adaptación de una capacidad de Arquitectura para apoyar SOA requiere una
considerable actividad en la fase preliminar de TOGAF. Estas actividades y
herramientas SOA específicas del Grupo de Trabajo SOA Open Group incluyen:  
Adaptar el principio de la orientación a servicios  La determinación de la
organización la preparación para SOA: OSIMM 

  Página 236 de 670 

TOGOF 9.1    
  Gobernanza: 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 la forma de una arquitectura
es descrito, 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 trabajo a nivel estratégico el objetivo es identificar
si se necesita SOA, y en el que los segmentos. En el trabajo a nivel de segmento el
propósito es describir la estructura y las capacidades de SOA. Por último, en el
trabajo a nivel de capacidades para identificar y describir los requisitos de los
servicios SOA que estarán disponibles. Cuando la entrega de SOA con TOGAF, el
médico nunca debe perder de vista el objetivo final: soluciones SOA que se ocupan
de la gestión de la complejidad de la empresa y proporcionar la agilidad del
negocio.

  Página 237 de 670 

TOGOF 9.1       

23. Principios de Arquitectura

En este capítulo se describen los principios para el uso en el desarrollo de una
empresa de arquitectura.

23.1 Introducción
Los principios son normas generales y directrices, destinadas a ser duradera y rara
vez modificada, que informan y apoyan la forma en que una organización se marca
sobre el cumplimiento de su misión. A su vez, los principios pueden ser sólo un
elemento de un conjunto estructurado de ideas que en conjunto definen y guías de la
organización, a partir de los valores a través de acciones y resultados.
Dependiendo de la organización, los principios pueden ser establecidos dentro de
los diferentes ámbitos y en diferentes niveles. Dos dominios clave informan al
desarrollo y la utilización de la arquitectura:  Enterprise principios
proporcionan una base para la toma de decisiones en toda la empresa, e informar de
cómo la organización se marca sobre el cumplimiento de su misión. Tales principios
se encuentran comúnmente como medio de armonizar la toma de decisiones en toda la
organización. En particular, son un elemento clave para una estrategia exitosa de
gobernabilidad arquitectura (ver 50. Arquitectura de Gobierno ).  Dentro del amplio
dominio de los principios empresariales, es común tener principios subsidiarios
dentro de una empresa o unidad organizativa. Los ejemplos incluyen informática,
recursos humanos, operaciones nacionales, o de las operaciones en el extranjero.
Estos principios proporcionan una base para la toma de decisiones dentro del
dominio subsidiario e informarán desarrollo de la arquitectura dentro del dominio.
Se debe tener cuidado para asegurar que los principios utilizados para informar el
desarrollo de arquitectura se alinean con el contexto organizativo de la Capacidad
de Arquitectura.  Arquitectura principios son un conjunto de principios que se
relacionan con el trabajo de la arquitectura. Son el reflejo de un nivel de
consenso en toda la empresa, y encarnan el espíritu y el pensamiento de los
principios empresariales existentes. Arquitectura principios rigen el proceso de
arquitectura, que afecta el desarrollo, mantenimiento y uso de la arquitectura de
la empresa. 

Es común tener conjuntos de principios forman una jerarquía, en ese segmento

principios serán informados por, y elaboran sobre los principios a nivel de
empresa.Principios Arquitectura serán informados y limitados por principios
empresariales. Principios Arquitectura pueden repetir otra orientación de la
empresa en términos y forma que orientar eficazmente el desarrollo de la
arquitectura. El resto de esta sección se refiere exclusivamente a los principios
de la arquitectura.

  Página 238 de 670 

TOGOF 9.1    

23.2 Características de Arquitectura Principios

Arquitectura principios definen las normas y directrices para el uso y despliegue
de todos los recursos y activos de TI en toda la empresa generales subyacentes. Son
el reflejo de un nivel de consenso entre los distintos elementos de la empresa, y
constituyen la base para la toma de decisiones de TI en el futuro. Cada principio
la arquitectura debe estar claramente relacionado de nuevo a los objetivos de
negocio y los conductores de arquitectura clave.

23,3 Componentes de Principios de Arquitectura

Es útil tener una forma estándar de principios que definen. Además de una
instrucción de definición, cada principio debe tener asociado declaraciones
justificación e implicaciones, tanto para promover el entendimiento y la aceptación
de los principios mismos, y para apoyar el uso de los principios en la explicación
y justificación de por qué se toman las decisiones específicas. Una plantilla
recomendada se da en la Tabla 23-1 .
En caso ambos representan 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. Evite las palabras ambiguas en el nombre y en el
Estado, tales como: el "apoyo", "Abrir", "considerar", y por falta de una buena
medida de la palabra "evitar", por sí mismo, tenga cuidado con " administrar
( ción) ", y buscar adjetivos y adverbios (pelusa) innecesarios. Declaración
Sucinta y sin ambigüedades deben comunicar la regla fundamental. En su mayor parte,
las declaraciones de principios para la gestión de la información son similares de
una organización a otra. Es de vital importancia que la declaración de principios
sea inequívoca. Razón Hará hincapié en los beneficios de negocio de adherirse al
principio, utilizando fundamental la terminología de negocios. Apunte a la
similitud de los principios de información y tecnología a los principios que rigen
las operaciones de negocio. Describa también 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 prioridad o tener más peso que otro para tomar una
decisión. Implicaciones Hará hincapié en los requisitos, tanto para el negocio y de
TI, para llevar a cabo el principio - en términos de recursos, costos y actividades
/ tareas. A menudo será evidente que los actuales sistemas, normas o prácticas
serían incongruentes con el principio sobre la adopción. El impacto para 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 afecta esto a mí?" Es importante
no simplificar demasiado, trivializar o juzgar el mérito del impacto.Algunas de las
consecuencias serán identificados como sólo los impactos potenciales, y puede ser
especulativa en lugar de totalmente analizado. Nombre

Tabla 23‐1: Formato recomendado para los principios que definen 
Un ejemplo conjunto de arquitectura siguientes principios de esta plantilla se da
en el 23,6 Ejemplo Conjunto de Principios de Arquitectura .

  Página 239 de 670 

TOGOF 9.1    

23.4 Desarrollo Principios Arquitectura

Arquitectura principios se desarrollan típicamente por los arquitectos de la
empresa, en conjunto con las principales partes interesadas, y son aprobados por el
Consejo de Arquitectura. Principios Arquitectura serán informados por principios en
el ámbito de la empresa, si es que existen. Principios Arquitectura deben estar
claramente detectable y claramente articulado para orientar la toma de decisiones.
Son elegidos con el fin de asegurar la alineación de la arquitectura y la
implementación de la arquitectura destino con las estrategias de negocios y
visiones. En concreto, el desarrollo de los principios de la arquitectura es
típicamente influenciado por el siguiente:   Misión de la empresa y los planes :
la misión, planes e infraestructura organizativa de la empresa.  Enterprise
iniciativas estratégicas : las características de la empresa - sus fortalezas,
debilidades, oportunidades y amenazas - y sus iniciativas en toda la empresa
actuales (tales como la mejora de procesos y gestión de la calidad).  La
restricción externa : factores de mercado (time-to-market imperativos, las
expectativas de los clientes, etc); legislación actual y potencial.  Sistemas y
tecnologías actuales : 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.  Nuevas tendencias
de la industria : las predicciones sobre los factores económicos, políticos,
técnicos y de mercado que influyen en el entorno empresarial. 

 

23.4.1 Cualidades de Principios

Simple hecho de tener una declaración escrita que se llama un principio no
significa que el principio es bueno, incluso si todo el mundo está de acuerdo con
él. Un buen conjunto de principios se fundó en las creencias y valores de la
organización y se expresa en un lenguaje que la empresa entiende y utiliza.
Principios deben ser pocos en número, orientada hacia el futuro, y respaldado y
defendido por la alta dirección. Ellos proporcionan una base sólida para la toma de
decisiones de arquitectura y planificación, formulación de políticas,
procedimientos y normas, y el apoyo a la resolución de situaciones contradictorias.
Un pobre conjunto de principios se convertirá rápidamente en desuso, y las
arquitecturas resultantes, políticas y normas aparecerá arbitrario o egoísta, y por
lo tanto carecen de credibilidad. Esencialmente, principios impulsan el
comportamiento. Hay cinco criterios que distinguen a un buen conjunto de
principios:  Comprensible : los principios subyacentes pueden ser captadas y
entendidas por las personas en toda la organización de forma rápida. La intención
del principio es clara e inequívoca, de modo que violaciónes, ya sea intencional o
no, se reducen al mínimo. 

  Página 240 de 670 

TOGOF 9.1    
 Robusto : permitir decisiones de buena calidad sobre arquitecturas y planes que
se hacer, y las políticas y normas de obligado cumplimiento que se creen. Cada
principio debe ser lo suficientemente definitivo y preciso para apoyar la toma de
decisiones coherentes en situaciones complejas y potencialmente controversiales. 
Completa :. 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.  De acuerdo : la estricta adhesión a un principio puede
requerir una interpretación libre de otro principio. El conjunto de principios debe
ser expresado 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 del otro. Cada palabra en un comunicado principio
debe elegirse cuidadosamente para permitir una interpretación coherente, pero
flexible.  Estable : principios deben ser duraderos, sin embargo, capaz de
adaptarse a los cambios. Un proceso de enmienda debe ser establecido para agregar,
eliminar o alterar los principios después de haber sido ratificadas inicialmente. 

23.5 Aplicación de Principios de Arquitectura

Arquitectura principios se utilizan para capturar las verdades fundamentales acerca
de cómo la empresa va a utilizar y desplegar los recursos de TI y los activos. Los
principios se utilizan en un número de diferentes maneras:

1. Para proporcionar un marco en el que la empresa puede empezar a tomar decisiones

conscientes acerca de la arquitectura y proyectos que implementan la arquitectura
de la empresa objetivo de la empresa 

2. Como guía para el establecimiento de criterios de evaluación pertinentes,

ejerciendo así
una fuerte influencia en la selección de productos, soluciones y arquitecturas de
soluciones en las últimas etapas de la gestión del cumplimiento de la arquitectura
de la empresa 

3. Como los controladores para la definición de los requisitos funcionales de la

arquitectura  4. Como aporte a la evaluación de ambas implementaciones existentes y
la cartera
estratégica, para el cumplimiento de las arquitecturas definidas; 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 de la empresa 

5. Las declaraciones Justificación dentro de un Principio Arquitectura destacan el

valor de
negocio de las implementaciones consistentes con el principio y proporcionar
orientación para las decisiones difíciles con los conductores o los objetivos en
conflicto 

6. Las declaraciones Implicaciones dentro de un Principio Arquitectura proporcionan

un
esquema de las principales tareas, recursos y costos potenciales para la empresa de
seguir el principio; sino que también proporcionan una valiosa aportación a las
futuras actividades de la iniciativa de transición y planificación 

7. Apoyar las actividades de gobierno de la arquitectura en términos de:   

Página 241 de 670 

TOGOF 9.1    
o Proporcionar un "back-stop" para las evaluaciones Arquitectura cumplimiento de
estándares donde se permite o requiere alguna interpretación  El apoyo a la
decisión de iniciar una solicitud de dispensa, donde las consecuencias de una
modificación particular arquitectura no se pueden resolver dentro del procedimiento
operativo local 

Principios están interrelacionados y deben ser aplicadas como un conjunto.

Principios a veces competir; por ejemplo, los principios de la "accesibilidad" y
"seguridad" tienden a decisiones contradictorias. Cada principio debe considerarse
en el contexto de "todas las cosas en igualdad". 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 documentado. Una reacción
común en la primera lectura de un principio es "esto es obvio y no necesita ser
documentado". El hecho de que un principio parece obvio no significa que la
orientación en un principio se siguió. Tener principios que aparecen evidentes
ayuda a asegurar que las decisiones que en realidad siguen el resultado deseado.
Aunque 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.

23.6 Ejemplo Conjunto de Principios de Arquitectura

Demasiados principios pueden reducir la flexibilidad de la arquitectura. Muchas
organizaciones prefieren definir sólo los principios de alto nivel, y para limitar
el número a entre 10 y 20. El siguiente ejemplo ilustra tanto el contenido típico
de un conjunto de principios de la arquitectura, y el formato recomendado para
definirlos, como se explicó anteriormente.

23.6.1 Principios de Negocio

Principio 1: Primacía de Principios

Declaración:  Estos principios de gestión de la información se aplican a todas las

organizaciones dentro de la empresa. 

  Página 242 de 670 

TOGOF 9.1    
Justificación:  La única manera de que podamos proporcionar un nivel consistente y
medible de información de calidad a los tomadores de decisiones es si todas las
organizaciones se rigen por los principios.  Implicaciones:     Sin este
principio, las exclusiones, el favoritismo y la inconsistencia socavaría
rápidamente la gestión de la información.  iniciativas de gestión de la información
no comenzarán hasta que se examinan para el cumplimiento de los principios.  Un
conflicto con un principio se resuelve cambiando el marco de la iniciativa. 

Principio 2: Maximizar beneficios a la Empresa

Declaración:  Decisiones de gestión de la información se hacen para proporcionar el

máximo beneficio a la empresa en su conjunto.  Justificación:  Este principio
encarna "servicio por encima de uno mismo". Las decisiones tomadas desde una
perspectiva de toda la empresa tienen un mayor valor a largo plazo de las
decisiones tomadas desde cualquier punto de vista organizativo particular. Máximo
rendimiento de la inversión requiere decisiones de gestión de la información a que
se adhieran a los conductores y las prioridades de toda la empresa. Ningún grupo
minoritario redundará en detrimento de la prestación de la totalidad. Sin embargo,
este principio no impedirá cualquier grupo minoritario de conseguir hacer su
trabajo.  Implicaciones:   Lograr el máximo beneficio de toda la empresa requerirá
cambios en la forma en que planificamos y gestionar la información. sola tecnología
no va a producir este cambio.  Algunas organizaciones pueden tener que reconocer
sus propias preferencias para el mayor beneficio de toda la empresa.  las
prioridades de desarrollo de aplicaciones deben ser establecidos por toda la
empresa para toda la empresa.  Componentes Aplicaciones deben ser compartidos a
través de las fronteras organizacionales.  las iniciativas de gestión de la
información debe realizarse de acuerdo con el plan de empresa. Las distintas
organizaciones deben perseguir iniciativas de gestión de la información que se
ajustan a los planos y las prioridades establecidas por la empresa. Vamos a cambiar
el plan, ya que necesitamos. 

   

  Página 243 de 670 

TOGOF 9.1    
 A medida que surjan las necesidades, las prioridades deben ser ajustados. Un foro
con representación global de la empresa debe tomar estas decisiones. 

Principio 3: Gestión de la información es asunto de todos

Declaración:  Todas las organizaciones de la empresa participan en las decisiones

de gestión de información necesarios para lograr los objetivos de negocio. 
Justificación:  Usuarios de la información son las principales partes interesadas,
o clientes, en la aplicación de tecnología para hacer frente a una necesidad de
negocio. Con el fin de garantizar la gestión de la información está alineada con el
negocio, todas las organizaciones en la empresa deben participar en todos los
aspectos del entorno de la información. Los expertos en negocios de toda la empresa
y el personal técnico responsable del desarrollo y la preservación del entorno de
información tienen que venir juntos como un equipo para definir conjuntamente los
objetivos y metas de TI.  Implicaciones:    Para operar como un equipo, todos los
grupos de interés, o cliente, tendrá que aceptar la responsabilidad de desarrollar
el entorno de la información.  Compromiso de los recursos se requiere para poner en
práctica este principio. 

Principio 4: Continuidad del Negocio

Declaración:  Las operaciones de la empresa se mantienen a pesar de las

interrupciones del sistema.  Justificación:  Como las operaciones del sistema se
torna más difundido, nos volvemos más dependientes de ellos; Por lo tanto, debemos
tener en cuenta la fiabilidad de estos sistemas a través de su diseño y uso.
Locales comerciales en toda la empresa debe proporcionar la capacidad de continuar
con sus funciones de negocios, independientemente de los acontecimientos externos.
Error de hardware, desastres naturales, y la corrupción de datos no se debe
permitir que interrumpir o detener las actividades empresariales. Las funciones de
negocio de la empresa debe ser capaz de operar sobre los mecanismos de entrega de
información alternativos.  Implicaciones:   La dependencia de las aplicaciones
compartidas mandatos del sistema que los riesgos de la interrupción del negocio se
deben establecer de antemano y gestionados. El manejo incluye pero no se limita a
las revisiones periódicas, control de la vulnerabilidad y la exposición, o el
diseño de servicios de misión crítica para

  Página 244 de 670 

TOGOF 9.1    
asegurar la continuidad del negocio a través de la función de las capacidades
redundantes o alternativos.    Recuperabilidad, redundancia y capacidad de
mantenimiento deben ser abordadas en el momento del diseño.  Las solicitudes deben
ser evaluados por la criticidad e impacto en la misión de la empresa, con el fin de
determinar qué nivel de continuidad que se requiere y lo que el plan de
recuperación correspondiente es necesario. 

Principio 5: Common Use Aplicaciones

Declaración:  Desarrollo de aplicaciones de uso en toda la empresa se prefiere

sobre el desarrollo de aplicaciones similares o duplicados que se proporcionan
únicamente a una organización en particular.  Justificación:  Capacidad de
duplicación es costosa y prolifera datos contradictorios.  Implicaciones:   Las
organizaciones que dependen de una capacidad que no sirve a toda la empresa debe
cambiar a la capacidad de toda la empresa de reemplazo. Para ello será necesario el
establecimiento de y la adhesión a una política que exige esto.  Organizaciones No
se permitirá el desarrollo de capacidades para su propio uso, que son similares /
duplicación de las capacidades de toda la empresa. De esta manera, se reducirán los
gastos de los escasos recursos para desarrollar esencialmente la misma capacidad en
marginalmente diferentes maneras.  Los datos y la información utilizada para apoyar
a las empresas la toma de decisiones se normalizarán en mucha mayor medida que
antes. Esto se debe a las capacidades de la organización, más pequeñas que producen
diferentes datos (que no fue compartida por otras organizaciones) serán
reemplazadas por las capacidades de toda la empresa. El impulso para la adición a
la serie de capacidades en toda la empresa bien puede provenir de una organización
que hace un caso convincente para el valor de los datos / información producida
anteriormente por su capacidad de organización, pero la capacidad resultante pasará
a formar parte del sistema en toda la empresa , y los datos que produce será
compartida en toda la empresa. 

Principio 6: Orientación al Servicio

Declaración:  La arquitectura se basa en un diseño de los servicios que reflejan

las actividades empresariales del mundo real que comprenden la empresa (o entre
empresas) los procesos de negocio. 

  Página 245 de 670 

TOGOF 9.1    
Justificación:  La orientación a servicios ofrece la agilidad empresarial y sin
fronteras Flujo de Información.  Implicaciones:   Representación de servicio
utiliza descripciones empresariales para proporcionar el contexto (es decir, los
procesos de negocio, meta, regla, política, interfaz de servicio, y el componente
de servicio) e implementa servicios utilizando la orquestación de servicios. 
Orientación al servicio pone requisitos únicos de la infraestructura, y las
implementaciones deben utilizar estándares abiertos para darse cuenta de la
interoperabilidad y la transparencia de ubicación.  Las implementaciones son
favorables al medio específico; se ven limitados o habilitadas por el contexto y
deben ser descritas dentro de ese contexto.  Se requiere un gobierno fuerte de la
representación de servicios y la ejecución.  Una "prueba de fuego", lo que
determina un "buen servicio", se requiere. 

  
Principio 7: El cumplimiento de la Ley

Declaración:  Procesos de gestión de información de la empresa cumplen con todas

las leyes, políticas y regulaciones.  Justificación:  La política de empresa es
cumplir con las leyes, políticas y regulaciones. Esa disposición no impedirá la
mejora de procesos de negocio que conducen a cambios en las políticas y
regulaciones.  Implicaciones:    La empresa debe tener en cuenta para cumplir con
las leyes, regulaciones y políticas exteriores relativas a la recogida, retención y
gestión de datos.  La educación y el acceso a las normas. Eficiencia, la necesidad
y el sentido común no son los únicos pilotos. Los cambios en la ley y los cambios
en las regulaciones pueden conducir los cambios en los procesos o aplicaciones. 

Principio 8: IT Responsabilidad

Declaración:  La organización de TI es responsable de la propiedad y la

implementación de los procesos de TI y de infraestructura que permitan soluciones
para satisfacer los requisitos definidos por el usuario para la funcionalidad, los
niveles de servicio, costo y tiempo de entrega. 

  Página 246 de 670 

TOGOF 9.1    
Justificación:  Alinear eficazmente las expectativas con las capacidades y los
costos de manera que todos los proyectos son rentables. Soluciones eficientes y
eficaces tienen costos razonables y claros beneficios.  Implicaciones:     Un
proceso debe ser creado para dar prioridad a los proyectos.  La función de TI debe
definir los procesos para manejar las expectativas de las unidades de negocio.  Los
datos, aplicaciones y modelos de tecnología deben ser creados para permitir
soluciones integradas de calidad y para maximizar los resultados. 

Principio 9: Protección de la Propiedad Intelectual

Declaración:  Propiedad intelectual de la empresa (IP) debe ser protegido. Esta

protección debe reflejarse en la arquitectura de TI, implementación y procesos de
gobernanza.  Justificación:  Una parte importante de IP de una empresa se encuentra
alojado en el dominio de TI.  Implicaciones:   Si bien la protección de los
activos de propiedad intelectual es un asunto de todos, gran parte de la protección
real se implementa en el dominio de TI.Incluso confiar en los procesos de TI no
pueden ser manejados por los procesos de TI (correo electrónico, notas
obligatorias, etc.)  Una política de seguridad, el gobierno y los actores humanos
de TI, se requerirá que puede mejorar sustancialmente la protección de la propiedad
intelectual. Esta debe ser capaz de tanto evitando compromisos y la reducción de
pasivos.  Recursos sobre estas políticas se pueden encontrar en el Instituto SANS
(consulte www.sans.org/security-resources/policies/ ). 

23.6.2 Principios de datos

Principio 10: Los datos son un activo

Declaración:  Los datos son un activo que tiene valor para la empresa y se gestiona
en consecuencia.  Justificación:  Los datos son un recurso valioso corporativa; que
tiene un valor real y medible. En términos simples, el propósito de los datos es
para facilitar la toma de decisiones. Precisa,

  Página 247 de 670 
TOGOF 9.1    
los datos a tiempo es fundamental para las decisiones precisas y oportunas. La
mayoría de los activos de la empresa se utilizan cuidadosamente, y los datos no es
una excepción. Los datos son el fundamento de nuestra toma de decisiones, por lo
que también debe gestionar cuidadosamente los datos para asegurarse de que sabemos
donde está, puede confiar en su exactitud, y puede obtenerlo cuando y donde lo
necesitamos.  Implicaciones:   Se trata de uno de los tres principios
estrechamente relacionados con las relativas a los datos: los datos son un activo;
los datos se comparten; y los datos de fácil acceso. La implicación es que no es
una tarea de educación para garantizar que todas las organizaciones dentro de la
empresa a entender la relación entre el valor de los datos, intercambio de datos, y
la accesibilidad a los datos.  Administradores deben tener la autoridad y los
medios para gestionar los datos de los que son responsables.  Hay que hacer la
transición cultural de "propiedad de los datos" pensar que "la administración de
datos" de pensar.  El papel del administrador de datos es crítica porque los datos
obsoletos, inexactos o incoherentes podrían ser pasados a personal de la empresa y
afectan negativamente a las decisiones en toda la empresa.  Parte de la función de
administrador de datos, que gestiona los datos, es garantizar la calidad de los
datos. Los procedimientos deben ser desarrollados y utilizados para prevenir y
corregir errores en la información y mejorar los procesos que producen la
información errónea. Tendrá que ser medido y las medidas adoptadas para mejorar la
calidad de los datos de calidad de datos - es probable que tendrán las políticas y
procedimientos que se han desarrollado para esto también.  Un foro con
representación integral de toda la empresa debe decidir sobre cambios en los
procesos sugeridos por el mayordomo.  Dado que los datos son un activo de valor
para toda la empresa, los administradores de datos responsables de la gestión
adecuada de los datos deben ser asignados a nivel de empresa. 

  

 

Principio 11: Los datos se Compartido

Declaración:  Los usuarios tienen acceso a los datos necesarios para llevar a cabo
sus funciones; Por lo tanto, los datos se comparten a través de las funciones y de
las organizaciones empresariales.  Justificación:  El acceso oportuno a datos
precisos es esencial para mejorar la calidad y eficiencia de la empresa la toma de
decisiones. Es menos costoso de mantener datos precisos y oportunos en una sola
aplicación, y luego compartirlo, de lo que es para mantener los

  Página 248 de 670 

TOGOF 9.1    
datos duplicados en múltiples aplicaciones. La empresa tiene una gran cantidad de
datos, sino que se almacena en bases de datos de cientos de tubos de la estufa
incompatibles. La velocidad de recopilación de datos, la creación, la transferencia
y la asimilación es impulsado por la capacidad de la organización para compartir de
manera eficiente estas islas de datos en toda la organización.  Los datos
compartidos se traducirá en la mejora de las decisiones ya que vamos a contar con
un menor número (en última instancia, uno virtual) de las fuentes de datos más
precisos y gestionados oportuna para toda nuestra toma de decisiones. Datos
compartidos electrónicamente tendrán como resultado una mayor eficiencia cuando se
pueden utilizar las entidades de datos existentes, y sin volver a escribir, a crear
nuevas entidades. Implicaciones:   Se trata de uno de los tres principios
estrechamente relacionados con las relativas a los datos: los datos son un activo;
los datos se comparten; y los datos de fácil acceso. La implicación es que no es
una tarea de educación para garantizar que todas las organizaciones dentro de la
empresa a entender la relación entre el valor de los datos, intercambio de datos, y
la accesibilidad a los datos.  Para permitir el intercambio de datos que debemos
desarrollar y cumplir con un conjunto común de políticas, procedimientos y normas
que rigen la gestión de datos y el acceso tanto a corto como a largo plazo.  Para
el corto plazo, para preservar nuestra importante inversión en sistemas de legado,
tenemos que invertir en software capaz de migrar los datos del sistema legado en un
entorno de datos compartido.  También vamos a necesitar desarrollar modelos
estándares de datos, elementos de datos, y otros metadatos que define a este
entorno compartido y desarrollar un sistema de depósito para el almacenamiento de
estos metadatos para que sea accesible.  Para el largo plazo, ya que los sistemas
antiguos se sustituyen, debemos adoptar y hacer cumplir las políticas y directrices
para los nuevos desarrolladores de aplicaciones comunes de acceso a datos para
asegurar que los datos en nuevas aplicaciones queda disponible para el medio
ambiente que compartimos y que los datos en el entorno compartido puede seguir ser
utilizados por las aplicaciones nuevas.  Tanto para el corto plazo y el largo plazo
debemos adoptar métodos y herramientas comunes para crear, mantener y acceder a los
datos compartidos en toda la empresa.  El intercambio de datos requerirá un cambio
cultural significativo.  El principio de intercambio de datos continuamente "se
topan con" el principio de seguridad de los datos. En ningún caso, el principio de
intercambio de datos ocasionar que los datos confidenciales sean comprometidos. 
Los datos puestos a disposición para el intercambio tendrán que confiar todos los
usuarios a ejecutar sus respectivas tareas. Esto asegurará que sólo los datos más

 

  Página 249 de 670 

TOGOF 9.1    
precisa y oportuna que se invoque para la toma de decisiones. Los datos compartidos
se convertirá en la "fuente única virtual" en toda la empresa de datos. 
Principio 12: Los datos son accesibles

Declaración:  Los datos son accesibles a los usuarios realizar sus funciones. 
Justificación:  Amplio acceso a los datos conduce a la eficiencia y la eficacia en
la toma de decisiones, y ofrece respuesta oportuna a las solicitudes de información
y prestación de servicios. Utilizando la información debe ser considerado desde el
punto de vista de la empresa para permitir el acceso de una amplia variedad de
usuarios. Se ahorra tiempo del personal y la consistencia de los datos se ha
mejorado.  Implicaciones:   Se trata de uno de los tres principios estrechamente
relacionados con las relativas a los datos: los datos son un activo; los datos se
comparten; y los datos de fácil acceso. La implicación es que no es una tarea de
educación para garantizar que todas las organizaciones dentro de la empresa a
entender la relación entre el valor de los datos, intercambio de datos, y la
accesibilidad a los datos.  Accesibilidad consiste en la facilidad con la que los
usuarios obtengan información.  La forma en que se accede y visualiza la
información debe ser suficientemente adaptable para satisfacer una amplia gama de
usuarios de la empresa y sus correspondientes métodos de acceso.  El acceso a los
datos no constituye la comprensión de los datos. El personal debe tener cuidado de
no malinterpretar la información.  El acceso a los datos no otorga necesariamente
los derechos de acceso de usuario para modificar o divulgar los datos. Para ello
será necesario un proceso de educación y un cambio en la cultura organizacional, el
cual actualmente es compatible con la creencia en la "propiedad" de los datos por
unidades funcionales. 

 

 

Principio 13: Depositario de datos

Declaración:  Cada elemento de dato tiene un administrador responsable de la

calidad de datos.  Justificación:  Uno de los beneficios de un entorno Diseñada es
la capacidad de compartir los datos (por ejemplo, texto, vídeo, sonido, etc) a
través de la empresa. A medida que el grado de intercambio de datos crece y las
unidades de negocio se basan en la información común, es esencial que sólo el
administrador de datos toma las decisiones sobre el contenido de

  Página 250 de 670 

TOGOF 9.1    
los datos. Puesto que los datos se pueden perder su integridad cuando se introduce
varias veces, el administrador de datos será el único responsable de la
introducción de datos que elimina el esfuerzo humano redundante y los recursos de
almacenamiento de datos.  Nota:  Un fiduciario es diferente de un mayordomo - un
fiduciario es responsable de la exactitud y actualidad de los datos, mientras que
las responsabilidades de un administrador pueden ser más amplias e incluyen la
estandarización de datos y tareas de definición.  Implicaciones:   tutela real
disuelve los problemas de la "propiedad" de datos y permite que los datos estén
disponibles para satisfacer las necesidades de todos los usuarios. Esto implica que
un cambio cultural a partir de datos de la "propiedad" de los datos de "tutela"
puede ser requerida.  El administrador de datos será responsable de cumplir con las
exigencias de calidad impuestas a los datos para los que el fiduciario es
responsable.  Es esencial que el fiduciario tiene la capacidad de proporcionar la
confianza del usuario en los datos en base a atributos tales como "fuente de
datos".  Es esencial identificar la verdadera fuente de los datos con el fin de que
la autoridad de datos se puede asignar esta responsabilidad fiduciaria. Esto no
significa que las fuentes de anuncios serán revelados ni significa la fuente será
el fiduciario.  La información debe ser capturada electrónicamente una vez e
inmediatamente validada tan cerca de la fuente como sea posible. Medidas de control
de calidad deben ser implementadas para garantizar la integridad de los datos. 
Como resultado del intercambio de datos en toda la empresa, el fiduciario es
responsable y responsable de la exactitud y actualidad de su elemento de datos
designado (s) y, posteriormente, a continuación, debe reconocer la importancia de
esta responsabilidad fiduciaria. 

  


Principio 14: vocabulario común y definiciones de datos

Declaración:  Los datos que se define consistentemente en toda la empresa, y las

definiciones son comprensibles y estar disponibles para todos los usuarios. 
Justificación:  Los datos que se va a utilizar en el desarrollo de aplicaciones
debe tener una definición común en toda la sede para permitir el intercambio de
datos. Un vocabulario común facilitar las comunicaciones y de diálogo habilitado
para ser eficaz. Además, se requiere para interfaz de los sistemas y los datos de
cambio.

    Página 251 de 670 

TOGOF 9.1    
Implicaciones:   Estamos adormecidos en el pensamiento de que esta cuestión se
aborde adecuadamente porque hay gente con "Gestión de datos" títulos de trabajo y
foros con las cartas que implica responsabilidad. Energía y recursos adicionales
significativos deben estar comprometidos con esta tarea. Es clave para el éxito de
los esfuerzos para mejorar el entorno de la información. Esto es independiente de,
pero relacionado con el tema de la definición del elemento de datos, que está
dirigida por una amplia comunidad - esto es más como un vocabulario y una
definición común.  La empresa debe establecer el vocabulario común inicial para el
negocio. Las definiciones se utilizarán de manera uniforme en toda la empresa. 
Siempre que se requiera una nueva definición de datos, el esfuerzo de definición
será coordinada y reconciliada con el "glosario" corporativo de descripciones de
datos. El administrador de datos de la empresa proporcionará esta coordinación. 
Las ambigüedades resultantes de múltiples definiciones parroquiales de datos deben
dar paso a las definiciones aceptadas en toda la empresa y la comprensión. 
Múltiples iniciativas de estandarización de los datos tienen que ser coordinados. 
las responsabilidades de administración de datos funcionales deben ser asignados. 

 

  

Principio 15: Seguridad de datos

Declaración:  Los datos están protegidos por el uso y la divulgación no autorizada.

Además de los aspectos tradicionales de clasificación de seguridad nacional, esto
incluye, pero no se limita a, la protección de la pre-decisional, sensible, la
fuente de selección sensible, información y propietaria.  Justificación:  Libre
intercambio de información y la divulgación de información a través de la
legislación pertinente debe equilibrarse con la necesidad de restringir la
disponibilidad de la información clasificada, de propiedad y confidencial.  Leyes y
reglamentos existentes requieren la salvaguardia de la seguridad nacional y la
privacidad de los datos, al tiempo que permite el acceso libre y
abierto.Información previa a la toma de decisiones (trabajo en progreso, aún no
autorizados para la liberación) debe ser protegida para evitar la especulación
injustificada, la mala interpretación y el uso inapropiado.

  Página 252 de 670 

TOGOF 9.1    
Implicaciones:   La agregación de los datos, tanto clasificado, y no, va a crear
un objetivo grande que requiere revisión y los procedimientos de clasificación DE
para mantener un control adecuado. Los propietarios de datos y / o usuarios
funcionales deben determinar si los resultados de la agregación en un mayor nivel
de clasificación. Vamos a necesitar de políticas y procedimientos adecuados para
manejar esta revisión y clasificación DE. Acceso a la información sobre la base de
una política de la necesidad de conocer obligará a revisiones periódicas de la
cantidad de información.  La práctica actual de tener sistemas separados para
contener diferentes clasificaciones necesita ser repensado. ¿Hay una solución de
software para la separación de los datos clasificados y no clasificados? La
solución de hardware actual es difícil de manejar, ineficaz y costosa. Es más caro
para gestionar datos no clasificados en un sistema clasificado. Actualmente, la
única manera de combinar los dos es para colocar los datos no clasificados en el
sistema clasificado, donde debe permanecer.  Con el fin de proveer adecuadamente el
acceso para abrir la información, manteniendo la información segura, las
necesidades de seguridad deben ser identificados y desarrollados a nivel de datos,
no el nivel de aplicación.  medidas de seguridad de datos se pueden poner en marcha
para restringir el acceso a "sólo vista", o "no ver nunca". Etiquetado de
sensibilidad para el acceso a la clasificada, información previa a la toma de
decisiones, toma de decisiones, sensible, ni de la propiedad debe ser determinado. 
La seguridad debe ser diseñado en elementos de datos desde el principio; que no se
puede añadir más tarde. Sistemas, datos y tecnologías deben ser protegidos contra
el acceso y la manipulación no autorizada. Información de la Sede debe
salvaguardarse contra la alteración involuntaria o no autorizada, el sabotaje, el
desastre o la divulgación.  Necesidad de nuevas políticas sobre la gestión de la
duración de la protección de la información pre-decisional y otras obras en curso,
teniendo en cuenta la actualización del contenido. 

23.6.3 Principios de Aplicación

Principio 16: Tecnología de la Independencia

Declaración:  Las solicitudes son independientes de las opciones tecnológicas

específicas y por lo tanto pueden operar en una variedad de plataformas
tecnológicas. 

  Página 253 de 670 

TOGOF 9.1    
Justificación:  Independencia de las aplicaciones de la tecnología subyacente
permite que las aplicaciones a desarrollar, actualizar y operar de la manera más
costo-efectiva y oportuna. De lo contrario, la tecnología, la cual está sujeta a
continua obsolescencia y proveedor de la dependencia, se convierte en el
controlador en lugar de los propios requisitos de los usuarios.  Al darse cuenta de
que cada decisión tomada con respecto a IT nos hace depender de que la tecnología,
la intención de este principio es garantizar que el software de aplicación no
depende de hardware específico y software de sistemas operativos. Implicaciones:  
 Este principio requiere normas que apoyan la portabilidad.  Para Commercial Off-
The-Shelf (COTS) y Gobierno Off-The-Shelf (GOTS) aplicaciones, no se podrá limitar
las opciones actuales, ya que muchas de estas aplicaciones son la tecnología y
dependiente de la plataforma.  tendrán que ser desarrolladas para permitir que las
aplicaciones de legado para interoperar con aplicaciones y entornos operativos
desarrollados bajo la arquitectura de la empresa las interfaces del subsistema. 
Middleware debería utilizarse para separar las aplicaciones de soluciones de
software específicas.  A modo de ejemplo, este principio podría llevar al uso de
Java, y los protocolos de Java como futuras, que le dan un alto grado de prioridad
a la independencia de la plataforma. 

 

Principio 17: Facilidad de Uso

Declaración:  Las aplicaciones son fáciles de usar. La tecnología subyacente es

transparente para los usuarios, para que puedan concentrarse en las tareas a mano. 
Justificación:  Cuanto más un usuario tiene que entender la tecnología subyacente,
menos productiva que el usuario es. La facilidad de uso es un incentivo positivo
para el uso de aplicaciones. Se anima a los usuarios a trabajar dentro del entorno
integrado de información en lugar de desarrollar sistemas aislados para realizar la
tarea fuera del entorno de la información integrada de la empresa. La mayor parte
de los conocimientos necesarios para operar un sistema será similar a los demás.
Formación se mantiene a un mínimo, y el riesgo de usar un sistema de forma
incorrecta es baja.  Usando una aplicación debe ser lo más intuitivo como conducir
un coche diferente.

  Página 254 de 670 

TOGOF 9.1    
Implicaciones:   Se requiere aplicaciones para tener un "look-and-feel" común y
apoyar a los requisitos ergonómicos. Por lo tanto, el estándar de look-and-feel
común debe ser diseñado y criterios de prueba de usabilidad debe ser desarrollado. 
Directrices para las interfaces de usuario no deben ser limitados por supuestos
estrechos acerca de la ubicación del usuario, el idioma, la formación de sistemas,
o capacidad física. Factores tales como la lingüística, los clientes achaques
físicos (agudeza visual, capacidad de utilizar el teclado / ratón), y competencia
en el uso de la tecnología tienen amplias ramificaciones en la determinación de la
facilidad de uso de una aplicación. 

23.6.4 Principios Tecnológicos

Cambio de base-Requisitos: Principio 18

Declaración:  Sólo en respuesta a las necesidades del negocio son cambios en las
aplicaciones y la tecnología realizada.  Justificación:  Este principio será
fomentar un ambiente en el que el entorno de la información cambia en respuesta a
las necesidades de la empresa, en lugar de tener el cambio de negocio en respuesta
a los cambios de TI. Esto es para asegurar que el objetivo de la ayuda la
información - la operación de los negocios - es la base de cualquier cambio
propuesto. Los efectos no intencionales en los negocios debido a que los cambios se
reducen al mínimo. Un cambio en la tecnología puede proporcionar una oportunidad
para mejorar los procesos de negocio y, por tanto, cambiar las necesidades del
negocio.  Implicaciones:      Cambios en la aplicación seguirán examen completo
de los cambios propuestos que utilizan la arquitectura empresarial.  No financiamos
una mejora o un sistema de desarrollo técnico a menos que exista una necesidad de
negocio documentado.  los procesos de gestión del cambio que se ajusten a este
principio serán desarrollados e implementados.  Este principio puede chocar contra
el principio de un cambio sensible. Debemos asegurar el proceso de documentación
requisitos no impide el cambio de respuesta para satisfacer las necesidades
comerciales legítimos. El propósito de este principio es mantenernos enfocados en
los negocios, no las necesidades de tecnología - Cambio de respuesta es también una
necesidad de negocio.

    Página 255 de 670 

TOGOF 9.1    
Principio 19: Cambio Responsive Gestión

Declaración:  Los cambios en el entorno de la información empresarial se

implementan de una manera oportuna.  Justificación:  Si las personas son de esperar
para trabajar en el entorno de la información empresarial, ese entorno la
información debe ser sensible a sus necesidades.  Implicaciones:    Tenemos que
desarrollar procesos para gestionar e implementar el cambio que no generan
retrasos.  Un usuario que sienta la necesidad de cambio tendrá que conectar con un
"experto en los negocios" para facilitar la explicación y la aplicación de esa
necesidad.  Si vamos a hacer cambios, debemos mantener las arquitecturas
actualizado.  La adopción de este principio podría requerir recursos adicionales. 
Este entrará en conflicto con otros principios (por ejemplo, el máximo beneficio de
toda la empresa, las aplicaciones en toda la empresa, etc.) 

  

Principio 20: Diversidad Técnica de Control

Declaración:  La diversidad tecnológica es controlado para minimizar el costo no

trivial de acumular conocimientos especializados y la conectividad entre múltiples
entornos de procesamiento.  Justificación:  Existe un verdadero costo, no trivial
de la infraestructura necesaria para apoyar las tecnologías alternativas para
entornos de procesamiento. Hay otros costos de infraestructura incurridos para
mantener múltiples construcciones de procesadores interconectados y mantenidos.  La
limitación del número de componentes soportados va a simplificar y reducir los
costos de mantenimiento. Las ventajas comerciales de la diversidad técnicos mínimos
son: un empaquetado estándar de los componentes; impacto de la implantación
predecible;valoraciones y retornos predecibles; redefinido las pruebas; estado de
utilidad; y aumento de la flexibilidad para acomodar los avances tecnológicos.
Tecnología Común en toda la empresa brinda los beneficios de las economías de
escala para la empresa. Costos de administración y de apoyo técnico se controlan
mejor cuando los recursos limitados pueden centrarse en este conjunto compartido de
la tecnología.

  Página 256 de 670 

TOGOF 9.1    
Implicaciones:    Las políticas, normas y procedimientos que rigen la adquisición
de la tecnología deben estar vinculados directamente a este principio.  Las
opciones tecnológicas se verán limitados por las opciones disponibles dentro del
plan de tecnología. Procedimientos para aumentar la tecnología aceptable
establecido para satisfacer las nuevas necesidades tendrán que ser desarrollado y
puesto en marcha.  No estamos congelando nuestra línea de base tecnológica. Damos
la bienvenida a los avances tecnológicos y cambiaremos el plan de tecnología cuando
la compatibilidad con la infraestructura actual, la mejora en la eficiencia
operativa, o una capacidad requerida ha sido demostrada. 

Principio 21: Interoperabilidad

Declaración:  Software y hardware deben ajustarse a las normas definidas que
promuevan la interoperabilidad de los datos, las aplicaciones y la tecnología. 
Justificación:  Las normas ayudan a garantizar la coherencia, mejorando así la
capacidad de administrar los sistemas y mejorar la satisfacción del usuario, y
proteger las inversiones existentes, maximizando así la rentabilidad de la
inversión y la reducción de costos. Los estándares para la interoperabilidad,
además, ayudan a asegurar el apoyo de múltiples proveedores para sus productos, y
facilitan la integración de la cadena de suministro.  Implicaciones:   Los
estándares de interoperabilidad y estándares de la industria serán seguidas a menos
que exista una razón de negocios para implementar una solución no estándar.  Un
proceso para el establecimiento de normas, examinar y revisar periódicamente, y la
concesión de excepciones debe ser establecido.  Las plataformas existentes deben
ser identificados y documentados. 

 

  Página 257 de 670 

TOGOF 9.1       

24. Gestión de las partes interesadas 24.1 Introducción

Gestión de las partes interesadas es una disciplina importante que los
profesionales de la arquitectura de éxito puede utilizar para ganar el apoyo de los
demás. Esto les ayuda a garantizar que sus proyectos tengan éxito donde otros
fracasan. Los beneficios de la exitosa gestión de los interesados son las
siguientes:  Los más poderosos partes interesadas pueden ser identificados
temprano y su entrada a continuación, se pueden utilizar para dar forma a la
arquitectura; esto asegura su apoyo y mejora la calidad de los modelos producidos. 
El apoyo de los grupos de interés más poderosos ayudará a que el compromiso de
ganar más recursos, con lo que la participación de la arquitectura más
probabilidades de éxito.  Mediante la comunicación con las partes interesadas
temprano y con frecuencia, el equipo de arquitectura puede asegurarse de que
comprenden plenamente el proceso de la 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 se puede
anticipar con mayor eficacia probables reacciones a 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, evitando o tratar cualquier reacción
negativa.  El equipo de arquitectura puede identificar objetivos en conflicto o en
competencia entre las partes interesadas temprana y desarrollar una estrategia para
resolver los problemas que surgen de ellos. 

 

Es esencial en cualquier iniciativa para identificar a los individuos y grupos

dentro de la organización que contribuyan al desarrollo de la arquitectura,
identificar aquellos que ganará y los que perderán a partir de su introducción, y
luego desarrollar una estrategia para tratar con ellos.

24.2 Enfoque de gestión de los interesados

Análisis de los interesados se debe utilizar durante la Fase A (Architecture
Vision) para identificar los actores clave en el compromiso, y también se
actualizará a lo largo de cada fase; diferentes grupos de interés pueden ser
descubiertos como el compromiso progresa a través en oportunidades y soluciones, de
planeamiento de migración, y Arquitectura de Gestión del Cambio. Arquitecturas
complejas son muy difíciles de manejar, no sólo en términos del propio proceso de
desarrollo de la arquitectura, sino también en términos de obtener el acuerdo de la
gran cantidad de grupos de interés afectados por ella. Por ejemplo, al igual que un
arquitecto de la construcción va a crear esquemas eléctricos, planos de planta y
elevaciones para describir las distintas facetas de un edificio para sus diferentes
grupos

  Página 258 de 670 

TOGOF 9.1    
de interés (electricistas, propietarios, funcionarios de planificación), por lo que
un arquitecto de la empresa debe crear diferentes puntos de vista de la empresa,
arquitectura de sistemas de información y tecnología para los grupos de interés que
tienen inquietudes relacionadas con estos aspectos. TOGAF identifica
específicamente este tema en todo el ADM a través de los siguientes conceptos (como
se define en 35.1 Conceptos Básicos ):     Las partes interesadas 
Preocupaciones  Vistas  Puntos de Vista 

24.3 Pasos en el proceso de gestión de los grupos de interés

Las siguientes secciones detallan recomienda la actividad de gestión de los grupos
de interés.

24.3.1 Identificar a los Interesados

Identificar los grupos de interés clave de la arquitectura de la empresa. La
primera tarea es la de una lluvia de ideas que los principales grupos de interés de
arquitectura empresarial son. Como parte de esto, piensa en todas las personas que
se ven afectados por ella, que tienen influencia o poder sobre él, o tienen un
interés en su conclusión exitosa o no. Puede incluir los altos ejecutivos, los
roles de organización de proyectos, roles de la organización cliente, los
desarrolladores de sistemas, socios de la alianza, los proveedores, las operaciones
de TI, clientes, etc En la identificación de los interesados, existe el peligro de
concentrarse demasiado en la estructura formal de una organización como la base
para la identificación. Los grupos informales de partes interesadas pueden ser tan
poderosos e influyentes como los formales. La mayoría de los individuos pertenecen
a más de un grupo de interesados, y estos grupos tienden a surgir como resultado de
eventos específicos. Mira quién está afectado por el proyecto de arquitectura de la
empresa:      ¿Quién gana y quién pierde con este cambio?  ¿Quién controla la
gestión del cambio de los procesos?  ¿Quién diseña nuevos sistemas?  ¿Quién tomará
las decisiones?  ¿Quién adquiere sistemas de TI y quién decide qué comprar? 

  Página 259 de 670 

TOGOF 9.1    
   ¿Quién controla los recursos?  ¿Quién tiene habilidades especiales que
necesita el proyecto?  ¿Quién tiene influencia? 

En particular, los influyentes deben ser identificados. Estos serán muy respetados
y se mueve hacia arriba, participar en las reuniones y comités importantes (ver
actas de reuniones), saben lo que está pasando en la empresa, ser valorado por sus
compañeros y superiores, y no necesariamente estar en cualquier posición formal de
poder. Aunque los interesados pueden ser tanto organizaciones como personas, en
última instancia, el equipo de arquitectura de la empresa tendrá que comunicarse
con la gente.Se trata de los actores individuales correctas dentro de una
organización de las partes interesadas que necesitan ser identificados formalmente.
Análisis de los actores 24.3.1.1 Muestra
Un análisis de los actores muestra que distingue 22 tipos de grupos de interés en
cinco grandes categorías, se muestra en la Figura 24-1 . Cualquier proyecto de
arquitectura en particular puede tener más, menos o diferentes grupos de interés; y
pueden ser agrupadas en más, menos, o de diferentes categorías.

  Figura 24‐1: Las partes interesadas de la muestra y Categorías   
Página 260 de 670 

TOGOF 9.1    
Tenga en cuenta tanto el Visible equipo - los obviamente asociado al proyecto /
cambio - y el equipo Invisible - los que tienen que hacer una verdadera
contribución al proyecto / cambio para que sea un éxito, pero que no han estado
vinculadas al mismo (por ejemplo, los proveedores de servicios de apoyo).

24.3.2 Posiciones Clasifique las partes interesadas

Desarrollar una buena comprensión de los actores más importantes y grabar este
análisis para referencia y refrescarse durante el proyecto. Un análisis de los
interesados ejemplo se muestra en la Tabla 24-1 .

 
Grupo de Tenedor de Capacidad partes apuestas de alterar el interesadas Cambio CIO
John Smith H CFO Jeff Brown M Actual comprensión M M Se requiere la comprensión H M
-Promiso actual L L -Promiso Apoyo Requerido Requerido M M H M

Ejemplo de análisis de las partes interesadas: Tabla 24‐1 
También es importante evaluar la disposición de cada uno de los interesados que se
comporten de una manera que apoye (es decir, demostrar su compromiso con la
iniciativa de arquitectura de la empresa).

Esto se puede hacer haciendo una serie de preguntas:    ¿Es esa persona
dispuesta a cambiar de dirección y comenzar a moverse hacia la Arquitectura
objetivo? Si es así, ¿listo?  ¿Es esta persona capaz de ser un defensor creíble o
agente de la iniciativa de la arquitectura empresarial propuesto? Si es así, cómo
es capaz?  ¿Qué tan involucrado está el individuo en la iniciativa de arquitectura
de la empresa? Son simplemente un observador interesado, o qué tienen que estar
involucrados en los detalles?  Esa persona ha hecho un compromiso contractual para
el desarrollo de la arquitectura de la empresa, y su papel en la gobernanza del
desarrollo de la organización? 

Luego, para cada persona cuyo compromiso es fundamental para garantizar el éxito,
hacer un juicio acerca de su actual nivel de compromiso y el nivel deseado de
compromiso futuro.

24.3.3 Determinar el enfoque de gestión de las partes interesadas

Los pasos anteriores identificaron una larga lista de personas y organizaciones que
se ven afectadas por el proyecto de arquitectura empresarial. Algunos de ellos
pueden tener el poder, ya sea para bloquear o avanzar. Algunos pueden estar
interesados en lo que la iniciativa de arquitectura de la empresa que está
haciendo; otros no

  Página 261 de 670 

TOGOF 9.1    
pueden cuidar. Este paso permite al equipo ver fácilmente que se espera que los
interesados para ser bloqueantes o los críticos, y que son susceptibles de ser
defensores y partidarios de la iniciativa de las partes interesadas. Calcula el
poder de las partes interesadas, la influencia y los intereses, a fin de enfocar la
participación de arquitectura empresarial de los individuos clave. Estos se pueden
asignar a una matriz de poder / interés, lo que también indica la estrategia a
adoptar para colaborar con ellos. Figura 24-2 muestra un ejemplo de matriz red
eléctrica.

  Figura 24‐2: Stakeholder Power Grid 
24.3.4 Tailor Engagement Entregables
Identificar los catálogos, matrices y diagramas 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 los catálogos específicos, matrices y
diagramas que son relevantes para un modelo de arquitectura de la empresa en
particular. Esto permite que la arquitectura se comunique a, y entendida por todos
los interesados, y les permite verificar que la iniciativa de arquitectura de la
empresa se ocupará de sus preocupaciones.

24.4 Plantilla Stakeholder Mapa

La siguiente tabla proporciona un ejemplo mapa de las partes interesadas para un
proyecto de arquitectura TOGAF que tiene grupos de interés identificados en la
Figura 24-1 .
Tenedor de apuestas CxO (Funciones Corporativas), por ejemplo, el CEO, CFO, CIO,
COO Preocupaciones claves Clase Catálogos, matrices y diagramas Diagrama de Huella
de negocios Meta / Objetivo diagrama / Servicio Organización diagrama de
descomposición Catálogo de Requisitos

Los pilotos de alto nivel, las MANTENGA metas y objetivos de la SATISFECHO

organización, y cómo éstos se traducen en un proceso efectivo y la arquitectura de
TI para avanzar en el negocio. Priorizar, la financiación, y MANTENGA la alineación
de la actividad SATISFECHO

Oficina del Programa de Gestión

  Página 262 de 670 

TOGOF 9.1    
(Funciones Corporativas), por ejemplo, los Gerentes de Cartera de Proyectos de
cambio. La comprensión de los contenidos del proyecto y las dependencias técnicas
entre los proyectos apoya la gestión de carteras de toma de decisiones. Diagrama de
Contexto del Proyecto Diagrama de Beneficios Diagrama de Huella de negocios
Diagrama de comunicaciones de la aplicación Diagrama de descomposición funcional
Adquisiciones Entender lo que los bloques JUGADORES CLAVE Catálogo Cartera
(Funciones de construcción de la Tecnológica Corporativas); arquitectura se pueden
por ejemplo, los comprar, y qué Catálogo de Normas de compradores restricciones (o
reglas) son Tecnología relevantes para la compra. Los compradores harán compras con
múltiples proveedores en busca de la mejor solución de coste, si bien respetando
las restricciones (o reglas) derivados de la arquitectura, como las normas. La
principal preocupación es hacer que las decisiones de compra que se ajustan a la
arquitectura. Recursos Humanos (HR) Se requieren los roles y MANTENGA Organización
diagrama de (Funciones actores para apoyar la INFORMADO descomposición
Corporativas), arquitectura y los cambios a por ejemplo, directores de la misma. La
principal Catálogo de Organización recursos humanos, preocupación es la gestión /
Actor Formación y Gerentes de de las personas Desarrollo transiciones. Ubicación
catálogo Aplicación y usuario diagrama Ubicación Asegurar que la JUGADORES CLAVE
Diagrama del ciclo de vida información, los datos y los del producto sistemas de la
organización están disponibles sólo para Diagrama de Divulgación aquellos que
tienen el de Datos permiso, y la protección de la información, los datos y Diagrama
de seguridad los sistemas de de datos manipulación no autorizada. Matriz Actor /
Rol Diagrama de Hardware en

Enterprise Security (Funciones Corporativas), por ejemplo, Gestión de Riesgo

Corporativo, Oficiales de Seguridad, Gerentes de Seguridad

  Página 263 de 670 

TOGOF 9.1    
Red Informática Ingeniería de Comunicaciones diagrama QA / Standards Group Asegurar
la gobernabilidad JUGADORES CLAVE Proceso / Evento / Control (Funciones consistente
de negocio de / Catálogo de productos Corporativas), la organización, datos, por
ejemplo, los aplicaciones y activos de Catálogo Contract / propietarios de los
datos, tecnología. Medida los dueños de procesos, normas técnicas Cuerpos Catálogo
de la cartera de aplicaciones Catálogo de interfaz Catálogo de Normas de Tecnología
Catálogo Cartera Tecnológica Diagrama de Huella de negocios Meta / Objetivo
diagrama / Servicio Organización diagrama de descomposición Diagrama de Flujo del
Proceso Diagrama de comunicaciones de la aplicación Gestión de líneas Funciones de
nivel superior JUGADORES CLAVE Diagrama de Huella de (Organización para el y los
procesos de la negocios usuario final); organización, y cómo las por ejemplo, los
altos aplicaciones clave de Organización diagrama de directivos empresariales,
apoyar estos procesos. descomposición Gerentes Regionales de Operaciones, Gerentes
de Diagrama de TI descomposición funcional Diagrama de Flujo del Proceso Diagrama
de comunicaciones de la aplicación Aplicación y usuario diagrama Ubicación

Ejecutivo Los pilotos de alto nivel, las MANTENGA (End User Organization); metas y
objetivos de la SATISFECHO por ejemplo, los organización, y cómo éstos Directores
de Unidad de se traducen en un proceso Negocio, CxOs Unidad de y la arquitectura
para Negocios, Business Unit avanzar en el negocio Director de TI / eficaz.
Arquitectura

  Página 264 de 670 

TOGOF 9.1    
Negocios Expertos de dominio (Organización para el usuario final); por ejemplo,
expertos de procesos de negocio, Business Analyst / Proceso, Proceso Arquitecto,
Diseñador de procesos, gerentes funcionales, Analista de Negocios Aspectos
funcionales de los JUGADORES CLAVE procesos y sistemas de apoyo. Esto puede cubrir
los actores humanos involucrados en el sistema, los procesos de usuario que
intervienen en el sistema, las funciones que se requieren para apoyar los procesos
y la información necesarios para fluir en apoyo de los procesos. Matriz de
interacción de negocios Matriz Actor / Rol Diagrama de Business Service /
Information Diagrama de descomposición funcional Diagrama del ciclo de vida del
producto Negocios diagrama de casos de uso Esquema de aplicación de casos de uso
Diagrama de comunicaciones de la aplicación Entity Data / matriz de funciones de
negocios Catálogo de Normas de Tecnología Catálogo Cartera Tecnológica Catálogo
Contract / Medida Diagrama Realización de proceso / aplicación Diagrama de
administración de Enterprise Enfoque de Desarrollo, la JUGADORES CLAVE Diagrama
Realización de modularidad del software y proceso / aplicación la reutilización,
portabilidad de migración, y la Aplicación / matriz de interoperabilidad. datos
Diagrama de Migración de aplicaciones Software diagrama de Ingeniería

IT Service Management Asegurar que los servicios MANTENGA (Operaciones de de TI

proporciona a la INFORMADO Sistemas), organización a cumplir con por ejemplo, el
los niveles de servicio Administrador de servicios requeridos por la de entrega
organización para tener éxito en los negocios.
Operaciones de TI Aplicaciones (Operaciones de sistema); por ejemplo, la
arquitectura de aplicaciones, sistemas y software Ingenieros

  Página 265 de 670 

TOGOF 9.1    
Diagrama de la descomposición Plataforma Diagrama de Red Informática / Hardware
Diagrama de distribución de software Operaciones de TI Ubicación, modificabilidad,
JUGADORES CLAVE Diagrama de Infraestructura reusabilidad y la descomposición
(Operaciones de disponibilidad de todos los Plataforma sistema); componentes del
por ejemplo, Arquitecto de sistema.Asegurar que los Catálogo de Normas de
Infraestructura, apoyo componentes adecuados se Tecnología Wintel, soporte de gama
desarrollan y despliegan media, DBA Operacional, dentro del sistema de una Catálogo
Cartera Service Desk manera óptima. Tecnológica Diagrama de administración de
Enterprise Diagrama de Red Informática / Hardware Diagrama de Procesamiento
Ambientes y zonas diagrama Comunicaciones de datos Ubicación, modificabilidad,
JUGADORES CLAVE Ingeniería de / voz - Operaciones de TI reusabilidad y la
Comunicaciones ; (Operaciones del disponibilidad de servicios diagrama sistema) de
comunicaciones y de por ejemplo, redes. Asegurar que las administración de red
correspondientes comunicaciones y los servicios de redes se desarrollan y
despliegan dentro del sistema de una manera óptima. Ejecutivo En tiempos, entrega
en el MANTENGA Catálogo de Requisitos (Organización del presupuesto de una
INFORMADO proyecto); iniciativa de cambio que va Catálogo de Principios por
ejemplo, el a darse cuenta de los Patrocinador, el beneficios esperados para
Diagrama de la cadena de Administrador de la organización. valor programas Diagrama
conceptual de soluciones Diagrama de

  Página 266 de 670 

TOGOF 9.1    
descomposición funcional Aplicación y usuario diagrama Ubicación Diagrama de
comunicaciones de la aplicación Diagrama de descomposición funcional

Administración de Línea (Organización del proyecto); por ejemplo, Gerente de

Proyectos

El logro de vista operativo a MANTENGA tiempo, entrega del INFORMADO presupuesto de

una iniciativa de cambio con un alcance acordado.

Ambientes y zonas diagrama Business Process / La adición de más detalle a JUGADORES

CLAVE Diagrama de Flujo del Experto Funcional las necesidades funcionales Proceso
(Organización del de una iniciativa de cambio proyecto); basado en la experiencia y
Negocios diagrama de por ejemplo, Finanzas la interacción con expertos casos de uso
FICO Consultor en el dominio de negocio de Funcional, HR Consultor la organización
del usuario Diagrama de Business Funcional final. Service / Information Diagrama de
descomposición funcional Diagrama de comunicaciones de la aplicación Especialista
de Producto Especificación de diseños JUGADORES CLAVE Software diagrama de
(Organización del de productos de tecnología Ingeniería proyecto); con el fin de
cumplir con los por ejemplo, Especialista requisitos del proyecto y Aplicación /
matriz de Product Portal cumplir con la Visión de datos Arquitectura de la
solución. En un entorno de paquetes y servicios empaquetados, experiencia con el
producto se puede utilizar para identificar las capacidades de productos que se
pueden aprovechar fácilmente y pueden proporcionar orientación sobre las
estrategias de personalización del producto. Especificación de diseños JUGADORES
CLAVE de productos de tecnología con el fin de cumplir con los requisitos del
proyecto y cumplir con la Visión de Arquitectura de la solución.
Técnico Especialista (Organización del proyecto); por ejemplo, la solicitud de
Arquitecto

Software diagrama de Ingeniería Diagrama de descomposición Plataforma Diagrama

Realización de

  Página 267 de 670 

TOGOF 9.1    
proceso / aplicación Aplicación / matriz de datos Diagrama de Migración de
aplicaciones Diagrama de Huella de negocios Diagrama de comunicaciones de la
aplicación

Organismos Reguladores (Servicios exteriores); por ejemplo, Regulador Financiero,

Reguladora de la Industria

La recepción de la MANTENGA información que necesitan SATISFECHO con el fin de

regular la organización del cliente, y asegurar que sus requisitos de información
se satisfacen correctamente. Interesado en los procesos de información, y los datos
y las aplicaciones que se utilizan para proporcionar información de retorno
reguladora. Proveedores Asegurarse de que sus MANTENGA (Servicios exteriores);
necesidades de intercambio SATISFECHO por ejemplo, la Alianza de información se
reunieron socios, proveedores clave con el fin de que los contratos de servicio de
acuerdo con las organizaciones de los clientes se pueden cumplir.

Diagrama de Huella de negocios Diagrama de Business Service / Information Diagrama

de comunicaciones de la aplicación

   
 

25. Patrones Arquitectura

Este capítulo proporciona directrices para el uso de patrones de arquitectura.

25.1 Introducción
Patrones para architecting sistema son muy mucho en su infancia. Ellos se han
introducido en TOGAF esencialmente para atraerlos a la atención de la comunidad de
arquitectura de sistemas como un importante recurso emergente, y como marcador de
posición para las descripciones de esperar más rigurosos y las referencias a los
recursos más abundantes en las futuras versiones de TOGAF. Han no (todavía) han
integrado en TOGAF. Sin embargo, en la siguiente, se intenta indicar el valor
potencial de TOGAF, y qué partes de la Arquitectura Método de Desarrollo de TOGAF
(ADM) que podrían ser relevantes.

  Página 268 de 670 

TOGOF 9.1    
25.1.1 Antecedentes
Un "modelo" se ha definido como: "una idea que ha sido útil en un contexto práctico
y probablemente será útil para los demás" [ Los patrones de análisis - modelos de
objetos reutilizables ]. En TOGAF, los patrones son considerados como una forma de
poner bloques de construcción en su contexto; por ejemplo, para describir una
solución reutilizable a un problema. Bloques de construcción son lo que usted
utiliza: patrones pueden decir cómo usarlos, cuándo, por qué, y qué ventajas y
desventajas que tiene que hacer con ello. Los patrones ofrecen la promesa de ayudar
al arquitecto a identificar combinaciones de Arquitectura y / o solución de
Building Blocks (Abs / SBB) que han sido probados para ofrecer soluciones eficaces
en el pasado, y pueden proporcionar la base para soluciones eficaces en el futuro.
Técnicas patrón generalmente se reconoce que se han establecido como una valiosa
técnica de diseño de la arquitectura de Christopher Alexander, arquitecto de los
edificios, que describió este enfoque en su libro The Way intemporal de la
Construcción , publicado en 1979. Este libro ofrece una introducción a las ideas
detrás de la uso de patrones, y Alexander siguió con dos libros más ( un lenguaje
de patrones y el experimento de Oregon ) en la que se expandió en su descripción de
las características y beneficios de un enfoque patrones de arquitectura. Software y
edificios los arquitectos tienen muchos problemas similares a la dirección, y por
lo que era natural para los arquitectos de software que se interesan por los
patrones como una herramienta arquitectónica. Muchos artículos y libros han sido
publicados en ellos desde 1979 el libro de Alexander, quizás los más reconocidos
bienestar Patrones de diseño: Elementos de la Reusable de Software Orientado a
Objetos . Este libro describe las soluciones simples y elegantes a problemas
específicos en el diseño de software orientado a objetos.

25.1.2 Contenido de un Patrón

Varios formatos se utilizan en la literatura para describir los patrones, y hay un
formato único ha logrado una aceptación generalizada. Sin embargo, existe un amplio
acuerdo sobre los tipos de cosas que un patrón debe contener. Los títulos que
siguen están tomadas de Pattern-Oriented Architecture Software: Un sistema de
modelos .Los elementos que se describen a continuación se pueden encontrar en la
mayoría de los patrones, aunque diferentes partidas se usan para describirlos.
Nombre  Una manera significativa y memorable para referirse al patrón, por lo
general una sola palabra o frase corta.  Problema  Una descripción del problema que
indica la intención de aplicar el patrón - las metas y objetivos previstos que han
de alcanzarse en el contexto y las fuerzas se describen a continuación (quizás con
alguna indicación de sus prioridades).  Contexto 

  Página 269 de 670 

TOGOF 9.1    
Las condiciones en las que el patrón es aplicable - una descripción de la situación
inicial antes de que el patrón se aplican.  Fuerzas  Una descripción de las fuerzas
y limitaciones correspondientes, y cómo interactúan / conflicto entre sí y con las
metas y objetivos previstos. La descripción debe aclarar las complejidades del
problema y hacer explícitos los tipos de compensaciones que se deben considerar.
(La necesidad de tales concesiones es típicamente lo que hace que el problema
difícil, y genera la necesidad de que el patrón en el primer lugar.) La noción de
"fuerzas" equivale en muchos aspectos a las "cualidades" que los arquitectos buscan
la optimización, y las preocupaciones que tratan de dirección, en el diseño de
arquitecturas. Por ejemplo:            Seguridad, robustez, fiabilidad,
tolerancia a fallos  Capacidad de administración  La eficiencia, el rendimiento, el
rendimiento, los requisitos de ancho de banda, la utilización del espacio 
Escalabilidad (crecimiento gradual en la demanda)  extensibilidad, capacidad de
evolución, mantenibilidad  La modularidad, la independencia, la reutilización, la
apertura, la componibilidad (plug-and-play), la portabilidad  Integridad y
exactitud  Facilidad de construcción  Facilidad de uso  etc, ... 

Solución  Una descripción, el uso de texto y / o gráficos, de cómo alcanzar las

metas y objetivos previstos. La descripción debe identificar tanto la estructura de
la solución estática y su comportamiento dinámico - el pueblo y los actores de
computación y sus colaboraciones. La descripción puede incluir instrucciones para
implementar la solución. Variantes o especializaciones de la solución también se
pueden describir.  Resultando Contexto  Los post-condiciones después el patrón ha
sido aplicada. La implementación de la solución suele requerir compensaciones entre
las fuerzas de la competencia.Este elemento describe que las fuerzas se han
resuelto y cómo, y que siguen sin resolverse. También puede indicar otros patrones
que pueden ser aplicables en el nuevo contexto. (Un patrón puede ser un paso más en
el cumplimiento de una meta más grande.) Ninguno de estos otros modelos se
describen en detalle en los patrones relacionados. 

  Página 270 de 670 

TOGOF 9.1    
Ejemplos  Una o más aplicaciones de ejemplo del patrón que ilustran cada uno de los
otros elementos: un problema específico, el contexto y conjunto de fuerzas; cómo se
aplica el patrón; y el contexto resultante.  Razón fundamental  Una explicación /
justificación del modelo en su conjunto, o de los componentes individuales dentro
de ella, lo que indica cómo funciona realmente el patrón, y por qué cómo resuelve
los esfuerzos para alcanzar las metas y objetivos deseados, y por qué es "bueno".
El elemento de la solución de un patrón describe la estructura externa y el
comportamiento de la solución: la Razón da una idea de su funcionamiento interno. 
Patrones Relacionados  . Las relaciones entre este patrón y otros Estos pueden ser
patrones predecesoras, cuyos contextos resultantes corresponden al contexto inicial
de éste; o patrones sucesores, cuyos contextos iniciales corresponden al contexto
resultante de éste; o patrones alternativos, que describen una solución diferente
para el mismo problema, pero bajo diferentes fuerzas; o patrones de co-
dependientes, que pueden / deben ser aplicadas junto con este patrón.  Usos
conocidos  Aplicaciones conocidas del patrón dentro de los sistemas existentes, la
verificación de que el patrón de hecho describe una solución probada a un problema
recurrente. Usos conocido también puede servir de ejemplo.  Los patrones también
pueden comenzar con un resumen de proporcionar una visión general de la estructura
y la indicación de los tipos de problemas que trata. El Resumen también puede
identificar el público objetivo y qué suposiciones se hacen del lector.

25.1.3 Terminología
Aunque los patrones de diseño han sido el centro de gran interés en la industria
del software por varios años, particularmente en los campos de orientación a
objetos y software basado en componentes, es sólo recientemente que se ha producido
un creciente interés en los patrones de la arquitectura - la ampliación de los
principios y conceptos de patrones de diseño al dominio de la arquitectura. La
literatura técnica relacionada con este campo es complicado por el hecho de que
muchas personas en los campos de software usan el término "arquitectura" para
referirse al software, y muchos patrones se describe como "patrones de
arquitectura" son los patrones de diseño de software de alto nivel. Esto
simplemente hace que sea aún más importante para ser precisos en el uso de la
terminología.
25.1.3.1 patrones de arquitectura y patrones de diseño

El término "patrón de diseño" se usa con frecuencia para referirse a cualquier

modelo que trata temas de arquitectura de software, el diseño o la implementación
de programación. En Pattern-

  Página 271 de 670 

TOGOF 9.1    
Oriented Software Architecture: Un sistema de modelos , los autores definen estos
tres tipos de patrones de la siguiente manera:  Un modelo de arquitectura expresa
una organización estructural fundamental o esquema para sistemas de software.
Proporciona un conjunto de subsistemas predefinidos, especifica sus
responsabilidades, e incluye reglas y directrices para la organización de las
relaciones entre ellos.   Un patrón de diseño proporciona un esquema para refinar
los subsistemas o componentes de un sistema de software, o las relaciones entre
ellos. En él se describe una estructura comúnmente recurrentes de comunicar
componentes que resuelve un problema de diseño general en un contexto particular.  
Un Idiom es un patrón de bajo nivel específicos de un lenguaje de programación. Un
modismo describe cómo implementar aspectos particulares de los componentes o las
relaciones entre ellas utilizando las características de la lengua dada.  

Estas distinciones son útiles, pero es importante tener en cuenta que los patrones
de la arquitectura en este contexto todavía se refiere únicamente a la arquitectura
de software. La arquitectura de software es sin duda una parte importante del
enfoque de TOGAF, pero no es su único objetivo. En esta sección nos ocupamos de las
pautas architecting sistema de la empresa. Estos son análogos a la arquitectura de
software y patrones de diseño, y piden prestado muchos de sus conceptos y la
terminología, sino que se centran en la prestación de los modelos y métodos
reutilizables específicamente para el architecting de los sistemas de información
de la empresa que comprende software, hardware, redes, y la gente - en oposición
puramente a los sistemas de software.
25.1.3.2 Los patrones y el Continuum Arquitectura

Aunque los patrones de arquitectura han no (todavía) han integrado en TOGAF, cada
una de las primeras cuatro fases principales de la ADM (fases A a D) da una
indicación de la etapa en que los activos de arquitectura reutilizables relevantes
del Continuum Arquitectura empresa debe ser considerado para el uso. Patrones de
arquitectura son uno de esos activos. Una empresa que adopta un enfoque formal para
el uso y re-uso de patrones de arquitectura normalmente integrar su uso en el
Continuum Arquitectura empresarial.
25.1.3.3 Patrones y Vistas

Arquitectura vistas son partes de uno o más modelos que representan seleccionan una
completa arquitectura del sistema, centrándose en los aspectos que abordan las
preocupaciones de uno o más grupos de interés. Los patrones pueden proporcionar
ayuda en el diseño de este tipo de modelos, y en la composición de puntos de vista
basados en ellos.
25.1.3.4 Los patrones y escenarios empresariales

Patrones de arquitectura pertinentes pueden también ser identificados en el trabajo

sobre los escenarios de negocio.

  Página 272 de 670 

TOGOF 9.1    
25.1.4 patrones de arquitectura en uso
Dos ejemplos de patrones de arquitectura en uso se describen en los apartados
siguientes, uno por el dominio de la propia estructura la arquitectura de una
empresa cliente de TI, y el otro de un proveedor del sistema principal que ha hecho
un montón de trabajo en los últimos años en el campo de la arquitectura patrones. 
La Guía de Desarrollo de Arquitectura del Tesoro de EE.UU. (TADG) documento (ver
25.2 del Tesoro de EE.UU. Arquitectura Orientación para el Desarrollo (TADG) )
proporciona una serie de patrones de arquitectura explícitas, además de explicar la
razón de ser, la estructura, y la taxonomía de patrones de arquitectura y su
relación con los EE.UU. Tesoro.  Los Patrones de IBM para el sitio web de e-
Business (ver 25.3 Patrones de IBM para eBusiness ) da una serie de patrones de
arquitectura que van desde el problema de negocio para soluciones específicas, en
primer lugar, a nivel genérico y luego en términos de soluciones específicas de
productos de IBM. Un recurso de apoyo es del conjunto de IBM Libros Rojos .  


El siguiente material está diseñado para dar a los punteros del lector a algunos de
los lugares en los que ya están siendo utilizados y puestos a disposición patrones
de arquitectura, con el fin de ayudar a los lectores a tomar sus propias opiniones
en cuanto a la utilidad de esta técnica para sus propios entornos.

25.2 del Tesoro de EE.UU. Arquitectura Orientación para el Desarrollo (TADG)

El Tesoro de EE.UU. Arquitectura Orientación para el Desarrollo (TADG) documento -
antes conocido como el Sistema de Información Arquitectura de Marco Tesoro (TISAF)
- ofrece una serie de patrones de arquitectura explícitas. Sección 7 del documento
TADG describe una razón de ser, la estructura, y la taxonomía de patrones de
arquitectura, mientras que los patrones en sí se documentan formalmente en el
Apéndice D. Los patrones de arquitectura presentados abarcan un conjunto más amplio
de los sistemas que sólo los sistemas orientados a objetos.Algunos patrones de
arquitectura se centran en los sistemas de legado, algunos en sistemas concurrentes
y distribuidos, y algunos de los sistemas en tiempo real.

25.2.1 TADG contenido Pattern

El contenido de un patrón de arquitectura como se define en el documento de TADG
contiene los siguientes elementos: Nombre  Cada patrón de arquitectura tiene un
nombre descriptivo único, corto. La colección de nombres de los motivos
arquitectura se puede utilizar como un vocabulario para describir, verificar y
validar la información de arquitecturas de sistemas.  Problema 

  Página 273 de 670 

TOGOF 9.1    
Cada patrón de arquitectura contiene una descripción del problema a resolver. El
planteamiento del problema puede describir una clase de problemas o un problema
específico.  Razón fundamental  La justificación describe y explica un problema
específico típico que es representativa de la amplia clase de problemas a resolver
por el patrón de la arquitectura.Para un problema específico, puede proporcionar
información adicional sobre la naturaleza del problema y los requisitos para su
resolución.  Supuestos  Los supuestos son condiciones que deben cumplirse para que
el patrón de arquitectura que pueda utilizarse en la solución del problema.
Incluyen restricciones en la solución y los requisitos que pueden hacer que la
solución más fácil de usar. 

   
Estructura  El patrón de la arquitectura se describe en los diagramas y palabras en
el mayor detalle que se requiere para transmitir al lector los componentes del
patrón y sus responsabilidades.  Interacciones  Las relaciones e interacciones
importantes entre los componentes del patrón se describen y limitaciones sobre
estas relaciones e interacciones se identifican.  Consecuencias  Las ventajas y
desventajas del uso de este patrón se describen, en particular en términos de otros
patrones (ya sea necesaria o excluidos), así como las limitaciones de recursos que
puedan surgir de su uso.  Implementación  Asesoramiento sobre la ejecución
adicional que puede ayudar a los diseñadores en modificar este patrón de diseño
arquitectónico para los mejores resultados. 

25.2.2 TADG Arquitectura Patrones

El documento TADG contiene los siguientes patrones.
Diseño Arquitectónico Nombre del patrón -Client Proxy Server

Sinopsis Actúa como un concentrador para muchos enlaces de baja velocidad para
acceder a un servidor.
  Página 274 de 670 

TOGOF 9.1    
Atención al cliente Reactor Servidores replicados Arquitectura en capas Pipe y
filtro de Arquitectura Interfaz Subsistema Soporta complejo contacto con el cliente
a través de múltiples organizaciones. Desacopla un evento de su procesamiento.
Replica los servidores para reducir la carga en el servidor central. Una
descomposición de los servicios tales que la mayoría de las interacciones ocurren
sólo entre capas vecinas. Transforma la información en una serie de pasos o
procesos incrementales. Administra las dependencias entre grupos cohesivos de
funciones (subsistemas).

25.3 Patrones de IBM para e-Business

Los Patrones de IBM para e-Business web site (consulte www.ibm.com / framework /
patrones ) proporciona un grupo de activos reutilizables destinada a acelerar el
proceso de desarrollo de aplicaciones de e-business. A apoyar el sitio web de IBM
está Patrones de Recursos eBusiness (consulte www.ibm.com / developerworks /
patrones / biblioteca ). Esto también se conoce como los "Libros Rojos". La razón
fundamental para la prestación de estos patrones de IBM es:   Proporciona una
manera simple y consistente para traducir las prioridades y requerimientos de
negocio en soluciones técnicas  Asistir y acelerar el desarrollo de la solución y
el proceso de integración, facilitando el montaje de una solución y minimizando
personalizada implementaciones uno-de-unobueno  Captura el conocimiento y las
mejores prácticas de los expertos y ponerla a disposición para su uso por personal
menos experimentados  Facilitar la reutilización del capital intelectual, como las
arquitecturas de referencia, marcos y otros activos de arquitectura 

 

Patrones de IBM se centran específicamente en soluciones para e-Business; es decir,

los que permiten a una organización para aprovechar las tecnologías web para
negocios rediseñar los procesos, mejorar las comunicaciones y las fronteras
organizacionales inferiores con:    Los clientes y los accionistas (a través de
Internet)  Los empleados y grupos de interés (a través de una Intranet
corporativa)  Los vendedores, proveedores y socios (a través de una Extranet) 

Tienen la finalidad de abordar los siguientes desafíos encontrados en este tipo de

entorno:   Alto grado de integración con sistemas heredados dentro de la empresa
y con los sistemas fuera de la empresa  Las soluciones tienen que llegar a los
usuarios más rápido; esto no significa sacrificar la calidad, pero sí significa dar
con maneras mejores y más rápidos para desarrollar estas soluciones 

  Página 275 de 670 

TOGOF 9.1    
   Acuerdos de Nivel de Servicio (SLAs) son críticos  Necesidad de adaptarse a
las tecnologías y los ciclos de producción reducido drásticamente cambiando
rápidamente  Dirección una aguda escasez de las habilidades clave necesarias para
desarrollar soluciones de calidad 

IBM define cinco tipos de patrón:  Patrones de Negocios , que identifican a los
actores principales de negocio, y describen las interacciones entre ellos en
términos de las diferentes interacciones de negocios arquetípicos tales como:  o
Servicio (aka-user-to-business) - Los usuarios que acceden a las transacciones
sobre una base 24x7  Colaboración (alias de usuario a usuario) - los usuarios que
trabajan con otros para compartir datos e información  Información Aggregation (aka
de usuario a los datos) - datos de múltiples fuentes agregan y se presentó a través
de múltiples canales  Extended Enterprise (también conocido como de empresa a
empresa) - integración de datos y procesos a través de las fronteras empresariales 

o 

Patrones de Integración , que proporcionan el "pegamento" para combinar negocios

patrones para formar soluciones. Caracterizan el problema de negocio, procesos de
negocio / rules y el entorno existente para determinar si se requiere front-end o
back-end de la integración.  o Integración Front-end (aka la integración de acceso)
- centrado en proporcionar un acceso transparente y coherente para funciones de
negocios. Funciones típicas incluyen siempre de sesión único, personalización,
transcodificación, etc  Back-end de integración (también conocido como la
integración de aplicaciones) se centró en la conexión, interfaces, o la integración
de bases de datos y sistemas. Integración típica se puede basar en la función, el
tipo de la integración, el modo de integración, y por topología. 

Patrones compuestos , que son previamente identificados combinaciones y selecciones

de patrones comerciales y de integración, para las situaciones previamente
identificados como: soluciones de comercio electrónico, (públicos) de portales
empresariales, portal de intranet de la empresa, la colaboración ASP, etc  Patrones
de aplicaciones : Cada patrón de negocios e integración puede ser implementada
utilizando uno o más patrones de aplicación. Un patrón de aplicación caracteriza la
estructura de grano grueso de la aplicación - los principales componentes de la
aplicación, la asignación de funciones de procesamiento y las interacciones entre
ellos, el grado de integración entre ellos, y la colocación de los datos relativos
a las aplicaciones.  Los patrones de tiempo de ejecución : los patrones de
aplicaciones pueden ser implementadas por los patrones de tiempo de ejecución, lo
que demuestra, las características de nivel de servicio no funcionales, como el
rendimiento, capacidad,

  Página 276 de 670 

TOGOF 9.1    
escalabilidad y disponibilidad. Identifican las principales limitaciones de
recursos y las mejores prácticas.  El sitio web de IBM también proporciona (IBM)
las asignaciones de productos específicos para los patrones de tiempo de ejecución,
lo que indica las opciones tecnológicas específicas para su implementación.

25.4 Algunos Recursos Patrón

 Los patrones Home Page (consulte hillside.net / patrones ) organizada por el
Grupo de Hillside proporciona información acerca de los patrones, enlaces a modelos
en línea, artículos y libros relacionados con los patrones y patrones relacionados
con las listas de correo.  El Patrones-Discusión FAQ (consulte g.oswego.edu / dl /
pd-FAQ / pd-FAQ.html ) mantenido por Doug Lea ofrece un FAQ muy completa y de fácil
lectura sobre los patrones.  Modelos y Software: Conceptos Esenciales y
Terminología de Brad Appleton (se refieren a www.bradapp.com / docs / patrones
intro.html ) proporciona otra cuenta completa y legible del campo patrones. 

 

  Página 277 de 670 

TOGOF 9.1       

26. Escenarios empresariales y objetivos de la empresa

En este capítulo se describe un método para derivar los requisitos de negocio para
la arquitectura y los requisitos técnicos implicados. También proporciona
directrices sobre la definición de metas y objetivos para el desarrollo de la
arquitectura.

26.1 Introducción
Un factor clave en el éxito de una empresa de arquitectura es la medida en la que
esté vinculada a los requerimientos del negocio, y se puede demostrar el apoyo y
permite a la empresa a alcanzar sus objetivos de negocio. Escenarios de negocios
son una técnica importante que puede ser utilizado en diversas etapas de la
arquitectura de la empresa, principalmente la Visión Arquitectura y Arquitectura de
negocios, sino también en otros dominios de la arquitectura, así, si es necesario,
para deducir las características de la arquitectura directamente de la alta los
requisitos de nivel de la empresa. Se utilizan para ayudar a identificar y entender
las necesidades del negocio, y por lo tanto para obtener los requisitos de negocio
que el desarrollo de la arquitectura tiene que abordar. Un escenario de negocios
describe:     Un proceso de negocio, una aplicación o conjunto de aplicaciones
que pueden ser habilitadas por la arquitectura  El ambiente de negocios y la
tecnología  El pueblo y componentes informáticos (llamados "actores") que ejecutan
el escenario  El resultado deseado de la correcta ejecución 

Un buen escenario de negocios es representativo de una necesidad de negocio

importante o problema, y permite a los proveedores a comprender el valor de la
organización del cliente de una solución desarrollada. Un buen escenario de
negocios es también "SMART":    Específico , mediante la definición de lo que
hay que hacer en el negocio  Medible , a través de métricas claras para el éxito 
Actionable , a través de:  o o  Claramente segmentar el problema  Proporcionar la
base para determinar los elementos y los planes para la solución 

Realista , en que el problema puede resolverse dentro de los límites de la realidad

física, el tiempo, y las limitaciones de costo 

  Página 278 de 670 

TOGOF 9.1    
 De duración determinada , en el que hay una declaración clara de cuándo caduca la
oportunidad solución 

26.9 Directrices sobre Metas y Objetivos proporciona ejemplos detallados sobre los
objetivos que se podrían considerar. Independientemente objetivos que utilice, la
idea es hacer que los objetivos de SMART.

26.2 Beneficios de escenarios empresariales

Un escenario de negocios es esencialmente una descripción completa de un problema
de negocio, tanto en los negocios como en términos de arquitectura, que permite a
los requisitos individuales para ser visto en relación unos con otros, en el
contexto del problema general. Sin una descripción tan completa a servir como
contexto :  Existe el peligro de la arquitectura se basa en un conjunto incompleto
de los requisitos que no se suman a una descripción del problema en conjunto, y por
lo tanto que puede confundir a obra de arquitectura.  El valor de negocio de la
solución del problema no está clara.  La relevancia de las posibles soluciones es
clara. 

 

También, debido a que la técnica requiere de la participación de la gerencia de

línea de negocios y otras partes interesadas en una fase temprana en el proyecto de
arquitectura, sino que también desempeña un papel importante en la obtención de la
buy-in de este personal clave para el proyecto en general y su producto final - la
arquitectura de la empresa. Una ventaja adicional de escenarios de negocios se
encuentra en comunicación con los proveedores. La mayoría arquitectura hoy en día
se lleva a cabo haciendo uso máximo de Commercial Off-The-Shelf (COTS) de
soluciones de software, a menudo de múltiples proveedores, adquirido en el mercado
abierto. El uso de escenarios de negocio por un cliente que puede ser una ayuda
importante para los proveedores de TI en la entrega de soluciones adecuadas. Los
vendedores deben asegurarse de que sus componentes de soluciones agregan valor a
una solución abierta y son negociables. Escenarios de negocio proporcionan un
lenguaje con el que la comunidad de proveedores puede vincular los problemas del
cliente y soluciones técnicas. Además de hacer evidente lo que se necesita, y por
qué, que permiten a los proveedores para resolver problemas de manera óptima,
usando estándares abiertos y el aprovechamiento de las habilidades de cada uno.

26.3 Crear el escenario de negocios

26.3.1 Proceso general
Creación de un escenario de negocio consiste en la siguiente, como se ilustra en la
Figura 26-1 :

1. Identificar, documentar y clasificar el problema de conducir el escenario  2.

Identificar el entorno empresarial y técnica del escenario y documentarla en
modelos de escenarios    Página 279 de 670 

TOGOF 9.1     3. Identificar y documentar los objetivos deseados (los resultados de

la manipulación de los problemas con éxito); conseguir "SMART"  4. La
identificación de los actores humanos (participantes) y su lugar en el modelo de
negocio  5. La identificación de los actores de ordenador (elementos de
computación) y su lugar en el modelo de la tecnología  6. Identificar y documentar
los roles, responsabilidades y medidas de éxito por el actor; la
documentación de los scripts requeridos por el actor, y los resultados del manejo
de la situación 

7. Comprobación de la "aptitud para el propósito" y refinación sólo si es

necesario 

   
 

  Figura 26‐1: Crear un escenario de negocios 
Un escenario empresarial se desarrolla en una serie de fases iterativas de la
recopilación, análisis y revisión de la información en el escenario de negocios. En
cada fase, cada una de las áreas antes mencionadas se mejora sucesiva. El
refinamiento paso consiste en decidir si se debe considerar el escenario completo y
pasar a la siguiente fase, o si un mayor refinamiento es necesario. Esto se logra
al preguntar si el estado actual del escenario de negocio es apto para el propósito
de llevar a los requerimientos aguas abajo en el proceso de la arquitectura.
  Página 280 de 670 

TOGOF 9.1    
Las tres fases del desarrollo de un escenario de negocios se describen en detalle
más adelante, y representan en la Figura 26-2 .

  Figura 26‐2: Fases del desarrollo de escenarios empresariales 
26.3.2 Reunión
La fase de recopilación es donde se recoge información sobre cada una de las áreas
en la Figura 26-1 . Si los procedimientos y las prácticas de recopilación de
información ya están en su lugar en una organización - por ejemplo, para reunir
información para la planificación estratégica - que se debe utilizar según el caso,
ya sea durante los talleres de escenarios de negocios o en lugar de los talleres de
escenarios de negocios. Múltiples técnicas se pueden utilizar en esta fase, como la
búsqueda de información, el análisis cualitativo, análisis cuantitativo, encuestas,
solicitudes de información, etcComo la mayor información posible se debe reunir y
pre-procesado "off-line" antes de cualquier cara a cara, talleres de cara
(descritos a continuación). Por ejemplo, una solicitud de información pueden
incluir una solicitud de planes estratégicos y operativos. Estos documentos suelen
ofrecer grandes ideas, pero la información que contienen por lo general requiere
preprocesamiento significativo. La información puede ser utilizada para generar un
proyecto inicial de la situación empresarial antes del taller, si es posible. Esto
aumentará la comprensión y la confianza del arquitecto, y el valor del taller a sus
participantes. Una manera muy útil para recopilar información es la realización de
talleres de escenarios de negocio, por lo que un consultor escenario de negocios
lleva a un grupo selecto y pequeño de representantes de las empresas a través de
una serie de preguntas para obtener la información que rodea el problema que se
aborda por el esfuerzo de la arquitectura. Los asistentes al taller deben ser
cuidadosamente seleccionados de altos niveles en los lados empresariales y técnicos
de la organización. Es importante que la gente que puede y va a proporcionar
información abierta y

  Página 281 de 670 

TOGOF 9.1    
honestamente. Si ya existe un borrador del escenario de negocios - por ejemplo,
como resultado de la decodificación previa información recogida durante esta fase,
tal como se describe más arriba - el taller también se puede usar para examinar el
estado del proyecto de escenario de negocios. A veces es necesario tener varios
talleres: en algunos casos, para separar la recolección de información en la parte
comercial de la recogida de información sobre los aspectos técnicos; y en otros
casos simplemente para obtener más información de más personas. Cuando la
recolección de información, el arquitecto puede fortalecer enormemente el escenario
de negocios mediante la obtención de "ejemplos de la vida real"; es decir, los
estudios de casos para los que el lector puede relacionar fácilmente. Al citar
ejemplos del mundo real, es importante para mantener un nivel de anonimato de las
partes involucradas, para evitar la culpa.

26.3.3 Analizar
La fase de Análisis es donde una gran cantidad de trabajo de Arquitectura de
negocios de bienes se hace realidad. Aquí es donde la información que se recopila
es procesada y documentada, y donde se crean los modelos para representar esa
información, por lo general visualmente. La fase de Análisis se aprovecha de los
conocimientos y la experiencia del consultor escenario de negocios utilizando
trabajos anteriores y experiencia para desarrollar los modelos necesarios para
representar la información capturada. Tenga en cuenta que los modelos y documentos
producidos no son necesariamente reproducen textualmentelas entrevistas, sino que
se filtran y se traducen de acuerdo a las necesidades reales subyacentes. En la
fase de Análisis es importante para mantener los vínculos entre los elementos clave
de la situación empresarial. Una técnica que ayuda en el mantenimiento de tales
enlaces es la creación de matrices que se utilizan para relacionar los procesos de
negocio de cada uno de:      Circunscripciones  Actores Humanos  Actores
Informática  Cuestiones  Objetivos 

De esta manera, el proceso de negocio se convierte en el punto focal de unión, lo

que hace que una gran cantidad de sentido, ya que en la mayoría de los casos, es la
mejora de procesos de negocio que se está buscando.

26.3.4 Revisión
La fase de Revisión es donde los resultados son alimentados de nuevo a los
patrocinadores del proyecto para asegurar que existe un entendimiento compartido de
todo el alcance del problema, y la profundidad potencial del impacto técnico. Se
recomiendan varios talleres de escenarios de negocios o reuniones de "lectura" con
los patrocinadores y las partes involucradas. Las reuniones deben ser configurados
para ser abierto e

  Página 282 de 670 

TOGOF 9.1    
interactivo. Se recomienda contar con ejercicios incorporados en las agendas de
reuniones, con el fin de probar la comprensión de los asistentes y de los niveles
de interés, así como para poner a prueba los propios supuestos y resultados del
arquitecto. Esta fase es muy importante, ya que la ausencia de expectativas
compartidas en muchos casos es la causa fundamental del fracaso de los proyectos.

26.4 Contenido de un escenario de negocios

La documentación de un escenario de negocios debe contener todos los detalles
importantes sobre el escenario. Debe capturar, y la secuencia, los pasos críticos e
interacciones entre actores que se ocupan de la situación. También debe declarar
toda la información relevante acerca de todos los actores, en concreto: las
diferentes responsabilidades de los actores; las condiciones previas fundamentales
que han de cumplirse antes de la funcionalidad correcta del sistema; y los
requisitos técnicos para el servicio sean de calidad aceptable. Hay dos tipos
principales de contenido:. Gráficas (modelos), y un texto descriptivo Ambos tienen
un papel que desempeñar.  Modelos escenario empresarial vistas captura de negocios
y tecnología en una forma gráfica, para facilitar la comprensión. En concreto, se
relacionan los actores e interacciones, y dan un punto de partida para confirmar
los requisitos específicos.  Descripciones de escenarios de negocios capturar
detalles en forma textual. Una lista del contenido típico de un escenario de
negocios es la siguiente. 

 
Tabla de contenidos PRÓLOGO RESUMEN EJECUTIVO DOCUMENTO DE HOJA DE RUTA ESCENARIO
DE NEGOCIO Visión general del escenario NEGOCIO ANTECEDENTES DE ESCENARIO PROPÓSITO
DEL ESCENARIO DEFINICIONES / DESCRIPCIÓN DE LOS TÉRMINOS UTILIZADOS OPINIONES DE
LOS ENTORNOS Y PROCESOS ENTORNO EMPRESARIAL Circunscripciones Descripciones de
procesos Proceso de "a" etc .... ENTORNO TÉCNICO Entorno técnico "a" etc ....
ACTORES Y SUS ROLES Y RESPONSABILIDADES ACTORES Y ROLES DEL ORDENADOR RELACIÓN DE
LOS COMPONENTES Y PROCESOS ACTORES Y ROLES HUMANOS RELACIÓN DE LAS PERSONAS Y LOS
PROCESOS ANÁLISIS DE FLUJO DE INFORMACIÓN PRINCIPIOS Y LIMITACIONES

  Página 283 de 670 
TOGOF 9.1    
Principios de TI Restricciones REQUISITOS ANÁLISIS DE ESCENARIOS DE NEGOCIO Resumen
del problema Cuestiones Objetivos RESUMEN ANEXOS ANEXO A: ESCENARIOS DE NEGOCIOS -
INFORMACIÓN ADICIONAL APÉNDICE Bn: NOTAS ESCENARIO DEL TALLER

26.5 Las contribuciones al Escenario de Empresas

Es importante darse cuenta de que la creación de un escenario de negocios no es el
único de la provincia del arquitecto. Como se mencionó anteriormente, la gestión de
la línea de negocios y otras partes interesadas en la empresa están involucrados,
para asegurar que los objetivos de negocio se capturan con precisión. Además,
dependiendo de la relación que la organización tiene con sus proveedores de TI,
estos últimos también pueden estar involucrados, para garantizar que las funciones
de las soluciones técnicas también se capturan con precisión, y para asegurar la
comunicación con los proveedores. Por lo general, la participación de la gestión
empresarial es mayor en las primeras etapas, mientras que los problemas de las
empresas se están explorando y capturados, mientras que la participación del
arquitecto es mayor en las etapas posteriores, y cuando se están describiendo
soluciones arquitectónicas. Del mismo modo, si los vendedores están involucrados en
el proceso de escenarios de negocio, la participación del lado del cliente (gestión
empresarial, más arquitectos de la empresa) es mayor en las primeras etapas,
mientras que la de los vendedores es el mayor en las etapas posteriores, cuando el
papel de la técnica específica soluciones se están explorando y capturaron. Este
concepto se ilustra en la Figura 26-3 .

 
Figura 26‐3: Contribuciones relación con un escenario de negocios 

  Página 284 de 670 

TOGOF 9.1    
Arquitectos de TI de proveedores podrían ser capaces de ayudar a los arquitectos de
TI de la empresa con la integración de los productos de los vendedores en la
arquitectura de la empresa. Esta asistencia muy probablemente cae en medio de la
línea de tiempo en la Figura 263.

26.6 Escenarios de Negocio y el TOGAF ADM

Escenarios empresariales figura más prominente en la fase inicial del Método
Arquitectura Desarrollo (ADM), Architecture Vision, cuando se utilizan para definir
los requisitos de negocio relevantes, y para construir un consenso con la gestión
de las empresas y otros grupos de interés. Sin embargo, los requerimientos del
negocio se hace referencia a lo largo de todas las fases del ciclo de ADM, como se
ilustra en la Figura 26-4 .

  Página 285 de 670 

TOGOF 9.1    

   
  Figura 26‐4: Importancia de los Requisitos A lo largo de la ADM 
Debido a los requerimientos del negocio son importantes en todas las fases del
ciclo de ADM, la técnica de escenario de negocios tiene un papel importante que
desempeñar en el TOGAF ADM, al asegurar que los propios requerimientos del negocio
son completos y correctos.

26.7 Desarrollo de Escenarios empresariales

26.7.1 Directrices Generales
Las partes interesadas (por ejemplo, administradores de empresas, usuarios finales)
le dirán lo que quieran, pero como arquitecto que aún deben obtener una comprensión
de los negocios, por lo que deben saber los actores más importantes en el sistema.
Si las partes interesadas no saben lo que quieren:     Tómese su tiempo,
observar y grabar cómo están trabajando hoy  Estructura de información de tal
manera que se puede utilizar más tarde  Destape las reglas de negocio críticos de
los expertos de dominio  Manténgase enfocado en lo que se necesita lograr, y cómo
se va a lograr 

Este esfuerzo proporciona el ancla para una cadena de la razón a partir de los
requerimientos del negocio a través de soluciones técnicas. Se dará sus frutos más
adelante ser diligente y crítica en la salida.

26.7.2 Preguntas que debe hacer para cada área

El escenario de negocios talleres mencionó anteriormente en la fase de recopilación
de entrevistas son muy estructurados. Si bien no existe un único conjunto de
preguntas apropiadas para preguntar en todas las situaciones, lo siguiente puede
servir de orientación para ayudar a los consultores de escenarios de negocio en
hacer preguntas.
La identificación, documentación, y Clasificación del Problema

¿El problema se describe como una declaración de lo que se necesita hacer, como los
pasos de un proceso, y no la forma (con la tecnología "push")? Si el problema es
demasiado específico o un "cómo":   Levantar una bandera roja  Pregunte "¿Por qué
necesita para hacerlo de esa manera?" preguntas 

  Página 286 de 670 

TOGOF 9.1    
Si el problema es demasiado vaga o no recurribles:   Levantar una bandera roja 
Pregunta "¿Qué es lo que hay que hacer, o va a ser capaz de hacer si se resuelve
este problema?" preguntas 

Haga preguntas que ayuden a identificar dónde y cuándo existe el problema:  

¿Adónde experimentando este problema en particular? En qué negocio proceso? 
¿Cuándo se encuentra con estos problemas? Durante el inicio del proceso, el medio,
el extremo? 

Haga preguntas que ayuden a identificar los costos del problema:     Cómo se
explica por los costos asociados con este problema? Si es así, ¿cuáles son?  ¿Hay
costos ocultos? Si es así, ¿cuáles son?  ¿El costo de este problema cubierto por el
costo de algo más? Si es así, qué y cuánto?  ¿El problema se manifiesta en términos
de mala calidad o una percepción de una organización ineficaz? 

Identificar el entorno empresarial y Técnico y Documentación de Modelos

Preguntas que debe hacer sobre el entorno empresarial:     ¿Qué proceso clave
sufre de los problemas? ¿Cuáles son los pasos principales que necesitan ser
procesados?  Ubicación / escala de departamentos internos de negocios?  Ubicación /
escala de socios de negocios externos?  Cualquier reglas y regulaciones de negocios
específicos relacionados con la situación? 

Preguntas que debe hacer sobre el entorno tecnológico actual:    ¿Qué

componentes de tecnología ya se presuponen estar relacionados con este problema? 
¿Existen limitaciones de la tecnología?  ¿Existen principios tecnológicos que se
aplican? 

Identificar y documentar los objetivos

¿Es el "qué" suficientemente respaldada con la justificación de "por qué"? Si no,

pida razón de ser medible en las siguientes áreas:

  Página 287 de 670 

TOGOF 9.1    
     Retorno de la inversión  Escalabilidad  Necesidades de rendimiento 
Conformidad con las normas  La facilidad de uso de las medidas de 

La identificación de los actores humanos y su lugar en el Modelo de Negocio

Un actor representa cualquier cosa que interactúa con o dentro del sistema. Esto
puede ser una un programa de ordenador humano, o una máquina, o. Actores iniciar la
actividad con el sistema, por ejemplo:     Usuario de la computadora con el
ordenador  Usuario del teléfono con el teléfono  Empleado de la nómina con el
sistema de nómina  Suscriptor de Internet con el navegador web 

Un actor representa un rol que un usuario juega; es decir, el usuario es una

persona que juega un papel mientras se utiliza el sistema (por ejemplo, John
(usuario) es un despachador (actor)). Cada actor utiliza el sistema de diferentes
maneras (de lo contrario, debe ser el mismo actor). Pregunte acerca de los seres
humanos que van a participar, desde diferentes puntos de vista, tales como:    
 Revelador  Mantenedor  Operador  Administrador  Usuario 

La identificación de los actores de ordenador y su lugar en el Modelo de Tecnología

Pregunte acerca de los componentes que pueden intervenir, de nuevo desde diferentes
puntos de vista de la computadora. ¿Qué deben hacer?
Roles Documentar, responsabilidades Medidas de éxito, Scripts Requeridos

En la definición de los roles, hacer preguntas como:   ¿Cuáles son las

principales tareas del actor?  ¿Será que el actor tenga que leer / escribir /
modificar la información? 

  Página 288 de 670 

TOGOF 9.1    
  ¿Será que el actor tiene que informar al sistema acerca de los cambios
externos?  ¿Desea el actor para ser informado sobre cambios inesperados? 

Comprobación de Aptitud para el propósito, y el perfeccionamiento de si es

necesario

¿Hay suficiente información para identificar a quién / qué podría cumplir el

requisito? Si no es así, indagar más a fondo. ¿Hay una descripción de cuándo y con
qué frecuencia, el requisito debe ser abordado? Si no, pregunte acerca de la
sincronización.

26.8 Documentación Escenario empresarial

26.8.1 Pruebas de documentación
La documentación efectiva escenario empresarial requiere un equilibrio entre la
garantía de que el detalle es accesible, y evitando que eclipsa los resultados y
abrumar al lector. Con este fin, el documento de escenario de negocios debe tener
los principales hallazgos en el cuerpo del documento y los detalles en los
apéndices. En los apéndices:  Capture todos los detalles importantes acerca de un
escenario de negocios:  o o o o   Descripción Situación y razón  Todas las
mediciones  Todos los roles de actor y sub-mediciones  Todos los servicios
requeridos 

Capture los pasos críticos entre los actores que se ocupan de la situación, y la
secuencia de las interacciones  Declarar la información relevante acerca de todos
los actores:  o o Se reparte la responsabilidad de los actores  Lista de
condiciones previas que deben cumplirse antes del funcionamiento correcto del
sistema  Proporcionar los requisitos técnicos para que el servicio sea de calidad
aceptable 

En el cuerpo principal del escenario de negocios:  Generalizar todos los datos

relevantes de los detalles en los apéndices 

26.8.2 Modelos escenario empresarial  Recuerde que el propósito de la

utilización de modelos: 

  Página 289 de 670 

TOGOF 9.1    
o o o  Ayuda comprensión  Dar un punto de partida para confirmar los requisitos 
Relacionar los actores y las interacciones 

Mantenga dibujos clara y ordenada:  o o No ponga demasiado en un diagrama 

Diagramas más simples son más fáciles de entender 

Esquemas numéricos para una fácil referencia:  o Mantener un catálogo de los

números para evitar duplicados 

26.9 Directrices sobre Metas y Objetivos

26.9.1 Importancia de los Objetivos de
Uno de los primeros pasos en el desarrollo de una arquitectura es definir los
objetivos generales y los objetivos para el desarrollo. Los objetivos deben
derivarse de los objetivos de negocio de la organización, y la forma en que se ve a
contribuir al logro de esos objetivos. Cada organización se comporta de manera
diferente en este sentido, algunas de verlo como la fuerza motriz de la empresa y
los demás ver que en un papel de apoyo, simplemente automatizar los procesos de
negocio ya existentes. Lo esencial es que los objetivos arquitectónicos deben ser
muy estrechamente alineados con las metas y objetivos de la organización de
negocios.

26.9.2 Importancia de Objetivos SMART

No sólo deben metas sean expresados en términos generales, sino también medidas
específicas necesitan ser unidos a ellos para que sean de SMART, como se describe
anteriormente. La cantidad de esfuerzo empleado en hacer esto dará lugar a una
mayor claridad para los patrocinadores del ciclo de la evolución de la
arquitectura. Se pagará por la conducción soluciones propuestas mucho más de cerca
a los objetivos en cada etapa del ciclo. Es extremadamente útil para los diferentes
grupos de interés dentro de la organización, así como para los proveedores y
consultores, para tener un criterio claro para medir la aptitud para el propósito.
Si se hace bien, el ADM se puede utilizar para rastrear las decisiones específicas
de regreso a los criterios, por lo que no darán su justificación. Las metas de
abajo han sido adaptados de los que figuran en las versiones anteriores de TOGAF.
Estas son las categorías de objetivos, cada uno con una lista de posibles
objetivos. Cada uno de estos objetivos debe hacerse de SMART con medidas y métricas
específicas para la tarea. Sin embargo, ya que el trabajo real que hacer será
específica para el proyecto de arquitectura que se trate, no es posible
proporcionar una lista de objetivos SMART genéricos que relacionarse con cualquier
proyecto. En su lugar, ofrecemos aquí algunos ejemplos de objetivos SMART.

  Página 290 de 670 

TOGOF 9.1    
Ejemplo de hacer objetivos SMART

En el marco del objetivo general de la rúbrica "Mejorar la productividad del

usuario" a continuación, hay un objetivo de proporcionar una "interfaz de usuario
uniforme" y se describe como sigue: "Una interfaz de usuario consistente
garantizará que todas las funciones y servicios accesibles para el usuario
aparecerán y se comportan de una manera predecible similares independientemente de
la aplicación o el sitio. Esto dará lugar a una mayor eficiencia y un menor número
de errores de los usuarios, que a su vez puede resultar en menor recuperación
costos ".  Para realizar este objetivo de SMART, nos preguntamos si el objetivo es
específico, medible y aplicable, realistas y de duración determinada, y luego
aumentar el objetivo de manera apropiada. La siguiente captura de un análisis de
estos criterios para el objetivo declarado:  Específico :. El objetivo de
proporcionar "una interfaz de usuario coherente que asegure todas las funciones y
servicios accesibles para el usuario aparecerán y se comportan de una manera
predecible similares independientemente de la aplicación o el sitio" es bastante
específico. Sin embargo, las medidas que figuran en la segunda frase podría ser más
específico ...  Medible : Como se indicó anteriormente, el objetivo es medible,
pero podría ser más específico. La segunda frase podría modificarse para leer (por
ejemplo): "Esto llevará a un 10% de mayor eficiencia del usuario y de la orden de
20% menos de errores de usuario de entrada, que a su vez puede dar lugar a un 5%
más bajos costos de entrada de pedidos."  Actionable : El objetivo parece ser
procesable. Parece claro que se debe proporcionar la consistencia de la interfaz de
usuario, y que podría ser manejado por los responsables de proporcionar la interfaz
de usuario para el dispositivo del usuario.  Realista : El objetivo de proporcionar
"una interfaz de usuario coherente que asegure todas las funciones y servicios
accesibles para el usuario aparecerán y se comportan de una manera predecible
similares independientemente de la aplicación o el sitio" podría no ser realista.
Teniendo en cuenta el uso actual de la PDA al final el usuario podría llevarnos a
aumentar este objetivo de asegurar que los desarrolladores de aguas abajo no crean
indebidamente diseños que dificultan el uso de las nuevas tecnologías. El objetivo
podría ser re-declaró como "una interfaz consistente usuario, a través de
dispositivos de interfaz de usuario que proporcionan similares funcionalidades, que
se asegurará de ... ", etc  Limitado en el Tiempo : El objetivo como se ha dicho,
no es de duración determinada. Para ser de duración determinada el objetivo podría
ser re-declaró como "Al final de la Q3, proporcionar una constante ... ". 

Los resultados anteriores en un objetivo de SMART que se parece más a esto (de
nuevo recuerda que esto es un ejemplo): "Para el final de la Q3, proporcionar una
interfaz de usuario consistente a través de dispositivos de interfaz de usuario que
proporcionan una funcionalidad similar para asegurar aparecen todas las funciones y
servicios accesibles para el usuario y se comportan de una manera similar cuando se
utilizan estos dispositivos en una forma predecible independientemente de la
aplicación o el sitio. Esta dará lugar a un 10% de mayor eficiencia de los usuarios
y el 20% menos de errores de

  Página 291 de 670 

TOGOF 9.1    
usuario de entrada de pedidos, que a su vez puede dar lugar a un 5% más bajos
costos de entrada de pedidos. " 

26.9.3 Categorías de Metas y Objetivos

Aunque cada organización tendrá su propio conjunto de objetivos, algunos ejemplos
pueden ayudar en el desarrollo de una lista específica de la organización. Los
objetivos que figuran a continuación son categorías de objetivos, cada uno con una
lista de posibles objetivos, los cuales han sido adaptados a partir de los
objetivos que figuran en las versiones anteriores de TOGAF. Cada uno de los
objetivos que figuran a continuación deben hacerse de SMART con medidas y métricas
específicas para la tarea en cuestión, como se ilustra en el ejemplo anterior. Sin
embargo, el trabajo real que hacer será específica para el proyecto de arquitectura
que se trate, y no es posible proporcionar una lista de objetivos SMART genéricos
que relacionarse con cualquier proyecto.
Objetivo: Mejorar el rendimiento de procesos de negocio

Mejoras en los procesos de negocios se pueden realizar a través de los siguientes

objetivos:      Mayor rendimiento proceso  Calidad de impresión consistente 
Costes del proceso predecibles  El aumento de la reutilización de los procesos
existentes  Reducción del tiempo de envío de información comercial de un proceso a
otro proceso 

Meta: Reducir Costos

Las mejoras en costes se pueden realizar a través de los siguientes objetivos:  

 Menores niveles de redundancia y la duplicación de los activos en toda la
empresa  Disminución de la dependencia de los proveedores de servicios de TI
externos para integración y personalización  Menores costos de mantenimiento 

Objetivo: Mejorar Operaciones de Negocios

Mejoras de operaciones comerciales se pueden realizar a través de los siguientes

objetivos:    Aumento del presupuesto disponible para las nuevas características
de negocio  Reducción de costes de funcionamiento de la empresa  Disminución del
tiempo de salida al mercado para los productos o servicios 

  Página 292 de 670 

TOGOF 9.1    
  Aumento de la calidad de los servicios a los clientes  Mejora de la calidad de
la información empresarial 

Objetivo: Mejorar la Eficacia de Gestión

Mejoras de eficacia de gestión se pueden realizar a través de los siguientes

objetivos:    Mayor flexibilidad de los negocios  Menos tiempo para tomar
decisiones  Decisiones de mayor calidad 

Meta: Reducir el Riesgo

Mejoras de riesgo se pueden realizar a través de los siguientes objetivos:   

Facilidad de implementación de nuevos procesos  Errores introducidos en los
procesos de negocio a través de sistemas complejos y defectuosos Disminución 
Riesgos para la seguridad del mundo real disminuyó (incluidos los peligros que
causan la pérdida de la vida) 

Objetivo: Mejorar la Efectividad de la organización de TI

Organización de TI efectividad puede ser realizado a través de los siguientes

objetivos:      El aumento de lanzamiento de nuevos proyectos  Disminución de
tiempo a la implantación de nuevos proyectos  Menor costo en el despliegue de
nuevos proyectos  Disminución de la pérdida de continuidad de servicio cuando el
despliegue de nuevos proyectos  El desarrollo común: las aplicaciones que son
comunes a múltiples áreas de negocio serán desarrollados o adquiridos una vez y
reutilizarse en lugar de desarrollar por separado por cada área de negocio.  Los
sistemas abiertos de entorno: un entorno operativo común basado en estándares, que
da cabida a la inyección de nuevos estándares, tecnologías y aplicaciones de nivel
de toda la organización, se establecerán. Este entorno basado en estándares,
servirá de base para el desarrollo de aplicaciones comunes y facilitar la
reutilización de software.  El uso de productos: en la medida de lo posible,
independiente del hardware, elementos fuera de la plataforma deben ser utilizados
para satisfacer los requisitos con el fin de reducir la dependencia de desarrollos
a medida y para reducir los costes de desarrollo y mantenimiento. 

  Página 293 de 670 

TOGOF 9.1    
 Software reutilización: para aquellas aplicaciones que se deben desarrollar,
desarrollo de aplicaciones móviles a medida reducirá la cantidad de software
desarrollado y añadir al inventario de software adecuado para su reutilización por
otros sistemas.  Compartir recursos: los recursos de procesamiento de datos
(hardware, software y datos) será compartido por todos los usuarios que requieren
los servicios de dichos recursos. El intercambio de recursos se lleva a cabo en el
contexto de la seguridad y las consideraciones operativas. 

Objetivo: Mejorar la productividad de los usuarios

Mejoras en la productividad del usuario se pueden realizar a través de los

siguientes objetivos:  Interfaz de usuario consistente: una interfaz de usuario
consistente garantizará que todas las funciones y servicios accesibles para el
usuario aparecerán y se comportan de una manera predecible similares
independientemente de la aplicación o el sitio. Esto dará lugar a una mayor
eficiencia y un menor número de errores de los usuarios, que a su vez puede
resultar en menores costos de recuperación.  Aplicaciones integradas: las
aplicaciones disponibles para el usuario se comportará de una manera lógicamente
consistente a través de entornos de usuario, lo que conducirá a los mismos
beneficios que una interfaz de usuario consistente.  El intercambio de datos: bases
de datos se comparten a través de la organización en el contexto de la seguridad y
las consideraciones operacionales, lo que aumenta la facilidad de acceso a los
datos requeridos. 

Objetivo: mejorar la portabilidad y escalabilidad

La portabilidad y escalabilidad de las aplicaciones será a través de los siguientes

objetivos:  Portabilidad: aplicaciones que se adhieren a los estándares abiertos
de sistemas serán portables, lo que aumenta la facilidad de movimiento-a través de
plataformas informáticas heterogéneas. Aplicaciones portátiles pueden permitir que
los sitios para actualizar sus plataformas conforme tengan lugar mejoras
tecnológicas, con un impacto mínimo en las operaciones.  Escalabilidad: las
aplicaciones que se ajustan al modelo será configurable, lo que permite el
funcionamiento en todo el espectro de plataformas requeridas. 

Objetivo: Mejorar la interoperabilidad

Mejoras de interoperabilidad entre aplicaciones y áreas de negocio se pueden

realizar a través de los siguientes objetivos:  Infraestructura común: la
arquitectura debe promover una infraestructura de comunicaciones y computación
basados en sistemas abiertos y sistemas de transparencia, incluyendo, pero no
limitado a, sistemas operativos, administración de bases de datos, intercambio de
datos, servicios de red, gestión de redes e interfaces de usuario. 

  Página 294 de 670 

TOGOF 9.1    
 Normalización: mediante la implementación de las plataformas basadas en
estándares, las aplicaciones se le proporcionará y será capaz de utilizar un
conjunto común de servicios que mejoren las oportunidades de interoperabilidad. 

Objetivo: Aumentar el proveedor de la Independencia

La independencia del proveedor se incrementará a través de los siguientes

objetivos:  Componentes intercambiables: sólo el hardware y el software que tiene
las interfaces basadas en estándares se seleccionarán, por lo que las
actualizaciones o la inserción de nuevos productos darán lugar a una interrupción
mínima en el entorno del usuario.  Especificaciones no propietarias: capacidades se
definen en términos de especificaciones no propietarias que soportan una
competencia plena y abierta, y están a disposición de cualquier fabricante para su
uso en el desarrollo de productos comerciales. 

Meta: Reducir los costos de ciclo de vida

Los costos de ciclo de vida se puede reducir a través de la mayor parte de los
objetivos mencionados anteriormente. Además, los siguientes objetivos se refieren
directamente a la reducción de los costes del ciclo de vida:  Reducción de la
duplicación: la sustitución de los sistemas y las islas de automatización con
sistemas abiertos interconectados aislados conducirá a la reducción de la
funcionalidad de superposición, duplicación de datos y la redundancia innecesaria
porque los sistemas abiertos pueden compartir datos y otros recursos.  Los costos
de mantenimiento de software Reducido: reducciones en la cantidad y variedad de
software utilizado en la organización dará lugar a reducciones en la cantidad y el
costo de mantenimiento del software. El uso de software estándar off-the-shelf
conducirá a nuevas reducciones de costes, ya que los proveedores de este tipo de
software distribuyen sus costos de mantenimiento del producto a través de una base
de usuarios mucho mayor.  Sustitución incremental: interfaces comunes a los
componentes de infraestructura compartida permite la sustitución gradual o
actualizar con una perturbación operativa mínima.  Reducción de costos de
formación, con sistemas comunes y compatibles Interfaces Hombre-Computadora (HCI)
conducirán a la reducción de los costes de formación. 

Objetivo: Mejorar la Seguridad

La seguridad puede ser mejorada en la información de la organización a través de

los siguientes objetivos:  Interfaces de seguridad consistentes para aplicaciones:
las interfaces de seguridad consistentes y procedimientos dará lugar a un menor
número de errores en el desarrollo de aplicaciones y la portabilidad de
aplicaciones aumentado. No todas las aplicaciones tienen el mismo conjunto de
características de seguridad, pero las características utilizadas serán
consistentes en todas las aplicaciones. 

  Página 295 de 670 

TOGOF 9.1    
 Interfaces de seguridad consistentes para los usuarios: una interfaz de usuario
común a las características de seguridad dará lugar a una reducción del tiempo de
aprendizaje cuando se pasa de un sistema a otro.  Independencia de Seguridad: la
implementación de aplicaciones pueden utilizar la política de seguridad y los
mecanismos apropiados para el entorno en particular si hay una buena
estratificación en la arquitectura.  Una reducción del 25% en las llamadas a la
mesa de ayuda en relación con las cuestiones de seguridad.  Una reducción del 20%
en los "falsos positivos" detectados en la red (un falso positivo es un evento que
parece ser un evento de seguridad procesable, pero en realidad es una falsa
alarma). 

 

Objetivo: Mejorar la capacidad de administración

Mejora de la gestión se puede realizar a través de los siguientes objetivos: 

Consistente interfaz de gestión: las prácticas y procedimientos de gestión
coherentes facilitarán la gestión a través de todas las aplicaciones y sus
estructuras de soporte subyacentes. Una interfaz consistente puede simplificar la
tarea de gestión, lo que aumenta la eficiencia del usuario.  El servicio reducido,
administración y mantenimiento de los costos: el funcionamiento, la administración
y los costos de mantenimiento se pueden reducir a través de la disponibilidad de
productos mejorados de gestión y una mayor estandarización de los objetos que se
manejan. 


26.10 Resumen
Escenarios empresariales ayudan a abordar uno de los problemas más comunes que
enfrentan los ejecutivos de TI: la alineación de TI con el negocio. El éxito de
cualquier gran proyecto de TI se mide por el grado en que se vincula a los
requerimientos del negocio, y se puede demostrar apoya y permite a la empresa a
alcanzar sus objetivos de negocio. Escenarios de negocios son una técnica
importante que puede ser utilizado en diversas etapas de la definición de
arquitectura de la empresa, o de cualquier otro gran proyecto de TI, para deducir
las características de la arquitectura directamente de los requisitos de alto nivel
de la empresa. Escenarios de negocio se utilizan para ayudar a identificar y
entender las necesidades del negocio, y por lo tanto para derivar los
requerimientos de negocio que el desarrollo de la arquitectura, y en última
instancia, la tecnología informática, ha de abordar. Sin embargo, es importante
recordar que los escenarios de negocios son sólo una herramienta, no el objetivo.
Son una parte de, y permiten, el proceso más amplio de desarrollo de la
arquitectura. El arquitecto debe usarlos, pero no perderse en ellos. La clave es
mantener la concentración cuidado con los "invasión de características", y abordar
los temas más importantes que tienden a devolver el valor más grande.

  Página 296 de 670 

TOGOF 9.1       

27. Análisis Gap

La técnica conocida como análisis de brechas se utiliza ampliamente en el TOGAF
Arquitectura Método de Desarrollo (ADM) para validar una arquitectura que se está
desarrollando. La premisa básica es poner de relieve un déficit entre la
arquitectura de línea de base y de la arquitectura de destino; es decir, los
elementos que se han omitido deliberadamente, accidentalmente dejados de lado, o
aún no definidas.

27.1 Introducción
Un paso clave en la validación de una arquitectura es considerar lo que pudo haber
sido olvidado. La arquitectura debe ser compatible con todas las necesidades de
procesamiento de la información esenciales de la organización. La fuente más
importante de las brechas que se deben considerar es preocupaciones de los
interesados que no han sido abordados en la obra arquitectónica previa. Las fuentes
potenciales de lagunas incluyen:  Lagunas de dominio de negocios:  o o o Gente
lagunas (por ejemplo, los requisitos de entrenamiento cruzado)  Lagunas de proceso
(por ejemplo, las ineficiencias del proceso)  Herramientas lagunas (por ejemplo,
duplicar o falta de funcionalidad de la herramienta)  Los vacíos de información 
Lagunas de medición  Brechas financieras  Instalaciones lagunas (edificios,
oficinas, etc) 

o o o o 

Lagunas de dominio de datos:  o o o o o o o Datos no de moneda suficiente  Los

datos que no se encuentren donde se necesita  No los datos que se necesita  Datos
no disponibles cuando se necesiten  Los datos no se ha creado  Los datos no se
consume  Lagunas relación de datos 

  Página 297 de 670 

TOGOF 9.1    
  Aplicaciones afectados, eliminados, o creados  Tecnologías afectados,
eliminados, o creados 
27.2 Pasos sugeridos
Los pasos sugeridos son los siguientes:  Elaborar una matriz con todos los
Arquitectura Bloques de Construcción (Abs) de la Arquitectura de referencia en el
eje vertical, y todo el ABBS de la arquitectura seleccionada en el eje horizontal. 
Añadir a la Arquitectura de referencia eje A última fila con la etiqueta "Nuevo", y
al eje de Arquitectura Target una última columna etiquetada "Eliminado".  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
referencia no se encuentra en la arquitectura destino, cada uno debe ser revisado.
Si se elimina correctamente, lo marca como tal en el apropiado "Eliminado" célula.
Si no lo fuera, una omisión accidental en la Arquitectura objetivo se ha
descubierto que debe abordarse mediante el restablecimiento de la ABB en la próxima
iteración del diseño de la arquitectura - marcarlo como tal en el apropiado
"Eliminado" célula.  Cuando un ABB de la Arquitectura objetivo no se puede
encontrar en la arquitectura de referencia, marcarlo en la intersección con la
línea "Nuevo", como una brecha que hay que cubrir, ya sea mediante el desarrollo o
adquisición de la piedra angular. 

  

Cuando el ejercicio se ha completado, cualquier cosa bajo "Eliminado" o "Nuevo" es

una brecha, que debería o bien ser explicado como correctamente eliminado o marcado
como ser abordado mediante el restablecimiento o el desarrollo / adquisición de la
función.

27.3 Ejemplo
La Figura 27-1 muestra un ejemplo de análisis de ABBS que son los servicios de la
categoría de servicios de red del modelo de referencia técnica (TRM), y muestra una
serie de servicios a partir de la arquitectura de referencia que faltan de la
arquitectura destino.

  Página 298 de 670 

TOGOF 9.1    

  Figura 27‐1: Ejemplo de análisis de carencias    

  Página 299 de 670 

TOGOF 9.1       

28. Técnicas de Planificación Migración

Este capítulo contiene una serie de técnicas que se utilizan para apoyar la
planificación de la migración en las fases E y F.

Evaluación Factor 28.1 Implementación & Matrix Deducción

La técnica de creación de una evaluación de la instrumentación Factor y la matriz
de deducción se puede utilizar para documentar los factores que afectan la
implementación de la arquitectura y el Plan de Migración. La matriz debe incluir
una lista de los factores a tener en cuenta, sus descripciones, y las deducciones
que indican las acciones o las limitaciones que deben ser tenidas en cuenta a la
hora de formular los planes. Los factores incluyen típicamente:      
Riesgos  Cuestiones  Supuestos  Dependencias  Acciones  Impactos 
Una matriz de ejemplo se muestra en la Figura 28-1 .

  Figura 28‐1: Evaluación Factor Implementación y Matrix Deducción 

  Página 300 de 670 

TOGOF 9.1    

   28.2 Las lagunas consolidados, soluciones, y Matrix Dependencias

La técnica de creación de unas lagunas consolidados, soluciones, y la matriz de
dependencias permite al arquitecto grupo de las lagunas identificadas en la
arquitectura de dominio resultados de análisis de carencias y evaluar las posibles
soluciones y las dependencias a uno o más espacios. Esta matriz se puede utilizar
como una herramienta de planificación cuando la creación de paquetes de trabajo.
Las dependencias identificadas impulsarán la creación de proyectos y planificación
de la migración en las fases E y F. Una matriz de ejemplo se muestra en la Figura
28-2 .

  Figura 28‐2: Consolidado Gaps, soluciones y Matrix Dependencias 

28.3 Arquitectura Definición Incrementos Tabla

La técnica de creación de una tabla de incrementos de definición de la arquitectura
permite al arquitecto para planear una serie de Transición Arquitecturas esbozar el
estado de la arquitectura de la empresa en los momentos especificados. Una tabla
debe elaborarse, como se muestra en la Figura 28-3 , que enumera los proyectos y la
asignación de sus entregas incrementales a través de las arquitecturas de
transición.

  Figura 28‐3: Incrementos de Arquitectura definición de la tabla   
Página 301 de 670 

TOGOF 9.1    

   28.4 Transición Arquitectura Estado Tabla de la Evolución

La técnica de creación de la tabla de transición Architecture Evolution Estado
permite que el arquitecto que muestra el estado de las arquitecturas propuestas en
varios niveles utilizando el Modelo de Referencia Técnica (TRM). Una tabla debe ser
dibujada, una lista de los servicios de la TRM se utiliza en la empresa, las
arquitecturas de transición, y las transformaciones propuso, como se muestra en la
Figura 28-4 . Todos los bloques de construcción de la solución (SBB) deben ser
descritos con respecto a su entrega y el impacto en estos servicios. También deben
estar marcados para mostrar el progreso de la arquitectura empresarial. En el
ejemplo, donde se ha alcanzado la capacidad objetivo, esto se muestra como "nuevos"
o "retener"; donde la capacidad es la transición a una nueva solución, esta se
marca como "de transición"; y donde una capacidad va a ser reemplazado, esta se
marca como "sustituir".

  Figura 28‐4: Arquitectura de transición de estados Tabla Evolution 
Otra técnica (no mostrado aquí) es el uso de la codificación de color en la matriz;
por ejemplo:    Verde: Servicio de SBB en su lugar (ya sea nuevo o retenido). 
Amarillo: Servicio realiza la migración a una nueva solución.  Rojo: Servicio a
sustituir. 

                  Página 302 de 670 

TOGOF 9.1        
28.5 Evaluación del Valor de Negocio Técnica
Una técnica para evaluar el valor del negocio es la elaboración de una matriz
basada en una dimensión índice de valor y una dimensión de índice de riesgo. Un
ejemplo se muestra en la Figura 28-5 . El índice de valor debe 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 debería
incluir criterios tales como el tamaño y la complejidad, la tecnología, la
capacidad de organización, y el impacto de un fracaso. A cada criterio se le debe
asignar un peso individual. El índice y sus criterios y ponderación deben ser
elaborados y aprobados por la alta dirección. Es importante establecer los
criterios para la toma de decisiones antes de conocer las opciones.

 
Figura 28‐5: Ejemplo de Evaluación de Proyectos con respecto a los negocios de valo
r y de Riesgo 

  Página 303 de 670 

TOGOF 9.1       

29. Requisitos de interoperabilidad

Este capítulo proporciona directrices para la definición y el establecimiento de
requisitos de interoperabilidad.

29.1 Información general

Una definición de la interoperabilidad es "la capacidad de compartir información y
servicios". Definir el grado en que la información y los servicios han de ser
compartidos es un requisito arquitectónico de gran utilidad, sobre todo en una
organización compleja y / o de la empresa extendida. La determinación de la
interoperabilidad está presente en todo el Método de desarrollo de la arquitectura
(ADM) de la siguiente manera:  En el Architecture Vision (Fase A), la naturaleza y
las consideraciones de seguridad de los intercambios de información y de servicios
se reveló por primera vez dentro de los escenarios de negocio.  En la arquitectura
de negocios (Fase B), los intercambios de información y de servicios se definen más
en términos de negocio.  En la arquitectura de datos (fase C), el contenido de los
intercambios de información se detallan el uso de los datos de la empresa y / o
modelo de intercambio de información.  En se especifica la arquitectura de la
aplicación (fase C), la forma en que las distintas aplicaciones son para compartir
la información y los servicios.  En la arquitectura de la tecnología (Fase D), se
especifican los mecanismos técnicos adecuados que permitan el intercambio de
información y servicios.  En Oportunidades y Soluciones (Fase E), se seleccionan
las soluciones reales (por ejemplo, paquetes de Commercial Off-The-Shelf (COTS)). 
En planeamiento de migración (Fase V), la interoperabilidad es implementado con
lógica. 

     

29.2 Definición de Interoperabilidad

Hay muchas maneras de definir la interoperabilidad y el objetivo es definir una que
se aplicará de manera uniforme dentro de la empresa y de la empresa extendida. Lo
mejor es que tanto la empresa y la empresa extendida usan las mismas definiciones.
Muchas organizaciones consideran que es útil para categorizar la interoperabilidad
de la siguiente manera:   Operacional o de negocios Interoperabilidad define cómo
los procesos de negocio han de ser compartidos.  Información sobre
interoperabilidad define cómo es la información para ser compartida. 
  Página 304 de 670 

TOGOF 9.1    
 Interoperabilidad Técnica define cómo los servicios técnicos han de ser
compartidos o al menos conectar entre sí. 

Desde una perspectiva de TI, sino que también es útil tener en cuenta la
interoperabilidad en una línea similar a la Integración de Aplicaciones
Empresariales (EAI);específicamente:  Presentación de integración /
interoperabilidad es que un enfoque común look-and-feel través de una solución de
portal común guía al usuario a la funcionalidad subyacente del conjunto de
sistemas.  Integración de la Información / Interoperabilidad es donde la
información corporativa está perfectamente compartida entre las distintas
aplicaciones de la empresa para lograr, por ejemplo, un conjunto común de
información del cliente. Normalmente, esto se basa en una ontología corporativa
comúnmente aceptado y servicios compartidos para la estructura, la calidad, el
acceso y la seguridad / privacidad de la información.  Integración de
Aplicaciones / Interoperabilidad es donde la funcionalidad corporativa está
integrada y compartida de modo que las aplicaciones no están duplicados (por
ejemplo, un cambio de servicio de dirección / componente; no una para cada
aplicación) y están perfectamente conectados entre sí a través de la funcionalidad
como el flujo de trabajo. Esto afecta a las aplicaciones de negocio y de
infraestructura, y está muy estrechamente vinculados a las empresas de procesos de
negocio unificación / la interoperabilidad.  Técnica de integración /
interoperabilidad incluye métodos comunes y servicios compartidos para la
comunicación, el almacenamiento, el procesamiento y el acceso a los datos sobre
todo en la plataforma de aplicaciones y dominios de la infraestructura de
comunicaciones. Esta interoperabilidad se basa en el grado de racionalización de la
infraestructura de TI de la empresa, sobre la base de normas y / o plataformas
comunes. Por ejemplo, varias aplicaciones compartiendo una infraestructura o 10.000
sitios web corporativos mediante uno de gestión de contenidos / servidor web
centralizado (en lugar de miles de servidores y webmasters extienden por todo el
país / mundo). 

Muchas organizaciones crean sus propios modelos de interoperabilidad, como se

ilustra en el siguiente ejemplo del Gobierno de Canadá. Tienen una definición de
alto nivel de las tres clases de interoperabilidad e identificar la naturaleza de
la información y servicios que desean compartir. La interoperabilidad se acuñó en
términos de los facilitadores electrónicos para la eAdministración. Su desglose
interoperabilidad es el siguiente:  Información sobre interoperabilidad:  o o o o
 Gestión del conocimiento  La inteligencia empresarial  Gestión de la información 
Identidad de confianza 

Interoperabilidad del comercio:  o Redes de entrega 

  Página 305 de 670 

TOGOF 9.1    
o o o o  e-Democracia  e-Business  Gestión de recursos empresariales  Gestión de
las relaciones y el caso 
Interoperabilidad Técnica:  o Infraestructura de TI 

En ciertos enfoques arquitectónicos, tales como sistema de sistemas o un modelo

federado, la interoperabilidad es una práctica muy recomendable que va a determinar
cómo los sistemas interactúan entre sí. Una consideración clave será el modelo
operativo de negocio de la empresa.

29.3 Empresa Modelo Operativo

La clave para el establecimiento de la interoperabilidad es la determinación del
modelo de funcionamiento empresarial, donde el modelo de funcionamiento es "el
nivel necesario de la integración de procesos de negocio y la normalización para la
entrega de los bienes y servicios a los clientes. Un modelo operativo se describe
cómo una empresa quiere prosperar y crecer. Por proporcionando una visión más
estable y procesable de la empresa de estrategia, el modelo operativo impulsa el
diseño de la base para su ejecución. " 1 Por ejemplo, si las líneas de unidades de
negocio o comerciales sólo necesitan compartir documentos, la Arquitectura y
Soluciones Building Blocks (ABBS y SBB) puede ser más sencillo que si hay una
necesidad de compartir datos de transacciones estructuradas. Del mismo modo, si el
Architecture Vision incluye un entorno de servicios compartidos, entonces es útil
para definir el nivel de los servicios que se van a compartir. El modelo de
funcionamiento empresarial normalmente indica qué tipo de enfoque de
interoperabilidad será apropiado. Este modelo debe ser determinado en la Fase A
(Architecture Vision) si no está en la Fase B (Arquitectura de negocios), y,
definitivamente, por la Fase E (Oportunidades y Soluciones). Empresas complejas y /
o las empresas extendidas (por ejemplo, la cadena de suministro) pueden tener más
de un tipo de modelo de funcionamiento. Por ejemplo, es común para el modelo de
funcionamiento interno (y apoyar modelo de interoperabilidad) a diferir de la
utilizada para la empresa extendida.

29.4 Interoperabilidad Refinación

La implementación de la interoperabilidad requiere de la creación, la gestión, la
aceptación y cumplimiento de las normas realistas que sean SMART (específicos,
mensurables, acciones concretas, realistas y de duración determinada). Medidas
claras de interoperabilidad son clave para el éxito. La arquitectura es la clave
para la identificación de las normas y sesiones facilitadas (lluvia de ideas),
examinará posibles formas pragmáticas (que caben dentro de la cultura empresarial
actual o emergente) para alcanzar el grado requerido de interoperabilidad.

  Página 306 de 670 

TOGOF 9.1    
La interoperabilidad debe ser refinado para que cumpla con las necesidades de la
empresa y / o empresa extendida de una manera inequívoca. Las medidas de
interoperabilidad refinados (grados, tipos y objetivos de alto nivel) deben ser
parte de o remitirse a la dirección estratégica de la arquitectura empresarial.
Estas medidas se crean instancias dentro de una estrategia de transformación que
deben ser incrustado dentro de la definición de la arquitectura de destino y
pragmáticamente a cabo en el Arquitecturas Transición. Al finalizar, también
actualizar los resultados del análisis de brecha consolidados y dependencias para
asegurarse de que todas las pepitas de brainstorming son capturados. Un ejemplo de
la especificación de interoperabilidad es el grado de interoperabilidad (utilizados
en el Departamento de la Defensa Nacional y la OTAN canadiense). Estas
organizaciones se han centrado en el intercambio de información y se acercó con
cuatro grados de interoperabilidad de la siguiente manera:  Grado 1: No
estructurado de intercambio de datos implica el intercambio de datos no
estructurados-humanos interpretable, como el texto libre que se encuentra en las
estimaciones operacionales, análisis y documentos.  Grado 2: Structured Data
Exchange implica el intercambio de datos estructuradoshumanos interpretable
destinados manual y / o tratamiento automatizado, pero requiere de la compilación
manual, la recepción y / o envío de mensajes.  Grado 3: Distribución transparente
de datos implica el intercambio automático de datos entre los sistemas basados en
un modelo de intercambio común.  Grado 4: Distribución transparente de la
Información es una extensión de grado 3 a la interpretación universal de la
información a través del procesamiento de datos basada en aplicaciones de co-
operación. 

 

Estos títulos deben ser perfeccionado y hecho técnicamente significativo para cada
uno de los grados. Un ejemplo refinamiento de grado 3 con cuatro subclasificaciones
sigue:     3A: Formal de mensajes de Exchange  3B: Intercambio de datos
comunes  3C: Completa el intercambio de datos  3D: en tiempo real de intercambio de
datos 

El propósito es especificar los grados detallados de interoperabilidad al nivel

requerido de detalle de manera que sean técnicamente significativa. Estos grados
son muy útiles para especificar la forma en que la información debe ser
intercambiada entre los distintos sistemas y proporcionar orientación crítica a los
proyectos de ejecución de los sistemas. Medidas similares se deben establecer para
determinar el servicio / negocio y la interoperabilidad técnica.

  Página 307 de 670 

TOGOF 9.1    

29.5 Determinación de los requisitos de interoperabilidad

La coexistencia entre los países emergentes y los sistemas existentes, sobre todo
durante la transformación, será un gran desafío y de intercambio de ideas debe
tratar de averiguar lo que hay que hacer para reducir el dolor. Es imperativo
involucrar al personal y los arquitectos de gestión de las operaciones en este
paso, ya que será responsable de la operación de los entregables de la cartera. Por
ejemplo, puede haber una necesidad de una aplicación de "contenedor" (una
aplicación que actúa como interfaz [intérprete alias] entre el uso de la herencia y
de la infraestructura emergente). De hecho, pragmáticamente, en el "si funciona, no
lo arregles" mundo, el "envoltorio" podría llegar a ser una solución permanente. En
cualquier caso, el uso de los resultados de análisis de carencias y escenarios de
negocio como una fundación, una lluvia de ideas de los problemas de TI y trabajar a
través de ellos para asegurarse de que todas las respuestas estén claramente
identificadas y tratadas y verificar que se cumplan los requisitos específicos de
la organización. Es importante señalar que el proceso de desarrollo posterior debe
incluir el reconocimiento de las dependencias y los límites de las funciones y debe
tener en cuenta qué productos están disponibles en el mercado. Un ejemplo de cómo
esto puede ser expresado se puede ver en el ejemplo de bloques de construcción
(véase la Parte III , 37.Building Blocks ). Si se utiliza un mecanismo como los
grados de interoperabilidad, a continuación, una matriz que muestra los requisitos
de interoperabilidad es una herramienta útil, como se ilustra en la Figura 291 y
Figura 29-2 , y señaló que el grado de intercambio de información no es
necesariamente simétrica o bidireccional entre los sistemas y / o grupos de
interés. La siguiente matriz se puede utilizar dentro de la empresa y / o dentro de
la empresa extendida como una forma de detallar que la información y / o servicios
pueden ser compartidos. La matriz debe comenzar en la Arquitectura de Negocios
(Fase B) para capturar la naturaleza del intercambio de información entre las
partes interesadas, y evolucionar para determinar la cuota de lo que los sistemas
de información que en la Fase C.

  Figura 29‐1: Business Information Matriz de interoperabilidad 

  Página 308 de 670 

TOGOF 9.1    
La figura 29-1 muestra que los grupos de interés requiere un intercambio
estructurado de datos (nivel 2) con los interesados / Sistemas B y D, y el
intercambio fluido de datos (grado 3) con las partes interesadas / Sistemas C, E, F
y G. La matriz de interoperabilidad de la información del negocio debe ser refinado
dentro de la arquitectura de sistemas de información utilizando medidas refinados y
especificando los sistemas actuales utilizados por los grupos de interés. Un
ejemplo se muestra en la Figura 29-2 .

  Figura 29‐2: Sistemas de Información Matriz de interoperabilidad 
En la Figura 29-2 , tanto la naturaleza del cambio es más detallada (por ejemplo,
Grado 3A frente único grado 3) y el intercambio entre los sistemas específicos en
lugar de las partes interesadas. Por ejemplo, la información de las acciones del
Sistema de A con los demás sistemas de conformidad con las normas técnicas de la
empresa. En muchas organizaciones las arquitecturas empresariales describen la
naturaleza de la información compartida entre las partes interesadas y / u
organizaciones (por ejemplo, en defensa del término es "nodo operativo"), y la
arquitectura de datos especifica la información que se comparte entre los sistemas.
Actualizar los datos de destino definido y Arquitectura de la aplicación (versión
1.0) con los problemas de interoperabilidad que se plantearon.

29.6 Requisitos de Conciliación de interoperabilidad con las soluciones potenciales

El arquitecto de la empresa tendrá que asegurarse de que no hay conflictos de
interoperabilidad, sobre todo si existe la intención de reutilizar SBB y / o cunas
existentes. La cuestión más importante a abordar es, de hecho, la interoperabilidad
empresarial. La mayoría de SBB o COTS tendrán sus propios procesos empresariales
incrustados.El cambio de los procesos de negocio integrados menudo requerirá mucho
trabajo, que se perderán las ventajas de las soluciones de reutilización de. Hay
numerosos ejemplos de esto en el pasado. Además, no es el aspecto de flujo de
trabajo entre los diversos sistemas que tiene que ser tomada en cuenta. El
arquitecto de la empresa tendrá que asegurarse de que cualquier cambio en los

  Página 309 de 670 

TOGOF 9.1    
requisitos de interoperabilidad de negocios está firmado por los arquitectos
comerciales y patrocinadores de arquitectura en una declaración revisada de
Arquitectura Obra.

29.7 Resumen
Definición de interoperabilidad de forma clara e inequívoca en varios niveles
(negocio / servicio, la información, y técnicos) es una herramienta de
planificación de la arquitectura de utilidad. Las nociones de interoperabilidad
serán cada vez más importante en la arquitectura orientada a servicios (SOA), donde
los servicios serán compartidos internamente y externamente en las empresas cada
vez más interdependientes extendidas.

  

  Página 310 de 670 
TOGOF 9.1       

30. Evaluación de la preparación de transformación de negocios

En este capítulo se describe una técnica conocida como Evaluación de la preparación
de transformación de negocios, que se utiliza para evaluar y cuantificar la
disposición de una organización a sufrir modificaciones. En este capítulo se basa
en el trabajo por la de su Programa de capacitación de la transformación del
negocio (BTEP) Gobierno Canadiense y. 1

30.1 Introducción
Arquitectura empresarial es una tarea importante dentro de una organización y la
mayoría de las veces un innovador Architecture Vision (Fase A) y apoyando
Definición Arquitectura (Fases B a D) supondrá un cambio considerable. Hay muchas
dimensiones de cambiar, pero con mucho, el más importante es el elemento humano.
Por ejemplo, si la empresa prevé una consolidación de las explotaciones de la
información y el paso a un nuevo paradigma como la orientación de servicios para la
prestación de servicios integrados, entonces las consecuencias para los recursos
humanos son importantes. Potencialmente, junto con una cultura de cambio adverso y
una fuerza de trabajo por poco calificada, la arquitectura más sólida y innovador
podría ir a ninguna parte. 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 en
la Implementación y planes de migración es clave para la transformación lograda
arquitectura en las fases E y F. Este será un esfuerzo conjunto entre las empresas
(especialmente los recursos humanos) personal, líneas de negocio, y los
planificadores de TI. Las actividades recomendadas en una evaluación de la
preparación de la organización para hacer frente a la transformación del negocio
son:      Determinar los factores de preparación que tendrán impacto en la
organización  Presentar los factores de preparación para el uso de modelos de
madurez  Evaluar los factores de preparación, incluida la determinación de las
calificaciones de los factores de preparación  Evaluar los riesgos para cada factor
de preparación e identificar acciones de mejora para mitigar el riesgo  El trabajo
de estas acciones en la Fase E y F Implementación y Plan de Migración 

30.1.1 Programa de capacitación de la transformación del negocio (BTEP)

El Programa de capacitación de la transformación del negocio Gobierno canadiense
(BTEP) se proporciona orientación sobre la manera de identificar las cuestiones
relacionadas con la transformación de los negocios.

  Página 311 de 670 

TOGOF 9.1    
El BTEP recomienda que todos los proyectos llevan a cabo una evaluación de la
preparación de transformación, al menos, descubrir los problemas de transformación
empresarial. Esta evaluación se basa en la determinación y el análisis /
calificación de una serie de factores de preparación. El resultado es una mayor
comprensión de los desafíos y oportunidades que se podrían presentar en el
transcurso de la tarea. Muchos de los desafíos que se traducen directamente en los
riesgos que tienen que ser abordados, supervisado, y, si es posible, mitigados. Las
siguientes secciones describen Evaluación de la preparación de transformación de
negocios usando el método BTEP, incluyendo algunas de las lecciones aprendidas.Los
lectores deben tener en cuenta que la mayoría de las organizaciones tienen su
propio conjunto único de factores y criterios, pero la mayoría son similares.

30.2 Determinar los factores de Preparación

El primer paso es determinar qué factores tendrán un impacto en la transformación
de los negocios asociados a la migración desde la línea de base a Target
Arquitecturas. Esto puede lograrse mejor a través de la realización de un taller
dirigido a personas de diferentes partes de la organización. Es importante que
todas las perspectivas son buscados como se variarán los temas. En este taller, es
muy útil empezar con una lista tentativa de los factores que los participantes
puedan reutilizar, rechazar, aumentar o reemplazar. Un ejemplo conjunto de factores
extraídos de la BTEP sigue:  Visión es la capacidad de definir y comunicar lo que
se quiere lograr con claridad. Aquí es donde la gestión es capaz de definir con
claridad los objetivos, tanto en términos estratégicos y específicos. El liderazgo
en la definición de la visión y necesidades proviene de la parte comercial de IT de
entrada. Existen procesos predecibles y probadas para pasar de la visión a la
exposición de las necesidades. Los principales impulsores de la iniciativa son
claros. El alcance y el enfoque de la iniciativa de transformación se han definido
claramente en toda la organización.  Deseo, Voluntad, y resolver es la presencia de
un deseo de alcanzar los resultados, la disposición a aceptar el impacto de hacer
el trabajo, y la decisión de seguir adelante y completar la tarea. Hay una
discusión activa sobre el impacto que la ejecución del proyecto pueda tener en la
organización, con indicación clara de la intención de aceptar las consecuencias.
Recursos clave (por ejemplo, financieros, humanos, etc) se asignan para el esfuerzo
y los altos ejecutivos proyectar el mensaje claro de que la organización va a
seguir adelante; un mensaje que identifica el esfuerzo, así como los beneficios.
Vista organizativo hay antecedentes de terminar lo que está en marcha y de llegar a
un cierre en temas en los plazos necesarios y hay un consenso en toda la
organización que la iniciativa de transformación es la cosa "correcta" de hacer. 
Necesita , en que hay una necesidad imperiosa de ejecutar la tarea. Hay
declaraciones claras en cuanto a lo que la organización no va a ser capaz de hacer
si el proyecto no avanza, y las declaraciones igualmente claras de lo que el
proyecto permitirá a la organización a hacer. Hay consecuencias visibles y
ampliamente entendido de criterios de fallo esfuerzo y éxito han sido claramente
identificada y comunicada.  Caso de Negocio existe eso crea un fuerte enfoque en el
proyecto, la identificación de los beneficios que se deben alcanzar y creando con
ello un imperativo para tener éxito. El documento de modelo de negocio identifica
beneficios concretos (ingresos o ahorros) que

  Página 312 de 670 

TOGOF 9.1    
la organización se compromete a entregar y con claridad y, sin duda, los puntos a
los objetivos que la organización se ha comprometido a lograr.    La financiación
, en forma de una clara fuente de recursos fiscales, existe que cumple una
inversión potencial del emprendimiento.  Patrocinio y Liderazgo existe y es
ampliamente compartido, pero no tan amplio como para difundir la rendición de
cuentas. Liderazgo mantiene a todos "a bordo" y mantiene todas ellas centradas en
los objetivos estratégicos. El esfuerzo es patrocinado por un ejecutivo que está
alineado adecuadamente para proporcionar el liderazgo de las necesidades empeño y
capaz de articular y defender las necesidades de la empresa a nivel de la alta
dirección. Estos patrocinadores ejecutivos son y seguirán siendo participar en
todo.  Gobernabilidad es la capacidad de involucrar a la participación y el apoyo
de todas las partes con un interés o responsabilidad de la empresa con el objetivo
de garantizar que se sirven a los intereses corporativos y los objetivos
alcanzados. Es evidente que hay grupos de interés identificados y un sentido claro
de su interés y responsabilidad con el proyecto; una cultura que fomenta la
participación hacia objetivos corporativos en lugar de locales; una historia de ser
capaces de gestionar con éxito las actividades que cruzan áreas de interés; una
cultura que fomenta significativa, en comparación con simbólica, la participación
en los procesos de gestión; y un compromiso de constante revisión y desafío y la
apertura a asesoramiento externo del proyecto.  Responsabilidad es la asignación de
responsabilidades específicas y apropiadas, el reconocimiento de las expectativas
medibles por todas las partes interesadas, y la alineación de la toma de decisiones
con áreas de responsabilidad y con el lugar donde se sentirá el impacto de las
decisiones. Rendición de cuentas está alineada con la zona en la que se harán
sentir los beneficios del éxito o consecuencias del fracaso del esfuerzo, así como
con las áreas de responsabilidad.  Enfoque y Ejecución Modelo realizable es un
enfoque que tiene sentido en relación con la tarea, con un ambiente de apoyo, el
modelo de un método de probada eficacia. Hay nociones claras del cliente y del
cliente papel en relación con el constructor o contratista principal y la
organización tiene experiencia con los esfuerzos de este tipo para que los
procesos, las disciplinas, los conocimientos y la gobernabilidad ya están en
marcha, probado y disponible para aplicar para el esfuerzo de transformación. Todos
los jugadores saben su papel porque los han jugado antes con éxito. En particular,
las funciones de "cliente" y "constructor de sistemas" son maduros y estables. Hay
un plan de comunicación que cubren todos los niveles de la organización y la
satisfacción de las necesidades que van desde la conciencia de la disponibilidad de
los detalles técnicos. Hay una recompensa y el plan de reconocimiento en lugar de
reconocer los equipos y los individuos que utilizan buenas prácticas de gestión del
cambio, la planificación y la prevención de conductas de crisis, y que reforzar las
conductas apropiadas para la nueva forma de hacer negocios. Es claro para todos
cómo se producirá la aplicación, cómo va a ser monitoreada, y cómo las acciones
reajuste se hará y hay suficientes recursos dedicados a la vida de la
transformación.  Capacidad de TI para ejecutar es la capacidad de realizar todas
las tareas de TI que requiere el proyecto, incluyendo las habilidades,
herramientas, procesos y capacidad de gestión. Ha habido una reciente ejecución
exitosa de un esfuerzo similar de tamaño y complejidad similar y existen procesos
adecuados, la disciplina, las habilidades, y un modelo justificación para decidir
qué habilidades y actividades a la fuente externa. 

  Página 313 de 670 

TOGOF 9.1    
 Empresa capacidad de ejecución es la capacidad de la empresa para llevar a cabo
todas las tareas requeridas por la empresa, en áreas fuera de las TI, incluyendo la
capacidad de tomar decisiones dentro de las limitaciones de tiempo típicos para
entornos basados en la reciente ejecución exitosa de un proyecto similar esfuerzo
de por lo menos la mitad del tamaño y complejidad. Existen procesos no-IT-
específicos, disciplina y habilidades para hacer frente a este tipo de esfuerzo. La
empresa tiene una capacidad demostrada para tratar con el tipo de problemas de
gestión de la cartera en curso / proyecto y los requisitos. Hay un reconocimiento
de la necesidad de conocimientos y desarrollo de habilidades para la nueva forma de
trabajar, así como el valor de un análisis de las deficiencias formales sobre las
capacidades y comportamientos.  Capacidad empresarial para implementar y operar los
elementos de transformación y de sus procesos de negocio relacionados, absorber los
cambios derivados de la aplicación, y la capacidad continua para operar en el nuevo
entorno. La empresa tiene una capacidad probada recientemente para hacer frente a
los problemas de gestión de cambios derivados de nuevos procesos y sistemas y que
ha establecido un programa sólido y disciplinado proceso impulsado por los
servicios de gestión que facilite las operaciones, el mantenimiento y el apoyo a
los sistemas existentes. 

Una vez que se han identificado y definido los factores, es útil para llamar a un
taller de seguimiento en donde se evaluarán los factores con más detalle en
términos de su impacto / riesgo. En la siguiente sección se ocupará de la
preparación para una evaluación eficaz de estos factores.

30.3 Factores de preparación actuales

Una vez que se determinan los factores, es necesario presentar de una manera tal
que la evaluación es clara y el valor máximo se deriva de los participantes. Uno de
tales presentación es a través del uso de modelos de madurez. Si cada factor se
convierte en un modelo de madurez (un activo reutilizable gobierno también)
acompañado de una plantilla de hoja de cálculo estándar que contiene toda la
información y las deducciones que deben ser reunidos, puede ser una herramienta muy
útil. El modelo de madurez debe permitir a los participantes:    Evalúe su
(Arquitectura de referencia) nivel de madurez actual  Determinar el nivel de
madurez de destino que tendría que ser alcanzado a darse cuenta de la arquitectura
destino  Determine un objetivo intermedio que serían realizables en un plazo menor 

El cuidado empleado en la preparación de los modelos (que no es insignificante)

será recuperado por un taller enfocado que rápidamente pasará a través de un número
importante de factores. Es importante que cada factor sea bien definido y que el
alcance de la empresa de arquitectura empresarial (planificación preliminar) se
reflejarán en los modelos para mantener a los participantes del taller enfocado y
productivo.

  Página 314 de 670 

TOGOF 9.1    
Circulación de los modelos antes del taller para los comentarios sería útil, aunque
sólo sea para asegurarse de que están completos, así como permitir a los
participantes a prepararse para el taller. Tenga en cuenta que el modelo que figura
a continuación también ha estado objetivo recomendado realizado por el arquitecto
empresarial; esta vez actúa como gobierno. Un ejemplo de un modelo de madurez se
muestra en la Figura 30-1 para uno de los factores BTEP:

  Figura 30‐
1: Negocio Evaluación de la preparación de Transformación ‐ Modelo de Madurez 

30.4 Evaluar los factores de Preparación

Lo ideal es que los factores deben ser evaluados en un taller multidisciplinario.
El uso de un mecanismo como modelos de madurez, arquitectos de la empresa
normalmente tiene que cubrir una gran cantidad de terreno en poco tiempo. El uso de
una serie de plantillas para cada factor aceleraría la evaluación, y garantizar la
coherencia entre la amplia gama de factores. La evaluación debe abordar tres cosas,
a saber:    Factor de Preparación Vision  Factor de Preparación Clasificación 
Factor de Preparación Riesgos y Acciones 

30.4.1 Factor de Preparación Vision

La visión de un factor de disposición es la determinación de cuando la empresa
tiene que evolucionar para abordar el factor. En primer lugar, el factor debe
evaluarse con respecto a su estado base y entonces su estado de destino.

  Página 315 de 670 
TOGOF 9.1    
Por ejemplo, si la "capacidad de TI para ejecutar" factor se califica como baja, el
factor debe estar preferentemente a "alto" para realizar el objetivo Architecture
Vision. Un objetivo intermedio podría ser útil para dirigir la puesta en práctica.
Los modelos de madurez son excelentes vehículos para guiar a esta determinación.

30.4.2 Factor de Preparación Clasificación

Una vez establecidas las visiones de los factores, entonces es útil para determinar
la importancia de cada factor es a la consecución de la arquitectura destino, así
como lo difícil que será para migrar el factor en un estado visionario aceptable.
El BTEP utiliza un esquema de preparación de Calificación que puede ser utilizado
como un punto de inicio para cualquier organización en cualquier vertical. Cada uno
de los factores de preparación son clasificados con respecto a:   Urgencia , de
forma que si un factor de disposición es urgente, que significa que es necesario
actuar antes de que pueda comenzar una iniciativa de transformación.  Estado de
disponibilidad , que está clasificado como sea baja (necesita trabajo importante
antes de proceder), Feria (necesita un poco de trabajo antes de proceder),
aceptable (existen algunos problemas de preparación, no hay motivos para desistir),
Bueno (existen cuestiones relativamente menores) o Alta (sin preparación
cuestiones).  Grado de dificultad para corregir las tasas de esfuerzo requerido
para superar los problemas identificados como bien No Acción Necesaria, Fácil,
Moderado o Difícil. 

Aunque una plantilla más amplia se puede utilizar en el taller, es útil para crear
una tabla resumen de los resultados de consolidar los factores y ofrecer una visión
de gestión. Un resumen como se muestra en la Figura 30-2 .

  Figura 30‐
2: Cuadro Resumen de Evaluación de la preparación de transformación de negocios   
Página 316 de 670 

TOGOF 9.1    
30.4.3 Factor de Preparación Riesgos y Acciones
Una vez que los factores han sido valorados y evaluados, se derivan una serie de
acciones que permitan a los factores de cambiar a un estado favorable. Cada factor
debe evaluarse en relación con el riesgo de utilizar el proceso de relieve en la
parte III , 31. Gestión de Riesgos , que incluye una estimación del impacto y
frecuencia. Cada factor debe ser evaluado de forma discreta y una serie de acciones
de mejora se indica. Antes de comenzar de nuevo, las acciones existentes descritos
en las arquitecturas deben ser revisados antes de crear otros nuevos. Estas
acciones recientemente identificados deben luego ser incorporados formalmente a la
Implementación emergentes y Plan de Migración. Desde una perspectiva de riesgo,
estas acciones están diseñadas para mitigar los riesgos y producir un riesgo
residual aceptable. Como riesgos, deben ser parte del proceso de gestión de riesgos
y un estrecho seguimiento como se está implementando la arquitectura empresarial.

30.5 Preparación y planeamiento de migración

El ejercicio de evaluación proporcionará una evaluación realista de la organización
y será un aporte importante para la planificación de la migración estratégica que
se inició en la fase E y se terminó en Fase F. Es importante tener en cuenta si las
acciones de transformación de negocio estarán en la visión de ruta crítica y, de
ser así, determinar cómo van a afectar a la ejecución. No tiene sentido el
despliegue de nueva capacidad de TI sin empleados formados para ello y apoyar al
personal listo para sostenerlo. Los factores de preparación, como parte de una
implementación global y el Plan de Migración, tendrán que ser supervisados de forma
continua (Fase G) y las acciones correctivas rápidas tomadas a través del marco de
gobierno de TI para asegurar que las arquitecturas definidas se pueden implementar.
La evaluación de los factores de preparación será un documento vivo y durante la
planificación y ejecución de las arquitecturas de Transición de migración, las
actividades de transformación empresarial desempeñará un papel clave.

30.6 La comercialización del Plan de Implementación

La definición de la arquitectura no debe ser ampliamente difundido hasta que los
problemas de transformación de negocio sean identificados y mitigados, y acciones
parte asociada de un plan general de "marketing" para la visión y la aplicación y
el Plan de Migración. Por ejemplo, la concentración parcelaria de la información
podría resultar en cientos de puestos de trabajo perdidos y esta visión no debe ser
anunciado antes de que un plan de recursos de la transformación del negocio /
humanos de apoyo está formulado para una nueva formación o apoyar los esfuerzos de
los trabajadores para el nuevo empleo. Los talleres de transformación de negocio
son una parte fundamental del Plan de Comunicación mediante el cual los individuos
clave dentro de la organización se reúnen para evaluar las

  Página 317 de 670 

TOGOF 9.1    
consecuencias de la transformación de la empresa. Para ello van a tomar conciencia
de la Arquitectura Visión y definición de la arquitectura (si no estaban ya
involucrados a través de los escenarios de negocios y Arquitectura de Negocios).
Este grupo se sentirá la propiedad de la arquitectura de la empresa, el
reconocimiento de la EA como mayordomo valioso. Su determinación de los factores
que volverá a crear una cultura de entendimiento entre la empresa y proporcionar
información útil para la aplicación y el Plan de Migración. Este último plan debe
incluir un plan de comunicación, sobre todo para mantener al personal afectado
informado. En muchos casos, la colaboración con los sindicatos y delegados
sindicales asistirá nuevamente a una transición integridad personal (y pacífica) al
estado de destino.

30.7 Conclusión
En resumen, la implementación de arquitectura empresarial requiere un profundo
conocimiento y la conciencia de toda la transformación del negocio los factores que
impactan la transición al estado visionario. Con la evolución de las TI, la
tecnología actual no es el verdadero problema más en la arquitectura de la empresa,
pero los factores críticos son más a menudo las culturales. Cualquier aplicación y
el Plan de Migración tiene que tener tanto en cuenta. Descuidar estos y centrándose
en los aspectos técnicos, invariablemente resultará en una aplicación mediocre que
no llega a darse cuenta de la verdadera promesa de un visionario de arquitectura
empresarial.

  Página 318 de 670 

TOGOF 9.1       

31. Gestión de Riesgos

En este capítulo se describe la gestión del riesgo, que es una técnica que se
utiliza para mitigar el riesgo en la aplicación de un proyecto de arquitectura.

31.1 Introducción
Siempre habrá riesgo con cualquier esfuerzo de transformación arquitectura /
negocio. Es importante identificar, clasificar y mitigar estos riesgos antes de
empezar, para que puedan realizar un seguimiento durante todo el esfuerzo de
transformación. La mitigación es un esfuerzo en curso y, a menudo los factores
desencadenantes de riesgo puede estar fuera del alcance de los planificadores de
transformación (por ejemplo, la fusión, de adquisición) para los planificadores
deben monitorear el contexto de transformación constante. También es importante
señalar que la empresa arquitecto puede identificar los riesgos y mitigar ciertas
personas, pero está dentro del marco de gobernanza que los riesgos tienen que ser
primero aceptado y luego logró. Hay dos niveles de riesgo que deben ser
considerados, a saber:

1. Nivel Inicial del Riesgo : categorización del riesgo antes de determinar e

implementar acciones de mitigación.  2. Nivel Residual de Riesgo : categorización
del riesgo después de la implementación de medidas de mitigación (si los hay). 
El proceso para la gestión de riesgos se describe en las siguientes secciones y
consta de las siguientes actividades:      La clasificación de riesgo 
Identificación de riesgos  Evaluación del riesgo inicial  La mitigación del riesgo
y evaluación del riesgo residual  Seguimiento del riesgo 

31.2 Clasificación de Riesgo

El riesgo es omnipresente en cualquier actividad arquitectura de la empresa y está
presente en todas las fases en el desarrollo de métodos de Arquitectura (ADM).
Desde una perspectiva de gestión, es útil para clasificar los riesgos para que la
mitigación de los riesgos se puede ejecutar con la mayor rapidez posible.

  Página 319 de 670 

TOGOF 9.1    
Una forma común de riesgos para ser clasificado es con respecto al impacto sobre la
organización (como se explica en 31.4 Evaluación del riesgo inicial ), por el cual
los riesgos con ciertos impactos tienen que ser abordadas por ciertos niveles de
gobernanza. Los riesgos se clasifican normalmente como el tiempo (horario), el
costo (presupuesto), y alcance, sino que también podrían incluir riesgos de
relación de transformación de cliente, los riesgos contractuales, riesgos
tecnológicos, riesgos alcance y complejidad, los riesgos ambientales (de empresa),
los riesgos del personal, y la aceptación del cliente riesgos. Otra forma de
delegar la gestión de riesgos es clasificar aún más los riesgos de los dominios de
la arquitectura. La clasificación de los riesgos como los negocios, la información,
las aplicaciones y la tecnología es útil, pero puede haber formas organizativo-
específicas de expresar el riesgo de que la empresa corporativa arquitectura
dirección debe adoptar o ampliar en lugar de modificar. En última instancia, la
arquitectura riesgos de la empresa son los riesgos corporativos y deben
clasificarse y según proceda manejadas en el mismo o prolongado camino.

31.3 Identificación de Riesgos

Las evaluaciones de preparación y transformación de vencimiento generarán una gran
cantidad de riesgos. Identificar los riesgos y determinar la estrategia para hacer
frente a ellos a través de la transformación. El uso de Modelos de Madurez de
Capacidad (CMM) es adecuada para los factores específicos asociados con la entrega
de la arquitectura para identificar primera referencia y objetivos estados y luego
identificar las acciones necesarias para pasar al estado de destino. Las
consecuencias de no alcanzar el estado de destino pueden resultar en el
descubrimiento de los riesgos. Consulte 30. Transformación del Negocio Evaluación
de preparación para los detalles específicos. Documentación de riesgos se realiza
en el contexto de un Plan de Gestión de Riesgos, para los que existen plantillas en
las metodologías de gestión de proyectos estándar (por ejemplo, gestión de
proyectos libro del conocimiento y PRINCE2), así como con las diferentes
metodologías de gobierno. Normalmente estas metodologías implican procedimientos
para la planificación de contingencia, el seguimiento y la evaluación de los
niveles de riesgo; reaccionar a los cambios en factores de nivel de riesgo, así
como los procesos de documentación, información y comunicación de los riesgos a los
interesados.

31.4 Evaluación del riesgo inicial

El siguiente paso consiste en clasificar los riesgos con respecto a los efectos y
frecuencia de acuerdo con los baremos empleados dentro de la organización. Combine
efecto y la frecuencia para llegar a una evaluación preliminar del riesgo. No hay
reglas duras y rápidas con respecto a los efectos y frecuencia de medición. Las
siguientes directrices se basan en las mejores prácticas de gestión de riesgos
existentes. efecto podría ser evaluada utilizando los siguientes criterios de
ejemplo:

  Página 320 de 670 

TOGOF 9.1    
    Catastrófico infiere la pérdida financiera crítica que podría resultar en
la quiebra de la organización.  Crítica infiere graves pérdidas económicas en más
de una línea de negocio que lleva a una pérdida de la productividad y no retorno de
la inversión en la inversión en TI.  Marginal infiere una pérdida financiera de
menor importancia en una línea de negocio y un retorno de la inversión en la
reducción de la inversión en TI.  Insignificante infiere un impacto mínimo en una
línea de negocio 'capacidad de prestar servicios y / o productos. 

Frecuencia podría indicarse como sigue:      Frecuente : Probabilidad de que

ocurra muy a menudo y / o de manera continua.  Probable : ocurre varias veces en el
transcurso de un ciclo de transformación.  Ocasionales : Ocurre esporádicamente. 
Rara vez : remotamente posible y probablemente se produciría no más de una vez en
el curso de un ciclo de transformación.  Improbable : probablemente no ocurrir
durante el curso de un ciclo de transformación. 

La combinación de los dos factores para inferir el impacto se llevará a cabo

utilizando una heurística basada en el esquema de clasificación pero consistente
para los riesgos. Un esquema de potencial para evaluar el impacto corporativa
podría ser como sigue:     Extremadamente Alto Riesgo (E) : El esfuerzo de
transformación lo más probable es un error con consecuencias graves.  Riesgo alto
(H) : insuficiencia significativa de partes del esfuerzo de transformación que
resulta en ciertas metas no están alcanzados.  Riesgo Moderado (M) : insuficiencia
notoria de partes del esfuerzo de transformación que amenaza el éxito de ciertas
metas.  Riesgo bajo (L) : Ciertas metas no serán un éxito completo. 

Estos impactos se pueden derivar utilizando un esquema de clasificación, como se

muestra en la Figura 31-1 .

    Página 321 de 670 

TOGOF 9.1     Figura 31‐1: Esquema de Clasificación de Riesgo 

31.5 Mitigación de Riesgos y Evaluación de Riesgo Residual

La mitigación del riesgo se refiere a la identificación, planificación y ejecución
de acciones que reduzcan el riesgo a un nivel aceptable. El esfuerzo de mitigación
podría ser un sistema de seguimiento y / o simple aceptación del riesgo para un
plan de contingencia en toda regla llamando para la redundancia completa en un Plan
de Continuidad de Negocio (con todo el alcance de dicha reglamentación, el coste y
las implicaciones de tiempo). Debido a las implicaciones de esta evaluación de
riesgos, tiene que llevarse a cabo de una manera pragmática, pero sistemática. Con
prioridad va a riesgos de alto impacto frecuentes, cada riesgo debe ser mitigado a
su vez.
31.6 Conducta Evaluación del Riesgo Residual
Una vez que el esfuerzo de mitigación se ha identificado para cada uno de los
riesgos, re-evaluar el efecto y la frecuencia y luego volver a calcular los
impactos y ver si el esfuerzo de mitigación realmente ha hecho una diferencia
aceptable. Los esfuerzos de mitigación suelen consumir muchos recursos y un
desembolso importante para poco o ningún riesgo residual debe ser impugnada. Una
vez que se mitiga el riesgo inicial, entonces el riesgo que queda se llama el
"riesgo residual". La consideración clave es que el esfuerzo atenuante reduce
realmente el impacto empresarial y no sólo pasar el riesgo a otra igualmente alto
cuadrante. Por ejemplo, cambiar el riesgo de frecuentes / catastrófico frecuentes /
crítico todavía ofrece un extremadamente de riesgo elevado. Si esto ocurre,
entonces el esfuerzo de mitigación tiene que ser re-examinado. El entregable final
debe ser una evaluación del riesgo de transformación que podría ser estructurado
como una hoja de cálculo, como se muestra en la Figura 31-2 .

  Figura 31‐
2: Ejemplo de Identificación de Riesgos y Mitigación Hoja de evaluación 

Monitoreo 31.7 Riesgos y Gobierno (Fase G)

Los riesgos residuales tienen que ser aprobados por el marco de gobierno de TI y,
potencialmente, en el gobierno corporativo, donde se requiere la aceptación
comercial de los riesgos residuales.

  Página 322 de 670 

TOGOF 9.1    
Una vez que se han aceptado los riesgos residuales, la ejecución de las acciones de
mitigación tiene que ser controlada cuidadosamente para asegurarse de que la
empresa está tratando con residual en lugar de riesgo inicial. Las hojas de trabajo
de evaluación de la identificación y mitigación de riesgos se mantienen como los
artefactos de gobierno y se mantienen al día en la Fase G (Gobernanza Aplicación)
donde se lleva a cabo el seguimiento del riesgo. Gobernabilidad implementación
puede identificar los riesgos críticos que no están siendo mitigados y podrían
requerir otro ciclo ADM total o parcial.

31.8 Resumen
Gestión de riesgos es una parte integral de la arquitectura empresarial. Se anima a
los profesionales a utilizar su metodología de gestión de riesgos corporativos o
ampliarlo mediante la orientación de este capítulo. En ausencia de una metodología
corporativa formal, los arquitectos pueden utilizar las instrucciones de este
capítulo como una buena práctica.

  Página 323 de 670 

TOGOF 9.1       

32. Planificación de Capacidad basada en

Este capítulo proporciona una visión general de la planificación basada en la
capacidad, una técnica de planificación de negocios que se centra en los resultados
de negocio.También arregla bien con la fricción de coordinar proyectos a través de
dominios funcionales empresariales que en conjunto permiten a la empresa para
lograr esa capacidad (por ejemplo, la prestación de servicios electrónicos).

32.1 Información general

Planificación basada en la capacidad se centra en la planificación, la ingeniería,
y la entrega de las capacidades estratégicas de negocio para la empresa. Es
impulsada por los negocios y las empresas dirigidas y combina los esfuerzos
necesarios de todas las líneas de negocio para alcanzar la capacidad deseada.
Planificación basada en la capacidad de alojar la mayoría, si no todos, de los
modelos de negocio de las empresas y es especialmente útil en las organizaciones
donde se requiere una capacidad latente para responder (por ejemplo, una unidad de
preparación para emergencias) y los mismos recursos están implicados en múltiples
capacidades. A menudo, lanecesidad de que estas capacidades se descubrió y
perfeccionó el uso de escenarios de negocios (véase la Parte III , 26. Escenarios
empresariales y objetivos de la empresa ). Desde una perspectiva de TI, la
planificación basada en la capacidad es particularmente relevante. Por ejemplo, la
creación de un centro de datos es realmente acerca de la consolidación de los datos
corporativos y de la prestación de los servicios relacionados. Arquitectos de la
empresa de entrega para esta capacidad se verán involucrados en la gestión de la
construcción, la capacitación del personal, y otras tareas de gestión del cambio,
así como las tareas de arquitectura de TI. En el pasado, muchos proyectos de TI
fueron menos de éxito a pesar de la implementación de TI real era brillante, pero
las otras tareas asociadas (proceso de reingeniería de negocios, formación de
clientes, apoyo a la formación, las infraestructuras, etc) fueron no controlados
por la empresa arquitectos y planificadores ya menudo no se completaron
satisfactoriamente. Por otra parte, los proyectos de TI a menudo se describen en
términos de prestaciones técnicas y no como resultados de negocio, lo que hace
difícil para las empresas para apreciar lo que se está entregando ya menudo los
arquitectos de TI perdió de vista el objetivo empresarial fundamental. Marcos de
planificación basado en la capacidad de todas las fases del desarrollo de la
arquitectura en el contexto de los resultados del negocio, vinculando claramente la
visión de TI, arquitecturas (ABBS y SBB), y la aplicación y los planes de migración
con la estratégica corporativa, de negocios, y la línea de planes de negocios. En
muchos gobiernos, la interoperabilidad horizontal y servicios compartidos se
perfilan como piedras angulares de sus implementaciones de e-gobierno y la gestión
basada en la capacidad es también prominente aunque bajo muchos disfraces. En el
sector privado, los conceptos de gestión de la cadena de suministro y la
Arquitectura Orientada a Servicios (SOA) están obligando cada vez más
planificadores / gestores de gobernar tanto horizontal como verticalmente.

32,2 capacidad basada en Planificación Paradigma

Planificación basada en la capacidad de mucho tiempo se ha afianzado en el ámbito
de Defensa de los EE.UU., Reino Unido, Australia y Canadá. Los mecanismos de
gobernanza asociados, así

  Página 324 de 670 

TOGOF 9.1    
como la capacidad de derivación rigurosa (ingeniería de la capacidad), están
surgiendo sobre todo en el dominio de la ingeniería de sistemas.Estos conceptos son
fácilmente transferibles a otros ámbitos, como el de TI.

32.3 Concepto de Planificación de Capacidad basada en

De una arquitectura empresarial y la perspectiva de TI, la planificación basada en
la capacidad es un poderoso mecanismo para asegurar que el plan estratégico de
negocios conduce la empresa desde un enfoque de arriba hacia abajo. También es
adaptable a la ingeniería la capacidad de aprovechar las innovaciones emergentes de
abajo hacia arriba. No importa cómo las estructuras de la corporación en sí ,
tendrá que hacer frente a la entrega de capacidades de negocio cuya entrega se
requerirá la coordinación y la alineación a través de verticales de negocio. Las
capacidades son los negocios impulsados y lo ideal sería impulsado por las
empresas. Uno de los principales retos es que los beneficios son recogidos muy a
menudo en la empresa y no la línea de nivel de negocios. En consecuencia, los
proyectos dentro de la línea de carteras de negocios dirigidas tienden a adoptar
una línea de negocio en lugar de la perspectiva empresarial. Gestión de la entrega
de una capacidad es un reto, pero el afianzamiento de una perspectiva basada en la
capacidad de una organización es un poderoso mecanismo para proporcionar un valor
comercial derivado sinérgica que resonará en la rentabilidad y el valor de las
acciones. Capacidades deben especificarse utilizando la misma disciplina en la
especificación de los objetivos como en los escenarios de negocio; concretamente,
se deben seguir las pautas de SMART para evitar ambigüedades. Como se muestra en la
Figura 32-1 , muchas capacidades son "horizontal" y van a contrapelo de gobierno
corporativo vertical normal. Muy a menudo, la gestión de la dirección, así como el
marco de rendición de cuentas de gestión empresarial se basan en la línea de las
métricas de negocio, no métricas empresariales. Arquitectura empresarial es también
una función horizontal que se ve a nivel de empresa (así como la línea de nivel
empresarial) la optimización y la prestación de servicios. Como era de esperar, la
planificación basada en la capacidad y la arquitectura de la empresa se apoyan
mutuamente. Ambos suelen operar contra la corriente corporativa y ambos tienen que
hacer frente a entornos empresariales exigentes. Apoyo a las empresas de
arquitectura de la empresa es crucial para su éxito y es lógico que se alinea con
los planificadores de capacidad de las empresas, así como proporcionar apoyo a las
personas dentro de las líneas verticales de negocio.

  Página 325 de 670 

TOGOF 9.1    

  Figura 32‐1: Concepto de planificación basado en capacidad 
Las capacidades también pueden ser verticales y manejado en el contexto de la
estructura de organización de negocios. De hecho, los requisitos de capacidad a
menudo conducen el diseño organizacional, pero dentro de una organización en el
proceso de transformación de la empresa, la organización pueden estar detrás de las
necesidades de capacidad. Capacidades verticales son más fáciles de manejar y el
apoyo de la función de la arquitectura empresarial, pero todavía desafiante cuando
los servicios se racionalizan a nivel de empresa y de las líneas de negocio reciben
servicios compartidos que no controlan directamente (proporcionan un control
indirecto a través de la gobernanza de TI en el Consejo de Arquitectura tal como
fue creado en la planificación preliminar y se utiliza en la fase G (Gobernanza de
Implementación). Para la planificación basada en la capacidad de tener éxito, tiene
que ser controlada con respecto a las dimensiones y los incrementos, tal como se
explica en las dos secciones siguientes.

32.3.1 Capacidad Dimensiones

Las capacidades están diseñadas / generan teniendo en cuenta las diversas
dimensiones que se sitúan en las carteras funcionales corporativas. Cada
organización tiene un conjunto de dimensiones diferentes pero similares. Un ejemplo
de ajuste (con base en el Departamento de Defensa Nacional de Canadá) podría
incluir personal, investigación y desarrollo, infraestructura / instalaciones,
conceptos / procesos, gestión de la información y material. Lo que se seleccionan
las dimensiones, deben ser bien explicadas y entendidas.

  Página 326 de 670 

TOGOF 9.1    

  Figura 32‐2: Incrementos de Capacidad y Dimensiones 
32.3.2 Los incrementos de capacidad
Una capacidad se llevará un tiempo prolongado para entregar (detalles estarán en
función de la organización y de la industria vertical) y participará normalmente
muchos proyectos que entregan numerosos incrementos. Además, la capacidad debe
proporcionar un valor empresarial real a los interesados lo antes posible y
mantener el impulso para lograr el Objetivo de Arquitectura, así como el apoyo
ejecutivo asociado y la financiación de las empresas. Por lo tanto, es útil para
romper la capacidad en incrementos de capacidad que permitan conseguir resultados
discretos, visibles y cuantificables, así como proporcionar el foco para la
Transición Arquitecturas y los entregables de numerosos proyectos
interdependientes. Estos resultados son los factores críticos de éxito (CSF) para
apoyo constante capacidad. Comunicar la potencialmente compleja evolución
incremental de una capacidad de la comunidad de partes interesadas es esencial para
establecer un buy-in en el inicio y para mantener su buy-in durante la transición.
El Incremento de Capacidad diagrama "Radar" (ver Figura 32-3 ) es un método de
probada eficacia para describir cómo una capacidad evolucionará con el tiempo. El
arquitecto selecciona los aspectos de capacidad que son importantes para la
comunidad de interesados como las líneas que irradian desde el centro. Contra cada
línea, el arquitecto dibuja puntos que representan importantes "puntos de
capacidad" (puntos de "inferiores" de capacidad más cercanas al centro, "superior"
puntos de capacidad más lejanos del centro). Con estos "marcadores" en su lugar el
arquitecto puede, uniendo los puntos de capacidad en un circuito cerrado, demostrar
de una forma sencilla cómo cada "incremento de capacidades" se extenderá sobre el
incremento anterior. Esto, por supuesto, requiere que cada punto de la capacidad se
define formalmente y "etiqueta" de una manera que tenga sentido para los grupos de
interés. En el siguiente diagrama, que hemos representado Capacidad Incremento 0
como la capacidad de arranque.

  Página 327 de 670 

TOGOF 9.1    

  Figura 32‐3: Incremento de Capacidad "Radar" 

32.4 Capacidades en un Contexto de Arquitectura Empresarial

Las capacidades se derivan directamente de la plan estratégico corporativo por los
planificadores estratégicos corporativos que son y / o incluyen los arquitectos de
la empresa y satisfacer las metas de la empresa, objetivos y estrategias. La
mayoría de las organizaciones también tendrán un plan de negocios anual que
describe cómo la organización tiene la intención de continuar durante el próximo
ejercicio fiscal con el fin de cumplir con los objetivos estratégicos de la
empresa. La figura 32-4 ilustra las relaciones cruciales entre la planificación
basada en la capacidad, la arquitectura empresarial y gestión de la cartera / del
proyecto. Por el lado de la mano izquierda, la gestión de la capacidad está
alineada con la arquitectura empresarial. La clave es que todas las arquitecturas
se expresará en términos de resultados empresariales y de valor más que en términos
de TI (por ejemplo, el establecimiento de una granja de servidores), asegurando así
la alineación de TI con el negocio. La intención es que la dirección estratégica
corporativa impulsa la visión de la Arquitectura en la Fase A, así como la
organización de la empresa, que será la base para la creación de carteras. Las
capacidades específicas dirigidas para la finalización será el tema central de la
definición de la arquitectura (las fases B, C y D) y, en base a la labor
mencionadapaquetes, se concibieron proyectos Fase E.

  Página 328 de 670 

TOGOF 9.1    
Los incrementos de capacidad serán los controladores para las arquitecturas de
transición (Fase E) que estructurarán los incrementos de los proyectos. La entrega
real será coordinado a través de la aplicación y los planes de migración (Fase F).
  Figura 32‐4: Relación Entre Capacidades, Arquitectura Empresarial y Proyectos 
Gerentes de capacidad al desarrollo de tareas similares a las de los gestores de
carteras, pero a través de las carteras de la alineación de los proyectos y los
incrementos del proyecto para entregar valor de negocio continuo. Considerando que
los gestores de cartera se ocupará de la coordinación de sus proyectos para diseñar
de manera óptima, construir y entregar los bloques de construcción de la solución
(SBB). Lo ideal sería que los administradores de capacidad también gestionarán los
fondos que pueden utilizar las arquitecturas de transición como puertas. La
coordinación entre la cartera y los administradores de capacidad tendrá que ser
proporcionada a nivel corporativo.

32.5 Resumen
Planificación basada en la capacidad es un paradigma de la planificación
empresarial versátil que es muy útil desde el punto de vista de arquitectura
empresarial. Ayuda a la alineación de TI con el negocio y ayuda a los arquitectos
de TI se centran en la creación continua de valor para el negocio.

  Página 329 de 670 

TOGOF 9.1       

PARTE IV Marco de  Arquitectura de  contenido

   

  Página 330 de 670 

TOGOF 9.1       

33. Introducción 33.1 Información general

Arquitectos ejecutar el método de Desarrollo Arquitectura (ADM) producirán una
serie de resultados, como resultado de sus esfuerzos, como los flujos de procesos,
requisitos arquitectónicos, planes de proyectos, evaluaciones de cumplimiento de
proyectos, etc El marco de contenido proporciona un modelo estructural para el
contenido arquitectónico que permite a los principales productos de trabajo que un
arquitecto crea que definirse constantemente, estructurada y presentada. El marco
de contenido proveído aquí tiene por objeto permitir TOGAF para ser utilizado como
un marco independiente para la arquitectura dentro de una empresa. Sin embargo,
existen otros marcos de contenido (como el Marco Zachman) y se prevé que algunas
empresas pueden optar por usar un marco externo en conjunto con TOGAF.En estos
casos, el marco de contenido proporciona una referencia útil y punto de partida
para el contenido TOGAF estar asignada a otros marcos. La Arquitectura del marco de
contenido usa las siguientes tres categorías para describir el tipo de producto de
trabajo de arquitectura dentro del contexto de uso:  Un entregable es un producto
de trabajo que se especifica y, a su vez revisado formalmente, de acuerdo, y
firmado por las partes interesadas contractualmente.Entregables representan la
salida de los proyectos y los resultados que se tenga en forma de documentación
serán típicamente archivadas en la finalización de un proyecto, o la transición
hacia un repositorio arquitectura como un modelo de referencia, estándar o
instantánea de la arquitectura del paisaje en un punto en el tiempo.   Un artefacto
es un producto del trabajo arquitectónico que describe un aspecto de la
arquitectura. Los artefactos se clasifican generalmente como catálogos (listas de
cosas), matrices (que muestran las relaciones entre las cosas), y diagramas
(imágenes de las cosas). Los ejemplos incluyen un catálogo de necesidades, matriz
de interacción de negocios, y un diagrama de casos de uso. Un entregable
arquitectónica puede contener muchos objetos y artefactos formarán el contenido de
la Arquitectura Repository.   Un bloque de construcción representa un
(potencialmente reutilizable), componente de negocio, TI, o la capacidad de la
arquitectura que se puede combinar con otros bloques de construcción para ofrecer
arquitecturas y soluciones.   Bloques de construcción se pueden definir en varios
niveles de detalle, dependiendo de la etapa de desarrollo de la arquitectura se ha
alcanzado. Por ejemplo, en una etapa temprana, un bloque de construcción puede
consistir simplemente en un nombre o una breve descripción. Más tarde, un bloque de
construcción se puede descomponer en varios bloques de edificios de apoyo y puede
ir acompañada de una especificación completa. Bloques de construcción pueden
relacionarse con "arquitecturas" o "soluciones". o Arquitectura Bloques de
Construcción (Abs) suelen describir la capacidad requerida y dar forma a la
especificación de soluciones de Bloques de Construcción (SBB). Por ejemplo, una
capacidad de servicio al cliente puede ser

  Página 331 de 670 

TOGOF 9.1    
necesaria dentro de una empresa, con el apoyo de muchos SBB, como los procesos,
datos y software de aplicación.  o Solución Building Blocks (SBB) representan los
componentes que se utilizarán para implementar la capacidad requerida. Por ejemplo,
una red es un bloque de construcción que se puede describir a través de artefactos
complementarios y luego objeto de un uso para darse cuenta de las soluciones para
la empresa. 

Las relaciones entre los entregables, artefactos y bloques de construcción se

muestran en la Figura 33-1 .

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

  Página 332 de 670 

TOGOF 9.1    

  Figura 33‐2: Ejemplo ‐ Arquitectura de definición de documento 

33.2 Metamodel contenido

El metamodelo de contenidos proporciona una definición de todos los tipos de
bloques de construcción que puedan existir dentro de una arquitectura, que muestra
cómo estos bloques de construcción pueden ser descritos y relacionados entre sí.
Por ejemplo, al crear una arquitectura , un arquitecto identificará las
aplicaciones, "entidades de datos", realizado dentro de las aplicaciones y
tecnologías que implementan esas aplicaciones. Estas aplicaciones serán a su vez
apoyar a determinados grupos de usuarios de negocios o actor, y se utilizarán para
cumplir con los "servicios empresariales". El metamodelo contenido identifica todas
estas preocupaciones (es decir, la aplicación, entidad de datos, tecnología, actor,
y servicios empresariales), muestra las relaciones posibles entre ellos (por
ejemplo, los actores consumen servicios de negocios), y, finalmente, identifica los
artefactos que se pueden utilizar para que los represente. La Figura 33-3 muestra
una visión general del metamodelo contenido.

  Página 333 de 670 

TOGOF 9.1    

 
Figura 33‐3: Contenido Metamodel Información general 

33.3 Marco de Contenido y el TOGAF ADM

El TOGAF ADM describe el proceso de pasar de un estado de la línea de base de la
empresa a un estado objetivo de la empresa. El ADM se abordará una necesidad de
negocio a través de un proceso de la visión, la definición de la arquitectura, la
planificación de la transformación, y la gobernanza de la arquitectura. En cada
etapa de este proceso, el ADM requiere información como entradas y salidas creará
como resultado de la ejecución de un número de pasos. El marco de contenido
proporciona una estructura subyacente para el ADM que define las entradas y salidas
con más detalle y pone cada resultado en el contexto de la vista de la arquitectura
global de la empresa. Por tanto, el marco de contenidos debe ser utilizado como un
complemento de la ADM. El ADM se describe lo que hay que hacer para crear una
arquitectura y el marco de contenido describe lo que la arquitectura debe ser
similar, una vez que se hace.

33.4 Estructura de la Parte IV

Parte IV: Arquitectura del marco de contenido está estructurado de la siguiente
manera:  Introducción (este capítulo) 

  Página 334 de 670 

TOGOF 9.1    
    Metamodel contenido (véase 34. Metamodel contenido )  Architectural
Artifacts (ver 35. Architectural Artifacts )  Arquitectura Entregables (ver 36.
Arquitectura entregables )  Bloques de construcción (ver 37. Building Blocks ) 

  Página 335 de 670 

TOGOF 9.1       

34. Metamodel contenido

 

34.1 Información general

La Arquitectura Método de Desarrollo de TOGAF (ADM) brinda un ciclo de vida de
procesos para crear y gestionar arquitecturas dentro de una empresa. En cada fase
dentro de la ADM, una discusión de entradas, salidas, y los pasos se describen una
serie de productos o artefactos de trabajo de arquitectura, como proceso y
aplicación. El metamodelo contenido proveído aquí define una estructura formal de
estos términos para garantizar la coherencia dentro de la ADM y también para
proporcionar una guía para las organizaciones que desean implementar su
arquitectura dentro de una herramienta de arquitectura.

34.2 Contenido Metamodel Visión y Conceptos

Esta sección proporciona una visión general de los objetivos del metamodelo
contenido, los conceptos que sustentan el metamodelo, y una visión general de la
propia metamodelo. En las secciones siguientes y luego ir a discutir cada área del
metamodelo con más detalle. Contenido de esta sección son los siguientes: 
Conceptos del metamodelo de contenido básico (ver 34.2.1 Conceptos básicos
Metamodel contenido ) identifica los conceptos clave dentro del metamodelo
contenido básico, que incluye:  o o o o  Core y contenido extensión  Modelado
formal e informal  Entidades metamodelo Core  Catálogo, matriz, y el concepto de
diagrama 

Información general sobre el contenido metamodelo TOGAF (ver 34.2.2 Descripción

general del Metamodel contenido ) proporciona una visión general de alto nivel del
contenido del metamodelo. 

34.2.1 Conceptos básicos Metamodel contenido

A TOGAF arquitectura se basa en la definición de una serie de bloques de
construcción de arquitectura dentro de la arquitectura catálogos, especificando las
relaciones entre esos bloques de construcción de matrices de arquitectura, y luego
la presentación de los diagramas de comunicación que muestran de una manera precisa
y concisa lo que la arquitectura es. En esta sección se presentan los conceptos
principales que conforman el contenido metamodelo TOGAF, a través de los siguientes
apartados:

  Página 336 de 670 

TOGOF 9.1    
 Core y Extensión de contenido proporciona una introducción a la forma en que
TOGAF emplea un metamodelo núcleo básico y luego se aplica una serie de módulos de
extensión para abordar los problemas arquitectónicos específicos en más detalle. 
Entidades Metamodel Core introduce las centrales entidades metamodelo TOGAF, que
muestra el propósito de cada entidad y las relaciones claves que apoyan la
trazabilidad arquitectónico.  Catálogo, Matrix, y árbol conceptual describe el
concepto de catálogos, matrices y diagramas. 

Core y Contenido de Extensión

El papel de TOGAF es proporcionar un estándar abierto para la arquitectura, que es

aplicable en muchos escenarios y situaciones. Con el fin de cumplir con esta
visión, es necesario proporcionar una completa empresa metamodelo arquitectura
destacado de contenido y también para proporcionar la capacidad de evitar la
realización de actividades innecesarias mediante el apoyo a la adaptación. El
metamodelo debe proporcionar un modelo básico con el conjunto mínimo de
características y luego apoyar la inclusión de extensiones opcionales durante el
enganche sastrería. El núcleo TOGAF contenido metamodelo y sus extensiones se
ilustran en la Figura 34-1 .

  Figura 34‐1: TOGAF Metamodel contenido y sus extensiones 
El metamodelo núcleo proporciona un conjunto mínimo de contenido arquitectónico
para apoyar la trazabilidad a través de artefactos. Conceptos adicionales
metamodelo para apoyar el modelado más específico o más detallado están contenidas
dentro de un grupo de extensiones que los catálogos lógicamente racimo de
extensión, matrices y diagramas, lo que permite el enfoque en áreas de interés y el
enfoque específico.

  Página 337 de 670 

TOGOF 9.1    
Todos los módulos de extensión son opcionales y deben seleccionarse durante la
Etapa Preliminar del desarrollo de la arquitectura para satisfacer las necesidades
de la organización. Además, los grupos de extensión descritos por el metamodelo
contenido son sólo una sugerencia y, además de sastrería se pueden llevar a cabo
para adaptarse a las necesidades específicas a la discreción de los arquitectos.
Este núcleo y el concepto de extensión se pretende como un paso hacia el apoyo a
los enfoques de extensión de métodos formales dentro TOGAF, tales como el método de
plug-in concepto que se encuentra dentro del Proceso de Ingeniería de Software
Metamodel (SPEM) desarrollado por el Object Management Group (OMG). 1
Entidades Metamodel Core

El metamodelo de contenido utiliza la terminología debatido en el TOGAF ADM como

base para un metamodelo formal. Se utilizan los siguientes términos básicos:   
 Actor : Una persona, organización o sistema que está fuera de la consideración
del modelo de arquitectura, sino que interactúa con él.  Componente de aplicación :
Una encapsulación de funcionalidad de la aplicación que está alineado con la
estructuración de la implementación.  Business Service : Soporta capacidades de
negocio a través de una interfaz definida explícitamente y se rige explícitamente
por una organización.  Entity Data : Una encapsulación de datos que es reconocido
por un experto dominio del negocio como un concepto discreto. Entidades de datos
pueden estar vinculados a las aplicaciones, repositorios y servicios y pueden ser
estructurados de acuerdo con las consideraciones de implementación.  Función :
Proporciona capacidades de negocio estrechamente alineadas a una organización, pero
no rige explícitamente por la organización.  Servicio de Sistema de Información :
Los elementos automáticos de un servicio empresarial. Un servicio del sistema de
información puede ofrecer o apoyar la totalidad o parte de uno o varios servicios
de oficina.  Unidad de Organización : Una unidad autónoma de los recursos con las
metas, objetivos y medidas. Unidades organizativas pueden incluir partes externas y
las organizaciones asociadas de negocios.  Plataforma de Servicios : Una capacidad
técnica requerida para proporcionar la infraestructura que permite que apoya la
entrega de aplicaciones.  Rol : Un actor asume un papel para realizar una tarea. 
Componente Tecnología : Una encapsulación de la infraestructura de tecnología que
representa una clase de producto de la tecnología o producto de tecnología
específica. 

 

  

Una definición más detallada de los términos utilizados en el metamodelo contenido

se puede encontrar en la parte I , 3. Definiciones .

  Página 338 de 670 

TOGOF 9.1    
Algunos de los conceptos clave relacionados con la relación de las entidades
metamodelo fundamentales se describen a continuación:  Proceso normalmente debe
ser usado para describir el flujo de  Un proceso es un flujo de interacciones entre
las funciones y servicios, y no se puede implementar físicamente. Todos los
procesos deben describir el flujo de ejecución de una función y, por tanto, el
despliegue de un proceso es a través de la función que soporta; es decir, una
aplicación implementa una función que tiene un proceso, no una aplicación
implementa un proceso.  Función describe unidades de capacidad de negocio en todos
los niveles de granularidad  El término "función" se utiliza para describir una
unidad de capacidad de negocio en todos los niveles de granularidad, encapsulando
términos tales como cadena de valor, área de proceso, la capacidad, la función
empresarial, etc Cualquier unidad acotado de la función empresarial debe ser
descrito como una función.  Servicios a empresas apoyan los objetivos
organizacionales y se definen a un nivel de granularidad en consonancia con el
nivel de la gobernabilidad necesaria  Un servicio de negocio opera como un límite
para una o más funciones. La granularidad de los servicios de negocio depende del
enfoque y el énfasis de la empresa (como se refleja en sus controladores, metas y
objetivos). Un servicio en la Arquitectura Orientada a Servicios (SOA) terminología
(por ejemplo, una unidad de despliegue de la funcionalidad de la aplicación) es en
realidad mucho más cerca de un servicio de aplicación, componente de la aplicación
o componente de tecnología, lo que puede implementar o apoyar a un servicio de
negocio.  Servicios a empresas se han desplegado en los componentes de
aplicaciones  Servicios a empresas puedan ser realizados por la actividad
empresarial que no se refiere a él, o pueden ser apoyados por TI. Servicios a
empresas que son apoyados por TI se despliegan en los componentes de la aplicación.
Componentes de aplicación se pueden descomponer jerárquicamente y pueden soportar
uno o más servicios de oficina. Es posible que un servicio de negocio a ser apoyado
por múltiples componentes de la aplicación, pero esto es problemático desde el
punto de vista de la gobernabilidad y es sintomático de servicios a las empresas
que son demasiado grano grueso, o componentes de aplicaciones que son demasiado
fino.  Los componentes de aplicación se despliegan en los componentes
tecnológicos  Un componente de la aplicación se lleva a cabo por un conjunto de
componentes de tecnología. Por ejemplo, una aplicación, como "Sistema de Recursos
Humanos" normalmente se llevaría a cabo en varios componentes de la tecnología,
incluyendo el hardware, el software de servidor de aplicaciones y servicios de
aplicación. La figura 34-2 ilustra las entidades centrales y sus relaciones.

  Página 339 de 670 

TOGOF 9.1    

  Figura 34‐2: Las entidades centrales y sus relaciones 
Catálogo, Matriz y Diagrama Concept

El metamodelo de contenido se utiliza como una técnica para estructurar la

información de arquitectura de una forma ordenada de manera que se puede procesar
para satisfacer las necesidades de los interesados. La mayoría de los grupos de
interés de arquitectura en realidad no necesita saber lo que la arquitectura
metamodelo es y sólo se preocupan de temas específicos, tales como "¿Qué
funcionalidad de este soporte de aplicaciones?", "Qué procesos se verán afectadas
por este proyecto? ", etc Con el fin de satisfacer las necesidades de estos grupos
de interés, se utilizan los conceptos TOGAF de bloques de construcción, catálogos,
matrices y diagramas. Bloques de construcción son entidades de un tipo particular
en el metamodelo (por ejemplo, un servicio de negocio llamado "Orden de Compra").
Bloques de construcción llevan metadatos según el metamodelo, que apoya la consulta
y análisis. Por ejemplo, los servicios de negocios tienen un atributo de metadatos
para el propietario, el cual permite que un grupo de interés para consultar todos
los servicios a las empresas de propiedad de una organización en particular.
Bloques de construcción también pueden incluir las entidades dependientes o
contenidos, según corresponda al contexto de la arquitectura (por ejemplo, un
servicio de negocio llamado "Orden de Compra" puede incluir implícitamente una
serie de procesos, entidades de datos, componentes de la aplicación, etc.) Los
catálogos son listas de bloques de construcción de un tipo específico, o de que lo
incluya, que se utilizan para los propósitos de gobierno o de referencia (por
ejemplo, un organigrama, que

  Página 340 de 670 

TOGOF 9.1    
muestra la ubicación y los actores). Al igual que con bloques de construcción,
catálogos llevan metadatos según el metamodelo, que apoya la consulta y análisis.
Las matrices son redes que muestran las relaciones entre dos o más entidades de
modelo. Las matrices se utilizan para representar las relaciones que son basados en
la lista en lugar de gráfica en su uso (por ejemplo, una matriz que muestra qué
aplicaciones CRUD crear, leer, actualizar y eliminar un determinado tipo de datos
es difícil de representar visualmente). Los diagramas son representaciones de
contenido arquitectónico en un formato gráfico para permitir a las partes
interesadas para recuperar la información requerida.Diagramas también se pueden
utilizar como una técnica para poblar gráficamente contenido de arquitectura o para
comprobar la integridad de la información que se ha recogido. TOGAF define un
conjunto de diagramas de arquitectura que se creen (por ejemplo, el organigrama).
Cada uno de estos diagramas se pueden crear varias veces para una arquitectura con
un estilo diferente o la cobertura de contenido de acuerdo a las preocupaciones de
las partes interesadas. Bloques de construcción, catálogos, matrices y diagramas
son conceptos que están bien apoyados por los principales herramientas de
arquitectura empresarial. En los entornos donde se utilizan herramientas para
modelar la arquitectura, estas herramientas suelen apoyar mecanismos para buscar,
filtrar y consultar la Arquitectura Repository. Consultas a petición del
Repositorio Arquitectura (como el ejemplo de la propiedad de servicio de negocio se
ha mencionado anteriormente) se puede utilizar para generar ad hoc, catálogos,
matrices y diagramas de la arquitectura. Como este tipo de consulta es, por
naturaleza, exige ser flexible, es, por tanto, no se limita o define dentro del
metamodelo contenido. Las interacciones entre bloques metamodelo, construcción,
diagramas, y las partes interesadas se muestran en la Figura 34-3 .

  Página 341 de 670 

TOGOF 9.1    

  Figura 34‐
3: Interacciones entre Metamodel, bloques de construcción, diagramas, y las partes 
interesadas 
34.2.2 Descripción general del Metamodel contenido
El metamodelo de contenido define un conjunto de entidades que permiten a los
conceptos arquitectónicos que se capturen, almacenen, se filtró, consultan, y se
representan en una manera que apoye la consistencia, integridad y trazabilidad. Al
más alto nivel, el marco de contenido se divide de acuerdo con las fases TOGAF ADM,
como se muestra en la Figura 34-4 .

    Página 342 de 670 

TOGOF 9.1     Figura 34‐4: Contenido Marco por Fases ADM 
 Principios Arquitectura, Visión y Requerimientos artefactos están destinados a
captar el contexto que lo rodea de modelos de arquitectura formales, incluyendo los
principios generales de arquitectura, el contexto estratégico que constituye la
entrada para el modelado de la arquitectura, y los requisitos generados a partir de
la arquitectura. El contexto arquitectura típicamente queda recogida en las fases
preliminares y Arquitectura de la visión.  Arquitectura Profesiones artefactos
captan los modelos arquitectónicos de la operación del negocio, centrándose
específicamente en los factores que motivan a la empresa, cómo se estructura
organizativamente la empresa, y también lo que las capacidades funcionales de la
empresa tiene.  Sistemas de Información Arquitectura modelos artefactos
arquitectura de captura de los sistemas de TI, mirando a las aplicaciones y datos
de acuerdo con las fases TOGAF ADM.  Arquitectura Tecnología artefactos captura
adquirió los activos tecnológicos que se utilizan para poner en práctica y hacer
realidad soluciones de sistemas de información.  Arquitectura Realización hojas de
ruta del cambio artefactos de captura que muestran la transición entre los estados
de arquitectura y estados de enlace que se utilizan para dirigir y gobernar una
implementación de la arquitectura. 

  

Una representación más detallada de la metamodelo contenido se muestra en la Figura

34-5 .

    Página 343 de 670 

TOGOF 9.1     Figura 34‐5: Representación detallada de la Metamodel contenido 

34.3 Metamodel contenido al detalle

Esta sección contiene los siguientes apartados:    Metamodel contenido Core (ver
34.3.1 Contenido Core Metamodel ) describe las entidades metamodelo que forman el
metamodelo contenido básico.  Artefactos arquitectura de núcleo (véase 34.3.2
Arquitectura del núcleo Artifacts ) enumera el conjunto de artefactos destinados a
acompañar el metamodelo contenido básico.  Metamodel contenido completo (véase
34.3.3 completa Metamodel contenido ) describe las entidades metamodelo que forman
extensiones al metamodelo contenido. 

34.3.1 Contenido Core Metamodel

La figura 34-6 muestra las entidades metamodelo y relaciones que están presentes
dentro del metamodelo contenido básico.

   
  Figura 34‐6: Entidades y relaciones presentes en el Metamodel contenido Core 

  Página 344 de 670 

TOGOF 9.1    
34.3.2 Arquitectura del núcleo Artefactos
35. Architectural Artifacts discute en detalle la forma en que el metamodelo
contenido subyacente puede ser utilizado para presentar un conjunto de catálogos,
matrices y diagramas para hacer frente a las preocupaciones de las partes
interesadas. El siguiente conjunto de artefactos están destinadas a acompañar el
metamodelo contenido básico:
ADM Fase Preliminar Architecture Vision Artefactos Principios Catálogo Stakeholder
Mapa Matrix Diagrama de la Cadena de Valor Solución Concepto Diagrama Catálogo
Organización / Actor Catálogo de funciones Business Service / Función catálogo
Matriz de Interacción de Negocios Matrix Actor / Rol Negocios Huella Diagrama
Business Service / Diagrama de Información Diagrama de Descomposición Funcional
Diagrama del ciclo de vida del producto Catálogo de Entity Data / componente de
datos Entity Data / Matrix Función comercial Aplicación / Data Matrix Diagrama
conceptual de datos Diagrama de lógica de datos Diagrama de Divulgación de Datos
Catálogo cartera de aplicaciones Catálogo de interfaz Aplicación / Matrix
Organización Matrix Papel / Aplicación Matrix Aplicación / Función Aplicación
matriz de interacción Aplicación Diagrama Comunicación Solicitud y usuario
Ubicación Diagrama Diagrama de Casos de Uso Catálogo de Estándares de Tecnología
Catálogo Cartera Tecnológica Aplicación / Matrix Tecnología Entornos y diagrama de
las ubicaciones Plataforma Descomposición Diagrama Proyecto Diagrama de Contexto
Diagrama de Beneficios Requisitos del catálogo

Arquitectura de Negocios

Sistemas de Información (Arquitectura de Datos)

Sistemas de Información (Solicitud de Arquitectura)

Arquitectura Tecnología

Oportunidades y Soluciones Gestión de Requisitos

34.3.3 completa Metamodel contenido

Cuando todas las extensiones se aplican al metamodelo contenido básico, se
introducen una serie de nuevas entidades metamodelo. Figura 34-7 muestra qué
entidades están contenidos en el metamodelo contenido básico y que nuevas entidades
se introducen mediante el cual la extensión.

  Página 345 de 670 

TOGOF 9.1    

  Figura 34‐7: Metamodel contenido con extensiones 
Las relaciones entre las entidades del metamodelo completo se muestran en la Figura
34-8 .

  Página 346 de 670 

TOGOF 9.1    

  Figura 34‐8: Las relaciones entre las entidades del metamodelo completo 

  Página 347 de 670 

TOGOF 9.1    

34.4 Extensiones Metamodel contenido

Como se señaló anteriormente, el contenido metamodelo TOGAF es compatible con una
serie de módulos de extensión que permiten una reflexión más profunda para las
preocupaciones particulares de la arquitectura. Figura 34-9 muestra el metamodelo
contenido básico y módulos de extensión predefinidos.

  Figura 34‐9: Core Metamodel Contenido y Módulos de Extensión predefinidos 
Durante la fase de Visión Arquitectura de un compromiso en particular, el alcance
del trabajo se puede utilizar para hacer una determinación sobre extensiones
adecuadas para ser utilizadas con el fin de abordar adecuadamente los requisitos de
arquitectura. Por ejemplo, el alcance de un compromiso podría ser definida como el
contenido de núcleo, además de las extensiones de gobierno, como se muestra en la
figura 34-10 .

  Figura 34‐10: Contenido Core con extensiones de Gobierno 
Las siguientes secciones proporcionan una descripción más detallada de la finalidad
y el contenido de cada uno de los módulos de ampliación.

  Página 348 de 670 

TOGOF 9.1    
34.4.1 Extensiones de Gobierno
Propósito

La extensión de gobierno tiene la intención de permitir que los datos estructurados

adicionales que se celebrarán con los objetivos y servicios a las empresas, el
apoyo a la gobernabilidad operacional del paisaje. El alcance de esta extensión es
como sigue:     La posibilidad de aplicar medidas destinadas a objetivos y
vincular estas medidas a los servicios  La capacidad de aplicar los contratos para
el servicio de comunicaciones o de servicios de interacción con los usuarios y los
sistemas externos  La capacidad de definir calidades de servicio reutilizables
definir un perfil de nivel de servicio que se puede utilizar en los contratos 
Creación de diagramas adicionales para mostrar la propiedad y gestión de los
sistemas 

Esta ampliación se debe utilizar en las siguientes situaciones:     Cuando una

organización está considerando cambios de TI que se traducirá en un impacto
significativo en los modelos de gobernanza operacionales existentes  Cuando una
organización tiene requisitos granulares para los niveles de servicio que difieren
de un servicio a otro  Cuando una organización está tratando de transformar su
práctica de gobierno operativa  Cuando una organización tiene muy fuerte enfoque en
los impulsores del negocio, las metas y objetivos y cómo se traza en los niveles de
servicio 

Los beneficios de usar esta extensión son los siguientes:  Los niveles de servicio
se definen de una manera más estructurada, con:  o o o  Más detalles  La capacidad
de reutilizar los perfiles de servicio a través de contratos  Más fuerte rastreo de
objetivos de negocio 

Impactos a las operaciones y modelos de gobernanza operacionales se consideran de

una manera más estructurada, con:  o o Diagramas adicionales del sistema y los
datos de propiedad  Diagramas adicionales de funcionamiento del sistema y las
dependencias en los procesos de operaciones 

  Página 349 de 670 

TOGOF 9.1    
Además de las extensiones descritas aquí, las organizaciones que deseen centrarse
en la gobernanza arquitectura también deben consultar:   El marco COBIT para la
gobernanza de TI proporcionados por los Sistemas de Información de Auditoría y
Control Association (ISACA); consulte www.isaca.org  El Fondo para el IT Portfolio
Management (ITPMF) del OMG; consulte www.omg.org / spec / ITPMF 

Cambios necesarios en el Metamodel

Los cambios en las entidades metamodelo y relaciones se muestran en la Figura 34-11

.
  Figura 34‐11: Extensiones de Gobierno: Cambios en Metamodel 
Los cambios en las entidades metamodelo y relaciones son las siguientes:

  Página 350 de 670 

TOGOF 9.1    
   Medida se añade como una nueva entidad que une objetiva y servicio de
negocio.  Calidad de servicio se añade como una nueva entidad que ofrece un
servicio de plantilla de perfil genérico que se aplica a los servicios
empresariales o contratos.  Contrato se añade como una nueva entidad que formaliza
las características funcionales y no funcionales de una interacción de servicio con
otros servicios, aplicaciones externas, o los usuarios. 

Los cambios en los atributos metamodelo son los siguientes:  Los atributos se
añaden a las nuevas entidades metamodelo de Medida, Calidad de Servicio y Contrato
de Servicios 

Diagramas adicionales que se creen son los siguientes:  Diagrama de administración

de Enterprise 

34.4.2 Servicios Extensiones

Propósito

La extensión de los servicios tiene por objeto permitir más sofisticado modelado de
la cartera de servicios mediante la creación de un concepto de los servicios es,
además del concepto básico de servicios de oficina. SE servicios están soportados
directamente por las aplicaciones y la creación de la capa de abstracción relaja
las restricciones en los servicios empresariales al tiempo que permite a la vez
actores técnicos que ponen más formalidad en un catálogo de servicios de SI. El
alcance de esta extensión es como sigue:  Creación de servicios de SI como una
extensión del servicio de negocio 

Esta ampliación se debe utilizar en las siguientes situaciones:    Cuando la

empresa tiene una definición preestablecida de sus servicios que no se alinea así
con las necesidades técnicas y arquitectónicas  Cuando el negocio y TI utilizan un
lenguaje diferente para describir capacidades similares  Cuando el servicio de TI
está desalineado con necesidad de negocio, especialmente en torno a las áreas de
calidad de servicio, la visibilidad del rendimiento y granularidad de gestión 
¿Dónde está tomando las primeras medidas para la participación del comercio en los
debates sobre la arquitectura de TI 

Los beneficios de usar esta extensión son los siguientes:  Servicios de negocios
se pueden definir fuera de las limitaciones que existen en el metamodelo básico.
Esto permite una participación más natural con accionistas de la empresa. 

  Página 351 de 670 

TOGOF 9.1    
 Servicios de SI pueden ser definidos de acuerdo a un modelo que correlaciona
estrechamente con la aplicación, proporcionando una abstracción solución más
realista para dar soporte a la toma de decisiones.  Relaciones de servicios de
negocios y es muestran donde la vista de negocios se alinea con la vista y donde
hay desajustes. 


Además de las extensiones descritas aquí, las organizaciones que deseen centrarse
en arquitecturas de servicios centrada también deben consultar:   El Service
Component Architecture (SCA) especificación desarrollada por la Arquitectura
Orientada a Servicios Abiertos colaboración (OSOA); consulte www.oasis-
opencsa.org/sca  Los Service Data Objects (SDO) de la especificación desarrollada
por la Arquitectura Orientada a Servicios Abiertos colaboración (OSOA); consulte
www.oasisopencsa.org/sdo 

Cambios necesarios en el Metamodel

Los cambios en las entidades metamodelo y relaciones se muestran en la Figura 34-12

.

  Figura 34‐12: Servicios de Extensión: Los cambios en Metamodel 
Los cambios en las entidades metamodelo y relaciones son las siguientes:

  Página 352 de 670 

TOGOF 9.1    
   Es el servicio se añade como una nueva entidad metamodelo, extender el
servicio de negocio.  ES Servicio hereda todas las relaciones de un servicio de
negocio.  Se crea una nueva relación que conecte a un servicio es un servicio de
negocio. 

Los cambios en los atributos metamodelo son los siguientes:  Es el servicio se

añade como un nuevo tipo de servicio de negocio. 

Diagramas adicionales que se creen son los siguientes:   Diagrama de negocios de

casos de uso  Organización Descomposición Diagrama 

34.4.3 Extensiones de modelado de procesos

Propósito

La extensión de modelado de procesos tiene por objeto permitir el modelado

detallado de los flujos de procesos mediante la adición de eventos, productos y
controles para el metamodelo. Típicamente, arquitectura de la empresa no perforar
en el flujo de proceso, pero en ciertas organizaciones proceso-céntrica o-centrado
de eventos puede ser necesario para la elaboración de proceso de una manera mucho
más formal utilizando este módulo de extensión. El alcance de esta extensión es
como sigue:     Creación de eventos como desencadenantes de procesos  Creación
de controles que la lógica de negocio y de gobierno puertas para la ejecución de
procesos  Creación de productos para representar la salida de un proceso de 
Creación de diagramas de eventos para realizar un seguimiento de los disparadores y
los cambios de estado en toda la organización 

Esta ampliación se debe utilizar en las siguientes situaciones:   Cuando la

arquitectura debe prestar especial atención a estado y eventos  Cuando se requiera
la arquitectura para identificar de manera explícita y medidas de control de
proceso de almacenamiento; por ejemplo, para apoyar el cumplimiento regulatorio 
Cuando la arquitectura cuenta con críticos o fluye elaborado proceso 

Los beneficios de usar esta extensión son los siguientes:

  Página 353 de 670 
TOGOF 9.1    
   Esta extensión permite el modelado de procesos detallado y la catalogación de
los artefactos de proceso.  Puede ser utilizado para apoyar las actividades de
cumplimiento normativo.  Se puede utilizar para volver a propósito de la herencia o
el análisis de descomposición de procesos no-arquitectónico. 

Además de las extensiones descritas aquí, las organizaciones que deseen centrarse
en arquitecturas basadas en procesos también deben consultar:   El Business
Process Modeling Notation (BPMN) especificación, proporcionada por el OMG; consulte
www.bpmn.org  El Proceso de Ingeniería de Software Metamodel (SPEM) especificación,
proporcionada por el OMG; consulte www.omg.org / Spec / SPEM 

Cambios necesarios en el Metamodel

Los cambios en las entidades metamodelo y relaciones se muestran en la Figura 34-13

.

  Figura 34‐13: Proceso Extensiones Modelado: Cambios en Metamodel 
Los cambios en las entidades metamodelo y relaciones son las siguientes:

  Página 354 de 670 

TOGOF 9.1    
   Evento se añade como una entidad metamodelo, sentado entre Actor, proceso y
servicio  El control se agrega como una entidad metamodelo, relativa a un proceso. 
El producto se añade como una entidad metamodelo, vinculando Organización y
Procesos. 

Los cambios en los atributos metamodelo son los siguientes:  Los atributos se
añaden a las nuevas entidades metamodelo de eventos, control y del producto. 

Diagramas adicionales que se creen son los siguientes:  Diagramas de flujo del
proceso, que muestran la forma en que las funciones de negocios, eventos, controles
y productos están relacionados con apoyar un escenario de negocios en particular 
Diagramas de eventos, mostrando los acontecimientos, se que se reciben, y qué
procesos se desencadenan 

34.4.4 de Extensiones
Propósito

La extensión de datos está destinado a permitir el modelado más sofisticado y la

encapsulación de datos. El modelo básico ofrece un concepto de entidad de datos que
soporta la creación de modelos de datos, que se extendió luego por esta extensión
para incluir el concepto de un componente de datos. Los componentes de datos forman
un encapsulamiento lógica o física de las entidades de datos abstractos en unidades
que pueden ser gobernados y desplegados en las aplicaciones. El alcance de esta
extensión es como sigue:   Creación de componentes de datos lógicos que las
entidades de datos de grupo en módulos encapsulados con fines de gobernabilidad,
seguridad y despliegue  Creación de componentes físicos de datos que implementan
los componentes de datos lógicos y son análogas a las bases de datos, registros,
depósitos, esquemas y otras técnicas de segmentación de datos  Creación del ciclo
de vida de los datos, seguridad de datos y diagramas de migración de datos de la
arquitectura para mostrar las preocupaciones de datos con más detalle 


Esta ampliación se debe utilizar en las siguientes situaciones:  Cuando la
arquitectura cuenta con complejidad y riesgo significativo en torno a la ubicación,
la encapsulación, y la gestión o el acceso a los datos 

Los beneficios de usar esta extensión son los siguientes:

  Página 355 de 670 

TOGOF 9.1    
 La estructura de los datos se modela independientemente de su ubicación, lo que
permite modelos de datos que deben desarrollarse que abarcan múltiples sistemas sin
estar atado a las preocupaciones físicas.  Agrupaciones lógicas de datos pueden ser
utilizados para establecer la gobernabilidad, la seguridad, o límites de despliegue
alrededor de los datos, proporcionando una apreciación mucho más holística de los
problemas de datos en torno a la arquitectura. 

Cambios necesarios en el Metamodel

Los cambios en las entidades metamodelo y relaciones se muestran en la Figura 34-14

.

  Figura 34‐14: Extensiones de datos: Los cambios en Metamodel 
Los cambios en las entidades metamodelo y relaciones son las siguientes:   
Componente lógica de datos se agrega como una nueva entidad metamodelo,
encapsulando las entidades de datos.  Componente Físico de Datos se añade como una
nueva entidad metamodelo, que se extiende de componentes lógica de datos.  Se crea
una relación entre el Componente Físico de Datos y componente de aplicación. Si se
aplica la extensión de consolidación de la infraestructura, esta debe ser física
componente de aplicación.  Si se aplica la extensión de consolidación de la
infraestructura, componentes de datos física tendrá una relación con Location. 

Los cambios en los atributos metamodelo son los siguientes:  Los atributos se
añaden a las nuevas entidades metamodelo de lógica de componentes de datos y
componentes de datos físicos. 

Diagramas adicionales que se creen son los siguientes:

  Página 356 de 670 

TOGOF 9.1    
   Diagrama de seguridad de datos  Diagrama de migración de datos  Diagrama del
ciclo de vida de datos 

34.4.5 Extensiones de Consolidación de Infraestructura

Propósito

La extensión de la consolidación de la infraestructura está destinado a ser

utilizado en los paisajes donde las aplicaciones y tecnología carteras hayan
fragmentado y la arquitectura busca consolidar el negocio como de costumbre en la
capacidad de un menor número de ubicaciones, aplicaciones o componentes de
tecnología. El alcance de esta extensión es como sigue:     La creación de una
entidad de ubicación para mantener la ubicación de los activos de TI y consumidores
externos de servicio  Creación de componentes de la aplicación lógica y física para
abstraer la capacidad de una aplicación fuera de las aplicaciones reales de
existencia  Creación de componentes de la aplicación lógica y física a Tipo de
producto abstracto de los productos de tecnología de reales en existencia  Creación
de diagramas adicionales centrados en la ubicación de los activos, cumplimiento de
las normas, la estructura de las aplicaciones, migración de la aplicación, y
configuración de la infraestructura 

Esta ampliación se debe utilizar en las siguientes situaciones:      Donde

muchos productos tecnológicos están en su lugar con el duplicado o la capacidad de
superposición  Donde muchas aplicaciones están en su lugar, con duplicado o
funcionalidad de superposición  Cuando las solicitudes están geográficamente
dispersos y la lógica de decisión para determinar la ubicación de una aplicación no
se conoce bien  Cuando las aplicaciones se van a migrar a una plataforma
consolidada  Cuando las funciones de aplicación van a migrar en una aplicación
consolidada 

Los beneficios de usar esta extensión son los siguientes:   Permite la

visibilidad y análisis de la duplicación redundante de la capacidad en los ámbitos
de aplicación y tecnología  Soporta análisis del cumplimiento de las normas 

  Página 357 de 670 

TOGOF 9.1    
  Soporta el análisis del impacto de la migración de aplicaciones o tecnología
consolidación  Soporta definición arquitectónica detallada de la estructura de la
aplicación 

Además de las extensiones descritas aquí, las organizaciones que deseen centrarse
en la consolidación de la infraestructura deben también consultar:   El Lenguaje
de Modelado Unificado (UML), proporcionado por el OMG; consulte www.uml.org  El
Sistemas de Lenguaje de Modelado (SysML) - www.sysml.org - que reduce la
complejidad y el software de enfoque de ingeniería de UML para los propósitos de
modelado de sistemas  El Fondo para el IT Portfolio Management (ITPMF) del OMG;
consulte www.omg.org / spec / ITPMF 

Cambios necesarios en el Metamodel

Los cambios en las entidades metamodelo y relaciones se muestran en la Figura 34-15

.

  Figura 34‐15: Infraestructura Extensiones de consolidación: Cambios en Metamodel 
Los cambios en las entidades metamodelo y relaciones son las siguientes: 
Ubicación atributos de Organización, Actor, componente de aplicación, el componente
de datos y componentes de Tecnología se han mejorado para crear una entidad de la
ubicación dentro del metamodelo.  Componentes de aplicación se amplían para incluir
Lógico componentes de aplicación (una clase de aplicación) y Física componentes de
aplicación (una aplicación real).  Componentes tecnológicos se amplían para incluir
componentes lógicos Tecnología (una clase de producto de tecnología) y componentes
Tecnología Físicas (un producto de la tecnología actual). 

 

  Página 358 de 670 
TOGOF 9.1    
Los cambios en los atributos metamodelo son los siguientes:  Creación de atributos
para las nuevas entidades Metamodel de Logical componente de aplicación, Física
componente de aplicación, lógica Componente Tecnología, Tecnología del componente
físico y Ubicación  La eliminación de ubicación como un atributo de las entidades
que tienen un lugar y su sustitución por una relación con la entidad Ubicación 

Diagramas adicionales que se creen son los siguientes:        Diagrama

Realización de proceso / aplicación  Software diagrama de Ingeniería  Diagrama de
Migración de aplicaciones  Diagrama de distribución de software  Diagrama de
Procesamiento  Diagrama de Red Informática / Hardware  Ingeniería de Comunicaciones
diagrama 

34.4.6 Extensiones Motivación

Propósito

La extensión de la motivación tiene por objeto permitir la modelización

estructurada adicional de los controladores, las metas y objetivos que influyen en
una organización para proporcionar servicios de negocio a sus clientes. Esto a su
vez permite la definición más efectiva de los contratos de servicios y una mejor
medición de los resultados empresariales. El alcance de esta extensión es como
sigue:     Creación de una nueva entidad metamodelo para el conductor que
muestra los factores que motivan o limitan generalmente a una organización 
Creación de una nueva entidad metamodelo para el objetivo que muestra el propósito
estratégico y la misión de una organización  Creación de una nueva entidad
metamodelo para el objetivo que se muestra cerca de los logros a mediano plazo que
una organización desea alcanzar  Creación de un diagrama de Meta / Objetivo /
servicio que muestra la trazabilidad de los conductores, las metas y objetivos a
través de los servicios 

Esta ampliación se debe utilizar en las siguientes situaciones:

  Página 359 de 670 

TOGOF 9.1    
 Cuando la arquitectura tiene que entender la motivación de las organizaciones con
más detalle que los principios de negocios o de compromiso de estándares y
objetivos que se modelan de manera informal dentro del metamodelo contenido básico 
Cuando las organizaciones tienen los conductores y los objetivos en conflicto y que
el conflicto tiene que ser entendido y tratado en una forma estructurada  Cuando
los niveles de servicio son desconocidos o poco clara 

 

Los beneficios de usar esta extensión son los siguientes:  Destacados

desalineación de las prioridades de toda la empresa y cómo éstas se cruzan con los
servicios compartidos (por ejemplo, algunas organizaciones pueden estar tratando de
reducir los costos, mientras que otros están tratando de aumentar la capacidad) 
Muestra la demanda de servicios empresariales que compiten de manera más
estructurada, permitiendo niveles de servicio de compromiso para definir 

Además de las extensiones descritas aquí, las organizaciones que deseen centrarse
en la arquitectura de modelado de motivación empresarial, también deben consultar:
 El Modelo Motivación Negocio (BMM) especificación, proporcionada por el OMG;
consulte www.omg.org / tecnología / documents / bms_spec_catalog.htm 

Cambios necesarios en el Metamodel

Los cambios en las entidades metamodelo y relaciones se muestran en la Figura 34-16

.

  Página 360 de 670 

TOGOF 9.1    

  Extensiones de motivación: Figura 34‐16 Cambios en Metamodel 
Los cambios en las entidades metamodelo y relaciones son las siguientes: 
Conductor, Meta y Objetivo se agregan como nuevas entidades que enlazan Unidad de
Organización de Servicios de Negocio. 

Los cambios en los atributos metamodelo son los siguientes:  Los atributos se
añaden a las nuevas entidades metamodelo de Conductor, Meta y Objetivo. 

Diagramas adicionales que se creen son los siguientes:  Meta / Objetivo diagrama /
Servicio 

    Página 361 de 670 

TOGOF 9.1    

34.5 Contenido Entidades Metamodel

La siguiente tabla muestra y describe las entidades dentro del metamodelo
contenido.
Metamodel Entidad Actor Descripción

Una persona, organización o sistema que tiene un papel que inicia o interactúa con
las actividades; por ejemplo, un representante de ventas que viaja a visitar a los
clientes. Los actores pueden ser internos o externos a la organización. En la
industria automotriz, un fabricante de equipo original se considera un actor por un
concesionario de automóviles que interactúa con sus actividades de la cadena de
suministro. Componente de Una encapsulación de funcionalidad de la aplicación
alineado con aplicación estructura de ejecución. Por ejemplo, una aplicación de
procesamiento de solicitud de compra. Ver también lógico componente de aplicación y
Física componente de aplicación . Una declaración de un hecho probable de que no ha
sido plenamente validado en esta etapa, debido a las restricciones externas. Por
ejemplo, se puede suponer que una aplicación existente apoyará un cierto conjunto
de requisitos funcionales, sin que tal exigencia aún no hayan sido validados de
forma individual. Soporta capacidades de negocio a través de una interfaz definida
explícitamente y se rige explícitamente por una organización. Un resultado centrado
en las empresas que se entrega por la realización de uno o más paquetes de trabajo.
El uso de un enfoque de planificación basado en las capacidades, las actividades de
cambio pueden ser secuenciados y se agrupan con el fin de proporcionar un valor
empresarial continuo e incremental. Un factor externo que impide que una
organización de la búsqueda de enfoques particulares para cumplir sus objetivos.
Por ejemplo, los datos del cliente no está armonizada dentro de la organización,
regional o nacional, lo que limita la capacidad de la organización para ofrecer un
servicio al cliente eficaz. Un acuerdo entre un consumidor de servicios y un
proveedor de servicios que establece los parámetros funcionales y no funcionales
para la interacción. Un paso de toma de decisiones con el acompañamiento de la
lógica de decisión utilizado para determinar el enfoque de ejecución de un proceso
o para asegurar que un proceso cumple con los criterios de gobierno. Por ejemplo,
un control de cierre de sesión en el proceso de tramitación de solicitud de compra
que comprueba si el valor total de la solicitud está dentro de los límites de
sesión fuera de la solicitante, o si necesita una escalada a la autoridad superior.
Una encapsulación de datos que es reconocido por un experto de dominio de negocios
como una cosa. Entidades de datos lógicos pueden estar vinculados a las
aplicaciones, repositorios y servicios y pueden ser estructurados de acuerdo con
las consideraciones de implementación. Una condición externa o interna que motiva a
la organización a definir sus metas. Un ejemplo de un controlador externo es un
cambio en la reglamentación o normas de cumplimiento que, por ejemplo, requieren
cambios en la forma en que una organización opera; es decir, la Ley Sarbanes-Oxley
en los EE.UU.. Un cambio de estado de la organización que desencadena eventos de
procesamiento; puede provenir de dentro o fuera de la organización y

Asunción

Servicios de Negocio Capacidad

Restricción

Contrato

Control

Entity Data

Conductor

Evento

  Página 362 de 670 

TOGOF 9.1    
Función puede ser resuelto dentro o fuera de la organización. Proporciona
capacidades de negocio estrechamente alineadas a una organización, pero no
necesariamente gobernadas de forma explícita por la organización. También se conoce
como "función empresarial". Una declaración de la diferencia entre los dos estados.
Se utiliza en el contexto de análisis de las carencias, donde se identifica la
diferencia entre la línea de base y Arquitectura Target.

Brecha

Nota:  El análisis de brechas se describe en la Parte III , 27.Análisis Gap . 

Una declaración de alto nivel de la intención o la dirección de una organización.
Normalmente se utiliza para medir el éxito de una organización. Sistema de Los
elementos automáticos de un servicio empresarial. Un servicio del Información de
sistema de información puede ofrecer o apoyar la totalidad o parte de uno Servicio
o varios servicios de oficina. Ubicación Un lugar donde la actividad empresarial se
lleva a cabo y se puede descomponer jerárquicamente. Lógico Una encapsulación de
funcionalidad de la aplicación que es independiente Aplicación de una
implementación particular. Por ejemplo, la clasificación de todas Componente las
aplicaciones de procesamiento de solicitud de compra implementados en una empresa.
Lógica de datos Una zona de frontera que encapsula las entidades de datos
relacionados de componentes para formar una ubicación lógica que se realizará; por
ejemplo, la información de aprovisionamiento externo. Lógico Una encapsulación de
la infraestructura de tecnología que es Tecnología independiente de un producto en
particular. Una clase de producto de la Componente tecnología; por ejemplo, el
software de gestión de la cadena de suministro, como parte de un paquete de
planificación de recursos empresariales (ERP), o un servicio de la empresa de
procesamiento de solicitud de compra Commercial Off-The-Shelf (COTS). Medida Un
indicador o factor que se puede controlar, por lo general en forma permanente, para
determinar el éxito o el alineamiento con los objetivos y metas. Objetivo Un hito
de tiempo limitado para que una organización utiliza para demostrar el progreso
hacia una meta; por ejemplo, "Aumentar la utilización de la capacidad en un 30% a
finales de 2009 para apoyar el aumento previsto de la cuota de mercado". Unidad de
Una unidad autónoma de los recursos con metas, objetivos y Organización
medidas.Unidades organizativas pueden incluir partes externas y las organizaciones
asociadas de negocios. Física Una aplicación, módulo de aplicación, servicios de
aplicaciones, u otro componente de despliegue de la funcionalidad. Por ejemplo, una
instancia Aplicación de componentes de una planificación de recursos empresariales
(ERP) de suministro Comercial Off-The-Shelf (COTS) configurado y desplegado la
aplicación de gestión de la cadena. Datos físicos Una zona de frontera que
encapsula las entidades de datos relacionados de componentes para formar un lugar
físico que se celebrará. Por ejemplo, un objeto de negocio de la orden de compra,
que comprende encabezado de la orden de compra y nodos de objetos de negocios
artículo. Tecnología Un producto de infraestructura de tecnología o la tecnología
instancia de Física producto infraestructura. Por ejemplo, un determinado modelo de
una Componente solución comercial Off-The-Shelf (COTS), o de una marca específica y
la versión del servidor. Meta

  Página 363 de 670 

TOGOF 9.1    
Plataforma de Servicios Principio Una capacidad técnica que se requiere para
proporcionar la infraestructura que permite que apoya la entrega de aplicaciones.
Una declaración de intenciones cualitativo que debe ser satisfecha por la
arquitectura. Tiene al menos un sustento racional y una medida de importancia.

Nota:  Un conjunto de muestras de principios de arquitectura se define en la Parte

III , 23. Arquitectura Principios . 
Proceso Un proceso representa flujo de control entre o dentro de las funciones y /
o servicios (depende de la granularidad de la definición). Los procesos representan
una secuencia de actividades que en conjunto logran un resultado determinado, puede
descomponerse en sub-procesos, y pueden mostrar el funcionamiento de una función o
servicio (en el siguiente nivel de detalle). Los procesos también pueden ser
utilizados para conectar o componer organizaciones, funciones, servicios y
procesos. La salida generada por el negocio. El producto de negocios de la
ejecución de un proceso. Una declaración cuantitativa de las necesidades de negocio
que debe ser cumplida por una arquitectura o paquete de trabajo en particular. La
función habitual o esperado de un actor, o la parte que alguien o algo juega en una
acción o evento en particular. Un actor puede tener una serie de funciones. Ver
también Actor . Un elemento de comportamiento que proporciona una funcionalidad
específica en respuesta a las peticiones de los actores o otros servicios.Un
servicio de entrega o apoya las capacidades de negocio, tiene una interfaz definida
explícitamente, y se rige de forma explícita. Los servicios se definen para los
negocios, los sistemas de información y plataformas. Una configuración
preestablecida de atributos no funcionales que pueden ser asignadas a un servicio o
contrato de servicio. Una encapsulación de infraestructura tecnológica que
representa una clase de producto de la tecnología o producto de tecnología
específica. Un conjunto de acciones identificadas para alcanzar uno o más objetivos
para el negocio. Un paquete de trabajo puede ser una parte de un proyecto, un
proyecto completo, o un programa.

Producto Requisito Papel

Servicio
Calidad de Servicio Componente Tecnología Paquete de Trabajo

34.6 Contenido Atributos Metamodel

La siguiente tabla muestra los atributos típicos para cada una de las entidades
metamodelo descritos anteriormente.

 
Metamodel Descripción Entidad Atributo Todas las Identificación Entidades

Identificador único para la entidad la arquitectura

  Página 364 de 670 

TOGOF 9.1    
Metamodel Nombre Descripción Categoría Fuente Propietario El valor del negocio
Incrementos Restricción Brecha Ubicación No hay atributos adicionales No hay
atributos adicionales Categoría Breve nombre de la entidad arquitectura Descripción
textual de la entidad arquitectura. Taxonomía de categorización definible por el
usuario para cada entidad metamodelo. Lugar desde donde se obtuvo la información.
Propietario de la entidad arquitectura. Describe cómo esta capacidad proporciona
valor a la empresa. Enumera los posibles niveles de madurez / calidad para la
capacidad. Esta entidad metamodelo sólo tiene atributos básicos. Esta entidad
metamodelo sólo tiene atributos básicos.

Capacidad

Principio

Requisito

Actor

Servicios de Negocio

Las siguientes categorías de ubicación aplican: Región (se aplica a un grupo de

países o territorio, por ejemplo, el sudeste de Asia, Reino Unido e Irlanda), País
(se aplica a un solo país, por ejemplo, EE.UU.), Construcción (se aplica a un sitio
de operación, donde se recogen varias oficinas en una sola ciudad, esta categoría
puede representar una ciudad), y la ubicación específica (se aplica a cualquier
ubicación específica dentro de un edificio, como una sala de servidores). La
naturaleza de la empresa puede introducir otras ubicaciones: Nave o puerto para una
compañía de ferry, Minas para una compañía de oro, coches de policía, el Hotel para
los trabajadores que viajan de cualquier empresa, y así sucesivamente. Categoría
Las siguientes categorías de principios se aplican: Principio Rector, Principio de
negocio, el Principio de datos, el principio de aplicación, el principio de
integración, Tecnología Principio. Prioridad Prioridad de este principio en
relación con otros principios. Declaración de principios Declaración de lo que el
principio es. Razón fundamental Declaración de por qué es necesario el principio y
el resultado a alcanzar. Implicación Declaración de lo que significa el principio
en términos prácticos. Métrico Identifica los mecanismos que se utilizarán para
medir si el principio se ha cumplido o no. Norma de exigencia Declaración de lo que
el requisito es, incluyendo una definición de si se cumple el requisito, debe
cumplirse, o puede cumplirse. Razón fundamental Declaración de por qué existe el
requisito. Los criterios de aceptación Declaración de qué pruebas se llevarán a
cabo para garantizar que se cumpla el requisito. # ETC Número estimado de FTE que
operan como este actor. Objetivo Actor Los objetivos que este actor tiene, en
términos generales. Tareas Actor Las tareas que realiza este actor, en términos
generales. Clase de Normas No estándar, de Norma, Norma Provisional, Standard,
phasing-out estándar, Jubilado estándar.

  Página 365 de 670 

TOGOF 9.1    
Fecha de creación del estándar Última fecha de revisión estándar La próxima fecha
de revisión estándar Fecha de jubilarse Características de comportamiento Nombre
del servicio "el que llama" Nombre del servicio "llama" Características de calidad
de servicio Características Disponibilidad Los tiempos de servicio Características
de manejabilidad Características Facilidad de servicio Características de
rendimiento Requisitos de respuesta Características de confiabilidad Calidad de la
información requerida Requisitos de control de Contrato Los requisitos de control
de resultados Si el producto es un estándar, cuando se creó la norma. Última fecha
en que la norma fue revisada. La próxima fecha para que la norma sea revisada.
Fecha en la que la norma se será retirado /. Comportamiento funcional para ser
soportado dentro del alcance del contrato. El consumo de servicios. Proporcionar
servicio. El comportamiento no funcional para el apoyo en el ámbito del contrato.
Grado en que algo está disponible para su uso. Horas en las que el servicio debe
estar disponible. Capacidad de recopilar información sobre el estado de algo y
controlarlo. Capacidad para identificar problemas y tomar medidas correctivas,
tales como reparar o actualizar un componente en un sistema en funcionamiento.
Capacidad de un componente para realizar sus tareas en un tiempo apropiado. Los
tiempos de respuesta que el proveedor de servicios debe cumplir para operaciones
particulares. Resistencia al fracaso.

Contrato

Requisitos contratados sobre la exactitud e integridad de la información. Nivel de

gobierno y aplicación de aplicarse a los parámetros contractuales para el servicio
en general. Las medidas previstas para asegurar que cada solicitud de servicio
cumple con los criterios contratados. Características Capacidad para restaurar un
sistema a un estado de Recuperabilidad trabajo después de una interrupción.
Características estado de Capacidad de un sistema que se encuentran cuando
localización sea necesario. Características de Capacidad de un sistema para evitar
el acceso no seguridad autorizado a las funciones y datos. Características
Privacidad Protección de datos de accesos no autorizados. Características de
Capacidad de un sistema para asegurar que los datos integridad no se ha dañado.
Características de Capacidad de un sistema para asegurar que la credibilidad
solicitud de servicio se origina de una fuente autorizada. Características de
Capacidad de un servicio para apoyar las variantes localización localizadas para
diferentes grupos de consumidores. Características de Capacidad de un servicio para
soportar las internacionalización variaciones internacionales en la lógica
empresarial y la representación de datos (como conjunto de caracteres).
Características de La capacidad del servicio para interactuar con interoperabilidad
diferentes entornos técnicos, dentro y fuera de la organización.

  Página 366 de 670 

TOGOF 9.1    
Características de escalabilidad Capacidad del servicio para aumentar o reducir su
rendimiento o capacidad adecuada a las exigencias del entorno en el que opera.
Portabilidad características De datos, personas, aplicaciones y componentes.
Características de Capacidad para aceptar la nueva funcionalidad. extensibilidad
Características de Capacidad contratada del proveedor de servicios para capacidad
atender las solicitudes. Rendimiento Capacidad de producción requerida. Período de
rendimiento El periodo de tiempo necesario para entregar la capacidad de
rendimiento. Crecimiento Tasa de crecimiento futuro esperado de solicitud de
servicio. Período de crecimiento El periodo de tiempo necesario para alcanzar la
tasa de crecimiento esperada. Perfil pico a corto plazo Perfil de corto plazo del
tráfico de las horas pico. Perfil pico largo plazo Perfil a largo plazo del tráfico
de las horas pico. No hay atributos Esta entidad metamodelo sólo tiene atributos
básicos. adicionales No hay atributos Esta entidad metamodelo sólo tiene atributos
básicos. adicionales No hay atributos Esta entidad metamodelo sólo tiene atributos
básicos. adicionales Clase de Normas No estándar, de Norma, Norma Provisional,
Standard, phasing-out estándar, Jubilado estándar. Fecha de creación del Si el
producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión
Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima
fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en
la que la norma se será retirado /. No hay atributos Esta entidad metamodelo sólo
tiene atributos básicos. adicionales No hay atributos Esta entidad metamodelo sólo
tiene atributos básicos. adicionales No hay atributos Esta entidad metamodelo sólo
tiene atributos básicos. adicionales Número de empleados Número de FTE que trabajan
dentro de la organización. Clase de Normas No estándar, de Norma, Norma
Provisional, Standard, phasing-out estándar, Jubilado estándar. Fecha de creación
del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha
de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de
La próxima fecha para que la norma sea revisada. revisión estándar Fecha de
jubilarse Fecha en la que la norma se será retirado /. Criticidad del proceso La
criticidad de este proceso para las operaciones comerciales. Manuales o
automáticas, Si este proceso es apoyado por IT o es un proceso manual. Volumetría
Proceso Los datos sobre la frecuencia de ejecución de procesos. No hay atributos
Esta entidad metamodelo sólo tiene atributos básicos.

Control Conductor Evento Función

Meta Medida Objetivo Unidad de Organización Proceso

Producto

  Página 367 de 670 

TOGOF 9.1    
adicionales Número estimado de FTE Esta entidad metamodelo sólo tiene atributos
básicos. que operan en este Rol Calidad de No hay atributos Esta entidad metamodelo
sólo tiene atributos básicos. Servicio adicionales Servicio Clase de Normas No
estándar, de Norma, Norma Provisional, Standard, phasing-out estándar, Jubilado
estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la
estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada.
estándar La próxima fecha de La próxima fecha para que la norma sea revisada.
revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /.
Componente de Clase de Normas No estándar, de Norma, Norma Provisional, Standard,
aplicación phasing-out estándar, Jubilado estándar. Fecha de creación del Si el
producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión
Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima
fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en
la que la norma se será retirado /. Sistema de Clase de Normas No estándar, de
Norma, Norma Provisional, Standard, Información de phasing-out estándar, Jubilado
estándar. Servicio Fecha de creación del Si el producto es un estándar, cuando se
creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue
revisada. estándar La próxima fecha de La próxima fecha para que la norma sea
revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será
retirado /. Lógico Aplicación Clase de Normas No estándar, de Norma, Norma
Provisional, Standard, Componente phasing-out estándar, Jubilado estándar. Fecha de
creación del Si el producto es un estándar, cuando se creó la estándar norma.
Última fecha de revisión Última fecha en que la norma fue revisada. estándar La
próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar
Fecha de jubilarse Fecha en la que la norma se será retirado /. Física Aplicación
El estado del ciclo de vida Propuso en el Desarrollo, en vivo, eliminación de
componentes gradual, jubilado . Clase de Normas No estándar, de Norma, Norma
Provisional, Standard, phasing-out estándar, Jubilado estándar. Fecha de creación
del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha
de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de
La próxima fecha para que la norma sea revisada. revisión estándar Fecha de
jubilarse Fecha en la que la norma se será retirado /. Fecha vivo inicial Fecha en
la que la primera versión de la aplicación fue / será lanzado en la producción.
Fecha de la última versión Fecha en la que la última versión de la aplicación fue
Papel

  Página 368 de 670 

TOGOF 9.1    
Fecha de la próxima versión Fecha de retiro Características Disponibilidad Los
tiempos de servicio Características de manejabilidad Características Facilidad de
servicio Características de rendimiento Características de confiabilidad
Características Recuperabilidad Características estado de localización
Características de seguridad Características Privacidad Características de
integridad Características de credibilidad lanzada en la producción. Fecha en la
que la próxima versión de la aplicación se dará a conocer en producción. Fecha en
la que la solicitud fue / será retirado. Grado en que algo está disponible para su
uso. Horas en las que la aplicación debe estar disponible. Capacidad de recopilar
información sobre el estado de algo y controlarlo. Capacidad para identificar
problemas y tomar medidas correctivas, tales como reparar o actualizar un
componente en un sistema en funcionamiento. Capacidad de un componente para
realizar sus tareas en un tiempo apropiado. Resistencia al fracaso.

Entity Data

Capacidad para restaurar un sistema a un estado de trabajo después de una

interrupción. Capacidad de un sistema que se encuentran cuando sea necesario.
Capacidad de un sistema para evitar el acceso no autorizado a las funciones y
datos. Protección de datos de accesos no autorizados. Capacidad de un sistema para
asegurar que los datos no se ha dañado. Capacidad de un sistema para asegurar que
la solicitud de servicio se origina de una fuente autorizada. Características de
Capacidad de un servicio para apoyar las variantes localización localizadas para
diferentes grupos de consumidores. Características de Capacidad de un servicio para
soportar las internacionalización variaciones internacionales en la lógica
empresarial y la representación de datos (como conjunto de caracteres).
Características de La capacidad del servicio para interactuar con interoperabilidad
diferentes entornos técnicos, dentro y fuera de la organización. Características de
Capacidad del servicio para aumentar o reducir su escalabilidad rendimiento o
capacidad adecuada a las exigencias del entorno en el que opera. Portabilidad
características De datos, personas, aplicaciones y componentes. Características de
Capacidad para aceptar la nueva funcionalidad. extensibilidad Características de
Capacidad contratada del proveedor de servicios para capacidad atender las
solicitudes. Rendimiento Capacidad de producción requerida. Período de rendimiento
El periodo de tiempo necesario para entregar la capacidad de rendimiento.
Crecimiento Tasa de crecimiento futuro esperado de solicitud de servicio. Período
de crecimiento El periodo de tiempo necesario para alcanzar la tasa de crecimiento
esperada. Perfil pico a corto plazo Perfil de corto plazo del tráfico de las horas
pico. Perfil pico largo plazo Perfil a largo plazo del tráfico de las horas pico.
Categoría Las siguientes categorías de entidad de datos se aplican: Mensaje,
internamente almacenados Entidad.
  Página 369 de 670 

TOGOF 9.1    
Clasificación de Privacidad Nivel de restricción puesta sobre el acceso a los
datos. Clasificación de Retención Duración de la retención que se colocará en los
datos. Lógica de datos Clase de Normas No estándar, de Norma, Norma Provisional,
Standard, de componentes phasing-out estándar, Jubilado estándar. Fecha de creación
del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha
de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de
La próxima fecha para que la norma sea revisada. revisión estándar Fecha de
jubilarse Fecha en la que la norma se será retirado /. Datos físicos Clase de
Normas No estándar, de Norma, Norma Provisional, Standard, de componentes phasing-
out estándar, Jubilado estándar. Fecha de creación del Si el producto es un
estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha
en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para
que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la
norma se será retirado /. Lógico Clase de Normas No estándar, de Norma, Norma
Provisional, Standard, Tecnología phasing-out estándar, Jubilado estándar.
Componente Fecha de creación del Si el producto es un estándar, cuando se creó la
estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada.
estándar La próxima fecha de La próxima fecha para que la norma sea revisada.
revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /.
Categoría Componentes tecnológicos lógicos se clasifican de acuerdo a la TOGAF TRM,
que podrá ampliarse para satisfacer las necesidades de una organización individual.
Tecnología Clase de Normas No estándar, de Norma, Norma Provisional, Standard,
Física phasing-out estándar, Jubilado estándar. Componente Fecha de creación del Si
el producto es un estándar, cuando se creó la estándar norma. Última fecha de
revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La
próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse
Fecha en la que la norma se será retirado /. Categoría Componentes tecnológicos
físicas se clasifican de acuerdo con el TOGAF TRM, que podrá ampliarse para
satisfacer las necesidades de una organización individual. Nombre del producto
Nombre del producto que constituyen el componente de tecnología. Nombre del módulo
Módulo u otro sub-producto, el nombre que constituyen el componente de tecnología.
Vendedor Vendor proporcionar el componente de tecnología. Versión Versión del
producto que constituyen el componente de tecnología.

  Página 370 de 670 

TOGOF 9.1    
Plataforma de Servicios Clase de Normas Categoría No estándar, de Norma, Norma
Provisional, Standard, phasing-out estándar, Jubilado estándar. Servicios de la
Plataforma se clasifican de acuerdo con el TOGAF TRM, que podrá ampliarse para
satisfacer las necesidades de una organización individual. No estándar, de Norma,
Norma Provisional, Standard, phasing-out estándar, Jubilado estándar. Las
siguientes categorías de paquete de trabajo se aplican: Paquete de Trabajo, Arroyo
trabajo, proyecto, programa, Portfolio . Describe la contribución de este paquete
de trabajo hace a la entrega de capacidades.

Componente Tecnología Paquete de Trabajo

Clase de Normas Categoría

Capacidad de entrega

34.7 Metamodel Relaciones

Entidad Fuente Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor
Capacidad Contrato Contrato Control Entity Data Entity Data Entity Data Entity Data
Entity Data Conductor Conductor Conductor Evento Evento Evento Evento Evento
Función Función Función Función Entidad Target Evento Evento Función Función
Ubicación Unidad de Organización Proceso Papel Servicio Actor Entity Data Paquete
de Trabajo Servicio Calidad de Servicio Proceso Lógico Aplicación Componente Lógica
de datos de componentes Servicio Entity Data Entity Data Meta Unidad de
Organización Conductor Actor Actor Proceso Proceso Servicio Actor Actor Unidad de
Organización Proceso Módulo de extensión Genera Proceso Resuelve Proceso Interactúa
con Núcleo Realiza Núcleo Opera en Infraestructura Consolidación Pertenece a Núcleo
Participa en Núcleo Realiza tareas en Núcleo Consume Núcleo Se descompone Núcleo
Suministros / Consume Núcleo Se entrega por Núcleo Gobierna y Medidas Gobernancia
Cumple Gobernancia Asegura el correcto funcionamiento de Proceso los Es procesado
por Núcleo Reside en Se accede y actualizada a través de Se descompone Se relaciona
con Crea Motiva Se descompone RESUELVE Es generado por RESUELVE Es generado por
RESUELVE Apoyos Se realiza por Es propiedad de Apoyos Datos Núcleo Núcleo Núcleo
Motivación Motivación Motivación Proceso Proceso Proceso Proceso Proceso Núcleo
Núcleo Núcleo Núcleo Nombre

  Página 371 de 670 

TOGOF 9.1    
Función Función Función Función Función Meta Meta Meta Ubicación Ubicación
Ubicación Ubicación Ubicación Ubicación Lógico Aplicación Componente Lógico
Aplicación Componente Lógico Aplicación Componente Lógico Aplicación Componente
Lógico Aplicación Componente Lógica de datos de componentes Lógica de datos de
componentes Lógico Tecnología Componente Lógico Tecnología Componente Lógico
Tecnología Componente Lógico Tecnología Componente Lógico Tecnología Componente
Medida Medida Medida Objetivo Objetivo Objetivo Unidad de Organización Unidad de
Organización Proceso Papel Servicio Función Función Conductor Objetivo Meta Actor
Unidad de Organización Física Aplicación de componentes Componente Físico de Datos
Tecnología Física Componente Ubicación Entity Data Física Aplicación de componentes
Servicio Lógico Aplicación Componente Lógico Aplicación Componente Entity Data
Componente Físico de Datos Tecnología Física Componente Plataforma de Servicios
Servicio Lógico Tecnología Componente Lógico Tecnología Componente Objetivo
Servicio Medida Meta Medida Objetivo Actor Conductor Se realiza por Se puede
acceder por Está delimitada por Se descompone Se comunica con Direcciones Se
realiza a través Se descompone Contiene Contiene Contiene Contiene Contiene Se
descompone Funciona con Está extendida por Implementos Se descompone Se comunica
con Encapsula Está extendida por Está extendida por Suministros Proporciona
plataforma para Se descompone Depende Establece criterios de desempeño para
Establece criterios de desempeño para Se descompone Se da cuenta de Se realiza un
seguimiento en contra Se descompone Contiene Está motivada por Núcleo Núcleo Núcleo
Núcleo Núcleo Motivación Motivación Motivación Infraestructura Consolidación
Infraestructura Consolidación Infraestructura Consolidación Infraestructura
Consolidación Infraestructura Consolidación Infraestructura Consolidación Núcleo
Infraestructura Consolidación Núcleo Núcleo Núcleo Datos Datos Infraestructura
Consolidación Núcleo Núcleo Núcleo Núcleo Gobernancia Gobernancia Gobernancia
Motivación Gobernancia Motivación Núcleo Núcleo

  Página 372 de 670 

TOGOF 9.1    
Unidad de Organización Unidad de Organización Unidad de Organización Unidad de
Organización Unidad de Organización Física Aplicación de componentes Física
Aplicación de componentes Física Aplicación de componentes Física Aplicación de
componentes Física Aplicación de componentes Física Aplicación de componentes Datos
físicos de componentes Datos físicos de componentes Datos físicos de componentes
Datos físicos de componentes Tecnología Física Componente Tecnología Física
Componente Tecnología Física Componente Tecnología Física Componente Tecnología
Física Componente Plataforma de Servicios Proceso Proceso Proceso Proceso Proceso
Proceso Proceso Proceso Proceso Proceso Proceso Producto Producto Papel Función
Ubicación Producto Servicio Unidad de Organización Ubicación Lógico Aplicación
Componente Datos físicos de componentes Tecnología Física Componente Física
Aplicación de componentes Física Aplicación de componentes Ubicación Lógica de
datos de componentes Datos físicos de componentes Física Aplicación de componentes
Ubicación Física Aplicación de componentes Lógico Tecnología Componente Tecnología
Física Componente Tecnología Física Componente Lógico Tecnología Componente Actor
Control Evento Evento Función Función Producto Servicio Servicio Proceso Proceso
Unidad de Organización Proceso Actor Posee Opera en Produce Posee y gobierna Se
descompone Está alojado en Extiende Encapsula Se realiza por Se descompone Se
comunica con Está alojado en Extiende Se descompone Encapsula Está alojado en Se da
cuenta de Extiende Se descompone Depende Se suministra por Involucra Se guía por
Genera Resuelve Orquesta Se descompone Produce Orquesta Se descompone Se descompone
Precede / Follows Es producido por Es producido por Se realiza por Núcleo Núcleo
Núcleo Núcleo Núcleo Infraestructura Consolidación Infraestructura Consolidación
Modelado de Datos Núcleo Núcleo Núcleo Infraestructura Consolidación Datos Núcleo
Modelado de Datos Consolidación de Infraestructura Núcleo Infraestructura
Consolidación Núcleo Núcleo Núcleo Núcleo Proceso Proceso Proceso Núcleo Núcleo
Proceso Núcleo Núcleo Núcleo Núcleo Proceso Proceso Núcleo

  Página 373 de 670 

TOGOF 9.1    
Papel Papel Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio
Servicio Servicio Servicio Servicio Servicio Servicio Servicio Calidad de Servicio
Calidad de Servicio Paquete de Trabajo Función Papel Actor Contrato Entity Data
Entity Data Evento Función Lógico Aplicación Componente Lógico Tecnología
Componente Medida Unidad de Organización Proceso Proceso Calidad de Servicio
Servicio Servicio Contrato Servicio Capacidad Accesos Se descompone Se proporciona
a Se rige y se mide por Proporciona Consume Resuelve Proporciona una interfaz
gobernado al acceso Se realiza a través Se implementa en Se realiza un seguimiento
en contra Es propiedad y está regulado por la Apoyos Se realiza por Cumple Consume
Se descompone Se aplica a los Se aplica a los Entrega Núcleo Núcleo Núcleo
Gobernancia Núcleo Núcleo Proceso Núcleo Núcleo Núcleo Gobernancia Núcleo Núcleo
Núcleo Gobernancia Núcleo Núcleo Gobernancia Gobernancia Núcleo

  

  Página 374 de 670 

TOGOF 9.1       

35. Architectural Artifacts

Este capítulo trata de los conceptos que rodean arquitectura artefactos y luego
describe los artefactos que se recomiendan que se creará para cada fase en el
Método de Desarrollo de Arquitectura (ADM). También se presenta una guía para el
desarrollo de un conjunto de puntos de vista, algunos o todos de los cuales pueden
ser apropiadas en un desarrollo de la arquitectura en particular.

35.1 Conceptos básicos

Artefactos arquitectónicos se crean con el fin de describir un sistema, solución, o
el estado de la empresa. Los conceptos tratados en esta sección han sido adaptados
de las definiciones más formales contenidos en la norma ISO / IEC 42010:2007 e
ilustrados en la Figura 35-1 . Nota:  La notación utilizada es del Lenguaje
Unificado de Modelado (UML) especificación. 

  Figura 35‐1: Conceptos básicos de la arquitectura 
Un "sistema" es una colección de componentes organizados para llevar a cabo una
función o conjunto de funciones específicas.

  Página 375 de 670 

TOGOF 9.1    
La "arquitectura" de un sistema es la organización fundamental del sistema,
encarnada en sus componentes, sus relaciones entre sí y con el medio ambiente, y
los principios que guían su diseño y evolución. Una "descripción de la
arquitectura" es una colección de artefactos que documentan una arquitectura . En
TOGAF, vistas de arquitectura son los artefactos claves en una descripción de la
arquitectura. "Las partes interesadas" son 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 inquietudes. Las partes interesadas pueden ser individuos, grupos u
organizaciones (o clases de los mismos). "La preocupación" son los intereses
dominantes que son de crucial importancia para las partes interesadas en el
sistema, y determinar la aceptabilidad del sistema. Las preocupaciones pueden
referirse a cualquier aspecto de funcionamiento del sistema, el desarrollo o la
operación, incluyendo consideraciones tales como el rendimiento, la fiabilidad, la
seguridad, la distribución y capacidad de evolución. Una "vista" es una
representación de todo un sistema desde la perspectiva de un conjunto relacionado
de preocupaciones. Al capturar o representar el diseño de un sistema de
arquitectura, el arquitecto normalmente crear uno o más modelos de arquitectura,
posiblemente utilizando diferentes herramientas. Una vista comprenderá partes
seleccionadas de uno o más modelos, elegidos con el fin de demostrar a un actor o
grupo de actores que sus preocupaciones están siendo abordadas adecuadamente en el
diseño de la arquitectura del sistema. Un "punto de vista", define la perspectiva
desde la cual 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 justificación de estas decisiones
(por ejemplo, describiendo el propósito y destinatario de la vista).    Un punto
de vista es lo que ves. Un punto de vista es donde se busca desde - el punto de
vista o perspectiva que determina lo que ves.  Puntos de vista son genéricos, y
pueden ser almacenados en las bibliotecas para la reutilización. Un punto de vista
es siempre específica a la arquitectura para la que se creó.  Cada posición 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 forma
explícita. Hacer esta distinción entre el contenido y el esquema de una vista puede
parecer a primera vista una sobrecarga innecesaria, sino que proporciona un
mecanismo para que los puntos de vista reutilizar en diferentes arquitecturas. 

En resumen, pues, vistas de arquitectura son representaciones de la arquitectura

global en términos significativos para las partes interesadas. Permiten a la
arquitectura que se comunicará a y entendido por las partes interesadas, para que
puedan verificar que el sistema se ocupará de sus preocupaciones.

  Página 376 de 670 

TOGOF 9.1    
Nota:  Los términos "preocupación" y "requisito" no son sinónimos. Una preocupación
es un área de interés. Por lo tanto, la fiabilidad del sistema podría ser una
preocupación / área de interés para algunos interesados. La razón por la que los
arquitectos deberían identificar las preocupaciones y asociarlos con los puntos de
vista, es garantizar que esas preocupaciones serán abordadas de alguna manera por
los modelos de la arquitectura. Por ejemplo, si el único punto de vista
seleccionado por un arquitecto es un punto de vista estructural, a continuación,
problemas de fiabilidad es casi seguro que no se abordan, ya que no pueden ser
representados en un modelo estructural. Dentro de esa preocupación, los interesados
pueden tener muchas necesidades distintas: diferentes clases de usuarios pueden
tener diferentes requisitos de fiabilidad para las diferentes capacidades del
sistema.  Las preocupaciones son la raíz del proceso de descomposición en los
requisitos. Las preocupaciones están representados en la arquitectura de estos
requisitos.Los requisitos deben ser SMART (por ejemplo, las métricas específicas).

35.1.1 Ejemplo simple de un Mirador y Vista

Para muchas arquitecturas , un punto de vista útil es la de los dominios de
negocio, que se puede ilustrar con un ejemplo tomado de The Open Group en sí. El
punto de vista se especifica de la siguiente manera:
Elemento Viewpoint Las partes interesadas Preocupaciones Técnica de modelado
Descripción Consejo de Administración, Director General Mostrar las relaciones de
alto nivel entre los sitios geográficos y funciones de negocios. Anidado diagrama
de cajas. cajas exterior = lugares; cajas internas = funciones de negocios.
Semántica de anidación = funciones realizadas en las localidades.

La vista correspondiente de The Open Group (en 2008) se muestra en la Figura 35-2 .

  Página 377 de 670 

TOGOF 9.1    

  Figura 35‐2: Ejemplo View ‐ The Open Group Negocio Dominios en 2008 

35.2 Vistas desarrollo en el ADM

35.2.1 Directrices Generales
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 todos los intereses pertinentes
de las partes interesadas; y la integridad de la arquitectura, en cuanto a la
conexión de todos los diferentes puntos de vista de la otra, la conciliación de
forma satisfactoria las preocupaciones conflictivas de los diferentes grupos de
interés, y que muestra las compensaciones hechas en hacerlo (como entre la
seguridad y el rendimiento, por ejemplo). La elección tiene que ser limitada por
consideraciones de orden práctico, y por el principio de la aptitud para el
propósito (es decir, la arquitectura debe ser desarrollado sólo hasta el punto en
el que es apto para el propósito, y no reiteró el infinito como un ejercicio
académico). Como se explica en la Parte II: Arquitectura Método de Desarrollo (ADM)
, el desarrollo de puntos de vista de arquitectura es un proceso iterativo. La
progresión típica es de negocio a la tecnología, el uso de una técnica como
escenarios de negocios (véase la Parte III , 26. Escenarios empresariales y
objetivos de la empresa ) para identificar correctamente todas las preocupaciones
pertinentes; y de introducción de alto nivel a los detalles de bajo nivel,
refiriéndose continuamente de nuevo a las preocupaciones y necesidades de las
partes interesadas en todo el proceso.

  Página 378 de 670 

TOGOF 9.1    
Por otra parte, cada una de estas progresiones tiene que ser hecho por dos
ambientes distintos: el entorno existente (conocida como la línea de base en el
ADM) y el entorno de destino. El arquitecto debe desarrollar puntos de vista
pertinentes de arquitectura, tanto de la arquitectura de línea de base y la
arquitectura destino. Esto proporciona el contexto para el análisis de las
deficiencias en el final de las fases B, C y D de la ADM, que establece los
elementos de la arquitectura de referencia que deban traspasarse y los elementos
que pueden añadir, eliminar o sustituir. Todo este proceso se explica en la Parte
III , 27. Análisis Gap .

35.2.2 Ver Proceso de Creación

Como se mencionó anteriormente, en el momento actual TOGAF alienta pero no obliga a
la utilización de la norma ISO / IEC 42010:2007. Por tanto, la siguiente
descripción se refiere tanto a la situación en la ISO / IEC 42010:2007 ha sido
adoptado y en las que no tiene. ISO / IEC 42010:2007 en sí no requiere ningún
proceso específico para el desarrollo de puntos de vista o la creación de puntos de
vista de ellos. Cuando la norma ISO / IEC 42010:2007 ha sido adoptado y convertido
en una práctica bien establecida dentro de una organización, a menudo será posible
crear los puntos de vista necesarios para una arquitectura particular, siguiendo
estos pasos:

1. Consulte una biblioteca existente de puntos de vista  2. Seleccione los puntos

de vista apropiados (basados en los grupos de interés y preocupaciones que deben
ser cubiertos por los puntos de vista)  3. Generar vistas del sistema mediante el
uso de los puntos de vista seleccionados como plantillas 
Este enfoque se puede esperar para llevar a los siguientes beneficios:    Menos
trabajo para los arquitectos (debido a que los puntos de vista ya se han definido,
por lo que las vistas se pueden crear más rápido)  Una mejor comprensión de las
partes interesadas (debido a que los puntos de vista ya están familiarizados) 
Mayor confianza en la validez de los puntos de vista (debido a que sus puntos de
vista tienen una trayectoria conocida) 

Sin embargo, las situaciones siempre pueden surgir en los que se necesita una vista
para la que ningún punto de vista adecuado ha predefinido. Esta es también la
situación, por supuesto, cuando una organización aún no ha incorporado la norma ISO
/ IEC 42010:2007 en su práctica de la arquitectura y establecido una biblioteca de
puntos de vista. En cada caso, el arquitecto puede elegir para desarrollar un nuevo
punto de vista que cubrirá la necesidad excepcional y, a continuación, generar una
vista de ella. (Esta es la norma ISO / IEC 42010:2007 práctica recomendada.) Por
otra parte, un enfoque más pragmático puede ser igualmente exitosa: el arquitecto
puede crear un especialpunto de vista de un sistema específico y luego considerar
si una forma generalizada de la perspectiva implícita debería definirse

  Página 379 de 670 

TOGOF 9.1    
explícitamente y guardado en una biblioteca, de modo que pueda ser reutilizado.
(Esta es una manera de establecer una biblioteca de puntos de vista inicialmente.)
Sea cual sea el contexto, el arquitecto debe ser consciente de que cada punto de
vista tiene un punto de vista, al menos implícitamente, y que define el punto de
vista de una manera sistemática (según lo recomendado por la norma ISO / IEC
42010:2007) ayudará en la evaluación de su eficacia; es decir, cubre el punto de
vista de las preocupaciones de las partes interesadas pertinentes?.

35.3 Vistas, Herramientas y lenguajes

La necesidad de puntos de vista de arquitectura, y el proceso de desarrollo de
ellos después de la ADM, se explicaron anteriormente. Esta sección describe las
relaciones entre puntos de vista de arquitectura, las herramientas utilizadas para
desarrollar y analizarlos, y una que permite la interoperabilidad entre lenguajes
estándar entre las herramientas.

35.3.1 Información general

Con el fin de alcanzar los objetivos de la integridad y la integridad en una
arquitectura , vistas de arquitectura suelen ser desarrollados, visualizar,
comunican y gestionan mediante una herramienta. En el estado actual del mercado,
diferentes herramientas normalmente tienen que ser utilizados para desarrollar y
analizar diferentes puntos de vista de la arquitectura. Es altamente deseable que
una descripción de la arquitectura se codifica en un lenguaje estándar, para
permitir un enfoque estándar para la descripción de la arquitectura semántica y su
reutilización entre distintas herramientas. Un punto de vista también se desarrolló
normalmente, visualizar, comunicar y administrar mediante una herramienta, y
también es muy deseable que se desarrollen puntos de vista estándar (por ejemplo,
plantillas o esquemas), de modo que las diferentes herramientas que se ocupan en
los mismos puntos de vista pueden interoperar, la elementos fundamentales de una
arquitectura pueden ser reutilizados, y la descripción de la arquitectura pueden
ser compartidas entre las herramientas. Las cuestiones relativas a la evaluación de
las herramientas para el trabajo de la arquitectura se discuten en detalle en la
Parte V , 42. Herramientas para el desarrollo de la arquitectura .

35.4 Puntos de vista y Puntos de Vista

35.4.1 Ejemplo de Tendencias y Puntos de Vista
Para ilustrar los conceptos de opiniones y puntos de vista, considere el ejemplo de
un sistema aeroportuario muy simple con dos partes diferentes: el piloto y el
controlador de tránsito aéreo. Un punto de vista se puede desarrollar desde el
punto de vista del piloto, que se ocupa de las preocupaciones del piloto.
Igualmente, otro punto de vista se puede desarrollar desde el punto de vista del
controlador de tránsito aéreo. Ni vista describe completamente el sistema en su
totalidad, porque el punto de vista de cada una de las partes interesadas
restricciones (y reduce) cómo cada uno ve el sistema global.

  Página 380 de 670 

TOGOF 9.1    
El punto de vista del piloto comprende algunas preocupaciones que no son relevantes
para el controlador, como pasajeros y combustible, mientras que el punto de vista
del controlador comprende algunas preocupaciones que no son pertinentes para el
piloto, como otros aviones. También hay elementos comunes entre los dos 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 nuestro 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. Pilotos describen el sistema desde su
perspectiva, utilizando un modelo de su posición y el 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 la información y rellenar el
modelo. Controladores describen el sistema de forma diferente, utilizando un modelo
del espacio aéreo y los lugares y vectores de 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 se cruzan parcialmente.) Parte de este
lenguaje común es acerca de la ubicación y vectores de aeronaves, 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. Existen herramientas para
ayudar a las partes interesadas, sobre todo cuando están interactuando con los
modelos complejos, como el modelo de un espacio aéreo , o el modelo de vuelo del
aire. La interfaz para el usuario humano de una herramienta es típicamente cerca de
la del modelo y de idioma asociado con el punto de vista. Las herramientas únicas
de la prueba piloto son el combustible, la altitud, la velocidad y los indicadores
de lugar. La herramienta principal del controlador es el radar. La herramienta
común es una radio. Para resumir el ejemplo anterior, podemos ver que una vista
puede subconjunto del sistema a través de la perspectiva de la parte interesada,
como el piloto contra el controlador. Este subconjunto puede ser descrito por un
modelo abstracto llamado un punto de vista, tal como un vuelo de aire en
comparación con un modelo de espacio de aire. Esta descripción de la vista se
documenta en un idioma parcialmente especializada, como "piloto-speak" frente
"controladorspeak". Las herramientas son usadas para ayudar a las partes
interesadas, y que interactúan entre sí en cuanto a la lengua derivada del punto de
vista ("piloto-speak" versus " "controladorspeak"). Cuando los actores usan
herramientas comunes, como el contacto de radio entre piloto y controlador, un
idioma común es esencial.

  Página 381 de 670 

TOGOF 9.1    
35.4.2 Vistas y puntos de vista en la arquitectura empresarial
Ahora vamos a mapear este ejemplo para la arquitectura empresarial. Consideremos
dos partes interesadas en un nuevo sistema informático pequeño: los usuarios y los
desarrolladores. Los usuarios del sistema tienen un punto de vista que refleja sus
inquietudes al interactuar con el sistema, y los desarrolladores del sistema de
tener un punto de vista diferente. Visto que se desarrollan para tratar cualquiera
de los dos puntos de vista son poco probable para describir exhaustivamente todo el
sistema, porque cada perspectiva reduce cómo cada uno ve el sistema. El punto de
vista del usuario se compone de todas las formas en que el usuario interactúa con
el sistema, no ver ningún detalle, como aplicaciones o sistemas de gestión de bases
de datos (DBMS). El punto de vista del desarrollador es uno de productividad y
herramientas, y no incluye cosas tales como los datos reales en vivo y las
conexiones con los consumidores. Sin embargo, hay cosas que se comparten, tales
como descripciones de los procesos que están habilitados por el sistema y / o
protocolos de comunicación establecido para que los usuarios comuniquen
directamente los problemas del desarrollo. En este ejemplo, un punto de vista es la
descripción de cómo el usuario ve el sistema, y el otro punto de vista es cómo el
desarrollador ve el sistema. Los usuarios describen el sistema desde su
perspectiva, utilizando un modelo de disponibilidad, tiempo de respuesta, y el
acceso a la información. Todos los usuarios del sistema de utilizar este modelo, y
el modelo tiene un lenguaje específico. Desarrolladores describir el sistema de
manera diferente que los usuarios, usando un modelo de software conectado al
hardware distribuido sobre una red, etc Sin embargo, hay muchos tipos de
desarrolladores (base de datos, seguridad, etc) del sistema, y no tienen un común
idioma derivada del modelo.

35.4.3 necesidad de un lenguaje común y herramientas interoperables para

Arquitectura Descripción
Existen herramientas para los usuarios y desarrolladores. Herramientas tales como
la ayuda en línea están allí específicamente para los usuarios, y tratan de
utilizar el idioma del usuario. Existen muchas herramientas diferentes para
diferentes tipos de desarrolladores, pero adolecen de la falta de un lenguaje común
que se requiere para que el sistema en conjunto. Es difícil, si no imposible, en el
estado actual del mercado de herramientas para tener una herramienta de interoperar
con otra herramienta. Las cuestiones relativas a la evaluación de las herramientas
para el trabajo de la arquitectura se discuten en detalle en la Parte V , 42.
Herramientas para el desarrollo de la arquitectura .
35.5 Conclusiones
Esta sección se trata de hacer frente a puntos de vista en forma estructurada, pero
esto de ninguna manera es un tratado completo de puntos de vista.

  Página 382 de 670 

TOGOF 9.1    
. En general, TOGAF abarca los conceptos y definiciones que se presentan en la
norma ISO / IEC 42010:2007, específicamente los conceptos que ayudan a guiar el
desarrollo de una visión y hacer que la visión accionable Estos conceptos se pueden
resumir en:    Selección de una de las partes interesadas clave  Entender sus
preocupaciones y generalizando / documentar esas preocupaciones  Entender cómo
modelar y hacer frente a esas preocupaciones 

35.6 Architectural Artifacts por ADM Fase

La Figura 35-3 muestra los artefactos que están asociados con el metamodelo
contenido de núcleo y cada una de las extensiones de contenido.

  Figura 35‐3: artefactos asociados con el metamodelo y Extensiones Core 
Las clases específicas de artefacto son los siguientes:    Catálogos son listas
de bloques de construcción.  Matrices muestran las relaciones entre los componentes
básicos de los tipos específicos.  Diagramas actuales bloques de construcción,
además de sus relaciones e interconexiones de un modo gráfico que soporta la
comunicación efectiva de los interesados. 

Los artefactos recomendadas para la producción en cada fase de ADM son los
siguientes.

  Página 383 de 670 

TOGOF 9.1    
35.6.1 Fase Preliminar
A continuación se describen los catálogos, matrices y diagramas que se pueden crear
dentro de la Etapa Preliminar, como se indica en la Parte II , 6.5 Salidas .
Principios Catálogo

El catálogo Principios capta principios de los principios de negocio y la

arquitectura que describen lo que una solución o arquitectura "buena" debe ser
similar. Principios se utilizan para evaluar y acordar un resultado para los puntos
de decisión arquitectura. Principios también se utilizan como una herramienta para
ayudar en la gestión de arquitectura de las iniciativas de cambio. El catálogo
Principios contiene las siguientes entidades metamodelo:  Principio 

35.6.2 Fase A: Architecture Vision

A continuación se describen los catálogos, matrices y diagramas que se pueden crear
dentro de la Fase A (Architecture Vision) que se enumeran en 7.5 Salidas .
Stakeholder Mapa Matrix

El propósito de la matriz de los interesados mapa es identificar los grupos de

interés para la contratación arquitectura, su influencia sobre el compromiso, y sus
preguntas clave, temas o preocupaciones que deben ser abordados en el marco de la
arquitectura. Entender las partes interesadas y sus necesidades permite a un
arquitecto para enfocar los esfuerzos en las áreas que satisfagan las necesidades
de los interesados (véase la Parte III , 24. Gestión de los grupos de interés ).
Debido a la naturaleza potencialmente confidencial de la información de mapeo de
los interesados y el hecho de que la fase Architecture Vision está destinado a ser
llevado a cabo utilizando técnicas de modelado informales, no hay entidades
metamodelo específicos se utilizan para generar un mapa de las partes interesadas.
Diagrama de la Cadena de Valor

Un diagrama de la cadena de valor ofrece una vista de orientación de alto nivel de

una empresa y cómo interactúa con el mundo exterior. En contraste con el diagrama
de descomposición funcional más formal desarrollado en la Fase B (Business
Architecture), el diagrama de la cadena de valor se centra en el impacto de
presentación. El propósito de este diagrama es rápidamente a bordo y alinear las
partes interesadas de una iniciativa particular el cambio, de modo que todos los
participantes entiendan el contexto funcional y organizativa de alto nivel de la
participación de la arquitectura.

  Página 384 de 670 

TOGOF 9.1    
Solución Concepto Diagrama

Un diagrama Solution Concept ofrece una orientación de alto nivel de la solución

que se prevé el fin de cumplir los objetivos de la participación de la
arquitectura. En contraste con los esquemas más formales y detalladas de
arquitectura desarrollado en las siguientes fases, el concepto de solución
representa un "dibujo a lápiz" de la solución esperada al inicio del contrato. Este
diagrama puede incorporar objetivos clave, requisitos y restricciones para la
participación y también poner de relieve las áreas de trabajo para ser investigado
con más detalle con el modelado de la arquitectura formal. Su propósito es
rápidamente a bordo y alinear las partes interesadas de una iniciativa particular
el cambio, de modo que todos los participantes entiendan lo que el compromiso de la
arquitectura está tratando de lograr y cómo se espera que un enfoque de solución
particular será satisfacer las necesidades de la empresa.

35.6.3 Fase B: Arquitectura de Negocios

A continuación se describen los catálogos, matrices y diagramas que se pueden crear
dentro de la Fase B (Business Architecture) como se indica en 8.5 Salidas .
Catálogo Organización / Actor

El propósito del catálogo Organización / Actor es capturar una lista definitiva de

todos los participantes que interactúan con él, incluidos los usuarios y los
propietarios de los sistemas de TI. El catálogo Organización / Actor se puede hacer
referencia al elaborar los requisitos con el fin de comprobar la integridad. Por
ejemplo, los requisitos para una aplicación que da servicio a los clientes se
pueden probar por la totalidad mediante la verificación de exactamente qué tipos de
clientes necesitan ser apoyados y si existen requisitos o restricciones
particulares para tipos de usuario. El / catalog Actor Organización contiene las
siguientes entidades metamodelo:    Unidad de Organización  Actor  Ubicación
(puede incluirse en este catálogo, si un catálogo independiente de la ubicación no
se mantiene) 

Conductor / Meta / Objetivo Catálogo

El propósito del Conductor / Meta / Objetivo catálogo es ofrecer una referencia de

toda la Organización de cómo una organización responde a sus pilotos en la práctica
a través de metas, objetivos, y (opcionalmente) las medidas. La publicación de una
ruptura definitiva de los conductores, las metas y objetivos permite que las
iniciativas de cambio dentro de la empresa para identificar las sinergias en toda
la organización

  Página 385 de 670 
TOGOF 9.1    
(por ejemplo, múltiples organizaciones que intentan lograr objetivos similares),
que a su vez permiten a las partes interesadas para identificar e iniciativas de
cambio vinculadas a alinear o consolidados. El Conductor / Meta / Objetivo catálogo
contiene las siguientes entidades metamodelo:      Unidad de Organización 
Conductor  Meta  Objetivo  Medida (pueden estar opcionalmente incluido) 

Catálogo de funciones

El propósito del catálogo de papel es el de proporcionar una lista de todos los

niveles de autorización o zonas dentro de una empresa. Con frecuencia, la seguridad
de aplicaciones o el comportamiento se define en contra de los conceptos entendidos
a nivel local de la autorización que crean consecuencias complejas e inesperadas
cuando se combina en el escritorio del usuario. Si se definen los roles,
entendidos, y alineados en todas las organizaciones y aplicaciones, lo que permite
una experiencia de usuario más fluida y aplicaciones en general, más seguras, ya
que los administradores no tengan que recurrir a soluciones alternativas con el fin
de permitir a los usuarios para llevar a cabo su trabajo. Además de apoyar la
definición de seguridad para la empresa, el catálogo de funciones también forma un
insumo clave para la identificación de los impactos de la organización de gestión
del cambio, la definición de las funciones de trabajo, y la ejecución de la
capacitación del usuario final. Como cada rol implica el acceso a una serie de
funciones de la empresa, si alguna de estas funciones de la empresa se ven
afectados, a continuación, cambiar será necesario el manejo, es posible que las
responsabilidades organizativas que redefinirse, y puede ser necesaria la
reconversión. El catálogo contiene las siguientes clases, entidades metamodelo: 
Papel 

Business Service / Función catálogo

El propósito de el catálogo de servicios de negocios / función es la de

proporcionar una descomposición funcional en una forma que se puede filtrar,
informó sobre, y preguntó, como un suplemento a los diagramas de descomposición
funcional gráficas. El catálogo de servicios de negocios / La función puede
utilizarse para identificar las capacidades de una organización y para comprender
el nivel de gobierno que se aplica a las funciones de una organización. Esta
descomposición funcional se puede utilizar para identificar nuevas capacidades

  Página 386 de 670 

TOGOF 9.1    
requeridas para apoyar el cambio de negocios o se puede usar para determinar el
alcance de las iniciativas de cambio, aplicaciones o componentes de la tecnología.
El catálogo de servicios de negocios / Función contiene las siguientes entidades
metamodelo:     Unidad de Organización  Función comercial  Servicios de
Negocio  Información de servicio del sistema (opcionalmente puede incluirse aquí) 

Ubicación catálogo

El catálogo Ubicación proporciona un listado de todos los lugares en los que la

empresa lleva a cabo operaciones de negocios o casas de activos arquitectónicamente
relevantes, tales como los centros de datos o equipos de computación de usuario
final. El mantenimiento de una lista definitiva de los lugares permite iniciativas
de cambio para definir rápidamente un alcance ubicación y para la prueba de
integridad en la evaluación de los paisajes actuales o soluciones destinatarios
propuestos. Por ejemplo, un proyecto para actualizar los sistemas operativos de
escritorio deberá identificar todas las ubicaciones donde se utilizan los sistemas
operativos de escritorio. Del mismo modo, cuando se están implementando nuevos
sistemas, un diagrama de las ubicaciones es esencial con el fin de desarrollar
estrategias de implementación adecuadas que comprenden tanto al usuario como
ubicación de la aplicación e identificar los problemas relacionados con la
ubicación, como la internacionalización, localización, los impactos sobre los
impactos de zona horaria de disponibilidad, distancia en latencia, los impactos de
la red de ancho de banda, y el acceso. El catálogo contiene Ubicación las
siguientes entidades metamodelo:  Ubicación 

Proceso / Evento / Control / Catálogo de Productos

El proceso / evento / Control / Catálogo de productos proporciona una jerarquía de

procesos, eventos que desencadenan los procesos, los productos procedentes de los
procesos y controles que se aplican a la ejecución de los procesos. Este catálogo
ofrece un complemento a cualquier diagrama de flujo de proceso que se crean y
permite a una empresa que va a filtrar, informe y consulta a través de las
organizaciones y procesos para identificar el alcance, en común, o impacto. Por
ejemplo, el proceso / evento / Control / Catálogo de productos permite a una
empresa para ver las relaciones de los procesos a los sub-procesos con el fin de
identificar la cadena de impactos resultantes de cambiar un proceso de alto nivel.
El proceso / evento / Control / Catálogo de productos incluye las siguientes
entidades metamodelo:

  Página 387 de 670 

TOGOF 9.1    
    Proceso  Evento  Control  Producto 

Contrato / Medida Catálogo

El catálogo Contract / Medida proporciona un listado de todos los contratos de

servicio acordados y (opcionalmente) las medidas adjuntas a esos contratos. Forma
la lista maestra de los niveles de servicio acordados para toda la empresa. El
Contrato / catalog Medida contiene las siguientes entidades metamodelo:    
Servicios de Negocio  Información de servicio del sistema (opcional)  Contrato 
Medida 

Matriz de Interacción de Negocios

El propósito de esta matriz es representar las interacciones de la relación entre

las organizaciones y funciones de negocio en toda la empresa. Comprender la
interacción de negocios de una empresa es importante ya que ayuda a resaltar la
cadena de valor y las dependencias en todas las organizaciones. La matriz de
interacción de negocios muestra las siguientes entidades metamodelo y relaciones: 
    Organización  Función comercial  Servicios de Negocio  Business Service
comunica con relaciones de servicios empresariales   Servicios de Negocio depende
de las relaciones de servicio de negocios  

Matrix Actor / Rol

El propósito de esta matriz es mostrar que los actores realizan que los roles, el
apoyo a la definición de los requisitos de seguridad y de cualificaciones.

  Página 388 de 670 

TOGOF 9.1    
Comprender las relaciones actor-a roles es una herramienta de apoyo clave en la
definición de las necesidades de capacitación, la configuración de seguridad del
usuario y la gestión del cambio organizacional. La matriz Actor / Rol muestra las
siguientes entidades metamodelo y relaciones:    Actor  Papel  Actor realiza
relaciones de rol  

Negocios Huella Diagrama

Un diagrama de negocios Huella describe los vínculos entre los objetivos de

negocio, unidades organizativas, funciones de oficina y servicios, y los mapas de
estas funciones a los componentes técnicos que entregan la capacidad requerida. Un
diagrama de negocios Huella proporciona una trazabilidad clara entre un componente
técnico y el objetivo comercial que satisface, a la vez que demuestra la propiedad
de los servicios identificados. Un diagrama de negocios Huella demuestra solamente
los hechos clave que relacionan funciones de la unidad de organización de los
servicios de entrega y se utiliza como una plataforma de comunicación para los de
categoría superior (CxO) las partes interesadas.
Business Service / Diagrama de Información

El diagrama de Servicios de Negocio / Información muestra la información necesaria

para apoyar uno o más servicios de oficina. El diagrama de Business Service /
Information muestra los datos que se consume en o producido por un servicio de
negocio y también puede mostrar la fuente de información. El diagrama de Business
Service / Information muestra una representación inicial de la información
incorporada dentro de la arquitectura y por lo tanto constituye una base para
elaboración y perfeccionamiento dentro de la fase C (Arquitectura de Datos).
Diagrama de Descomposición Funcional

El propósito del diagrama de descomposición funcional es mostrar en una sola página

de las capacidades de una organización que son relevantes para la consideración
deuna arquitectura . Mediante el examen de las capacidades de una organización
desde una perspectiva funcional, es posible desarrollar rápidamente modelos de lo
que hace la organización sin ser arrastrado a prolongar el debate sobre cómo la
organización hace. Una vez que un diagrama básico de descomposición funcional se ha
desarrollado, se hace posible a la capa de calor-maps en la parte superior de este
diagrama para mostrar el alcance y las decisiones. Por ejemplo, la capacidad para
ser implementadas en diferentes fases de un programa de cambio.

  Página 389 de 670 

TOGOF 9.1    
Diagrama del ciclo de vida del producto

El propósito del diagrama del ciclo de vida del producto es ayudar en la

comprensión de los ciclos de vida de las entidades clave dentro de la empresa.
Entender los ciclos de vida de productos es cada vez más importante con respecto a
las preocupaciones ambientales, la legislación y la reglamentación cuando los
productos deben ser rastreados desde su fabricación hasta su eliminación. Del mismo
modo, las organizaciones que crean productos que involucran información personal o
sensible deben tener un conocimiento detallado de la vida útil del producto durante
el desarrollo de la arquitectura de negocios con el fin de garantizar el rigor en
el diseño de los controles, procesos y procedimientos. Ejemplos de esto incluyen
tarjetas de crédito, tarjetas de débito, tarjetas de la tienda / de fidelidad,
tarjetas inteligentes, credenciales de identidad de usuario (documentos de
identidad, pasaportes, etc.)
Meta / Objetivo Diagrama / Servicio

El propósito de un diagrama de Meta / Objetivo / Servicio es definir las formas en

que un servicio contribuye a la consecución de una visión o estrategia de negocio.
Los servicios se asocian con los controladores, metas, objetivos y medidas que
apoyan, lo que permite a la empresa a entender que los servicios contribuyen a
aspectos similares de rendimiento empresarial. El diagrama de Meta / Objetivo /
servicio también proporciona entrada cualitativa sobre lo que constituye un alto
rendimiento para un servicio en particular.

Diagrama de negocios de casos de uso

Un diagrama de negocios de caso de uso muestra las relaciones entre consumidores y

proveedores de servicios de oficina. Servicios a empresas son consumidos por los
actores u otros servicios de negocios y el diagrama de negocios de caso de uso
proporciona riqueza agregada al describir la capacidad del negocio mediante la
ilustración de cómo y cuándo se utiliza esa capacidad. El propósito del diagrama de
casos de uso de negocios es ayudar a describir y validar la interacción entre los
actores y sus roles en los procesos y funciones. Como la arquitectura avanza, el
caso de uso puede evolucionar desde el nivel de negocio para incluir datos,
aplicaciones, y detalles de tecnología. Negocio casos de uso de arquitectura
también se pueden volver a utilizar en los sistemas de trabajo de diseño.
Organización Descomposición Diagrama

Un diagrama de Organización Descomposición describe los vínculos entre actores,

roles, y la ubicación dentro de un árbol de organización. Un mapa de la
organización debe proporcionar una cadena de mando de los propietarios y encargados
de tomar decisiones en la organización. Aunque no es la intención de la
Organización diagrama de descomposición vincular meta de la organización, debería
ser posible vincular de forma intuitiva las metas a las partes interesadas en el
diagrama de la Organización de descomposición.

  Página 390 de 670 

TOGOF 9.1    
Diagrama de Flujo de Proceso

El propósito del diagrama de flujo de proceso es representar todos los modelos y

las asignaciones relacionadas con la entidad metamodelo proceso. Los diagramas de
flujo de procesos muestran el flujo secuencial de control entre las actividades y
pueden utilizar las técnicas de natación carriles para representar la propiedad y
la realización de los pasos del proceso. Por ejemplo, la aplicación que soporta una
fase del proceso se puede mostrar como un baño carriles. Además de mostrar una
secuencia de la actividad, flujos de proceso también pueden ser utilizados al
detalle los controles que se aplican a un proceso, los eventos que desencadenan o
resultan de la finalización de un proceso, y también los productos que se generan a
partir de la ejecución del proceso. Los diagramas de flujo de proceso son útiles en
la elaboración de la arquitectura con especialistas en la materia, ya que permiten
al especialista para describir "cómo el trabajo está hecho" para una función en
particular. A través de este proceso, cada paso del proceso puede llegar a ser una
función de grano más fino y puede, a su vez ser elaborado como un proceso.
Diagrama de eventos

El propósito del diagrama de eventos es para representar la relación entre los

eventos y proceso. Ciertos eventos - como la llegada de cierta información (por
ejemplo, el cliente envía pedido de cliente) o de un determinado punto en el tiempo
(por ejemplo, al final del trimestre fiscal) necesitan causa el trabajo y ciertas
acciones que deben emprenderse en el negocio. Éstos se refieren a menudo como
"eventos de negocios" o simplemente "eventos" y se consideran como factores
desencadenantes de un proceso. Es importante tener en cuenta que el evento tiene
que desencadenar un proceso y generar una respuesta de negocios o resultado.
35.6.4 Fase C: Arquitectura de Datos
A continuación se describen los catálogos, matrices y diagramas que se pueden crear
dentro de la fase C (Arquitectura de datos) que se enumeran en 10.5 Salidas .
Catálogo de Entity Data / componente de datos

El propósito del catálogo de Entity Data / componente de datos es identificar y

mantener una lista de todo el uso de los datos en toda la empresa, incluyendo las
entidades de datos y también los componentes de datos donde se almacenan las
entidades de datos. Un catálogo de Entity Data / componente de datos acordado apoya
la definición y aplicación de políticas de gestión de la información y gobierno de
datos y también fomenta el intercambio de datos eficaz y reutilización. El catálogo
Entity Data / componente de datos contiene las siguientes entidades metamodelo:  
 Entity Data  Componente lógica de datos  Componente Físico de Datos 

  Página 391 de 670 

TOGOF 9.1    
Entity Data / Matrix Función comercial

El propósito de la matriz de funciones de Entity Data / Negocios es ilustrar las

relaciones entre las entidades de datos y funciones de negocios dentro de la
empresa.Funciones de negocio se apoyan en los servicios empresariales con límites
definidos de forma explícita y contarán con el apoyo y se dieron cuenta de los
procesos de negocio. El mapeo de la relación de funciones de Entity DataBusiness
permite lo siguiente a tener lugar:      Asignar la propiedad de entidades de
datos a las organizaciones  Comprender los datos y las necesidades de intercambio
de información de los servicios de negocio  Apoyar el análisis de las deficiencias
y determinar si las entidades de datos se han perdido y es necesario crear  Definir
solicitud de origen, solicitud de registro, y la aplicación de referencia para
entidades de datos  Habilitar el desarrollo de los programas de gobierno de datos
en toda la empresa (establecer administrador de datos, el desarrollo de estándares
de datos pertinentes a la función de negocios, etc) 

La matriz de datos de entidad / Función negocios muestra las siguientes entidades y

relaciones:    Entity Data  Función comercial  Relación Entity Data para ser
propietario de unidad organizativa 

Aplicación / Data Matrix

El propósito de la matriz de aplicación / datos es para representar la relación

entre las aplicaciones (es decir, componentes de la aplicación) y las entidades de
datos que se tiene acceso y actualizados por ellos. Las solicitudes serán crear,
leer, actualizar y eliminar entidades específicas de datos que se asocian con
ellos. Por ejemplo, una aplicación de CRM será crear, leer, actualizar y eliminar
información de la entidad cliente. Las entidades de datos en un entorno de paquetes
/ servicios empaquetados se pueden clasificar como datos maestros, datos de
referencia, datos de transacciones, datos de contenido y datos históricos. Las
aplicaciones que operan en las entidades de datos incluyen aplicaciones
transaccionales, aplicaciones de gestión de la información y las aplicaciones de
almacenamiento empresarial. El mapeo de la relación componente de aplicación-Entity
Data es un paso importante, ya que permite lo siguiente a tener lugar:  Asigne
acceso de datos para aplicaciones específicas en la organización 

  Página 392 de 670 

TOGOF 9.1    
   Entender el grado de duplicación de datos en diferentes aplicaciones, y la
escala del ciclo de vida de los datos  Entender donde los mismos datos se actualiza
por diferentes aplicaciones  Apoyar el análisis de las deficiencias y determinar si
alguna de las aplicaciones están desaparecidos y como consecuencia es necesario
crear 

La matriz de aplicaciones / datos es una tabla de dos dimensiones con Logical

componente de aplicación en un eje y Entity Data en el otro eje.
Diagrama conceptual de datos

El propósito fundamental del esquema conceptual de datos es representar las

relaciones entre las entidades de datos críticos dentro de la empresa. Este esquema
se ha desarrollado para atender las preocupaciones de los interesados del negocio.
Las técnicas utilizadas son:   Modelos de relación Entidad  Diagramas de clases
UML simplificado 

Diagrama de lógica de datos

El propósito fundamental del esquema lógico de datos es mostrar vistas lógicas de

las relaciones entre las entidades de datos críticos dentro de la empresa. Este
esquema ha sido desarrollado para atender las preocupaciones de:   Los
desarrolladores de aplicaciones  Los diseñadores de bases de datos 

Diagrama de Divulgación de Datos

El propósito del diagrama de Divulgación de Datos es mostrar la relación entre la

entidad de datos, servicio de negocios, y componentes de la aplicación. El diagrama
muestra cómo las entidades lógicas se han de realizar físicamente por componentes
de la aplicación. Esto permite dimensionamiento eficaz para llevar a cabo y la
huella de TI para ser refinado. Por otra parte, mediante la asignación de valor
para el negocio a los datos, una indicación de la criticidad del negocio de
componentes de la aplicación se puede ganar. Además, el diagrama puede mostrar la
replicación de datos y la propiedad de las aplicaciones de la referencia principal
para los datos. En este caso, puede mostrar dos copias y la relación amo-copia
entre ellos. Este diagrama puede incluir servicios; es decir, los servicios
encapsulan datos y residen en una aplicación o servicios que se encuentran en una
aplicación y acceder a datos encapsulados dentro de la aplicación.
Diagrama de seguridad de datos

  Página 393 de 670 

TOGOF 9.1    
Los datos se consideran como un activo para la empresa y la seguridad de datos,
simplemente significa asegurar que los datos de la empresa no está comprometida y
que el acceso a la misma se controla adecuadamente. El propósito del diagrama de
seguridad de datos es describir qué actor (persona, organización o sistema) pueden
acceder a que los datos empresariales. Esta relación se puede mostrar en forma de
matriz entre dos objetos o puede mostrarse como una asignación. El diagrama también
se puede utilizar para demostrar el cumplimiento de las leyes de privacidad de
datos y demás normativa aplicable (HIPAA, SOX, etc). Este diagrama también debe
considerar las implicaciones de confianza donde los socios de una empresa o de
terceros pueden tener acceso a los sistemas de la empresa, como una situación
subcontratada donde la información puede ser administrado por otras personas e
incluso puede ser alojado en un país diferente.
Diagrama de migración de datos

La migración de datos es fundamental en la aplicación de un paquete o una solución

basada en los servicios empaquetados. Esto es particularmente cierto cuando una
aplicación heredada existente se reemplaza por un paquete o una empresa se va a
migrar a una mayor huella de paquetes / servicios empaquetados. Paquetes tienden a
tener su propio modelo de datos y durante la migración de datos pueden necesitar
los datos de aplicaciones heredadas a ser transformado antes de cargarlos en el
paquete. Actividades de migración de datos por lo general implicará los siguientes
pasos:    Extraer los datos de las aplicaciones de código (sistemas de
referencia)  Perfil de datos de origen  Realizar las operaciones de transformación
de datos, incluidos los procesos de calidad de datos:  o o o  Estandarizar,
normalizar, los datos-de duplicado de origen (limpieza de datos)  Partido, fusionar
y consolidar datos de diferentes fuentes (s)  Asignaciones de fuente a destino 

Cargue en aplicaciones de destino (sistemas de destino) 

El propósito del diagrama de migración de datos es para mostrar el flujo de datos

desde la fuente a las aplicaciones de destino. El diagrama proporcionará una
representación visual de la propagación de fuentes / objetivos y servir como
herramienta de auditoría de datos y el establecimiento de la trazabilidad. Este
diagrama puede ser elaborado o mejorado como se detalla en caso necesario. Por
ejemplo, el diagrama puede contener sólo una disposición general de la migración de
paisaje o podría entrar en el nivel de elementos de metadatos aplicación individual
de detalle.

  Página 394 de 670 

TOGOF 9.1    
Diagrama del ciclo de vida de datos

El diagrama de datos del ciclo de vida es una parte esencial de la gestión de los
datos de negocio a lo largo de su ciclo de vida, desde su concepción hasta su
eliminación dentro de las limitaciones del proceso de negocio. Los datos se
considera como una entidad en sí mismo, desvinculado de los procesos de negocio y
de la actividad. Cada cambio en el estado está representado en el diagrama que
puede incluir el evento o reglas que desencadenan que el cambio en el estado. La
separación de los datos de proceso permite a los requisitos de datos comunes que se
identifiquen, que permite el intercambio de recursos para alcanzar con mayor
eficacia.

35.6.5 Fase C: Arquitectura de aplicaciones

A continuación se describen los catálogos, matrices y diagramas que se pueden crear
dentro de la fase C (Application Architecture) como se indica en 11.5 Salidas .
Catálogo cartera de aplicaciones

La finalidad de este catálogo es identificar y mantener una lista de todas las

aplicaciones de la empresa. Esta lista ayuda a definir el alcance horizontal de las
iniciativas de cambio que puedan afectar a determinados tipos de aplicaciones. Un
portafolio de aplicaciones permite acordado un conjunto estándar de aplicaciones
que se definan y gobernados. El catálogo del portafolio de aplicaciones proporciona
una base sobre la cual basar las matrices y diagramas restantes. Normalmente es el
punto de inicio de la fase de Arquitectura de la aplicación. El catálogo de la
Cartera de Aplicaciones contiene las siguientes entidades metamodelo:   
Servicio de Sistema de Información  Lógico componente de aplicación  Física
componente de aplicación 

Catálogo de interfaz

El propósito de el catálogo de interfaz es el alcance y documentar las interfaces

entre las aplicaciones que permitan a las dependencias globales entre aplicaciones
a ser de ámbito tan pronto como sea posible. Las solicitudes serán crear, leer,
actualizar y eliminar datos en otras aplicaciones; esto se logrará por algún tipo
de interfaz, ya sea a través de un archivo por lotes que se carga periódicamente,
una conexión directa con la base de datos de otra aplicación, o por medio de algún
tipo de API o servicio web. El mapeo de la relación entidad de la aplicación del
Componente-aplicación es un paso importante, ya que permite lo siguiente a tener
lugar:

  Página 395 de 670 

TOGOF 9.1    
     Entender el grado de interacción entre las aplicaciones, identificando
aquellos que son esenciales en términos de sus dependencias en otras aplicaciones 
Entender el número y tipos de interfaces entre aplicaciones  Entender el grado de
duplicación de interfaces entre aplicaciones  Identificar las posibilidades de
simplificación de las interfaces cuando se considera la cartera de aplicaciones de
destino  Apoyar el análisis de las deficiencias y determinar si alguna de las
aplicaciones están desaparecidos y como consecuencia es necesario crear 

El catálogo de interfaz contiene las siguientes entidades metamodelo:    Lógico

componente de aplicación  Física componente de aplicación  Aplicación comunica con
relación aplicación  

Aplicación / Matrix Organización

El propósito de esta matriz es representar la relación entre las aplicaciones y

unidades de la organización dentro de la empresa. Funciones de negocio son
realizadas por unidades organizativas. Algunas de las funciones y servicios
prestados por las unidades organizativas serán apoyados por las aplicaciones. El
mapeo de la relación Aplicación Unidad Componente-Organización es un paso
importante, ya que permite lo siguiente a tener lugar:     Asignar el uso de
aplicaciones a las unidades de la organización que realizan funciones
empresariales  Comprender los requisitos de soporte de aplicaciones de los
servicios de negocios y procesos llevados a cabo por una unidad de organización 
Apoyar el análisis de las deficiencias y determinar si alguna de las aplicaciones
están desaparecidos y como consecuencia es necesario crear  Definir el conjunto de
aplicaciones que utiliza una unidad de organización en particular 

La matriz de Aplicación / Organización es una tabla de dos dimensiones con el

componente lógico de aplicación / física en un eje y unidad de organización en el
otro eje. La relación entre estas dos entidades es un compuesto de un número de
relaciones metamodelo que necesitan validar:   Unidades de Organización de poseer
Servicios   Actores que pertenecen a unidades de organización utilizan Servicios

  Página 396 de 670 

TOGOF 9.1    
 Los servicios se realizan por componentes de aplicación lógicas / físicas  

Matrix Papel / Aplicación

El propósito de la matriz de Papel / Aplicación es describir la relación entre las

aplicaciones y los roles de negocio que los utilizan en la empresa. La gente en una
organización interactúan con las aplicaciones. Durante esta interacción, estas
personas asumen un papel específico para realizar una tarea; por ejemplo, el
comprador del producto. El mapeo de la relación de componentes-función de
aplicación es un paso importante, ya que permite que el siguiente tenga lugar:  
  Asignar el uso de aplicaciones a las funciones específicas en la organización 
Entender los requisitos de seguridad de la aplicación de los servicios y procesos
de apoyo a la función de negocio, y se les trata de acuerdo con la política actual 
Apoyar el análisis de las deficiencias y determinar si alguna de las aplicaciones
están desaparecidos y como consecuencia es necesario crear  Definir el conjunto de
aplicaciones que utiliza una función de negocio en particular; esencial en
cualquier movimiento hacia la computación basada en roles 

La matriz de roles / aplicaciones es una tabla de dos dimensiones con Logical

componente de aplicación en un eje y Papel en el otro eje. La relación entre estas
dos entidades es un compuesto de un número de relaciones metamodelo que necesitan
validar:    Papel accede Función   Función es limitado por servicio   Los
servicios se realizan por componentes de aplicación lógicas / físicas  

Matrix Aplicación / Función

El propósito de la matriz de Uso / función es representar la relación entre las

aplicaciones y funciones de negocios dentro de la empresa. Funciones de negocio son
realizadas por unidades organizativas. Algunas de las funciones y los servicios
financieros serán mantenidos por las aplicaciones. El mapeo de la relación de
componentes-función de aplicación es un paso importante, ya que permite lo
siguiente a tener lugar:   Asignar el uso de aplicaciones a las funciones de
negocio que son compatibles con ellos  Comprender los requisitos de soporte de
aplicaciones de los servicios de negocios y procesos llevados a cabo 

  Página 397 de 670 

TOGOF 9.1    
  Apoyar el análisis de las deficiencias y determinar si alguna de las
aplicaciones están desaparecidos y como consecuencia es necesario crear  Definir el
conjunto de aplicaciones utilizado por una empresa particular la función 

La matriz de aplicación / función es una tabla de dos dimensiones con lógica

componente de aplicación en un eje y Función en el otro eje. La relación entre
estas dos entidades es un compuesto de un número de relaciones metamodelo que
necesitan validar:   Función es limitado por servicio   Los servicios se realizan
por componentes de aplicación lógicas / físicas  

Aplicación matriz de interacción

El propósito de la matriz de interacción de aplicaciones es para representar

relaciones de comunicación entre aplicaciones. El mapeo de las interacciones de las
aplicaciones muestra en la matriz de formar el equivalente de la Catálogo de
interfaz o un diagrama de comunicaciones de la aplicación. La matriz de la
interacción de aplicaciones es una tabla de dos dimensiones con servicios de
aplicaciones, Logical componente de aplicación, y Física componente de aplicación
en las filas y las columnas de la tabla. Las relaciones representadas por esta
matriz incluyen:    Application Service consume Application Service   Lógico
componente de aplicación se comunica con Logical componente de aplicación   Física
componente de aplicación se comunica con Física componente de aplicación  

Aplicación Diagrama Comunicación

El propósito del diagrama de comunicaciones de la aplicación es para representar

todos los modelos y las asignaciones relacionadas con la comunicación entre las
aplicaciones en la entidad metamodelo. Muestra los componentes de aplicaciones e
interfaces entre los componentes. Las interfaces pueden estar asociados con las
entidades de datos en su caso. Las aplicaciones pueden estar asociados con los
servicios de negocio en su caso. La comunicación debe ser lógica y sólo debe
mostrar la tecnología intermedia donde es arquitectónicamente relevante.
Solicitud y usuario Ubicación Diagrama

El Esquema de aplicación y usuario Ubicación muestra la distribución geográfica de

las solicitudes. Se puede utilizar para mostrar donde las aplicaciones se utilizan
por el usuario final; la

  Página 398 de 670 

TOGOF 9.1    
distribución de donde se ejecuta y / o entrega en los escenarios de cliente ligero
de la aplicación host; la distribución de donde se desarrollan aplicaciones,
probados y puestos en libertad; etcétera El análisis puede revelar oportunidades
para la racionalización, así como la duplicación y / o lagunas. El propósito de
este diagrama es representar claramente las ubicaciones de la empresa de la que los
usuarios de negocios por lo general interactúan con las aplicaciones, sino también
la ubicación de alojamiento de la infraestructura de aplicaciones. El diagrama
permite:     Identificación del número de instancias de paquetes necesarios
para soportar suficientemente la población de usuarios que pueden estar dispersas
geográficamente  Estimación del número y el tipo de licencias de usuario para el
paquete u otro software  Estimación del nivel de apoyo necesario para los usuarios
y la ubicación de centro de apoyo  Selección de las herramientas de administración
del sistema, la estructura y el sistema de gestión necesarios para apoyar las
empresas los usuarios / clientes / socios tanto a nivel local como a distancia  La
planificación adecuada para los componentes tecnológicos de la empresa, es decir,
el ancho de banda tamaño del servidor y de la red, etc  Consideraciones sobre el
rendimiento, mientras que la implementación de soluciones de arquitectura de
aplicaciones y tecnología 

 

Normalmente, los usuarios interactúan con las aplicaciones en una variedad de

maneras; por ejemplo:      Para apoyar las operaciones de los negocios del día
a día  Para participar en la ejecución de un proceso de negocio  Para tener acceso
a la información (búsqueda, lectura)  Para desarrollar la aplicación  Administrar y
mantener la aplicación 

Diagrama de Casos de Uso

Un Esquema de aplicación de casos de uso muestra las relaciones entre consumidores

y proveedores de servicios de aplicación. Los servicios de aplicación son
consumidos por los actores u otros servicios de la aplicación y el diagrama de
casos de uso de aplicaciones proporciona riqueza agregada en la descripción de
funciones de la aplicación mediante la ilustración de cómo y cuándo se utiliza esa
funcionalidad.

  Página 399 de 670 

TOGOF 9.1    
El propósito del diagrama de aplicación de casos de uso es ayudar a describir y
validar la interacción entre los actores y sus roles con las aplicaciones. Como la
arquitectura avanza, el caso de uso puede evolucionar a partir de información
funcional para incluir detalles realización técnica. Aplicación casos de uso
también pueden ser reutilizadas en los sistemas más detallado trabajo de diseño.
Empresa Manejabilidad Diagrama
El diagrama muestra cómo la empresa de administración de una o más aplicaciones
interactúan con aplicaciones y tecnología de componentes que soportan la gestión
operativa de una solución. Este diagrama es realmente un filtro en el diagrama de
comunicaciones de la aplicación, en concreto para el software de clase de gestión
empresarial. El análisis puede revelar duplicaciones y lagunas y oportunidades en
la operación de gestión de servicios de TI de una organización.
Realización de proceso / aplicación Diagrama

El propósito del diagrama Realización Proceso / aplicación es de representar

claramente la secuencia de eventos cuando múltiples aplicaciones están implicados
en la ejecución de un proceso de negocio. Realza el diagrama de comunicaciones de
la aplicación añadiéndole las restricciones de secuenciación, y los puntos de la
mano-off entre lotes y procesamiento en tiempo real. Sería identificar secuencias
complejas que podrían simplificarse, e identificar posibles puntos de
racionalización en la arquitectura con el fin de proporcionar información más
oportuna a los usuarios de negocios. También puede identificar las mejoras en la
eficiencia de procesos que pueden reducir el tráfico de la interacción entre
aplicaciones.
Software Diagrama Ingeniería

El diagrama de la Ingeniería del Software rompe aplicaciones en paquetes, los

módulos, los servicios y las operaciones desde una perspectiva de desarrollo.
Permite a un análisis más detallado del impacto en la planificación de las etapas
de la migración, y el análisis de las oportunidades y soluciones. Es ideal para los
equipos de desarrollo de aplicaciones y equipos de gestión de aplicaciones en la
gestión de los entornos de desarrollo complejos.
Diagrama de aplicación de Migración

El diagrama de Migración de aplicaciones identifica la migración de aplicaciones de

línea de base a los componentes de la aplicación. Permite a una estimación más
precisa de los costos de migración al mostrar con precisión qué se deben asignar
entre las etapas de migración de aplicaciones e interfaces.

  Página 400 de 670 

TOGOF 9.1    
Sería identificar aplicaciones temporales, áreas de estacionamiento, y la
infraestructura necesaria para apoyar las migraciones (por ejemplo, entornos de
ejecución paralelas, etc.)
Diagrama de distribución de software

El diagrama de distribución de software, se muestra cómo el software de aplicación

se estructura y se distribuye a través de la finca. Es útil en la actualización de
los sistemas o de los proyectos de consolidación de aplicaciones. Este diagrama
muestra cómo las aplicaciones físicas se distribuyen a través de la tecnología
física y de la ubicación de esa tecnología. Esto permite una visión clara de cómo
se encuentra alojado el software, sino que también permite que gestiona el personal
de operaciones pueda comprender como que el software de aplicación se mantiene una
vez instalado.

35.6.6 Fase D: Architecture Tecnología

La siguiente sección describe los catálogos, matrices y diagramas que se pueden
crear dentro de la Fase D (Architecture Technology) que se enumeran en 12.5 Salidas
.

Catálogo de Estándares de Tecnología

El catálogo de Estándares de Tecnologías documenta las normas acordadas para la

tecnología en toda la empresa que cubren las tecnologías y las versiones, los
ciclos de vida de la tecnología, y los ciclos de actualización de la tecnología.
Dependiendo de la organización, esto también puede incluir la ubicación o dominio
específico de información comercial estándares. Este catálogo ofrece una visión
general de las tecnologías estándares de la empresa que son o pueden ser
desplegados, y también ayuda a identificar las discrepancias en toda la empresa. Si
los estándares de tecnología están actualmente en vigor, se aplican estos para el
catálogo Cartera Tecnológica para obtener una visión de base del cumplimiento de
los estándares tecnológicos. El catálogo Cartera Tecnológica contiene las
siguientes entidades metamodelo:    Plataforma de Servicios  Lógico Componente
Tecnología  Componente Tecnología Física 

  Página 401 de 670 

TOGOF 9.1    
Catálogo Cartera Tecnológica

La finalidad de este catálogo es identificar y mantener una lista de toda la

tecnología en uso en toda la empresa, incluyendo hardware, software de
infraestructura y software de aplicación. Una cartera de tecnología acordado apoya
la gestión del ciclo de vida de productos de tecnología y versiones, y también es
la base para la definición de estándares de tecnología. El catálogo Cartera
Tecnológica proporciona una base sobre la cual basar las matrices y diagramas
restantes. Normalmente es el punto de inicio de la fase de Tecnología de la
Arquitectura. Registros de tecnología y bases también proporcionan aportación a
este catálogo de una línea de base y se dirigen a la perspectiva. Tecnologías en el
catálogo deben clasificarse en contra de la tecnología Modelo de Referencia TOGAF
(TRM) - véase la parte VI , 43. Fundación Arquitectura: Modelo de referencia
técnica - la extensión del modelo según sea necesario para ajustarse a la
clasificación de los productos de la tecnología en uso. El catálogo Cartera
Tecnológica contiene las siguientes entidades metamodelo:    Plataforma de
Servicios  Lógico Componente Tecnología  Componente Tecnología Física 

Aplicación / Matrix Tecnología

La matriz de Aplicación / Tecnología documenta el mapeo de aplicaciones para la

plataforma tecnológica. Esta matriz debe estar alineada con y complementar uno o
varios diagramas de descomposición de la plataforma. La Aplicación / matriz
Tecnología muestra:    Componentes lógicos de aplicación / Física  Servicios,
Componentes Tecnológicos lógicos y Componentes Tecnología Físicas  Tecnología del
componente físico se da cuenta de las relaciones de componente de aplicación de
Física  

Entornos y diagrama de las ubicaciones

El diagrama de ambientes y zonas representa qué lugares albergan las aplicaciones,

lo que identifica las tecnologías y / o aplicaciones que se utilizan en las
ubicaciones y, finalmente, identifica los lugares desde los que los usuarios de
negocios por lo general interactúan con las aplicaciones.

  Página 402 de 670 

TOGOF 9.1    
Este diagrama también debe mostrar la existencia y ubicación de los diferentes
entornos de implementación, incluyendo entornos no productivos, como el desarrollo
y la producción de pre.
Plataforma Descomposición Diagrama
El diagrama de la Plataforma de descomposición representa la plataforma tecnológica
que soporta las operaciones de la Arquitectura de Sistemas de Información. El
esquema cubre todos los aspectos de la plataforma de infraestructura y proporciona
una visión general de la plataforma tecnológica de la empresa. El diagrama se puede
ampliar para mapear la plataforma de tecnología para componentes de aplicación
apropiadas dentro de un área funcional o proceso específico. Este diagrama puede
mostrar detalles de las especificaciones, como las versiones de producto, número de
CPU, etc, o simplemente podría ser un "ojo-chart" informal que proporciona una
visión general del entorno técnico. El diagrama debe mostrar claramente las
aplicaciones empresariales y la plataforma de tecnología para cada área de
aplicación más se puede descomponer de la siguiente manera:  Hardware:  o o 
Componentes tecnológicos lógicos (con atributos)  Componentes tecnológicos física
(con atributos) 

Software:  o o Componentes tecnológicos lógicos (con atributos)  Componentes

tecnológicos física (con atributos) 

Dependiendo del alcance de la obra de arquitectura empresarial, la tecnología de la

información adicional entre plataformas (por ejemplo, comunicaciones,
telecomunicaciones y la información de video) se puede abordar.
Diagrama de Procesamiento

El diagrama de procesamiento se centra en unidades de despliegue de código /

configuración y cómo éstas se implementan en la plataforma tecnológica. Una unidad
de implementación representa la agrupación de las funciones de negocios, servicio,
o componentes de la aplicación. El diagrama de procesamiento se dirige a la
siguiente:    Que deben ser agrupados conjunto de componentes de la aplicación
para formar una unidad de despliegue  Como una unidad de despliegue conecta /
interactúa con otro (LAN, WAN, y los protocolos aplicables)  Como formas de
configuración de la aplicación y uso generan requerimientos de carga o de capacidad
para los distintos componentes de la tecnología 

La organización y agrupación de unidades de implementación depende de las

preocupaciones de separación de la presentación, lógica de negocio y almacenamiento
de datos capas y los requisitos

  Página 403 de 670 

TOGOF 9.1    
de nivel de servicio de los componentes. Por ejemplo, unidad de despliegue capa de
presentación se agrupa en base a la siguiente:   Los componentes de aplicación
que proporcionan funciones de interfaz de usuario o de acceso de usuarios  Los
componentes de aplicación que se diferencian por ubicación y funciones de usuario 

Hay varias consideraciones para determinar cómo se agrupan los componentes de

aplicaciones. Cada unidad de despliegue se compone de sub-unidades, tales como:  
 Instalación : Parte que contiene el código ejecutable o configuración de paquetes
(en el caso de los paquetes).  Ejecución : el componente de la aplicación con su
estado asociado en tiempo de ejecución.  Persistencia : Los datos que representa el
estado persistente de la componente de la aplicación. 

Por último, estas unidades de implementación se implementan en los componentes

tecnológicos y dedicar o compartidos (estación de trabajo, servidor web, servidor
de aplicaciones o servidor de base de datos, etc.) Es importante tener en cuenta
que el procesamiento de la tecnología puede influir y repercutir en la definición
de servicios y granularidad.
Red Informática / Hardware Diagrama
A partir de la transformación de los sistemas cliente-servidor de mainframes y más
tarde con la llegada del e-Business y J2EE, las grandes empresas movido
principalmente en un entorno distribuido de computación en red altamente red basada
en servidores de seguridad y zonas desmilitarizadas. En la actualidad, la mayoría
de las aplicaciones tienen un front-end web y, mirando a la arquitectura de
implementación de estas aplicaciones, es muy común encontrar tres capas distintas
en el panorama de la red; a saber, una capa de presentación de la tela, una lógica
de negocio o capa de aplicación, y una capa de almacenamiento de datos back-end. Es
una práctica común para las aplicaciones que se desplegarán y alojados en un
entorno de infraestructura compartida y común. Por lo que es muy crítico para
documentar la correspondencia entre las aplicaciones lógicas y los componentes de
la tecnología (por ejemplo, servidores) que apoya la aplicación tanto en los
entornos de desarrollo y producción. El propósito de este diagrama es para mostrar
la vista lógica "como desplegado" de componentes de aplicaciones lógicas en un
entorno informático de red distribuida. El diagrama es útil para las siguientes
razones:    Habilitar la comprensión de que la aplicación se implementa en donde
en el entorno informático de red distribuida  El establecimiento de la
autorización, la seguridad y el acceso a estos componentes de la tecnología 
Entender la Arquitectura Tecnología que soporta las aplicaciones durante la
resolución de problemas y solución de problemas 

  Página 404 de 670 

TOGOF 9.1    
 Aislar los problemas de rendimiento encontradas por las aplicaciones, determine
si es relacionado con el código de la aplicación o relacionada con la plataforma de
la tecnología, y realizar la actualización necesaria para los componentes
específicos de la tecnología física  Identificar las áreas de optimización a medida
que las nuevas tecnologías están disponibles que eventualmente reducir costos 
Habilitar application / tecnología de auditación y acreditar el cumplimiento de las
normas de tecnología de la empresa  Servir como una herramienta importante para
introducir cambios en la arquitectura de la tecnología, de tal modo apoyando la
gestión del cambio efectiva  Establecer la trazabilidad y el cambio de dirección de
punto final de la aplicación mientras se mueve la aplicación ya sea de un entorno
compartido de un entorno dedicado o viceversa  

   

El alcance del diagrama puede ser definido apropiadamente para cubrir una
aplicación específica, la función de negocios, o toda la empresa. Si es elegido
para ser desarrollado en el ámbito de la empresa, entonces el panorama de la
informática de la red puede ser representado de una manera agnóstica aplicación
también.
Comunicaciones Diagrama Ingeniería

El diagrama de Ingeniería de Comunicaciones se describen los medios de comunicación

- el método de envío y recepción de información - entre estos activos en la
Arquitectura de Tecnología; siempre que la selección de paquetes de soluciones en
las arquitecturas anteriores imponer requisitos específicos sobre las
comunicaciones entre las aplicaciones. El diagrama de Ingeniería de Comunicaciones
tendrá conexiones lógicas entre el cliente y componentes de servidor y de
identificar los límites de la red y la infraestructura de red necesaria para
implementar físicamente esas conexiones. No describe el formato de la información o
el contenido, pero se ocupará de cuestiones de protocolo y de capacidad.

35.6.7 Fase E: Oportunidades y Soluciones

La siguiente sección describe los catálogos, matrices y diagramas que se pueden
crear dentro de la Fase E (Oportunidades y Soluciones) que se enumeran en 13.5
Salidas .
Proyecto Diagrama de Contexto

Un diagrama de contexto del proyecto se muestra el alcance de un paquete de trabajo

para ser implementado como parte de un plan más amplio de transformación. El
diagrama de contexto del proyecto vincula un paquete de trabajo de las
organizaciones, funciones, servicios, procesos, aplicaciones, datos y tecnología
que se agrega, se quita o afectado por el proyecto. El diagrama de contexto del
proyecto es también una valiosa herramienta para la gestión de la cartera de
proyectos y la movilización de proyectos.
Diagrama de Beneficios

  Página 405 de 670 

TOGOF 9.1    
El diagrama muestra Beneficios oportunidades identificadas en la definición de la
arquitectura, que se clasifica en función de su tamaño relativo, el beneficio y la
complejidad. Este diagrama puede ser utilizado por los interesados para hacer la
selección, priorización y secuenciación de las decisiones sobre las oportunidades
identificadas.

Gestión 35.6.8 Requisitos

La siguiente sección describe los catálogos, matrices y diagramas que se pueden
crear dentro de la fase de gestión de requisitos que se enumeran en 17.5 Salidas .
Requisitos del catálogo

El catálogo Requisitos capta las cosas que la empresa tiene que hacer para cumplir
con sus objetivos. Requisitos generados a partir de la arquitectura compromisos se
aplican normalmente a través de las iniciativas de cambio identificados y con
ámbito en la Fase E (Oportunidades y Soluciones). Los requisitos también pueden ser
utilizados como una herramienta de control de calidad para asegurarse de que una
arquitectura particular, es apto para el propósito (es decir, la arquitectura puede
cumplir todos los requisitos identificados). El catálogo contiene los requisitos de
las siguientes entidades metamodelo:     Requisito  Asunción  Restricción 
Brecha 

35.7 Vistas Arquitectura recomendados para ser desarrollados

Parte III , 24. Gestión de los grupos de interés se presenta un resumen de los
principales grupos de interés que se encuentran normalmente en el desarrollo de la
arquitectura empresarial. Los probables preocupaciones de cada grupo de interés
también son identificados junto con los artefactos pertinentes (catálogos, matrices
y diagramas). Los puntos de vista de arquitectura, y puntos de vista
correspondientes, que se pueden crear para apoyar cada uno de estos grupos de
interés se dividen en las siguientes categorías:  Vistas Arquitectura Profesiones,
que abordan las preocupaciones de los usuarios del sistema, y describen los flujos
de información empresarial entre las personas y los procesos de negocio  Puntos de
vista de arquitectura de datos, que responden a las preocupaciones de los
diseñadores de bases de datos y administradores de bases de datos e ingenieros de
sistemas responsables de desarrollo e integración de los distintos componentes de
bases de datos del sistema  Vistas arquitectura de la aplicación, que abordan las
preocupaciones de los sistemas y software ingenieros responsables del desarrollo y
la integración de los diversos componentes de software de aplicación del sistema
de 


  Página 406 de 670 

TOGOF 9.1    
 Vistas Arquitectura Tecnología, que abordan las preocupaciones de los compradores
(el personal de adquisiciones responsables de la adquisición de la Commercial Off-
The-Shelf (COTS) de software y hardware que se incluirán en el sistema), el
personal de operaciones, administradores de sistemas y administradores de sistemas 

En las siguientes subsecciones TOGAF presenta algunas vistas recomendadas, algunos

o todos de los cuales pueden ser apropiadas en un desarrollo de la arquitectura en
particular. Esto no pretende ser un conjunto exhaustivo de puntos de vista, sino
simplemente como un punto de partida. Los descritos podrán complementarse con
visitas adicionales según sea necesario. Este material debe ser considerado como
guías para el desarrollo y el tratamiento de una vista, no como una definición
completa de un punto de vista. Los artefactos identificados en 35.6 Architectural
Artifacts por ADM fase se pueden utilizar para hacer frente a las preocupaciones
específicas de los grupos de interés, y en algunos casos los artefactos se pueden
utilizar con la vista del mismo nombre; por ejemplo, el diagrama de Ingeniería de
Software, Ingeniería de Comunicaciones diagrama, y el diagrama de la Empresa de
administración. Cada subsección se describen los grupos de interés relacionados con
la vista, sus preocupaciones y las entidades modeladas y el lenguaje utilizado para
describir la vista (el punto de vista). El mirador ofrece conceptos de arquitectura
de los diferentes puntos de vista, incluidos los componentes, interfaces y
asignación de los servicios esenciales para la vista. Los idiomas punto de vista,
los métodos analíticos, y de modelado métodos asociados con vistas se aplican
típicamente con el uso de herramientas apropiadas.

35.7.1 Desarrollo de una arquitectura empresarial Visualizar

El punto de vista de la Arquitectura de Negocios se ocupa de atender las
preocupaciones de los usuarios.
35.7.1.1 Las partes interesadas y Preocupaciones

Este punto de vista debe ser desarrollado para los usuarios. Se centra en los
aspectos funcionales del sistema desde la perspectiva de los usuarios del sistema.
Responder a las expectativas de los usuarios incluye la consideración de los
siguientes: Personas  Los aspectos de recursos humanos del sistema. Examina los
actores humanos involucrados en el sistema.  Proceso  Se ocupa de los procesos de
usuario que intervienen en el sistema.  Función  Se ocupa de las funciones
requeridas para soportar los procesos.  Información de contacto  Se ocupa de la
información necesaria para fluir en apoyo de los procesos. 

  Página 407 de 670 

TOGOF 9.1    
Usabilidad  Considera los aspectos de usabilidad del sistema y de su entorno. 
Rendimiento  Considera los aspectos de rendimiento del sistema y de su entorno. 
35.7.1.2 Desarrollo de la Vista

Escenarios de negocios (véase la Parte III , 26. Escenarios empresariales y

objetivos de la empresa ) son una técnica importante que puede utilizarse antes y
como un insumo clave para el desarrollo de la vista de arquitectura de negocio,
para ayudar a identificar y entender las necesidades del negocio, y por lo tanto
para obtener los requerimientos del negocio y las limitaciones que el desarrollo de
la arquitectura tiene que abordar. Escenarios de negocios son una manera muy útil
para describir lo que debe suceder cuando se planifican y se producen
acontecimientos imprevistos. Es altamente recomendable que los escenarios de
negocio pueden crear para el cambio planificado, y para el cambio no planificado.
La siguiente sección describe algunas de las cuestiones clave que el arquitecto
podría tener en cuenta al construir escenarios de negocio.
35.7.1.3 Cuestiones clave

La vista Business Architecture considera los aspectos funcionales del sistema; es

decir, lo que el nuevo sistema se pretende hacer. Esto puede ser construido a
partir de un análisis del entorno existente y de los requisitos y limitaciones que
afectan al nuevo sistema. Los nuevos requisitos y limitaciones aparecerán a partir
de un número de fuentes, incluyendo posiblemente:     Existentes
especificaciones internas y las listas de productos aprobados  Metas y objetivos de
negocio  Actividades de reingeniería de procesos de negocio  Los cambios en la
tecnología 

Lo que debería salir de la vista de arquitectura de negocio es una comprensión

clara de los requisitos funcionales de la nueva arquitectura, con frases como: "Se
necesitan mejoras en el manejo de consultas de los clientes a través del uso más
amplio de integración computadora / telefonía". La vista Business Architecture
considera los aspectos de usabilidad del sistema y de su entorno. . También debe
tener en cuenta los impactos sobre el usuario, tales como los niveles de
cualificación requeridos, la necesidad de formación especializada, y la migración
de la práctica actual Al considerar la usabilidad del arquitecto debería tener en
cuenta:  El, y cómo intuitiva facilidad de uso de la interfaz de usuario es 

  Página 408 de 670 

TOGOF 9.1    
       Sea o no un acceso transparente a los datos y aplicaciones,
independientemente de la ubicación  La facilidad de gestión del entorno de usuario
por el usuario  Interoperabilidad de aplicaciones a través de medios tales como
arrastrar y soltar  Servicios de ayuda en línea  La claridad de la documentación 
Seguridad y contraseña aspectos, tales como evitar la necesidad de múltiples
cuadros de diálogo de inicio de sesión y contraseña  El acceso a las aplicaciones
de productividad, como el correo o una hoja de cálculo 

Tenga en cuenta que, aunque la seguridad y la gestión se cree por aquí, es desde el
punto de vista de la facilidad de uso y funcionalidad. Los aspectos técnicos de la
seguridad y la gestión son considerados en la vista de seguridad de la empresa (ver
35.7.2 Desarrollar un Vista Enterprise Security ) y la visión empresarial de
administración (ver 35.7.7 Desarrollo de una empresa de administración Ver ).

35.7.2 Desarrollo de un Vista Enterprise Security

La vista Enterprise Security se ocupa de los aspectos de seguridad del sistema.
35.7.2.1 Las partes interesadas y Preocupaciones

Este punto de vista se debe desarrollar para los ingenieros de seguridad del
sistema. Se centra en cómo se implementa el sistema desde el punto de vista de la
seguridad, y cómo afecta a la seguridad de las propiedades del sistema. Se examina
el sistema para establecer qué información es almacenada y procesada, lo valioso
que es, lo que las amenazas existen, y cómo se pueden abordar. Las principales
preocupaciones de este punto de vista son la comprensión de cómo asegurarse de que
el sistema está disponible sólo a aquellos que tienen permiso, y cómo proteger el
sistema contra cambios no autorizados.
35.7.2.2 Desarrollo de la Vista

Los temas de la arquitectura general de un "sistema de seguridad" son componentes

que están asegurados, o componentes que proporcionan servicios de seguridad.Además
Listas de control de acceso (ACL) y definiciones de esquema de seguridad se
utilizan para modelar e implementar la seguridad.
35.7.2.3 Conceptos Básicos

En esta sección se presentan los conceptos básicos necesarios para la comprensión

de la seguridad del sistema de información.

  Página 409 de 670 

TOGOF 9.1    
La esencia de la seguridad es el uso controlado de la información. El propósito de
esta sección es proporcionar una breve descripción de cómo se lleva a cabo la
protección de seguridad de los componentes de un sistema de información. Mecanismos
doctrinales o de procedimiento, tales como los procedimientos y políticas de
seguridad físicas y de personal, no se discuten aquí en profundidad. La Figura 35-4
muestra una vista abstracta de una Arquitectura de Sistemas de la Información, que
hace hincapié en el hecho de que un sistema de información desde la perspectiva de
la seguridad es ya sea parte de un entorno local de abonado (LSE) o una Red de
Comunicaciones (CN). Un LSE puede ser fijo o móvil. Las empresas grandes, por
definición, están bajo el control de la organización utilizando. En una aplicación
de computación distribuida de sistemas abiertos, casi con toda seguridad se
requerirán LSE seguras y no seguras para interoperar.

  Figura 35‐4: Abstracto Seguridad Arquitectura Vista 
Dominios de Información

El concepto de un dominio de información proporciona la base para la discusión de

los requisitos de protección de la seguridad. Un dominio de la información se
define como un conjunto de usuarios, sus objetos de información, y una política de
seguridad. Una política de seguridad de la información de dominio es la declaración
de los criterios de adhesión en el ámbito de la información y la protección
necesaria de los objetos de información. Rompiendo la información de una
organización hasta en dominios es el primer paso en la reducción de la tarea de la
elaboración de políticas de seguridad a un tamaño manejable. El negocio de la
mayoría de las organizaciones requiere que sus miembros operan en más de un dominio
de información. La diversidad de las actividades comerciales y la variación en la
percepción de las amenazas a la seguridad de la información dará lugar a la
existencia de diferentes dominios de información dentro de una política de
seguridad de la organización. Una actividad específica puede utilizar varios
dominios de información, cada uno con su propia información distinta la política de
seguridad de dominio. Dominios de información no están necesariamente limitadas por
los sistemas de información o incluso redes de sistemas. Los mecanismos de
seguridad implementados en los componentes del sistema de información pueden ser
evaluados por su capacidad para cumplir con las políticas de seguridad de dominio
de información.

  Página 410 de 670 

TOGOF 9.1    
Aislamiento Estricto

Dominios de información puede ser vista como estrictamente aislados unos de otros.
Objetos de información deben ser transferidos entre dos dominios de información
sólo de acuerdo con las reglas establecidas, condiciones y procedimientos
expresados en la política de seguridad de cada dominio de la información.
Protección Absoluta

El concepto de "protección absoluta" se utiliza para lograr el mismo nivel de

protección en todos los sistemas de información de apoyo a la información de
dominio particular. Se llama la atención sobre los problemas creados por la
interconexión de las empresas grandes que proporcionan diferentes puntos fuertes de
protección de seguridad. Esta interconexión es probablemente porque los sistemas
abiertos pueden consistir en un número indeterminado de empresas grandes
heterogéneos. Análisis de los requisitos mínimos de seguridad se asegurará de que
el concepto de protección absoluta se conseguirá para cada dominio de información a
través de las empresas grandes.
35.7.2.4 Generic Security Architecture Vista

La Figura 35-5 muestra una vista de la arquitectura genérica que puede ser
utilizado para discutir la asignación de los servicios de seguridad y la
implementación de mecanismos de seguridad. Este punto de vista se identifican los
componentes de la arquitectura dentro de una LSE. Las empresas grandes están
conectados por la CNS.Las empresas grandes son los sistemas finales, sistemas de
retransmisión y Sistemas Locales de Comunicaciones (LCS), que se describen a
continuación.

  Figura 35‐5: Generic Security Architecture Vista 
 Relay System (RS) : El componente de la LSE, cuya funcionalidad se limita a la
transferencia de información y es sólo indirectamente accesible por los usuarios
(por ejemplo, router, switch, multiplexor, Agente de transferencia de mensajes
(MTA)). Se puede tener una funcionalidad similar a un sistema final, sino un
usuario final no utilizarlo directamente. Tenga en cuenta que las funciones del
sistema de relé se pueden proporcionar en un sistema final. 

  Página 411 de 670 

TOGOF 9.1    
 Sistema de Comunicación Local (LCS) : Una red que proporciona capacidades de
comunicación entre las empresas grandes o dentro de un LSE con todos los
componentes bajo el control de un LSE.  Red de Comunicaciones (CN) : Una red que
proporciona inter-LSE capacidades de comunicación, pero no es controlado por las
empresas grandes (por ejemplo, los transportistas comerciales). 

El sistema de cierre y el sistema de relé son vistos como que requiere el mismo
tipo de protección de seguridad. Por esta razón, una discusión de la protección de
seguridad en un sistema de extremo generalmente también se aplica a un sistema de
relé. Las protecciones de seguridad en un sistema final podría ocurrir en el
hardware y el software.
35.7.2.5 Asignación de Servicios de Seguridad

La protección de seguridad de un sistema de información es proporcionada por los

mecanismos implementados en el hardware y el software del sistema y por el uso de
los mecanismos doctrinales. Los mecanismos implementados en el hardware y el
software del sistema se concentran en el sistema final o sistema de relé. Este
enfoque para la protección de seguridad se basa en el sistema abierto, el enfoque
de computación distribuida para sistemas de información. Esto implica el uso de
portadores comunes comerciales y sistemas de comunicación de uso común privadas
como el proveedor de CN entre las empresas grandes. Por lo tanto, para la operación
de sistemas de extremo en un entorno distribuido, un mayor grado de protección de
seguridad puede asegurarse de la aplicación de mecanismos en el sistema final o
sistema de relé. Sin embargo, las redes de comunicación deben satisfacer el
elemento de disponibilidad de la seguridad con el fin de proporcionar una
protección de seguridad adecuada para el sistema de información. Esto significa que
los CN debe proporcionar un nivel acordado de la capacidad de respuesta, la
continuidad del servicio, y la resistencia a las amenazas accidentales e
intencionales a la disponibilidad de servicios de comunicaciones. La aplicación de
la protección de la seguridad necesaria en el sistema final se produce en tres
áreas de servicio del sistema de TOGAF. Ellos están operando los servicios del
sistema, servicios de red y servicios de administración de sistemas. La mayor parte
de la implementación de la protección de seguridad se espera que ocurra en el
software. Se espera que el hardware para proteger la integridad del software de
sistema de extremo. Mecanismos de seguridad de hardware incluyen la protección
contra la manipulación, emanaciones no deseadas, y la criptografía.
Servicios del sistema operativo

Un "contexto de seguridad" se define como un proceso controlado el espacio objeto

de una política de seguridad de la información de dominio. Por tanto, el contexto
de seguridad es análogo a una noción de sistema operativo común de espacio de
proceso de usuario. Se requiere aislamiento de contextos de seguridad. Se requieren
los contextos de seguridad para todas las aplicaciones (aplicaciones por ejemplo,
los usuarios finales y la gestión de la seguridad). La atención se centra en el
aislamiento estricto de los dominios de información, gestión de los recursos del
sistema final, y el uso compartido controlado y la transferencia de información
entre los dominios de información. Cuando sea posible, las funciones críticas de
seguridad deben ser aislados en relativamente pequeños módulos que se relacionan de
maneras bien definidas .

  Página 412 de 670 

TOGOF 9.1    
El sistema operativo aislará múltiples contextos de seguridad entre sí mediante
funciones de protección de hardware (por ejemplo, registro de estado del
procesador, registros de asignación de memoria) para crear espacios de direcciones
separados para cada uno de ellos. Software no fiable utilizará recursos del sistema
final sólo invocando funciones críticas de seguridad a través del núcleo de la
separación. La mayor parte de las funciones críticas de seguridad son las funciones
de bajo nivel de los sistemas operativos tradicionales.
Servicios de red

Dos clases básicas de comunicaciones se prevén para los que distribuyen contextos
de seguridad pueden necesitar ser establecida. Estos son interactivos y
protagonizaron (almacenamiento y retransmisión) de comunicaciones. El concepto de
una "asociación de seguridad" constituye un contexto interactivo seguridad
distribuida. Una asociación de seguridad se define como todos los mecanismos de
comunicación y de seguridad y funciones que amplían las protecciones exigidas por
una política de seguridad de la información de dominio dentro de un sistema de
extremo a la información en la transferencia entre múltiples sistemas finales. La
asociación de seguridad es una extensión o ampliación de una asociación de capa de
aplicación de OSI. Una asociación de capa de aplicación se compone de funciones y
protocolos de capa de aplicación apropiadas, además de todas las funciones y
protocolos de comunicaciones subyacentes en otras capas del modelo OSI. Múltiples
protocolos de seguridad pueden ser incluidos en un solo asociación de seguridad
para proporcionar una combinación de servicios de seguridad. Para las
comunicaciones de entrega por etapas (por ejemplo, correo electrónico), se hará uso
de una técnica de encapsulación (denominado "proceso de envoltura") para transmitir
los atributos de seguridad necesaria con los datos que se transfieren como parte de
los servicios de red. Los atributos de seguridad envueltos pretenden permitir que
el sistema extremo receptor para establecer el contexto de seguridad necesarias
para el procesamiento de los datos transferidos. Si el proceso de envoltura no
puede proporcionar toda la protección de la seguridad es necesario, contextos de
seguridad de interacción entre sistemas finales tendrán que ser utilizados para
garantizar la transferencia segura en escena de la información.
Sistema de Servicios de Gestión de la Seguridad

Gestión de la seguridad es un caso particular de las funciones de gestión de

sistemas de información que se analiza en los capítulos anteriores. Servicios de
gestión de la seguridad del sistema de información se refieren a la instalación,
mantenimiento y observancia de dominio de la información y las reglas de política
de seguridad de sistemas de información en el sistema de información destinado a
proporcionar estos servicios de seguridad. En particular, la función de gestión de
la seguridad controla la información que necesitan los servicios del sistema
operativo dentro de la arquitectura de seguridad del sistema final. Además de estos
servicios básicos, gestión de seguridad requiere el manejo de eventos, la auditoría
y la recuperación. La normalización de las funciones de gestión de seguridad,
estructuras de datos y protocolos permitirá la interoperabilidad de los procesos de
aplicación de gestión de seguridad (smaps) a través de muchas plataformas de apoyo
a la gestión de seguridad distribuida.

35.7.3 Desarrollo de un Software Engineering Ver

La vista de la Ingeniería de Software tiene que ver con el desarrollo de nuevos
sistemas de software.

  Página 413 de 670 

TOGOF 9.1    
35.7.3.1 Las partes interesadas y Preocupaciones

La construcción de un sistema de software intensivo es a la vez caro y consume

mucho tiempo. Debido a esto, es necesario establecer directrices para ayudar a
minimizar el esfuerzo requerido y los riesgos involucrados. Este es el propósito de
la vista de la Ingeniería del Software, que debe ser desarrollado para los
ingenieros de software que van a desarrollar el sistema. Las principales
preocupaciones de estos grupos de interés son:     Enfoque de Desarrollo  La
modularidad del software y de re-uso  Portabilidad  Migración e interoperabilidad 

Enfoque de Desarrollo

Hay muchos modelos de ciclo de vida definido para el desarrollo de software

(cascada, prototipos, etc.) Una consideración para el arquitecto es la mejor manera
de alimentar las decisiones arquitectónicas en el modelo de ciclo de vida que va a
ser utilizado para el desarrollo del sistema.
Software Modularidad y Reutilización

Como una pieza de software crece en tamaño, por lo que la complejidad y las
interdependencias entre diferentes partes del aumento de código. Confiabilidad
caerá drásticamente a menos que esta complejidad puede ser controlada. La
modularidad es un concepto por el cual una pieza de software se agrupa en un número
de subunidades distintas y lógicamente cohesivos, la presentación de los servicios
para el mundo exterior a través de una interfaz bien definida. En términos
generales, los componentes de un módulo se compartir el acceso a los datos comunes,
y la interfaz proporcionará el acceso controlado a estos datos. El uso de la
modularidad, se hace posible construir una aplicación de software de forma
incremental en una base fiable de código antes de la prueba. Un beneficio adicional
de un sistema modular bien definida es que los módulos definidos dentro de ella
pueden ser reutilizadas en el mismo o en otros proyectos, cortar drásticamente el
tiempo de desarrollo mediante la reducción tanto en el desarrollo y prueba de
esfuerzo. En los últimos años, el desarrollo de los lenguajes de programación
orientados a objetos se ha incrementado en gran medida el apoyo lenguaje de
programación para el desarrollo del módulo y la reutilización del código. Estos
lenguajes permiten al desarrollador definir "clases" (una unidad de modularidad) de
objetos que se comportan de una manera controlada y bien definido. Técnicas tales
como la herencia - que permite a las partes de una interfaz existente a un objeto
que cambiar - aumentar el potencial de reutilización al permitir que las clases
predefinidas para ser adaptados o ampliados cuando los servicios que ofrecen no
llegan a cumplir con el requisito del desarrollador. Si la modularidad y la
reutilización del software es probable que sean los objetivos principales de los
nuevos desarrollos de software, se debe prestar atención a si las partes que
componen un

  Página 414 de 670 

TOGOF 9.1    
proyecto de arquitectura puede facilitar o prohibir el nivel deseado de la
modularidad en las áreas apropiadas.
Portabilidad

Software portabilidad - la capacidad de tomar un pedazo de software escrito en un

entorno y hacer que se ejecute en otro - es importante en muchos proyectos,
especialmente el desarrollo de productos. Se requiere que todos los aspectos de
software y hardware de una Arquitectura Tecnológica elegido (no sólo la aplicación
de nuevo desarrollo) estarán disponibles en la nueva plataforma. Será, por lo
tanto, ser necesario para asegurar que las partes componentes de cualquier
arquitectura elegida están disponibles a través de todas las plataformas de destino
apropiadas.
Migración e interoperabilidad

La interoperabilidad es siempre necesaria entre las partes componentes de una nueva

arquitectura. También podrá, sin embargo, precisa entre una nueva arquitectura y
las piezas de un sistema heredado existente; Por ejemplo, durante la sustitución
escalonada de un sistema antiguo. La interoperabilidad entre las nuevas y viejas
arquitecturas puede, por lo tanto, ser un factor en la elección de la arquitectura.
35.7.3.2 Cuestiones clave

    

Data-intensiva contra los sistemas de software de información-intensivos   Lograr

la interoperabilidad  Niveles de software  Usos de un nivel de acceso a datos 
Distribución 

Data-Intensive frente a los sistemas de software de información-intensivos

Este punto de vista considera dos categorías generales de sistemas de software. En

primer lugar, están los sistemas que requieren sólo una interfaz de usuario a una
base de datos, que requieren poco o nada de la lógica de negocio integrada en el
software. Estos sistemas pueden ser llamados "uso intensivo de datos." En segundo
lugar, están los sistemas que requieren los usuarios manipular la información que
pueda ser distribuido a través de múltiples bases de datos, y para ello la
manipulación de acuerdo con un predefinido lógica de negocio. Estos sistemas se
pueden llamar "información-intensiva" Sistemas de uso intensivo de datos se pueden
construir con relativa facilidad mediante el uso de herramientas 4GL. En estos
sistemas, la lógica de negocio está en la mente de los usuarios; es decir, el
usuario entiende las reglas para la manipulación de los datos y utiliza esas reglas
mientras que hace su trabajo. Sistemas de información intensiva son diferentes. La
información se define como "datos significativos"; es decir, los datos en un
contexto que incluye la lógica de negocio.La información es diferente de datos. Los
datos son las fichas que están almacenados en bases de datos u otros almacenes de
datos. La información es varias fichas de datos combinados para transmitir un
  Página 415 de 670 

TOGOF 9.1    
mensaje. Por ejemplo, "3" son los datos, pero "3 widgets" es la información.
Normalmente, la información refleja un modelo. Sistemas de información intensiva
también tienden a requerir información de otros sistemas y, si este camino de la
transmisión de información está automatizado, por lo general se requiere un poco de
mediación para convertir el formato de la información que llega a un formato que
puede ser utilizado a nivel local. Debido a esto, los sistemas de información
intensiva tienden a ser más complejos que otros, y requieren el máximo esfuerzo
para construir, integrar y mantener. Este punto de vista se ocupa principalmente de
los sistemas de información intensiva. Además de los sistemas que pueden manejar la
información, a pesar de la construcción, los sistemas también deben ser lo más
flexible posible. Esto tiene una serie de beneficios. Se permite que el sistema
para ser utilizado en diferentes entornos; por ejemplo, el mismo sistema debería
pueda utilizarse con diferentes fuentes de datos, incluso si el nuevo almacén de
datos es una configuración diferente. Del mismo modo, podría tener sentido utilizar
la misma funcionalidad pero con los usuarios que necesitan una interfaz de usuario
diferente. Así los sistemas de información deben ser construidos de manera que
puedan ser reconfigurados con diferentes almacenes de datos o diferentes interfaces
de usuario. Si un sistema está construido para permitir esto, permite a la empresa
a las partes volver a utilizar (o componentes) de un sistema en otro.
El logro de la interoperabilidad

La palabra "interoperar" implica que un sistema de procesamiento realiza una

operación en nombre o bajo requerimiento de otro sistema de procesamiento. En la
práctica, la petición es una oración completa que contiene un verbo (en
funcionamiento) y uno o más sustantivos (identidades de los recursos, donde los
recursos pueden ser la información, datos, dispositivos físicos, etc.)
Interoperabilidad proviene de funcionalidad compartida. Interoperabilidad sólo
puede lograrse cuando se pasa información, no cuando se pasa de datos. La mayoría
de los sistemas de información de hoy en día reciben información tanto de sus
propios almacenes de datos y otros sistemas de información. En algunos casos, la
red de la conectividad entre los sistemas de información es bastante extensa. La
Fuerza Aérea de EE.UU., por ejemplo, tiene un concepto conocido como "La
interoperabilidad A5". Esto significa que los datos requeridos se encuentra
disponible en cualquier momento y en cualquier lugar, por cualquier persona , que
está autorizada, de cualquier manera. Esto requiere que muchos sistemas de
información están vinculados arquitectónicamente y proporcionan información a la
otra. Tiene que haber algún tipo de conectividad física entre los sistemas. Esto
podría ser una red de área local (LAN), una red de área amplia (WAN), o, en algunos
casos, podría ser simplemente el paso de medios de almacenamiento de datos entre
sistemas. Suponiendo una red conecta los sistemas, debe haber un acuerdo sobre los
protocolos utilizados. Esto permite la transferencia de bits. Cuando los bits se
ensamblan en el sistema de recepción, que deben ser colocados en el contexto de que
el sistema de recepción debe. En otras palabras, tanto los sistemas de origen y de
destino deben estar de acuerdo en un modelo de información. El sistema de origen
utiliza este modelo para convertir su información en datos que se pasan, y el
sistema de destino utiliza este mismo modelo para transformar los datos obtenidos
en información que puede utilizar. Esto por lo general requiere de un acuerdo entre
los arquitectos y diseñadores de los dos sistemas. En el pasado, este acuerdo fue a
menudo documentado en la forma de un Documento de Control de Interfaz (ICD). La CIE
define la sintaxis y la semántica exacta de que el sistema de envío utilizará para
que el sistema receptor sabrá qué hacer cuando lleguen los datos. El mayor

  Página 416 de 670 
TOGOF 9.1    
problema con los DCI es que tienden a ser soluciones únicas entre dos sistemas. Si
un sistema dado debe compartir información con notros sistemas, existe la necesidad
potencial de N 2 DAI. Esta integración extremadamente apretado prohíbe la
flexibilidad y la capacidad de un sistema para adaptarse a un entorno cambiante. El
mantenimiento de todos estos DAI es también un desafío. Las nuevas tecnologías,
como el Extensible Markup Language (XML), tiene la promesa de hacer que los datos
de "auto describe". uso de las nuevas tecnologías como XML, una vez que estén
fiable y bien documentada, que podría eliminar la necesidad de un DAI. Además, hay
sería Comercial productos (COTS) disponibles para analizar y manipular los datos
XML Off-The-Shelf, eliminando la necesidad de desarrollar estos productos en el
local. También debe aliviar el dolor de mantener todas las interfaces. Otro enfoque
es la construcción de "mediadores" entre los sistemas. Los mediadores usarían
metadatos que se envía con los datos para comprender la sintaxis y la semántica de
los datos y convertirlos en un formato utilizable por el sistema receptor. Sin
embargo, los mediadores no se requiere que se le envíe metadatos bien formado,
añadiendo a la complejidad de la interfaz.

Niveles de Software

Por lo general, las arquitecturas de software son un bien de dos niveles o de tres
niveles. 2 Cada nivel se presenta típicamente al menos una capacidad.
De dos niveles

En un dos -tier arquitectura, la interfaz de usuario y la lógica de negocio están

estrechamente acopladas mientras los datos se mantiene independiente. Esto le da la
ventaja de permitir que los datos residen en un servidor de datos dedicado. También
permite que los datos se mantienen de forma independiente. El estrecho acoplamiento
de la interfaz de usuario y la lógica de negocio a asegurar que van a trabajar bien
juntos, para este problema en este ámbito. Sin embargo, el estrecho acoplamiento de
la interfaz de usuario y la lógica de negocio aumenta drásticamente los riesgos de
mantenibilidad, mientras que la reducción de la flexibilidad y oportunidades para
su reutilización.
Three-Tier

Un enfoque de tres niveles, añade un nivel que separa la lógica de negocio de la

interfaz de usuario. En principio, esto permite que la lógica de negocio para ser
utilizado con diferentes interfaces de usuario, así como con diferentes almacenes
de datos. Con respecto a la utilización de diferentes interfaces de usuario, los
usuarios podrían querer la misma interfaz de usuario, pero usando diferentes
servidores de presentación COTS; por ejemplo, Java Virtual Machine (JVM). Del mismo
modo, si la lógica de negocio se va a utilizar con distintos almacenes de datos, a
continuación, cada almacén de datos debe utilizar el mismo modelo de datos 3
(estandarización de los datos), o un nivel de mediación debe ser añadido por encima
del almacén de datos (encapsulación de datos).
Cinco Tier

  Página 417 de 670 

TOGOF 9.1    
Para lograr la máxima flexibilidad, el software debería utilizar un esquema de
cinco niveles para el software que amplía el paradigma de tres niveles (ver Figura
35-6 ). Este régimen está destinado a proporcionar una fuerte separación de las
tres principales áreas funcionales de la arquitectura. Puesto que hay de cliente y
servidor aspectos tanto de la interfaz de usuario y el almacén de datos, el esquema
a continuación, tiene cinco niveles. 4 El nivel de presentación es típicamente
basados en COTS. La interfaz de presentación puede ser un servidor de X, Win32, etc
No debe haber un nivel separado para el cliente de interfaz de usuario. Este
cliente establece el look-and-feel de la interfaz; el servidor (capa de
presentación) en realidad lleva a cabo las tareas mediante la manipulación de la
pantalla. El cliente de interfaz de usuario oculta el servidor de presentación de
la lógica empresarial de la aplicación. La lógica empresarial de la aplicación (por
ejemplo, un motor de programación) debe ser un nivel separado. Este nivel se
denomina "lógica de la aplicación" y funciona como un servidor para el cliente de
interfaz de usuario. Se conecta a la interfaz de usuario típicamente a través de
devoluciones de llamada. La capa de lógica de aplicación también funciona como un
cliente para el nivel de acceso a datos. Si hay un usuario necesita utilizar una
aplicación con múltiples bases de datos con diferentes esquemas, entonces se
necesita un nivel diferente para el acceso a datos.Este cliente podría acceder a
los almacenes de datos utilizando la interfaz apropiada COTS 5 y luego convertir
los datos en bruto en un tipo de datos abstracto que representa las partes del
modelo de información. La interfaz de esta red sería entonces objeto proporcionar
una interfaz de acceso a datos generalizada (DAI), que ocultar los detalles de
almacenamiento de los datos de cualquier aplicación que utilice esos datos. Cada
nivel en este esquema puede tener cero o más componentes. La organización de los
componentes dentro de un nivel es flexible y puede reflejar un número de diferentes
arquitecturas basadas en necesidad. Por ejemplo, puede haber muchos componentes
diferentes en el nivel de aplicación de la lógica (programación, contabilidad,
control de inventario, etc) y la relación entre ellos puede consistir en una
arquitectura tiene sentido, pero ninguno de ellos debe ser un cliente para el
servidor de presentación. Esta separación limpia de interfaz de usuario, la lógica
de negocio, y la información dará lugar a la máxima flexibilidad y el software en
componentes que se presta a las prácticas de desarrollo línea de productos. Por
ejemplo, es concebible que la misma funcionalidad debe ser construido de una vez y
sin embargo ser utilizable por diferentes servidores de presentación (por ejemplo,
en los ordenadores o cajas de sistema UNIX), que se muestran con un aspecto
diferente y se siente en función de las necesidades del usuario, y se puede usar
con múltiples bases de datos heredadas . Por otra parte, esta flexibilidad no debe
requerir reescrituras masivas para el software cada vez que se necesita un cambio.

  Página 418 de 670 

TOGOF 9.1    

  Figura 35‐6: La Organización de cinco niveles 
Algunos usos de un nivel de acceso a datos

El nivel de acceso a datos proporciona una vista estandarizada de ciertas clases de

datos, y como tal funciona como un servidor para uno o más niveles lógica de la
aplicación. Si se aplica correctamente, no habría necesidad de que el código de
aplicación "saber" acerca de los detalles de implementación de los datos. El código
de la aplicación sólo tendría que saber acerca de una interfaz que presenta un
nivel de abstracción superior a los datos. Esta interfaz se denomina interfaz de
acceso a datos (DAI). Por ejemplo, en caso de necesitar un motor de programación
para saber qué eventos están programados entre dos fechas, dicha consulta no
debería requerir el conocimiento de tablas y combinaciones en una base de datos
relacional. Por otra parte, el DAI podría proporcionar técnicas de acceso
estandarizados para los datos. Por ejemplo, el DAI podría proporcionar una
publicación y suscripción (P & S) de interfaz mediante el cual los sistemas que
requieren el acceso a almacenes de datos podría registrar un interés en ciertos
tipos de datos, tal vez, en determinadas condiciones, y el DAI podría proporcionar
los datos requeridos cuando se producen esas condiciones .
Una posible instanciación de un DAI

Uno de los medios para crear una instancia de un componente de acceso de datos es
con tres capas, como se muestra en la Figura 35-7 . Este no es el único medio para
construir un DAI, pero se presenta como una posibilidad.

  Página 419 de 670 

TOGOF 9.1    

  Figura 35‐7: Data Access Interface (DAI) 
Mientras que la capa de acceso a datos directo contiene los detalles de
implementación de uno o varios almacenes de datos, la Red de objetos y la capa de
Distribución de la Información no requieren de tal conocimiento. En cambio, las dos
capas superiores reflejan la necesidad de estandarizar la interfaz de un dominio
determinado. La capa de acceso a datos directo extiende la brecha entre el nivel de
acceso a datos y el nivel de almacén de datos, y por lo tanto tiene conocimiento de
los detalles de implementación de los datos. SQL declaraciones, ya sea incrustadas
oa través de una norma como la DRDA u ODBC, se encuentran aquí. La capa de red del
objeto es la creación de instancias de software del modelo de información. Como
tal, es un medio eficaz para mostrar las relaciones que se dan entre piezas de
datos. La traducción de los datos de los accesos a los objetos de la red sería la
función de la capa de acceso a datos directo. Dentro de la capa de Distribución de
la Información se encuentra la interfaz con el "mundo exterior". Esta interfaz
normalmente utiliza un bus de datos para distribuir los datos (véase más adelante).
6 También podría contener diversos servicios relacionados con la información; Por
ejemplo, un registro de P & S y servicio de publicación o una interfaz a un
servidor de seguridad para el control de acceso a datos. 7 la capa de información
de distribución pueden también ser usados para distribuir aplicaciones o applets
requeridos para procesar información distribuida. Los objetos en la red objeto
señalarían las aplicaciones o applets, lo que permite un fácil acceso al código de
procesamiento requerido.
IAA Habilitar Flexibilidad

El DAI permite una arquitectura muy flexible. Capacidades primas múltiples pueden
acceder a los mismos o diferentes almacenes de datos, todo a través de la misma
DAI.Cada DAI podría implementarse de muchas maneras, de acuerdo a las necesidades
específicas de las capacidades de primas que lo usan. Figura 35-8 ilustra una serie
de posibilidades, incluyendo múltiples IAA diferentes en diferentes ámbitos con el
acceso a la misma base de datos, un único DAI acceder a múltiples bases de datos, y
varias instancias de la misma DAI acceden a la misma base de datos.

  Página 420 de 670 

TOGOF 9.1    
No siempre está claro que se necesita un DAI, y que parece requerir un trabajo
adicional durante todas las fases de desarrollo. Sin embargo, si una base de datos
cada vez ser rediseñado, o si una aplicación se va a volver a utilizar y no hay
ningún control sobre cómo se implementa la nueva información, el uso de un DAI
ahorra tiempo en el largo plazo.

  Figura 35‐8: usos múltiples de una interfaz de acceso a datos (IAA) 
Distribución

El modelo de referencia ISO para el procesamiento distribuido abierto (RM-ODP)

ofrece un metaestándar que se pretende permitir normas más específicas que
surjan.Define el modelo de referencia de RM-ODP un conjunto de transparencias de
distribución que sean aplicables a la vista TOGAF Software Engineering.  Acceso
Transparencia máscaras diferencias en la representación de datos y los mecanismos
de invocación para permitir el interfuncionamiento entre objetos. Esta
transparencia resuelve muchos de los problemas de interfuncionamiento entre
sistemas heterogéneos, y por lo general se proporciona de forma predeterminada. 
Transparencia El incumplimiento máscaras de un objeto del fracaso y la posible
recuperación de otros objetos (o sí) para permitir la tolerancia a fallos. Cuando
se proporciona esta transparencia, el diseñador puede trabajar en un mundo
idealizado en el que no se produce la clase correspondiente de fracasos.  Ubicación
Transparencia enmascara el uso de la información sobre la ubicación en el espacio
cuando la identificación y unión a las interfaces. Esta transparencia proporciona
una vista lógica de nombrar, independientemente de la ubicación física real. 
Transparencia Migración máscaras de un objeto de la capacidad de un sistema para
cambiar la ubicación de ese objeto. La migración se utiliza a menudo para alcanzar
el equilibrio de carga y reducir la latencia.  Transparencia Reubicación máscaras
reubicación de una interfaz de otras interfaces asociadas a la misma. Reubicación
permite la operación del sistema para continuar incluso cuando la migración o el
reemplazo de algunos objetos crea inconsistencias temporales en la vista visto por
sus usuarios. 

  Página 421 de 670 

TOGOF 9.1    
 Transparencia de replicación enmascara el uso de un grupo de objetos mutuamente
compatibles conductualmente para sustentar una interfaz. replicación se utiliza a
menudo para mejorar el rendimiento y la disponibilidad.  Transparencia Transacción
máscaras de coordinación de las actividades entre una configuración de los objetos
para lograr consistencia. 

Bus Infraestructura

El bus de la infraestructura representa el middleware que establece la relación de

cliente / servidor. Este software comercial es como un plano posterior en la que
las capacidades se pueden conectar. Un sistema debe cumplir con una aplicación
comercial de un estándar middleware. Esto es para asegurar que las capacidades
utilizando diferentes implementaciones comerciales de la norma pueden interoperar.
Si se utiliza más de una norma comercial (por ejemplo, COM y CORBA), entonces el
sistema debe permitir la interoperabilidad entre las implementaciones de estos
estándares a través del uso de software de puente comercial. 8 Cuando sea posible,
las interfaces deben ser especificados en la adecuada descripción de la interfaz
Idioma (IDL). Tomado de esta forma, todas las interfaces en el esquema de cinco
niveles representa una oportunidad para su distribución. Los clientes pueden
interactuar con los servidores a través del bus de la infraestructura. En esta
interacción, el transporte real de la red (TCP / IP, HTTP, etc), la plataforma /
proveedor del servidor y del sistema operativo del servidor son todos
transparentes.

 
   

 
Página 422 de 670 

TOGOF 9.1     Figura 35‐9: nocional Modelo de Distribución 
35.7.3.3 Conclusión

La vista de la Ingeniería de Software proporciona orientación sobre la forma de

estructurar el software de una manera muy flexible. Siguiendo estas pautas, el
software resultante será por componentes. Esto permite la reutilización de los
componentes en diferentes entornos. Por otra parte, mediante el uso de un bus de
infraestructura y las interfaces limpias, el software resultante será independiente
de la ubicación, lo que permite su distribución a través de una red.

35.7.4 Desarrollo de un sistema de ingeniería Ver

El punto de vista de Ingeniería de Sistemas se ocupa de reunir software y
componentes de hardware en un sistema de trabajo.
35.7.4.1 Las partes interesadas y Preocupaciones

Este punto de vista se debe desarrollar para el personal de ingeniería de sistemas

del sistema, y debe centrarse en cómo se implementa el sistema desde el punto de
vista de hardware / software y redes. Los ingenieros de sistemas están normalmente
preocupados por la ubicación, modificabilidad, reusabilidad y la disponibilidad de
todos los componentes del sistema. El punto de vista de Ingeniería de Sistemas
presenta un número de diferentes formas en que los componentes de software y
hardware se puede montar en un sistema de trabajo. En gran medida, la elección del
modelo determina las propiedades del sistema final. Se ve en la tecnología que ya
existe en la organización, y lo que está disponible en la actualidad o en un futuro
próximo. Esto revela áreas en las que las nuevas tecnologías pueden contribuir a la
función o la eficiencia de la nueva arquitectura, y cómo los diferentes tipos de
procesamiento de la plataforma puede soportar diferentes partes del sistema en
general. Las principales preocupaciones de este punto de vista son la comprensión
de los requisitos del sistema. En general, estos grupos de interés tienen que ver
con garantizar que los componentes adecuados se desarrollan y despliegan dentro del
sistema de una manera óptima. El desarrollo de este punto de vista ayuda en la
selección de las mejores configuraciones para el sistema.
35.7.4.2 Cuestiones clave

Este punto de vista de la arquitectura se centra en los modelos de computación que

son apropiados para un entorno de computación distribuida. Para apoyar la migración
de sistemas heredados, esta sección también presenta modelos que son apropiados
para un entorno centralizado. Las definiciones de muchos de los modelos de
computación (por ejemplo, basado en host, maestro / esclavo, y de tres niveles)
históricamente precedieron a la definición del modelo de cliente / servidor, que
trata de ser un modelo de propósito general. En la mayoría de los casos, los
modelos no se han redefinido en la literatura informática en términos de contrastes
con el modelo cliente / servidor. Por lo tanto, algunas de las distinciones de
características no siempre están limpios. En general, sin embargo, los modelos se
distinguen por la asignación de funciones para una aplicación de sistema de
información a los distintos componentes (por ejemplo, terminales,

  Página 423 de 670 

TOGOF 9.1    
plataformas de computación). Estas funciones que componen una aplicación de sistema
de información son la presentación, la función de la aplicación y gestión de datos.
Modelo cliente / servidor

  Figura 35‐10: Básico Modelo Cliente / Servidor 
Procesamiento cliente / servidor es un tipo especial de computación distribuida
denominado "proceso cooperativo", porque los clientes y servidores cooperan en el
procesamiento de una aplicación total de (presentación, procesamiento funcional,
datos de gestión). En el modelo, los clientes son procesos que solicitan servicios
y servidores son procesos que proporcionan servicios. Los clientes y los servidores
pueden estar ubicados en el mismo procesador, diferentes nodos multi-procesador, o
en procesadores separados en ubicaciones remotas. El cliente normalmente inicia las
comunicaciones con el servidor. El servidor normalmente no inicia una petición de
un cliente. Un servidor puede soportar muchos clientes y puede actuar como un
cliente a otro servidor. Figura 35-10 muestra un modelo cliente / servidor de base,
que hace hincapié en las relaciones de solicitud-respuesta. Figura 35-11 muestra el
mismo tipo elaborado siguiendo el TOGAF TRM, mostrando cómo las diversas entidades
e interfaces se pueden utilizar para soportar un modelo de cliente / servidor, si
el servidor es local o remoto para el cliente. En estas representaciones, las
relaciones de solicitud-respuesta se definirían en el API.

  Página 424 de 670 

TOGOF 9.1    

Figura 35‐11: Referencia Modelo Representación de modelo de cliente / servidor 

Los clientes tienden a generalizarse y pueden ejecutarse en uno de los muchos

nodos. Los servidores suelen estar especializados y se ejecutan en un par de nodos.
Los clientes suelen implementarse como una llamada a una rutina. Los servidores se
implementan normalmente como un proceso continuo a la espera de las solicitudes de
servicio (de los clientes). Muchas implementaciones de cliente / servidor implican
comunicaciones remotas a través de una red. Sin embargo, nada en el modelo
cliente / servidor dicta comunicaciones remotas, y la ubicación física de los
clientes es normalmente transparente para el servidor. La comunicación entre un
cliente y un servidor puede implicar una comunicación local entre dos procesos
independientes en la misma máquina. Un programa de aplicación se puede considerar
que constará de tres partes:    El manejo de datos  Función de aplicación 
Presentación 

En general, cada uno de ellos puede ser asignado a un cliente o aplicación de

servidor, haciendo un uso adecuado de los servicios de la plataforma. Esta
asignación define una configuración específica de cliente / servidor.
Master / Slave y Modelos Jerárquicos

En este modelo, los ordenadores esclavos están conectados a un ordenador central.

En cuanto a la distribución, el modelo maestro / esclavo es un paso adelante
respecto al modelo basado en host. La distribución se proporciona en una sola
dirección - del maestro a los esclavos. Los ordenadores esclavos realizan la
tramitación del expediente sólo cuando es dirigido por el equipo maestro. Además,
los procesadores esclavos pueden realizar el procesamiento local limitado, tales
como la edición, procesamiento de tecla de función y la validación del campo. Una
configuración

  Página 425 de 670 

TOGOF 9.1    
típica podría ser una unidad central como el maestro con los PC como los esclavos
que actúan como terminales inteligentes, como se ilustra en la figura 35-12 . El
modelo jerárquico es una extensión del modelo maestro / esclavo con más capacidades
de distribución. En este enfoque, la capa superior es generalmente un mainframe de
gran alcance, que actúa como un servidor para el segundo nivel. La segunda capa
consiste en servidores y clientes de la LAN a la primera capa, así como servidores
de la tercera capa. La tercera capa consiste en PCs y estaciones de trabajo. Este
modelo ha sido descrita como la adición de un verdadero procesamiento distribuido
en el modelo maestro / esclavo. Figura 35-12 muestra un ejemplo modelo jerárquico
en la tercera configuración, y por debajo, la figura 35-13 muestra el modelo
jerárquico representado en términos de las entidades e interfaces de la TRM.

  Figura 35‐12: Host‐Based, Master / Slave y Modelos Jerárquicos 

  Página 426 de 670 

TOGOF 9.1    

   
 

  Figura 35‐13: Modelo jerárquico utilizando el modelo de referencia 
Modelo Peer-to-Peer

En el modelo peer-to-peer existen procesos de coordinación. Todos los equipos son

servidores que puedan recibir las solicitudes de servicios y responder a ellos; y
todos los equipos son clientes, ya que pueden enviar solicitudes de servicios a
otras computadoras. En las implementaciones actuales, a menudo hay funciones
redundantes en las plataformas participantes. Se han hecho intentos para
implementar el modelo de los sistemas de bases de datos heterogéneas (o federados)
distribuidos. Este modelo podría ser considerado como un caso especial del modelo
de cliente / servidor, en el que todas las plataformas son servidores y clientes.
Figura 35-14 (A) muestra un ejemplo de configuración del par-a-par en el que todas
las plataformas tienen funciones completas.

  Página 427 de 670 

TOGOF 9.1    

  Figura 35‐14: Peer‐to‐Peer y distribuidos Modelos de Gestión de objetos 
Distribuido Modelo de Gestión de Objetos

En este modelo, el procedimiento remoto llamadas Se utiliza normalmente para la

comunicación en el cliente / servidor y otros modelos de procesamiento distribuido
son reemplazados por los mensajes enviados a los objetos. Los servicios prestados
por los sistemas en una red son tratados como objetos. . Un solicitante no necesita
conocer los detalles de cómo se configura el objeto El enfoque requiere:  Un
mecanismo para enviar mensajes 

  Página 428 de 670 

TOGOF 9.1    
  Un mecanismo para coordinar la entrega de los mensajes  Las aplicaciones y
servicios que soportan una interfaz de mensajería 

Este enfoque no contrasta con el cliente / servidor o modelos de peer-to-peer, pero

especifica una interfaz consistente para la comunicación entre plataformas de co-
operación. Es considerado por algunos como un enfoque de implementación de
cliente / servidor y modelos peer-to-peer. Figura 35-14 presenta dos ejemplos de
modelos de objetos distribuidos. Ejemplo B muestra cómo se alteraría una
configuración cliente / servidor para dar cabida al modelo de gestión de objetos
distribuidos. Ejemplo C muestra cómo se vería alterada un modelo peer-to-peer para
llevar a cabo la gestión de objetos distribuidos. El Object Management Group (OMG),
un consorcio de participantes de la industria que trabajan hacia los estándares de
objeto, se ha desarrollado una arquitectura - Common Object Request Broker
Architecture (CORBA) - que especifica el protocolo de una aplicación de cliente
debe utilizar para comunicarse con un intermediario de solicitud de objetos ( ORB),
que presta servicios. El ORB especifica cómo los objetos de manera transparente
pueden hacer peticiones y recibir respuestas. Además, Object Linking de Microsoft e
incrustación de objetos (OLE) estándar para Windows es un ejemplo de una aplicación
de gestión de objetos distribuidos, por lo que cualquier aplicación compatible con
OLE puede trabajar con datos de cualquier otra aplicación compatible con OLE.

35.7.5 Desarrollo de un Comunicaciones Ingeniería View

La vista de la Ingeniería de Comunicaciones se ocupa de las comunicaciones de
estructuración y elementos de red para simplificar la planificación y diseño de la
red.
35.7.5.1 Las partes interesadas y Preocupaciones

Este punto de vista debe ser desarrollado para las comunicaciones del personal de
ingeniería del sistema, y debe centrarse en cómo se implementa el sistema desde la
perspectiva del ingeniero de comunicaciones. Ingenieros de comunicaciones son
típicamente preocupado por la ubicación, modificabilidad, reusabilidad y la
disponibilidad de servicios de comunicaciones y redes. Las principales
preocupaciones de este punto de vista son la comprensión de los requisitos de
comunicaciones de red y. En general, estos grupos de interés tienen que ver con
garantizar que las correspondientes comunicaciones y los servicios de redes se
desarrollan y despliegan dentro del sistema de una manera óptima. El desarrollo de
este punto de vista ayuda en la selección de la mejor modelo de comunicaciones para
el sistema.
35.7.5.2 Cuestiones clave

Las redes de comunicaciones se construyen de dispositivos finales (por ejemplo,

impresoras), nodos de procesamiento, los nodos de comunicación (elementos de
conmutación), y los medios de comunicación de enlace que los conectan. La red de
comunicaciones proporciona los medios por los cuales se intercambia información.
Las formas de información incluyen datos, imágenes, voz y video. Dado que los
sistemas de información automatizados aceptan y procesan la información usando los
formatos de datos digitales en lugar de los formatos analógicos, los conceptos de

  Página 429 de 670 

TOGOF 9.1    
comunicación TOGAF y orientación se centrará en las redes digitales y los servicios
digitales.Servicios multimedia integrados están incluidos. La vista de la
Ingeniería de Comunicaciones se describe la arquitectura de comunicaciones con
respecto a la geografía, se analiza el modelo de referencia de interconexión de
sistemas abiertos (OSI), y describe un marco general destinado a permitir el
análisis de sistemas eficaces y planificación.
Infraestructura de comunicaciones

La infraestructura de comunicaciones puede contener hasta tres niveles de

transporte - local, regional / metropolitano, y global - como se muestra en la
Figura 35-15 . Los nombres de los componentes de transporte se basan en su
respectivo ámbito geográfico, pero también existe una relación jerárquica entre
ellos. Los componentes de transporte corresponden a una estructura de gestión de la
red en la que la gestión y el control de los recursos de red se distribuyen a
través de los diferentes niveles. Los componentes locales se refieren a los activos
que se encuentran relativamente cerca geográficamente. Este componente contiene
equipos de comunicaciones fijas y pequeñas unidades de equipos de comunicaciones
móviles. LAN, a la que se conectará la mayoría de los dispositivos finales, están
incluidos en este componente. Las interfaces estándar facilitará la portabilidad,
flexibilidad e interoperabilidad de las redes LAN y dispositivos finales. Redes de
área metropolitana (MAN) Regional y están geográficamente dispersos en una gran
superficie. Una red regional o metropolitano podría conectar componentes locales en
varias bases fijas o conectarse puestos remotos separados. En la mayoría de los
casos, las redes regionales y metropolitanas se utilizan para conectar redes
locales. Sin embargo, las bases de datos compartidas, plataformas regionales de
procesamiento y centros de gestión de red pueden conectarse directamente oa través
de una red LAN. Las interfaces estándar serán proporcionados para conectar redes
locales y dispositivos finales. Redes de Área Global o amplia (WAN) se encuentran
en todo el mundo, proporcionando conectividad a las redes regionales y
metropolitanas en el entorno fijo y desplegado.Además, unidades móviles, bases de
datos compartidas, y centros de procesamiento central se pueden conectar
directamente a la red mundial, como se requiera. Las interfaces estándar serán
proporcionados para conectar las redes regionales y metropolitanas y los
dispositivos finales.

  Página 430 de 670 

TOGOF 9.1    

  Figura 35‐15: Infraestructura de comunicaciones 

  
Comunicaciones Modelos

La infraestructura geográficamente dividido descrito anteriormente es la base de un

marco global de comunicaciones. Estas divisiones geográficas permiten la aplicación
por separado de las diferentes responsabilidades de gestión, las actividades de
planificación, las funciones operacionales y tecnologías de apoyo que deben
aplicarse en cada área. Componentes y servicios de hardware y software instalados
en el marco forman el modelo completo. Los siguientes puntos se describe el modelo
de referencia OSI y una agrupación de las capas OSI que facilita la discusión de
los problemas de interoperabilidad.
El modelo de referencia OSI

La interconexión de sistemas abiertos (OSI) Modelo de referencia, representada en

la figura 3516 , es el modelo utilizado para las comunicaciones de datos en
TOGAF.Cada una de las siete capas del modelo representa uno o más servicios o
protocolos (un conjunto de normas que regulan las comunicaciones entre sistemas),
que definen la operación funcional de las comunicaciones entre los usuarios y los
elementos de red. Cada capa (con la excepción de la capa superior)

  Página 431 de 670 

TOGOF 9.1    
proporciona servicios para la capa por encima de ella. Este modelo tiene por objeto
establecer el funcionamiento de sistemas abiertos e implica la implementación
basada en estándares. Se esfuerza para permitir diferentes sistemas para llevar a
cabo la interoperabilidad completa y la calidad de funcionamiento en toda la red.
Las siete capas del modelo OSI están estructurados para facilitar el desarrollo
independiente dentro de cada capa y para proporcionar cambios independientes de
otras capas. Protocolos estándares internacionales estables en conformidad con las
definiciones de capas OSI modelo de referencia han sido publicadas por diversos
organismos de normalización. Esto no quiere decir que los únicos protocolos que se
ajustan en TOGAF son protocolos OSI. Otras normas de protocolo, como SNA o TCP / IP
se pueden describir utilizando el modelo de capas OSI de siete como referencia.
Soporte y áreas de negocio de aplicaciones, tal como se define en TOGAF, están por
encima de la pila de protocolos modelo de referencia OSI y el uso de sus servicios
a través de la capa de aplicaciones.
Marco de comunicaciones

Un sistema de comunicaciones basado en el modelo de referencia OSI incluye los

servicios en todas las capas pertinentes, el apoyo y el software de aplicación de
área de negocio que se encuentra por encima de la capa de aplicación del modelo de
referencia OSI y el equipo físico que lleva los datos. Estos elementos se pueden
agrupar en niveles arquitectónicos que representan las principales capacidades
funcionales, tales como la conmutación y el enrutamiento, la transferencia de datos
y el rendimiento de las aplicaciones.

  Figura 35‐16: modelo de referencia OSI    Página 432 de 670 

TOGOF 9.1    
Estos niveles arquitectónicos son:  El nivel de transmisión (por debajo de la capa
física del modelo de referencia OSI) proporciona todas las capacidades físicas y
electrónicas, las cuales establecen una ruta de transmisión entre los elementos
funcionales del sistema (cables, circuitos arrendados, interconexiones, etc.)   La
red de conmutación de nivel (capas OSI 1 a 3), establece la conectividad a través
de los elementos de la red para soportar el encaminamiento y control del tráfico
(interruptores, controladores, software de red, etc.)   El nivel de intercambio de
datos (capas OSI 4 a 7) lleva a cabo la transferencia de la información después de
que la red se ha establecido (de extremo a extremo, la transferencia de usuario a
usuario) que incluye elementos más capaces de procesamiento (hosts, estaciones de
trabajo, servidores, etc ).   En el TRM, servicios de la capa de aplicación OSI se
consideran parte de la entidad plataforma de aplicaciones, ya que ofrecen
interfaces estandarizadas a la entidad de programación de aplicaciones.  El nivel
del Programa de Aplicaciones (por encima de la OSI) incluye el apoyo y aplicaciones
en áreas de negocios (programas de aplicación no de gestión).  

El marco de las comunicaciones se define para consistir en los tres componentes

geográficos de la infraestructura de comunicaciones (local, regional y global) y
los cuatro niveles de la arquitectura (Programa de Aplicaciones de transmisión,
conmutación de red, intercambio de datos, y), y se representa en la figura 35 -
17 . Los servicios de comunicaciones se llevan a cabo en uno o más de estos niveles
de la arquitectura dentro de los componentes geográficos. Figura 35-17 muestra
computación elementos (que operan a nivel de programa de aplicaciones) con el apoyo
a elementos de intercambio de datos, vinculados entre sí a través de diversos
elementos de conmutación (que funcionan a la Nivel de conmutación de red), cada uno
situado dentro de su respectivo componente geográfico. Figura 35-17 también
identifica la relación de TOGAF a la arquitectura de comunicación.

  Página 433 de 670 

TOGOF 9.1    

  Figura 35‐17: Marco de comunicaciones 
Asignación de Servicios a Componentes

La infraestructura de comunicaciones consta de los componentes de transporte local,

regional y global. Los servicios destinados a estos componentes son idénticos a los
servicios del programa de aplicación, el intercambio de datos, conmutación de red,
o los niveles de arquitectura de transmisión que se aplican a un componente.
Intercambio de datos y servicios de nivel de conmutación de red son idénticos a los
servicios de las correspondientes capas de modelo de referencia OSI. Normalmente,
sólo conmutación de redes y servicios de transmisión se asignan a los componentes
regionales y globales, que consisten en nodos de comunicación y medios de
transmisión. Todos los servicios se pueden realizar en el componente local, que
incluye los dispositivos finales, nodos de procesamiento, nodos de comunicaciones,
y los medios de comunicación de enlace. Transporte, transformación, transporte y
aplicaciones son todas realizadas en este componente.

35.7.6 Desarrollo de un Vista de flujo de datos

El punto de vista de flujo de datos se refiere a almacenamiento, recuperación,
procesamiento, archivo y seguridad de los datos.

  Página 434 de 670 

TOGOF 9.1    
35.7.6.1 Las partes interesadas y Preocupaciones

Este punto de vista se debe desarrollar para los ingenieros de bases de datos del
sistema. Las principales preocupaciones de este punto de vista son la comprensión
de cómo proporcionar datos a las personas adecuadas y las aplicaciones con las
interfaces adecuadas en el momento adecuado. Esta visión se refiere a la
arquitectura del almacenamiento, recuperación, procesamiento, archivo y seguridad
de los datos. Se ve en el flujo de datos a medida que se almacena y se procesa, y
en qué se requerirá componentes para apoyar y gestionar tanto el almacenamiento y
el procesamiento. En general, estos grupos de interés tienen que ver con garantizar
el acceso ubicuo a la información de alta calidad.
35.7.6.2 Desarrollo de la Vista

Los temas de la arquitectura general de un "sistema de base de datos" son

componentes de base de datos o componentes que proporcionan servicios de bases de
datos. El modelado de una "base de datos" se suele hacer con los diagramas de
entidad-relación y definiciones de esquema, incluyendo las definiciones de tipo de
documento.
35.7.6.3 Cuestiones clave

. Servicios de gestión de datos pueden ser proporcionados por una amplia gama de
implementaciones Algunos ejemplos son:    Las mega-centros que proporcionan las
bases de datos corporativas orientación funcional de apoyo a las necesidades de
datos locales y remotas  DBMS distribuido que apoyan el uso interactivo de las
bases de datos con particiones y parcialmente replicados  Los sistemas de archivos
proporcionados por los sistemas operativos, los cuales pueden ser utilizados por
las aplicaciones de procesamiento tanto interactivos y por lotes 

Servicios de gestión de datos incluyen el almacenamiento, la recuperación, la

manipulación, la copia de seguridad, reinicio / recuperación, seguridad y funciones
asociadas para texto, datos numéricos y de datos complejos, tales como documentos,
gráficos, imágenes, audio y video. El sistema operativo proporciona servicios de
gestión de archivos, pero que se consideran aquí porque existen muchas bases de
datos de legado como uno o más archivos, sin los servicios de un DBMS. Los
componentes principales que ofrecen servicios de gestión de datos que se describen
en esta sección son:    Sistemas de gestión de bases de datos (ver Sistemas de
gestión de bases de datos )  Diccionario de Datos / Sistemas de directorios (ver
diccionario de datos / Directory Systems )  Administración de datos (en la
administración de datos ) 

  Página 435 de 670 

TOGOF 9.1    
 Seguridad de los datos (ver Seguridad de Datos ) 

Estos son los aspectos críticos de la gestión de datos por las siguientes razones.
El DBMS es el componente más crítico de cualquier capacidad de gestión de datos, y
un sistema / directorio de diccionario de datos es necesario en colaboración con el
DBMS como una herramienta para ayudar a la administración de la base de
datos.Seguridad de los datos es una parte necesaria de toda política global para la
seguridad en el procesamiento de información.
Sistemas de Gestión de Base de Datos

Un sistema de gestión de bases de datos (DBMS) prevé la gestión sistemática de los

datos. . Este componente de gestión de datos proporciona servicios y capacidades
para la definición de los datos, la estructuración de los datos, acceder a los
datos, así como la seguridad y la recuperación de los datos Un DBMS realiza las
siguientes funciones:       Estructuras de datos de una manera coherente 
Proporciona acceso a los datos  Minimiza la duplicación  Permite reorganización; es
decir, cambios en el contenido de los datos, estructura, y el tamaño  Soporta las
interfaces de programación  Proporciona seguridad y control 

Un DBMS debe proporcionar:      Persistencia; los datos siguen existiendo

después de la ejecución de la aplicación se ha completado  Gestión de
almacenamiento secundario  Concurrencia  Recuperación  Definición de Datos / Data
Manipulation Language (DDL / DML), que puede ser una interfaz gráfica 

Base de datos Modelos

El modelo de datos lógica que subyace a la base de datos que caracteriza a un DBMS.
Los modelos de datos lógicos comunes son las siguientes:  Modelo Relacional : Un
sistema de gestión de base de datos relacional de datos (RDBMS) estructuras en
tablas que tienen ciertas propiedades:  o Cada fila de la tabla es distinta de cada
dos filas. 

  Página 436 de 670 

TOGOF 9.1    
o Cada fila contiene sólo datos atómicos; es decir, no hay datos de repetición o
estructuras tales como matrices.  Cada columna de la tabla relacional define campos
o atributos de datos con nombre. 

Una colección de tablas relacionadas en el modelo relacional constituye una base de

datos. La teoría matemática de las relaciones subyace en el modelo relacional -
tanto a la organización de los datos y los lenguajes que manipulan los datos. Edgar
Codd, a continuación, en IBM, ha desarrollado el modelo relacional en 1973. Ha sido
popular, en términos de uso comercial, desde principios de 1980.  Modelo
Jerárquico : El modelo de datos jerárquico organiza los datos en una estructura de
árbol. Hay una jerarquía de segmentos de padres y de datos de niños.Esta estructura
implica que un registro puede haber repetición de la información, en general, en
los segmentos de datos secundarios. Por ejemplo, una organización puede almacenar
información sobre un empleado, como nombre, número de empleado, departamento,
salario. La organización también puede almacenar información acerca de los niños de
un empleado, como nombre y fecha de nacimiento. Los datos de los empleados y los
niños forman una jerarquía, donde los datos de empleado representa el segmento de
los padres y de los datos de los niños representa el segmento infantil. Si un
empleado tiene tres hijos, entonces no habría tres segmentos secundarios asociados
con un segmento de los empleados. En una base de datos jerárquica de la relación
padre-hijo es uno-amuchos. Esto restringe un segmento niño a tener sólo un segmento
de matriz. DBMS jerárquicos fueron populares desde finales de 1960, con la
introducción del Sistema de Gestión de la Información de IBM (IMS) DBMS, a través
de la década de 1970.  Modelo de la Red : La popularidad del modelo de datos de la
red coincide con la popularidad del modelo de datos jerárquico. Algunos datos se
modelan de forma más natural con más de un padre por niño. Así, el modelo de red
permite el modelado de muchos-a-muchos en los datos. En 1971, la Conferencia sobre
Sistemas de Datos Idiomas (CODASYL) define formalmente el modelo de red. La
construcción básica de modelado de datos en el modelo de red es la construcción de
conjunto.Un conjunto consiste en un tipo de propietario registro, un nombre de
conjunto, y un tipo de registro miembro. Un tipo de registro miembro puede tener
ese papel en más de un conjunto, de ahí el concepto multipadre es compatible. Un
tipo de registro propietario también puede ser miembro o propietario en otro
conjunto. El modelo de red CODASYL se basa en la teoría matemática de conjuntos. 
Orientada a objetos Modelo : Un sistema de gestión de base de datos orientada a
objetos (SGBDOO) debe ser a la vez un DBMS y un sistema orientado a objetos. Como
DBMS debe proporcionar las capacidades identificadas anteriormente. OODBMS
normalmente puede modelar datos tabulares, datos complejos, datos jerárquicos, y
las redes de datos. Las siguientes son características importantes de un sistema
orientado a objetos:  o Los objetos complejos: por ejemplo, los objetos pueden
estar compuestos de otros objetos.  Objeto de identidad: cada objeto tiene un
identificador único externo a los datos.  Encapsulación: un objeto consta de datos
y los programas (o métodos) que manipularlo. 

o o

  Página 437 de 670 

TOGOF 9.1    
o o o Tipos o clases: una clase es una colección de objetos similares.  Herencia:
subclases heredan los atributos y los métodos de las clases de datos.  Reemplazar
con el enlace en tiempo: el método particular de una subclase puede reemplazar el
método de una clase en tiempo de ejecución.  Extensibilidad: por ejemplo, un
usuario puede definir nuevos objetos.  Completitud computacional: un lenguaje de
propósito general (tal como Ada, C o C + +) es computacionalmente completa. El
lenguaje SQL de propósito especial no lo es. La mayoría de OODBMS incorporan un
lenguaje de programación de propósito general. 

o o

Archivos planos : Un sistema de archivos planos está estrechamente asociada con un

método de acceso de almacenamiento. Un ejemplo es el método de acceso secuencial
indizado de IBM (ISAM). Los modelos analizados anteriormente en esta sección son
modelos de datos lógicos; archivos planos requieren que el usuario trabajar con la
disposición física de los datos en un dispositivo de almacenamiento. Por ejemplo,
el usuario debe conocer la ubicación exacta de un elemento de datos en un registro.
Además, los archivos planos no proporcionan todos los servicios de un DBMS, tales
como la designación de los datos, la eliminación de la redundancia y control de
concurrencia. Además, no hay independencia de los datos y el programa de
aplicación. El programa de aplicación debe conocer la disposición física de los
datos. 

SGBD Distribuidos

Un DBMS distribuido gestiona una base de datos que se extiende sobre más de una
plataforma. La base de datos puede basarse en cualquiera de los modelos de datos
mencionados anteriormente (excepto el archivo plano). La base de datos puede ser
replicado, particiones, o una combinación de ambos. Una base de datos replicada es
una en la que existen copias completas o parciales de la base de datos en las
diferentes plataformas. Una base de datos particionada es una en la que parte de la
base de datos es en una plataforma y partes son en otras plataformas. La partición
de una base de datos puede ser vertical u horizontal. Una partición vertical pone
algunos campos y los datos asociados en una sola plataforma y algunos campos y los
datos asociados en otra plataforma. Por ejemplo, considere una base de datos con
los siguientes campos: identificación de empleado, nombre del empleado,
departamento, número de dependientes, proyecto asignado, tasa de salario, impuesto
tasa. Una partición vertical podría colocar la identificación del empleado, número
de dependientes, la tasa de salario y tasa de impuestos en una plataforma y el
nombre del empleado, departamento y proyecto asignado en otra plataforma. Una
partición horizontal puede mantener todos los campos en todas las plataformas, pero
la distribución de los registros. Por ejemplo, una base de datos con 100.000
registros podría poner los primeros 50.000 registros en una plataforma y los
segundos 50.000 registros en una segunda plataforma. Si la base de datos
distribuida se replica o se repartió, un único DBMS gestiona la base de datos. Hay
un único esquema (descripción de los datos en una base de datos en términos de un
modelo de datos; por ejemplo, relacional) para una base de datos distribuida. La
distribución de la base de datos es generalmente transparente para el usuario. El
término "DBMS distribuido" implica homogeneidad.
Distribuidos Heterogéneos DBMS

  Página 438 de 670 

TOGOF 9.1    
Un sistema distribuido de bases de datos heterogéneas es un conjunto de bases de
datos independientes, cada uno con sus propios DBMS, presenta a los usuarios como
una única base de datos y sistema. "Federados" se utiliza como sinónimo de
"distribuido heterogéneo". La heterogeneidad se refiere a las diferencias en los
modelos de datos (por ejemplo, de la red y relacionales), los DBMS de diferentes
proveedores, plataformas de hardware diferentes, u otras diferencias. Los tipos más
simples de los sistemas de bases de datos federadas son comúnmente llamadas
"puertas de acceso". En una puerta de entrada, un proveedor (por ejemplo, Oracle)
proporciona acceso unidireccional a través de sus DBMS a otra base de datos
gestionada por DBMS de un proveedor diferente (por ejemplo, DB2 de IBM). Los dos
DBMS no necesitan compartir el mismo modelo de datos. Por ejemplo, muchos
proveedores de RDBMS son portales a los DBMS jerárquicos y de red. Hay sistemas de
bases de datos federadas, tanto en el mercado y en la investigación que
proporcionan un acceso más general a los diversos DBMS. Estos sistemas suelen
proporcionar un componente de integración de esquemas para integrar los esquemas de
las diversas bases de datos y presentarlos a los usuarios como una única base de
datos, un componente de gestión de consultas para distribuir las consultas a los
diferentes DBMS en la federación, y un componente de gestión de transacciones, para
distribuir y gestionar los cambios en las distintas bases de datos de la
federación.
Diccionario de Datos / Sistemas de directorios

El segundo componente de la prestación de servicios de gestión de datos, el

Diccionario / Sistema de Directorio de Datos (DD / DS), se compone de los servicios
públicos y los sistemas necesarios para el catálogo, documentar, gestionar, y el
uso de metadatos (datos sobre los datos). Un ejemplo de los metadatos es la
siguiente definición: una larga cadena alfanumérica de seis caracteres, en el que
el primer carácter es una letra del alfabeto y cada uno de los restantes cinco
caracteres es un número entero entre 0 y 9; el nombre de la cadena es "la
identificación del empleado " . Las utilidades DD / DS hacen uso de archivos
especiales que contienen el esquema de base de datos. (Un esquema, el uso de
metadatos, define el contenido y la estructura de una base de datos.) Este esquema
está representado por un conjunto de tablas para incluir en la compilación de
definición de datos (DDL) Idioma. El DD / DS normalmente se proporciona como parte
de un DBMS pero a veces está disponible a partir de fuentes alternativas. En la
gestión de datos distribuidos, información de distribución también se puede
mantener en el sistema de directorio de red. En este caso, la interfaz entre los DD
/ DS y el sistema de directorio de red sería a través de la API del componente de
servicios de red en la plataforma. En los entornos actuales, diccionarios de datos
se suelen integrar con el DBMS y sistemas de directorio se limitan por lo general a
una sola plataforma. Directorios de red se usan para expandir el reino DD / DS. La
relación entre los DD / DS y el directorio de red es una combinación compleja de
fuentes físicos y lógicos de datos.
Administración de Datos

La administración de datos aborda adecuadamente la arquitectura de datos, que está

fuera del alcance de TOGAF. Se discuten brevemente aquí debido a las áreas de
superposición. Se ocupa de todos los recursos de datos de una empresa, y como tal
hay solapamientos con la gestión de datos, que se ocupa de los datos en bases de
datos. Dos áreas específicas de superposición son los depositarios y administración
de base de datos, que se describen brevemente a continuación.
Repositorio

  Página 439 de 670 

TOGOF 9.1    
Un repositorio es un sistema que gestiona todos los datos de la empresa, que
incluye datos y modelos de procesos y otra información de la empresa. Por lo tanto,
los datos en un repositorio es mucho más extensa que la de una DD / DS, que por lo
general sólo define los datos que forman una base de datos.
Administración de bases de datos

La administración de datos y administración de base de datos son procesos

complementarios. La administración de datos es responsable de los datos, estructura
de datos, y la integración de datos y procesos. Administración de base de datos,
por otro lado, incluye el diseño físico, desarrollo, implementación, seguridad y
mantenimiento de las bases de datos físicos. Administración de base de datos es
responsable de la gestión y aplicación de las políticas de la empresa relacionadas
con bases de datos individuales.
Seguridad de los datos

El tercer componente de la prestación de servicios de gestión de datos es la

seguridad de los datos. Esto incluye los procedimientos y las medidas tecnológicas
aplicadas para prevenir el acceso no autorizado, modificación, uso y difusión de
los datos almacenados o procesados por un sistema informático. La seguridad de
datos incluye también la integridad de datos (es decir, preservar la exactitud y
validez de los datos), y proteger el sistema de daños físicos (incluidas las
medidas preventivas y los procedimientos de recuperación). Control de autorización
permite sólo los usuarios autorizados tengan acceso a la base de datos en el nivel
adecuado. Directrices y procedimientos se pueden establecer para la rendición de
cuentas, los niveles de control, y el tipo de control. Autorización para el control
de los sistemas de bases de datos difiere de la de los sistemas de archivos
tradicionales, ya que, en un sistema de base de datos, no es raro para que
diferentes usuarios tienen diferentes derechos a los mismos datos. Este requisito
abarca la capacidad de especificar subconjuntos de datos y para distinguir entre
grupos de usuarios. Además, el control descentralizado de las autorizaciones es de
particular importancia para los sistemas distribuidos. La protección de datos es
necesario para evitar que los usuarios no autorizados de comprender el contenido de
la base de datos. El cifrado de datos, como uno de los métodos primarios para la
protección de datos, es útil tanto para la información almacenada en el disco y de
la información intercambiada en una red.

35.7.7 Desarrollo de una empresa de administración Ver

La visión empresarial de administración se ocupa de las operaciones, la
administración y gestión del sistema.
35.7.7.1 Las partes interesadas y Preocupaciones

Este punto de vista debe ser desarrollado para las operaciones, la administración y
el personal de gestión del sistema. Las principales preocupaciones de estos grupos
de interés son la comprensión de cómo el sistema se gestiona como un todo, y cómo
se controlan todos los componentes del sistema. La preocupación principal es la
gestión de cambio en el sistema y predecir el mantenimiento preventivo necesario.

  Página 440 de 670 

TOGOF 9.1    
En general, estos grupos de interés tienen que ver con garantizar que la
disponibilidad del sistema no sufre cuando se produzcan cambios. Administrar el
sistema incluye Administración de componentes como:      Componentes de
seguridad  Los activos de datos  Activos de software  Los activos de hardware 
Redes activos 

35.7.7.2 Desarrollo de la Vista

Escenarios de negocios son una manera muy útil para describir lo que debe suceder
cuando se planifican y se producen acontecimientos imprevistos. Es altamente
recomendable que los escenarios de negocio pueden crear para el cambio planificado,
y para el cambio no planificado. A continuación se describen algunas de las
cuestiones clave que el arquitecto podría considerar en la construcción de
escenarios de negocio.

35.7.7.3 Cuestiones clave

La visión empresarial de administración actúa como un control y equilibrio sobre

las dificultades y el día a día los gastos de funcionamiento de los sistemas
construidos en la nueva arquitectura. A menudo, la gestión del sistema no se
considera hasta que se hayan tomado todas las decisiones de compra y de desarrollo
importantes, y tener una visión de gestión independiente en una etapa temprana en
el desarrollo de la arquitectura es una forma de evitar este escollo. Es una buena
práctica para desarrollar la visión empresarial de administración con un examen
atento de la opinión de Ingeniería de Sistemas , ya que, en general, la gestión es
difícil de adaptar en un diseño existente. Los elementos clave de la visión
empresarial de administración son:       Las políticas, los procedimientos y
directrices que impulsan sus necesidades de gestión (por ejemplo, una política para
restringir la descarga de software desde Internet)  Cómo su disponibilidad del
sistema de medidas de la tienda  Los servicios de gestión y los servicios públicos
necesarios  La magnitud que pueda, calidad y ubicación del personal de gestión y
apoyo  La capacidad de los usuarios para asumir las tareas de administración del
sistema, tales como el mantenimiento de contraseñas  La capacidad de administración
de los componentes existentes y previstas en cada una de las categorías de
componentes 

  Página 441 de 670 

TOGOF 9.1    
  Si la administración debe ser centralizada o distribuida  Si la seguridad es
responsabilidad de los administradores de sistemas o un grupo separado, teniendo en
cuenta todos los requisitos legales 

Componentes técnicos principales categorías que son objeto de la operación vista

empresarial de administración con el cambio, ya sean mejoras previstas, o
interrupciones no planificadas. La siguiente tabla muestra las preocupaciones
específicas de cada categoría de componente.

 
Categoría de Consideraciones sobre el cambio componentes planeadas Componentes de
¿Cómo se propaga un cambio de seguridad seguridad en todo el sistema? ¿Quién es
responsable de hacer los cambios; usuarios finales, o guardias de seguridad?
Activos de Datos ¿Cómo se añaden nuevos elementos de datos? Modificación imprevista
Consideraciones ¿Qué debe suceder cuando se viola la seguridad? ¿Qué debe ocurrir
si un componente de seguridad falla?

¿Cuáles son los procedimientos de respaldo y son todas las capacidades del sistema
de copia de seguridad allí en el ¿Cómo se importan los datos / exportados tiempo? o
carga / sin carga? ¿Cómo se gestiona la copia de seguridad mientras se ejecuta de
forma continua? ¿Cómo se propaga el cambio de datos en un entorno distribuido? ¿Qué
es lo que quieres que ocurra cuando ¿Cómo es una nueva aplicación introducida en
los sistemas? falla una aplicación? ¿Qué procedimientos existen para controlar la
calidad del software? ¿Cómo se propagan los cambios de aplicaciones en un entorno
distribuido? ¿Cómo es la introducción de software no deseado restringido dada la
Internet? ¿Cómo evalúa el impacto del nuevo ¿Qué es lo que quieres que ocurra
cuando hardware en el sistema, especialmente la se producen interrupciones de
hardware? red de carga? ¿Cómo evalúa el impacto de los nuevos componentes de red?
¿Cómo optimizar los componentes de red? ¿Qué es lo que quieres que ocurra cuando
falla un recurso de la aplicación?

Activos de Software

Activos de Hardware Networking Activo

35.7.8 Desarrollo de un Adquirente Ver

La vista adquiriente tiene que ver con la adquisición de Commercial Off-The-Shelf
(COTS) de software y hardware.

  Página 442 de 670 

TOGOF 9.1    
35.7.8.1 Las partes interesadas y Preocupaciones

Este punto de vista debe ser desarrollado para el personal que participa en la
adquisición de cualquiera de los componentes de la arquitectura de tema. Las
principales preocupaciones de estos grupos de interés son la comprensión de lo que
la construcción de bloques de la arquitectura se pueden comprar, y qué
restricciones (o reglas) existen que son relevantes para la compra. La adquirente
comprará con múltiples proveedores en busca de la mejor solución de coste, si bien
respetando las restricciones (o reglas) aplicadas por la arquitectura, como las
normas. La principal preocupación es hacer que las decisiones de compra que se
ajustan a la arquitectura, y por lo tanto reducir el riesgo de los costos
adicionales que surjan a partir de componentes que no cumplen.
35.7.8.2 Desarrollo de la Vista

La vista adquirente normalmente se representa como una arquitectura de soluciones

de Bloques de Construcción (SBB), complementados con vistas a las normas que deben
ser respetados por los bloques de construcción individuales.
35.7.8.3 Cuestiones clave

El adquirente normalmente se ejecuta un proceso similar a la de abajo. Dentro de

las descripciones de pasos que podemos ver las preocupaciones y problemas que
enfrenta la entidad adquirente.

 
Etapas del Paso Descripción y Salida Proceso de Contratación Planificación Crea el
plan para la compra de algún componente. Para los sistemas de TI, las siguientes
consideraciones son pertinentes a la construcción de bloques. Adquisición Este paso
requiere el acceso a la Arquitectura Bloques de Construcción (Abs) y SBB.

   
Exploración Concept

El proxeneta necesita saber qué ABBS aplicar restricciones (estándares) para su uso
en la evaluación y para la creación de RFP / RFI.  El proxeneta necesita saber qué
SBB candidatos se adhieran a estos estándares.  El procurador también necesita
saber qué proveedores ofrecen SBB aceptados, y en el que han sido desplegados.  El
procurador tiene que saber cuál es el presupuesto de este componente fue dada en
relación con el coste total del sistema. 

En este paso, el procurador mira a la viabilidad del concepto. Bloques de

construcción dan el planificador de un sentido de los riesgos existentes; si
existen muchos ABBS o SBB que coinciden con el concepto, el riesgo es menor.

  Página 443 de 670 

TOGOF 9.1    
Este paso requiere el acceso a ABBS y SBB. El planificador necesita saber qué ABBS
aplicar restricciones (estándares), y necesita saber qué SBB candidatos se adhieran
a estos estándares. Demostración En este paso, el proxeneta trabaja con el
desarrollo de un prototipo de una Concepto aplicación. El procurador recomienda los
dispositivos SBB reutilizables basados en y Validación estándares en forma, y la
experiencia pasada con los proveedores. Este paso requiere el acceso a SBB
reutilizables. En este paso, el proxeneta trabaja con el desarrollo para gestionar
la relación con los proveedores que suministran los dispositivos SBB. Bloques de
construcción que han demostrado ser aptos para esta finalidad y son marcados como
aprobados. Este paso requiere una actualización de la situación de "aprobado la
contratación" de un SBB. En este paso, el proxeneta trabaja con el desarrollo para
gestionar la relación con los proveedores que suministran los dispositivos SBB.
Bloques de construcción que se ponen en producción consiguen debidamente marcado.
Este paso requiere una actualización de la situación a "la producción" de SBB, con
el identificador del sistema de donde se está desarrollando el bloque de
construcción. En este paso, el proxeneta trabaja con el desarrollo para gestionar
la relación con los proveedores que suministran los dispositivos SBB. Bloques de
construcción que están totalmente desplegados obtener debidamente marcado. Este
paso requiere una actualización del estado a "desplegado" de SBB, con el
identificador del sistema de que se ha desplegado el bloque de construcción.

Desarrollo

Producción

Despliegue

  

  Página 444 de 670 

TOGOF 9.1       

36. Arquitectura Entregables

En este capítulo se ofrece una descripción de los entregables que se hace
referencia en el Método de Desarrollo de Arquitectura (ADM).

36.1 Introducción
Este capítulo define los entregables que se suele consumidos y producidos en todo
el ciclo de TOGAF ADM. Como prestaciones suelen ser los productos de trabajo
contractuales o formales de un proyecto de arquitectura, es probable que estas
prestaciones se verán limitados o alterados por cualquier proyecto global o la
gestión de procesos de la empresa (como CMMI, PRINCE2, PMBOK, o MSP). Por tanto,
este capítulo está destinado a proporcionar una línea de base típica de la
arquitectura entregables con el fin de definir mejor las actividades que se
requieren en el ADM y actuar como un punto de partida para la adaptación dentro de
una organización específica. El marco de contenido TOGAF (ver la Parte IV , 33.
Introducción ) identifica los entregables que se producen como salidas de la
ejecución del ciclo ADM y potencialmente consumidos como insumos en otros puntos de
la ADM. Otros entregables pueden producirse en otros lugares y consumidos por el
ADM. Entregables producidos por la ejecución de la ADM se muestran en la tabla a
continuación.
Entregable Arquitectura Bloques de Construcción (Ver 36.2.1 Arquitectura Building
Blocks ) Arquitectura Contrato (Ver 36.2.2 Arquitectura de licitación )
Arquitectura Definición de documento (Ver 36.2.3 Arquitectura de definición de
documento ) Principios Arquitectura (Ver 36.2.4 Principios de Arquitectura )
Arquitectura Repositorio (Ver 36.2.5 Arquitectura Repositorio ) Arquitectura
Requisitos Especificación (ver 36.2.6 Arquitectura Especificación de Requisitos )
Arquitectura Roadmap (Ver 36.2.7 Arquitectura Roadmap ) Architecture Vision (Ver
36.2.8 Architecture Vision ) Principios de Actuación, objetivos de negocio, y los
impulsores del negocio (Ver 36.2.9 Principios de Actuación, objetivos de negocio, y
los impulsores del negocio ) Evaluación de Capacidad La producción de ... F, H B,
C, D, E, F De entrada a ... A, B, C, D, E C, D, E, F, G, H

Preliminar, A, B, C, D Preliminar

B, C, D, E, F, Gestión de Requisitos B, C, D, E, F A, E Preliminar, A, B

Preliminar, A, B, C, D, E, F, G, H Preliminar, A, B, C, D, E, F, G, H, Gestión de

Requisitos C, D, Gestión de Requisitos B, C, D, E, F B, C, D, E, F, G, H, Gestión
de Requisitos A, B

A, E

B, C, D, E, F
  Página 445 de 670 

TOGOF 9.1    
(Ver 36.2.10 Evaluación de Capacidad ) Solicitud de cambio (Ver 36.2.11 Solicitud
de cambio ) Plan de Comunicación (Ver 36.2.12 Plan de Comunicaciones ) Evaluación
de cumplimiento (Ver Evaluación del Cumplimiento 36.2.13 ) Implementación y Plan de
Migración (Ver 36.2.14 Implementación y Plan de Migración ) Gobierno Modelo de
Implementación (Ver 36.2.15 Implementación Modelo de Gobierno ) Modelo de
Organización de Empresa Arquitectura (ver 36.2.16 Modelo de Organización de Empresa
de Arquitectura ) Solicitud de Arquitectura Trabajo (Ver 36.2.17 Solicitud de
Arquitectura de Trabajo ) Evaluación de Impacto Requisitos (Ver 36.2.18 Requisitos
de Evaluación de Impacto ) Solución Building Blocks (Ver Solución 36.2.19 Building
Blocks ) Declaración de Arquitectura de Trabajo (Ver 36.2.20 Declaración de
Arquitectura de Trabajo ) Marco de Arquitectura Adaptado (Ver 36.2.21 Tailored
Architecture Framework ) F, G, H La T E, F B, C, D, E, F H F

G, H

Preliminar

Preliminar, A, B, C, D, E, F, G, H, Gestión de Requisitos A, G

Preliminar, F, H

Gestión de Requisitos

Gestión de Requisitos

T A, B, C, D, E, F, G, H

A, B, C, D, E, F, G B, C, D, E, F, G, H, Gestión de Requisitos Preliminar, A, B, C,

D, E, F, G, H, Gestión de Requisitos

Preliminar, A

36.2 Descripciones Entregables

Las siguientes secciones ofrecen ejemplos de las descripciones de los entregables
que se hace referencia en el ADM. Tenga en cuenta que no todo el contenido descrito
aquí tiene que estar contenido en una entrega especial. Más bien, se recomienda el
uso de referencias externas cuando sea posible; por ejemplo, los planes
estratégicos de una empresa no deben ser copiados a una Solicitud de Arquitectura
Trabajo, sino más bien el título de los planes estratégicos deben ser
referenciados. Además, no se sugiere que estas descripciones se deben seguir a la
letra. Sin embargo, cada elemento debe ser considerado cuidadosamente; haciendo
caso omiso de cualquier elemento de entrada o de salida puede causar problemas
aguas abajo.

36.2.1 Arquitectura Bloques de Construcción

Documentación de Arquitectura y modelos de arquitectura de repositorio de la
empresa; véase la Parte IV , 37. Building Blocks .

  Página 446 de 670 

TOGOF 9.1    
36.2.2 Arquitectura Contrato
Propósito

Arquitectura contratos son los acuerdos conjuntos entre los socios de desarrollo y
los patrocinadores de los 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 gobernanza arquitectura eficaz (véase la Parte VII , 50. Arquitectura
de Gobierno). Mediante la implementación de un enfoque regido a la gestión de los
contratos, lo siguiente será garantizada:  Un sistema de monitoreo continuo para
comprobar la integridad, los cambios, la toma de decisiones, y la auditoría de
todas las actividades relacionadas 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 los riesgos en todos los aspectos del
desarrollo y la implementación de la arquitectura (s) que cubre el desarrollo
interno contra las normas aceptadas, 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 un entorno resistente  Un conjunto de
procesos y prácticas que garanticen 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 ámbito de la arquitectura bajo el
gobierno de este órgano 

 

Contenido

Contenido típico de un diseño y desarrollo de contratos de Arquitectura son:   

       Introducción y antecedentes  La naturaleza del acuerdo  Alcance de la
arquitectura  Arquitectura y estratégicos principios y los requisitos  Los
requisitos de conformidad  Proceso y las funciones de desarrollo y gestión de la
Arquitectura  Medidas Arquitectura Target  Fases definidas de entregables  Plan de
trabajo conjunto priorizado  Ventana de tiempo (s) 

  Página 447 de 670 

TOGOF 9.1    
 Arquitectura de entrega y de negocios métricas 

Los contenidos típicos de la arquitectura de licitación de un negocio de los

usuarios son:          Introducción y antecedentes  La naturaleza del
acuerdo  Alcance  Requisitos estratégicos  Los requisitos de conformidad 
Arquitectura adoptantes  Ventana de tiempo  Arquitectura métricas de negocio 
Arquitectura de servicios (que incluye el contrato de nivel de servicio (SLA)) 

Para más detalles sobre el uso de la arquitectura de Contratos, consulte la Parte

VII , 49. Arquitectura de Contratos .

36.2.3 Arquitectura de definición de documento

Propósito

La definición de documento La arquitectura es el contenedor de entrega de los

artefactos arquitectónicos básicos creados durante el proyecto y para obtener
información importante relacionada. La definición de documento Arquitectura abarca
todos los ámbitos de arquitectura (negocio, datos, aplicaciones y tecnología) y
también examina todos los estados relevantes de la arquitectura (línea de base,
transición y meta). 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. La
definición de documento La arquitectura es un complemento de la arquitectura de
Especificación de Requisitos, con un objetivo complementario:   La definición de
documento 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
arquitectura Requisitos ofrece una visión cuantitativa de la solución, indicando
los criterios cuantificables que deben cumplirse durante la implementación de la
arquitectura. 

Contenido

  Página 448 de 670 

TOGOF 9.1    
Los contenidos típicos de una definición de arquitectura de documento son:    
 Alcance  Metas, objetivos y limitaciones  Principios Arquitectura  Arquitectura
de línea de base  Modelos de arquitectura (por cada estado para modelar):  o o o o
  Modelos Arquitectura Profesiones  Modelos de arquitectura de datos  Modelos de
arquitectura de la aplicación  Modelos de arquitectura tecnológica 

Fundamento y justificación de enfoque arquitectónico  Mapeo de Arquitectura

Repositorio:  o o o o Mapeo de Arquitectura del Paisaje  Mapeo para referenciar los
modelos  Mapeo de las normas  Evaluación Reutilización 

  

Análisis de las deficiencias  La evaluación del impacto  Arquitectura de

transición:  o o o o o 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 aplicaciones de cada estado de transición  Arquitectura
Tecnológica para cada estado de transición 

36.2.4 Principios Arquitectura

Propósito

Los principios son normas generales y directrices, destinadas a ser duradera y rara
vez modificada, que informan y apoyan la forma en que una organización se marca
sobre el cumplimiento de su misión.

  Página 449 de 670 

TOGOF 9.1    
A su vez, los principios pueden ser sólo un elemento de un conjunto estructurado de
ideas que en conjunto definen y guías de la organización, a partir de los valores a
través de acciones y resultados.
Contenido

Ver Parte III , 23. Principios de Arquitectura de directrices y un conjunto

detallado de principios de arquitectura genéricos, entre ellos:     Principios
empresariales (véase 23.6.1 Principios de Negocios )  Principios de datos (véase
23.6.2 Datos Principios )  Principios de aplicación (ver 23.6.3 Principios de
Aplicación )  Principios Tecnología (ver 23.6.4 Principios Tecnológicos ) 
36.2.5 Arquitectura Repositorio
Propósito

La arquitectura de 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 la gestión de sus entregables, localizar
reutilizables activos, y publicar los resultados a las partes interesadas y otras
partes interesadas.
Contenido

Véase la Parte V , 41. Arquitectura Repositorio para obtener una descripción

detallada del contenido de un repositorio de Arquitectura.

36.2.6 Arquitectura Especificación de Requisitos

Propósito

La especificación de arquitectura Requisitos proporciona un conjunto de enunciados

cuantitativos que describen lo que un proyecto de implementación debe hacer para
cumplir con la arquitectura. Una arquitectura de Especificación de Requisitos
típicamente formará un componente importante de un contrato de ejecución o
contratar más detallada Arquitectura Definición. Como se mencionó anteriormente, la
arquitectura de Especificación de Requisitos es un complemento de la definición de
documento de Arquitectura, con un objetivo complementario:   La definición de
documento Arquitectura proporciona una visión cualitativa de la solución y tiene
por objeto comunicar la intención del arquitecto.  La especificación de
arquitectura Requisitos ofrece una visión cuantitativa de la solución, indicando
los criterios cuantificables que deben cumplirse durante la implementación de la
arquitectura. 

Contenido

  Página 450 de 670 

TOGOF 9.1    
Los contenidos típicos de una arquitectura de Especificación de Requisitos son:  
         Medidas de éxito  Requisitos de arquitectura  Contratos de
servicios de negocios  Contratos de servicios de aplicaciones  Directrices de
implementación  Las especificaciones de implementación  Las normas de aplicación 
Requisitos de interoperabilidad  Requisitos de gestión de servicios de TI 
Restricciones  Supuestos 

36.2.7 Arquitectura Roadmap

Propósito

La Arquitectura Roadmap 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 referencia para la arquitectura destino. La Hoja
de Ruta de la arquitectura destaca el valor del negocio paquetes de trabajo
individuales en cada etapa.Arquitecturas de transición necesarias para realizar
eficazmente la Arquitectura objetivo se identifican como pasos intermedios. La Hoja
de Ruta de la arquitectura se desarrolla gradualmente a lo largo de las fases E y
F, e informada por los componentes de la hoja de ruta fácilmente identificables de
la Fase B, C y D dentro de la ADM.
Contenido

Los contenidos típicos de una hoja de ruta de la Arquitectura son:  Cartera

Paquete de trabajo:  o o o o o Descripción Paquete de trabajo (nombre, descripción,
objetivos, entregables)  Requisitos funcionales  Dependencias  Relación con la
oportunidad  Relación a la Arquitectura de definición de documento y Arquitectura
Especificación de Requisitos 

  Página 451 de 670 

TOGOF 9.1    
o  El valor del negocio  Evaluación Factor de Aplicación y de la matriz de
deducción, incluyendo:  o o o o o o  Riesgos  Cuestiones  Supuestos  Dependencias 
Acciones  Entradas 

Brechas consolidados, soluciones, y la matriz de dependencias, entre ellas:  o o o

o Arquitectura dominio  Brecha  Posibles soluciones  Dependencias 

 

Cualquier Arquitecturas de transición  Recomendaciones para la implementación:  o o

o Criterios de valoración de la eficacia de los proyectos  Riesgos y problemas 
Bloques de Solución de construcción (SBB) 

36.2.8 Architecture Vision

Propósito

El Architecture Vision se crea desde el principio en el ciclo de ADM. Proporciona

un resumen de los cambios a la empresa que se derivarán de la implementación
exitosa de la arquitectura destino. El propósito de la Architecture Vision es
proporcionar actores clave con un resultado acordado formalmente. Pronto acuerdo
sobre el resultado permite a los arquitectos para centrarse en los detalles
necesarios para validar la factibilidad. Proporcionar una Architecture Vision
también es compatible con la comunicación de las partes interesadas, proporcionando
una versión resumida de la arquitectura Definición completa.
Contenido

Los contenidos típicos de una Visión Arquitectura son:  Descripción del problema: 

  Página 452 de 670 

TOGOF 9.1    
o o   Las partes interesadas y sus preocupaciones  Lista de temas / situaciones
que deben abordarse 

Objetivo de la Declaración de Arquitectura de Trabajo  Resumen considera necesaria

para la solicitud de Arquitectura Trabajo y la versión 0.1 de negocios,
aplicaciones, datos y tecnología Arquitecturas creó; típicamente incluyendo:  o o
Diagrama de la cadena de valor  Diagrama conceptual de soluciones 

 

Requisitos asignados  Referencia al proyecto de arquitectura Definición de

documento 

36.2.9 Principios de Actuación, objetivos de negocio, y los impulsores del negocio

Propósito

Principios de Actuación, los objetivos de negocio, y los impulsores del negocio

proporcionan un contexto para el trabajo de la arquitectura, mediante la
descripción de las necesidades y formas de trabajo empleado por la empresa. No
obstante, muchos factores que están fuera de la consideración de la arquitectura la
disciplina pueden tener implicaciones importantes para la forma en que la
arquitectura se desarrolla.
Contenido

El contenido y la estructura del contexto de negocios para la arquitectura puede

variar considerablemente de una organización a otra.

36.2.10 Evaluación de Capacidad

Propósito

Antes de embarcarse en una arquitectura detallada definición, es valioso para

comprender la línea de base y el nivel de capacidad objetivo de la empresa. Esta
evaluación de la capacidad puede ser examinado en varios 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 la capacidad o nivel de
madurez de la función de TI dentro de la empresa? ¿Cuáles son las posibles
consecuencias de la realización del proyecto de arquitectura en términos de
gobernanza o el diseño, la gestión 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? 

  Página 453 de 670 

TOGOF 9.1    
 ¿Cuál es la capacidad y la madurez de la función de la arquitectura dentro de la
empresa? ¿Qué activos de arquitectura se encuentran actualmente en la existencia?
¿Se mantienen y precisa? ¿Qué normas y modelos de referencia deben ser
considerados? ¿Es probable que haya oportunidades para crear reutilizables activos
durante el proyecto de arquitectura?  Cuando existan vacíos de capacidad, en qué
medida es el negocio listo para transformar con el fin de alcanzar la capacidad de
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 capacidades
básicas? 

Contenido

Los contenidos típicos de una Evaluación de Capacidad son:  Evaluación de la

capacidad del negocio, incluyendo:  o o o o o o  Capacidades del negocio 
Evaluación del estado basal del nivel de rendimiento de cada capacidad  Futuro
aspiración estado para el nivel de rendimiento de cada capacidad  Evaluación del
estado de línea de base de cómo se realiza cada capacidad  Futuro aspiración estado
para saber cómo debe ser realizado cada capacidad  Evaluación de los posibles
impactos a la organización de la empresa resultante de la implementación exitosa de
la arquitectura destino 

Evaluación de capacidades de TI, incluyendo:  o o o o Línea de base y objetivo de

nivel de madurez del proceso de cambio  Nivel de partida y de destino de madurez de
los procesos operativos  Evaluación de la capacidad de línea de base y la
capacidad  Evaluación de los impactos probables a la organización de TI como
resultado de la implementación exitosa de la arquitectura destino 


Evaluación de la madurez de la Arquitectura, que incluye:  o o o Procesos de
gobernanza Arquitectura, organización, funciones y responsabilidades  Evaluación de
habilidades Arquitectura  Amplitud, profundidad y calidad de la definición del
paisaje con el Repositorio de Arquitectura  Amplitud, profundidad y calidad de
definición las normas con el Repositorio Arquitectura  Amplitud, profundidad y
calidad de la determinación del modelo de referencia con el Repositorio de
Arquitectura 

  Página 454 de 670 

TOGOF 9.1    
o  Evaluación de re-uso potencial  Preparación para la transformación del negocio
de Evaluación, que incluye:  o o o o Factores de Preparación  Visión para cada
factor de preparación  Las calificaciones de preparación actuales y de destino 
Riesgos de Preparación 

36.2.11 Solicitud de Cambio

Propósito

Durante la implementación de una arquitectura , a medida que más datos se dan a

conocer, es posible que la definición y los requisitos de arquitectura original no
son adecuadas o no son suficientes para completar la implementación de una
solución. En estas circunstancias, es necesario que los proyectos de implementación
de cualquiera desvían del enfoque arquitectónico sugerido o solicitar ampliaciones
de ámbito. Además, los factores externos - como los factores del mercado, cambios
en estrategia de negocios y nuevas oportunidades de la tecnología - pueden 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 la arquitectura.
Contenido

Los contenidos típicos de una solicitud de cambio son:    Descripción del cambio
propuesto  Justificación del cambio propuesto  La evaluación del impacto del cambio
propuesto, incluyendo:  o o o o o o  Referencia a los requisitos específicos 
Prioridad de los interesados de los requisitos a la fecha  Fases para ser
revisitados  Fase de llevar sobre los requisitos de priorización  Los resultados de
las investigaciones de fase y prioridades revisadas  Recomendaciones sobre la
gestión de requisitos 

Número de referencia del Repositorio 

36.2.12 Plan de Comunicación

Propósito

  Página 455 de 670 

TOGOF 9.1    
Las arquitecturas empresariales contienen grandes volúmenes de información compleja
e interdependiente. La comunicación efectiva de 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 Comunicación para la
arquitectura permite esta comunicación se lleve a cabo dentro de un proceso
planificado y gestionado.
Contenido

Contenido típico de un plan de comunicaciones son:    Identificación de las

partes interesadas y la agrupación por las necesidades de comunicación 
Identificación de las necesidades de comunicación, los mensajes clave en relación
con el Architecture Vision, los riesgos de la comunicación, y factores críticos de
éxito (CSF)  Identificación de los mecanismos que se utilizan para comunicarse con
las partes interesadas y permitir el acceso a la arquitectura de la información,
tales como reuniones, boletines, repositorios, etc  Identificación de un calendario
de comunicaciones, mostrando qué comunicaciones se produzcan con cuál grupo de
participantes en qué momento y en qué lugar 

36.2.13 Evaluación de cumplimiento

Propósito

Una vez que una arquitectura se ha definido, es necesario para gobernar que la
arquitectura a través de la aplicación para asegurarse de que el original
Architecture Vision se realiza de manera adecuada y que ningún aprendizajes de
implementación se introducen de nuevo en el proceso de la arquitectura. Revisiones
de cumplimiento del período de los proyectos de aplicación proporcionan un
mecanismo para revisar el progreso del proyecto y asegurarse de que el diseño y la
implementación se avanzan en línea con los objetivos estratégicos y
arquitectónicos.
Contenido

Los contenidos típicos de una Evaluación de Cumplimiento son:    Información

general sobre el progreso y el estado del proyecto  Descripción general de la
arquitectura del proyecto / diseño  Completadas las listas de verificación de
arquitectura:  o o o o o Hardware y sistema operativo lista  Los servicios de
software y middleware lista  Aplicaciones listas de comprobación  Listas de control
de gestión de la información  Listas de control de seguridad 

  Página 456 de 670 

TOGOF 9.1    
o o o Listas de control de gestión del sistema  Listas de control de ingeniería de
sistemas  Métodos y herramientas de listas de verificación 

36.2.14 Implementación y Plan de Migración

Propósito

La aplicación y el Plan de Migración ofrece un calendario de los proyectos que

realizarán la arquitectura destino. La aplicación y el Plan de Migración incluye
proyectos ejecutables agrupados en carteras y programas gestionados. La
Implementación y Estrategia de migración de identificar el enfoque para el cambio
es un elemento clave de la aplicación y el Plan de Migración.
Contenido

Contenido típico de una aplicación y el Plan de Migración son:  Implementación y

Estrategia de migración:  o o  Dirección estratégica aplicación  Enfoque de
secuenciación de Implementación 

Proyectos y Distribución de la cartera de ejecución:  o o o o o Asignación de los

paquetes de trabajo para proyectar y de cartera  Capacidades entregados por
proyectos  Hitos y calendario  Estructura de desglose del trabajo  Puede incluir el
impacto sobre la cartera existente, programa y proyectos 

Puede contener:  Cartas del proyecto:  o o o o o Paquetes de trabajo incluidos  El

valor del negocio  Riesgo, problemas, hipótesis, dependencias  Las necesidades de
recursos y los costes  Beneficios de la migración, determinados (incluyendo la
asignación a los requerimientos del negocio)  Estimación de los gastos de las
opciones de migración 

  Página 457 de 670 

TOGOF 9.1    
36.2.15 Implementación Modelo de Gobierno
Propósito

Una vez que una 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 las funciones de la
arquitectura, no es probable que sea un marco de gobernanza que ya existen, pero
los procesos específicos, las organizaciones, los roles, las responsabilidades y
las medidas puede ser necesario definir sobre una base de proyecto por proyecto. El
Gobierno asegura Modelo de Aplicación de que un proyecto de transición a la
aplicación también pasa de manera ordenada en la gobernanza arquitectura apropiada.
Contenido

Contenido típico de un Modelo de Gobierno de Ejecución se encuentran:     Los

procesos de gobernanza  Estructura de la organización de Gobierno  Funciones y
responsabilidades de Gobierno  Los puestos de control de gobierno y los criterios
de éxito / fracaso 

36.2.16 Modelo Organizacional para Arquitectura Empresarial

Propósito

Para que un marco de arquitectura para ser utilizado con éxito, debe ser apoyado
por la correcta organización, las funciones y las responsabilidades dentro de la
empresa.De particular importancia es la definición de los límites entre los
distintos profesionales de arquitectura empresarial y de las relaciones de
gobernanza que se extienden a través de estas fronteras.
Contenido

Contenido típico de un modelo organizativo para la arquitectura de la empresa son

los siguientes:       Ámbito de las organizaciones afectadas  La evaluación
gestacional, lagunas, y el enfoque de resolución  Roles y responsabilidades de
equipo de arquitectura (s)  Las restricciones sobre el trabajo de arquitectura 
Necesidades presupuestarias  Gobernabilidad y estrategia de apoyo 

  Página 458 de 670 

TOGOF 9.1    
36.2.17 Solicitud de Arquitectura Trabajo
Propósito

Este es un documento que se envía desde la organización patrocinadora de la

organización Arquitectura para desencadenar el inicio de un ciclo de desarrollo de
la arquitectura. Las solicitudes de Arquitectura trabajo se pueden crear como una
salida de la fase preliminar, a raíz de las solicitudes de cambio aprobadas
arquitectura, o los términos de referencia para el trabajo de arquitectura
procedentes de planificación de la migración. En general, toda la información
contenida en este documento debe estar a un nivel alto.
Contenido

Las solicitudes de Arquitectura trabajo suelen incluir:             

Patrocinadores Organización  Declaración de la misión de la Organización  Los
objetivos de negocio (y cambios)  Los planes estratégicos de la empresa  Plazos 
Los cambios en el entorno empresarial  Limitaciones de organización  La información
presupuestaria, las limitaciones financieras  Las restricciones externas,
restricciones comerciales  Descripción del sistema de negocio actual  Descripción
del sistema actual arquitectura / TI  Descripción de desarrollar organización 
Descripción de los recursos disponibles para el desarrollo de la organización 

Evaluación de Impacto 36.2.18 Requisitos

Propósito

A lo largo de la ADM, la nueva información se recoge en relación con una

arquitectura . Como se recoge esta información, nuevos hechos pueden salir a la luz
que invalida los aspectos actuales de la arquitectura. A Requisitos de evaluación
de impacto evalúa los requisitos de arquitectura actuales y las especificaciones
para identificar los cambios que se deben hacer y las implicaciones de esos
cambios.

  Página 459 de 670 

TOGOF 9.1    
Contenido

Los contenidos típicos de una Evaluación de Impacto Los requisitos son:      

 Referencia a los requisitos específicos  Prioridad de los interesados de los
requisitos a la fecha  Fases para ser revisitados  Fase de llevar sobre los
requisitos de priorización  Los resultados de las investigaciones de fase y
prioridades revisadas  Recomendaciones sobre la gestión de requisitos  Número de
referencia del Repositorio 

Solución 36.2.19 Building Blocks

-Implementación específica bloques de construcción de la empresa Arquitectura
repositorio; véase la Parte IV , 37. Building Blocks .

36.2.20 Declaración de Arquitectura de Trabajo

Propósito

La Declaración de Arquitectura Trabajo define el alcance y el enfoque que se

utilizará para completar un ciclo de desarrollo de la arquitectura. La Declaración
de Arquitectura El trabajo es por lo general el documento contra el cual se medirá
la ejecución exitosa del proyecto de arquitectura y puede constituir la base de un
acuerdo contractual entre el proveedor y el consumidor de servicios de
arquitectura.
Contenido

Los contenidos típicos de una Declaración de Arquitectura Trabajo son:      

  Título  Arquitectura solicitud de proyecto y antecedentes  Arquitectura
Descripción y alcance del proyecto  Descripción general de Arquitectura Visión 
Cambio específico de los procedimientos de alcance  Las funciones, las
responsabilidades y los entregables  Criterios y procedimientos de aceptación  Plan
de la configuración y programación del proyecto 
  Página 460 de 670 

TOGOF 9.1    
 Aprobaciones 

36.2.21 Tailored Architecture Framework

Propósito

TOGAF proporciona un marco estándar de la industria para la arquitectura que se

puede utilizar en una amplia variedad de organizaciones. Sin embargo, antes de
TOGAF se puede utilizar con eficacia dentro de un proyecto de arquitectura,
sastrería a dos niveles es necesario. En primer lugar, es necesario adaptar el
modelo TOGAF para la integración en la empresa. Esta adaptación incluye la
integración con los marcos de los proyectos y de gestión de 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 el detalle de las estructuras adoptadas también deben alinearse con
otros factores contextuales para la empresa, tales como la cultura, las partes
interesadas, los modelos comerciales para la arquitectura de la empresa, y el nivel
actual de la arquitectura de Capacidad. 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. Adaptación a este nivel seleccionará entregables y
artefactos adecuados para satisfacer las necesidades del proyecto y las partes
interesadas. Véase la Parte II , 6.4.5 Tailor TOGAF y, en su caso, Otros
arquitectura marco seleccionado (s) para otras consideraciones al seleccionar y
adaptar el marco de la arquitectura.
Contenido

Contenido típico de un Marco de Arquitectura Tailored son:     Método de

arquitectura adaptada  Adaptado contenido de la arquitectura (entregables y
artefactos)  Herramientas de configurar e implementar  Interfaces con modelos de
gobierno y otros marcos:  o o o o o Planificación Ejecutiva  Arquitectura
Empresarial  Portafolio, Programa, Gestión de Proyectos  Desarrollo de Sistemas /
Ingeniería  Operaciones (Servicios) 

  Página 461 de 670 

TOGOF 9.1       

37. Bloques de Construcción

En este capítulo se explica el concepto de bloques de construcción.

37.1 Información general

Esta sección tiene por objeto explicar e ilustrar el concepto de bloques de
construcción en la arquitectura. Después de esta visión general, hay dos partes
principales:  Introducción a los Bloques de construcción (véase 37.2 Introducción
a los Bloques de Construcción ), discute los conceptos generales de bloques de
construcción, y explica las diferencias entre Arquitectura Bloques de Construcción
(Abs) y solución Building Blocks (SBB).  Bloques de Construcción y la ADM ( 37.3
Bloques de Construcción y el ADM ), resume las etapas en las que el diseño y la
especificación de bloque de construcción se produce dentro de la Arquitectura
Método de Desarrollo de TOGAF (ADM). 

37.2 Introducción a los Bloques de Construcción

Esta sección es una introducción al concepto de bloques de construcción.

37.2.1 Información general

En esta sección se describen las características de los bloques de construcción. La
utilización de bloques de construcción en el ADM se describe por separado en 37.3
Bloques de Construcción y el ADM .

37.2.2 Características genéricas

Bloques de construcción tienen características genéricas de la siguiente manera: 
    Un bloque de construcción es un paquete de funcionalidad definida para
satisfacer las necesidades del negocio en toda la organización.  Un bloque de
construcción tiene un tipo que corresponde al contenido metamodelo TOGAF (como
actor, servicio de negocios, la aplicación, o entidad de datos)  Un bloque de
construcción tiene un límite definido y es generalmente reconocido como "una cosa"
por los expertos de dominio.  Un bloque de construcción puede interoperar con
otros, bloques de construcción, interdependientes.  Un buen bloque de construcción
tiene las siguientes características: 

  Página 462 de 670 

TOGOF 9.1    
o Se considera la implementación y el uso, y evoluciona para explotar la tecnología
y las normas.  Se puede ensamblar a partir de otros bloques de construcción.  Puede
ser un subconjunto de otros bloques de construcción.  Lo ideal es un bloque de
construcción es reutilizable y reemplazable, y bien especificado. 

o o o

Frontera y la especificación de un bloque de construcción deben ser débilmente

acoplados a su aplicación; es decir, debe ser posible realizar un bloque de
construcción de varias maneras diferentes sin impactar en el límite o la
especificación del bloque de construcción. La forma en que los medios y capacidades
se montan en bloques de construcción pueden variar ampliamente entre las
arquitecturas individuales. Cada organización debe decidir por sí mismo lo que la
disposición de bloques de construcción que funciona mejor para él. 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 están construidos a partir de colecciones de
bloques de construcción, por lo que la mayoría de los bloques de construcción que
interoperar con otros bloques de construcción. Dondequiera que eso 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 la etapa de desarrollo de la arquitectura se ha
alcanzado. Por ejemplo, en una etapa temprana, un bloque de construcción puede
consistir simplemente en un nombre o una breve descripción. Más tarde, un bloque de
construcción se puede descomponer en varios bloques de edificios de apoyo y puede
ir acompañada de una especificación completa. El nivel de detalle al que se debe
especificar un bloque de construcción depende de los objetivos de la arquitectura
y, en algunos casos, menos detalle puede ser de mayor valor (por ejemplo, en la
presentación de las capacidades de una empresa, una única clara y concisa la imagen
tiene más valor que una densa especificación de 100 páginas). El OMG ha
desarrollado un estándar para la Especificación de activos reutilizables (RAS) , 1
que proporciona un buen ejemplo de cómo los bloques de construcción pueden ser
descritas formalmente y gestionados.

37.2.3 Arquitectura Bloques de Construcción

Arquitectura Bloques de Construcción (Abs) se refieren a la Arquitectura Continuum
(véase la Parte V , 39.4.1 Arquitectura Continuum ), y se definen o seleccionados
como resultado de la aplicación de la ADM.
37.2.3.1 Características

Abs:

  Página 463 de 670 

TOGOF 9.1    
  Captura de requisitos de arquitectura; requisitos, por ejemplo, de negocio,
datos, aplicaciones y tecnología  Dirigir y orientar el desarrollo de SBB 

37.2.3.2 Especificación Contenido

Especificaciones de ABB son los siguientes, como mínimo:      Funcionalidad y

atributos fundamentales: semántico, sin ambigüedades, incluyendo la capacidad de
seguridad y capacidad de gestión  Interfaces: conjunto elegido, suministrado  La
interoperabilidad y la relación con otros bloques de construcción  Bloques de
construcción dependientes con la funcionalidad requerida y las interfaces de
usuario con nombre  Mapa de negocios / entidades organizativas y políticas 

37.2.4 Solución Building Blocks

Solución Building Blocks (SBB) se relacionan con el Continuum Solutions (véase la
Parte V , 39.4.2 Soluciones Continuum ), y puede ser o bien adquieren o se
desarrollan.
37.2.4.1 Características

SBB:     Definir cuáles son los productos y componentes serán implementar la

funcionalidad  Definir la ejecución  Cumplir los requisitos de negocio  Son
producto o proveedores conscientes 

37.2.4.2 Especificación Contenido

Especificaciones SBB incluyen los siguientes, como mínimo:     Funcionalidad y

atributos específicos  Interfaces; el conjunto implementado  SBB necesarios que se
utilizan con la funcionalidad y los nombres de las interfaces utilizadas requerido 
Mapeo de la SBB con la topología de TI y las políticas operacionales 

  Página 464 de 670 

TOGOF 9.1    
 Especificaciones de atributos compartidos a través del medio ambiente (que no
debe confundirse con la funcionalidad), tales como seguridad, manejabilidad,
localizabilidad, escalabilidad  Rendimiento, capacidad de configuración 
Conductores Diseño y limitaciones, incluyendo la arquitectura física  Las
relaciones entre los SBB y ABBS 

  

37.3 Bloques de Construcción y el ADM

37.3.1 Principios básicos
Esta sección se centra en el uso de los bloques de construcción de la ADM.
Consideraciones generales y características de los bloques de construcción se
describen en 37.2 Introducción a los Bloques de Construcción .
37.3.1.1 pilares en Arquitectura

Una arquitectura es un conjunto de bloques de construcción representados en un

modelo arquitectónico, y una especificación de cómo esos bloques de construcción
están conectados a cumplir con los requisitos generales de la empresa. Los diversos
bloques de construcción en una arquitectura especifican el alcance y el enfoque que
se utilizará para hacer frente a un problema de negocio específico. Hay algunos
principios generales que sustentan el uso de bloques de construcción en el diseño
de arquitecturas específicas:   Una arquitectura sólo debe contener elementos
básicos que son relevantes para el problema de negocio que la arquitectura está
tratando de resolver.  Bloques de construcción pueden tener relaciones complejas
entre sí. A una cuadra del edificio puede soportar múltiples bloques de
construcción o puede apoyar parcialmente un solo bloque de construcción (por
ejemplo, el servicio de negocio de "la tramitación de reclamaciones" sería apoyada
por muchas entidades de datos y, posiblemente, varios componentes de la
aplicación).  Bloques de construcción deben ajustarse a las normas pertinentes de
su tipo, los principios de la empresa, así como las normas de la empresa. 

37.3.1.2 Módulo de Diseño

El proceso de identificación de bloques de construcción incluye el estudio de las

colecciones de las capacidades o activos que interactúan entre sí y luego
dibujarlos juntos o haciéndolos diferente:  Considere tres clases de bloques de
construcción:  o Bloques de construcción reutilizables, como los elementos
heredados 

  Página 465 de 670 

TOGOF 9.1    
o Bloques de construcción a ser objeto de desarrollo, tales como las nuevas
aplicaciones  Bloques de construcción a ser objeto de adquisición; es decir,
Commercial OffThe-Shelf (COTS) aplicaciones 

o 

Utilice el nivel deseado de integración para unir o combinar funciones en bloques

de construcción. Por ejemplo, los elementos heredados podrían ser tratados como
grandes bloques de construcción para evitar que éstas se descompongan. 

En las primeras etapas y durante visitas de la empresa de más alto nivel, los
bloques de construcción son a menudo mantenidos en una definición amplia
integración. Es durante estos ejercicios en que las definiciones de servicios a
menudo puede ser mejor vieron. Como se abordan consideraciones de implementación,
vistas más detalladas de bloques de construcción a menudo pueden utilizarse para
hacer frente a las decisiones de implementación, se centran en las decisiones
estratégicas críticas, o la ayuda en la evaluación del valor y el impacto futuro de
lo común y reutilización.

37.3.2 Módulo Especificación de procesos en el ADM

El proceso de definición de bloque de construcción se lleva a cabo gradualmente a
medida que la ADM es seguido, sobre todo en las fases A, B, C y D. Se trata de un
proceso iterativo porque como definición procede, información detallada sobre la
funcionalidad requerida, las limitaciones impuestas a la arquitectura , y la
disponibilidad de los productos puede afectar a la elección y el contenido de
bloques de construcción. Las partes clave de la ADM en el que los bloques de
construcción están diseñados y especificados se resumen a continuación. La obra más
importante en estos pasos consiste en identificar los ABBS necesarios para cumplir
con las metas y objetivos de negocio. El conjunto seleccionado de ABBS se refina en
un proceso iterativo para llegar a un conjunto de SBB, que puede ser comprado o
bien off-the-shelf o la costumbre desarrollada. La especificación de la
construcción de bloques utilizando el ADM es un proceso evolutivo e iterativo. Las
fases y etapas del ADM en el que se desarrollaron y se especifican los bloques de
construcción principales se resumen a continuación, y se ilustran en la Figura 37-1
.

  Página 466 de 670 

TOGOF 9.1    

  Figura 37‐
1: Fases ADM / Pasos clave en la que los bloques de construcción están Evolved / 
especificado    

  Página 467 de 670 

TOGOF 9.1       

Parte V

Continuum Empresarial y Herramientas

 

  

  Página 468 de 670 

TOGOF 9.1    

38. Introducción 
Este capítulo proporciona una introducción y una visión general de los contenidos
de la Parte V: Empresa Continuum y Herramientas .

38.1 Introducción
Por lo general es imposible crear una única arquitectura unificada que reúne todos
los requisitos de todas las partes interesadas de todos los tiempos. Por lo tanto,
la empresa arquitecto tendrá que lidiar no sólo con una única arquitectura de la
empresa, pero con muchas arquitecturas empresariales relacionados. Cada
arquitectura tendrá un propósito diferente y arquitecturas se relacionan entre sí.
Efectivamente delimita el ámbito de aplicación de una arquitectura , por tanto, es
un factor crítico de éxito en permitir que los arquitectos para romper un espacio
de problemas complejos en componentes manejables que se pueden abordar de forma
individual. The Enterprise Continuum ofrece una vista del Repositorio de
Arquitectura que muestra la evolución de estas arquitecturas relacionadas de
genérico a lo específico, de lo abstracto a concreto y de lógica física. Esta parte
de TOGAF Enterprise Continuum discute; incluyendo el Continuum Arquitectura y el
Continuum Solutions. En él se describe cómo las arquitecturas se pueden particionar
y organizados dentro de un repositorio. También se describen las herramientas para
el desarrollo de la arquitectura.

38.2 Estructura de la Parte V

Parte V: Empresa Continuum y Herramientas se estructura de la siguiente manera:
Introducción (este capítulo)  The Enterprise Continuum (ver 39. Empresa Continuum )
describe una vista del Repositorio de Arquitectura que proporciona métodos para
clasificar la arquitectura y los artefactos de la solución, que muestra cómo los
diferentes tipos de artefactos evolucionan, y cómo pueden ser aprovechados y
reutilizados.  Arquitectura Particionamiento (ver
40. Arquitectura de particionamiento ) describe las diversas características que se
pueden aplicar para clasificar y luego arquitecturas de partición.  La Arquitectura
Repositorio (ver 41. Arquitectura Repositorio ) muestra cómo las clasificaciones
abstractas de la arquitectura se pueden aplicar a una estructura de repositorio
para que las arquitecturas pueden ser organizadas y de fácil acceso. 

  Página 469 de 670 

TOGOF 9.1    
Herramientas para el desarrollo de la arquitectura (véase
42. Herramientas para el desarrollo  de la arquitectura ) proporciona directrices
sobre la selección de un conjunto de herramientas para crear y administrar los
artefactos arquitectónicos. 

     

  Página 470 de 670 

TOGOF 9.1    

  

39. Continuum Empresarial

39.1 Información general
The Enterprise Continuum ofrece métodos para clasificar la arquitectura y los
artefactos de la solución, tanto internos como externos en el Repositorio de
Arquitectura, a medida que evolucionan a partir de genéricos Arquitecturas
Fundación a las arquitecturas Organización Específicos. The Enterprise Continuum
permite al arquitecto para articular la perspectiva amplia de qué, por qué, y cómo
la arquitectura de la empresa ha sido diseñado con los factores y los conductores
considerados. The Enterprise Continuum es una ayuda importante para la comunicación
y el entendimiento, tanto dentro de las empresas individuales, y entre las empresas
de los clientes y organizaciones de vendedores. Sin una comprensión de "qué lugar
del continuum que eres", gente discutiendo la arquitectura a menudo pueden hablar
con propósitos cruzados, ya que hacen referencia a diferentes puntos en el
continuo, al mismo tiempo, sin darse cuenta. Cualquier arquitectura es un contexto
específico; Por ejemplo, hay arquitecturas que son específicos a los clientes
individuales, industrias, subsistemas, productos y servicios. Arquitectos, tanto en
el lado de la compra y el lado de la oferta, deben tener a su disposición un
lenguaje coherente para comunicar eficazmente las diferencias entre las
arquitecturas. Tal lenguaje permitirá eficiencia de la ingeniería y el
aprovechamiento eficaz de Commercial Off-The-Shelf (COTS) la funcionalidad del
producto. The Enterprise Continuum establece que un lenguaje coherente. The
Enterprise Continuum permite a la organización de los artefactos de arquitectura
reutilizables y activos de soluciones para maximizar las oportunidades de inversión
de arquitectura empresarial.

39.2 de Enterprise Continuum y Arquitectura Re-Uso

La manera más simple de pensar de la Empresa Continuum es como una vista del
repositorio de todos los activos de la arquitectura. Puede contener descripciones
de arquitectura, maquetas, bloques de construcción, modelos, puntos de vista, y
otros artefactos - que existen tanto dentro de la empresa y en la industria de TI
en general, que la empresa considere haya disponible para el desarrollo de
arquitecturas para la empresa. Los ejemplos de artefactos de arquitectura y
soluciones internas son los entregables del trabajo previo de la arquitectura, que
están disponibles para su reutilización.Los ejemplos de la arquitectura y la
solución artefactos externos son la gran variedad de modelos de
  Página 471 de 670 

TOGOF 9.1    

referencia de la industria y los patrones de arquitectura que existen, y están

continuamente surgiendo, incluyendo aquellas que son muy genérico (como el modelo
de referencia técnica TOGAF (TRM)); las específicas de ciertos aspectos de la
tecnología (por ejemplo, una arquitectura de servicios web, o una arquitectura de
gestión genéricos); las específicas de ciertos tipos de tratamiento de la
información, tales como el comercio electrónico, gestión de la cadena de
suministro, etc; y las específicas de ciertas industrias verticales, como los
modelos generados por consorcios verticales como TMF (en el sector de las
Telecomunicaciones), ARTE (Retail), Energistics (petrotécnicos), etc La
arquitectura de la empresa determina que la arquitectura y los artefactos de la
solución de una organización incluye en su arquitectura de repositorio. La
reutilización es una consideración importante en esta decisión.

39.3 Los constituyentes de la Empresa Continuum

Una visión general del contexto y de los constituyentes de la Empresa Continuum se
muestra en la Figura 39-1 .

 
Figura 39‐1: Empresa Continuum   

    Página 472 de 670 

TOGOF 9.1    

The Enterprise Continuum está dividida en tres continua distinta de la siguiente

manera:
La empresa Continuum (ver 39.4 Empresa Continuum en detalle ) es el continuum más
externa y clasifica los activos relacionados con el contexto de la estructura
general de la empresa. Las clases de Enterprise Continuum de activos pueden influir
en las arquitecturas, pero no se utilizan directamente durante el desarrollo de la
arquitectura ADM. The Enterprise Continuum clasifica los activos contextuales
utilizados para desarrollar arquitecturas, como las políticas, normas, iniciativas
estratégicas, estructuras organizativas y capacidades de nivel empresarial. The
Enterprise Continuum también puede clasificar las soluciones (a diferencia de las
descripciones o especificaciones de soluciones). Por último, la empresa Continuum
contiene dos especialidades, a saber, la Arquitectura y Soluciones Continua.  La
Arquitectura Continuum (ver 39.4.1 Arquitectura Continuum ) ofrece una manera
consistente para definir y entender las reglas genéricas, las representaciones y
las relaciones en una arquitectura, incluyendo las relaciones de trazabilidad y de
derivación (por ejemplo, para demostrar que una Arquitectura Organización
Específico se basa en una industria o norma genérica). La Arquitectura Continuum
representa una estructuración de Arquitectura Bloques de Construcción (Abs) que son
activos arquitectura reutilizables. ABBS evolucionan a través de su ciclo de vida
de desarrollo de entidades abstractas y genéricas que expresan plenamente activos
Organización de una arquitectura específica. Los activos Arquitectura Continuum se
utilizarán para orientar y seleccionar los elementos de la serie continua de
soluciones (véase más adelante). La Arquitectura Continuum muestra las relaciones
entre los marcos fundamentales (como TOGAF), arquitecturas de sistemas comunes
(como el III-RM), arquitecturas industriales y arquitecturas empresariales. La
Arquitectura Continuum es una herramienta útil para descubrir en común y eliminar
la redundancia innecesaria.  El Continuum Soluciones (ver
39.4.2 Soluciones Continuum ) proporciona una forma consistente para describir y
comprender la aplicación de los activos definidos en la Arquitectura Continuum. El
Continuum Soluciones define lo que está disponible en el entorno de la organización
como reutilizables Solution Building Blocks (SBB). Las soluciones son el resultado
de acuerdos entre los clientes y los socios de negocios que implementan las reglas
y relaciones definidas en el espacio de la arquitectura. El Continuum Soluciones
aborda los aspectos comunes y las diferencias entre los productos, sistemas y
servicios de los sistemas implementados. 

The Enterprise Continuum clasifica los activos de arquitectura que son aplicables
en todo el ámbito de la arquitectura de la empresa. Estos activos, que pueden ser
referidos como bloques de construcción, pueden representar una variedad de
elementos que en conjunto definen y limitan la arquitectura empresarial. Ellos
pueden tomar la forma de los objetivos de negocio y objetivos, iniciativas
estratégicas, capacidades, políticas, normas y principios. The Enterprise Continuum
también contiene el Continuum Arquitectura y el Continuum Solutions. Cada uno de
estos Continua se describe en mayor detalle en las siguientes secciones.

  Página 473 de 670 

TOGOF 9.1    

39.4 Continuum Empresarial en detalle

The Enterprise Continuum pretende representar la clasificación de todos los activos
que están disponibles para una empresa. Clasifica los activos que existen dentro de
la empresa junto con otros activos en el medio ambiente en general que son
relevantes para la empresa, como los productos, la investigación, los factores del
mercado, factores comerciales, estrategias de negocios, y la legislación. TOGAF
pretende ser un marco para la realización de arquitectura de la empresa, y como
resultado muchos de los activos que se encuentran dentro de la Empresa Continuum
están más allá de la consideración específica del marco TOGAF. Sin embargo, las
arquitecturas están conformadas fundamentalmente por las preocupaciones fuera de la
práctica de la arquitectura y por lo tanto de suma importancia es que toda la
arquitectura debe reflejar con precisión el contexto externo. Los factores
contextuales específicas a ser identificados e incorporados en una arquitectura
variarán desde la arquitectura a la arquitectura. Sin embargo, los factores
contextuales típicos para el desarrollo de la arquitectura es probable que
incluyan:
Factores que influyen externos, como el cambio de reglamentación, los avances
tecnológicos, y la actividad de la competencia  Estrategia y el contexto de
negocios, incluyendo fusiones, adquisiciones y otros requisitos de transformación
empresarial  Operaciones de negocios actuales, lo que refleja las arquitecturas y
soluciones implementadas 

Al observar el contexto de la arquitectura, se puede observar que existe actividad

de desarrollo de la arquitectura dentro de un ciclo de vida de la empresa más
amplia de cambio continuo. ABBS se definen en relación a un conjunto de factores
contextuales y luego se dio cuenta a través de SBB. SBB se despliegan en forma de
soluciones en vivo y se convierten en una parte del modelo de operación de línea de
base de la empresa. El modelo de explotación de la empresa y la información
empírica sobre el desempeño de la empresa conforma el contexto y los requisitos
para el cambio futuro. Por último, estos nuevos requisitos para el cambio crean una
retroalimentación de lazo para influir en la creación de nuevas arquitecturas de
destino.
39.4.1 Arquitectura Continuum

La Arquitectura Continuum ilustra cómo se desarrollan y evolucionan las

arquitecturas a través de un continuo que va desde la Fundación arquitecturas, como
la proporcionada por TOGAF, a través de los Sistemas Comunes de Arquitecturas y
Industria Arquitecturas y las propias arquitecturas específicos de la organización
de una empresa.
  Página 474 de 670 

TOGOF 9.1    

Las flechas en el Continuum Arquitectura representan la relación que existe entre

las diferentes arquitecturas de la Arquitectura Continuum. La dirección hacia la
izquierda se centra en satisfacer las necesidades de la empresa y los
requerimientos del negocio, mientras que la dirección hacia la derecha se centra en
el aprovechamiento de los componentes arquitectónicos y bloques de construcción.

 
Figura 39‐2: Arquitectura Continuum 

Las necesidades de la empresa y los requerimientos del negocio se abordan en

detalle creciente de izquierda a derecha. El arquitecto tendrá una apariencia
típica de encontrar elementos arquitectónicos reutilizables hacia la izquierda del
continuo. Cuando no se encuentran elementos, los requisitos para los elementos que
faltan se pasan a la izquierda de la continuo para su incorporación. Esas
arquitecturas de aplicación dentro de sus propias organizaciones pueden utilizar
los mismos modelos continuos especializados para su negocio. Los cuatro tipos de
arquitectura particulares ilustradas en la Figura 39-2 están destinados a indicar
la gama de diferentes tipos de arquitectura que se puedan desarrollar en diferentes
puntos en el continuo; que no son fijos etapas en un proceso. Muchos tipos
diferentes de la arquitectura pueden ocurrir en los puntos entre las ilustradas en
la Figura 39-2 . Aunque la serie continua transformación evolutiva ilustrado no
representa un proceso formal, representa una progresión, que se produce en varios
niveles:
Lógico para física  Horizontal (IT centrada) a vertical (centrado en las empresas) 
Generalización de la especialización  Taxonomía para completar y especificación
específica de la arquitectura 

En cada punto del continuo, una arquitectura está diseñada en función de los
conceptos de diseño y los módulos disponibles y pertinentes a ese punto.
  Página 475 de 670 

TOGOF 9.1    

Las cuatro arquitecturas ilustrados en la Figura 39-2 representan principales

clasificaciones de las arquitecturas posibles, y serán relevantes y familiar para
muchos arquitectos. Ellos se analizan en detalle a continuación.
Fundación Arquitectura

Una Fundación de Arquitectura consta de componentes genéricos, interrelaciones,

principios y directrices que proporcionan una base sobre la que las arquitecturas
más específicas se pueden construir. El TOGAF ADM es un proceso que apoye la
especialización de dichas arquitecturas de la Fundación con el fin de crear modelos
específicos de la organización. El TOGAF TRM describe una arquitectura fundamental
sobre el que pueden basarse otras arquitecturas, más específicos. Ver 43. Fundación
Arquitectura: Técnico Modelo de Referencia para más detalles.
Sistemas Comunes Arquitecturas

Sistemas Comunes Arquitecturas guiar la selección e integración de los servicios

específicos de la Architecture Foundation para crear una arquitectura útil para la
construcción de soluciones comunes (es decir, altamente reutilizables) en una
amplia serie de ámbitos pertinentes. Ejemplos de sistemas comunes Arquitecturas
incluyen: un título de arquitectura, una arquitectura de gestión, una arquitectura
de red, una arquitectura operaciones, etc Cada uno es incompleto en términos de
funcionalidad general del sistema, pero es completa en términos de un dominio
determinado problema (seguridad, capacidad de gestión, la creación de redes,
operaciones, etc), por lo que las soluciones que implementan la arquitectura
constituyen bloques de construcción reutilizables para la creación de estados de
funcionamiento funcionalmente completos de la empresa. Otras características de los
sistemas comunes Arquitecturas incluyen:
Refleja los requisitos específicos de un dominio del problema genérico  Define
componentes básicos específicos de un dominio del problema genérico  Define los
estándares de negocios, datos, aplicaciones, o de tecnología para la implementación
de estos bloques de construcción  Proporciona elementos básicos para los gastos
fáciles reutilización y bajos 

El TOGAF Integrado de Información de Referencia Infraestructura Modelo (III-RM)

véase la parte VI , 44. Integrado de Información Infraestructura Modelo de
referencia- es un modelo de referencia que apoya la descripción de los sistemas de
Common Architecture en el dominio
  Página 476 de 670 

TOGOF 9.1    

de aplicación que se centra en los requisitos, bloques de construcción, y las

normas relativas a la visión del flujo de información sin fronteras.
Arquitecturas de la Industria

Arquitecturas Industria guían la integración de los componentes de los sistemas

comunes con componentes específicos de la industria, y orientar la creación de
soluciones de la industria para los problemas de los clientes específicos dentro de
una industria en particular. Un ejemplo típico de un componente específico de la
industria es un modelo de datos que representa las funciones y los procesos de
negocio específicos de un sector vertical en particular, como la arquitectura de la
industria al por menor "Activo tienda", o un Sector Arquitectura que incorpora el
modelo de datos Energistics (consulte www.energistics.org ). Otras características
de la Industria Arquitecturas incluyen:
Refleja los requisitos y las normas específicas de un sector vertical  Define
componentes básicos específicos de un dominio del problema genérico  Contiene datos
lógicos específicos de la industria y modelos de procesos  Contiene aplicaciones
específicas de la industria y modelos de procesos, así como las reglas de negocio
específicos de la industria  Proporciona directrices para las pruebas de las
colecciones de los sistemas  Alienta a los niveles de interoperabilidad en toda la
industria  Arquitecturas-organización específica

Arquitecturas específicos de la organización describen y guían la implementación

final de componentes de la solución para una empresa en particular o red de
empresas conectadas extendido. Puede haber una variedad de arquitecturas de
Organización-específicas que se necesitan para cubrir eficazmente las necesidades
de la organización mediante la definición de las arquitecturas de los crecientes
niveles de detalle. Alternativamente, esto podría dar lugar a varias arquitecturas
más detallados-organización específica para entidades específicas dentro de la
empresa global. Desglosando Arquitecturas-organización específica en piezas
constituyentes se aborda en el 40. Arquitectura de particionamiento . La
Arquitectura Organización-específico guía la personalización final de la solución,
y tiene las siguientes características:

  Página 477 de 670 
TOGOF 9.1    
Proporciona un medio para comunicar y gestionar las operaciones de negocio a través
de las cuatro áreas de arquitectura  Refleja los requisitos específicos para una
empresa en particular  Define bloques de construcción específicos para una empresa
en particular  Contiene modelos de negocio específicos de la organización, datos,
aplicaciones y tecnologías  Proporciona un medio para fomentar la implementación de
soluciones adecuadas para satisfacer las necesidades empresariales  Proporciona los
criterios para medir y seleccionar los productos adecuados, soluciones, y
servicios  Proporciona un camino evolutivo para apoyar el crecimiento y las nuevas
necesidades de la empresa 

39.4.2 Soluciones Continuum

El Continuum Soluciones representa la especificación detallada y la construcción de

las arquitecturas en los niveles correspondientes de la Arquitectura Continuum. En
cada nivel, el Continuum Solutions es una población de la arquitectura con bloques
de construcción de referencia - bien los productos comprados o componentes
integrados - que representan una solución a las necesidades de negocio de la
empresa expresaron en ese nivel. Un repositorio poblada basado en el Continuo
Soluciones puede considerarse como un inventario de soluciones o re-uso de la
biblioteca, que se puede añadir un valor significativo a la tarea de gestionar e
implementar mejoras a la empresa. El Continuum Soluciones se ilustra en la Figura
39-3 .

    
Figura 39‐3: Soluciones de Continuidad 

"Mover a la derecha" en el Continuo Soluciones se centra en proporcionar soluciones

de valor (es decir, las soluciones de cimentación proporcionan valor en la creación
de soluciones de sistemas comunes; soluciones de sistemas comunes se utilizan para
crear soluciones de la industria, y las soluciones industriales que se utilizan
para crear soluciones
  Página 478 de 670 

TOGOF 9.1    

específicas de la organización ). "Mover a la izquierda" en el Continuo Soluciones

se centra en hacer frente a las necesidades empresariales. Estos dos puntos de
vista son importantes para una empresa tratando de centrarse en sus necesidades y
aumentar al máximo el uso de los recursos disponibles a través del apalancamiento.
Los apartados siguientes describen cada uno de los tipos de soluciones dentro del
Continuum Solutions.
Soluciones Fundación

Soluciones Fundación son conceptos muy genéricos, herramientas, productos,

servicios y componentes de la solución, que son los proveedores fundamentales de
capacidades. Los servicios incluyen servicios profesionales - tales como la
capacitación y servicios de consultoría - que garantizan el valor máximo de
inversión de las soluciones en el menor tiempo posible; y servicios de apoyo - como
el Help Desk - que garantizan el máximo valor posible de las soluciones (servicios
que aseguran las actualizaciones oportunas y mejoras de los productos y sistemas).
Soluciones Ejemplo Fundación incluirían los lenguajes de programación, sistemas
operativos, estructuras de datos fundamentales (como EDIFACT), enfoques genéricos
organización estructuración, estructuras fundamentales para la organización de las
operaciones de TI (como ITIL), etc
Sistemas Comunes Soluciones
Una solución común de sistemas es una implementación de un sistema de arquitectura
común compuesto por un conjunto de productos y servicios, que pueden ser
certificados o con la marca. Representa el máximo común denominador para una o más
soluciones en los segmentos de la industria que la solución de los Sistemas Comunes
apoya. Sistemas Comunes Soluciones representan colecciones de requisitos y
capacidades comunes, en lugar de los específicos de un cliente o industria en
particular.Sistemas Comunes soluciones proporcionan a las organizaciones con
entornos operativos específicos para las necesidades operativas y de información,
como la alta disponibilidad de los sistemas de almacenamiento de datos escalable de
procesamiento de transacciones y. Ejemplos de sistemas comunes de soluciones
incluyen: un producto de sistema de gestión de la empresa o un producto de sistema
de seguridad. Proveedores de sistemas informáticos son los proveedores típicos de
centradas en la tecnología de sistemas comunes Solutions. "Software como servicio"
proveedores son proveedores habituales de las soluciones de aplicaciones comunes.
Proveedores de
  Página 479 de 670 

TOGOF 9.1    

outsourcing de procesos de negocios son típicas del negocio proporciona capacidad

centrada en sistemas comunes Solutions.
Soluciones para la Industria

Una solución de la Industria es una implementación de una Arquitectura de la

Industria, que ofrece paquetes reutilizables de componentes y servicios comunes
específicos para una industria. Componentes fundamentales son proporcionados por
sistemas comunes Soluciones y / o Fundación Solutions, y se complementan con los
componentes específicos de la industria. Los ejemplos incluyen: un esquema de base
de datos física o un dispositivo de punto de servicio específico de la industria.
Soluciones para la industria son específicas de la industria, las compras agregadas
que están listos para ser adaptado a las necesidades de una organización
individual. En algunos casos, una solución de la industria puede incluir no sólo
una implementación de la arquitectura de la Industria, pero también otros elementos
de la solución, como los productos específicos, servicios y soluciones de sistemas
que sean apropiadas a esa industria.
Solutions-organización específica

Una solución-organización específica es una implementación de la arquitectura de la

Organización específica que proporciona las funciones de la empresa necesarios.Dado
que las soluciones están diseñadas para operaciones específicas de negocio, que
contienen la mayor cantidad de contenido único con el fin de dar cabida a las
personas y los procesos de las organizaciones específicas que varían. Soluciones
Building Organización específicas sobre Soluciones para la industria, sistemas
comunes Soluciones y Fundación Solutions es el principal propósito de conectar el
Continuum Arquitectura al Continuum Solutions, como guiado por los arquitectos
dentro de una empresa. Una solución-organización específica se estructura con el
fin de apoyar los acuerdos específicos Nivel de Servicio (SLA) para asegurar el
apoyo de los sistemas operativos en los niveles de servicio deseados. Por ejemplo,
una aplicación de terceros proveedor de alojamiento puede ofrecer diferentes
niveles de apoyo a los sistemas operativos. Estos acuerdos definen los términos y
condiciones de ese apoyo. Otros factores clave que deben ser definidos dentro de
una solución de Organización Específicos son los parámetros operativos clave y
métricas de calidad que pueden utilizarse para controlar y gestionar el medio
ambiente.
  Página 480 de 670 

TOGOF 9.1    
The Enterprise Continuum puede proporcionar un enlace clave entre la arquitectura,
el desarrollo, y el personal de operaciones por lo que les permite comunicarse y
llegar a un acuerdo sobre los requisitos de apoyo operacionales previstos. El
personal de operaciones a su vez puede acceder al Enterprise Continuum para obtener
información con respecto a los conceptos de operación y requisitos de
compatibilidad de servicios del sistema implementado.

39.5 La Empresa Continuum y el ADM

El TOGAF ADM describe el proceso de desarrollo de una arquitectura específica de la
empresa y una solución (s) específica de la empresa que se ajustan a la
arquitectura mediante la adopción y la adaptación (en su caso) arquitecturas y
soluciones (de izquierda a derecha en la clasificación continua) genéricos. De
manera similar, las arquitecturas y soluciones específicas que han demostrado ser
efectivos y creíbles serán generalizados para su reutilización (de derecha a
izquierda en la clasificación continua). En los lugares pertinentes en todo el
TOGAF ADM, hay punteros a los activos de arquitectura útiles al nivel pertinente de
generalidad en la clasificación continuum. En algunos casos - por ejemplo, en el
desarrollo de una arquitectura Tecnología - esto puede ser la Fundación
Arquitectura TOGAF TRM (ver más abajo). En otros casos - por ejemplo, en el
desarrollo de una arquitectura de negocios - que puede ser un modelo de referencia
para el comercio electrónico tomada de la industria en general. Sí TOGAF ofrece dos
modelos de referencia para la consideración para su uso en el desarrollo de la
arquitectura de una organización:
1. La Fundación Arquitectura TOGAF , que comprende una TRM de los servicios y
funciones genéricas que proporciona una base firme sobre la cual las arquitecturas
más específicos y componentes arquitectónicos se pueden construir. 

2. La Integrado de Información de Referencia Infraestructura Modelo (III-RM), que

se
basa en la Fundación Arquitectura TOGAF, y está específicamente diseñado para
ayudar a la realización de arquitecturas que permiten y apoyan la visión de Flujo
de información sin fronteras. 

Sin embargo, en el desarrollo de las arquitecturas de los distintos dominios dentro

de una arquitectura global de la empresa, el arquitecto tendrá que considerar el
uso y re-uso de una amplia variedad de diferentes activos de la arquitectura, y la
Empresa Continuum ofrece un enfoque para clasificar y comunicar estos diferentes
activos .

39.6 La Empresa Continuum y su organización

Las secciones anteriores han descrito la empresa Continuum, la Arquitectura
Continuum, y el Continuum Solutions. Las siguientes secciones describen las
relaciones entre cada uno de los tres continuos y cómo deben aplicarse estas
relaciones dentro de su organización.
  Página 481 de 670 

TOGOF 9.1     39.6.1 Relaciones

Cada uno de los tres continuos contiene información acerca de la evolución de las
arquitecturas durante su ciclo de vida:
The Enterprise Continuum ofrece un contexto general de las arquitecturas y
soluciones y clasifica los activos que se aplican en todo el ámbito de la empresa. 
La Arquitectura Continuum proporciona un mecanismo de clasificación de los activos
que definen colectivamente la arquitectura en diferentes niveles de evolución de
genérico a lo específico.  El Continuum Soluciones ofrece la clasificación de los
activos para describir las soluciones específicas para la organización que pueden
ser implementadas para lograr el propósito de la arquitectura. 
Las relaciones entre el Continuum Arquitectura y Soluciones Continuum se muestran
en la Figura 39-4 .

 
Figura 39‐4: Las relaciones entre la arquitectura y Soluciones Continua 

La relación entre la arquitectura y el Continuum Continuum Solutions es una de

orientación, dirección y apoyo. Por ejemplo, la Fundación Arquitecturas guían la
creación o selección de la Fundación Solutions. Soluciones Fundación de Apoyo a la
Architecture Foundation, ayudando a comprender la arquitectura definida en la
Arquitectura Continuum. La Architecture Foundation también guía el desarrollo de la
Fundación Solutions, proporcionando arquitectónicos de dirección, los requisitos y
los principios que guían la selección y realización de soluciones apropiadas. Una
relación similar existe entre los otros elementos de la empresa Continuum.
  Página 482 de 670 

TOGOF 9.1    

The Enterprise Continuum presenta mecanismos para ayudar a mejorar la productividad

a través del apalancamiento. La Arquitectura Continuum ofrece una manera
consistente para entender las diferentes arquitecturas y sus componentes. El
Continuum Soluciones ofrece una manera consistente para entender los diferentes
productos, sistemas, servicios y soluciones que se requieren. The Enterprise
Continuum no se debe interpretar como la representación de las relaciones
estrictamente encadenados. Arquitecturas específicos de la organización pueden
tener componentes de una arquitectura común de sistemas y soluciones de
Organizaciónespecíficas podrían contener soluciones Fundación. Las relaciones que
se muestran en la figura 39-1 son una ilustración que muestra las oportunidades
para el aprovechamiento de los componentes de la arquitectura y de la solución.
39.6.2 Su Empresa

TOGAF proporciona un método para que usted pueda "arquitecto" de los sistemas de su
empresa. Su organización arquitectura tendrá que hacer frente a cada tipo de
arquitectura se ha descrito anteriormente. Por ejemplo, se recomienda que usted
tiene su propio Architecture Foundation que rige todos sus sistemas. Usted también
debe tener sus propias arquitecturas de sistemas comunes que rigen los principales
sistemas compartidos - como el sistema de red o sistema de gestión. Usted puede
tener sus propias arquitecturas específicas de la industria que rigen la forma en
que sus sistemas deben comportarse dentro de su industria. Por último, cualquier
departamento u organización dentro de su negocio puede necesitar su propia
Arquitectura-Organización Específica individuo para gobernar los sistemas dentro de
ese departamento. Su organización arquitectura o bien adoptar o adaptar las
arquitecturas existentes, o desarrollará sus propias arquitecturas desde cero. En
cualquier caso, TOGAF es una herramienta para ayudar. Proporciona un método para
ayudarle a generar / mantener cualquier tipo de arquitectura dentro de la
Arquitectura Continuum tiempo de aprovechar los activos de arquitectura ya
definidos, interno o externo a la organización. El TOGAF ADM que a los activos de
arquitectura reutilizar ayuda, por lo que su organización arquitectura más
eficiente y eficaz.

  Página 483 de 670 

TOGOF 9.1      

40. Arquitectura de particionamiento

40.1 Información general
Las particiones se utilizan para simplificar el desarrollo y la gestión de la
arquitectura empresarial. Las particiones se encuentran en la base de la
arquitectura de la gobernanza y son distintos de los niveles y los conceptos
organizadores del Continuum Arquitectura (ver 39. Empresa Continuum ).
Arquitecturas están divididas debido a que:
Arquitecturas de unidad organizativa en conflicto entre sí.  Los diferentes equipos
tienen que trabajar en los diferentes elementos de la arquitectura al mismo tiempo
y particiones permiten a grupos específicos de los arquitectos poseen y desarrollan
los elementos específicos de la arquitectura.  Arquitectura reutilización efectiva
requiere segmentos modulares de arquitectura que pueden adoptarse e incorporarse en
las arquitecturas y soluciones más amplias. 

No es práctico para presentar un modelo de partición definitiva de la arquitectura.

Cada empresa tiene que adoptar un modelo de partición que refleja su propio modelo
de funcionamiento. Este capítulo trata de los criterios de clasificación que se
aplican en general a las arquitecturas y cómo estos se pueden aprovechar para
dividir la empresa en un conjunto de arquitecturas con complejidad manejable y una
gobernanza eficaz.

40.2 Clasificación Aplicar para crear arquitecturas con particiones

Por las razones expuestas en la sección anterior, es valioso para dividir y
organizar la empresa Continuum en un conjunto de soluciones y arquitecturas
relacionadas con:
Complejidad manejable para cada arquitectura o solución individual  Agrupaciones
definidas  Jerarquías definidas y estructuras de navegación  Procesos adecuados,
roles y responsabilidades adjuntas a cada agrupación 

  Página 484 de 670 

TOGOF 9.1    

La siguiente tabla muestra cómo los criterios de clasificación adecuados pueden ser
utilizados para apoyar el particionamiento de soluciones:
  

Característica Uso de Apoyo a la Solución de particionamiento Asunto (Manga) Las

soluciones se organizan naturalmente en grupos para apoyar la gestión operativa y
control. Ejemplos de particiones de soluciones de acuerdo a la materia incluirían
aplicaciones, departamentos, divisiones, productos, servicios, centros de servicio,
sitios, etc Descomposición de soluciones por tema suele ser la técnica fundamental
para la estructuración de las dos soluciones y las arquitecturas que las
representan. Los ciclos de vida de la solución se suelen organizar en torno a una
línea de tiempo, lo que permite que el impacto del desarrollo de la solución,
implantación, operación y retiro para ser manejado contra otra actividad económica
que ocurre en períodos de tiempo similares. La madurez y la volatilidad de una
solución típicamente afectar la velocidad de ejecución necesaria para el ciclo de
vida de la solución. Además, la volatilidad y la madurez darán forma a las
prioridades de inversión. Soluciones existentes en entornos altamente volátiles
pueden ser más adecuados para, técnicas de desarrollo ágil rápidos. La siguiente
tabla muestra cómo cada criterio de clasificación se pueden utilizar para apoyar el
particionamiento de arquitecturas:
  

Tiempo

Vencimiento / Volatilidad

Característica Uso de fomentar una arquitectura de particionamiento Profundidad El

nivel de detalle dentro de una arquitectura tiene una fuerte correlación con los
grupos de interés que estén interesados en la arquitectura. Arquitecturas
Típicamente menos detallados serán de interés para las partes interesadas
ejecutivos. Como arquitecturas aumentan en detalle, su relevancia para la
implementación y el personal de operaciones también se incrementará.
  Página 485 de 670 

TOGOF 9.1    

En términos prácticos, la arquitectura disciplina se utiliza para soportar un

número de diferentes tipos de arquitectura que se utilizan para diferentes
objetivos. Los criterios de clasificación antes mencionados, pueden ser utilizados
en diferentes formas de apoyar el logro de cada objetivo. Las siguientes
características no se utilizan para dividir una Arquitectura del Paisaje:
Arquitecturas utilizadas para describir la arquitectura del paisaje en general, no
son abstractos.  Volatilidad Solución general evita las arquitecturas de ser
definido, que están lejos en el futuro. La volatilidad también reduce la precisión
de los edificios históricos en el tiempo, ya que los cambios en la organización y
se adapta a las nuevas circunstancias. 

El uso de los criterios anteriores, las arquitecturas se pueden agrupar en las

particiones.
40.2.1 Las actividades dentro de la Etapa Preliminar

El objetivo clave de la Etapa Preliminar es establecer la capacidad Arquitectura

para la empresa. En la práctica esta actividad requerirá el establecimiento de un
número de particiones de arquitectura, proporcionando límites definidos, gobierno y
propiedad. En términos generales, cada equipo que lleva a cabo la actividad de la
arquitectura dentro de la empresa será propietaria de una o más particiones de
arquitectura y ejecutará el ADM de definir, gobernar, y hacer realidad sus
arquitecturas. Si se espera que más de un equipo para trabajar en una sola
arquitectura, esto puede llegar a ser problemático, ya que las responsabilidades
precisas de cada equipo son difíciles de establecer. Por esta razón, es preferible
aplicar la partición a la arquitectura hasta cada arquitectura tiene un equipo
propietaria. Por último, vale la pena considerar la distinción entre las
capacidades permanentes de la empresa y los equipos temporales movilizados para
apoyar una iniciativa de cambio en particular. Aunque las competencias de los
equipos permanentes dentro de la empresa se puede definir con precisión, es más
difícil de prever y especificar las responsabilidades de (posiblemente
desconocidos) equipos de arquitectura de carácter temporal. En los casos de estos
equipos temporales, cada equipo debe venir bajo el gobierno de un equipo de
arquitectura en pie y debe haber un proceso dentro del ciclo de ADM de estos
equipos para establecer partición arquitectura apropiada. Pasos en la Etapa
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 : Los diversos equipos permanentes que va a crear la arquitectura deben ser
identificados. Para cada uno de estos equipos, los límites apropiados deben ser
establecidos, incluyendo: 

  Página 486 de 670 

TOGOF 9.1    
o Los órganos de gobierno que son aplicables al equipo  o de miembros del equipo  o
Equipo de las líneas de responsabilidad  Determinar las responsabilidades de cada
equipo de arquitectura de pie : Para cada equipo de arquitectura, las
responsabilidades deben ser identificados.Este paso se aplica la lógica de
repartición en la arquitectura de la empresa con el fin de identificar en primer
lugar, el alcance de cada equipo y en segundo lugar a la partición de la
arquitectura bajo el mandato de un solo equipo. Una vez completado, este paso
debería haber particionado todo el ámbito de la empresa y debería haber asignado la
responsabilidad para cada arquitectura particionada a un solo equipo. El
particionamiento debe crear una definición de cada arquitectura que incluya:  o
áreas temáticas están cubiertos  o Nivel de detalle que el equipo trabajará en  o
Los períodos de tiempo que deben cubrirse  o Grupos de Interés  Determinar las
relaciones entre arquitecturas : Una vez que se ha creado un conjunto de
arquitecturas con particiones, las relaciones entre las arquitecturas deben
desarrollarse. Este paso permite que las relaciones de gobernanza para formalizarse
y también muestra donde los artefactos de una arquitectura se espera que sean
reutilizados en otras arquitecturas. Áreas de consideración incluyen:  o ¿Dónde se
superponen diferentes arquitecturas / cola de milano / drill-down?  o ¿Cuáles son
los requisitos de cumplimiento entre las arquitecturas? 

Una vez que la fase preliminar se completa, los equipos a cargo de la arquitectura
debe entenderse. Cada equipo debe tener un alcance definido y las relaciones entre
los equipos y la arquitectura debe ser entendido. Asignación de equipos a alcance
arquitectura se muestra en la Figura 40-1 .

  Página 487 de 670 

TOGOF 9.1    

 
Figura 40‐1: Asignación de equipos a Arquitectura Alcance 

40.3 Integración
La creación de arquitecturas con particiones corre el riesgo de producir una
colección fragmentada y desarticulada de las arquitecturas que no pueden integrarse
para formar un panorama general (ver Parte II , 5.6 Arquitectura de Integración ).
Para las grandes empresas complejas arquitecturas federados - desarrollados de
forma independiente, mantenidos y administrados arquitecturas que se integran
posteriormente dentro de un marco de integración - son típicos. Arquitecturas
federados normalmente se utilizan en los gobiernos y los conglomerados, donde las
unidades organizativas separadas necesitan arquitecturas diferentes. Dicho marco
especifica los principios de interoperabilidad, la migración, y la conformidad.
Esto permite que las unidades de negocio específicas que tienen arquitecturas
desarrolladas y reguladas como proyectos de arquitectura independientes.
Información adicional y orientación sobre cómo especificar los requisitos de
interoperabilidad para las diferentes soluciones se pueden encontrar en la Parte
III , 29. Requisitos de interoperabilidad . Con el fin de mitigar este riesgo, las
normas para la integración de contenidos deben ser definidos y la gobernanza
arquitectura deben abordar la integración de contenidos como condición para el
cumplimiento de la arquitectura. Marcos de contenido, tales como el marco TOGAF
contenido (consulte la Parte IV: Marco de Arquitectura de contenido ) se puede
utilizar para especificar bloques de construcción estándar y artefactos que son
objeto de las normas de integración de contenidos. Por ejemplo, un catálogo
estándar de los procesos de negocio puede ser acordado por una empresa.
Arquitecturas posteriores a continuación pueden facilitar la integración mediante
  Página 488 de 670 

TOGOF 9.1    

el uso de la misma lista de procesos y referencias cruzadas a otros aspectos de la

arquitectura de los procesos estándar. La integración puede ser dirigido desde un
número de dimensiones:
Integración a través de los dominios de arquitectura proporciona una vista en corte
de dominio del estado de un segmento de la empresa para un punto en el tiempo. 
Integración a través del ámbito organizativo de la empresa proporciona una vista en
corte del segmento de la empresa.  El Architecture Vision proporciona un resumen
integral de la arquitectura Definiciones, que proporcionan un resumen integrado de
Transición Arquitecturas.  La Figura 40-2 muestra cómo el contenido arquitectónico
se puede agregar utilizando una variedad de técnicas.

 
Figura 40‐2: Arquitectura de Agregación de Contenidos 

  Página 489 de 670 

TOGOF 9.1      

41. Arquitectura Repositorio

41.1 Información general
El funcionamiento de una Arquitectura Capability madura dentro de una gran empresa
crea un enorme volumen de la producción arquitectónica. La gestión eficaz y el
apalancamiento de estos productos de trabajo de arquitectura requieren una
taxonomía formal para los diferentes tipos de activos de arquitectura junto a los
procesos y herramientas dedicadas para el almacenamiento de contenido
arquitectónico. Esta sección de TOGAF proporciona un marco estructural para un
repositorio de Arquitectura que permite a una empresa para distinguir entre
diferentes tipos de activos arquitectónicas que existen en diferentes niveles de
abstracción en la organización. Este repositorio de arquitectura es una parte de la
más amplia Enterprise Repository, que proporciona la capacidad de vincular
elementos arquitectónicos a los componentes del diseño detallado, distribución y
servicio de administración de repositorios. A un alto nivel, se espera que seis
clases de información arquitectónica que se celebrará dentro de un repositorio de
Arquitectura:
La Arquitectura Metamodel describe la aplicación organizativo adaptado de un marco
de arquitectura, incluyendo un método para el desarrollo de la arquitectura y un
metamodelo para el contenido de la arquitectura.  La Capacidad de Arquitectura
define los parámetros, estructuras y procesos que ayuden a la gobernabilidad de la
arquitectura de repositorio.  La arquitectura del paisaje presenta una
representación arquitectónica de los activos en uso, o previsto, por la empresa en
determinados puntos en el tiempo.  La Base de información de Normas captura las
normas que deben cumplir las nuevas arquitecturas, que pueden incluir normas de la
industria, los productos y servicios seleccionados de proveedores o servicios
compartidos ya desplegados dentro de la organización.  La Biblioteca de Referencia
proporciona directrices, plantillas, patrones y otras formas de material de
referencia que se puede aprovechar el fin de acelerar la creación de nuevas
arquitecturas para la empresa.  El Gobierno Log proporciona un registro de la
actividad de gobierno en toda la empresa. 

Las relaciones entre estas áreas del Repositorio de Arquitectura se muestran en la

Figura 411.

  Página 490 de 670 

TOGOF 9.1    

 
Figura 41‐1: Visión general de la arquitectura de repositorio 

Esta sección de TOGAF describe la estructura y el contenido de las áreas de

depósito que tienen la salida de los proyectos, es decir, la arquitectura del
paisaje, la Biblioteca, la Base de información de normas y el registro de la
gobernanza. Esta sección, además, los requisitos que deben considerarse al
seleccionar las herramientas para la gestión de un repositorio de Arquitectura.

41.2 Arquitectura del Paisaje

La Arquitectura del Paisaje tiene vistas arquitectónicas del estado de la empresa
en determinados puntos en el tiempo. Debido a la gran cantidad y las diversas
necesidades de los interesados a lo largo de toda la empresa, la arquitectura del
paisaje se divide en tres niveles de granularidad:
1. Arquitecturas Estratégicas (ver Parte I , 3,70 Arquitectura Estratégica )
muestran una vista
de resumen a largo plazo de toda la empresa. Arquitecturas estratégicos
proporcionan un

  Página 491 de 670 

TOGOF 9.1    
marco de organización de la actividad operativa y el cambio y permiten una
configuración de dirección a nivel ejecutivo. 

2. Arquitecturas del segmento (véase la Parte I , Arquitectura 3.62 Segmento )

proporcionar
modelos operativos más detallados para las áreas dentro de una
empresa.Arquitecturas del segmento se pueden utilizar a nivel de programa o de una
cartera de organizar y operativamente alinear actividad de cambio más detallada. 

3. Arquitecturas de capacidad (véase la Parte I , Arquitectura 3,27 Capability )

muestran de
una forma más detallada cómo la empresa puede soportar una unidad particular de la
capacidad. Arquitecturas de capacidad se utilizan para proporcionar una visión
general de la capacidad de corriente, capacidad de objetivo, y los incrementos de
capacidad y permitir paquete de obras y proyectos a ser agrupados dentro de las
carteras y los programas gestionados. 

41.3 Referencia de la Biblioteca

41.3.1 Información general

La Biblioteca proporciona un depósito para contener los materiales de referencia

que se deben utilizar para desarrollar arquitecturas. Materiales de referencia de
que se pueden obtener a partir de una variedad de fuentes, incluyendo:
Los organismos de normalización  De productos y servicios proveedores  Comunidades
o foros de la industria  Las plantillas estándar  Mejores prácticas empresariales 

La Biblioteca debe contener:

Arquitecturas de Referencia  Modelos de Referencia  Biblioteca Mirador  Plantillas 
Nota:  Los términos arquitectura de referencia y modelo de referencia no se
utilizan con cuidado en la mayoría de la literatura. Arquitectura de referencia y
modelo de referencia tienen la misma relación que la arquitectura y el modelo.
Cualquiera puede existir como un estado genérico o específico de la organización.
Típicamente,un genérico arquitectura de referencia proporciona el equipo de
arquitectura con un esbozo de su arquitectura de referencia específica de la
organización que se personaliza para una organización específica. Por ejemplo, un
genérico arquitectura de referencia puede identificar que existe

  Página 492 de 670 
TOGOF 9.1    
una necesidad de modelos de datos.Una organización que selecciona el SID del TMF
como un modelo de datos de referencia es la creación de una arquitectura de
referencia específicos de cada organización. 

Con el fin de separar las diferentes clases de materiales de referencia de

arquitectura, la Biblioteca puede utilizar el Continuum La arquitectura como un
método para la clasificación.

 
Figura 41‐2: Arquitectura Continuum 

La Arquitectura Continuum, como se muestra en la Figura 41-2 , se puede ver como un

esquema de clasificación Reference Library. Como tal, ilustra cómo las
arquitecturas de referencia se pueden organizar a través de una gama - desde la
Fundación Arquitecturas y Arquitecturas específicos de la industria, para una
Arquitectura Organización Específico. Las necesidades de la empresa y los
requerimientos del negocio se abordan en la disminución de la abstracción de
izquierda a derecha. El arquitecto tendrá típicamente encontrar más elementos
arquitectónicos reutilizables hacia la izquierda de la gama. Cuando no se
encuentran elementos, los requisitos para los elementos que faltan se pasan a la
izquierda de la gama para su incorporación. A través de este ejercicio, es
importante tener en cuenta los conceptos de niveles y particiones. En diferentes
niveles de granularidad puede existir materiales de referencia apropiados para el
nivel, y las particiones dentro de la arquitectura del paisaje se puede esperar
para utilizar el material de referencia diferente (ver 40. Arquitectura de
particionamiento y la Parte III , 20. Aplicando la ADM a través de la Arquitectura
del Paisaje ).

41.4 Normas de Información de Base

41.4.1 Información general

La Base de información de Normas proporciona un área de depósito para contener un

conjunto de especificaciones, a la que deben ajustarse las
arquitecturas.Establecimiento de
  Página 493 de 670 

TOGOF 9.1    

una base de información de Normas proporciona una base inequívoca para la

gobernanza de la arquitectura debido a que:
Las normas son de fácil acceso a los proyectos y, por tanto, las obligaciones del
proyecto pueden ser comprendidas y previstas para  Las normas se establecen en
forma clara e inequívoca, de modo que el cumplimiento se puede evaluar
objetivamente 

41.4.2 Tipos de Norma

Normas normalmente se dividen en tres clases:

Obligaciones legales y reglamentarias : Estas normas son obligatorias por ley y,
por tanto, una empresa debe cumplir o enfrentar graves consecuencias.  Estándares
de la industria : Estas normas son establecidas por organismos de la industria,
tales como The Open Group, y luego son seleccionados por la empresa para su
aprobación. Estándares de la industria ofrecen un potencial para la interoperación
y compartir a través de las empresas, sino que también quedan fuera del control de
la empresa y, por tanto, se debe supervisar de manera activa.  Normas de
organización : Estas normas se establecen dentro de la organización y se basan en
la aspiración de la empresa (por ejemplo, la selección de las aplicaciones estándar
de apoyo a la cartera de consolidación). Normas de organización requieren procesos
para permitir exenciones y normas evolución. 

Normas 41.4.3 Ciclo de Vida

Normas generalmente no existen para todos los tiempos. . Las nuevas normas se
identifican y gestionan a través de un proceso de ciclo de vida general, las normas
pasan a través de las siguientes etapas:
Norma : Norma potencial ha sido identificado por la organización, pero que aún no
ha sido evaluada para su aprobación.  Norma Provisional (también conocido como un
estándar de prueba ): Un estándar provisional ha sido identificado como un posible
estándar para la organización, pero no se ha probado a un nivel en el que su valor
se entiende completamente. Los proyectos que deseen adoptar las Normas
provisionales podrán hacerlo, pero bajo condiciones experimentales específicas, por
lo que la viabilidad de la norma puede ser examinado con más detalle.  Estándar
(también conocido como un estándar activo ): Una Norma define una solución de la
corriente principal que se debe utilizar generalmente como el enfoque de elección. 
Supresión gradual estándar (también conocido como un estándar de Deprecated ): Un
estándar Phasing-Out se acerca al fin de su ciclo de vida útil. Los proyectos que
se reutilizando componentes existentes en general, puede seguir haciendo uso de la
supresión gradual de las Normas. Despliegue de nuevas instancias de la Norma
Phasing-Out son generalmente desalentada. 

  Página 494 de 670 

TOGOF 9.1    
Estándar Retirado (también conocido como un estándar obsoleto ): Un estándar
Retirado ya no es aceptada como válida en el paisaje. En la mayoría de los casos,
se deben tomar medidas correctivas para eliminar la Norma Retirado del paisaje.
Cambio de la actividad en un estándar Jubilado sólo debe ser aceptado como parte de
un plan general de desmantelamiento. 

Todas las normas deben ser revisadas periódicamente para asegurar que se sientan en
el lado derecho del escenario del ciclo de vida de normas. Como parte de la gestión
del ciclo de vida de las normas, el impacto de cambiar el estado del ciclo de vida
debe ser dirigida a comprender el impacto paisajístico de un cambio de las normas y
el plan de acción adecuado para abordarlo.
41.4.4 Normas de Clasificación dentro de la Base de
Información de Normas

Normas dentro de la Base de información de normas se clasifican de acuerdo a los

bloques de construcción dentro del contenido metamodelo TOGAF. Cada entidad
metamodelo puede potencialmente tener estándares asociados (por ejemplo, servicios
de negocios, Componente Tecnología). Las normas pueden relacionarse con bloques de
construcción (por ejemplo, una lista de componentes de tecnología estándar)
"aprobado" o puede especificar el uso adecuado de un bloque de construcción (por
ejemplo, los escenarios donde la infraestructura de mensajería es el caso, las
normas de comunicación de aplicación se definen). En el nivel superior, las normas
se clasifican de acuerdo con los ámbitos de arquitectura TOGAF, incluyendo las
siguientes áreas:
Normas Comerciales :  o Norma compartió las funciones de negocio  o definiciones de
roles y actores estándar  o normas de gobierno para la actividad empresarial y de
Seguridad  Estándares de Datos :  o la codificación y valores de datos estándar  o
estructuras y formatos de datos estándar  o Normas de origen y la propiedad de los
datos  o restricciones a la reproducción y el acceso  Aplicaciones Estándares :  o
aplicaciones estándar / compartidos que apoyan las funciones de negocio
específicas 
  Página 495 de 670 

TOGOF 9.1    
o Normas para la comunicación de solicitud y la interoperación  o Normas de acceso,
presentación y estilo  Estándares de Tecnología ;  o Los productos de hardware
estándar  o Los productos de software estándar  o Normas para el desarrollo de
software 

41.5 Gobierno Entrar

41.5.1 Información general

El Gobierno de registro proporciona un área repositorio para almacenar la

información compartida en relación con la gobernanza en curso de los proyectos. El
mantenimiento de un repositorio compartido de información de gobierno es
importante, debido a que:
Las decisiones tomadas durante los proyectos (por ejemplo, desviaciones estándares
o la justificación de un enfoque arquitectónico particular) son importantes para
retener y acceder en forma permanente. Por ejemplo, si un sistema se va a
sustituir, que tiene la vista de las decisiones arquitectónicas clave que dieron
forma a la implementación inicial es muy valiosa, ya que pondrá de relieve las
limitaciones que de otra manera puedan estar tapados.  Muchos actores están
interesados en los resultados de gestión del proyecto (por ejemplo, otros
proyectos, los clientes del proyecto, el Consejo de Arquitectura, etc.) 

41.5.2 Contenido de la sesión de Gobierno

El Registro de la gobernanza debe contener los siguientes elementos:

Decisión Log :. Un registro de todas las decisiones de gran importancia
arquitectónica que se han hecho en la organización Esto suele incluir:  o
selecciones de producto  o Justificación de las principales características
arquitectónicas de proyectos  o desviaciones de Normas  o Normas cambios de ciclo
de vida  o Solicitud de cambio de las evaluaciones y aprobaciones  o evaluaciones
de Re-uso  Evaluaciones de cumplimiento : En el puesto de control hitos clave en el
progreso de un proyecto, una revisión formal de la arquitectura se llevarán a cabo.
. Esta revisión se mida

  Página 496 de 670 

TOGOF 9.1    
la conformidad del proyecto con los estándares de arquitectura definidos para cada
proyecto, este registro debe incluir:  o Visión general del proyecto  o visión
Progreso (línea de tiempo, estado, problemas, riesgos, dependencias, etc)  o listas
de control completadas arquitectura  o Los estándares de evaluación del
cumplimiento  o Acciones recomendadas  Evaluaciones de capacidad : En función de
sus objetivos, algunos proyectos se llevará a cabo evaluaciones de los negocios, o
Arquitectura de capacidad. . Estas evaluaciones deben llevarse a cabo
periódicamente y realiza un seguimiento para asegurar que se está logrando progreso
adecuado Este registro debe incluir:  o Los modelos de referencia para la ejecución
de evaluaciones de capacidad Plantillas y  o evaluaciones de la capacidad de
Empresas  o evaluaciones de la capacidad de TI, de madurez y de impacto  o
evaluaciones de madurez Arquitectura  Calendario : El calendario debería mostrar un
calendario de proyectos en vuelo y las sesiones formales de revisión, que se
celebrará en contra de estos proyectos.  Cartera de Proyectos : La cartera de
proyectos debe contener información resumida acerca de todos los proyectos en vuelo
que se incluyen en la gobernanza de arquitectura, incluyendo:  o El nombre y la
descripción del proyecto  o ámbito arquitectónico del proyecto  o Los roles y las
responsabilidades asociadas con el proyecto arquitectónico  Medición del
desempeño : En base a un estatuto de la función de la arquitectura, por lo general
se define una serie de criterios de rendimiento. El registro de medición del
desempeño debe capturar las métricas relacionadas para que el rendimiento puede ser
medido y evaluado de forma continua a la gobernanza y cualquier otra medida de
rendimiento en relación con la carta de la arquitectura del proyecto. 

41.6 El Enterprise Repository

Mientras que el Repositorio de Arquitectura 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. Esto incluye los requisitos
requisitos de acopio de repositorio y el Depósito Soluciones de almacenamiento
Soluciones Building Blocks (SBB). Ver Figura 41-1 .
  Página 497 de 670 

TOGOF 9.1    

Los resultados de negocio para los requisitos se reflejarán en el Repositorio de

soluciones a través del tiempo. Cuando esto ocurre se cumplen y se archivan para
fines de auditoría con los requisitos.
41.6.1 Requisitos Repositorio

El Repositorio de Requisitos es utilizado por la fase de gestión de requisitos del

Método de Desarrollo de Arquitectura (ADM) para registrar y gestionar toda la
información pertinente a las necesidades de la arquitectura. Los requisitos frente
a los muchos tipos de requisitos de arquitectura; es decir, los requisitos,
estratégicos y de capacidad de segmento que son los motores principales de la
arquitectura de la empresa. Los requisitos pueden ser recogidos en todas las etapas
del ciclo de vida del desarrollo de la arquitectura y deben ser aprobados a través
de las diferentes fases y procesos de gobernanza.
41.6.2 Soluciones Repositorio

El Repositorio Soluciones mantiene los bloques de construcción de la solución

(SBB).

41.7 Repositorios externos

41.7.1 Modelos de referencia externos

Hay muchos modelos de referencia de la industria disponibles que pueden ayudar a

comprender el papel de los y el desarrollo de las arquitecturas de referencia. Los
ejemplos incluyen MDA de OMG, FEA de Gobierno de los EE.UU., TMF de la industria de
las telecomunicaciones, los modelos de referencia de SOA de OASIS y The Open Group.
Normas externos 41.7.2

Estos se refieren a la industria, mejores prácticas o estándares definidos formales

utilizados por organizaciones líderes. Los ejemplos incluyen ISO, IEEE, y las
normas gubernamentales.
Aprobaciones 41.7.3 Arquitectura de la Junta

Las decisiones tomadas por el Consejo de Arquitectura que afectan a la arquitectura

de la empresa a menudo se registran en las actas de las reuniones. Estas actas se
celebran a menudo en los archivos de documentación que están excluidos de la
Arquitectura Repositorio por motivos legales o reglamentarios.

  Página 498 de 670 

TOGOF 9.1    
  

42. Herramientas para el Desarrollo de la Arquitectura

42.1 Información general
Como un marco de arquitectura empresarial, TOGAF proporciona una base para el
desarrollo de arquitecturas de una manera uniforme y consistente. Su objetivo en
este sentido es asegurar que las diversas descripciones de arquitectura
desarrollados dentro de una empresa, tal vez por diferentes arquitectos o equipos
de arquitectura, soportan la comparación y la integración de arquitecturas de
dentro y fuera de los dominios de la arquitectura (de negocios, datos,
aplicaciones, tecnología), y en relación a diferentes ámbitos de la zona de
negocios dentro de la empresa. Para apoyar este objetivo, TOGAF define numerosos
productos en forma de arquitecturas, representados como modelos de arquitectura,
vistas de la arquitectura de los modelos, y otros artefactos. Con el tiempo, estos
artefactos se convierten en un recurso que debe ser gestionado y controlado, en
particular con vistas a su reutilización. Este concepto se refiere el TOGAF como la
"Empresa Continuum". Modelos de arquitectura y las vistas son discutidos en detalle
por separado en la Parte IV , 35. Architectural Artifacts . Esta sección trata
sobre las consideraciones en la elección de las herramientas automatizadas para
generar este tipo de modelos de arquitectura y vistas, y para su mantenimiento en
el tiempo.

42.2 Problemas de la Herramienta de Normalización

En el estado actual del mercado de herramientas, muchas empresas de desarrollo de
arquitecturas empresariales luchan con el tema de la estandarización de
herramientas, ya sea que busquen un solo "una talla para todos" herramienta o un
conjunto multiherramienta para el modelado de arquitecturas y la generación de los
diferentes puntos de vista de arquitectura requerida. Hay ventajas aparentes
asociadas con la selección de una sola herramienta. Organizaciones siguientes tal
política puede aspirar a obtener beneficios tales como reducción de la formación,
las licencias compartidas, descuentos por cantidad, el mantenimiento y el
intercambio de datos más fácil. Sin embargo, también hay razones para negarse a
identificar a una sola herramienta mandato, incluyendo razones de principio (que
respaldan una única herramienta de la arquitectura no alentaría la innovación
comercial competitiva o el desarrollo de la capacidad de la herramienta avanzada);
y el hecho de que una sola herramienta no tendría en cuenta una variedad de
desarrollo de la arquitectura "niveles de madurez" y necesidades específicas a
través de una empresa.
  Página 499 de 670 

TOGOF 9.1    

Equipos de arquitectura empresarial de éxito son a menudo los que armonicen sus
herramientas de arquitectura con su nivel de arquitectura madurez, equipo /
capacidades organizacionales y los objetivos o el enfoque. Si diferentes
organizaciones dentro de una empresa se encuentran en diferentes niveles de madurez
de la arquitectura y tener diferentes objetivos o enfoque (por ejemplo, la empresa
frente a la Empresa frente Architecture Technology), se hace muy difícil para una
herramienta para satisfacer las necesidades de todas las organizaciones.

  Página 500 de 670 

TOGOF 9.1    

     

PARTE VI Modelos TOGAF Referencia

 

  Página 501 de 670 

TOGOF 9.1    

  

. 43 Architecture Foundation: Referencia técnica Modelo

En este capítulo se describe el modelo de referencia técnica (TRM), incluida la
taxonomía básica, la representación gráfica y la detallada taxonomía plataforma. La
taxonomía detallada plataforma se describe en 43.5 Taxonomía Plataforma detallada .

43.1 Conceptos
En esta sección se describe el papel de la TRM, los componentes de la TRM, y el uso
de otros TRM.
43.1.1 Función de la TRM en la Architecture Foundation

La Fundación Arquitectura TOGAF es una arquitectura de servicios genéricos y las

funciones que proporciona una base sobre la que las arquitecturas más específicos y
componentes arquitectónicos se pueden construir. Esta Architecture Foundation se
encarna en el modelo de referencia técnica (TRM), que proporciona un modelo y
taxonomía de los servicios de la plataforma genéricos. El TRM es universalmente
aplicable y, por lo tanto, se puede utilizar para construir cualquier arquitectura
de sistema.
43.1.2 TRM Componentes

Cualquier TRM tiene dos componentes principales:

1. Una taxonomía , que define la terminología, y proporciona una descripción
coherente de los componentes y la estructura conceptual de un sistema de
información  2. Un asociado gráfico TRM , que proporciona una representación visual
de la taxonomía, como una ayuda para la comprensión 

El objetivo de la TOGAF TRM es proporcionar un ampliamente aceptado taxonomía

núcleo, y una representación visual apropiada de que la taxonomía. El gráfico TRM
se ilustra en 43,3 TRM en detalle , y la taxonomía se explica en un 43,4
Application Platform Taxonomía .
43.1.3 Otros TRM

Una de las grandes dificultades en el desarrollo de un marco de arquitectura es en

la elección de una TRM que funcione para todos.
  Página 502 de 670 

TOGOF 9.1    

El TOGAF TRM fue derivado originalmente de la Arquitectura del marco de Técnico de

Gestión de la Información (TAFIM) TRM (que a su vez se deriva del modelo de IEEE
1003.0). Esta TRM es "plataforma-centric": se centra en los servicios y la
estructura de la plataforma subyacente necesario para apoyar el uso y la
reutilización de aplicaciones (es decir, la portabilidad de la aplicación). En
particular, se centra en las interfaces entre la plataforma y que las aplicaciones
soportadas, y entre la plataforma y el medio ambiente externo. La corriente TOGAF
TRM es una versión modificada de la TAFIM TRM, que tiene como objetivo hacer
hincapié en el aspecto de la interoperabilidad, así como el de la portabilidad. El
objetivo de la TRM es permitir definición estructurado de la plataforma de
aplicaciones estandarizada y sus interfaces asociadas. El resto de entidades, que
son necesarios en cualquier arquitectura específica, sólo se abordan en la TRM en
la medida en que influyen en la plataforma de aplicaciones. El objetivo que subyace
en este enfoque es asegurar que los bloques de construcción de alto nivel que
constituyen soluciones de negocio tienen una completa plataforma sólida sobre la
que ejecutar. Otros modelos arquitectónicos - taxonomías y / o gráficos - no sólo
son posibles, pero puede ser preferible para algunas empresas. Por ejemplo, un
modelo de este tipo específico de la empresa podría ser derivado por extensión o
adaptación del TOGAF TRM. Alternativamente, una taxonomía diferente puede ser
realizada en el legado de la obra arquitectónica anterior por una empresa, y la
empresa puede preferir a perpetuar el uso de esta taxonomía. Del mismo modo, una
empresa puede preferir para representar la taxonomía TOGAF (o su propia taxonomía)
utilizando una forma diferente de gráfico, que capta mejor los conceptos heredados
y resulta más fácil para los propósitos de comunicación interna. Además de su uso
como un modelo de referencia para el desarrollo de la arquitectura de la
tecnología, la TRM se puede utilizar como una taxonomía para desarrollar una Base
de Información de Normas (SIB) dentro de una organización específica. El núcleo de
TOGAF es su ADM: el TRM es una herramienta utilizada en la aplicación de la ADM en
el desarrollo de arquitecturas específicas. Coherencia prevista entre TRM y SIB se
mantienen, el TOGAF ADM es válida cualquiera que sea la elección de la taxonomía
específica, TRM gráfico, o SIB conjunto de herramientas.

43.2 Desglose de Alto Nivel

En esta sección se describen los principales elementos de la TRM.
43.2.1 Información general

El detalle más gruesa de la TRM se muestra en la Figura 43-1 , que muestra tres
entidades principales (software de aplicación, la plataforma de aplicaciones y la
infraestructura de
  Página 503 de 670 

TOGOF 9.1    

comunicaciones) conectados por dos interfaces (Plataforma de Aplicaciones de

Interfaz y Comunicaciones Interfaz de Infraestructura).

    
Figura 43‐1: Referencia técnica Modelo ‐ de Alto Nivel de Vista 

El diagrama no dice nada acerca de las relaciones detalladas entre las entidades;
sólo que ellos existen. Cada uno de los elementos de este diagrama se discute en
detalle en el 43,3 TRM en detalle .
43.2.2 Portabilidad e Interoperabilidad

La TRM de alto nivel busca destacar dos importantes objetivos arquitectónicos

comunes:
1. Portabilidad de aplicaciones , a través de la plataforma de interfaz de
aplicación - la
identificación del conjunto de servicios que van a ser puestos a disposición en una
forma estándar de aplicaciones a través de la plataforma 

2. Interoperabilidad , a través de la interfaz de comunicaciones Infraestructura -

la
identificación del conjunto de servicios de infraestructura de comunicaciones que
han de ser aprovechados de una manera estándar por la plataforma 

  Página 504 de 670 
TOGOF 9.1    

Ambos objetivos son esenciales para permitir la integración dentro de la empresa y

la interoperabilidad de confianza a escala mundial entre las empresas. En
particular, el modelo de alto nivel busca reflejar el papel cada vez más importante
de Internet como base para la interoperabilidad inter e intra-empresa. La dimensión
horizontal de la modelo en la Figura 43-1 representa la diversidad, y la forma del
modelo se pretende hacer hincapié en la importancia de la diversidad mínima en la
interfaz entre la plataforma de aplicaciones y la infraestructura de
comunicaciones. Esto a su vez significa centrarse en el conjunto básico de
servicios que pueden ser garantizados con el apoyo de todas las redes basadas en
IP, como la base sobre la que construir entornos informáticos empresariales
interoperables de hoy.

43.3 TRM en detalle

En esta sección se describe la TRM en detalle, incluyendo las categorías de
servicios de plataforma y entorno externo sub-entidades.
43.3.1 Introducción
Figura 43-2 se expande en la Figura 43-1 para presentar las categorías de servicios
de la plataforma de aplicaciones y las dos categorías de software de aplicación.

  Página 505 de 670 

TOGOF 9.1    

 
Figura 43‐2: Modelo de referencia técnica detallada (Mostrando Categorías de servic
io)  Figura 43-2 es sólo una representación de las entidades de TRM: ni implica ni
inhibe las

interrelaciones entre ellos. Arquitecturas de TI derivados de TOGAF pueden variar

considerablemente en función de los requisitos del sistema de información. En la
práctica, muchas arquitecturas no incluirán todos los servicios aquí descritos, y
muchos van a incluir servicios adicionales para apoyar el software de aplicación
que es específico de la organización o de su industria vertical. En la construcción
de una arquitectura , los usuarios de TOGAF deben evaluar sus propias necesidades y
seleccionar los servicios, interfaces y estándares que satisfagan sus propias
necesidades de negocio.
43.3.2 Entidades TRM e Interfaces

Las secciones siguientes describen en detalle cada elemento de la TRM se ilustra en

la Figura 43-2 . Ambos se incluyen en el siguiente orden:
Las tres entidades: 

  Página 506 de 670 

TOGOF 9.1    
o software de aplicación (ver 43.3.3 Aplicación de Software )  o plataforma de
aplicaciones (ver 43.3.4 Application Platform )  o infraestructura de
comunicaciones (ver 43.3.5 Infraestructura de Comunicaciones )  Las dos
interfaces:  o Aplicación Interface Platform (ver
43.3.6 Aplicación Interface Platform )  o Interfaz de infraestructura de
comunicaciones (ver 43.3.7 Interfaz de Comunicaciones  Infraestructura ) 

43.3.3 Aplicación de Software

La TRM detallada reconoce dos categorías de Software de aplicación:
1. Aplicaciones empresariales , que implementan negocio procesos para una empresa
en
particular o sector vertical. La estructura interna de las aplicaciones de negocio
se relaciona estrechamente con la configuración de software de aplicación
específico seleccionado por una organización. 

2. Aplicaciones de Infraestructura , que proporcionan funcionalidad empresarial de

uso general, con base en los servicios de infraestructura. 

Durante el desarrollo de la arquitectura de la tecnología, aplicaciones de negocios

y aplicaciones de infraestructura son importantes fuentes de requisitos para los
servicios de arquitectura de la tecnología, y la selección de las normas para la
plataforma de aplicaciones se verán influenciados fuertemente por la configuración
del software de aplicación para ser admitido.
43.3.3.1 Aplicaciones empresariales

Las aplicaciones empresariales son las aplicaciones que son específicas de una
empresa en particular o industria vertical. . Dichas aplicaciones suelen modelar
elementos de dominio de una empresa de actividad o proceso de negocios Ejemplos de
las aplicaciones de negocio pueden incluir:
Servicios de gestión de archivo de historias clínicas utilizadas en la industria
médica  Servicios de gestión de inventario utilizados en la industria al por menor 
Servicios de modelado de datos geológicos utilizados en la industria del petróleo 

Con el tiempo, las aplicaciones de negocio en particular puede convertirse en

aplicaciones de infraestructura, si llegan a ser lo suficientemente ubicuos,
interoperables y de propósito general que es potencialmente útil para una amplia
gama de usuarios de TI de la empresa.
43.3.3.2 Aplicaciones Infraestructura

  Página 507 de 670 

TOGOF 9.1    

Aplicaciones de infraestructura son las aplicaciones que tienen todas, o casi

todas, de las siguientes características:
La amplia disponibilidad como Commercial Off-The-Shelf (COTS) de software significa
que es poco rentable para considerar la implementación personalizada.  La
interacción del usuario es una parte importante de la función de la aplicación. 
Las implementaciones se basan en los servicios de infraestructura.  Las
implementaciones pueden incluir extensiones significativas más allá de la necesaria
para utilizar los servicios de infraestructura subyacentes.  La interoperabilidad
es un requisito fuerte. 

Ejemplos de las aplicaciones en esta categoría incluyen:

Servicios de pago y transferencia electrónica de fondos  Servicios de cliente de
correo electrónico  Publicar y suscribirse  Los agentes inteligentes  Servicios de
calendario y programación  Servicios Groupware  Los servicios de flujo de trabajo 
Hojas de cálculo  El software de presentación  Edición de documentos y
presentación  Aplicaciones de gestión, sistema de uso general rendimiento y gestión
de redes funciones para el administrador del sistema  Herramientas de ingeniería de
software, proporcionando funciones de desarrollo de software para el personal de
desarrollo de sistemas 

Aplicaciones de infraestructura tienen fuertes dependencias de servicios de nivel

inferior en la arquitectura. Por ejemplo, una aplicación de flujo de trabajo puede
utilizar los servicios de la plataforma, como la mensajería o el procesamiento de
transacciones para implementar el flujo de trabajo entre tareas. Del mismo modo,
una aplicación de trabajo en grupo es probable que hacer un uso extensivo de los
datos y servicios de comunicación para la estructura de los documentos, así como la
mecánica de almacenar y acceder a ellos. Aplicaciones de infraestructura, por
definición, son aplicaciones que se consideran suficientemente ubicuos,
interoperables y de uso general dentro de la empresa puedan
  Página 508 de 670 

TOGOF 9.1    

considerarse de hecho como parte de la infraestructura de TI. Al igual que las

aplicaciones de negocio pueden con el tiempo llegan a ser consideradas como
aplicaciones de infraestructura, por lo que las aplicaciones de infraestructura
suelen ser candidatos para ser incluidos como servicios de infraestructura en las
futuras versiones de un TI arquitectura.
43.3.4 Plataforma de Aplicaciones
43.3.4.1 Plataforma Concept

El término "plataforma" se utiliza de muchas maneras diferentes en la industria de

TI hoy en día. Debido a los diferentes usos, el término a menudo calificado; por
ejemplo, "la plataforma de aplicaciones", "normalizado" y "plataformas
propietarias", "cliente" y "plataformas de servidor", "plataforma informática
distribuida", "plataforma de portabilidad". Común a todos estos usos es la idea de
que alguien necesita un conjunto de servicios prestados por un determinado tipo de
plataforma, y pondrá en marcha una función de "alto nivel" que hace uso de esos
servicios. El TOGAF TRM se centra en la plataforma de aplicaciones, y la "función
de nivel superior" es el conjunto de software de aplicación, que se ejecuta en la
parte superior de la plataforma de aplicaciones, que se necesita para hacer frente
a los requerimientos del negocio de la empresa. Es importante reconocer que la
plataforma de aplicaciones en el TOGAF TRM es un genérico, entidad, conceptual.
Desde el punto de vista de la TOGAF TRM, la Plataforma de Aplicaciones contiene
todos los servicios posibles. En una arquitectura específica de destino, la
plataforma de aplicaciones contendrá sólo aquellos servicios necesarios para apoyar
las funciones requeridas. Por otra parte, la plataforma de aplicaciones para una
arquitectura específica Target normalmente no ser una entidad única, sino más bien
una combinación de diferentes entidades para diferentes funciones más necesarias,
como cliente de escritorio, servidor de archivos, servidor de impresión, servidor
de aplicaciones, servidor de Internet, bases de datos servidor, etc, cada uno de
los cuales estará integrado por un conjunto específico, definido de servicios
necesarios para apoyar la función específica de que se trate. También es importante
reconocer que muchos de los sistemas de TI del mundo real que sean comprados y
utilizados en la actualidad para implementar una arquitectura de tecnología están
totalmente equipadas con numerosos servicios avanzados, que a menudo se dan por
sentados por el comprador. Por ejemplo, un sistema de ordenador de sobremesa típico
de hoy viene con el software que implementa los servicios de la mayoría, si no
todas las categorías de servicios de la TOGAF TRM. Dado que el comprador de un
sistema de este tipo a menudo no se considera nada "más pequeño" que el paquete
total de servicios que viene con el sistema, ese paquete de servicio puede llegar a
ser muy fácilmente la "plataforma". En efecto, en ausencia de una Arquitectura
Tecnológica para guiar el proceso
  Página 509 de 670 

TOGOF 9.1    

de adquisición, esto es, invariablemente, lo que sucede. Como este proceso se

repite en toda la empresa, los diferentes sistemas adquiridos para funciones
similares (como el cliente de escritorio, servidor de impresión, etc) pueden
contener marcadamente diferentes paquetes de servicios. Paquetes de servicios están
representados en una Arquitectura Tecnológica en forma de "bloques de
construcción". Una de las tareas clave del arquitecto de TI para pasar de la
plataforma de aplicaciones conceptual de la TRM para una Arquitectura Tecnológica
específica de la empresa es mirar más allá del conjunto de plataformas del mundo
real que ya existen en la empresa. El arquitecto de TI debe analizar los servicios
realmente necesarios a fin de implementar una infraestructura de TI que cumpla con
los requerimientos del negocio de la empresa en la forma óptima, y para definir el
conjunto de óptimas soluciones de Bloques de Construcción (SBB) - en el mundo real
"plataformas" para poner en práctica esa arquitectura.
43.3.4.2 La extensión de la TRM

El TOGAF TRM identifica un conjunto genérico de servicios de la plataforma, y

proporciona una taxonomía en la que estos servicios de la plataforma se dividen en
categorías de funcionalidad similar. Una organización en particular puede que tenga
que aumentar este conjunto con servicios adicionales o categorías de servicios que
se consideran ser genéricos en su propio segmento de mercado vertical. El conjunto
de servicios identificados y definidos para la plataforma de aplicaciones va a
cambiar con el tiempo. Se necesitarán nuevos servicios como aparece la nueva
tecnología y a medida que cambian las necesidades de aplicación.
43.3.4.3 Interfaces entre Servicios

Además de apoyar el software de aplicación a través de la plataforma de

aplicaciones de interfaz (API), los servicios de la plataforma de aplicaciones
pueden apoyarse unos a otros, ya sea mediante interfaces especificadas abiertamente
lo que puede o no ser la misma que la API, o por interfaces no expuestas privadas.
Un objetivo clave del desarrollo de la arquitectura es para módulos de servicios
sean capaces de sustitución por otros módulos que proporcionan la misma
funcionalidad del servicio a través de la misma API de servicio. El uso de las
interfaces privadas, sin impresionar entre módulos de servicio puede comprometer la
capacidad de sustituir. Interfaces privadas representan un riesgo que debe ser
resaltado para facilitar la futura transición.
43.3.4.4 Desarrollos futuros

La TRM se ocupa de la futura evolución de la plataforma de aplicaciones de dos

formas. En primer lugar, como las interfaces con los servicios que se estandaricen,
funcionalidad que formaba parte anteriormente de la entidad de software de
aplicación migra a formar parte
  Página 510 de 670 

TOGOF 9.1    

de la plataforma de aplicaciones. En segundo lugar, la TRM se puede ampliar con

nuevas categorías de servicios que aparece una nueva tecnología. Ejemplos de áreas
funcionales que pueden incluirse en las categorías de servicio de la plataforma de
aplicaciones en el futuro incluyen:
Funciones de hoja de cálculo, incluyendo la capacidad de crear, manipular y
presentar la información en tablas o gráficos; esta capacidad debe incluir la
capacidad de habla como de cuarta generación que permiten el uso de la lógica de
programación dentro de las hojas de cálculo  Funciones de apoyo a las decisiones,
incluidas las herramientas que apoyan la planificación, administración y gestión de
proyectos  Funciones de cálculo, incluyendo la capacidad de realizar cálculos
aritméticos rutinarias y complejas  Funciones de calendario, incluyendo la
capacidad para gestionar proyectos y horarios coordinados a través de un calendario
automatizado 

Una taxonomía detallada de la plataforma de aplicaciones se da en el 43,4

Application Platform - Taxonomía .
43.3.5 Comunicaciones Infraestructura

La infraestructura de comunicaciones proporciona los servicios básicos para la

interconexión de sistemas y proporcionar los mecanismos básicos para la
transferencia de datos opaco. Contiene los elementos de hardware y software que
forman los enlaces de comunicaciones en red y físicos utilizados por el sistema, y
por supuesto todos los otros sistemas conectados a la red. Tiene que ver con el
complejo mundo de las redes y la infraestructura de comunicaciones físico,
incluyendo interruptores, proveedores de servicios y los medios de transmisión
física. Un conductor primario en Arquitectura Tecnología de toda la empresa en los
últimos años ha sido la creciente conciencia de la utilidad y el costo-efectividad
de Internet como la base de una infraestructura de comunicaciones para la
integración de la empresa. Esto está causando un rápido aumento en el uso de
Internet y un aumento constante en la gama de aplicaciones que unen a la red para
el servicio descentralizado. Esto se considera aún más en 43.3.7 Interfaz de
Comunicaciones Infraestructura .
43.3.6 Aplicación Interface Platform

La plataforma de interfaz de aplicaciones (API) especifica una interfaz completa

entre el software de aplicación y la plataforma de aplicaciones subyacente a través
del cual se proporcionan los servicios. Una definición rigurosa de los resultados
de la interfaz en portabilidad de la aplicación, a condición de que tanto la
plataforma y la aplicación se
  Página 511 de 670 

TOGOF 9.1    

ajustan a la misma. Para que esto funcione, la definición de la API debe incluir la
sintaxis y la semántica de no sólo la interfaz de programación, sino también todo
el protocolo necesario y definiciones de estructuras de datos. Portabilidad depende
de la simetría de la conformidad de las aplicaciones y de la plataforma a la API
con arquitectura. Es decir, la plataforma debe ser compatible con la API de lo
especificado, y la aplicación debe utilizar no más de la API especificada. El API
especifica una interfaz completa entre una aplicación y uno o más servicios que
ofrece la plataforma de aplicaciones subyacente. Una aplicación puede utilizar
varios APIs, y puede incluso utilizar diferentes APIs para implementaciones
diferentes de un mismo servicio.
Interface 43.3.7 Comunicaciones Infraestructura

La interfaz de la infraestructura de comunicaciones es la interfaz entre la

plataforma de aplicaciones y la infraestructura de comunicaciones.
Figura 43-1 busca reflejar el papel cada vez más importante de Internet como base
para la interoperabilidad inter e intra-empresa. La dimensión horizontal de la
modelo en la Figura 431 representa la diversidad, y la forma de la modelo está
destinado específicamente para enfatizar la diversidad mínima en la interfaz entre
la plataforma de aplicaciones y la infraestructura de comunicaciones.

En particular, el modelo hace hincapié en la importancia de centrarse en el

conjunto básico de servicios que pueden ser garantizados con el apoyo de todas las
redes basadas en IP, como la base sobre la que construir entornos informáticos
empresariales interoperables de hoy.
43.3.8 Cualidades

Además del conjunto de componentes que forman el TRM, hay un conjunto de atributos
o cualidades que son aplicables a todos los componentes. Por ejemplo, para el
servicio de gestión para ser eficaz, capacidad de gestión debe ser una cualidad
omnipresente de todos los servicios de la plataforma, aplicaciones y servicios de
infraestructura de comunicaciones.
Figura 43-2 capta este concepto representa los componentes de TRM se sientan en un
plano

posterior de cualidades. Otro ejemplo de una calidad de servicio es la seguridad.

La aplicación adecuada de todo el sistema de seguridad requiere no sólo un conjunto
de servicios de seguridad, que corresponden a la categoría de los servicios de
seguridad se muestra en la plataforma, sino también el apoyo (es decir, la
"conciencia de seguridad") de software en otras partes de la
  Página 512 de 670 

TOGOF 9.1    

TRM. Por lo tanto, una aplicación podría utilizar un servicio de seguridad para
marcar un archivo como de sólo lectura, pero es la aplicación correcta de la
calidad de la seguridad en los servicios del sistema operativo que impide que las
operaciones de escritura en el archivo. Servicios de seguridad y del sistema
operativo deben cooperar para hacer el archivo seguro. Cualidades se especifican en
detalle durante el desarrollo de una arquitectura de destino. Algunas cualidades
son más fáciles que otros para describir en términos de estándares. Por ejemplo, el
apoyo de un conjunto de locales se puede definir como parte de la especificación de
la calidad a escala internacional. Otras cualidades mejor pueden especificarse en
términos de medidas en lugar de los estándares. Un ejemplo sería el rendimiento,
para el que las API o protocolos estándar son de uso limitado.

43.4 Plataforma de Aplicaciones - Taxonomía

En esta sección se describe la taxonomía plataforma de aplicaciones, incluidos los
principios fundamentales y un resumen de los servicios y calidades. Una taxonomía
detallada de servicios de la plataforma y cualidades se puede encontrar en 43,5
Taxonomía Plataforma detallada .
43.4.1 Principios básicos

El TOGAF TRM tiene dos componentes principales:

1. Una taxonomía , que define la terminología, y proporciona una descripción
coherente de los componentes y la estructura conceptual de un sistema de
información  2. Un asociado gráfico TRM , que proporciona una representación visual
de la taxonomía, como una ayuda para la comprensión 

En esta sección se describe en detalle la taxonomía del TOGAF TRM. El objetivo es

proporcionar una taxonomía central que proporciona una definición útil, coherente y
estructurado de la entidad Plataforma de aplicaciones y es ampliamente aceptable.
No se hacen afirmaciones que la clasificación elegida es la única posible, o que
representa la mejor opción. De hecho, es importante hacer hincapié en que el uso de
TOGAF, y, en particular, el TOGAF ADM, es de ninguna manera depende del uso de la
taxonomía TOGAF TRM. Otros taxonomías son perfectamente posibles, y pueden ser
preferibles para algunas organizaciones. Por ejemplo, una taxonomía diferente puede
ser realizada en el legado de la obra arquitectónica anterior por una organización,
y la organización puede preferir a perpetuar el uso de esta taxonomía.
Alternativamente, una organización puede decidir que se puede
  Página 513 de 670 

TOGOF 9.1    

derivar una taxonomía específica de la organización más adecuada mediante la

extensión o adaptación de la taxonomía TOGAF TRM. De la misma manera, una
organización puede preferir para representar la taxonomía TOGAF (o su propia
taxonomía) utilizando una forma diferente de gráfico TRM, que capta mejor los
conceptos heredados y resulta más fácil para los propósitos de comunicación
interna.
43.4.2 Aplicación de Servicios Plataforma Categorías

Las principales categorías de servicios definidos para la plataforma de

aplicaciones se enumeran a continuación. Tenga en cuenta que "los servicios de
objetos" no aparece como una categoría de la taxonomía TRM. Esto se debe a que
todos los servicios de objetos individuales se incorporan en las principales
categorías de servicios pertinentes. Sin embargo, las diversas descripciones
también se recogen en un único apartado (véase 43.4.2.1 orientada a objetos
Prestación de Servicios ) con el fin de proporcionar un único punto de referencia
que muestra cómo los servicios de objetos relacionados con las principales
categorías de servicios.
Servicios de Intercambio de Datos (ver 43.5.1 Servicios de datos de intercambio ): 
o Documentar los servicios de tipos de datos y conversión genéricos  o servicios de
intercambio de datos gráficos  o servicios de intercambio de datos especializadas 
o servicios de intercambio electrónico de datos  o Los servicios de fax  o
funciones de la interfaz gráfica Raw  o funciones de procesamiento de texto  o
funciones de procesamiento de documentos  o Las funciones de publicación  o
funciones de procesamiento de vídeo  o funciones de procesamiento de audio  o
funciones de procesamiento multimedia  o funciones de sincronización de medios  o
funciones de presentación y distribución de información 

  Página 514 de 670 

TOGOF 9.1    
o funciones de hipertexto  Servicios de gestión de datos (véase
43.5.2 Servicios de gestión de datos ):  o diccionario de datos / servicios de
repositorio  o Sistema de Gestión de Base de Datos de los servicios (DBMS)  o
servicios de Sistema de Gestión de Base de datos orientada a objetos (SGBDOO)  o
Los servicios de gestión de archivos  o funciones de procesamiento de consultas  o
funciones de generación de pantalla  o Informe funciones de generación de  o Redes
funciones de acceso / concurrentes  o las funciones de almacenamiento  Gráficos y
Servicios de imágenes (véase 43.5.3 Gráficos y servicios de imágenes ):  o Los
servicios de gestión gráfica de objetos  o servicios de Dibujo  o funciones de
imagen  Servicios Internacionales de la operación (ver
43.5.4 Internacionales Servicios de Operación ):  o Los conjuntos de caracteres y
servicios de representación de datos  o Los servicios de convenciones Cultural  o
Los servicios de apoyo en el idioma local  Ubicación y servicios de directorio
(véase 43.5.5 Ubicación y servicios de directorio ):  o Los servicios de
directorio  o Los servicios de nombres para usos especiales  o los servicios de
ubicación de servicio  o Los servicios de inscripción  o Los servicios de filtrado 
o Servicios de contabilidad  Servicios de red (véase 43.5.6 Servicios de red ):  o
Los servicios de comunicaciones de datos 

  Página 515 de 670 

TOGOF 9.1    
o los servicios de correo electrónico  o servicios de datos distribuidos  o
servicios de archivos distribuidos  o servicios de nombres distribuidos  o
servicios de tiempo Distribuido  o servicios de procesos a distancia (acceso)  o
Los servicios de cola de impresión remota y la distribución de salidas  o funciones
de telefonía mejoradas  o funciones de la pantalla compartida  o funciones de
conferencia de vídeo  o funciones de difusión  o funciones de la lista de correo 
Servicios del sistema operativo (véase 43.5.7 Servicios del sistema operativo ):  o
Los servicios de operaciones del kernel  o servicios de intérprete de comandos y de
servicios públicos  o Los servicios de procesamiento por lotes  o Los servicios de
archivos y sincronización de directorios  Servicios de Ingeniería de Software (ver
43.5.8 Software Engineering Services ):  o Los servicios de lenguaje de
programación  o Código objeto vincular los servicios  o servicios de ingeniería de
software asistida por ordenador (CASE) medio ambiente y herramientas  o servicios
de la interfaz gráfica de usuario (GUI) de construcción  o Los servicios de
lenguaje de secuencias de comandos  o servicios de Idioma vinculante  o Los
servicios de entorno de tiempo de ejecución  o servicios de interfaz de aplicación
binaria 

  Página 516 de 670 

TOGOF 9.1    
Servicios de procesamiento de transacción (ver
43.5.9 Servicios de Procesamiento de  Transacciones ):  o Los servicios de
administrador de transacciones  Servicios de la interfaz de usuario (ver
43.5.10 usuario Servicios Interface ):  o servicios Cliente gráfico / servidor  o
mostrar los objetos de servicios  o Los servicios de administración de Ventana  o
servicios de apoyo de diálogo  o Servicios de impresión  o servicios de formación y
de ayuda en línea basados en ordenador  o Los servicios basados en caracteres 
Servicios de seguridad (ver Servicios de Seguridad 43.5.11 ):  o servicios de
autenticación de Identificación y  o servicios de control de entrada del sistema  o
Los servicios de Auditoría  o Los servicios de control de acceso  o Los servicios
de no repudio  o Los servicios de gestión de seguridad  o servicios de recuperación
de confianza  o Los servicios de cifrado  o servicios de comunicaciones de
confianza  Sistema y Servicios de Gestión de Red (ver
43.5.12 Sistema y los Servicios de Gestión de  Red ):  o Los servicios de gestión
de usuario  o Configuración de la gestión de servicios (CM)  o Los servicios de
gestión de rendimiento  o Disponibilidad y gestión de fallos servicios  o Los
servicios de gestión de la contabilidad 

  Página 517 de 670 

TOGOF 9.1    
o Los servicios de gestión de seguridad  o Imprimir Servicios de gestión  o Los
servicios de gestión de red  o Copia de seguridad y los servicios de restauración 
o Los servicios de gestión de disco en línea  o Los servicios de gestión de
Licencia  o Los servicios de gestión de la capacidad  o Los servicios de
instalación de software  o Dificultad para venta de entradas de servicios  43.4.2.1
orientada a objetos Prestación de Servicios

Una descripción detallada de cada una de estas categorías de servicios se da en

43.5.13 orientada a objetos Prestación de Servicios .
Object Request Broker (ORB) Servicios:  o Los servicios de repositorio de
Implementación  o Servicios de instalación y activación  o servicios de repositorio
de interfaz  o Los servicios de replicación  Comunes Servicios de objeto:  o
cambiar los servicios de gestión  o Los servicios de Colecciones  o Los servicios
de control de concurrencia  o Los servicios de intercambio de datos  o servicios de
gestión de eventos  o Los servicios de Externalización  o Servicios de cesión  o
Los servicios de ciclo de vida  o servicios de nombres 

  Página 518 de 670 

TOGOF 9.1    
o Los servicios de objetos persistentes  o Propiedades de los servicios  o Los
servicios de consulta  o Los servicios de relaciones  o Servicios de seguridad  o
servicios de puesta en marcha  o Los servicios de Tiempo  o Los servicios de
comercio  o Servicios de transacción, 
43.4.3 Cualidades aplicación de servicio de la plataforma
43.4.3.1 Principios

Además de las categorías de servicios de plataforma delineados por categoría

funcional, calidades de servicio afectan Arquitecturas de Sistemas de Información.
A la calidad de servicio se describe un comportamiento, como la capacidad de
adaptación o de gestión. Calidades de servicio tienen un efecto penetrante en el
funcionamiento de la mayoría o la totalidad de las categorías de servicios
funcionales. En general la exigencia de un determinado nivel de calidad de servicio
en particular requiere una o más categorías de servicios funcionales a cooperar en
la consecución del objetivo. Por lo general, esto significa que los bloques de
construcción de software que implementan los servicios funcionales contienen
software que contribuye a la implementación de la calidad. Por la calidad que se
proporciona adecuadamente, todos los servicios funcionales pertinentes deben haber
sido diseñados para apoyarlo. Cualidades de servicios también tienen que sujetarse
en software en la entidad de software de aplicación y el ambiente externo, así como
la plataforma de aplicaciones. En algunos casos, una calidad de servicio afecta a
cada una de las categorías de servicios en una manera similar, mientras que en
otros casos, la calidad del servicio tiene una influencia única en una categoría de
servicio particular. Por ejemplo, la operación internacional depende de la mayor
parte de las categorías de servicios de la misma manera, tanto a los servicios ya
la necesidad de su cooperación para la localización de los mensajes, las fuentes y
otras características de un local, pero puede tener un efecto más profundo en la
servicios de ingeniería de software, que quizá requiera de instalaciones para la
producción de software internacionalizado.
  Página 519 de 670 

TOGOF 9.1    

Durante el proceso de desarrollo de la arquitectura, el arquitecto debe ser

consciente de la existencia de las cualidades y el grado de su influencia en la
elección de los bloques de construcción de software utilizado en la implementación
de la arquitectura. La mejor manera de asegurarse de que las cualidades no se
olvidan es crear una matriz de calidad, que describe las relaciones entre cada
servicio funcional y las cualidades que influyen en ella.
43.4.3.2 Taxonomía de calidades de servicio

Las calidades de servicio actualmente identificados en la taxonomía TRM son:

Disponibilidad (el grado en que algo está disponible para su uso), incluyendo:  o
Capacidad de administración , la capacidad de reunir información sobre el estado de
algo y para controlarlo  o de servicio , la capacidad de identificar los problemas
y tomar medidas correctivas, tales como reparar o actualizar un componente en un
sistema que ejecuta  o de rendimiento , la capacidad de un componente para ejercer
sus funciones en el momento oportuno  o fiabilidad , o la resistencia al fracaso  o
valorización , o la capacidad de restaurar un sistema a un estado de trabajo
después de una interrupción  O el estado de localización , la capacidad de un
sistema para encontrar cuando sea necesario  Aseguramiento , incluyendo:  o de
seguridad , o la protección de la información contra accesos no autorizados  o
integridad o la seguridad de que los datos no se ha dañado  o credibilidad , o el
nivel de confianza en la integridad del sistema y sus datos  Usabilidad , o la
facilidad de operación de los usuarios, incluyendo:  o la operación internacional ,
incluyendo habilidades multilingües y multiculturales  Adaptabilidad , incluyendo: 
o la interoperabilidad , ya sea dentro o fuera de la organización (por ejemplo, la
interoperabilidad de las funciones de calendario o programación puede ser clave
para la utilidad de un sistema)  O escalabilidad , la capacidad de un componente
para aumentar o reducir su rendimiento o capacidad adecuada a las exigencias del
entorno en el que opera  o Portabilidad , de datos, de personas, aplicaciones y
componentes 

  Página 520 de 670 

TOGOF 9.1    
o extensibilidad , o la capacidad de aceptar la nueva funcionalidad  o La capacidad
de ofrecer acceso a los servicios en los nuevos paradigmas, tales como la
orientación a objetos 

43.5 Taxonomía Plataforma detallada

En esta sección se ofrece una taxonomía detallada de los servicios de la plataforma
y cualidades.
43.5.1 Servicios de datos de intercambio

Servicios de intercambio de datos proporcionan apoyo especializado para el

intercambio de información entre las aplicaciones y el entorno externo. Estos
servicios están diseñados para manejar el intercambio de datos entre aplicaciones
en la misma plataforma y aplicaciones en diferentes plataformas (heterogéneas).
Existe un conjunto análogo de los servicios de intercambio de datos orientada a
objetos, que se puede encontrar en Servicios de Intercambio de Datos y Servicios de
Externalización de 43.5.13 orientada a objetos Prestación de Servicios .
Documento Generic Data Typing y Conversión servicios están respaldados por las
especificaciones para la codificación de los datos (por ejemplo, texto, imagen,
carácter numérico, especial) y tanto las estructuras lógicas y visuales de los
documentos electrónicos, incluidos los documentos compuestos.  Gráficos de datos de
intercambio de servicios se apoyan en las descripciones independientes del
dispositivo de elementos de imagen para gráficos basados en vectores y
descripciones de gráficos basados en raster.  Especializada Data Interchange
servicios están respaldados por las especificaciones que describen los datos
utilizados por mercados verticales específicos.Mercados cuando éstas existan
incluyen las industrias del petróleo Médico, Biblioteca, Dental, Assurance, y. 
Electronic Data Interchange servicios se utilizan para crear un entorno electrónico
(sin papel) para llevar a cabo el comercio y lograr ganancias significativas en la
calidad, capacidad de respuesta, y el ahorro que ofrece este entorno. Ejemplos de
las aplicaciones que utilizan servicios de comercio electrónico incluyen: búsqueda
y selección de proveedores; adjudicación del contrato; datos de los productos;
envío, reenvío y recepción; costumbres; información de pago; control de
inventarios; mantenimiento; los datos relacionados con los impuestos; y los datos
relacionados con los seguros.  Fax servicios se utilizan para crear, analizar,
transmitir y / o recibir imágenes de fax. 

Las siguientes áreas funcionales están soportados principalmente por el software de

aplicación, pero están avanzando hacia la migración a la plataforma de
aplicaciones:
Gráficos Raw Interfaz formatos de archivos de datos gráficos de apoyo a funciones
tales como TIFF, JPEG, GIF, y CGM. 

  Página 521 de 670 

TOGOF 9.1    
Tratamiento de Textos funciones, incluyendo la capacidad de crear, editar,
combinar, y dar formato al texto.  Procesamiento de Documentos funciones,
incluyendo la capacidad de crear, editar, combinar, y formatear documentos. Estas
funciones permiten a la composición de los documentos que incorporan gráficos,
imágenes, e incluso anotación de voz, junto con el texto estilizado. Se incluyen de
formato y edición avanzadas funciones como guías de estilo, corrección ortográfica,
el uso de múltiples columnas, tabla de la generación de contenido, encabezados y
pies de página, herramientas Esquema, y el apoyo para la digitalización de imágenes
en formatos de mapas de bits. Otras capacidades incluyen la compresión y
descompresión de imágenes o documentos enteros.  Publicación funciones, incluyendo
la incorporación de imágenes de calidad fotográfica y gráficos en color y
características de formato y estilo avanzadas, tales como el ajuste de texto
alrededor de objetos gráficos o fotos y kerning (es decir, cambiar el espaciado
entre caracteres de texto). Estas funciones también interactuar con sofisticados
equipos de impresión y producción. Otras capacidades incluyen la representación de
color y la compresión y descompresión de imágenes o documentos enteros.  Video
Processing funciones, incluyendo la capacidad de capturar, componer, editar,
comprimir y descomprimir la información de vídeo utilizando formatos como MPEG. Aún
así también se proporcionan gráficos y funciones de generación de título. 
Procesamiento de audio funciones, incluyendo la capacidad de capturar, componer,
editar, comprimir y descomprimir datos de audio.  Procesamiento Multimedia
funciones, incluyendo la capacidad de almacenar, recuperar, modificar, ordenar,
buscar e imprimir todos o cualquier combinación de los medios de comunicación
mencionados. Esto incluye el apoyo a los medios de comunicación microfilm,
tecnología de almacenamiento óptico que permite el almacenamiento de los documentos
escaneados o produce computadora que utilizan técnicas digitales de almacenamiento,
una función de barrido, y la compresión y descompresión de datos.  Sincronización
de medios funciones permiten la sincronización de los flujos de datos, tales como
audio y video para presentaciones.  Presentación de la Información y de
distribución funciones se utilizan para gestionar la distribución y presentación de
información de lotes y aplicaciones interactivas. Estas funciones se utilizan para
proteger las aplicaciones en áreas de negocio de cómo se utiliza la información.
Permiten a las aplicaciones en áreas de negocio para crear piscinas genéricas de
información sin la incorporación de controles que determinan el uso de esa
información. Funciones de distribución de la información y de presentación incluyen
la selección de las funciones de formato apropiadas requeridas para llevar a cabo
la distribución y presentación de la información a una variedad de aplicaciones en
áreas de negocio y los usuarios. Funciones de presentación y distribución de la
información también incluye la capacidad de almacenar, archivar, priorizar,
restringir, y volver a crear información.  Hipertexto funciones apoyan la
generación, distribución, localización, búsqueda y visualización de texto e
imágenes, ya sea local o global. Estas funciones incluyen la búsqueda y la
navegación, los enlaces de hipertexto, y la presentación de información
multimedia. 

  Página 522 de 670 

TOGOF 9.1     Servicios de gestión de datos 43.5.2

. Central a la mayoría de los sistemas es la gestión de datos que se puede definir

de forma independiente de los procesos que crean o utilizan, mantenerse
indefinidamente, y se comparte entre muchos procesos de los servicios de gestión de
datos incluyen:
Diccionario de Datos / Repositorio servicios permiten a los administradores de
datos y los ingenieros de la información para acceder y modificar los datos acerca
de los datos (es decir, metadatos). Estos datos pueden incluir formatos interna y
externa, la integridad y reglas de seguridad, y la ubicación dentro de un sistema
distribuido. Diccionario de datos y servicios de repositorio también permiten a los
usuarios finales y las aplicaciones para definir y obtener datos que está
disponible en la base de datos. La administración de datos define la normalización
y registro de los tipos de elementos de datos individuales para cumplir con los
requisitos para el intercambio de datos y la interoperabilidad entre los sistemas
de información en toda la empresa. Funciones de administración de datos incluyen
los procedimientos, pautas y métodos para la planificación efectiva de datos,
análisis, normas, modelos, gestión de configuración, almacenamiento, recuperación,
protección, la validación y la documentación. Los diccionarios de datos a veces son
atados a un único sistema de gestión de bases de datos (DBMS), pero los
diccionarios de datos heterogéneas apoyarán el acceso a diferentes DBMS.
Repositorios pueden contener una amplia variedad de información, incluyendo bases
de información de administración (MIB), o información relacionados con las causas.
Sistemas orientados a objetos pueden proporcionar repositorios de objetos e
interfaces, descritas en los servicios de repositorio de implementación y servicios
de repositorio de interfaz en 43.5.13 orientada a objetos 
Prestación de Servicios .  Sistema de Gestión de Base de Datos (DBMS) servicios
proporcionan acceso controlado a los datos estructurados. Para gestionar los datos,
el DBMS proporciona control de concurrencia y facilidades para combinar datos de
diferentes esquemas. Los diferentes tipos de DBMS soportan diferentes modelos de
datos, entre ellos, la red, los modelos orientados a objetos, y de archivos planos
relacionales, jerárquicas. Algunos DBMS están diseñados para funciones especiales
tales como el almacenamiento de objetos grandes o datos multimedia. Servicios de
DBMS son accesibles a través de una interfaz de lenguaje de programación, una
interfaz de lenguaje de manipulación de datos interactivos (como SQL), o un
interfaz de lenguaje interactivo / cuarta generación. Look-up y recuperación de
datos para los objetos se describen por separado en los servicios de consulta en
43.5.13 orientada a objetos Prestación de Servicios . Para una mayor eficiencia,
los DBMS a menudo ofrecen servicios específicos para crear, rellenar, mover, copia
de seguridad, restaurar, recuperar, y bases de datos de archivos, aunque algunos de
estos servicios podrían ser proporcionados por las capacidades de administración de
archivos generales descritos en 43.5.7 Servicios del sistema operativo o una
específica servicio de copia de seguridad. Algunos distribución apoyo DBMS de la
base de datos, incluyendo las instalaciones para la actualización de registros de
forma remota, replicación de datos, localizar y almacenar datos en caché, y la
administración remota.  Sistema de gestión de base de datos orientada a objetos de
servicios (SGBDOO) proporcionan almacenamiento para objetos e interfaces a esos
objetos.Estos servicios pueden apoyar el Repositorio de Ejecución, Interface
Repository, y los servicios de objetos persistentes en
43.5.13 orientada a objetos Prestación de Servicios .  Administración de archivos
proporcionan servicios de gestión de datos a través de métodos de acceso a archivos
incluidos secuencial indizado (ISAM) y hash de acceso

  Página 523 de 670 

TOGOF 9.1    
aleatorio. Servicios de archivos planos y directorios se describen en
43.5.7 servicios del  sistema operativo . 

Las siguientes áreas funcionales están soportados principalmente por el software de

aplicación, pero están avanzando hacia la migración a la plataforma de
aplicaciones:
Procesamiento de consultas funciones que proporcionan para la selección
interactiva, la extracción y el formato de la información almacenada en los
archivos y bases de datos. Funciones de procesamiento de consultas se invocan a
través de lenguajes orientados a los usuarios y herramientas (a menudo referida
como lenguajes de cuarta generación), que simplifican la definición de criterios y
la búsqueda de ayuda en la creación de presentación eficaz de la información
recuperada (incluyendo el uso de gráficos).  Generación Screen funciones que
proporcionan la capacidad de definir y generar pantallas que apoyan la
recuperación, presentación y actualización de datos.  Informe Generación funciones
que proporcionan la capacidad de definir y generar informes impresos compuestos por
los datos extraídos de una base de datos.  Redes / acceso simultáneo funciones que
gestionan el acceso de usuarios simultáneos al sistema de gestión de bases de datos
(DBMS) funciones.  Almacenaje funciones que proporcionan la capacidad de almacenar
grandes cantidades de datos - generalmente capturados de otros sistemas de bases de
datos - y para realizar el procesamiento analítico en línea sobre el mismo en apoyo
de ad hoc consultas. 

43.5.3 Gráficos y Servicios de Imágenes

. Servicios Gráficos proporcionan funciones necesarias para crear, almacenar,

recuperar y manipular imágenes Estos servicios incluyen:
Gestión de objetos gráficos de servicios, incluyendo la definición de los objetos
gráficos multidimensionales en una forma que es independiente de los dispositivos
de salida, y la gestión de las estructuras jerárquicas que contienen datos de los
gráficos. Formatos gráficos de datos incluyen dos y dibujos geométricos
tridimensionales, así como imágenes.  Dibujo servicios de apoyo a la creación y
manipulación de imágenes con software como GKS, PEX, PHIGS o OpenGL. 

Las siguientes áreas funcionales están soportados principalmente por el software de

aplicación, pero están avanzando hacia la migración a la plataforma de
aplicaciones:
Imaging funciones que prevén la exploración, creación, edición, compresión y
descompresión de imágenes de acuerdo con los estándares de formato de imagen
reconocidos; por ejemplo, PIKS / IPI, OpenXIL o XIE. 

43.5.4 Internacionales Servicios de Operación

Como práctica, los desarrolladores de sistemas de información tienen sistemas para

satisfacer las necesidades de un segmento de mercado geográfico o lingüístico
específico,
  Página 524 de 670 

TOGOF 9.1    

que puede ser una nación o de un mercado cultural particular diseñado y

desarrollado en general. Para hacer que el sistema de información viable, o
comercial, a un segmento diferente del mercado, por lo general se requiere un
proceso de reingeniería completa. Los usuarios u organizaciones que necesitan para
operar en un entorno multi-nacional o multicultural típicamente hicieron lo mismo
con varios sistemas de procesamiento de información en general, incompatibles.
Operación Internacional proporciona un conjunto de servicios e interfaces que
permiten a un usuario definir, seleccionar y cambiar entre diferentes entornos de
aplicaciones culturalmente relacionados con el apoyo de la aplicación particular.
En general, estos servicios deben proporcionarse de tal manera que las cuestiones
de internacionalización son transparentes a la lógica de la aplicación.
Conjuntos de caracteres y representación de datos servicios incluyen la capacidad
de introducir, almacenar, manipular, recuperar, comunicar y presentar datos de
forma independiente del esquema de codificación utilizado. Esto incluye la
capacidad de mantener y acceder a un repositorio central de juego de caracteres de
todos los conjuntos de caracteres codificados que se usan a lo largo de la
plataforma. Los conjuntos de caracteres se identifican de forma única para que el
usuario o la aplicación final puede seleccionar el conjunto de caracteres
codificados para ser utilizado. Esta representación independiente del sistema
soporta la transferencia (o compartir) de los valores y la sintaxis, pero no la
semántica, de registros de datos entre sistemas de comunicación. Las
especificaciones son independientes de los registros y campos representaciones
internas de los sistemas de comunicación. También se incluye la capacidad de
reconocer el conjunto de caracteres codificados de entidades de datos y,
posteriormente, a la entrada, comunicar y presentar esos datos.  Convenio Cultural
servicios proporcionan la capacidad de almacenar y acceder a las reglas y
convenciones para las entidades culturales que se mantienen en un repositorio
convención cultural llamado un "locale". Locales deben estar disponibles para todas
las aplicaciones. Locales suelen incluir la fecha y la moneda formatos, las
secuencias de clasificación y formatos de número. Formatos estandarizados de
localización y APIs permiten a las entidades de software que utilizan la
información de localización desarrollado por otros.  Asistencia de idiomas locales
los servicios proporcionan la capacidad de soportar más de un idioma al mismo
tiempo en un sistema. Mensajes, menús, formularios y documentación en línea se
pueden visualizar en el idioma seleccionado por el usuario. Las aportaciones de los
teclados que se han modificado a nivel local para apoyar a los conjuntos de
caracteres locales puede ser interpretada correctamente. 

El buen funcionamiento de los servicios de operación internacionales depende de

todas las entidades de software que participan tienen la capacidad de:
Utilice locales  Cambie entre locales según sea necesario  Mantener varias
configuraciones regionales activas 

  Página 525 de 670 

TOGOF 9.1    
Acceso a las fuentes adecuadas 

Esto requiere que las entidades de software que se escriben en un estilo particular
y en ser diseñado desde el principio con la internacionalización en mente.
43.5.5 Ubicación y Servicios de Directorio

Ubicación y directorio de servicios proporcionan apoyo especializado para la

localización de los recursos necesarios y la mediación entre los consumidores de
servicios y los proveedores de servicios. La World Wide Web, basada en Internet, ha
creado la necesidad de localizar los recursos de información, que actualmente está
satisfecho principalmente mediante el uso de motores de búsqueda. Los avances en la
Internet global, y en los sistemas distribuidos heterogéneos, demandan una
mediación activa a través de servicios de correduría que incluyen el registro
automático y dinámico, acceso al directorio, la comunicación de directorios,
filtración, y servicios de contabilidad para el acceso a los recursos.
Directorio de servicios proporcionan los servicios para que los clientes establecen
que los recursos son, y, por extensión, la forma en que se puede llegar. "Los
clientes" pueden ser los seres humanos o los programas de ordenador, y "recursos"
pueden ser una gran variedad de cosas, tales como nombres, direcciones de correo
electrónico, los certificados de seguridad, impresoras, páginas web, etc 
Nomenclatura de Propósitos Especiales servicios proporcionan servicios que hagan
referencia los nombres (cadenas ordenadas de caracteres imprimibles) a los objetos
dentro de un contexto determinado (namespaces). Los objetos son normalmente
organizados jerárquicamente dentro de los espacios de nombres. Ejemplos son:  o
Sistemas de archivos  o las bases de datos de seguridad  o colas de proceso 
Servicio de Localización de servicios proporcionan acceso a "Páginas Amarillas"
servicios en respuesta a las preguntas sobre la base de las limitaciones.  Registro
de servicios proporcionan servicios para registrar la identidad, la descripción de
los servicios de un recurso está proporcionando y descripciones de los medios para
acceder a ellos.  Filtrado de servicios proporcionan servicios para seleccionar
información útil de datos utilizando criterios definidos.  Contabilidad servicios
proporcionan servicios como cuenta abierta, actualización de cuenta, saldo de la
cuenta, cuenta detalle, cierre contable, descuentos, recuento proyecto cuenta /
uso, la cuenta del acuerdo de pago basado en el tráfico de mensajes, y / o el
tiempo de conexión y / o utilización de los recursos, y / o específicos de agente
(por ejemplo, basado en el valor). 

  Página 526 de 670 
TOGOF 9.1     Servicios de red 43.5.6

Los servicios de red se proporcionan para soportar aplicaciones distribuidas que

requieren acceso a datos y aplicaciones de la interoperabilidad en entornos de red
heterogéneos u homogéneos. Un servicio de red consiste tanto una interfaz y un
protocolo subyacente.
Comunicaciones de datos , que incluyen las interfaces y protocolos para la
transmisión de datos fiable, transparente de extremo a extremo a través de redes de
comunicaciones. Servicios de comunicaciones de datos incluyen tanto las funciones
de alto nivel (tales como transferencia de archivos, acceso remoto, ejecución de
procesos a distancia, o los servicios de integración de PC) y funciones de bajo
nivel (como un API de sockets) que da acceso directo a los protocolos de
comunicación.  El correo electrónico servicios incluyen la capacidad de enviar,
recibir, reenviar, almacenar, visualizar, recuperar, priorizar, autenticar y
gestionar los mensajes.Esto incluye la capacidad para anexar archivos y documentos
a los mensajes. Los mensajes pueden incluir cualquier combinación de datos, texto,
audio, gráficos e imágenes, y deben ser capaces de ser formateado en formatos de
intercambio de datos estándar. Este servicio incluye el uso de directorios y listas
de distribución de información de enrutamiento, la capacidad de asignar
prioridades, el uso de los formularios electrónicos con formato previo, y la
capacidad de seguir el estado de los mensajes. Servicios asociados incluyen una
lista resumida de los mensajes entrantes, un registro de los mensajes recibidos y
leer, la posibilidad de presentar o mensajes de impresión, y la capacidad de
responder o reenviar mensajes.  Datos Distribuidos servicios proporcionan acceso a,
y la modificación de los datos / metadatos en las bases de datos locales o remotos.
En un entorno distribuido, los datos no disponibles en la base de datos local es
descabellada desde un servidor de datos a distancia, a petición del cliente local. 
Distribuidos de archivos servicios proporcionan para el acceso remoto a archivos
transparente. Las aplicaciones tienen un acceso equivalente a los datos
independientemente de la ubicación física de los datos. Servicios auxiliares para
esta función pueden incluir direcciones, datos transparentes en caché, replicación
de datos, bloqueo de archivos y el registro de archivos.  Nombre Distribuidos
servicios proporcionan un medio para la identificación única de los recursos dentro
de un sistema de computación distribuida. Estos servicios están disponibles para
aplicaciones dentro de la red y proporciona información que puede incluir el nombre
de los recursos, atributos asociados, la ubicación física y la funcionalidad de los
recursos. Tenga en cuenta que todos los recursos del sistema deben ser
identificables, en todos los sistemas de información, por el nombre distribuida.
Esto permite que la ubicación física de cambiar, no sólo para acomodar el
movimiento, sino también equilibrio de carga, la utilización del sistema, la
ampliación (añadiendo procesadores y moviendo los recursos para acomodar el aumento
de recursos), procesamiento distribuido, y todos los aspectos de los sistemas
abiertos. Servicios de nombres distribuidas incluyen los servicios de directorio,
como los servicios X.500 y de navegación de la red. Servicios de nombres
distribuidas incluyen maneras de localizar objetos de datos tanto por nombre como
por su función. 43.5.13 orientada a objetos Prestación de Servicios describe los
servicios equivalentes al amparo de los servicios de nomenclatura y Servicios
comerciales, respectivamente. 

  Página 527 de 670 

TOGOF 9.1    
Tiempo Distribuidos proveen servicios de tiempo sincronizado coordinación tan
necesaria entre procesos distribuidos en diferentes zonas horarias. Un servicio
equivalente se describe en Servicios de Tiempo en
43.5.13 orientada a objetos Prestación de Servicios .  Proceso Remoto (acceso) los
servicios proporcionan los medios para aplicaciones dispersas para comunicarse a
través de una red informática. Estos servicios facilitan las comunicaciones de
programa a programa, independientemente de su naturaleza distribuida o una
operación en plataformas heterogéneas. Servicios de procesos a distancia,
incluyendo la llamada a procedimiento remoto (RPC) y los mecanismos de mensajería
asíncrona sustentan aplicaciones cliente / servidor.  Cola de impresión remota y
Distribución de salida servicios proporcionan los medios para la impresión de
producción de forma remota. Los servicios incluyen la gestión de la impresión
remota incluyendo impresora y selección de medios, el uso de las formas, la
seguridad y la gestión de colas de impresión. 

Las siguientes áreas funcionales están soportados principalmente por el software de

aplicación, pero están avanzando hacia la migración a la plataforma de
aplicaciones:
Telefonía mejoradas funciones, incluyendo el establecimiento de llamada, llaman la
coordinación, desvío de llamadas, llamada en espera, directorios programadas, las
teleconferencias, distribución automática de llamadas (útil para los ocupados
categorías de servicio al cliente), y la grabación de llamadas detalle.  Pantalla
compartida funciones que proporcionan las teleconferencias de audio con ventanas de
estaciones de trabajo comunes entre dos o más usuarios. Esto incluye la capacidad
para actualizar ventanas cada vez que alguien muestra nuevo material o cambia una
batería existente. Cada usuario dispone de la capacidad para anotar de forma
gráfica o modificar la ventana de conferencia compartida.  Video-conferencia
funciones que proporcionan la transmisión de video de dos vías entre los diferentes
sitios. Estas funciones incluyen establecimiento de llamada, llame a la
coordinación, la pantalla de movimiento completo de eventos y participantes de una
manera bidireccional, el apoyo a la gestión de la dirección de las cámaras, que van
desde la posición fija, al remitente dirigido, dirigido al receptor, al sonido
automatizado recogida.  Broadcast funciones que proporcionan un solo sentido
funciones de audio o las comunicaciones de audio / vídeo entre una ubicación y
envío de múltiples emplazamientos de recepción o entre múltiples enviar y recibir
ubicaciones.  Listas de Correo de funciones que permiten a los grupos a participar
en las conferencias. Estas conferencias pueden o no ocurrir en tiempo real. Los
conferenciantes o invitados pueden caer dentro o fuera de las conferencias o
subconferencias a voluntad. Se proporciona la capacidad de rastrear los
intercambios.Las funciones incluyen el intercambio de documentos, gestión de
conferencias, instalaciones de grabación, y la búsqueda y la capacidad de
recuperación. 

43.5.7 servicios del sistema operativo

Servicios del sistema operativo son los responsables de la gestión de los recursos
de la plataforma, incluyendo el procesador, la memoria, los archivos, y la entrada
y salida. . Por
  Página 528 de 670 

TOGOF 9.1    

lo general protegen las aplicaciones de los detalles de implementación de la

máquina de los servicios del sistema operativo se incluyen:
Operaciones del núcleo proporcionan servicios de bajo nivel necesarias para:  o
Creación y gestión de los procesos y subprocesos de ejecución  o Ejecutar
programas  o Definir y comunicar eventos asíncronos  o Definir y operaciones del
reloj del sistema proceso  o Implementar las funciones de seguridad  o Gestión de
archivos y directorios  o Entrada de control / procesamiento de salida hacia y
desde los dispositivos periféricos 

Algunos servicios del núcleo tienen análogos descritos en 43.5.13 orientada a

objetos Prestación de Servicios , como los servicios de control de concurrencia.
Intérprete de comandos y utilitarios servicios incluyen mecanismos de servicios a
nivel de operador, tales como:  o contenidos Comparando, impresión y archivos que
muestran  o Edición de archivos  o patrones de búsqueda  o expresiones Evaluación 
o Los mensajes de registro  o mover archivos entre directorios  o Ordenación de
datos  o Ejecución de scripts de comandos  o cola de impresión local  o Los
procesos de ejecución de señal de programación  o Acceso a la información del
entorno  El procesamiento por lotes los servicios de apoyo a la capacidad de la
cola de trabajo (puestos de trabajo) y gestionar la secuencia de procesamiento
basado en comandos de control de trabajo y listas de datos. Estos servicios también
incluyen el apoyo a la gestión de la salida de procesamiento por lotes, lo que con
frecuencia incluye archivos actualizados o bases de datos y productos de
información tales como informes impresos o

  Página 529 de 670 

TOGOF 9.1    
documentos electrónicos. El procesamiento por lotes se realiza de forma asíncrona
desde el usuario que solicita el trabajo.  De archivos y sincronización de
directorios servicios permiten copias locales y remotas de los archivos y
directorios que se hagan idénticos. Los servicios de sincronización normalmente se
utilizan para actualizar los archivos después de períodos de trabajo sin conexión
en un sistema portátil. 

43.5.8 Software Engineering Services

El aspecto funcional de una aplicación se materializa en los lenguajes de

programación utilizados para codificarlo. Además, los desarrolladores de sistemas
profesionales requieren herramientas adecuadas para el desarrollo y mantenimiento
de aplicaciones. Estas capacidades son proporcionados por los servicios de
ingeniería de software, las cuales incluyen:
Lenguaje de programación de servicios proporcionan la sintaxis básica y definición
semántica para su uso por un desarrollador de software para describir la función
del software de aplicación deseada. Shell y servicios lingüísticos ejecutivo de
guión permiten el uso de los comandos del sistema operativo o de los servicios
públicos en lugar de un lenguaje de programación. Shells y scripts ejecutivos
suelen ser interpretados en lugar de compilarse, pero los compiladores de apoyo
algunos sistemas operativos para los scripts de ejecutivos. Por el contrario,
algunos compiladores producen código para ser interpretado en tiempo de
ejecución.Otras herramientas de este grupo incluyen formateadores de código fuente
y los compiladores del compilador.  Código Object Linking servicios proporcionan la
capacidad de los programas para acceder a la aplicación y el sistema operativo de
la plataforma subyacente a través de las API que se han definido de forma
independiente del lenguaje de programación. Es utilizado por los programadores para
acceder a estos servicios utilizando métodos compatibles con el sistema operativo y
el idioma específico usado. La unión se dependiendo del sistema operativo, pero
independiente del lenguaje.  Computer-Aided Software Engineering (CASE) Medio
ambiente y Herramientas servicios incluyen sistemas y programas que ayudan en el
desarrollo automatizado y mantenimiento de software. Estos incluyen, pero no están
limitados a, herramientas para la especificación de requisitos y análisis, para el
trabajo de diseño y análisis, para crear, editar, probar, y el código de programa
de depuración, para documentar, para la creación de prototipos, y para la
comunicación de grupo. Las interfaces entre estas herramientas incluyen servicios
para almacenar y recuperar información acerca de los sistemas y el intercambio de
esta información entre los diversos componentes del sistema de entorno de
desarrollo. Un complemento de estas capacidades es la capacidad de gestionar y
controlar la configuración de los componentes de software, los datos de prueba, y
las bibliotecas para registrar los cambios en el código fuente o para acceder a los
repositorios CASE. Otras herramientas de idioma incluyen generadores de código y
traductores, herramientas de inteligencia artificial, y herramientas como el
comando del sistema UNIX make , que utiliza el conocimiento de las
interdependencias entre los módulos de recompilar y enlazar los sólo aquellas
partes de un programa que han cambiado.  Interfaz gráfica de usuario (GUI) de
construcción servicios de ayuda en el desarrollo de la Interfaz Hombre-Computadora
(HCI) elementos de las aplicaciones.Las herramientas

  Página 530 de 670 

TOGOF 9.1    
incluyen servicios para la generación y la captura de los diseños de pantalla, y
para definir la apariencia, la función, el comportamiento, y la posición de los
objetos gráficos.  Scripting Language servicios proporcionan los lenguajes
interpretados que permiten al usuario llevar a cabo alguna función complicada de un
modo simple. Las áreas de aplicación servidos por lenguajes de scripting de
propósito especial incluyen cálculo, desarrollo de la interfaz gráfica de usuario,
y el desarrollo de prototipos de aplicaciones.  Binding Language servicios
proporcionan asignaciones de las interfaces proporcionadas por los lenguajes de
programación en los servicios prestados por la plataforma de aplicaciones. En
muchos casos, el mapeo es sencillo ya que la plataforma suministra servicios
análogos a los esperados por la aplicación. En otros casos, el servicio de enlace
lenguaje debe utilizar una combinación de los servicios de la plataforma de
aplicaciones para proporcionar una cartografía totalmente funcional.  Medio
ambiente en tiempo de ejecución de servicios proporcionan soporte para el software
de aplicación en tiempo de ejecución. Este soporte incluye la localización y la
conexión de bibliotecas de enlace dinámico, o incluso de emulación de un entorno
operativo diferente a la que realmente existe.  Interfaz de aplicación binaria
servicios proporcionan servicios que hacen que la plataforma de aplicaciones de
cumplir con los estándares de interfaz binaria de aplicación definidos. 

Servicios de Procesamiento de Transacciones 43.5.9

Servicios de procesamiento de transacciones (TP) proporcionan soporte para el

procesamiento en línea de información en unidades discretas llamadas
"transacciones", con la garantía del estado de la información al final de la
transacción. Normalmente, esto implica secuencias predeterminadas de entrada de
datos, la validación, la pantalla y la actualización o la investigación en contra
de un archivo o base de datos. También incluye los servicios para priorizar y
rastrear transacciones.Servicios de TP pueden incluir el apoyo a la distribución de
las transacciones a una combinación de los procesadores locales y remotos. Una
transacción es una unidad completa de trabajo. Se puede comprender muchas tareas de
cálculo, que puede incluir interfaz de usuario, de recuperación de datos, y
comunicaciones. Una típica transacción modifica los recursos compartidos. Las
transacciones también deben ser capaces de ser revertido (es decir, sin hacer) si
es necesario, en cualquier etapa. Cuando una transacción se ha completado sin
fallos, se ha comprometido. Finalización de una transacción significa cualquiera de
compromiso o retrotracción. Normalmente, un servicio de TP contendrá un gestor de
transacciones, que une la entrada de datos y de software de visualización con el
procesamiento, la base de datos, y otros recursos para formar el servicio completo.

  Página 531 de 670 

TOGOF 9.1    

La suma de todo el trabajo realizado en cualquier parte del sistema en el

transcurso de una sola transacción se llama una "transacción global." Las
transacciones no se limitan a una sola plataforma de aplicaciones.
Gestor de transacciones . servicios, que permiten a una aplicación demarcar
transacciones, y dirigir su realización los servicios del gestor de transacciones
incluyen:  o Inicio de una transacción  o Coordinación de recursos recuperables que
intervienen en una transacción  o Confirmación o retrotracción de transacciones  o
Control de los tiempos de espera en las transacciones  o Encadenamiento de
transacciones, conjuntamente,  o situación de la operación de Monitoreo 

Algunos servicios de gestor de transacciones tienen equivalentes descritos en

43.5.13 orientada a objetos Prestación de Servicios , bajo Servicios de
transacción.
43.5.10 Servicios al Usuario de la interfaz

Servicios de interfaz de usuario definen cómo los usuarios pueden interactuar con
una aplicación. Dependiendo de las capacidades requeridas por los usuarios y las
aplicaciones, estas interfaces pueden incluir los siguientes:
Gráficos de cliente / servidor de servicios que definen las relaciones entre
cliente y servidor los procesos operativos de interfaz gráfica de usuario muestra,
por lo general dentro de una red. En este caso, el programa que controla cada
unidad de visualización es un proceso de servidor, mientras que los programas de
usuario independientes son procesos clientes que solicitan servicios de
visualización del servidor.  Display Objetos servicios que definen las
características de los elementos de visualización, tales como color, forma, tamaño,
movimiento, contexto gráfico, las preferencias del usuario, la gestión de la
fuente, y las interacciones entre los elementos de la pantalla.  Gestión Ventana
servicios que definan cómo deben ventanas creadas, mover, almacenar, recuperar,
eliminar, y relacionados entre sí.  Soporte de diálogo servicios se traducen los
datos introducidos para la exhibición a la que en realidad se muestra en la
pantalla (por ejemplo, los movimientos del cursor, la entrada de datos del teclado,
y los dispositivos de entrada de datos externos).  Impresión de salida de soporte
de servicios de texto y / o los datos gráficos, incluyendo cualquier filtración o
la conversión del formato necesario. Servicios de impresión pueden incluir la
capacidad de imprimir todo o parte de un documento, imprimir y compaginar más de
una copia, para seleccionar el tamaño y la orientación de la producción, para
elegir la

  Página 532 de 670 

TOGOF 9.1    
resolución de impresión, los colores, y el comportamiento gráfico, y para
especificar las fuentes y otros características.  Entrenamiento y Ayuda Online
Computer-Based servicios proporcionan un entorno de formación integrada en
estaciones de trabajo de usuario. La formación está disponible en una base como-
necesaria para cualquier aplicación disponible en el entorno. Los mensajes
electrónicos se proporcionan en el golpe de una tecla desde cualquier lugar dentro
de la aplicación. Esto incluye la formación tutorial sobre la aplicación en el uso
y la disponibilidad de conexión, capacitación interactiva en el sitio.  Carácter-
Basado servicios, que tienen que ver con el apoyo a los terminales no gráficas.
Servicios basados en caracteres incluyen soporte para terminal de control de tipo
independiente de atributos de visualización, movimientos del cursor, teclas
programables, señales acústicas, y otras funciones. 

Los servicios asociados a un sistema de ventanas incluyen la presentación visual de

la información en una pantalla que contiene una o más ventanas o paneles, el apoyo
a señalar a un objeto en la pantalla mediante un dispositivo señalador como un
ratón o pantalla táctil, y la manipulación de un conjunto de objetos en la pantalla
a través del dispositivo de señalización oa través de la entrada de teclado. Otras
interfaces de usuario que se incluyen son los controles industriales y dispositivos
de realidad virtual.
43.5.11 Servicios de Seguridad
Los servicios de seguridad son necesarias para proteger la información sensible en
el sistema de información. El nivel adecuado de protección se determina en base al
valor de la información a los usuarios finales de la zona de negocios y de la
percepción de las amenazas a la misma. Para ser eficaz, la seguridad debe hacerse
fuerte, nunca debe darse por sentado, y debe ser diseñado en una arquitectura y no
agregada después. Si un sistema es independiente o distribuido, la seguridad debe
ser aplicado a todo el sistema. No hay que olvidar que la exigencia de la seguridad
se extiende no sólo a través de la gama de entidades de un sistema, sino también a
través del tiempo. En el establecimiento de una fianza . arquitectura, el mejor
enfoque es considerar qué se está defendiendo, ¿qué valor tiene, y cuáles son las
amenazas a que son las principales amenazas que deben contrarrestarse son:
La pérdida de la confidencialidad de los datos  Falta de disponibilidad de datos o
servicios  La pérdida de integridad de los datos  El uso no autorizado de los
recursos 

Contadores a estas amenazas son proporcionados por los siguientes servicios:

  Página 533 de 670 

TOGOF 9.1    
Identificación y autenticación de los servicios ofrecen:  o Identificación,
rendición de cuentas y auditoría de los usuarios y sus acciones  o Los datos de
autenticación y de cuentas  o Protección de datos de autenticación  o información
del estado de usuario de Active  o Los mecanismos de autenticación Contraseña 
Control de Sistema de Entrada servicios ofrecen:  o advertencia a los usuarios no
autorizados de que el sistema es consciente de la seguridad  o Autenticación de
usuarios  o de la Información, aparece en la entrada, a unos exitosos y no exitosos
intentos de conexión anteriores  o bloqueo iniciado por el usuario de una sesión de
prevenir aún más el acceso hasta que el usuario se ha autenticado re-  Auditoría
servicios ofrecen un control autorizado y la protección de la pista de auditoría,
el registro de información de eventos relevantes para la seguridad detalladas, y
control de seguimiento de auditoría, la gestión y la inspección.  Control de acceso
proporcionan servicios:  o los atributos de control de acceso para los sujetos
(tales como procesos) y objetos (como archivos)  o La aplicación de normas para la
asignación y modificación de atributos de control de acceso  o Ejecución de los
controles de acceso  o de control de la creación y eliminación de objeto, incluso
asegurando que la reutilización de objetos no permite sujetos para obtener
accidentalmente el acceso a la información preexistente en el objeto 

Servicios de control de acceso también aparecen bajo los servicios de seguridad en

43.5.13 orientada a objetos Prestación de Servicios .
No repudio servicios proporcionan la prueba de que un usuario realiza una acción, o
enviar o recibir información, en un momento determinado. Servicios de no repudio
también aparecen bajo los servicios de seguridad en
43.5.13 orientada a objetos Prestación de  Servicios .  Gestión de Seguridad de
servicios proporcionan seguro sistema de configuración e inicialización, el control
de los parámetros de la política de seguridad, la gestión de los

  Página 534 de 670 

TOGOF 9.1    
datos de registro del usuario, y los recursos del sistema y las restricciones en el
uso de las funciones administrativas.  Recuperación de confianza los servicios
proporcionan instalaciones de recuperación como la restauración de las copias de
seguridad de forma que no comprometan la protección de seguridad.  Cifrado
servicios proporcionan formas de codificación de datos de tal manera que sólo puede
ser leído por alguien que posee una tecla apropiada, o alguna otra pieza de
información secreta. Además de proporcionar confidencialidad de los datos para la
comunicación de confianza, los servicios de cifrado se utilizan para sustentar
muchos otros servicios, como la identificación y autenticación, control de entrada
del sistema, y los servicios de control de acceso.  Comunicación Trusted servicios
ofrecen:  o Una forma segura para la comunicación partidos para autenticarse entre
sí, sin el riesgo de un espía, posteriormente, haciéndose pasar por una de las
partes  o Una forma segura de generar y verificar los valores de comprobación de
integridad de los datos  o cifrado y descifrado de la confidencialidad y otros
fines de Datos  o una manera de producir un hash irreversible de los datos para el
apoyo de las funciones de firma digital y el no repudio  o Generación, derivación,
distribución, almacenamiento, recuperación y eliminación de claves criptográficas 

Los servicios de seguridad requieren otras entidades de software para cooperar en:
Control de acceso para los recursos gestionados por la entidad  Contabilidad y
auditoría de los eventos relevantes para la seguridad  La importación y exportación
de datos  Potencialmente todos los otros servicios de seguridad, según el enfoque
de implementación particular 

Los servicios de seguridad son una categoría en la que una amplia vista es
particularmente importante, ya que una cadena es tan fuerte como su eslabón más
débil.Esta es una categoría de servicios cuando el ambiente externo tiene
implicaciones críticas en la plataforma de aplicaciones. Por ejemplo, la presencia
de un servidor de seguridad puede proporcionar un único punto de acceso a una red
del mundo exterior, por lo que es posible concentrar el control de acceso en un
lugar y relajar los requisitos de detrás del firewall.

  Página 535 de 670 

TOGOF 9.1     43.5.12 Sistema y los Servicios de Gestión de

Red

Los sistemas de información están compuestos por una gran variedad de diversos
recursos que se debe manejar de manera efectiva a la consecución de los objetivos
de un entorno de sistema abierto. Mientras que los recursos individuales (por
ejemplo, impresoras, software, usuarios, procesadores) pueden ser muy diferentes,
la abstracción de estos recursos como objetos administrados permite el tratamiento
de una manera uniforme. Los conceptos básicos de la gestión - incluyendo la
operación, administración y mantenimiento - pueden entonces aplicar a todo el
conjunto de componentes del sistema de información junto con sus servicios de
ayudante. Sistema y funcionalidad de gestión de red se pueden dividir en varias
maneras diferentes; Una forma es hacer una división de acuerdo a los elementos de
gestión que genéricamente se aplican a todos los recursos funcionales. Esta
división reduce como sigue:
Gestión de usuarios de servicios ofrecen la posibilidad de mantener las
preferencias y privilegios de un usuario.  Gestión de la Configuración (CM) los
servicios de dirección de cuatro funciones básicas:  o Identificación y
especificación de todos los recursos del componente  o de control, o la capacidad
de congelar los elementos de configuración, el cambio sólo a través de procesos
acordados  o la contabilidad de estado de cada elemento de configuración  o
Verificación a través de una serie de revisiones para asegurar la conformidad entre
el elemento de configuración actual y la información registrada sobre él 

Estos servicios incluyen: Procesador CM, CM Red, Sistema Distribuido de CM, CM

Topología y Aplicación CM. Procesador CM toma un enfoque de plataforma centrada.
Servicios de CM Red y Sistema Distribuido de CM permiten a los sistemas remotos a
ser gestionados y controlados incluyendo el intercambio de estado de la red.
Topología de CM se utiliza para controlar la topología de las entidades físicas o
lógicas que se distribuyen. CM aplicación se centra en las aplicaciones. Gestión de
la configuración aparece también como servicios de gestión del cambio en 43.5.13
orientada a objetos Prestación de Servicios .
Gestión del rendimiento de servicios monitorean aspectos de rendimiento de
hardware, la plataforma y el software de aplicación, y los componentes de red y
proporcionar maneras de ajustar el sistema para cumplir con los objetivos de
rendimiento.  Disponibilidad y gestión de fallos servicios permiten un sistema para
reaccionar ante la pérdida o el funcionamiento incorrecto de los componentes del
sistema, incluyendo hardware, software de plataforma y software de aplicación. 
Gestión Contable servicios proporcionan la capacidad de gastos de los servicios
para la carga y el reembolso. 

  Página 536 de 670 

TOGOF 9.1    
Gestión de Seguridad de los servicios de control de los servicios de seguridad de
acuerdo con las políticas de seguridad aplicables.  Administración de impresión
servicios ofrecen la posibilidad de gestionar los servicios de cola de impresión,
tanto locales como remotos.  Administración de red de servicios comprenden
elementos de todos los servicios descritos anteriormente, pero a menudo se tratan
como un servicio separado.  Copia de seguridad y restauración de servicios
proporcionan una instalación de almacenamiento multi-nivel para garantizar la
seguridad continua de datos en caso de fallo de un componente o subsistema.  Online
Administración de discos servicios gestionar la utilización del almacenamiento en
disco frente a los valores de umbral e invocan una acción correctiva. 
Administración de licencias de servicios de apoyo a la aplicación efectiva de los
acuerdos de licencia de software. Servicios de cesión de objetos se describen en la
sección de Licencias de servicios en
43.5.13 orientada a objetos Prestación de Servicios .  Gestión de Capacidad
servicios abordan tres funciones básicas:  o en curso de análisis de gestión de la
capacidad y el desempeño histórico y la capacidad  o gestión de carga de trabajo
para identificar y comprender las aplicaciones que utilizan el sistema  o
Planificación de la capacidad para planificar los recursos de hardware necesarios
para el futuro  Instalación de software de distribución de servicios de apoyo, la
instalación, retirada, traslado, la activación y actualización automática de
software o paquetes de datos desde medios transportables o a través de redes.
Servicios similares para los objetos se describen en los servicios de instalación y
activación en 43.5.13 orientada a objetos  Prestación de Servicios . 

Las siguientes áreas funcionales están soportados principalmente por el software de

aplicación, pero están avanzando hacia la migración a la plataforma de
aplicaciones:
Trouble Ticketing servicios de apoyo a la generación, procesamiento y seguimiento
de los informes de problemas. Problemas de venta de entradas es un término de
origen en el mundo de las telecomunicaciones, en referencia a la capacidad de pasar
informes de faltas tanto dentro como entre los proveedores de servicios de
telecomunicaciones. En este entorno, las fallas se encuentran a menudo por un
cliente de un proveedor, mientras que la causa del problema se encuentra en el
dominio administrativo de otro proveedor. Venta de entradas El problema es que un
servicio común que puede ser útil para una gama creciente de aplicaciones si el
trabajo se hace necesario hacer que descienda de las telecomunicaciones en las
zonas más amplias de aplicaciones distribuidas, tales como el correo electrónico. 

  Página 537 de 670 

TOGOF 9.1    

Esta ruptura de los servicios del sistema y gestión de la red es paralela a la

ruptura de las nuevas de gestión de red OSI, lo cual representa un marco global
coherente que se aplica por igual a las redes integrales y los nodos individuales
de las redes. Una consideración importante de las normas de apoyo a los servicios
de esta categoría es que no deben hacer cumplir las políticas de gestión
específicas, sino más bien permitir que una amplia variedad de diferentes políticas
de gestión a implementar, seleccionados de acuerdo con las necesidades particulares
de las instalaciones del usuario final. Servicios de gestión del sistema y de red
necesitan la cooperación de otras entidades de software en:
Proporcionar información sobre el estado  Eventos notificantes  En respuesta a las
instrucciones de manejo 

43.5.13 orientada a objetos Prestación de Servicios

En esta sección se muestra cómo se prestan los servicios de una manera orientada a
objetos. "Servicios de objeto" no aparece como una categoría en el modelo de
referencia técnica (TRM), ya que todos los servicios de objetos individuales se
incorporan en su caso, en las categorías de servicios dados. Un objeto es una
entidad identificable, encapsulado que proporciona uno o más servicios que pueden
ser solicitadas por un cliente. Los clientes solicitan un servicio invocando el
método apropiado asociado con el objeto, y el objeto lleva a cabo el servicio en
nombre del cliente. Los objetos proporcionan un paradigma de programación que puede
conducir a importantes beneficios, entre ellos:
El aumento de la modularidad  Una reducción en los errores  Facilidad de
depuración 

Servicios de gestión de objetos proporcionan formas de crear, localizar y nombrar a

los objetos, y que les permite comunicarse en un entorno distribuido. El conjunto
completo de servicios de objetos identificados hasta ahora se enumeran a
continuación en aras de la exhaustividad. . Cuando un servicio objeto en particular
es parte de una categoría de servicio de aplicación más general, se le da un
puntero a la otra categoría de servicio objeto servicios incluyen:
Object Request Broker (ORB) . servicios, que permiten a los objetos para hacer y
recibir las solicitudes y respuestas en un entorno distribuido de forma
transparente los servicios ORB incluyen: 

  Página 538 de 670 

TOGOF 9.1    
o Implementación del repositorio servicios apoyan la ubicación y la gestión de
implementaciones de objetos. Los servicios se asemejan a las que proporciona el
diccionario de datos / servicios de repositorio en
43.5.2 Servicios de administración de  datos .  o Instalación y activación de
servicios proporcionan formas de distribuir, instalar, activar y mover los objetos.
Esto corresponde a los Servicios de instalación de software en
43.5.12 Sistema y Servicios de gestión de red .  o Interface Repository servicios
apoyan el almacenamiento y gestión de la información acerca de las interfaces a los
objetos. Los servicios se asemejan a las que proporciona el diccionario de datos /
servicios de repositorio en 43.5.2 Servicios  de administración de datos .  o
replicación de replicación de servicios de soporte de objetos en sistemas
distribuidos, incluyendo la gestión de la coherencia entre las copias.  Objeto
común de servicios, que proporcionan funciones básicas para el uso y aplicación de
objetos. . Estos son los servicios necesarios para construir cualquier aplicación
distribuida por objeto servicios comunes incluyen:  o Gestión del Cambio servicios
proporcionan para identificación de la versión y la configuración de interfaces de
objetos, implementaciones y casos. Esto corresponde a los servicios de
administración de configuración que se describen en
43.5.12 Sistema y Servicios de gestión de red .  o Colecciones servicios
proporcionan operaciones sobre colecciones de objetos, como listas, árboles, pilas,
o colas. Los servicios incluyen el establecimiento, la adición de objetos, o
sacarlos de las colecciones, poniendo a prueba la pertenencia establecido, formando
uniones e intersecciones de conjuntos, y así sucesivamente.  o el control de
concurrencia servicios permiten a varios clientes para coordinar su acceso a los
recursos compartidos. Sincronización como éste se proporciona normalmente con los
servicios prestados en Kernel 43.5.7 servicios del sistema  operativo .  o Data
Interchange servicios apoyan el intercambio de información visible estado entre los
objetos. Dependiendo del tipo de objeto implicado, esto corresponde a una o más de
los servicios prestados en 43.5.1 Data Interchange Services .  o Gestión de eventos
servicios proporcionan capacidades básicas para la gestión de eventos, incluyendo
eventos asíncronos, evento "fan-in", la notificación de "fanout", y entrega de
eventos confiable.  o Externalización de servicios definen los protocolos y
convenciones para la externalización y la internalización de los objetos. Medios de
grabación el estado del objeto en una corriente de datos de externalización, y
medios de internalización recrear un estado del objeto a partir de un flujo de
datos. Este es un ejemplo de la Presentación de la Información y las funciones de
distribución en 43.5.1 Servicios de  datos de intercambio . 

  Página 539 de 670 

TOGOF 9.1    
o licencias de políticas de apoyo a los servicios para la concesión de licencias de
objetos y medición y tarificación por el uso de objetos. Esto corresponde a los
servicios de gestión de licencias en
43.5.12 Sistema y Servicios de gestión de red .  o Ciclo de Vida de los servicios
definen las convenciones para crear, eliminar, copiar y mover objetos. La creación
de objetos se define en términos de los objetos de la fábrica, que son objetos que
crean otros objetos.  o Asignación de nombres a los servicios proporcionan la
capacidad de unirse a un nombre a un objeto, y para localizar un objeto por su
nombre. Esto es análogo al servicio Nombre Distribuida descrito en
43.5.6 Servicios de red .  o de objetos persistentes servicios proporcionan
interfaces comunes para retener y gestionar el estado persistente de los objetos.
Objetos menudo se almacenan en un SGBDOO, describen como uno de los servicios de
gestión de datos 43.5.2 .  o Propiedades de los servicios de apoyo a la creación,
supresión, misiones, y la protección de las propiedades dinámicas asociadas con los
objetos.  o Consulta de los servicios de soporte de indexación y las operaciones de
consulta de las colecciones de objetos que devuelven un subconjunto de la
colección. Esto es similar a la base de datos de consulta, una parte de las
funciones de DBMS en Servicios de Gestión de Datos 43.5.2 .  o Relación servicios
permiten relaciones entre los objetos (tales como la propiedad o de contención) que
se representan explícitamente como objetos.  o de seguridad de control de acceso de
servicios de apoyo en los objetos y no repudio de las operaciones sobre los
objetos. El control de acceso se define como un servicio de seguridad (ver
43.5.11 Servicios de Seguridad ). No repudio, que es también un servicio de
seguridad, proporciona la prueba de que una acción se llevó a cabo por un usuario
particular en un momento particular.  o de puesta en marcha de servicios de apoyo
automático de inicio y terminación de los servicios objeto de ORB puesta en marcha
o terminación.  o Tiempo de sincronización de servicios de apoyo de los relojes en
un sistema distribuido. Esto es lo mismo que el servicio de hora Distribuido en
43.5.6 Servicios  de red .  o de comercio de servicios permiten a los clientes a
localizar los objetos por los servicios de los objetos proporcionan, en lugar de
por su nombre. Esto es similar a la de servicio de nombres distribuido en
43.5.6 Servicios de red .  o transacciones de servicios proporcionan facilidades
para agrupar operaciones en unidades atómicas, llamado "transacciones", con la
certeza de que una transacción se llevará a cabo en su totalidad o en absoluto.
Esto corresponde a algunos de los servicios del gestor de transacciones de
Servicios de Procesamiento  de Transacciones 43.5.9 . 
  
  Página 540 de 670 

TOGOF 9.1    

  

  Página 541 de 670 

TOGOF 9.1    

  

44. Integrado de Información de Referencia Infraestructura Modelo

En este capítulo se describe la información integrada de referencia Infraestructura
Modelo (III-RM), en términos de sus conceptos, una visión general, y la taxonomía.

44.1 Conceptos básicos

Esta sección trata de los conceptos básicos de la III-RM, incluyendo antecedentes,
componentes y conductores.
44.1.1 Antecedentes

Con la aparición de las tecnologías basadas en Internet en los últimos años, para
muchas organizaciones el principal foco de atención, y el circuito de retorno de la
inversión en la arquitectura esfuerzo, se ha desplazado desde el espacio de la
plataforma de aplicaciones para el espacio de software de aplicación. (De hecho,
este ha sido uno de los factores que impulsan la migración de sí TOGAF de un marco
y un método para la Tecnología de la Arquitectura a uno para la arquitectura global
de la empresa.) El Modelo de Referencia Técnica TOGAF (TRM) se describe en el 43.
Fundación Arquitectura: Modelo de referencia técnica se centra en el espacio de la
plataforma de aplicaciones. En esta sección se describe un modelo de referencia que
se centra en el software de aplicación espacial, y "Sistemas Comunes de
Arquitectura" en términos de Enterprise Continuum. Este es el Integrado de
Información de Referencia Infraestructura Modelo (IIIRM). El III-RM es un
subconjunto de la TOGAF TRM en términos de su alcance general, sino que también se
expande ciertas partes de la TRM - en particular, las aplicaciones de negocio y
aplicaciones de infraestructura partes - con el fin de proporcionar ayuda para
hacer frente a una de las claves desafíos que enfrenta el arquitecto empresarial de
hoy: la necesidad de diseñar una infraestructura de información integrada para
permitir sin fronteras flujo de información. Estos conceptos se explican en detalle
a continuación. Esta sección introductoria examina el concepto de flujo de
información sin fronteras; ¿por qué es necesaria una infraestructura de información
integrada que le permita;y cómo el IIIRM puede ayudar al arquitecto en el diseño de
una infraestructura de información integrada para su empresa.

  Página 542 de 670 

TOGOF 9.1     44.1.2 componentes del modelo

Al igual que el TOGAF TRM, el III-RM tiene dos componentes principales:

1. Una taxonomía , que define la terminología, y proporciona una descripción
coherente de
los componentes y la estructura conceptual de una infraestructura de información
integrada 

2. Un asociado gráfico III-RM , que proporciona una representación visual de la

taxonomía, y la interrelación de los componentes, como una ayuda para la
comprensión 

El modelo supone la existencia subyacente de una plataforma de computación y la

red, como se describe en la TRM; estos no se representan en el modelo.
44.1.3 Relación con otras partes de TOGAF

La relación de la III-RM a la TRM se explica más arriba. Aunque el III-RM se

pretende ser una herramienta útil en la ejecución de la Arquitectura Método de
Desarrollo de TOGAF (ADM), es importante destacar que la ADM es de ninguna manera
depende del uso de la RM-III (más de lo que es depende del uso de la TRM). Existen
otras taxonomías y modelos de referencia en este espacio que se puede utilizar en
conjunción con el ADM, y de hecho pueden ser preferibles para algunas
organizaciones.
Drivers 44.1.4 clave de negocio y técnicos
44.1.4.1 problema de espacio: la necesidad de flujo de información sin fronteras

El problema de espacio sin fronteras de flujo de información es uno que es

compartido por muchos de los miembros de los clientes de The Open Group, y por
muchas otras organizaciones similares en todo el mundo. Es esencialmente el
problema de la obtención de información a las personas adecuadas en el momento
adecuado de una manera segura y fiable, con el fin de apoyar las operaciones que
son fundamentales para la empresa extendida. En General Electric, Jack Welch
inventó el término "la Organización sin fronteras", no quiere decir que no hay
límites, pero que deben hacerse permeable. La creación de estructuras organizativas
que permitieron a cada departamento para operar con la máxima eficiencia fue
durante mucho tiempo aceptado como el mejor enfoque para la gestión de una gran
empresa. Entre otros beneficios, este enfoque fomenta el desarrollo de
conocimientos especializados en el personal, que se podrían aplicar esas
habilidades a aspectos específicos de una actividad general (como un proceso de
fabricación), con el fin de cumplir las tareas implicadas mejor, más rápido y más
barato.
  Página 543 de 670 

TOGOF 9.1    

A medida que cada actividad global progresó a través de la organización, que pasa
de un departamento a otro (por ejemplo, desde el diseño hasta la producción a las
ventas), cada departamento tomaría insumos del departamento anterior en el proceso,
podrá aplicar sus propios procesos de negocio para la actividad, y enviar su salida
al siguiente departamento en línea. En el mundo actual donde la velocidad, la
flexibilidad y la capacidad de respuesta a los cambios del mercado marcan la
diferencia entre el éxito y el fracaso, este método de trabajo ya no es apropiado.
Las organizaciones han estado tratando durante algún tiempo para superar las
limitaciones impuestas por las estructuras tradicionales de organización. Se han
emprendido y abandonado porque eran demasiado ambiciosos, mientras que otros
cuestan mucho más en tiempo y dinero de lo previsto originalmente Muchos esfuerzos
de reingeniería de procesos de negocio. Sin embargo, las organizaciones de hoy en
día reconocen que no necesitan abandonar la organización funcional o departamental
en conjunto. Pueden permitir que las personas adecuadas se reúnan en equipos
multifuncionales de modo que todas las habilidades, conocimientos y experiencia
pueden ser ejercidas sobre cualquier problema específico o una oportunidad de
negocio. Pero esto a su vez plantea sus propios desafíos. CIOs están bajo una
enorme presión para facilitar el acceso a la información a cada equipo
multifuncional según sea necesario-, y sin embargo, las fuentes de estos datos
pueden ser numerosas y los volúmenes enormes. Peor aún, los sistemas informáticos,
que se han construido en un período de 20 o 30 años a un costo de miles de millones
de dólares, y no están a punto de ser expulsado o al por mayor reemplazado, fueron
construidos para cada departamento funcional. Así que a pesar de que puede ser
posible que la gente a trabajar juntos de manera efectiva (no es un logro menor en
sí mismo), los sistemas informáticos que utilizan están diseñados para soportar el
pensamiento de estilo antiguo. Los sistemas de TI en lugar de hoy no permiten que
la información fluya en apoyo de la organización sin fronteras. Cuando lo hacen,
entonces tendremos sin fronteras Flujo de Información.
44.1.4.2 Solución Espacio: La necesidad de una infraestructura de información
integrada

El Open Group Interoperable Enterprise Business Escenario 1 publicado originalmente

en 2001, cristaliza esta necesidad sin fronteras Flujo de información y describe la
forma en que esta necesidad impulsa el despliegue de su infraestructura de la
información de los clientes de TI. En este escenario, planteamiento del problema
del cliente dice que yo (como la empresa cliente) podría ganar eficiencias
operativas significativas y mejorar los diferentes procesos de negocio de la
empresa - tanto los procesos internos, y los que abarca las principales
  Página 544 de 670 

TOGOF 9.1    

interacciones con los proveedores, clientes y socios - si tan sólo pudiera dar mi
personal con:
Información integrada para que diferentes y potencialmente conflictivas piezas de
información que no se distribuyen a través de diferentes sistemas  Acceso integrado
a esa información a fin de que el personal pueda acceder a toda la información que
necesitan y tienen derecho a, a través de una cómoda interfaz 

La infraestructura que permite a esta visión se denomina la "infraestructura de

información integrada". A modo de ejemplo, un enfoque actual de la infraestructura
de información integrada es proporcionar "portales empresariales" que permiten un
acceso integrado a la información de diferentes sistemas de aplicaciones, a través
de una cómoda interfaz web-enabled, (uno de los segmentos de color en los extremos
de toda la empresa el cilindro en la Figura 44-1 ).

 
Figura 44‐1: Una aproximación al flujo de información sin fronteras (Enterprise Por
tals) 

Uno de los principales retos para el arquitecto en la empresa de hoy es trabajar, y

luego comunicar a la alta dirección, como las tecnologías lejanos como los
servicios web,
  Página 545 de 670 

TOGOF 9.1    

servicios de integración de aplicaciones, etc, se van hacia el logro de una

infraestructura de información integrada, y darse cuenta de la visión sin fronteras
Flujo de Información, en la empresa de que se trate. Análisis de seguimiento del
Grupo Abierto del Escenario Interoperable Enterprise Business ha dado lugar al
desarrollo de un modelo integrado de infraestructura de la información (el III-RM),
que representa a los principales componentes necesarios para abordar el problema de
espacio sin fronteras Flujo de Información, y puede ayudar al arquitecto en esta
tarea. Así, el III-RM ofrece ideas relacionadas con las necesidades del cliente
para sin fronteras flujo de información en entornos empresariales. El modelo
también apunta a las reglas y normas para ayudar a aprovechar las soluciones y
productos dentro de la cadena de valor. Las siguientes subsecciones discuten el
modelo en detalle.
44.1.5 Situación de la III‐RM

El III-RM se documenta en su forma actual, y de ninguna manera considerados un

artículo acabado. Sin embargo, se trata de un modelo que ha sido desarrollado y
aprobado por los miembros de The Open Group en su conjunto, en respuesta a la
Interoperable Enterprise Business Scenario, que a su vez se desarrolló en respuesta
a la urgente necesidad expresada por los miembros de los clientes de The Open Grupo
de ayuda en este campo. El escenario de negocios y el modelo de referencia por lo
tanto representan un problema y un enfoque de solución que la pertenencia al grupo
abierto en su conjunto apoya plenamente. Se espera que la publicación de la modelo
como parte de TOGAF fomentará su adopción y el uso generalizado, y proporcionar un
canal de comunicación mediante el cual la experiencia con el uso del modelo puede
ser realimentada, puntos de mejora asimilado, y el modelo refinado y reeditado como
sea necesario .

44.2 de Alto Nivel View

Esta sección proporciona una vista de alto nivel de la III-RM, incluyendo
derivación del modelo, gráfico de alto nivel, y los componentes.
44.2.1 Obtención de la III‐RM de la TRM

El III-RM es un modelo de las principales categorías de componentes para el

desarrollo, gestión y operación de una infraestructura de información integrada. Se
trata de un modelo de un conjunto de aplicaciones que se sienta encima de una
plataforma de aplicaciones. Este modelo es un subconjunto de la TOGAF TRM, y
utiliza una orientación ligeramente diferente.
  Página 546 de 670 

TOGOF 9.1    

Considere la Figura 44-2 , donde se presentan dos vistas de la TOGAF TRM. El lado
izquierdo es la visión familiar de la TOGAF TRM; es una vista lateral, donde nos
fijamos en el modelo como si estuviera buscando en una casa del lado, revelando el
contenido de los "pisos". La vista de arriba hacia abajo en la parte derecha
representa lo que se podría ver si la mirara a una casa del "techo" abajo.

 
Figura 44‐2: TOGAF TRM Orientación Vistas 

El subconjunto de la TRM que comprende el III-RM se representa en la figura 44-3 ,

en el que las partes de la TRM no es relevante para la III-RM están "en gris".
La figura 44-3 ilustra que la atención se centra en el software de aplicación, la
plataforma de aplicaciones y cualidades subconjunto del TOGAF TRM.

  Página 547 de 670 

TOGOF 9.1    

 
Figura 44‐3: Enfoque de la III‐RM 

44.2.2 de Alto Nivel III‐RM Gráfico

El propio III-RM resultante se representa en la Figura 44-4 . Es fundamentalmente

un modelo de referencia de arquitectura de aplicaciones - un modelo de componentes
de aplicaciones y servicios de aplicación de software esencial para una
infraestructura de información integrada. (Hay más aplicaciones de negocios y
aplicaciones de infraestructura que éstas en el medio ambiente, por supuesto, pero
estos son los subconjuntos relevantes para el problema de espacio sin fronteras
Flujo de Información.)

  Página 548 de 670 

TOGOF 9.1    

 
Figura 44‐4: III‐RM ‐ de Alto Nivel 

Como se explicó anteriormente, el modelo supone la existencia subyacente de un

cálculo y la plataforma de red, y no representa a ellos explícitamente. Aunque la
computación y de la plataforma de red no se muestran, puede haber requisitos en los
que se deben cumplir, además de los requisitos de los componentes de la III-RM, con
el fin de abordar plenamente el problema de espacio sin fronteras Flujo de
Información.
44.2.3 Componentes de Alto Nivel III‐RM

El III-RM tiene los siguientes componentes principales:

Aplicaciones empresariales , designados por las cajas amarillas en el modelo de
alto nivel (que corresponden al cuadro "Aplicaciones empresariales" en el gráfico
TRM). Hay tres tipos de Aplicaciones de Negocio en el modelo:  o Aplicaciones de
intermediación , que gestionan las solicitudes de cualquier número de clientes ya
través de cualquier número de aplicaciones de los proveedores de información 

  Página 549 de 670 

TOGOF 9.1    
o aplicaciones de proveedores de información , que proporcionan respuestas a las
peticiones de los clientes y el acceso rudimentario a los datos gestionados por un
servidor particular  o Aplicaciones de Información al Consumidor , que entregan
contenido al usuario del sistema, y proporcionan servicios para solicitar el acceso
a la información en el sistema en nombre del usuario  Aplicaciones
Infraestructura , denotados por las cajas de color naranja en el modelo de alto
nivel (que corresponden al cuadro "Aplicaciones de Infraestructura" en el gráfico
TRM). Hay dos tipos de Aplicación Infraestructura en el modelo:  o Herramientas de
desarrollo , que proporcionan todo el modelado es necesario, el diseño, la
construcción y las capacidades para desarrollar e implementar aplicaciones que
requieren acceso a la infraestructura de información integrada, de manera
compatible con las normas de medio ambiente  o Servicios de Gestión , que
proporcionan todos los servicios públicos necesarios para comprender, operar,
ajustar y administrar el sistema en tiempo de ejecución con el fin de satisfacer
las demandas de un negocio en constante cambio, de una manera consistente con las
normas de medio ambiente  Una plataforma de aplicaciones , que proporciona
servicios de apoyo a todas las aplicaciones mencionadas - en áreas tales como la
ubicación, el directorio, el flujo de trabajo, gestión de datos, intercambio de
datos, etc - y por lo tanto proporciona la capacidad de encontrar, manipular y
mover la información dentro del entorno. Este conjunto de servicios constituye un
subconjunto del conjunto total de los servicios de la plataforma de aplicaciones de
TRM, y se representa por la capa base de color verde oscuro en el modelo de alto
nivel (que corresponde a la plataforma de aplicaciones en el gráfico TRM).  Las
interfaces utilizadas entre los componentes. Las interfaces incluyen formatos y
protocolos, interfaces de programación de aplicaciones, switches, los valores de
datos, etc Interfaces entre los componentes a nivel de aplicación son de color
rojo. Interfaces entre los componentes de nivel de aplicación y sus servicios de
apoyo en la plataforma de aplicaciones son de color blanco (que corresponde a la
caja de API en el gráfico TRM).  El Cualidades backplane, denotado por la capa base
de color marrón en el modelo de alto nivel (que corresponde a la placa posterior
Cualidades en el gráfico TRM). El software de aplicación y la plataforma de
aplicaciones deben cumplir con las políticas y los requisitos descritos por el
backplane cualidades. 

44.3 Taxonomía detallada

En esta sección se ofrece una taxonomía detallada de la III-RM, incluyendo gráfica
detallada, las categorías de servicios de plataforma, y el medio ambiente sub-
entidades externas.
  Página 550 de 670 

TOGOF 9.1     44.3.1 detallada III‐RM Gráfico

El detallado III-RM se muestra en la Figura 44-5 .

    
Figura 44‐5: III‐RM ‐ Detallado 

Las restantes subsecciones se expanden en el detalle taxonomía / componente se

muestra en la Figura 44-5 .
44.3.2 Aplicaciones de Negocio

Hay tres tipos de aplicaciones de negocio en el modelo:

Aplicaciones proveedor de información , que proporcionan respuestas a las
solicitudes de los clientes y el acceso rudimentario a los datos gestionados por un
servidor particular  Aplicaciones de intermediación , que gestionan las solicitudes
de cualquier número de clientes hacia y a través de cualquier número de proveedores
de servicios  Información de los usos del consumidor , que entregan contenido al
usuario del sistema, y prestan servicios a la solicitud de acceso a la información
en el sistema en nombre del usuario 

El conjunto global de proveedor de información, de información al consumidor, y

aplicaciones de corretaje crea colectivamente un entorno que proporciona un amplio
  Página 551 de 670 

TOGOF 9.1    

conjunto de servicios de usuario final para acceder de forma transparente los

sistemas heterogéneos, bases de datos y sistemas de archivos.
44.3.2.1 Información Aplicaciones Proveedores

En la medida en que la información de hoy puede ser considerado como "rehenes",

como se muestra en la Figura 44-6 , Aplicaciones proveedor de información son las
aplicaciones que "liberar" a los datos de sus silos.

 
Figura 44‐6: Liberate datos Silos para satisfacer las necesidades de información de 
los equipos de la empresa  de funciones cruzadas 

Aplicaciones proveedor de información a lograr esto proporcionando una interfaz

abierta para una interfaz de silo potencialmente propietario, como se ilustra en la
Figura 44-7 , donde los puertos en la izquierda de la información de aplicaciones
de proveedores están interfaces abiertas y las interfaces entre las aplicaciones de
los proveedores de información y datos de silo son interfaces propietarias.
  Página 552 de 670 

TOGOF 9.1    

 
Figura 44‐7: Información Aplicaciones Proveedores Liberate de datos, proporcionando 
interfaces abiertas a  los datos Silos 

  
44.3.2.2 Aplicaciones Corretaje

Aplicaciones de corretaje sirven peticiones individuales que requieren acceso a

múltiples fuentes de información. Una aplicación de Bolsa analiza dicha solicitud,
distribuye la solicitud a múltiples fuentes de información, recoge las respuestas,
y envía una única respuesta al cliente solicitante. Aplicaciones de corretaje
acceder a la información del proveedor de aplicaciones que utilizan las interfaces
abiertas proporcionadas por las aplicaciones de los proveedores de la información
(como se describe más arriba); que integran la información de múltiples
aplicaciones de los proveedores de información y transmiten la información
integrada para aplicaciones de información al consumidor mediante interfaces
abiertas. Aplicaciones de corretaje también permiten el acceso a la información
dentro de la empresa por los socios estratégicos.

  Página 553 de 670 

TOGOF 9.1    

 
Figura 44‐8: Aplicaciones de corretaje integrar la información de la Información Ap
licaciones Proveedores 

  
44.3.2.3 Información usos del consumidor

Información de los usos del consumidor facilitan información a los usuarios en la

forma en que la necesitan, cuando lo necesitan, y de una manera segura a
terminar.Esto incluye el suministro de la información en el texto, video, audio,
Inglés, Alemán, etc Información de los usos del consumidor se comunican con las
aplicaciones de corretaje o Aplicaciones proveedor de información que utilizan las
interfaces abiertas que las aplicaciones Corretaje e Información de Proveedores
proporcionan. La seguridad se proporciona a través de los servidores de seguridad y
/ o servicios de seguridad.
La figura 44-9 muestra las aplicaciones de consumidor de información con los
servicios de

seguridad que aparecen como el patrón de ladrillo.

  Página 554 de 670 

TOGOF 9.1    

 
Figura 44‐9: Información usos del consumidor se comunican mediante interfaces abier
tas 

   44.3.3 Aplicaciones Infraestructura

Hay dos tipos de Aplicación Infraestructura en el modelo:
Herramientas de desarrollo , que proporcionan todo el modelado es necesario, el
diseño, la construcción y las capacidades para desarrollar e implementar
aplicaciones que requieren acceso a la infraestructura de información integrada, de
manera compatible con las normas de medio ambiente  Utilidades de gestión , que
proporcionan todos los servicios públicos necesarios para comprender, operar,
ajustar y administrar el sistema en tiempo de ejecución con el fin de satisfacer
las demandas de un negocio en constante cambio, de manera compatible con las normas
de medio ambiente  44.3.3.1 Herramientas de desarrollo

El componente Herramientas de Desarrollo del modelo comprende aplicaciones que

toman la forma de herramientas para el modelado, diseño y construcción de la
infraestructura de información integrada. En concreto, incluye herramientas para
los negocios, procesos y modelado de datos, así como las herramientas para la
construcción de aplicaciones tradicionales que transforman el modelo de negocio en
el software que automatiza los procesos de negocio que giran en torno a la
información.
  Página 555 de 670 

TOGOF 9.1    

Tenga en cuenta que cada conjunto de herramientas estará conectada lógicamente a

través de un directorio, lo que permite una herramienta a ser impulsado por los
datos de otra. Las secciones siguientes describen los requisitos para componentes
de herramientas de desarrollo. El conjunto de herramientas también incluye un
repositorio.

Herramientas de Modelado de Negocios

Esta categoría cubre las herramientas para el modelado de reglas de negocio y

reglas de procesos de negocio. Modelado de actividades se describe y documenta el
negocio de una amplia base de conocimientos. Establece un consenso entre la
dirección general de los requisitos de dirección de negocio, organización,
procesos, información y el entorno actual de los negocios. Tal vez lo más
importante es que esta comprensión se documenta en un formato común, orientada a
los negocios que se utilizarán para la mejora posterior.
Herramientas de Modelado Diseño

Esta categoría cubre las herramientas para diseñar, definir y documentar los
elementos de TI más relevantes de la empresa sobre la base de las reglas de negocio
y los procesos de negocio. Ejemplos de elementos a ser diseñados incluyen:
conexiones entre las personas, las organizaciones, los flujos de trabajo y
ordenadores; datos y modelos de objetos; traducción de datos física y las reglas de
traducción; y limitaciones.
Implementación y herramientas de construcción

Instrumentos de aplicación permiten el desarrollo oportuno de los reutilizables

procesos, aplicaciones y servicios de aplicación. Estas herramientas incluyen
navegadores inteligentes, los compiladores de lenguaje de manipulación de datos y
optimizadores, compiladores de aplicaciones distribuidas y depuradores, cliente y
servidor de desarrollo de herramientas heterogéneas, las herramientas de definición
de políticas y herramientas de generación de scripts del flujo de trabajo.
Herramientas de Modelado de Datos Herramientas de implementación

Herramientas de implementación son necesarios para mover el software implementado

en el entorno de desarrollo en el entorno operativo.
Bibliotecas
  Página 556 de 670 

TOGOF 9.1    

Este componente incluye las bibliotecas reutilizables de software que utilizan las
normas del entorno operacional.
44.3.3.2 Gestión de Servicios Públicos

Esta categoría cubre las aplicaciones que toman la forma de utilidades para las
operaciones, la administración y gestión de redes, y de la gestión de los datos en
función de los requisitos de disponibilidad y costo. Dichas utilidades pueden
ejecutarse en una o en un entorno desatendido asistido.

Operaciones, Administración y Gestión (OA & M) Utilidades

El componente de OA & M cubre servicios de gestión y administración de sistemas

tradicionales que gestionan las reglas de negocio y los objetos de
información.Algunos ejemplos son: utilidades para la instalación, derechos de autor
y la gestión de licencias; y administración miscelánea, la configuración y las
funciones de registro. Además, existen utilidades para el control de la facturación
del servicio, el servicio de activación y administración de cuentas.
Calidad de servicio Administrador de Utilidades

Estos incluyen utilidades de monitorización y gestión de la salud.

Copia Gestión De Servicios

Utilidades de administración de copia son los que gestionan el movimiento de datos

desde cualquier sistema operativo dado a los puntos de distribución necesarias en
la empresa, con el fin de garantizar el máximo aprovechamiento de los datos de los
sistemas operativos. También se incluyen herramientas que detectan y bandera datos
de mala calidad.
Administración de almacenamiento Utilidades

Estos son los servicios públicos que permita la gestión de almacenamiento de datos
de menor costo. Utilidades de administración de almacenamiento compatibles con la
gran variedad de mecanismos de almacenamiento y están conectados a un archivo,
objeto, y los sistemas de bases de datos.

  Página 557 de 670 

TOGOF 9.1     44.3.4 Plataforma de Aplicaciones

Todos los diferentes tipos de aplicaciones descritas anteriormente se construyen en

la parte superior de los servicios prestados por la plataforma de aplicaciones. El
componente de la plataforma de aplicaciones de la III-RM comprende un subconjunto
de todos los servicios que se definen en el TOGAF TRM, el subconjunto que se
refiere a la infraestructura de información integrada. Específicamente, comprende
todos los servicios en la plataforma de aplicaciones de TRM que permiten a las
aplicaciones se centran en la comprensión y tratamiento de la información
requerida, en lugar de comprender la forma, formato y / o ubicación de la
información. Los servicios del componente Application Platform se pueden utilizar
para dar soporte a aplicaciones convencionales, así como Intermediación,
información para el consumidor, y las aplicaciones de proveedor de información.
Cuando se utiliza como parte de una arquitectura global de aplicación de esta
forma, este enfoque permite la máxima influencia de un único entorno operativo que
está diseñado para asegurar la transferencia efectiva y coherente de los datos
entre los procesos, y para apoyar el desarrollo rápido y eficiente, la
implementación y la gestión de de aplicaciones. El componente de la plataforma de
aplicaciones comprende las siguientes categorías de servicio.

44.3.4.1 Software Engineering Services Idiomas  Bibliotecas  Registros  44.3.4.2

Servicios de Seguridad Autenticación, autorización y control de acceso  Single
Sign-On  Firma digital  Firewall  Encryption  La detección de intrusiones  Gestión
de la identidad 

  Página 558 de 670 

TOGOF 9.1    
Gestión de claves  44.3.4.3 Ubicación y Servicios de Directorio

Ubicación y directorio de servicios proporcionan facilidades de acceso para el

nombre, ubicación, descripción y datos de relaciones que describe la
infraestructura de información integrada. Los servicios de directorio compatibles
con el despliegue y la disponibilidad de toda la empresa de un directorio de la
infraestructura de información integrada. Los datos en el directorio se ponen a
disposición de todos los demás componentes en el modelo de arquitectura.
La figura 44-10 muestra la yuxtaposición de ubicación y servicios de directorio
para los otros

componentes.

 
Figura 44‐10: Yuxtaposición de ubicación y servicios de directorio para otros compo
nentes 

Los servicios específicos incluyen:

Directorio  Registro  Publicación / suscripción  Descubrimiento  Nombrando 

  Página 559 de 670 

TOGOF 9.1    
Hacer referencia / eliminación de referencias  44.3.4.4 Interacción Humano
Servicios

Servicios de interacción humana proporcionan los medios para constantemente

presentan datos al usuario final en el formato adecuado. Comprenden servicios que
contribuyan a la formulación de solicitudes de datos del cliente y permiten la
visualización y presentación de los datos consultados. Los servicios específicos
incluyen:
Presentación  Transformación  Navegador  Meta índices  Portal y personalización 
44.3.4.5 Servicios de Data Interchange

Los servicios específicos incluyen:

Formato de Información  Formularios Electrónicos  Mensajería instantánea 
Aplicación de mensajería  Comunicación de aplicación a aplicación  Integración de
aplicaciones empresariales  Servicios de administración de datos 44.3.4.6

Los servicios específicos incluyen:

Información y datos de acceso  Mapeo de Transformación  Distribución de consultas 
Agregación  Búsqueda 

  Página 560 de 670 
TOGOF 9.1    
Expediente 

Servicios de acceso a la información proporcionan la capacidad de una aplicación

para acceder a una visión integrada de los datos, independientemente de si existen
los datos en un sistema de computadora central o en un sistema distribuido. Los
servicios de acceso a la información aseguran que la integridad de datos se
mantiene entre múltiples bases de datos, y también proporcionan la limpieza de
datos en línea (en el que los datos se comprueba con normas de datos para cada
acceso). Servicios de acceso a datos proporcionan interfaces abiertas para los
datos heredados, proporcionar nuevas aplicaciones de servicios de acceso a la base
de datos estándar para grandes cantidades de datos existentes, y proporcionar
servicios de acceso estándar a los nuevos tipos de datos.
44.3.4.7 Otros servicios del sistema operativo

Los servicios específicos incluyen:

Intermediación Evento  Workflow 

Estos servicios adicionales permiten el flujo de información, como se representa en

la figura 44-11 .

    Página 561 de 670 

TOGOF 9.1    
Figura 44‐11: Workflow Services Habilitar Flujo de Información 

Flujo de trabajo denota el concepto de automatización de procesos, facilitando las

interacciones del usuario y la ejecución de aplicaciones de acuerdo con un mapa de
procesos. Los servicios de flujo de trabajo permiten la integración de aplicaciones
empresariales, lo que resulta en aplicaciones de valor extendida. Los servicios de
flujo de trabajo también se ocupan de las necesidades de la gestión de un entorno
en el que los sistemas heredados son frecuentes. Los servicios de flujo de trabajo
también proporcionan un medio para encapsular las aplicaciones existentes, apoyando
así las necesidades del cliente para el apalancamiento de los activos existentes.
44.3.5 Cualidades

El componente de las cualidades del modelo se apoya en la calidad de los servicios

de servicio, incluyendo los diversos servicios que se requieren para mantener la
calidad del sistema como se especifica en los Acuerdos de Nivel de Servicio (SLA).
En esto se incluyen los servicios a crear las condiciones para, y reaccionar a las
peticiones de la Calidad de Service Manager.

  Página 562 de 670 

TOGOF 9.1    

     

PARTE VII Marco de Arquitectura de Capacidad

      Página 563 de 670 

TOGOF 9.1    

  
45. Introducción
Este capítulo proporciona una introducción y una visión general de los contenidos
de la parte VII: Arquitectura del marco de Capacidad .

45.1 Información general

Con el fin de operar con éxito una función de la arquitectura dentro de una
empresa, es necesario poner en marcha las estructuras apropiadas de organización,
procesos, funciones, responsabilidades y habilidades para realizar la Capacidad de
Arquitectura.
Parte VII: Architecture Framework Capacidad proporciona un conjunto de materiales
de referencia

para la forma de establecer una función de este tipo de arquitectura. Los lectores
deben tener en cuenta que aunque esta parte contiene una serie de directrices para
apoyar actividades clave, en su forma actual, el Marco de Capacidad Arquitectura no
pretende ser una plantilla completa para el funcionamiento de una capacidad de
arquitectura empresarial. Una estructura general para el marco de capacidades de
Arquitectura se muestra en la Figura
45-1 .

  Página 564 de 670 

TOGOF 9.1    

 
Figura 45‐1: Arquitectura Maduro Capability 

     

45.2 Estructura de la Parte VII

Parte VII: Arquitectura del marco de Capacidad está estructurado de la siguiente
manera: Introducción (este capítulo)  Establecer una capacidad de Arquitectura (ver
46. establecer una capacidad de Arquitectura )  Architecture Board (ver
47. Architecture Board )  Arquitectura de cumplimiento (véase
48. Arquitectura de Cumplimiento )  Contratos de Arquitectura (ver
49. Arquitectura Contratos )  Arquitectura de control (véase
50. Arquitectura de Gobierno )  Modelos de Madurez Arquitectura (ver
51. Arquitectura de Madurez Modelos )  Arquitectura Skills Framework (véase
52. Arquitectura Skills Framework ) 

  Página 565 de 670 

TOGOF 9.1          

  Página 566 de 670 

TOGOF 9.1    

  

46. Establecer una capacidad de Arquitectura

Este capítulo proporciona directrices sobre cómo utilizar el ADM para establecer
una capacidad de Arquitectura.

46.1 Información general

Como con cualquier capacidad de negocio, la creación de una capacidad de
arquitectura empresarial puede ser apoyado por el Método de Desarrollo de
Arquitectura TOGAF (ADM). El uso exitoso de la ADM proporcionará una práctica de
valor añadido, y la arquitectura sostenible centrada en el cliente que permite a la
empresa, ayuda a maximizar el valor de las inversiones, e identifica proactivamente
las oportunidades de obtener beneficios de negocio y gestionar el riesgo. El
establecimiento de un estudio de arquitectura sostenible dentro de una organización
se puede lograr mediante la adhesión a la misma aproximación que se utiliza para
establecer las demás capacidades - tales como la capacidad de gestión de procesos
de negocio - dentro de una organización. El ADM es un método ideal para ser
utilizado al arquitecto y gobernar la aplicación de tal capacidad. La aplicación de
la ADM con el Architecture Vision específica para establecer un estudio de
arquitectura en la organización iba a lograr este objetivo. Esto no debe ser visto
como una fase de un proyecto de arquitectura, o de un proyecto de una sola vez,
sino más bien como una práctica continua que ofrece el contexto, el ambiente y los
recursos para gobernar y permitir la entrega de arquitectura para la organización.
Como un proyecto de arquitectura se ejecuta dentro de este entorno que podría
solicitar un cambio en la práctica de la arquitectura que daría lugar a un nuevo
ciclo de la ADM de ampliar la práctica de la arquitectura. La implementación de
cualquier capacidad dentro de una organización requeriría el diseño de las cuatro
arquitecturas de dominio: de negocios, datos, aplicaciones, y Tecnología. Por lo
tanto, se establece la práctica de la arquitectura dentro de una organización
requeriría el diseño de:
La arquitectura de negocio de la práctica de la arquitectura que pondrá de relieve
la gobernabilidad arquitectura, los procesos de arquitectura, arquitectura
estructura organizativa, las necesidades de información de arquitectura, productos
de arquitectura, etc  La Arquitectura de Datos que defina la estructura de la
empresa Continuum y Arquitectura Repositorio de la organización 

  Página 567 de 670 

TOGOF 9.1    
La arquitectura de aplicaciones especificando la funcionalidad y / o servicios de
aplicaciones se requiere para que el estudio de arquitectura  La Tecnología de la
Arquitectura que describe las necesidades de infraestructura de la práctica de la
arquitectura y el despliegue en apoyo de las aplicaciones de arquitectura y Empresa
Continuum 

Los pasos en el establecimiento de un estudio de arquitectura se explican a

continuación, contra el contexto de las fases de ADM. Por tanto, el lector debe
referirse a la fase de ADM relevante en la Parte II: Arquitectura Método de
Desarrollo (ADM) , para comprender el alcance completo de cada paso. En esta
sección, los aspectos fundamentales se destacarán para cada fase de ADM que se debe
considerar y son específicas para el establecimiento de un estudio de arquitectura.
La intención, por lo tanto no es repetir la descripción de cada fase de ADM, pero
para guiar al lector a aplicar cada fase de ADM en el contexto del establecimiento
de una práctica de la arquitectura.

46.2 Fase A: Architecture Vision

El propósito de esta fase en el contexto del establecimiento de un estudio de
arquitectura es definir o revisar la visión, las partes interesadas, y los
principios de la práctica de la arquitectura. El objetivo en esta fase sería en la
práctica de la arquitectura en su conjunto y no en un proyecto de arquitectura en
particular. Lo siguiente debe ser considerado en términos de comprensión de los
pasos en el contexto del establecimiento de una práctica de la arquitectura:
Establecer el Proyecto : Este paso debe centrarse en la definición de los grupos de
interés en la práctica de la arquitectura. Las partes interesadas incluirían las
funciones y unidades de la organización que participan en la práctica de la
arquitectura, así como aquellos que se beneficiarán de las prestaciones generadas
por la práctica de la arquitectura, por tanto, que se puede definir como los
clientes de la práctica de la arquitectura.  Identificar a los Interesados y
preocupaciones, los requisitos de negocio y Architecture Vision : Este paso genera
las primeras definiciones, muy de alto nivel de los entornos de referencia y
objetivos, desde una perspectiva de los sistemas de información de negocios y
tecnología para la práctica de la arquitectura.  Identificar objetivos de negocio y
los impulsores del negocio : Esto sería más relevante para la práctica de la
arquitectura, que a un proyecto de arquitectura en particular. La comprensión de
los objetivos de negocio y los conductores es esencial para alinear la práctica de
la arquitectura para el negocio.  Definir el Alcance : Definir el alcance de la
práctica de la arquitectura sería un plan de proyecto de alto nivel de lo que debe
ser abordado en términos de arquitectura para el próximo período.  Definir
restricciones : El enfoque en este paso debe estar en las limitaciones de toda la
empresa que impactarían en todos los proyectos de arquitectura. 

  Página 568 de 670 

TOGOF 9.1    
Revise Arquitectura Principios, incluidos los Principios de Actuación : La
intención en este paso debe ser definir los principios que regirían y orientar la
gestión de la práctica de la arquitectura. Cuando los principios de arquitectura
generalmente rigen las prestaciones de arquitectura, los principios de la práctica
de arquitectura abordarían la organización práctica de la arquitectura, el
contenido, las herramientas, y el proceso.  Desarrollar el Enunciado del Trabajo de
Arquitectura y Aprobación Secure : Este paso debe generar la práctica la visión y
el ámbito de la arquitectura. 

Otro paso que se puede considerar en esta fase es llevar a cabo una evaluación de
la madurez de la arquitectura. Consulte 51. Modelos de Madurez de Arquitectura para
la orientación sobre este tema.

46.3 Fase B: Arquitectura de Negocios

Las áreas clave de enfoque durante esta fase de establecimiento o el
perfeccionamiento de la Arquitectura Empresarial de la práctica de la arquitectura
son:
Una Arquitectura Ontología definir los términos y las definiciones que se
utilizarán en la organización con el fin de establecer una comprensión común de
estos términos arquitectónicos.  El proceso de arquitectura donde el ADM formaría
la base del proceso y la necesidad de ser personalizado para satisfacer las
necesidades de la organización y práctica de la arquitectura de la visión. Consulte
5.3 Adaptación de la ADM para la orientación en el desarrollo de este proceso. Los
procesos de gobernanza arquitectura requeridas deben ser incluidos en el proceso
general de la arquitectura.  Los puntos de vista de arquitectura y vistas que
muestra todos los puntos de vista y opiniones que deben ser abordados por el
estudio de arquitectura. Las prácticas de los actores identificados arquitectura
guiarían el desarrollo de esta definición. Uno de los puntos de vista que deben
incluirse es el punto de vista de la arquitectura de gobernanza; consulte
la Parte IV , 35. Architectural Artifacts para orientarlos respecto a esta salida. 
La arquitectura marco descriptivo de las distintas entregas de arquitectura que se
generarán por la práctica de la arquitectura, las interrelaciones y dependencias
entre los entregables de arquitectura, así como las normas y directrices que rigen
el diseño de estos productos entregables. Los puntos de vista y las opiniones de
arquitectura definidos deben utilizarse para orientar la definición del marco de la
arquitectura. Parte II: Arquitectura  Método de Desarrollo (ADM) y
36. Arquitectura Entregables son referencias útiles que ayudarán a describir el
marco de la arquitectura.  La Planilla de Responsabilidades Arquitectura definición
de las funciones en la práctica de la arquitectura y la asignación de la
responsabilidad de las funciones a las prestaciones y los procesos de arquitectura.
Esta matriz incluiría las estructuras necesarias arquitectura de gobernanza y
roles. Parte II: Arquitectura Método de Desarrollo (ADM) , así como
47. Architecture Board , 50. Arquitectura de Gobierno , y 52 . Arquitectura Skills 
Framework proporcionará orientación sobre esta salida. 

  Página 569 de 670 

TOGOF 9.1    
La arquitectura de rendimiento Métrica identificación y descripción de los
indicadores que se utilizarán para monitorear el desempeño de la práctica de la
arquitectura en contra de su declarada práctica la visión y los objetivos de la
arquitectura.  El Marco de Gobierno de Arquitectura , que es un punto de vista
específico del proceso de arquitectura definida y Arquitectura Planilla de
Responsabilidades. 

46.4 Fase C: Arquitectura de Datos

La Arquitectura de Datos de la práctica de la arquitectura especificaría y gobernar
la estructura de la empresa Continuum de la organización y arquitectura de
repositorio. La Arquitectura de Datos debe definirse con base en el marco de la
arquitectura. La Arquitectura de Datos se refiere a veces como el metamodelo de la
práctica de la arquitectura.

46.5 Fase C: Arquitectura de aplicaciones

La Arquitectura de la aplicación de la práctica de la arquitectura define la
funcionalidad necesaria para generar, mantener, publicar, distribuir, y gobernar
los entregables arquitectura como se define en el marco de la arquitectura. Un
enfoque clave debe estar en los conjuntos de herramientas de modelización
necesarias para modelar, pero no debería ser el único foco. Consulte 42.
Herramientas para el desarrollo de la arquitectura para la orientación en la
selección de un conjunto de herramientas. La publicación de los entregables de
arquitectura para hacer frente a puntos de vista específicos en el marco de la
arquitectura a veces requieren una funcionalidad especializada o personalizada y no
debe ser descuidado.

46.6 Fase D: Architecture Tecnología

La Tecnología de la Arquitectura de la práctica de la arquitectura debería definir
la infraestructura de tecnología de apoyo a la práctica de la arquitectura.

46.7 Fase E: Oportunidades y Soluciones

Un factor crítico a considerar durante esta fase de la planificación de la creación
de la práctica de la arquitectura es el cambio organizacional que se requiere y
cómo se va a lograr.

46.8 Fase F: planeamiento de migración

El enfoque no debe ser sólo en los componentes de los sistemas de información de
arquitectura en esta fase, sino que incluyen la arquitectura de negocio. La
adopción del proceso de la arquitectura y el marco tendrá un impacto importante en
el establecimiento general de la práctica de la arquitectura en la organización.

  Página 570 de 670 

TOGOF 9.1    

46.9 Fase G: Gobernanza Aplicación

La implementación de la Arquitectura Empresarial de la práctica de la arquitectura
debe ser el foco de esta fase. Cambiar las prácticas dentro de la organización a
adoptar un enfoque más estructurado y disciplinado será un reto y debe ser abordado
por las técnicas de cambio de organización adecuadas.

46.10 Fase H: Gestión Arquitectura Cambio

Los cambios en la arquitectura de la práctica de la arquitectura deben ser
gestionados por esta fase. Estos cambios generalmente se activan durante la
ejecución de proyectos de arquitectura. Un cambio típico sería el requisito para
una nueva arquitectura entregable. Esto tendría un impacto en todos los ámbitos de
la arquitectura de la práctica de la arquitectura.

Gestión 46.11 Requisitos

La comprensión y la gestión de los requisitos para la práctica de la arquitectura
es crucial. Los requisitos deben estar claramente articuladas y se alinean con la
visión práctica de la arquitectura.

  Página 571 de 670 

TOGOF 9.1    

  

47. Architecture Board

Contenido del capítulo 
47.1 Rol | 47.2 Responsabilidades | 47.3 Configuración de la Junta de Arquitectura 
| 47.4  Funcionamiento del Consejo de Arquitectura 

Este capítulo proporciona directrices para el establecimiento y funcionamiento de

un Consejo de Arquitectura Empresarial.

47.1 Papel
Un elemento clave para una estrategia exitosa de gobernabilidad arquitectura (ver
50. Arquitectura de Gobierno ) es una Junta de Arquitectura de toda la organización
para supervisar la implementación de la estrategia. Este órgano debe ser
representativa de todos los actores clave en la arquitectura, y comprenderá
normalmente un grupo de ejecutivos responsables de la revisión y el mantenimiento
de la arquitectura general. Arquitectura Boards pueden tener, o alcance la línea de
negocio global, regional. Sobre todo en las grandes empresas, Arquitectura Juntas
están compuestas normalmente por representantes de la organización en un mínimo de
dos niveles:
Local (expertos en el dominio, la responsabilidad de línea)  Mundial (la
responsabilidad de toda la organización) 

En tales casos, cada tabla se establecerá con identificable y articulado:

Responsabilidades y capacidades de toma de decisiones  Límites de mandato y
autoridad 

47.2 Responsabilidades
La Junta de Arquitectura se hace típicamente responsable y rendir cuentas, para
lograr algunos o todos de los siguientes objetivos:
Proporcionar la base para todas las decisiones con respecto a las arquitecturas 
Coherencia entre los sub-arquitecturas  El establecimiento de objetivos para la
reutilización de los componentes  La flexibilidad de la arquitectura de la
empresa: 

  Página 572 de 670 

TOGOF 9.1    
o para satisfacer las cambiantes necesidades del negocio  o Para aprovechar las
nuevas tecnologías  Ejecución de Arquitectura de Cumplimiento  Mejorar el nivel de
madurez de la arquitectura la disciplina dentro de la organización  Asegurarse de
que se adopte la disciplina de desarrollo basado en la arquitectura  El apoyo a una
capacidad de escalada visible para las decisiones fuera de los límites 

Otras responsabilidades de una perspectiva operacional deben incluir:

Todos los aspectos de seguimiento y control del Contrato Arquitectura  Reunión
sobre una base regular  Asegurar la gestión y la aplicación efectiva y coherente de
las arquitecturas  Resolución de ambigüedades, problemas o conflictos que han sido
escalados  Prestar asesoramiento, orientación e información  Asegurar el
cumplimiento de las arquitecturas, y la concesión de las dispensas que están en
consonancia con la estrategia y objetivos de la tecnología  Teniendo en cuenta la
política (calendario, Acuerdos de Nivel de Servicio (SLAs), etc) cambia cuando se
solicitan y otorgan dispensas similares; por ejemplo, la nueva forma de requisitos
de servicio  Garantizar que toda la información pertinente para la aplicación del
Contrato de Arquitectura se publica bajo condiciones controladas y transmitirse a
las partes autorizadas  La validación de los niveles de servicio reportados, ahorro
de costes, etc 

Desde la perspectiva de la gobernabilidad, la Junta de Arquitectura también es

responsable de:
La producción de materiales y actividades de gobernanza utilizable  Proporcionar un
mecanismo para la aceptación formal y la aprobación de la arquitectura a través del
consenso y la publicación autorizada  Proporcionar un mecanismo de control
fundamental para asegurar la aplicación efectiva de la arquitectura  Establecer y
mantener el enlace entre la aplicación de la arquitectura, la estrategia de
arquitectura y los objetivos plasmados en la arquitectura de la empresa, así como
los objetivos estratégicos del negocio  La identificación de divergencia con
respecto a las actividades de la arquitectura y de planificación para la
reestructuración a través de dispensaciones o actualizaciones de la política 

  Página 573 de 670 

TOGOF 9.1    

47.3 Configuración Up Architecture Board

47.3.1 Los disparadores

Uno o más de los siguientes sucesos desencadena normalmente el establecimiento de

un Consejo de Arquitectura:
Nuevo CIO  Fusión o adquisición  Examen de un traslado a las nuevas formas de la
informática  Reconocimiento de que es mal alineado al negocio  El deseo de lograr
una ventaja competitiva a través de la tecnología  Creación de un programa de
arquitectura de la empresa  El cambio de negocios importante o un rápido
crecimiento  Requisitos para las soluciones complejas, multi-funcionales 

En muchas empresas, el patrocinador ejecutivo del esfuerzo inicial de la

arquitectura es el CIO (u otro alto ejecutivo). Sin embargo, para obtener un amplio
apoyo de las empresas, un organismo que patrocina tiene más influencia. Este
organismo patrocinador se llama aquí un Consejo de Arquitectura, pero el título no
es importante.Sea cual sea el nombre, es el grupo de nivel ejecutivo responsable de
la revisión y mantenimiento de la arquitectura estratégica y todos sus sub-
arquitecturas. La Junta de Arquitectura es el patrocinador de la arquitectura
dentro de la empresa, sino que el propio Consejo de Arquitectura necesita un
patrocinador ejecutivo del más alto nivel de la corporación. Este compromiso debe
abarcar el proceso de planificación y continuará en la fase de mantenimiento del
proyecto de arquitectura. En muchas empresas que fracasan en un esfuerzo
planificación de la arquitectura, hay una notable falta de participación ejecutiva
y aliento para el proyecto. Una fuente pasa por alto con frecuencia de los miembros
de la Junta de Arquitectura es la Junta Directiva de la empresa. Estas personas
siempre tienen diversos conocimientos sobre la empresa y su competencia. Debido a
que tienen un impacto significativo en la visión y los objetivos de negocio, pueden
tener éxito en la validación de la armonización de las estrategias de TI con los
objetivos empresariales.
47.3.2 Tamaño de la Junta

El tamaño recomendado para una Junta de Arquitectura es de cuatro o cinco años (y

no más de diez) miembros permanentes.
  Página 574 de 670 

TOGOF 9.1    

Con el fin de mantener el Consejo de Arquitectura de un tamaño razonable, al tiempo

que garantiza la representación de toda la empresa en la que con el tiempo,
miembros de la Junta de Arquitectura se puede girar, dando privilegios y
responsabilidades de toma de decisiones a diversos altos directivos. Esto puede ser
necesario en cualquier caso, debido a que algunos miembros de la Junta de
Arquitectura de la búsqueda de que las limitaciones de tiempo a prevenir la
participación activa a largo plazo. Sin embargo, una cierta continuidad debe
existir en el Consejo de Arquitectura, para evitar que la arquitectura corporativa
de la variación de un conjunto de ideas a otro. Una técnica para asegurar la
rotación con continuidad es tener términos establecidos para los miembros, y para
tener los términos expiran en diferentes momentos. En el proceso de arquitectura en
curso tras el esfuerzo inicial de la arquitectura, la Junta de Arquitectura se
puede volver a alquilar. El patrocinador ejecutivo revisará normalmente la labor de
la Junta de Arquitectura y evaluar su eficacia; si es necesario, el proceso de
revisión de Arquitectura de Cumplimiento está actualizado o modificado.
Estructura Junta 47.3.3

El Marco de Gobierno TOGAF Arquitectura (ver 50.2 Arquitectura Governance Framework

) proporciona un marco de organización genérica que posiciona a la Junta de
Arquitectura en el marco de las estructuras de gobierno más amplios de la empresa.
Esta estructura identifica los principales grupos y las responsabilidades de
organización, así como la relación entre cada grupo. Se trata de una estructura de
las mejores prácticas, y puede estar sujeto a cambio dependiendo de la forma de la
organización y las estructuras existentes. Hay que prestar atención al tamaño de la
organización, su forma, y cómo las funciones de TI se implementan. Esto
proporcionará la base para diseñar la estructura Architecture Board en el contexto
del entorno general de gobierno. En particular, se debe considerar que el concepto
de propiedad global y la implementación local, y la integración de nuevos conceptos
y tecnologías de todas las áreas de aplicación correspondientes arquitecturas. La
estructura de la Junta de Arquitectura debe reflejar la forma de la organización.
La estructura de gobierno de la arquitectura requerida y puede ir más allá de las
estructuras genéricas descritas en el Marco de Gobierno TOGAF Arquitectura (ver
50.2 Arquitectura del marco de la gobernanza ). La organización puede necesitar
para definir una combinación del proceso de gobernanza de la TI en su lugar y las
estructuras y capacidades organizacionales existentes, que suelen incluir los
siguientes tipos de cuerpo:
Junta de gobierno Global  Junta de Gobierno Local  Autoridades de Diseño  Grupos de
trabajo 

  Página 575 de 670 

TOGOF 9.1    
47.4 El funcionamiento del Consejo de Arquitectura
En esta sección se describe el funcionamiento de la Junta de Arquitectura de todo
desde la perspectiva de gobierno.
47.4.1 general

Reuniones de Arquitectura de la Junta deben llevarse a cabo dentro de las agendas

claramente identificados con los objetivos explícitos, la cobertura de contenidos y
acciones definidas. En general, las reuniones de la junta estarán alineados con las
mejores prácticas, tal como se da en el marco COBIT (ver 50.1.4.1 Un Controles de
TI Marco - COBIT ). Estas reuniones brindarán dirección clave:
Apoyo a la producción de materiales y actividades de gobernanza de calidad 
Proporcionar un mecanismo para la aceptación formal a través del consenso y la
publicación autorizada  Proporcionar un mecanismo de control fundamental de velar
por la aplicación efectiva de las arquitecturas  Establecer y mantener el enlace
entre la aplicación de las arquitecturas y la estrategia y objetivos de la
organización se indica (de negocios y de TI)  La identificación de la divergencia
de las actividades contractuales y de planificación para realinear con el contrato
a través de dispensaciones o actualizaciones de la política 

47.4.2 Preparación

Cada participante recibirá una agenda y la documentación de apoyo - por ejemplo,

las solicitudes de exención, los informes de gestión del rendimiento, etc - y se
espera que esté familiarizado con el contenido de cada uno. Cuando las acciones se
han asignado a un individuo, es responsabilidad de la persona que informe sobre los
avances en contra de estos. Cada participante debe confirmar su disponibilidad y la
asistencia a la reunión de Junta de Arquitectura.
47.4.3 del orden del día

En esta sección se describe el contenido de un programa de la reunión Architecture

Board. Cada tema del programa se describe en términos de sólo su contenido.
Acta de la reunión anterior

  Página 576 de 670 

TOGOF 9.1    

Minutos contienen los detalles de la anterior reunión Architecture Board según el

protocolo estándar de la organización.
Las solicitudes para el Cambio

Los artículos de este capítulo están normalmente cambian las solicitudes de

modificación de las arquitecturas, principios, etc, pero también pueden incluir el
control de las empresas respecto a la arquitectura de Contratos; por ejemplo,
asegurarse de que el tráfico de voz a números de tarificación adicional, como
informes del tiempo, se prohibió el tráfico de datos a ciertos sitios web se
controla. Cualquier solicitud de cambio se realiza dentro de los niveles y
parámetros definidos por el Contrato Arquitectura autoridad acordados.
Dispensaciones

Una dispensación se utiliza como el mecanismo para solicitar un cambio en las

arquitecturas existentes, contratos, principios, etc fuera de los parámetros
normales de operación; por ejemplo, excluye la prestación del servicio a una
filial, solicitud de los niveles de servicio inusuales por motivos de negocio
específicas, implementar la tecnología o los productos no estándar para apoyar las
iniciativas empresariales específicas. Las dispensaciones se conceden por un
periodo de tiempo determinado y un conjunto de servicios identificados y los
criterios operativos que deben ser ejecutadas durante la vida útil de la
dispensación. Las dispensaciones no se otorgan por tiempo indefinido, pero se
utilizan como un mecanismo para asegurar que los niveles de servicio y los niveles
operacionales, etc se cumplen mientras que proporciona una flexibilidad de nivel en
su aplicación y el tiempo. La naturaleza de duración determinada de dispensaciones
asegura que son un disparador para la actividad de Cumplimiento Arquitectura.
Evaluaciones de cumplimiento

El cumplimiento se evalúa a los SLA, Acuerdos de Nivel Operacional (OLA), los

objetivos de costes, y refresca arquitectura requeridas. Estas evaluaciones serán
revisadas y aceptadas o rechazadas en función de los criterios definidos en el
Marco de Gobierno de Arquitectura. El informe de evaluación Arquitectura
Cumplimiento incluirá detalles como se describe.
Resolución de Disputas

Las controversias que no han sido resueltos a través de la arquitectura de

cumplimiento y los procesos de dispensación se identifican aquí para más acción y
se documentan a través de las evaluaciones de cumplimiento Arquitectura y
documentación dispensación.
Arquitectura Estrategia y Dirección de Documentación

  Página 577 de 670 

TOGOF 9.1    

Este describe las estrategias de la arquitectura, la dirección y las prioridades y

sólo será formulada por el Consejo de Arquitectura global. Se debe tomar la forma
de documentación de arquitectura estándar.
Acciones de Asignación

Se trata de un informe sobre las acciones asignadas en anteriores reuniones de la

Junta de Arquitectura. Un rastreador de acción se utiliza para documentar y
mantener el estado de todas las acciones asignadas durante las reuniones de la
Junta de Arquitectura y debe consistir de por lo menos la siguiente información:
Referencia  Prioridad  Descripción Acción  Propietario Acción  Información de la
acción  Fecha planteado  Fecha de vencimiento  Estado  Tipo  Fecha de Resolución 
Gestión de la Documentación del Contrato

Se trata de una aceptación formal de las actualizaciones y cambios a la

documentación de la arquitectura para su publicación en adelante.
Otros asuntos (AOB)

Descripción de las cuestiones que no están directamente cubiertos por alguno de los
anteriores. Estos no pueden ser descritos en el orden del día, sino que deben ser
planteadas al comienzo de la reunión. Toda la documentación necesaria se debe
manejar de acuerdo toda la documentación de la gobernanza de la arquitectura.
Calendario de reuniones

Toda reunión Fechas de detalle debe ser detallada y publicada.

  
  Página 578 de 670 

TOGOF 9.1    

  

4. Arquitectura Cumplimiento
Contenido del capítulo 
48.1 Introducción | 48.2 Terminología: El significado de la Arquitectura Cumplimien
to | 48.3 
Arquitectura Cumplimiento Opiniones | Proceso de Revisión de Cumplimiento 48.4 
Arquitectura | Arquitectura 48.5 Revisión de Cumplimiento Listas de comprobación | 
Directrices  48.6 Arquitectura de Revisión de Cumplimiento 

Este capítulo proporciona directrices para asegurar el cumplimiento del proyecto a

la arquitectura.

48.1 Introducción
Garantizar el cumplimiento de los proyectos individuales con la arquitectura de la
empresa es un aspecto esencial de la gobernabilidad arquitectura (véase
50.Arquitectura de Gobierno ). Con este fin, la función de gobierno de TI dentro de
una empresa normalmente se definen dos procesos complementarios:
La Arquitectura función se requiere para preparar una serie de arquitecturas de
Proyecto; es decir, puntos de vista específicos del proyecto de la arquitectura
empresarial que ilustran cómo los impactos de arquitectura empresarial en los
principales proyectos de la organización. (ver Fases ADM de A a F)  El IT
Governance función será definir un proceso de revisión formal de Arquitectura de
Cumplimiento (véase 48.3 Comentarios Arquitectura de cumplimiento ) para revisar el
cumplimiento de los proyectos a la arquitectura de la empresa. 

Además de la definición de procesos formales, el gobierno arquitectura (ver 50.

Arquitectura de Gobierno ) función también puede estipular que la función de la
arquitectura debe extenderse más allá de la función de la definición de la
arquitectura y la selección de las normas, y participar también en el proceso de
selección de la tecnología, e incluso en el comercial relaciones involucradas en la
provisión de servicios y productos de las compras externas. Esto puede ayudar a
minimizar la posibilidad de una mala interpretación de la arquitectura de la
empresa y maximizar el valor de la negociación comercial centralizada.

48.2 Terminología: El significado de la Arquitectura de Cumplimiento

Una relación clave entre la arquitectura y la implementación se encuentra en las
definiciones de los términos "conformes", "conforme", etc Si bien el uso de la
terminología puede diferir entre las organizaciones, los conceptos de niveles de
conformidad se ilustran en la Figura 48-1 puede ser muy útil en la formulación de
una estrategia de cumplimiento de TI.
  Página 579 de 670 

TOGOF 9.1    

 
Figura 48‐1: Niveles de Arquitectura Conformidad 

La frase "de conformidad con" en la figura 48-1 significa:

Apoya la estrategia declarada y direcciones futuras  Se adhiere a los estándares
establecidos (incluida la sintaxis y las reglas semánticas especificadas) 
Proporciona la funcionalidad declarado  Se adhiere a los principios enunciados; por
ejemplo:  o donde sea abierto posible y adecuado  o reutilización de bloques de
construcción de los componentes siempre que sea posible y apropiado 

  Página 580 de 670 

TOGOF 9.1    

48.3 Comentarios Arquitectura Cumplimiento

Una revisión de Cumplimiento La arquitectura es un examen de la conformidad de un
proyecto específico en función de criterios establecidos de arquitectura, el
espíritu y los objetivos de negocio. Un proceso formal para esos exámenes
normalmente se forma el núcleo de una estrategia de cumplimiento de arquitectura
empresarial.
48.3.1 Propósito

Los objetivos de la revisión de Cumplimiento Arquitectura incluyen algunos o todos

de los siguientes:
En primer lugar, detectar errores en la arquitectura temprana del proyecto, y por
lo tanto reducir el costo y el riesgo de los cambios requeridos más adelante en el
ciclo de vida. Esto a su vez significa que el tiempo total del proyecto se acorta,
y que la empresa obtiene el beneficio línea de fondo del desarrollo de la
arquitectura más rápido.  Velar por la aplicación de las mejores prácticas para el
trabajo de la arquitectura.  Proporcionar una visión general del cumplimiento de
una arquitectura de estándares de la empresa por mandato.  Identificar dónde las
propias normas pueden exigir modificaciones.  Identificar los servicios que están
actualmente específica de la aplicación, pero podrían ser incluidos como parte de
la infraestructura de la empresa.  Estrategias de Documentos para la colaboración,
el intercambio de recursos y otras sinergias a través de múltiples equipos de
arquitectura.  Tome ventaja de los avances tecnológicos.  Comunicar a la gestión de
la situación de la disponibilidad técnica del proyecto.  Identificar criterios
clave para las actividades de adquisición (por ejemplo, para su inclusión en los
documentos comerciales el producto RFI / RFP Off-The-Shelf (COTS)).  Identificar y
comunicar deficiencias arquitectónicas significativas de productos y proveedores de
servicios. 

Además de los objetivos generales relacionados con la garantía de calidad se ha

señalado, existen motivaciones adicionales, orientación política más para la
realización de Arquitectura Las revisiones de cumplimiento, que pueden ser
relevantes en casos particulares:
La revisión de cumplimiento La arquitectura puede ser una buena manera de decidir
entre alternativas de arquitectura, ya que los tomadores de decisiones que suelen
participar en la revisión pueden guiar las decisiones en términos de lo que es
mejor para el negocio, en lugar de lo que es técnicamente más agradable o
elegante. 

  Página 581 de 670 

TOGOF 9.1    
La salida de la revisión de Cumplimiento La arquitectura es una de las pocas
entregas cuantificables para el CIO para ayudar en la toma de decisiones. 
Arquitectura opiniones pueden servir como una manera para que la organización
Arquitectura para colaborar con los proyectos de desarrollo que de otro modo
podrían avanzar sin la participación de la función de la arquitectura. 
Arquitectura opiniones pueden demostrar un apoyo rápido y positivo a la comunidad
de negocios de la empresa:  o La arquitectura de la empresa y Arquitectura
Cumplimiento ayuda a asegurar la alineación de los proyectos de TI con los
objetivos empresariales.  o arquitectos a veces puede ser considerado como
profundamente en infraestructura técnica y alejada de la actividad principal.  o
Desde una revisión de cumplimiento Arquitectura tiende a mirar sobre todo a las
zonas de riesgo críticos de un sistema, a menudo se destacan los principales
riesgos para los propietarios de los sistemas. 

Si bien se requiere el cumplimiento de la arquitectura para el desarrollo y

ejecución, el incumplimiento también proporciona un mecanismo para poner de
relieve:
Áreas que deben abordarse para el reajuste  Temas para estudiar para su integración
en las arquitecturas, ya que están al descubierto por los procesos de cumplimiento 

Este último punto identifica el cambio continuo y la adaptabilidad de las

arquitecturas de los requisitos que se puedan conducir por indisciplina, pero
también permite que los cambios se registran por los cambios rápidos en movimiento
en el entorno operacional. Típicamente dispensas (véase 50.1.4 IT Governance ) se
utilizarán para poner de relieve estos cambios y poner en marcha un proceso para
registrar, monitorear y evaluar la idoneidad de los cambios necesarios.
48.3.2 El tiempo

El momento de las actividades de cumplimiento debe ser considerado en relación con

el desarrollo de las propias arquitecturas. Las revisiones de cumplimiento se
llevan a cabo en los hitos o puntos de control de proyectos apropiados en el ciclo
de vida del proyecto. puestos de control específicos debe incluirse la siguiente
manera:
El desarrollo de la propia arquitectura (cumplimiento ADM)  La implementación de la
arquitectura (s) (arquitectura cumplimiento) 

Arquitectura tiempos de proyectos para las evaluaciones deben incluir:

  Página 582 de 670 

TOGOF 9.1    
Inicio del proyecto  Diseño inicial  Los principales cambios en el diseño  Ad hoc 

La revisión de cumplimiento Arquitectura normalmente está dirigida a un punto en el

tiempo cuando los requerimientos del negocio y la arquitectura de la empresa son
razonablemente firme, y la arquitectura del proyecto está tomando forma, mucho
antes de su finalización. El objetivo es llevar a cabo la revisión lo antes
posible, en una etapa en que todavía hay tiempo para corregir los errores o
deficiencias importantes, con la condición obvia que no necesita haber sido algún
desarrollo importante de la arquitectura del proyecto con el fin de que exista ser
algo a revisar. Las entradas a la revisión de Cumplimiento Arquitectura pueden
venir de otras partes del ciclo de vida del proyecto de norma, el cual puede tener
un impacto en el tiempo.
48.3.3 Gobernabilidad y Escenarios de personal

En cuanto a la gobernanza y la realización del examen de cumplimiento de

Arquitectura, y el personal involucrado, hay varios escenarios posibles:
Para proyectos de menor escala, el proceso de revisión podría simplemente tomar la
forma de una serie de preguntas que los arquitectos del proyecto o de los líderes
del proyecto representan a sí mismos, utilizando las listas de verificación que
aparecen a continuación, tal vez el cotejo de las respuestas en alguna forma de
informe del proyecto a la gerencia. La necesidad de llevar a cabo un proceso de
este tipo se incluye normalmente en las políticas generales de gobierno de TI en
toda la empresa.  Cuando el proyecto que se examina no ha implicado una práctica o
arquitecto a tiempo completo hasta la fecha (por ejemplo, en un proyecto de nivel
de aplicación), el propósito de la revisión es típicamente para hacer valer la
experiencia arquitectónica de una función de la arquitectura empresarial. En tal
caso, la función de la arquitectura empresarial iba a organizar, dirigir y llevar a
cabo la revisión, con la participación de expertos en los sectores de negocios. En
tal escenario, la revisión no es un sustituto de la participación de los
arquitectos en un proyecto, pero puede ser un complemento o una guía para su
participación. Es probable que sea necesaria una base de datos para manejar el
volumen de datos que se producirían en el análisis de un gran sistema o conjunto de
sistemas.  En la mayoría de los casos, sobre todo en proyectos de mayor
envergadura, la función de la arquitectura se han estado profundamente involucrado
en, y tal vez conduzca, el proyecto de desarrollo que se examina. (Este es el
escenario típico TOGAF.) En tales casos, la revisión será coordinado por el
arquitecto de la empresa principal, que reunirá un equipo de expertos en negocios y
dominio técnico para la revisión, y compilar las respuestas a las preguntas
formuladas durante la la revisión en alguna forma de informe. Las preguntas suelen
plantearse durante el examen por los expertos en negocios

  Página 583 de 670 

TOGOF 9.1    
y dominio técnico. Por otra parte, la revisión podría ser dirigido por un
representante de una Junta de Arquitectura o algún organismo similar en las
responsabilidades de toda la empresa. 

En todos los casos, el proceso de revisión de Cumplimiento Arquitectura necesita el

respaldo de la alta dirección, y normalmente se encargó como parte de las políticas
de gobierno corporativo de arquitectura (ver 50. Arquitectura de Gobierno ).
Normalmente, la empresa CIO o empresa Architecture Board (ver 47. Arquitectura
Board ) dará un mandato opiniones arquitectura para todos los proyectos, con
posteriores revisiones anuales.

48.4 Proceso de Arquitectura de Revisión de Cumplimiento

48.4.1 Información general

El proceso de revisión de Arquitectura cumplimiento se ilustra en la Figura 48-2 .

 
Figura 48‐2: Proceso Arquitectura Revisión de Cumplimiento 

48.4.2 Roles

Los papeles principales en el proceso se tabulan a continuación.

  

No. Papel Responsabilidades 1 Architecture Para asegurarse de que las Board

arquitecturas de TI son consistentes y apoyar las necesidades generales de la
 

Notas Patrocinador y supervisar las actividades de arquitectura.

Página 584 de 670 

TOGOF 9.1    

2 Líder del Proyecto (o Junta del Proyecto) 3 Architecture Review Coordinador 4

empresa. Responsable de todo el proyecto.

5 6

Para administrar todo el proceso Más probabilidades de de desarrollo de la

arquitectura y ser orientado a los la revisión. negocios de orientación
tecnológica. Enterprise Para asegurarse de que la Un especialista en Architect
arquitectura es técnicamente arquitectura de TI. Lead coherente y a prueba de
futuro. Arquitecto Uno de los asistentes técnicos de la Enterprise Architect plomo.
Cliente Para asegurar que los Gestiona la parte de la requerimientos del negocio
están organización que va a claramente expresados y depender del éxito de la
comprendidos. TI se describe en la arquitectura. Negocios Para asegurar que los
procesos Sabe cómo funciona el dominio para satisfacer los requerimientos dominio
del Expert del negocio se justifican y negocio; También puede ser el cliente.
comprendido. Los Para garantizar que los arquitectos Los miembros de la directores
de tienen una comprensión organización del cliente proyecto suficientemente
detallada de los que tienen entrada a los procesos del departamento de
requerimientos del atención al cliente. Pueden negocio que la proporcionar entrada
al dominio arquitectura es abordar. de expertos de negocios o para los arquitectos.

48.4.3 Pasos

Los principales pasos en el proceso se tabulan a continuación.

  

No. Acción 1 Solicitud arquitectura revisión

Notas Conforme a lo dispuesto por las políticas y procedimientos de gobierno de TI.

¿Quién Cualquier persona, sea o orientada a los negocios, con un interés o

responsabilidad en el área de los negocios

  Página 585 de 670 

TOGOF 9.1    

2 Identificar parte responsable de la organización y los directores de los

proyectos correspondientes. 3 Identificar Enterprise Architect plomo y otros
arquitectos. 4 Determinar el alcance de Identificar qué otras la revisión unidades
de negocio / departamentos están involucrados. Comprender que el sistema se ajuste
en el marco de la arquitectura corporativa. 5 Listas de verificación a Para hacer
frente a los medida. requerimientos del negocio. 6 Horario Arquitectura reunión de
revisión

afectados. Architecture Review Coordinador

Architecture Review Coordinador Architecture Review Coordinador

Enterprise Architect Lead Architecture Review Coordinador con la colaboración de

Enterprise Architect plomo. Lead Enterprise Architect y / o Arquitecto, líder del
proyecto, y los Clientes

7 Directores de proyectos Para obtener Entrevista información básica y técnica:

Para proyecto interno: en persona  Para COTS: en persona o por medio de RFP 

Utilice las listas de comprobación. 8 Analizar las listas de Repase con los
verificación terminados estándares corporativos. Identificar y resolver
 

Enterprise Architect Lead

Página 586 de 670 

TOGOF 9.1    

9 Preparar Arquitectura informe de revisión de cumplimiento 10 Hallazgos de la

revisión Para Clientes Presente Para Architecture Board 11 Acepte revisión y firmar
12 Enviar el informe de evaluación / Resumen de Architecture Review Coordinador

problemas. Determinar recomendaciones. Puede incluir personal Enterprise Architect

de apoyo. Lead Enterprise Architect Lead Architecture Board y el Cliente Enterprise
Architect Lead

48.5 Arquitectura de Revisión de Cumplimiento listas de verificación

Las siguientes listas de control de revisión proporcionan una amplia gama de
preguntas típicas que se pueden utilizar en la realización de Arquitectura Las
revisiones de cumplimiento, en relación con diversos aspectos de la arquitectura.
La organización de las preguntas que incluye las disciplinas básicas de la
ingeniería de sistemas, gestión de la información, seguridad y administración de
sistemas. Las listas de control se basan en material proporcionado por un miembro
de The Open Group, y son específicos para esa organización. Otras organizaciones
pueden utilizar las siguientes listas de verificación con otras preguntas a la
medida de sus necesidades particulares. Las listas de comprobación proporcionadas
contienen demasiadas preguntas para cualquier crítica individual: Tienen el
objetivo de adaptarse de forma selectiva con el proyecto de que se trate (véase
48.6 Arquitectura para la Revisión de Cumplimiento ). Las listas de verificación
efectivamente utilizadas típicamente se desarrollan / seleccionados por expertos en
la materia. Están destinados a ser actualizado anualmente por los grupos de interés
en esas áreas. Algunas de las listas de verificación incluyen una breve descripción
del principio arquitectónico que provoca la pregunta, así como una breve
descripción de lo que debe buscar en la respuesta. Estas extensiones de la lista de
control tienen por objeto permitir que los inteligentes re-fraseo de las preguntas,
y para dar al usuario de la lista de verificación una idea de por qué se hizo la
pregunta. De vez en cuando las preguntas se pueden escribir, como en RFP, o en el
trabajo con un arquitecto superior del proyecto. Más típicamente se expresan
oralmente, como parte de una entrevista o sesión de trabajo con el proyecto.
  Página 587 de 670 

TOGOF 9.1    

Las listas de control que aquí se han diseñado para su uso en proyectos de
arquitectura individuales, no para el dominio de la arquitectura de negocios o de
la arquitectura a través de múltiples proyectos. (Haciendo una revisión de la
arquitectura para una esfera más amplia de la actividad, a través de procesos de
negocio y proyectos de sistemas múltiples, que implicaría un proceso similar, pero
las categorías lista de verificación y sus contenidos serían diferentes.)
48.5.1 Sistema Operativo Hardware y lista de control 1.
¿Cuál es el enfoque del ciclo de vida del proyecto?  2. ¿En qué fase está el
proyecto en su ciclo de vida?  3. ¿Qué cuestiones clave han sido identificados ni
analizados que el proyecto cree que va a
conducir evaluaciones de hardware y sistemas operativos para redes, servidores y
dispositivos de usuario final? 

4. ¿Qué capacidades del sistema implicará gran volumen y / o transferencias de

datos de alta frecuencia?  5. ¿De qué manera el impacto del diseño del sistema o
implican dispositivos de usuario final?  6. ¿Cuál es la cantidad y la distribución
(regional y mundial) de uso, almacenamiento de datos y el procesamiento?  7. ¿Qué
aplicaciones tienen afinidad con su proyecto por las similitudes en los datos,
servicios de aplicaciones, etc? ¿Hasta qué punto está de datos affinitized con su
proyecto? 

8. ¿Qué opciones de hardware y sistemas operativos se han realizado antes del

diseño funcional de los elementos clave del sistema?  9. Si se toman las decisiones
de hardware y sistema operativo fuera del control del proyecto: 
o o Lo que la conciencia tiene el proyecto de la justificación de esas decisiones? 
¿Cómo puede influir en el proyecto aquellas decisiones que el diseño del sistema se
concreta? 

10. Si se han elegido algunos no estándares: 

o ¿Cuáles son los requisitos de negocio y técnicas esenciales para no utilizar las
normas corporativas?  ¿Es compatible con un modelo de negocio?  Haga que los
supuestos en el caso de negocios sido objeto de escrutinio? 

o o

11. ¿Cuál es su proceso de evaluación de los costes del ciclo de vida completo de
hardware y sistemas operativos?  12. ¿Cómo ha sido la gestión financiera de las
empresas ha dedicado a la evaluación de los costes del ciclo de vida?  13. ¿Ha
realizado un análisis financiero de la empresa?    Página 588 de 670 

TOGOF 9.1     14. ¿Ha hecho compromisos con ningún proveedor?  15. ¿Cree usted que
sus necesidades pueden ser satisfechas por un solo proveedor?  48.5.2 Servicios
de Software y Middleware Checklist 1. Describir cómo se definen
las condiciones de error, criados, y se propagan entre los componentes de la
aplicación.  2. Describe el patrón general de cómo se definen y se disponen en
varios módulos de aplicación métodos.  3. Describe el patrón general de cómo se
definen y organizan en varios módulos de
aplicación los parámetros del método. Son [en], [in / out], [out] parámetros
especificados siempre en el mismo orden? ¿Los valores booleanos devueltos por
módulos tienen un resultado consistente? 

4. Describa el enfoque que se utiliza para minimizar el número de viajes de ida y

vuelta entre
cliente y servidor de llamadas, sobre todo para las llamadas fuera de proceso, y
cuando las estructuras de datos complejas están involucrados. 

5. Describir las principales estructuras de datos que se pasan entre los

principales componentes del sistema.  6. Describir los principales protocolos de
comunicación que se utilizan entre los principales componentes del sistema.  7.
Describir las técnicas de cálculo de referencias que se utilizan entre diversos
componentes
del sistema. Describa cualquier arreglo de cálculo de referencias especializadas
que se utilizan. 

8. Describir en qué medida el sistema está diseñado con componentes con estado y
sin estado.  9. Describa cómo y cuándo se guarda el estado de ambos componentes con
estado y sin estado.  10. Describir el grado en que se crean los objetos,
utilizado, y destruido frente reutilizados a través de la agrupación de objetos. 
11. Describir la medida en que el sistema se basa en el roscado o de la sección de
codificación crítico.  12. Describa el enfoque y la documentación interna que se
utiliza internamente en el sistema
para documentar los métodos, los métodos de argumentos, y la funcionalidad del
método. 

13. Describir el proceso de revisión de código que se utilizó para construir el

sistema.  14. Describa la prueba de la unidad que se ha utilizado para probar los
componentes del sistema.  15. Describir la pre-y post-condición de prueba que se
incluye en varios módulos del sistema.  16. Describa la prueba de la afirmación que
se incluye con el sistema.    Página 589 de 670 

TOGOF 9.1     17. ¿Los componentes son compatibles con todos los tipos de
interfaces que necesitan para
apoyar o son ciertas suposiciones hechas sobre qué tipos de componentes llamará a
otros componentes, ya sea en términos de enlaces de lenguaje u otras formas de
cálculo de referencias? 

18. Describir la medida en que necesitan grandes problemas-endian o little-endian

formato de datos que se manejan a través de diferentes plataformas.  19. Describa
si los números o cadenas deben ser manejados de manera diferente a través de
diferentes plataformas.  20. Describa si el software tiene que comprobar de punto
flotante de errores de redondeo.  21. Describir cómo las funciones de fecha y hora
a gestionar fechas a fin de evitar un manejo inadecuado del tiempo y el cálculo de
la fecha o la pantalla.  22. Describir qué herramientas o procesos se han utilizado
para probar el sistema en busca de fugas de memoria, la accesibilidad o la robustez
general.  23. Describir las capas del software de servicios de sistemas. Describir
el número general de
los vínculos entre los principales componentes del sistema. ¿El sistema está
compuesto por una gran cantidad de interfaces de punto a punto o son los mayores
backbones de mensajería utilizado en su lugar? 

24. Describir en qué medida los componentes del sistema están bien imprecisa o
fuertemente acoplados.  25. ¿Qué requisitos necesita el sistema a partir de la
infraestructura en materia de bibliotecas
compartidas, soporte para protocolos de comunicación, equilibrio de carga,
procesamiento de transacciones, la supervisión del sistema, los servicios de
nombres u otros servicios de infraestructura? 

26. Describir cómo los componentes del sistema y del sistema están diseñados para
refactorización.  27. Describir cómo los componentes del sistema o del sistema
dependen de la infraestructura de mensajería común frente a una estructura única de
comunicación punto a punto.  48.5.3 Aplicaciones Listas de verificación
48.5.3.1 Infraestructura (Empresa Productividad) Aplicaciones

1. ¿Existe la necesidad de capacidades que no se ofrecen a través de productos de

aplicación infraestructura estándar de la empresa? Por ejemplo: 
o Colaboración      Uso compartido de aplicaciones  La videoconferencia 
Calendarios  Email 

  Página 590 de 670 

TOGOF 9.1    
o o Gestión de flujo de trabajo  Tramitación de las solicitudes de publicación /
palabra       o o HTML  SGML y XML  Formato de documento portátil  Elaboración
de documentos (formato propietario)  Edición 

Aplicaciones de hoja de cálculo  Aplicaciones de presentación        

Presentaciones de negocios  Imagen  Animación  Vídeo  Sonido  CBT  Navegadores web 

Aplicaciones de gestión de datos      Interfaz de base de datos  La gestión de

documentos  La gestión de datos del producto  Los almacenes de datos / mart 

Aplicaciones de gestión de Programa    Gestión de proyectos  Visibilidad

Programa 

2. Describir los requisitos de negocio para capacidades de aplicaciones de

infraestructura de la empresa, que no son satisfechas por los productos estándar. 
48.5.3.2 Aplicaciones empresariales

1. Son algunas de las capacidades requeridas proporcionado por los productos

estándar que apoyan una o más aplicaciones de línea de negocio? Por ejemplo:   
Página 591 de 670 

TOGOF 9.1    
o Aplicaciones de adquisición de negocios   o Ventas y marketing 

Aplicaciones de ingeniería     Diseño asistido por ordenador  Ingeniería

asistida por ordenador  El análisis matemático y estadística 

Aplicaciones de gestión de proveedores    Gestión de la cadena de suministro 

Customer Relationship Management 

Aplicaciones de fabricación       Planificación de Recursos Empresariales

(ERP)  Manufacturing Execution Systems  La calidad de fabricación  Ingeniería de
procesos de fabricación  Máquina y el control adaptativo 

Aplicaciones de soporte al cliente    Apoyo logístico de avión  Ingeniería de

mantenimiento 

o o o o

Aplicaciones Finanzas  Gente aplicaciones  Instalaciones aplicaciones  Aplicaciones

de sistemas de información         Ingeniería de sistemas  Ingeniería de
software  Herramientas de desarrollo Web  Entornos de desarrollo integrados 
Categorías de ciclo de vida  Categorías funcionales  Categorías de productos
especializados 

  Página 592 de 670 

TOGOF 9.1    
o o o Fabricación asistido por ordenador  habilitación de e-Business  Ingeniería de
procesos de negocios   El control de calidad estadístico 

2. Describir los requisitos del proceso de capacidades de aplicaciones de negocio

que no son satisfechas por los productos estándar. 
Integración 48.5.3.3 Aplicación Enfoque

1. ¿Qué puntos de integración (de procesos de negocio / actividad, aplicaciones,

datos, entorno de computación) son el objetivo de esta arquitectura?  2. ¿Qué
técnicas de integración de aplicaciones se aplicará (objetos de negocio comunes
[ORB], las definiciones de datos estándar [STEP, XML, etc], presentación de la
interfaz de usuario común / desktop)? 

Información 48.5.4 Gestión de listas de verificación

48.5.4.1 Valores de datos

1. ¿Cuáles son los procesos que estandarizan la gestión y uso de los datos?  2.
¿Qué procesos de negocio apoya la entrada y la validación de los datos? Uso de los
datos ?  3. ¿Qué acciones de negocio corresponden a la creación y modificación de
los datos?  4. ¿Qué acciones de negocio corresponden a la supresión de los datos y
se lo considera parte de un registro de negocios?  5. ¿Cuáles son los requisitos de
calidad de los datos requeridos por el usuario de negocios?  6. ¿Qué procesos
existen para apoyar la integridad referencial de los datos y / o normalización? 
48.5.4.2 Definición de Datos

1. ¿Cuáles son el modelo de datos, definiciones de datos, la estructura, y las

opciones de alojamiento de aplicaciones compradas (COTS)?  2. ¿Cuáles son las
normas para la definición y el mantenimiento de los requisitos de datos y diseños
para todos los componentes del sistema de información?  3. Lo repositorio
compartible se utiliza para capturar el contenido del modelo y la información de
apoyo para los datos?  4. ¿Cuál es la definición del modelo de datos físicos
(derivados de modelos de datos lógicos) que se utiliza para diseñar la base de
datos?    Página 593 de 670 

TOGOF 9.1     5. ¿Qué herramientas de desarrollo y software de gestión de datos han

sido seleccionados?  6. Lo que los propietarios de los datos se han identificado
como responsable de las
definiciones comunes de datos, eliminando la redundancia no planificada, con
información constantemente confiable, oportuna y precisa, y la protección de datos
por el mal uso y la destrucción?  48.5.4.3 Seguridad / Protección

1. ¿Cuáles son la entidad de datos y atributos reglas de acceso que protegen los
datos de alteraciones no intencionales y no autorizados, divulgación y
distribución?  2. ¿Cuáles son los mecanismos de protección de datos para proteger
los datos contra el acceso externo no autorizado?  3. ¿Cuáles son los mecanismos de
protección de datos para controlar el acceso a los datos de fuentes externas que
tienen residencia temporal interna dentro de la empresa? 
48.5.4.4 Hosting, Tipos de datos, y recursos compartidos

1. ¿Qué es la disciplina de la gestión de datos única de autoridad-como una fuente

lógica con
reglas definidas para la actualización de datos físicas que residen en diferentes
plataformas? 

2. ¿Qué es la disciplina de la gestión de datos replicados, que se deriva de los

datos de autoridad única-operacionales?  3. ¿Qué servidor de nivel de datos se ha
identificado para el almacenamiento de los datos operativos de alto o crítico
medianas?  4. ¿Qué servidor de nivel de datos se ha identificado para el
almacenamiento de tipo C datos operativos?  5. ¿Qué servidor de nivel de datos se
ha identificado para el almacenamiento de datos de apoyo a las decisiones
contenidas en un almacén de datos?  6. ¿Qué Database Management Systems (DBMS) han
puesto en marcha? 
48.5.4.5 Servicios Comunes

1. ¿Cuáles son los servicios normalizados distribuidos de gestión de datos (por

ejemplo,
validación, controles de coherencia, las modificaciones de datos, cifrado y gestión
de transacciones) y de dónde residen?  48.5.4.6 Método de acceso

1. ¿Cuáles son los requisitos de acceso a los datos de archivo estándar, el mensaje
y la gestión de datos?  2. ¿Cuáles son los requisitos de acceso para los datos de
apoyo a las decisiones?    Página 594 de 670 

TOGOF 9.1     3. ¿Cuáles son el almacenamiento de datos y las ubicaciones de lógica

de aplicación?  4. ¿Qué lenguaje de consulta se está utilizando?  48.5.5 Lista
de Verificación de Seguridad 1. Conciencia de Seguridad : ¿Se
ha asegurado que las políticas y directrices a las que
usted está diseñando seguridad corporativa son las últimas versiones? ¿Ha leído
usted de ellos? ¿Es usted consciente de todos los procesos de cumplimiento de
seguridad informática y la aceptación del riesgo pertinentes? (Entrevistador debe
enumerar todas las políticas y directrices pertinentes.) 

2. Identificación / Autenticación : Diagrama de flujo del proceso de cómo se

identifica a un
usuario para la aplicación y cómo la aplicación autentica que el usuario es quien
dice ser. Proporcionar documentación de apoyo para el diagrama que explica el flujo
de la interfaz de usuario para el servidor (s) aplicación / base de datos y de
vuelta al usuario. ¿Está conforme con las políticas corporativas sobre cuentas,
contraseñas, etc? 

3. Autorización : Proporcionar un flujo de procesos de principio a fin que muestra

cómo un
usuario solicita el acceso a la aplicación, indicando que los controles de
seguridad asociados y separación de funciones. Esto debe incluir la forma en que la
solicitud sea aprobada por el titular de los datos apropiados, cómo se coloca el
usuario en el perfil de la clasificación de nivel de acceso adecuado, ¿cómo se crea
el ID de usuario, la contraseña y el acceso y proporcionar al usuario. También
incluye la forma en que se informa al usuario de sus responsabilidades asociadas
con el uso de la aplicación, dada una copia del contrato de acceso, cómo cambiar la
contraseña, a quién llamar para pedir ayuda, etc 

4. Controles de acceso : Documento de cómo se agregan los IDs de usuario,

contraseñas y
acceso perfiles, cambiar, quitar, y documentados. La documentación debe incluir
quién es responsable de estos procesos. 

5. Sensitive Information Protection : Proporcionar documentación que identifica los

datos
sensibles que requieren protección adicional. Identificar los propietarios de los
datos responsables de estos datos y el proceso que se utiliza para proteger el
almacenamiento, transmisión, impresión y distribución de estos datos. Incluya cómo
se protege el campo / archivo de contraseñas. ¿Cómo se pueden prevenir los usuarios
vean la información confidencial de otra persona? ¿Existen acuerdos con terceros
(socios, proveedores, contratistas, etc) sobre la salvaguardia de la información?
Si es así, ¿cuáles son las obligaciones? 

6. Pistas de auditoría y registros de auditoría : Identificar y cuentas de grupo de

documentos requeridos por los usuarios o el soporte de aplicaciones, incluyendo las
cuentas de grupos de sistema operativo. Identificar y documentar las cuentas
individuales y / o roles que tienen privilegios de superusuario tipo, lo que estos
privilegios son, quién tiene acceso a estas cuentas, cómo se controla el acceso a
estas cuentas, el seguimiento, y se registra y cómo se maneja el cambio de
contraseña y distribución, incluyendo cuentas del sistema operativo. También
identificar los registros de auditoría, que pueden leer los registros de auditoría,
que se modifican los registros de auditoría, que pueden eliminar los registros de
auditoría, y cómo los registros de auditoría queda protegido y almacenado. ¿Es el
ID de usuario oscurecido en las pistas de auditoría? 

7. Consideraciones de acceso externo : ¿La aplicación puede utilizar sólo

internamente? Si no es así, ¿está conforme con los requisitos de acceso externos de
las empresas?    Página 595 de 670 
TOGOF 9.1     Lista de control de gestión del sistema 48.5.6
1. ¿Cuál es la frecuencia de los cambios de software que debe ser
distribuido?  2. ¿Qué herramientas se utilizan para la distribución de software? 
3. Son varias las versiones de software y / o datos permitidos en la producción? 
4. ¿Cuál es la frecuencia de copia de seguridad de los datos de usuario y se espera
el tiempo de restauración?  5. ¿Cómo están las cuentas de usuario creadas y
administradas?  6. ¿Cuál es la estrategia de gestión de licencias de sistema?  7.
Se requieren herramientas de administración del sistema general ¿Qué?  8. Se
requieren herramientas de administración de aplicaciones específicas Qué?  9. Se
requieren herramientas de administración del servicio Lo específicos?  10. ¿Cómo
están de servicio las llamadas recibidas y enviadas?  11. Describa cómo se
desinstala el sistema.  12. Describa el proceso o las herramientas disponibles para
comprobar que el sistema está correctamente instalado.  13. Describir las
herramientas o instrumentos que están disponibles que monitorean la salud y el
rendimiento del sistema.  14. Describir las herramientas o proceso en lugar de que
se pueden usar para determinar dónde se ha instalado el sistema.  15. Describa qué
tipo de registros de auditoría se encuentran en el lugar para capturar la historia
del sistema, sobre todo después de un accidente.  16. Describir las capacidades del
sistema para enviar sus propios mensajes de error para el personal de servicio. 
Sistema 48.5.7 Ingeniería / Arquitectura general listas
de verificación
48.5.7.1 general

1. ¿Qué otras aplicaciones y / o sistemas requieren la integración con el tuyo?  2.

Describir el nivel de integración y estrategia con cada uno.  3. Cómo
geográficamente distribuida es la base de usuarios?  4. ¿Cuál es la importancia
estratégica de este sistema a otras comunidades de usuarios dentro y fuera de la
empresa? 

  Página 596 de 670 

TOGOF 9.1     5. ¿Qué recursos de computación son necesarios para ofrecer un

servicio de sistema para
los usuarios dentro de la empresa? Fuera de la empresa y el uso de los activos
informáticos de la empresa? Fuera de la empresa y el uso de sus propios activos? 

6. ¿Cómo pueden los usuarios fuera del entorno de entrega nativa acceder a sus
aplicaciones y datos?  7. ¿Cuál es la esperanza de vida de esta solicitud?  8.
Describir el diseño que se adapta a los cambios en la base de usuarios, datos
almacenados y la tecnología del sistema de entrega.  9. ¿Cuál es el tamaño de la
base de usuarios y su nivel de rendimiento esperado?  10. ¿Qué rendimiento y
técnicas de las pruebas de tensión se utilizan?  11. ¿Cuál es la organización
general de los componentes de software y de datos?  12. ¿Qué es el servicio y la
configuración del sistema en general?  13. ¿Cómo son el software y los datos
configurados y asignan a la configuración del servicio y el sistema?  14. ¿Qué se
necesita tecnología propietaria (hardware y software) para este sistema?  15.
Describa cómo todos y cada versión del software puede ser reproducido y re-
desplegarse en el tiempo.  16. Describir la actual base de usuarios y cómo se
espera que la base de cambiar en los próximos tres a cinco años.  17. Describir la
distribución geográfica actual de la base de usuarios y cómo se espera que la base
de cambiar en los próximos tres a cinco años.  18. Describir la forma en que muchos
usuarios actuales o futuros deben utilizar la aplicación con carácter móvil o que
necesitan para trabajar fuera de línea.  19. Describir lo que la aplicación general
lo hace, los componentes principales de la aplicación, así como los principales
flujos de datos.  20. Describir la instrumentación incluido en la aplicación que
permite la salud y el rendimiento de la aplicación a monitorizar.  21. Describir la
justificación de negocio para el sistema.  22. Describir las razones para escoger
el lenguaje de desarrollo del sistema frente a otras
opciones en términos de costo inicial de desarrollo en comparación con los costes
de mantenimiento a largo plazo. 

23. Describir el proceso de análisis de sistemas que se utilizó para llegar a la

fase de la arquitectura del sistema y la selección de productos de la arquitectura
del sistema.  24. Quién además del cliente original puede tener un uso para o
beneficiarse del uso de este sistema?    Página 597 de 670 

TOGOF 9.1     25. ¿Qué porcentaje de los usuarios utilizan el sistema en modo de

exploración frente a modo de actualización?  26. ¿Cuál es la duración típica de las
solicitudes que son transaccional?  27. ¿Es necesario la entrega de datos
garantizada o actualización, o ¿El sistema tolera el fracaso?  28. ¿Cuáles son los
requisitos de tiempo de hasta del sistema?  29. Describa en donde la arquitectura
del sistema se adhiere o no se adhiere a los estándares.  30. Describir el enfoque
de la planificación y el análisis de proyectos utilizado en el proyecto. 
48.5.7.2 Procesadores / Servidor / Clientes

1. Describir la arquitectura de aplicaciones cliente / servidor.  2. Anotar lo

pictórico para ilustrar donde se ejecuta la funcionalidad de la aplicación. 
48.5.7.3 Client

1. Son funciones distintas de presentación realizadas en el dispositivo de

usuario?  2. Describir la instalación de datos y ayuda proceso que se prestan.  3.
Describa la técnica de navegación con pantalla a pantalla.  4. Describa cómo el
usuario navega entre esta y otras aplicaciones.  5. ¿Cómo es esto y otras
aplicaciones en marcha del dispositivo de usuario?  6. ¿Existen datos entre
aplicaciones y capacidades de uso compartido proceso? Si es así, describir lo que
está siendo compartido y por qué técnica / tecnología.  7. Describir los volúmenes
de datos que se transfieren al cliente.  8. ¿Cuáles son los requisitos adicionales
para el almacenamiento de datos local para apoyar la aplicación?  9. ¿Cuáles son
los requisitos adicionales de software de almacenamiento / memoria local para
apoyar la aplicación?  10. ¿Existen conflictos de hardware / software conocidos o
limitaciones de capacidad
provocadas por otros requisitos de aplicación o situaciones que puedan afectar a
los usuarios de aplicaciones? 

11. Describir cómo el look-and-feel de la capa de presentación se compara con el

look-and-feel de las otras aplicaciones existentes.  12. Describir en qué medida el
cliente necesita para apoyar la comunicación asincrónica y / o sincrónica.   
Página 598 de 670 

TOGOF 9.1     13. Describir cómo se separa la capa de presentación del sistema de

otras capas de cálculo o de transferencia de datos del sistema. 
48.5.7.4 Application Server

1. Can / hacer la capa de presentación y niveles de aplicación se ejecutan en

procesadores separados?  2. Can / hacer la capa de aplicación y la capa de acceso a
datos se ejecutan en procesadores separados?  3. ¿Puede esta aplicación puede
colocar en un servidor independiente de aplicación de todas las demás aplicaciones?
En caso negativo, explique las dependencias.  4. ¿Se pueden agregar fácilmente
servidores de aplicaciones paralelas adicionales? Si es así, ¿cuál es el mecanismo
de equilibrio de carga?  5. ¿Se ha medido la demanda de recursos generados por la
aplicación y lo que es el
valor? Si es así, ¿la capacidad del servidor planeado sido confirmada en los
niveles de aplicación y agregados?  48.5.7.5 Data Server

1. ¿Hay otras aplicaciones que deben compartir el servidor de datos? Si es así,

identificarlos y describir los datos y los requisitos de acceso a datos.  2. ¿Se ha
medido la demanda de recursos generados por la aplicación y lo que es el
valor? Si es así, ¿la capacidad del servidor planeado sido confirmada en los
niveles de aplicación y agregados?  48.5.7.6 COTS (en su caso)

1. Es el proveedor sustancial y estable?  2. ¿La empresa recibirá el código fuente

sobre la desaparición del proveedor?  3. ¿Este software configurado para el uso de
la empresa?  4. ¿Hay datos o procesos que impidan el uso de este software
peculiares de A & D? 
o ¿Es este software disponible en la actualidad? 

5. ¿Se ha utilizado / demostrado para los requisitos de volumen / disponibilidad /

nivel de los servicios similares a los de la empresa? 
o Describir la historia pasada financiera y la cuota de mercado del proveedor. 

Ingeniería del sistema 48.5.8 / Métodos y Herramientas

Lista de verificación 1. ¿Existen indicadores para la actual forma
de hacer negocios?  2. El dueño del sistema ha creado criterios de evaluación que
se utilizarán para orientar el proyecto? Describa cómo se utilizarán los criterios
de evaluación.    Página 599 de 670 

TOGOF 9.1     3. ¿Se ha hecho una investigación de las arquitecturas existentes

para aprovechar el trabajo
ya existente? Describir el método utilizado para descubrir y entender. Se
integrarán las arquitecturas? Si es así, explique el método que se utilizará. 

4. Describir los métodos que se utilizarán en el proyecto: 

o o o o o o o o o o o o Para la definición de las estrategias de negocio  Para
definir las áreas en necesidad de mejorar  Para definir la línea de base y de
destino los procesos de negocio  Para la definición de los procesos de transición 
Para la gestión del proyecto  Para la comunicación del equipo  Para la gestión del
conocimiento, gestión de cambios y gestión de la configuración  Para el desarrollo
de software  Para hacer referencia a las normas y declaraciones de la dirección 
Para asegurar la calidad de los entregables  Para las revisiones de diseño y de la
aceptación entregable  Para capturar las métricas 

5. ¿Los métodos documentados y distribuidos a cada miembro del equipo?  6. ¿En qué
medida son los miembros del equipo estén familiarizados con estos métodos?  7. ¿Qué
procesos existen para garantizar el cumplimiento de los métodos?  8. Describir la
infraestructura que está en su lugar para apoyar el uso de los métodos a través de
la finalización del proyecto y libera previstos. 
o o o o ¿Cómo se ofrece la consulta y resolución de problemas?  ¿Cómo se coordinó
la capacitación?  ¿Cómo son los cambios y las mejoras incorporadas y en cascada? 
¿Cómo son las lecciones aprendidas capturados y comunicados? 

9. ¿Qué herramientas se están utilizando en el proyecto? (Especificar versiones y

plataformas). ¿En qué medida son los miembros del equipo estén familiarizados con
estas herramientas? 

10. Describir la infraestructura que está en su lugar para apoyar el uso de las
herramientas a través de la finalización del proyecto y libera anticipadas? 
o ¿Cómo se ofrece la consulta y resolución de problemas? 

  Página 600 de 670 

TOGOF 9.1    
o o o ¿Cómo se coordinó la capacitación?  ¿Cómo son los cambios y las mejoras
incorporadas y en cascada?  ¿Cómo son las lecciones aprendidas capturados y
comunicados? 

11. Describa cómo el proyecto promoverá la reutilización de sus entregables y

contenido entregable.  12. ¿Los diseños de la arquitectura "en vivo" después de que
el proyecto se ha
implementado? Describa el método que se utilizará para incorporar los cambios de
nuevo en los diseños de la arquitectura. 

13. Se definieron los procesos actuales?  14. Se temas documentados, valorados, y

se asocian a los procesos actuales? Si no, ¿cómo sabes que está reparando algo que
está roto?  15. ¿Estaban / actividades de mejora de procesos existentes o previstas
identificados y
asociados a los procesos actuales? Si no, ¿cómo se sabe que esta actividad no está
en conflicto con o redundante a otras Declaraciones de trabajo? 

16. ¿Tiene métricas actuales? ¿Tiene previsto la métrica? Si no, ¿cómo sabes que
está mejorando algo?  17. ¿Qué procesos va a poner en marcha para recoger, evaluar,
y las métricas de informes?  18. ¿Qué impactos tendrá el nuevo diseño de tener en
los procesos existentes de negocios,
las organizaciones y los sistemas de información? ¿Se han documentado y compartido
con los propietarios? 

48.6 Arquitectura de Cumplimiento para la Revisión

48.6.1 Adaptación de las listas de verificación Centrarse
en: 
o zonas de alto riesgo  o esperados (y emergente) diferenciadores  Para cada
pregunta en la lista de verificación, de entender:  o La pregunta en sí misma  o El
principio detrás de él  o Lo que debe buscar en las respuestas  Pregunte expertos
en el tema para sus puntos de vista  Fijar las preguntas la lista de verificación
para su uso  Tenga en cuenta la necesidad de información a la Junta de
Arquitectura 

  Página 601 de 670 

TOGOF 9.1     48.6.2 Realización de Arquitectura revisiones de

cumplimiento
Comprender claramente los objetivos de quienes solicitan la revisión; y mantenerse
en el camino y entregar lo que se le pide. Por ejemplo, por lo general quieren
saber lo que está bien o mal con el sistema que se está con arquitectura; no lo que
está bien o mal en la metodología de desarrollo utilizada, su propia estructura de
gestión, etc Es fácil de conseguir fuera de la pista y discutir temas que son
interesantes y tal vez valga la pena, pero no lo que se solicitó. Si usted puede
arrojar luz y conocimiento sobre los enfoques técnicos, pero la discusión no es
necesaria para la revisión, como voluntario para proporcionar después de la
revisión.  Si se hace evidente durante el debate que hay otras cuestiones que deben
abordarse, que están fuera del alcance de la revisión solicitada, tocar el tema con
el presidente de la reunión después. Un plan para resolver los problemas puede ser
desarrollado de acuerdo con su grado de gravedad.  Stay "científica". En lugar de:
"Nos gusta ver grandes bases de datos hospedadas en ABC en lugar de XYZ . ", dicen
cosas como: "El tiempo de inactividad asociado con XYZ entornos de bases de datos
es mucho mayor que en el ABC . entornos de bases de datos tanto no recomendamos
hospedaje tipo M y Nsistemas de un XYZ medio ambiente. "  Haga preguntas
"abiertas"; es decir, preguntas que no suponen una respuesta en particular.  A
menudo hay "agendas ocultas" o cuestiones controvertidas entre quienes solicitan
una revisión, que probablemente no sabrá por adelantado. Un enfoque despersonaliza
a los debates puede ayudar a cerrar las brechas de opinión en lugar de agravarlos. 
Trate a los que están siendo entrevistados con respeto. Puede que no hayan
incorporado el sistema "como debe ser", pero probablemente lo hizo lo mejor que
pudo, dadas las circunstancias que se colocan pulg  Ayuda el ejercicio se convierta
en una experiencia de aprendizaje para usted y los presentadores.  Las revisiones
deben incluir actividades de evaluación detalladas contra las arquitecturas y deben
asegurarse de que los resultados se almacenan en la empresa Continuum. 

  Página 602 de 670 

TOGOF 9.1    

  

49. Contratos de Arquitectura

Este capítulo proporciona directrices para la definición y el uso de Arquitectura
Contratos.

49.1 Papel
Arquitectura contratos son los acuerdos conjuntos entre los socios de desarrollo y
los patrocinadores de los entregables, la calidad y la aptitud para el propósito
deuna arquitectura . La implementación exitosa de estos acuerdos será entregado a
través de la gobernanza arquitectura eficaz (véase 50. Arquitectura de
Gobierno ).Mediante la implementación de un enfoque regido a la gestión de los
contratos, lo siguiente será garantizada:
Un sistema de monitoreo continuo para comprobar la integridad, los cambios, la toma
de decisiones, y la auditoría de todas las actividades relacionadas 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
los riesgos en todos los aspectos del desarrollo y la implementación de la
arquitectura (s) que cubre el desarrollo interno contra las normas aceptadas,
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 un entorno resistente  Un conjunto de procesos y prácticas que garanticen
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 ámbito de la arquitectura bajo el gobierno de este órgano 

El Contrato Arquitectura tradicional es un acuerdo entre el patrocinador y la

función de la arquitectura o IS departamento. Sin embargo, cada vez más servicios
están siendo proporcionados por los integradores de sistemas, proveedores de
aplicaciones y los proveedores de servicios, coordinados a través de la función de
la arquitectura o IS departamento. Por tanto, existe una necesidad de un Contrato
de Arquitectura de establecer acuerdos conjuntos entre todas las partes
involucradas en el desarrollo de la arquitectura y el parto. Arquitectura contratos
pueden ocurrir en diferentes etapas del Método de Desarrollo de Arquitectura (ADM);
por ejemplo:

  Página 603 de 670 

TOGOF 9.1    
La Declaración de Arquitectura de Trabajo creado en la Fase A de
la parte II: Arquitectura  Método de Desarrollo (ADM) es efectivamente un contrato
de Arquitectura entre la organización de la arquitectura y el patrocinador de la
arquitectura de la empresa (o la función de gobierno de TI).  El desarrollo de uno
o más dominios de la arquitectura (de negocios, datos, aplicaciones, tecnología), y
en algunos casos, la supervisión de la arquitectura general de la empresa, puede
contratar a los integradores de sistemas, proveedores de aplicaciones, y / o
proveedores de servicios. Cada uno de estos acuerdos normalmente se regirá por un
contrato de Arquitectura que define las prestaciones, la calidad y la aptitud para
el propósito de la arquitectura desarrollada, y los procesos por los que los socios
en el desarrollo de la arquitectura van a trabajar juntos.  Al inicio de la fase G
(Gobernanza de Implementación), entre la función de la arquitectura y la función de
responsable de la aplicación de la arquitectura de la empresa se define en las
fases anteriores de ADM. Normalmente, este será o bien la función de desarrollo de
sistemas en la empresa, o de un importante contratista a quien se contrata la
obra.  o ¿Qué se está "implementada" en la Fase G del ADM es la arquitectura
general de la empresa. En general, abarca la infraestructura de tecnología (de la
Fase D), y también aquellas aplicaciones empresariales y capacidades de gestión de
datos que se han definido en la arquitectura de aplicaciones y arquitectura de
datos (a partir de la fase C), ya sea porque son de toda la empresa en el ámbito de
aplicación, o porque son estratégicos en términos de negocio, y por lo tanto de
importancia y visibilidad en toda la empresa. Sin embargo, normalmente no incluyen
aplicaciones de negocio no estratégicas, que las unidades de negocio serán
posteriormente desplegar en la parte superior de la infraestructura de la
tecnología que se implementa como parte de la arquitectura de la empresa.  o En las
implementaciones de gran escala, bien puede ser uno de licitación Arquitectura por
el equipo de implementación de un programa de proyectos de implementación.  Cuando
la arquitectura de la empresa ha puesto en práctica (al final de la fase G), un
Contrato de Arquitectura normalmente se elaborará entre la función architecting ( o
la función de gobierno de TI, que subsume la función architecting) y los usuarios
de negocios que posteriormente se construye y la implementación de sistemas de
aplicaciones en el entorno con arquitectura. 

Es importante tener en cuenta en todos los casos en que el objetivo final no es

sólo una empresa de arquitectura, sino una arquitectura empresarial dinámico; es
decir, aquella que permite la evolución flexibles en respuesta a los cambios en los
conductores de tecnología y negocios, sin restricciones innecesarias. El Contrato
de Arquitectura es crucial para permitir una dinámica arquitectura de la empresa y
es clave para que rige la aplicación. Los contenidos típicos de estas tres clases
de Arquitectura Contrato se explican a continuación.

49.2 Contenido
  Página 604 de 670 

TOGOF 9.1     49.2.1 Declaración de Arquitectura de Trabajo

La Declaración de Arquitectura Trabajo se crea como un entregable de la fase A, y

es efectivamente un contrato de Arquitectura entre la organización de la
arquitectura y el patrocinador de la arquitectura de la empresa (o la función de
gobierno de TI, en nombre de la empresa). Los contenidos típicos de una Declaración
de Trabajo de Arquitectura son los definidos en la Parte IV , 36.2.20 Declaración
de Arquitectura de Trabajo .
49.2.2 Contrato entre Arquitectura y Socios de Desarrollo

Esta es una declaración de intención firmada en el diseño y el desarrollo de la

arquitectura de la empresa, o de una parte significativa de la misma, de las
organizaciones asociadas, incluyendo integradores de sistemas, proveedores de
aplicaciones y proveedores de servicios. Cada vez más el desarrollo de uno o más
dominios de la arquitectura (de negocios, datos, aplicaciones, tecnología) puede
ser subcontratada, con la función de la arquitectura de la empresa que proporciona
la supervisión de la arquitectura general de la empresa, y la coordinación y el
control del esfuerzo general. En algunos casos, incluso esta función de supervisión
puede ser contratado, aunque la mayoría de las empresas prefieren mantener que la
responsabilidad principal en la casa. Cualesquiera que sean los detalles de los
acuerdos de contratación externa, los propios arreglos normalmente se rigen por un
contrato de Arquitectura que define las prestaciones, la calidad y la aptitud para
el propósito de la arquitectura desarrollada, y los procesos por los que los socios
en el desarrollo de la arquitectura trabajarán juntos. Contenido típico de un
diseño y desarrollo de contratos de Arquitectura son:
Introducción y antecedentes  La naturaleza del acuerdo  Alcance de la arquitectura 
Arquitectura y estratégicos principios y los requisitos  Los requisitos de
conformidad  Proceso y las funciones de desarrollo y gestión de la Arquitectura 
Medidas arquitectura objetivo  Fases definidas de entregables  Plan de trabajo
conjunto priorizado 

  Página 605 de 670 

TOGOF 9.1    
Ventana de tiempo (s)  Arquitectura de entrega y de negocios métricas 

La plantilla para este contrato normalmente se define como parte de la Fase

Preliminar de la ADM, si no es que ya existe, y el contrato específico se definirá
en la fase adecuada de la ADM, en función de la obra en particular que se está
subcontratado.
49.2.3 Función Contrato entre la arquitectura y los
Usuarios de Negocio

Esta es una declaración firmada de la intención de cumplir con la arquitectura de

la empresa, expedida por los usuarios de negocio de la empresa. Cuando la
arquitectura de la empresa ha puesto en práctica (al final de la Fase F), un
Contrato de Arquitectura normalmente se elaborará entre la función architecting ( o
la función de gobierno de TI, que subsume la función architecting) y los usuarios
de negocios que posteriormente se construye y la implementación de sistemas de
aplicaciones en el entorno con arquitectura. Los contenidos típicos de la
arquitectura de licitación de un negocio de los usuarios son:
Introducción y antecedentes  La naturaleza del acuerdo  Alcance  Requisitos
estratégicos  Entregables Arquitectura que cumplan con los requisitos de negocio 
Los requisitos de conformidad  Arquitectura adoptantes  Ventana de tiempo 
Arquitectura métricas de negocio  Arquitectura de servicios (que incluye el
contrato de nivel de servicio (SLA)) 

Este contrato también se utiliza para administrar los cambios en la arquitectura de

la empresa en la Fase H.

49.3 Relación con la arquitectura de la gobernanza

El documento de la Arquitectura Contrato produce en Fase G de las figuras ADM lugar
destacado en el ámbito de la gobernanza arquitectura, como se explica en la Parte
VII , 50. Arquitectura de Gobierno .

  Página 606 de 670 

TOGOF 9.1    

En el contexto de la gobernanza arquitectura, el Contrato de Arquitectura se

utiliza a menudo como un medio para impulsar el cambio de la arquitectura. Con el
fin de garantizar que el Contrato Arquitectura es eficaz y eficiente, puede ser
necesario introducir en la fase G, los siguientes aspectos de la normativa de
gobierno:
Procesos simples  Autoridad centrado en las personas  Comunicación fuerte  Las
respuestas oportunas y un proceso de escalada efectiva  Apoyo a las estructuras
organizativas  El seguimiento del estado de implementación de la arquitectura 
  Página 607 de 670 

TOGOF 9.1    

  

50. Arquitectura de Gobierno

Este capítulo proporciona un marco y directrices para la gobernanza de la
arquitectura.

50.1 Introducción
En esta sección se describe la naturaleza de la gobernanza, y los niveles de
gobernanza.
50.1.1 Niveles de Gobierno dentro de la empresa

Gobernabilidad Arquitectura es la práctica y la orientación en la que las

arquitecturas empresariales y otras arquitecturas son gestionados y controlados a
nivel de toda la empresa. Gobernabilidad Arquitectura típicamente no funciona de
manera aislada, sino dentro de una jerarquía de las estructuras de gobierno, que,
sobre todo en la empresa más grande, pueden incluir todos los siguientes dominios
distintos con sus propias disciplinas y procesos:
El gobierno corporativo  Gobernabilidad Tecnología  Gobierno de TI  Gobernabilidad
Arquitectura 

Cada uno de estos dominios de gobierno puede existir en diversos niveles

geográficos mundial, regional y local - dentro de la empresa en general. El
gobierno corporativo es, pues, un tema muy amplio, más allá del alcance de un marco
de arquitectura de la empresa, tales como TOGAF. Este y otros apartados se centran
en la gobernanza de arquitectura; pero ellos lo describen en el contexto de la
gobernabilidad en toda la empresa, debido a la jerarquía de las estructuras de
gobierno en el que por lo general opera, como se explicó anteriormente. En
particular, esta sección y las siguientes tienen por objeto:
Proporcionar una visión general de la naturaleza de la gobernanza como una
disciplina por derecho propio  Describir el contexto de la gobernanza en la que el
gobierno arquitectura típicamente funciona dentro de la empresa 

  Página 608 de 670 

TOGOF 9.1    
Describir un marco de gobernanza de Arquitectura que se pueden adaptar y aplicar en
la práctica, tanto para la arquitectura de la empresa y de otras formas de la
arquitectura de TI 

50.1.2 Naturaleza de la Gobernabilidad

50.1.2.1 Gobernabilidad: una perspectiva genérica

La gobernanza es esencial en asegurar que el negocio se lleva a cabo correctamente.

Es menos sobre el control manifiesto y el cumplimiento estricto de las normas, y
más acerca de la orientación y eficaz y la utilización equitativa de los recursos
para asegurar la sostenibilidad de los objetivos estratégicos de la organización. A
continuación se describen los principios básicos de la gestión empresarial,
identificados por la Organización para la Cooperación y el Desarrollo Económicos
(OCDE):
Se centra en los derechos, las funciones y el tratamiento equitativo de los
accionistas  Comunicación y transparencia y las responsabilidades de la junta 
Asegura:  o Sonido orientación estratégica de la organización  o La vigilancia
eficaz de la gestión de la junta  o la rendición de cuentas Junta para la empresa y
para los accionistas  Las responsabilidades de la Junta:  o revisión y dirección de
la estrategia corporativa  o Configuración y supervisión del cumplimiento de los
objetivos de desempeño de la gerencia 

Apoyando esto, la OCDE considera una visión tradicional de la gobernanza como: "...
el sistema por el cual las corporaciones de negocios son dirigidas y controladas La
estructura de gobierno corporativo especifica la distribución de derechos y
responsabilidades entre los diferentes participantes en la empresa - tales como el
tablero. , gerentes, accionistas y otras partes interesadas - y detalla las normas
y procedimientos para la toma de decisiones en asuntos corporativos Al hacer esto,
sino que también proporciona la estructura a través del cual se los objetivos de la
empresa. establecen, y los medios para alcanzar dichos objetivos y la supervisión
del rendimiento "[OCDE (1999)].
50.1.2.2 Características de Gobernabilidad

Las siguientes características han sido adaptados de Gobierno Corporativo (Naidoo,

2002) y se coloca aquí para poner de relieve el valor y la necesidad de una
gobernanza como un enfoque que se adoptará dentro de las organizaciones y sus
relaciones con todas las partes involucradas:
  Página 609 de 670 

TOGOF 9.1    
Disciplina  Todas las partes interesadas tendrán un compromiso de cumplir con los
procedimientos, los procesos y las estructuras de autoridad establecidos por la
organización.  Transparencia  Todas las acciones implementadas y su apoyo a las
decisiones estarán disponibles para su inspección por las partes de la organización
y los proveedores autorizados.  Independencia  Todos los procesos, toma de
decisiones y los mecanismos utilizados se establecerán con el fin de minimizar o
evitar potenciales conflictos de interés.  Responsabilidad  Grupos identificables
dentro de la organización - por ejemplo, las juntas de gobierno que toman las
acciones o tomar decisiones - están autorizados y responsables de sus actos. 
Responsabilidad  Se requiere que cada parte contratada para actuar con
responsabilidad para la organización y sus grupos de interés.  Justicia  Todas las
decisiones tomadas, los procesos utilizados y su aplicación no se les permitirá
crear una ventaja injusta a ningún partido en particular. 

Gobernanza 50.1.3 Tecnología

Controla la gobernanza Tecnología cómo una organización utiliza la tecnología en la

investigación, desarrollo y producción de sus productos y servicios. A pesar de que
puede incluir las actividades de gobierno de TI, a menudo tiene un alcance más
amplio. Gobierno La tecnología es una capacidad clave, requisitos y recursos para
la mayoría de las organizaciones debido a la omnipresencia de la tecnología en todo
el espectro de la organización. Estudios recientes han demostrado que muchas
organizaciones tienen un saldo a favor de los intangibles más que tangibles que
requieren gestión. Dado que la mayoría de estos intangibles son activos
informativos y digitales, es evidente que las empresas son cada vez más
dependientes de la TI, y la gobernabilidad de TI - El gobierno de TI - por lo
tanto, se está convirtiendo en una parte aún más importante de la gestión de la
tecnología. Estas tendencias también destacan las dependencias de las empresas no
sólo en la información en sí, sino también los procesos, sistemas y estructuras que
crean, ofrecen y consumen. A medida que el cambio hacia el aumento de valor a
través de intangibles
  Página 610 de 670 

TOGOF 9.1    
aumenta en muchos sectores de la industria, por lo que la gestión del riesgo debe
ser considerado como la clave para la comprensión y la moderación de los nuevos
desafíos, amenazas y oportunidades. No sólo son organizaciones que dependen cada
vez más de la información para sus operaciones y la rentabilidad, sino también su
reputación, la marca, y en última instancia, sus valores también dependen de la
misma información y la tecnología de apoyo.
50.1.4 Gobierno de TI

Gobierno de TI proporciona el marco y la estructura que une los recursos de TI y la

información a los objetivos y estrategias de la empresa. Por otra parte, el
gobierno de TI institucionaliza las mejores prácticas para la planificación,
adquisición, implementación y monitoreo de desempeño de TI, para asegurarse de que
los activos de TI de la empresa apoyan sus objetivos de negocio. En los últimos
años, el gobierno de TI se ha convertido en parte integral de la gobernanza
efectiva de la empresa moderna. Las empresas son cada vez más dependientes de TI
para apoyar las funciones críticas del negocio y los procesos; y para ganar con
éxito la ventaja competitiva, las empresas necesitan para gestionar eficazmente la
tecnología compleja que es un fenómeno generalizado en toda la organización, con el
fin de responder de manera rápida y segura a las necesidades empresariales. Además,
los entornos normativos de todo el mundo están exigiendo cada vez más estricto
control de la empresa sobre la información, impulsada por el aumento de los
informes de los desastres del sistema de información y el fraude electrónico. La
gestión de los riesgos relacionados con las TI es ahora ampliamente aceptada como
una parte clave de la gobernanza empresarial. De ello se desprende que una
estrategia de gobierno de TI, y una organización adecuada para la implementación de
la estrategia, deben ser establecidas con el apoyo de la alta dirección, aclarando
que es dueño de los recursos de TI de la empresa, y, en particular, que tiene la
responsabilidad última de su integración en toda la empresa .
50.1.4.1 Un Controles de TI Marco - COBIT

Al igual que con el gobierno corporativo, gobierno de TI es un tema muy amplio, más
allá del alcance de un marco de arquitectura de la empresa, tales como TOGAF. Una
buena fuente de información detallada sobre el gobierno de TI es el marco COBIT
(Objetivos de Control para la Información y Tecnologías Relacionadas). Este es un
estándar abierto para el control de TI, desarrollado y promovido por el Instituto
de Gobierno de TI, y publicado por la Information Systems Audit y Control
Foundation (ISACF). Controles de COBIT pueden proporcionar una ayuda útil a la
ejecución de una estrategia de cumplimiento. Un mapeo integral entre TOGAF y COBIT
está disponible que guía al practicante en la
  Página 611 de 670 

TOGOF 9.1    

aplicación de la gobernanza arquitectura alineado con el gobierno de TI: Mapeo de

TOGAF 8.1Con . COBIT 4.0, por el IT Governance Institute (ITGI) 1
50.1.5 Arquitectura de Gobierno: Visión general
50.1.5.1 arquitectura de gobernanza Características

Gobernabilidad Arquitectura es la práctica y la orientación en la que las

arquitecturas empresariales y otras arquitecturas son gestionados y controlados a
nivel de toda la empresa. 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 garantizar la efectiva
introducción, implantación y evolución de 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  El establecimiento de
procesos de apoyo a la gestión eficaz de los procesos anteriores dentro de los
parámetros acordados  El desarrollo de prácticas que garanticen la rendición de
cuentas a una comunidad claramente identificadas las partes interesadas, tanto
dentro como fuera de la organización  50.1.5.2 Arquitectura gobernanza como una
responsabilidad del nivel de dirección

Como se mencionó anteriormente, el gobierno de TI se ha convertido recientemente en

una responsabilidad bordo como parte de la gobernanza empresarial en general. El
gobierno de las arquitecturas de una organización es un factor clave en la
vinculación de TI / negocio eficaz, y por lo tanto es cada vez más una tecla de
responsabilidad a nivel de placa en su propio derecho. Esta sección tiene como
objetivo proporcionar el impulso para la apertura de TI y la gestión de
arquitectura para que las responsabilidades empresariales asociados con las
actividades de la arquitectura y los artefactos pueden ser dilucidados y
gestionados.
50.1.5.3 TOGAF y Arquitectura de Gobierno

Fase G del TOGAF ADM (véase parte II , 15 Fase G:. Gobernanza Aplicación ) está
dedicado a la gobernanza de ejecución, que se ocupa de la realización de la
arquitectura a través de los proyectos de cambio. Gobernabilidad implementación es
sólo un aspecto de la gobernanza arquitectura, que abarca la gestión y el control
de todos los aspectos del desarrollo y la evolución de las arquitecturas
empresariales y otras arquitecturas dentro de la empresa. Gobernabilidad
Arquitectura necesita ser apoyado por un marco de gobernanza Arquitectura (descrito
en 50.2 Arquitectura Governance Framework ), que ayuda a identificar los procesos
efectivos para que las responsabilidades empresariales asociados a la
  Página 612 de 670 

TOGOF 9.1    

gobernabilidad arquitectura pueden ser dilucidados, comunicadas, y gestionadas con

eficacia.

50.2 Arquitectura del marco de la gobernanza

En esta sección se describe un marco conceptual y organizativo para la gobernanza
de la arquitectura. Como se ha explicado anteriormente, la fase G del TOGAF ADM
(ver Parte II , 15. Fase G: Gobernanza Aplicación ) está dedicado a la gobernanza
de ejecución, que se ocupa de la realización de la arquitectura a través de los
proyectos de cambio. Gobernabilidad implementación es sólo un aspecto de la
gobernanza arquitectura, que abarca la gestión y el control de todos los aspectos
del desarrollo y la evolución de las arquitecturas empresariales y otras
arquitecturas dentro de la empresa. Gobernabilidad Arquitectura necesita ser
apoyado por un marco de gobernanza Arquitectura, se describe a continuación. El
marco del gobierno de describir es un marco genérico que se puede adaptar al
entorno de gobernanza existente de una empresa. Se tiene la intención de ayudar en
la identificación de procesos eficaces y de organización de estructuras, de modo
que las responsabilidades empresariales asociados a la gobernabilidad arquitectura
pueden ser dilucidados, comunicadas, y gestionadas con eficacia.
50.2.1 Arquitectura del marco de gobernanza ‐ Estructura
conceptual
50.2.1.1 Conceptos clave

Conceptualmente, la gobernabilidad arquitectura es un enfoque, una serie de

procesos, una orientación cultural, y un conjunto de responsabilidades de propiedad
que garanticen la integridad y la eficacia de las arquitecturas de la organización.
Los conceptos clave se ilustran en la Figura 50-1 .

  Página 613 de 670 
TOGOF 9.1    

Figura 50‐1: Arquitectura Governance Framework ‐ Estructura conceptual 

La división del proceso, el contenido y el contexto son clave para el apoyo de la

iniciativa de gobierno arquitectura, por lo que permite la introducción de nuevo
material de gobierno (legal, reglamentaria, basada en estándares, o legislativo)
sin afectar indebidamente los procesos. Este enfoque de contenido agnóstico asegura
que el marco es flexible. Los procesos suelen ser independiente del contenido y
poner en práctica un enfoque de mejores prácticas probadas de la gobernanza activa.
El Marco de Gobierno La arquitectura es parte integral de la empresa Continuum, y
gestiona todo el contenido relevante, tanto para la propia arquitectura y para los
procesos de gobernanza de la arquitectura.
50.2.1.2 Procesos Clave arquitectura de la gobernanza

Se requieren procesos de gobierno para identificar, gestionar, auditar y difundir

toda la información relacionada con la gestión de la arquitectura, los contratos y
la ejecución. Estos procesos de gestión servirá para asegurarse de que todos los
artefactos de la arquitectura y de los contratos, los principios y los acuerdos de
nivel operativo son monitoreados en forma permanente con capacidad de auditoría
clara de todas las decisiones tomadas.
  Página 614 de 670 

TOGOF 9.1    
Gestión de Políticas y Take-On

Todas las modificaciones de arquitectura, los contratos y la información de apoyo

deben estar bajo el gobierno a través de un proceso formal para registrar, validar,
ratificar, administrar y publicar contenido nuevo o actualizado. Estos mecanismos
servirán para garantizar la integración ordenada con contenido de gobierno
existente de tal manera que todas las partes relevantes, documentos, contratos y la
información de apoyo son administrados y auditados.
Conformidad

Las evaluaciones del cumplimiento contra los Acuerdos de Nivel de Servicio (SLAs),
Acuerdos de Nivel Operacional (OLA), las normas y los requisitos reglamentarios se
llevarán a cabo de manera continua para garantizar la estabilidad, la conformidad y
supervisión del rendimiento. Estas evaluaciones serán revisadas y aceptadas o
rechazadas en función de los criterios definidos en el marco de gobernanza.
Dispensa

Una evaluación de la conformidad puede rechazarse cuando la materia (diseño,

funcionamiento, nivel de servicio o la tecnología) no son compatibles. En este
caso, el tema puede:
1. Ser ajustado o reajustado a fin de satisfacer los requisitos de cumplimiento  2.
Solicite una dispensación 

En caso de rechazo de una Evaluación de Cumplimiento, una ruta alternativa para el

cumplimiento de la conformidad provisional se proporciona a través de las
dispensaciones. Éstos se conceden por un periodo de tiempo determinado y un
conjunto de servicios identificados y criterios operacionales que deben ser
ejecutadas durante la vida útil de la dispensación. Las dispensaciones no se
otorgan por tiempo indefinido, pero se utilizan como un mecanismo para asegurar que
los niveles de servicio y los niveles operativos se cumplen mientras que
proporciona un nivel de flexibilidad en su aplicación y el tiempo. La naturaleza de
duración determinada de dispensaciones asegura que son un disparador importante en
el ciclo de cumplimiento.
Control y seguimiento
Se requiere una gestión de rendimiento para asegurar que tanto los elementos
operativos y de servicios se gestionan en contra de un conjunto acordado de
criterios.Esto incluirá la vigilancia contra los acuerdos de servicio y de nivel
operativo, los comentarios para el ajuste y presentación de informes. Información
de gestión interna se considerará en Gestión Ambiental .
  Página 615 de 670 

TOGOF 9.1    
Control para Empresas

Control para Empresas se relaciona con los procesos alegadas para garantizar el
cumplimiento de las políticas comerciales de la organización.
Gestión Ambiental

Esto identifica todos los servicios necesarios para asegurar que el medio ambiente
basada en un repositorio que sustenta el marco de gobierno es eficaz y
eficiente.Esto incluye la gestión física y lógica repositorio, acceso,
comunicación, formación y acreditación de todos los usuarios. Todos los artefactos
arquitectura, contratos de servicio, contratos, e información de apoyo deben estar
bajo el gobierno a través de un proceso formal para registrar, validar, ratificar,
administrar y publicar contenido nuevo o actualizado. Estos mecanismos servirán
para garantizar la integración ordenada con contenido de gobierno existente de tal
manera que todas las partes relevantes, documentos, contratos y la información de
apoyo son administrados y auditados. El ambiente de gobernabilidad tendrá una serie
de procesos administrativos definidos con el fin de efectuar un servicio gestionado
y entorno del proceso. Estos procesos incluyen la gestión de usuarios, SLA internos
(definidos con el fin de controlar sus propios procesos), y la información de
gestión de informes.
50.2.2 Arquitectura del marco de gobernanza ‐ Estructura
Organizacional
50.2.2.1 Información general

Gobernabilidad Arquitectura es la práctica y la orientación en la que las

arquitecturas empresariales y otras arquitecturas son gestionados y controlados.
Con el fin de garantizar que este control es eficaz dentro de la organización, es
necesario contar con las estructuras organizativas correctas establecidas para
apoyar todas las actividades de gobierno. Una estructura de gobierno arquitectura
para la aplicación efectiva del enfoque descrito en esta sección incluirá
típicamente los siguientes niveles, que pueden en la práctica implican una
combinación de procesos de TI existentes de gobierno, las estructuras organizativas
y capacidades. Ellos suelen incluir lo siguiente:
Junta de gobierno Global  Junta de Gobierno Local  Autoridades de Diseño  Grupos de
trabajo 

  Página 616 de 670 

TOGOF 9.1    

La organización arquitectura se ilustra en la Figura 50-2 se destacan los

principales elementos estructurales necesarios para una iniciativa de gobierno
arquitectura. Si bien cada empresa tendrá diferentes necesidades, se espera que los
fundamentos del diseño de la organización se muestra en la Figura 50-2 se aplicarán
y aplicables en una amplia variedad de tipos de organización.

 
Figura 50‐2: Arquitectura Governance Framework ‐ Estructura Organizacional 
50.2.2.2 Áreas Clave Figura 50-2 identifica tres áreas clave de la gestión de la
arquitectura: Desarrollar,

implementar y desplegar. Cada uno de ellos es la responsabilidad de uno o varios

grupos dentro de la organización, mientras que la empresa Continuum se muestra para
apoyar todas las actividades y los artefactos asociados a la gobernanza de las
arquitecturas en todo su ciclo de vida. Los Desarrollar responsabilidades, procesos
y estructuras suelen estar vinculadas a la TOGAF ADM y su uso, mientras que las
responsabilidades Implementar, procesos y estructuras generalmente están vinculados
a la fase G (véase la Parte II , 15 Fase G:. Gobernanza Aplicación ).
  Página 617 de 670 

TOGOF 9.1    

Como se mencionó anteriormente, el Marco de Gobierno La arquitectura es parte

integral de la empresa Continuum, y gestiona todo el contenido relevante, tanto a
los propios como a los procesos de gobernanza configuraciones configuración.
50.2.2.3 Beneficios operacionales

Como se ilustra en la Figura 50-2 , la gobernanza de las arquitecturas de la

organización no sólo proporciona el control directo y la orientación de su
desarrollo y aplicación, pero también se extiende a las operaciones de las
arquitecturas implementadas. Se han encontrado los siguientes beneficios que se
derivan a través de la continua gobierno de arquitecturas:
Enlaces procesos de TI, los recursos y la información a las estrategias y objetivos
de la organización  Se integra e institucionaliza las mejores prácticas de  Alinea
con los marcos de la industria tales como COBIT (planificación y organización,
adquisición e implementación, entrega y apoyo, y el seguimiento del desempeño de
TI)  Permite a la organización a sacar el máximo provecho de sus activos de
información, de infraestructura y de hardware y software  Protege los activos
digitales subyacentes de la organización  Soporta requisitos de prácticas de
regulación y mejores como la auditabilidad, la seguridad, la responsabilidad y la
rendición de cuentas  Promueve la gestión del riesgo visible 

Estos beneficios se posicionan Governance Framework TOGAF Arquitectura como un

enfoque, una serie de procesos, una orientación cultural, y un conjunto de
propiedad de responsabilidades, que juntos asegurar la integridad y la eficacia de
las arquitecturas de la organización.

50.3 Arquitectura de Gobierno en la Práctica

Esta sección proporciona directrices prácticas para la aplicación eficaz de
gobernanza de la arquitectura.
Factores claves de éxito ‐ 50.3.1 Arquitectura de
Gobierno

Es importante tener en cuenta lo siguiente para asegurar un enfoque exitoso para el

gobierno arquitectura, y para la gestión eficaz del Contrato de Arquitectura:

  Página 618 de 670 

TOGOF 9.1    
Mejores prácticas para la presentación, la adopción, la reutilización, la
notificación y el retiro de las políticas de arquitectura, procedimientos,
funciones, competencias, estructuras organizativas, y servicios de apoyo 
Responsabilidades y estructuras de apoyo a los procesos de gobernanza de
arquitectura y requisitos de información de la Organización  Integración de las
herramientas y procesos para facilitar la asimilación de los procesos, tanto de
procedimiento y culturalmente  Criterios para el control de los procesos de
gobierno arquitectura, dispensas, evaluaciones de cumplimiento, SLAs y OLAs 
Requisitos internos y externos para la eficacia, eficiencia, confidencialidad,
integridad, disponibilidad, cumplimiento y confiabilidad de toda la información
relacionada con la arquitectura de gobernanza-, los servicios y los procesos 

50.3.2 Elementos de una Estrategia de Gobernabilidad Efectiva

Arquitectura
50.3.2.1 Arquitectura Gobernabilidad y Política Corporativa

Una arquitectura empresarial impuesta sin el apoyo político adecuado está condenada
al fracaso. Para tener éxito, la arquitectura de la empresa debe reflejar las
necesidades de la organización. Los arquitectos de la empresa, si no están
implicados en el desarrollo de la estrategia de negocio, por lo menos deben tener
una comprensión fundamental de la misma y de los problemas de negocio imperantes
que enfrenta la organización. Incluso puede ser necesario para que puedan
participar en el proceso de implementación del sistema y de poseer en última
instancia, las decisiones de inversión y selección de productos derivados de la
aplicación de la Tecnología de la Arquitectura. Hay tres elementos importantes de
la estrategia de gobierno de la arquitectura que se refieren en particular a la
aceptación y el éxito de la arquitectura dentro de la empresa. Mientras relevantes
y aplicables en su propio derecho, aparte de su papel en el gobierno, y por lo
tanto, describe por separado, sino que también de una parte integral del cualquier
estrategia de gobierno arquitectura eficaz.
Una Junta de Arquitectura de toda la Organización (véase 47. Architecture Board )
se debe establecer con el respaldo de la alta dirección para supervisar la
aplicación de la estrategia de gobierno de TI.  Un completo conjunto de principios
de la arquitectura (véase 23. Principios de  Arquitectura debe establecerse), para
orientar, informar y apoyar la forma en que una organización se marca sobre el
cumplimiento de su misión a través de la utilización de las TI.  Una Cumplimiento
Arquitectura (ver . 48 Arquitectura Cumplimiento ) estrategia debe ser adoptada -
medidas específicas (algo más que una declaración de política) para garantizar el
cumplimiento de la arquitectura, incluyendo las evaluaciones de impacto de
proyectos, un proceso de revisión de Cumplimiento Arquitectura formal, y,
posiblemente, incluso mediante la integración del equipo de arquitectura de la
contratación del producto. 

  Página 619 de 670 

TOGOF 9.1    

  

  Página 620 de 670 

TOGOF 9.1    

  

51. Arquitectura de Madurez Modelos

Este capítulo proporciona técnicas para evaluar y cuantificar la madurez de una
organización en la arquitectura de la empresa.

51.1 Información general

Organizaciones que pueden gestionar el cambio con eficacia son generalmente más
éxito que las que no pueden. Muchas organizaciones saben que necesitan para mejorar
sus procesos con el fin de gestionar con éxito el cambio, pero no saben cómo. Tales
organizaciones típicamente gastan muy poco en la mejora de procesos, porque no
están seguros de cómo proceder mejor; o gastar mucho, en una serie de esfuerzos
paralelos y desenfocadas, con poco o ningún resultado. Modelos de Madurez de
Capacidad (CMM) abordan este problema al proporcionar un método eficaz y probado
para una organización para ganar poco a poco el control y la mejora de sus procesos
de cambio. Estos modelos proporcionan los siguientes beneficios:
Describen las prácticas que cualquier organización debe llevar a cabo con el fin de
mejorar sus procesos.  Proporcionan un criterio para medir periódicamente la
mejora.  Constituyen un marco probado en el que la gestión de los esfuerzos de
mejora.  Organizan las diversas prácticas en niveles, cada nivel que representa una
mayor capacidad para controlar y gestionar el entorno de desarrollo. 

Una evaluación de las prácticas de la organización contra el modelo - llamado una

"evaluación" - determina el nivel en el que se encuentra la organización en la
actualidad. Indica la capacidad de la organización para ejecutar en la zona de que
se trate, y las prácticas en las que la organización necesita para centrarse con el
fin de ver la mejora más grande y el más alto retorno de la inversión. Los
beneficios de MMCs para efectivamente esfuerzo directo están bien documentados.

51.2 Antecedentes
El Instituto de Ingeniería de Software (SEI) - www.sei.cmu.edu operado por la
Universidad Carnegie Mellon - desarrolló el CMM originales (Capability Maturity
Model) para el Software (SWCMM) a principios de 1990, que sigue siendo ampliamente
utilizado hoy. Esta CMM proporciona un marco para desarrollar modelos de madurez en
una amplia gama de disciplinas.
  Página 621 de 670 

TOGOF 9.1    

El creciente interés en la aplicación de estas técnicas a otros campos ha dado

lugar a una serie de herramientas de la plantilla que evalúan:
El estado de los procesos de arquitectura  La arquitectura  Buy-in de la
organización tanto a 

Los principales temas abordados en estos modelos incluyen:

Implementación de procesos y de auditoría  Las mediciones de calidad  Gente
competencias  Gestión de las inversiones 

Implican el uso de una multiplicidad de modelos, y se centran en particular en la

medición de los beneficios del negocio y retorno de la inversión. Un tema
estrechamente relacionado es el Skills Framework Architecture (ver 52. Arquitectura
Skills Framework ), que se puede utilizar para planificar las habilidades objetivo
y capacidades requeridas por una organización para desarrollar y utilizar la
arquitectura empresarial con éxito, y para determinar las necesidades de
capacitación y desarrollo de individuos.

51.3 Marco de EE.UU. Departamento de Comercio ACMM

51.3.1 Información general

Como un ejemplo de la tendencia hacia un mayor interés en la aplicación de técnicas

de CMM para la arquitectura empresarial, ahora se espera que todas las agencias
federales de Estados Unidos para proporcionar modelos de madurez y clasificaciones
como parte de sus requisitos de gestión de inversiones y de auditoría de TI. En
particular, el Departamento de Comercio de EE.UU. (DoC) ha desarrollado una
arquitectura empresarial Capability Maturity Model (ACMM ) 1 para ayudar en la
realización de evaluaciones internas. ACMM versión 1.2 se publicó en diciembre de
2007. El ACMM proporciona un marco que representa los componentes clave de un
proceso de arquitectura de la empresa productiva. El objetivo es mejorar las
probabilidades generales para el éxito de la arquitectura empresarial mediante la
identificación de las áreas débiles y proporcionar un camino evolutivo definido a
mejorar el proceso global de la arquitectura. El ACMM se compone de tres secciones:
1. El modelo de madurez de la arquitectura empresarial    Página 622 de 670 

TOGOF 9.1     2. Características de arquitectura empresarial de los procesos de las

unidades operativas en los diferentes niveles de madurez  3. El CMM scorecard
arquitectura empresarial 

Las dos primeras secciones se explica la arquitectura de los niveles de madurez de

la capacidad y la arquitectura elemento personal empresa correspondiente y las
características de cada nivel de madurez para ser utilizados como medidas en el
proceso de evaluación. En la tercera sección se utiliza para obtener el nivel de
madurez de capacidades Arquitectura que debe ser reportada a la Información Oficial
Jefe Departamento de Comercio (CIO).
51.3.2 Elementos del ACMM

La Declaración ACMM consta de seis niveles de madurez y nueve elementos de la

arquitectura. Los seis niveles son:
0  Ninguno  1  Inicial  2  En desarrollo  3  Definido  4  Gestionado  5  Medido 

Los nueve elementos de la arquitectura de la empresa son los siguientes:

1. Proceso de Arquitectura  2. El desarrollo de la Arquitectura  3. Vinculación de
negocios  4. Implicación personal directivo superior    Página 623 de 670 

TOGOF 9.1     5. Participación unidad de funcionamiento  6. Comunicación

Arquitectura  7. Seguridad de TI  8. Gobernabilidad Arquitectura  9. Inversión en
TI y la estrategia de adquisición 

Dos métodos complementarios se utilizan en el ACMM para calcular una calificación

de madurez. El primer método se obtiene una media de nivel de madurez de
arquitectura empresarial ponderado. El segundo método muestra el porcentaje
alcanzado en cada nivel de madurez para los nueve elementos de la arquitectura.
51.3.3 Ejemplo: Arquitectura Empresarial niveles de madurez
de procesos

El siguiente ejemplo muestra las características detalladas de los niveles de

madurez de arquitectura empresarial que se aplican a cada uno de los nueve
elementos. Por ejemplo, el Nivel 3: Definido, el punto número 8 (gobernanza
explícito documentado de la mayoría de las inversiones en TI), muestra el estado
del Nivel de Madurez 3 por elemento 8 (Arquitectura de Gobierno).
Nivel 0: Ninguno

Ningún programa de arquitectura de la empresa. No arquitectura empresarial que

hablar.
Nivel 1: Inicial

Informal proceso de arquitectura de la empresa en marcha.

1. Los procesos son ad hoc y localizada. Algunos procesos de arquitectura
empresarial se
definen. No hay proceso de la arquitectura unificada a través de tecnologías o
procesos de negocio. El éxito depende de los esfuerzos individuales. 

2. Procesos de arquitectura de la empresa, la documentación y las normas son

establecidas por una variedad de especiales medios y son localizados o informal. 
3. Minimal, vinculación o implícita de las estrategias de negocio o controladores
de negocio.  4. Conocimiento limitado equipo de gestión o la participación en el
proceso de la arquitectura.  5. Limited funcionamiento de la unidad de aceptación
del proceso de arquitectura de la empresa.  6. La última versión de la
documentación de la arquitectura empresarial de la unidad de
mando está en la web. Existe poca comunicación sobre el proceso de arquitectura de
la empresa y las mejoras posibles procesos. 

  Página 624 de 670 

TOGOF 9.1     7. Consideraciones de seguridad de TI son ad hoc y localizada.  8. No

gobernabilidad explícita de las normas arquitectónicas.  9. Poca o ninguna
participación de personal de planificación y adquisiciones estratégicas en
el proceso de arquitectura de la empresa. Poca o ninguna adherencia a los
estándares existentes.  Nivel 2: En desarrollo

Proceso de arquitectura de la empresa se encuentra en desarrollo.

1. Proceso básico de arquitectura empresarial se documenta sobre la base de la OMB
Circular A-130 y el Departamento de Comercio de Arquitectura Empresarial de
Orientación. El proceso de la arquitectura se ha desarrollado funciones y
responsabilidades claras. 

2. La visión de TI, los principios, los vínculos comerciales, de línea de base y

Arquitectura
objetivo se identifican. Existen normas Arquitectura, pero no necesariamente
vinculados a Target Arquitectura. Modelo Referencia técnica (TRM) y el marco de las
Normas perfil establecido. 

3. Vinculación explícita con las estrategias de negocio.  4. Conciencia de Gestión

de la arquitectura esfuerzo.  5. Asignación de responsabilidades y se está
trabajando.  6. El Departamento de Comercio y de la unidad de funcionamiento las
páginas web de
arquitectura empresarial se actualizan periódicamente y se utilizan para documentar
la arquitectura entregables. 

7. Arquitectura de seguridad de TI ha definido roles y responsabilidades claras. 

8. Gobernanza de unos estándares arquitectónicos y algunos adherencia al existente
Perfil Normas.  9. Poco o ningún gobierno formal de la inversión en TI y la
estrategia de adquisición. Equipo de operación demuestra la adhesión a alguna
existente Perfil Normas. 
Nivel 3: Definido

Arquitectura empresarial Definido incluyendo procedimientos escritos detallados y

TRM.
1. La arquitectura está bien definida y comunicada al personal de TI y la gestión
empresarial
con el equipo de operación responsabilidades de TI. El proceso se siguió en gran
medida. 

2. Se han completado el análisis de brechas y el Plan de Migración. TRM

desarrollado plenamente y Normas perfil. IT objetivos y métodos se identifican.  3.
Arquitectura empresarial está integrada con la planificación del capital y el
control de las inversiones.    Página 625 de 670 

TOGOF 9.1     4. Equipo Directivo al tanto y apoya el proceso de arquitectura de

toda la
empresa. Administración apoya activamente las normas arquitectónicas. 

5. La mayoría de los elementos de la unidad de operación muestran aceptación o

están participando activamente en el proceso de arquitectura de la empresa.  6.
Arquitectura documentos actualizados regularmente en la empresa doc Página web
arquitectura.  7. Arquitectura de seguridad de TI Normas perfil está totalmente
desarrollado y se integra con la arquitectura empresarial.  8. Gobernabilidad
explícita documentada de la mayoría de las inversiones en TI.  9. Existe una
estrategia de adquisición de TI e incluye medidas de cumplimiento de la
arquitectura de TI de la empresa. Beneficios económicos son considerados en la
identificación de proyectos.  Nivel 4: Gestionado

Gestionado y el proceso de arquitectura de la empresa medido.

1. Proceso de arquitectura de la empresa forma parte de la cultura. Las métricas de
calidad asociados con el proceso de la arquitectura son capturados.  2.
Documentación de la arquitectura Enterprise se actualiza en un ciclo regular para
reflejar la
arquitectura de la empresa actualizada. Arquitecturas de negocios, datos,
aplicaciones y tecnología definida por el apropiado de jure y de facto normas. 

3. La planificación de capital y control de las inversiones se ajustan en base a

los comentarios
recibidos y las lecciones aprendidas de la arquitectura empresarial actualizado.
periódica nuevo examen de los impulsores del negocio. 

4. Equipo de alta gerencia que participan directamente en el proceso de revisión de

la arquitectura.  5. La unidad operativa entera acepta y participa activamente en
el proceso de arquitectura de la empresa.  6. Arquitectura documentos se actualizan
regularmente, y frecuentemente crítica para los últimos desarrollos de arquitectura
/ standards.  7. Métricas de desempeño asociados a la arquitectura de seguridad de
TI son capturados.  8. Gobernabilidad explícita de todas las inversiones de TI. Los
procesos formales para la gestión de las varianzas retroalimentan arquitectura
empresarial.  9. Todas las adquisiciones y compras de TI planificadas son guiados y
regidos por la arquitectura de la empresa. 
Nivel 5: Optimización

  Página 626 de 670 

TOGOF 9.1    

Mejora continua del proceso de arquitectura de la empresa.

1. Concertada los esfuerzos para optimizar y mejorar continuamente el proceso
arquitectura.  2. Un proceso de las normas y renuncias se utiliza para mejorar el
proceso de desarrollo de la arquitectura.  3. Métricas de procesos Arquitectura se
utilizan para optimizar e impulsar los vínculos
comerciales. Negocios involucrado en las mejoras continuas de los procesos de la
arquitectura empresarial. 

4. Participación alta dirección en la optimización de mejoras en los procesos de

desarrollo de la arquitectura y la gobernabilidad.  5. Comentarios sobre el proceso
de la arquitectura de todos los elementos de la unidad de servicio se utiliza para
impulsar mejoras en los procesos de la arquitectura.  6. Arquitectura documentos
son utilizados por todos los que toma las decisiones en la organización para cada
decisión de negocios relacionados con las TI.  7. La retroalimentación de TI
arquitectura de seguridad métricas se utilizan para impulsar mejoras en los
procesos de la arquitectura.  8. Gobernabilidad explícita de todas las inversiones
de TI. Un proceso de las normas y renuncias se utiliza para hacer las mejoras de
gobierno en procesos.  9. Sin inversión en TI no planificado o de la actividad de
adquisición. 

51.4 Modelos de Madurez de Capacidad de Integración (CMMI)

51.4.1 Introducción

Los modelos de capacidad que el SEI está actualmente involucrado en el desarrollo,

expansión, o el mantenimiento son las siguientes:
CMMI (Capability Maturity Model Integration)  IPD-CMM (Desarrollo de Productos
Integrada Capability Maturity Model)  P-CMM (People Capability Maturity Model)  SA-
CMM (Software Acquisition Capability Maturity Model)  SE-CMM (Ingeniería de
Sistemas Capability Maturity Model)  SW-CMM (Capability Maturity Model de
Software) 

Como se explica en este capítulo, en los últimos años la industria ha experimentado

un crecimiento significativo en el área de modelos de madurez. La multiplicidad de
modelos disponibles ha llevado a sus propios problemas, en cuanto a la forma de
integrar todos los
  Página 627 de 670 

TOGOF 9.1    

diferentes modelos para producir una métrica con significado para la madurez del
proceso global. En respuesta a esta necesidad, el SEI ha desarrollado un marco
llamado Capability Maturity Model Integration (CMMI), para proporcionar un medio de
gestionar la complejidad. Según el SEI, el uso de los modelos CMMI mejora en las
mejores prácticas de los modelos anteriores en muchos aspectos importantes, en
particular las organizaciones que permitan a:
Vincular de forma más explícita las actividades de gestión y de ingeniería a los
objetivos de negocio  Ampliar el alcance y la visibilidad de las actividades del
ciclo de vida del producto y de ingeniería para asegurar que el producto o servicio
cumple con las expectativas del cliente  Incorporar las lecciones aprendidas de
otras áreas de las mejores prácticas (por ejemplo, medición, gestión de riesgos y
la gestión de proveedores)  Implementar prácticas de alta madurez más robustas 
Dirección funciones organizativas adicionales críticos para sus productos y
servicios  Más cumplir plenamente con las normas pertinentes de la ISO 

CMMI se está adoptando en todo el mundo.

51.4.2 Método SCAMPI

El CMMI Método de evaluación estándar para la Mejora de Procesos (SCAMPI) es el

método de evaluación asociada con CMMI. El método de evaluación SCAMPI se utiliza
para identificar las fortalezas, debilidades, y valoraciones en relación con los
modelos de referencia CMMI. Incorpora las mejores prácticas encontradas con éxito
en la comunidad de evaluación, y se basa en las características de varios métodos
de evaluación legado. Es aplicable a una amplia gama de modos de uso de evaluación,
incluyendo tanto la mejora de procesos internos y externos determinaciones de
capacidad. El documento de definición del método SCAMPI 2 se describen los
requisitos, las actividades y las prácticas relacionadas con cada uno de los
procesos que componen el método SCAMPI.

51.5 Conclusiones
En esta sección se ha tratado de introducir en TOGAF el tema de los métodos y
técnicas basadas en CMM para su uso en relación con la arquitectura empresarial.
Los beneficios de usar MMCs están bien documentados. Las futuras versiones de TOGAF
pueden incluir un modelo de madurez para medir la adopción de sí TOGAF.
  Página 628 de 670 

TOGOF 9.1    

  
52. Arquitectura Skills Framework
En este capítulo se proporciona un conjunto de funciones, la habilidad y la
experiencia de las normas para el trabajo de arquitectura de empresa del personal
de la empresa.

52.1 Introducción
. Habilidades marcos proporcionan una vista de los niveles de competencia
requeridos para funciones específicas Definen:
Los roles dentro de un área de trabajo  Las habilidades que requiere cada función 
La profundidad de los conocimientos necesarios para cumplir la función con éxito 

Son relativamente comunes para la definición de las competencias necesarias para

una empresa de consultoría y / o cesión de gestión de proyectos, para entregar un
proyecto específico o paquete de trabajo. También son muy utilizados por las
agencias de contratación y de búsqueda para que coincida con los candidatos y los
roles. Su valor se deriva de su capacidad para proporcionar un medio para
identificar rápidamente partidos de habilidad y lagunas. Aplicado con éxito, pueden
asegurar que los candidatos son aptos para los puestos de trabajo que tengan
asignadas. Su valor en el contexto de la arquitectura de la empresa se debe a la
inmadurez de la disciplina de arquitectura empresarial, y los problemas que surgen
de esto.

52.2 Necesidad de un Marco de Arquitectura Empresarial Habilidades

52.2.1 Definitoria Rigor

"Arquitectura Empresarial" y "EA" son ampliamente utilizados pero hoy mal definidos
los términos de la industria. 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 arquitectura / arquitecto que se está describiendo. Esta falta de
uniformidad conduce a dificultades para las organizaciones que buscan contratar o
asignar / promoción de personal para cubrir puestos en el campo de la arquitectura.
Debido a los diferentes usos de los términos, a menudo la incomprensión y la
  Página 629 de 670 

TOGOF 9.1    

falta de comunicación entre los que buscan reclutar a favor, y los que tratan de
llenar, los diferentes roles del arquitecto.
52.2.2 Bases de la Práctica de la Arquitectura Interior

A pesar de la falta de una terminología uniforme, habilidades de arquitectura están

en el incremento de la demanda, ya que la disciplina de la arquitectura ganancias
cada vez más atención en la industria. Muchas empresas han establecido, o están
considerando la creación, una práctica de la arquitectura empresarial, como medio
de fomentar el desarrollo de las habilidades y experiencia necesarias entre el
personal de la casa para llevar a cabo las diferentes tareas requeridas por la
arquitectura de la empresa. Una práctica de la arquitectura empresarial es un
programa formal de desarrollo y certificación, mediante el cual una entidad
reconoce formalmente la competencia de sus arquitectos en ejercicio, como se
demuestra por su trabajo. Ese programa es esencial para asegurar la alineación de
las capacidades del personal y la experiencia con las tareas de arquitectura que la
empresa desee realizar. También se requiere que las definiciones de funciones y de
competencias en el que un programa de este tipo tiene que basarse, por tanto el
reclutamiento y las organizaciones que suministran, en los casos en que el personal
externo ha sido contratada para realizar el trabajo de arquitectura (por ejemplo,
como parte de un compromiso de consultoría). Una práctica de arquitectura de la
empresa es difícil y costoso establecer. Normalmente se construye en torno a un
proceso de revisión por pares, y consiste en el tiempo y el talento del liderazgo
técnico estratégico de una empresa. Normalmente se trata de establecimiento de un
comité de revisión de pares, y la documentación del proceso, y de los requisitos
para la certificación interna. El tiempo también se exigió a los aspirantes a
prepararse para la revisión por pares, mediante la creación de un portafolio de su
trabajo para demostrar sus habilidades, experiencias y contribuciones a la
profesión. El TOGAF Arquitectura Skills Framework intenta abordar esta necesidad
proporcionando definiciones de las habilidades de la arquitectura y los niveles de
competencia necesarios de personal, internos o externos, que vaya a realizar las
diversas funciones Architecting definidos en el Marco TOGAF. Debido a la
complejidad, el tiempo y costo, muchas empresas no cuentan con un programa interno
de certificación de arquitecto de la empresa, prefiriendo en lugar de simplemente
entrevistar y contratar a personal de la arquitectura en un ad hoc base. Existen
riesgos graves asociados con este enfoque:
La comunicación entre las organizaciones de reclutamiento, consultoras y agencias
de empleo es muy difícil. 

  Página 630 de 670 

TOGOF 9.1    
El tiempo es perdido entrevistar al personal que puedan haber aplicado de buena fe,
pero aún carecen de los conocimientos y / o experiencia requeridas por el
empleador.  El personal que son capaces de llenar papeles arquitectura puede ser
pasado por alto, o no puede identificarse con las vacantes publicadas y por lo
tanto ni siquiera aplicar.  Hay mayor riesgo de personal inadecuados ser empleado o
contratado, a través de la culpa de nadie, ya pesar de todos los involucrados que
actúan de buena fe.Esto a su vez puede:  o Aumentar los gastos de personal, a
través de la necesidad de volver a contratar o reasignar personal  o afectar
negativamente el tiempo, costo y calidad de los sistemas de TI operacionales y los
proyectos que les ofrecen 

     

52,3 Goles / Justificación

52.3.1 Certificación de Enterprise Architects

El propósito principal de un establecimiento de un programa interno de

certificación de arquitecto de la empresa de la empresa es doble:
1. Reconocer formalmente a la habilidad de sus arquitectos en ejercicio, como parte
de la tarea de establecer y mantener una organización architecting profesional  2.
Para asegurar la alineación de las capacidades del personal necesario y la
experiencia con
las tareas de arquitectura que la empresa desea realizar, si éstos se van a
realizar internamente a la empresa o en el exterior; por ejemplo, como parte de un
compromiso de consultoría 

52.3.2 Beneficios específicos

Los beneficios específicos previstos por el uso del TOGAF Arquitectura Skills
Framework incluyen:
Reducción del tiempo, el costo y el riesgo en la formación, la contratación y la
gestión de profesionales de la arquitectura, tanto internos como externos:  o la
comunicación entre las organizaciones de reclutamiento Simplifica, consultoras y
agencias de empleo  o Evita perder tiempo entrevistando a personal que puedan haber
aplicado de buena fe, pero aún carecen de los conocimientos y / o experiencia
requeridas por el empleador 
  Página 631 de 670 

TOGOF 9.1    
o personal evita que son capaces de llenar papeles Arquitectura ser pasado por
alto, o no se identifican con las vacantes publicadas y por lo tanto ni siquiera
aplicando  Tiempo y costo para establecer una práctica de la arquitectura interna
reducida:  o Muchas empresas no tienen una práctica de la arquitectura interna
debido a la complejidad de instalar uno, prefiriendo en lugar de simplemente
entrevistar y contratar a personal de la arquitectura en un ad hoc base.  o Al
proporcionar definiciones de las habilidades de la arquitectura y los niveles de
competencia requeridos del personal que vaya a realizar las diversas funciones
definidas dentro de la arquitectura de TOGAF, el Skills Framework Architecture
reduce enormemente el tiempo, el costo y el riesgo de la creación de una práctica
por primera vez, y evita "llantas de re-inventar".  o Las empresas que ya tienen
una práctica de la arquitectura interna son capaces de establecer normas para toda
la empresa, pero aún así experimentar dificultades como se indica más arriba en la
contratación de personal o consultores atractivas, de fuentes externas, debido a la
falta de uniformidad entre las distintas empresas. Al alinear su marco de
competencias existente con las definiciones aceptadas en la industria
proporcionados por The Open Group, una empresa puede simplificar en gran medida
estos problemas.  Reducción del tiempo y el costo de implementar un estudio de
arquitectura ayuda a reducir el tiempo, costo y riesgo de desarrollo global de la
solución:  o Las empresas que no tienen una práctica de la arquitectura interna
corren el riesgo de personal inadecuados está empleada o contratada, a través de la
culpa de nadie, ya pesar de todos los involucrados que actúan de buena fe. El
tiempo y costo resultantes penas superan con creces el tiempo y el costo de tener
un estudio de arquitectura interior:   Los gastos de personal se incrementan, a
través de la necesidad ocasional de volver a contratar o reasignar personal.   Aún
más importante es el impacto adverso sobre el tiempo, costo y calidad de los
sistemas de TI operacionales y los proyectos para lanzarlas, como resultado de
malas asignaciones del personal. 

   

52.4 Arquitectura Empresarial de rol y Habilidad Categorías

52.4.1 Información general

En esta sección se describe el papel de un arquitecto de la empresa, las

habilidades fundamentales que se requieren, y algunas disciplinas posibles en que
un arquitecto de la empresa puede especializarse.

  Página 632 de 670 

TOGOF 9.1    

TOGAF ofrece una empresa de arquitectura, y por lo tanto requiere de los negocios y
los profesionales capacitados de TI para desarrollar la arquitectura de la empresa.
El TOGAF Arquitectura Skills Framework proporciona una vista de los niveles de
competencia para las funciones específicas dentro del equipo de arquitectura de la
empresa. El marco define:
Los roles dentro de un área de trabajo de arquitectura empresarial  Las habilidades
requeridas por esos roles  La profundidad de los conocimientos necesarios para
cumplir cada función con éxito 

El valor está en que proporciona un medio rápido para la identificación de las

habilidades y las lagunas. Aplicado con éxito, el marco puede ser utilizado como
una medida para:
El desarrollo del personal  Asegurar que la persona correcta hace el trabajo
adecuado 

52.4.2 Roles TOGAF

Un equipo típico de la arquitectura de emprender el desarrollo de una empresa de

arquitectura como se describe en TOGAF comprendería las siguientes funciones:
Los miembros de la Junta de Arquitectura  Arquitectura Patrocinador  Arquitectura
del Administrador  Arquitectos para:  o Enterprise Architecture (que para el
propósito de las tablas que se muestran a continuación se puede considerar como un
superconjunto de negocios, datos, aplicaciones, y Arquitectura de Tecnología)  o
Arquitectura de Negocios  o Arquitectura de Datos  o Arquitectura de aplicaciones 
o Tecnología de la Arquitectura  Programa y / o Jefes de Proyecto  Diseñador de TI 
Y muchos otros ... 

  Página 633 de 670 

TOGOF 9.1    

Las siguientes tablas muestran, para cada uno de estos roles, las habilidades
requeridas y el nivel deseable de competencia en cada habilidad. De todas las
funciones enumeradas anteriormente, el que necesita un análisis particularmente
detallado y definición es, por supuesto, el papel central del arquitecto de la
empresa. Como se explicó anteriormente, "Arquitectura Empresarial" y "EA" son
términos que son muy utilizados pero muy mal definidos en la industria hoy en día,
lo que denota una gran variedad de prácticas y habilidades aplicadas en una amplia
variedad de dominios de la arquitectura. A menudo hay confusión entre el papel de
un arquitecto y la de un diseñador o constructor. Muchas de las habilidades
requeridas por un arquitecto de la empresa también son requeridos por el diseñador,
que ofrece las soluciones. Aunque sus habilidades son complementarias, las de la
diseñadora son principalmente la tecnología enfocada y traducen la arquitectura en
componentes entregables. El inciso final por debajo, por tanto, explora en detalle
las características genéricas del papel de arquitecto de la empresa, así como los
requisitos de habilidades clave, cualquiera que sea el dominio particular
arquitectura (Arquitectura Empresarial, Arquitectura de Negocios, Arquitectura de
datos, arquitectura de aplicaciones, Arquitectura de Tecnología, etc.)
52.4.3 Categorías de Habilidades

El conjunto de habilidades del equipo TOGAF deberá incluir las siguientes

categorías principales de capacidades:
Competencias Genéricas : - que comprende típicamente de liderazgo, trabajo en
equipo, habilidades interpersonales, etc  Habilidades de Negocios y Métodos : - que
típicamente comprenden casos de negocio, procesos de negocio, planificación
estratégica, etc  Arquitectura Empresarial Habilidades : - que típicamente
comprende modelado, diseño de bloques de construcción, aplicaciones y diseño de
papel, integración de sistemas, etc  Programa o Proyecto de Habilidades
Directivas : - que típicamente comprende la gestión del cambio empresarial, métodos
y herramientas de gestión de proyectos, etc  IT Generales Conocimiento
Habilidades : - que típicamente comprende aplicaciones de corretaje, gestión de
activos, planificación de la migración, SLAs, etc  Técnicas Habilidades de TI : -
que típicamente comprende la ingeniería de software, seguridad, intercambio de
datos, gestión de datos, etc  Entorno legal : - que típicamente comprende las leyes
de protección de datos, derecho contractual, derecho de contratación, fraude, etc 

Las tablas siguientes ilustran cada una de estas categorías de habilidades.

  Página 634 de 670 
TOGOF 9.1    

Las siguientes tablas muestran, para cada una de estas habilidades, los papeles en
los que sean pertinentes y del nivel deseable de competencia en cada habilidad.
52.4.4 Niveles de Competencia

El TOGAF Arquitectura Skills Framework identifica cuatro niveles de conocimiento o

habilidad en cualquier área:

   52.5

Arquitectura Empresarial de rol y Habilidad Definiciones

52.5.1 Competencias Genéricas

  52.5.2 Negocio Habilidades y Métodos 

    Página 635 de 670 

TOGOF 9.1        52.5.3 Arquitectura Empresarial Habilidades

     52.5.4 Programa o Habilidades de Gestión de Proyectos

    

  Página 636 de 670 

TOGOF 9.1       52.5.5 TI Habilidades Conocimientos

generales

  52.5.6 Técnicas Habilidades de TI

  52.5.7 Entorno Legal

    Página 637 de 670 

TOGOF 9.1          

52.6 Rol genérico y Habilidades de la EA

De todas las funciones enumeradas anteriormente, el que necesita un análisis
particularmente detallado y definición es, por supuesto, el papel central del
arquitecto de la empresa. Como se explicó anteriormente, "Arquitectura Empresarial"
y "EA" son términos que son muy utilizados pero muy mal definidos en la industria
hoy en día, lo que denota una gran variedad de prácticas y habilidades aplicadas en
una amplia variedad de dominios de la arquitectura. Por tanto, esta sección explora
en detalle las características genéricas del papel de arquitecto de la empresa, y
algunos de los requisitos de habilidades clave, cualquiera que sea el dominio
particular arquitectura (Arquitectura Empresarial, Arquitectura de Negocios,
Arquitectura de datos, arquitectura de aplicaciones, Arquitectura de Tecnología,
etc.)
52.6.1 Rol Genérico

Arquitectos empresariales son visionarios, entrenadores, jefes de equipo, de

empresa a técnico enlaces, informáticos y expertos de la industria. La siguiente es
una descripción de trabajo efectiva para un arquitecto de la empresa:
"El arquitecto tiene la responsabilidad de asegurar la integridad (aptitud para el
propósito) de la arquitectura, en términos de abordar adecuadamente todos los
intereses pertinentes de las partes interesadas, y la integridad de la
arquitectura, en cuanto a la conexión de todos los diferentes puntos de vista para
entre ellos, la conciliación de forma satisfactoria las preocupaciones conflictivas
de los diferentes grupos de interés, y que muestra las compensaciones hechas en
hacerlo (como entre la seguridad y el rendimiento, por ejemplo). 

La elección de qué puntos de vista particulares de arquitectura para desarrollar es

una de las decisiones clave que la empresa arquitecto tiene que hacer. La elección
tiene que ser limitada por consideraciones de orden práctico, y por el principio de
la aptitud para el propósito (es decir, la arquitectura debe ser desarrollado sólo
hasta el punto en el que es apto para el propósito, y no reiteró el infinito como
un ejercicio académico). " El papel de la empresa arquitecto es más parecido al de
un planificador de la ciudad que la de un arquitecto del edificio, y el producto de
la empresa arquitecto se caracteriza mejor como una comunidad planificada (en
oposición a una expansión urbana sin restricciones), y no como un edificio bien
diseñado o un conjunto de edificios. Un arquitecto de la empresa no crea la visión
técnica de la empresa, pero tiene relaciones profesionales con los ejecutivos de la
empresa para reunir y articular la visión técnica, y
  Página 638 de 670 

TOGOF 9.1    

para elaborar el plan estratégico para darse cuenta. Este plan siempre está
relacionada con los planes de negocio de la empresa, y las decisiones de diseño son
trazables al plan de negocios. El plan estratégico de la empresa arquitecto está
ligada al proceso de gobernanza arquitectura (ver 50. Arquitectura de Gobierno )
para la empresa, por lo que las decisiones de diseño no sean eludidas por
conveniencia táctica. El arquitecto de la empresa produce documentación de las
decisiones de diseño para los equipos de desarrollo de aplicaciones o equipos de
aplicación de productos para su ejecución. Un arquitecto está involucrado en todo
el proceso; empezando con el trabajo con el cliente para entender las necesidades
reales, en oposición a sus deseos, y a continuación, durante todo el proceso de
traducir esas necesidades en capacidades verificadas para satisfacer las
necesidades. Además, el arquitecto puede presentar diferentes modelos para el
cliente que se comunican cómo pueden cumplirse esas necesidades, y por lo tanto es
un participante esencial en el proceso de venta consultiva. Sin embargo, el
arquitecto no es el constructor, y deberá permanecer en un nivel de abstracción
necesario para garantizar que no se interpongan en el camino de la aplicación
práctica. El siguiente extracto de El Arte de Sistemas Architecting ilustra esta
idea:
"Es la responsabilidad del arquitecto de conocer y concentrarse en los pocos
detalles e interfaces críticos que realmente importan, y no sobrecargarse con el
resto." 

El enfoque del arquitecto es en la comprensión de lo que se necesita para

satisfacer al cliente, donde el valor cualitativo se utiliza más de las medidas
cuantitativas. El arquitecto utiliza más habilidades inductivas que las habilidades
deductivas de la constructora. Las ofertas de arquitecto más con las directrices,
en lugar de las normas que los constructores utilizan como una necesidad. También
debe quedar claro que el papel de un arquitecto puede ser realizado por un
ingeniero. Un objetivo de este documento es describir el papel - lo que debe
hacerse, sin importar el que la ejecuta. Por lo tanto, el papel del arquitecto se
puede resumir como a:
Conocer e interpretar los requisitos : investigar para obtener información,
escuchar a la información, influir en las personas, facilitar la creación de
consenso, sintetizar y traducir las ideas en acciones concretas requisitos,
articular esas ideas a los demás. Identificar el uso o propósito, las limitaciones,
riesgos, etc El arquitecto participa en el descubrimiento y la documentación de los
escenarios de negocio de los clientes que están impulsando la

  Página 639 de 670 

TOGOF 9.1    
solución. El arquitecto es el responsable de los requisitos de la comprensión y el
entendimiento de que los requisitos encarna en la especificación de la
arquitectura.  Crear un modelo de utilidad : tomar los requisitos y desarrollar
modelos bien formulados de los componentes de la solución, aumentando los modelos
según sea necesario para adaptarse a todas las circunstancias. Mostrar múltiples
puntos de vista a través de los modelos para comunicar las ideas de manera
efectiva. El arquitecto es responsable de la integridad de la arquitectura global y
el mantenimiento de la visión de la oferta desde una perspectiva arquitectónica. El
arquitecto también garantiza oportunidades de apalancamiento se identifican,
utilizando bloques de construcción, y es un enlace entre los grupos funcionales
(sobre todo de desarrollo y comercialización) para garantizar que las oportunidades
de apalancamiento se realicen. El arquitecto proporciona y mantiene estos modelos
como un marco para entender el dominio (s) del trabajo de desarrollo, guiando a lo
que debe hacerse dentro de la organización o fuera de la organización. El
arquitecto debe representar la opinión de la organización de la arquitectura
mediante la comprensión de todos los componentes necesarios del negocio.  Validar,
refinar y expandir el modelo : verificar las hipótesis, traer expertos en la
materia, etc con el fin de mejorar el modelo y definir con mayor precisión,
añadiendo nuevas ideas necesarias para que el resultado sea más flexible y más
estrechamente ligado a la corriente y requisitos previstos. El arquitecto, además,
debe evaluar el valor de los desarrollos de soluciones de mejora que emanan del
trabajo de campo y de incorporarlos en los modelos de arquitectura, según
corresponda.  Gestione la arquitectura : un seguimiento continuo de los modelos y
actualizarlos si es necesario para mostrar los cambios, adiciones y
alteraciones.Representar a la arquitectura y problemas durante el desarrollo y toma
los puntos del programa. El arquitecto es un "agente de cambio", lo que supone que
la necesidad de la puesta en práctica de la arquitectura. A través de este ciclo de
desarrollo, el arquitecto promueve continuamente la puesta en común de los
clientes, la arquitectura y la información técnica entre las organizaciones. 

52.6.2 Caracterización en términos de la Empresa Continuum

Bajo ciertas circunstancias, la complejidad de una solución puede requerir

arquitectos adicionales para apoyar el esfuerzo de la arquitectura. Las diferentes
categorías de arquitectos se describen a continuación, pero como son arquitectos,
todos ellos realizan las tareas descritas anteriormente. Cualquier combinación de
empresas, soluciones empresariales y soluciones de arquitectos puede ser utilizada,
como un equipo. En estos casos, cada miembro puede tener un enfoque específico, si
las funciones y responsabilidades que no son específicas, dentro de las fases del
proceso de desarrollo. En los casos en que sea necesario un equipo de arquitectos,
un arquitecto de la empresa principal debe ser asignado para gestionar y dirigir a
los miembros del equipo.
El Enterprise Architect tiene la responsabilidad para el diseño arquitectónico y la
documentación en un paisaje y técnico nivel del modelo de referencia. El Enterprise
Architect a menudo conduce a un grupo de los Arquitectos del segmento y / o
arquitectos de soluciones relacionadas con un programa determinado. El enfoque de
la EA está en funciones de negocios a nivel de empresa necesarios. 

  Página 640 de 670 

TOGOF 9.1    
El Arquitecto segmento tiene la responsabilidad para el diseño arquitectónico y la
documentación de los problemas o las organizaciones empresariales específicas. Un
Arquitecto Segmento re-utiliza la salida de todos los otros arquitectos, uniéndose
a las soluciones técnicas detalladas en el paisaje arquitectónico general. El
enfoque del Arquitecto segmento está en las soluciones de negocio a nivel de
empresa en un determinado dominio, tales como finanzas, recursos humanos, ventas,
etc  El arquitecto de la solución tiene la responsabilidad para el diseño
arquitectónico y la documentación en un sistema o subsistema, como la gestión o la
seguridad. Un arquitecto de la solución puede blindar el Enterprise Architect /
Segmento de los detalles innecesarios de los sistemas, productos y / o
tecnologías.El enfoque del arquitecto de soluciones en las soluciones de tecnología
de sistema; Por ejemplo, un componente de una solución tal como el almacenamiento
de datos de la empresa. 

52.6.3 Características clave de un Enterprise Architect

52.6.3.1 habilidades y experiencia en la producción de diseños

Un arquitecto de la empresa deben ser competentes en las técnicas que intervienen

en la producción de diseños de sistemas complejos, incluidos los requisitos de
descubrimiento y el análisis, la formulación de solución contexto, la
identificación de alternativas de solución y su evaluación, selección de
tecnología, y la configuración de diseño.
52.6.3.2 Amplia Manga Técnica, con la profundidad técnica en uno o unos pocos
Disciplinas

Un arquitecto de la empresa debe poseer una extensa amplitud técnica a través de la

experiencia en la industria de TI. Esta amplitud debe ser en áreas de desarrollo y
despliegue de aplicaciones, y en las áreas de creación y mantenimiento de la
infraestructura para apoyar el entorno de aplicaciones complejas. Entornos de TI
actuales son heterogéneos por naturaleza, y el arquitecto de la empresa con
experiencia tendrán habilidades a través de múltiples plataformas, incluyendo los
sistemas distribuidos y entornos de mainframe tradicionales. Arquitectos
empresariales tendrán, como resultado de su carrera, las habilidades en al menos
una disciplina que se considera que está en el nivel de un experto en la materia.
52.6.3.3 Método Enfoque determinado de Ejecución

Los arquitectos de la empresa se acercan a su trabajo a través del uso constante de

los métodos de diseño reconocidas, como la Arquitectura Método de Desarrollo TOGAF
(ADM). Los arquitectos de la empresa deben tener conocimiento de trabajo de más de
un método de diseño y ser confortables partes Implementación de métodos apropiados
para la situación en la que están trabajando trabajando. Esto debe considerarse en
el cuerpo de trabajo de diseño de la empresa arquitecto ha producido a través de
uso exitoso repetida de más de un método de diseño. La habilidad en el uso la
metodología está en saber qué partes de los métodos a utilizar en una situación
dada, y qué métodos no utilizar.
52.6.3.4 Completa Experiencia del Alcance del Proyecto

  Página 641 de 670 

TOGOF 9.1    

Mientras los arquitectos empresariales son responsables del diseño y de la mano-off

del proyecto a los ejecutores, es vital que tengan experiencia en todos los
aspectos de un proyecto, desde el diseño hasta el desarrollo, prueba,
implementación y producción. Este ámbito de aplicación de la experiencia servirá
para mantener los arquitectos empresariales basadas en la noción de la aptitud para
el propósito y el carácter práctico de la implementación del sistema. El impacto de
la experiencia completa del alcance del proyecto debe liderar el arquitecto
empresarial para tomar mejores decisiones de diseño, e informar mejor a los
intercambios realizados en esas decisiones.
52.6.3.5 Liderazgo

Comunicación y trabajo en equipo son clave para el papel exitoso de la empresa

arquitecto. La mezcla de buena habilidad técnica y la capacidad de conducir son
cruciales para el trabajo. El arquitecto de la empresa debe ser visto como un líder
en la empresa mediante la organización de TI, los clientes que sirven, y la
gestión.
52.6.3.6 Habilidades Personales y Profesionales

El arquitecto de la empresa debe tener las comunicaciones sólidas y habilidades de

relación. Una de las principales tareas de la empresa arquitecto es comunicar
información técnica compleja para todos los interesados del proyecto, incluidos los
que no tienen una formación técnica. También se requiere que la negociación fuerte
y habilidades de resolución de problemas. El arquitecto de la empresa debe trabajar
con el equipo de gestión del proyecto para tomar decisiones de manera oportuna para
mantener los proyectos en marcha.

52.6.3.7 habilidades y experiencia en una o más industrias

La habilidad de la Industria y la experiencia harán que la tarea de reunir los

requisitos y decidir las prioridades más fácil y efectivo para la EA. Los
arquitectos de la empresa deben entender los procesos de negocio de la empresa en
la que trabajan, y cómo esos procesos trabajan con otras empresas de pares en la
industria.También debe ser capaz de detectar las principales tendencias y procesos
viciados correctas, dando a la organización de TI la capacidad de dirigir la
empresa, no sólo responder a las solicitudes. La misión de la empresa es arquitecto
liderazgo técnico estratégico.

52.7 Conclusiones
El TOGAF Arquitectura Skills Framework proporciona una evaluación de las
habilidades necesarias para ofrecer una exitosa arquitectura empresarial.

  Página 642 de 670 

TOGOF 9.1    

Se espera que la prestación de este Skills Framework Architecture le ayudará a

reducir el tiempo, costo y riesgo involucrado en la formación, la contratación y la
gestión de profesionales de la arquitectura de TI, y al mismo tiempo permitir y
animar a más organizaciones para instituir una estructura de funcionamiento interno
de TI , es de esperar en base a (o por lo menos apalancamiento) la función y las
definiciones de habilidad siempre.

L 

  Página 643 de 670 

TOGOF 9.1    

  

Apéndices

 
  Página 644 de 670 

TOGOF 9.1      

  

A. Glosario de Definiciones complementarias

Este apéndice contiene definiciones adicionales para complementar las definiciones
contenidas en el 3. Definiciones .

A.1 de control de acceso (AC)

Un servicio de seguridad que garantiza que sólo los usuarios con los derechos
correctos puede acceder a determinados dispositivos, aplicaciones o datos.

A.2 Ada
Un lenguaje de programación de alto nivel desarrollado por el Departamento de
Defensa de EE.UU. ( DoD ) y ampliamente utilizado en los países del Departamento de
Defensa y de la OTAN. Se utiliza para el procesamiento en tiempo real, es de
naturaleza modular, e incluye características orientadas a objetos.

Componente de aplicación A.3

Una encapsulación de funcionalidad de la aplicación alineado con estructura de
ejecución. Por ejemplo, una aplicación de procesamiento de solicitud de compra. Ver
también A.50 Lógico componente de aplicación y A.63 Física componente de aplicación
.

Software de Aplicación A.4

Entidades de software que tienen un fin comercial específico.

A.5 Disponibilidad
En el contexto de los sistemas de TI, la probabilidad de que las capacidades
funcionales del sistema están listos para su uso por un usuario en cualquier
momento, en donde se considera todos los tiempos, incluyendo operaciones,
reparación, administración y tiempo de logística. La disponibilidad se define
además por categoría sistema tanto para las operaciones de rutina y prioritarios.

Procesamiento por lotes A.6

  Página 645 de 670 

TOGOF 9.1    

Procesamiento de los datos o la realización de trabajos acumulados con antelación,

de tal manera que cada acumulación así formado se procesa o se lleva a cabo en la
misma computadora funcione.

A.7 Business System

Hardware, software, declaraciones de políticas, procesos, actividades, normas, y
las personas que en conjunto implementan una función de negocios.

Catálogo A.8
Una lista estructurada de los productos arquitectónicos de un tipo similar, que se
utiliza como referencia. Por ejemplo, a las normas de tecnología catálogo o un
portafolio de aplicaciones.

A.9 Cliente
Un componente de la aplicación que solicita los servicios de un servidor.
A.10 COBIT
Es el acrónimo de Objetivos de Control para la Información y Tecnologías
Relacionadas, creado por la Asociación de Sistemas de Información de Auditoría y
Control (ISACA) y el IT Governance Institute (ITGI), que proporciona un conjunto de
mejores prácticas recomendadas para la gestión / administración de los sistemas de
información y tecnología .

A.11 Red de Comunicaciones

Un conjunto de productos, conceptos y servicios que permiten la conexión de los
sistemas informáticos con el fin de transmitir datos y otras formas (por ejemplo,
voz y video) entre los sistemas.

A.12 Comunicaciones Nodo

Un nodo que es ya sea interna a la red de comunicaciones (por ejemplo, enrutadores,
puentes, o repetidores) o situado entre el dispositivo final y la red de
comunicaciones para operar como una puerta de enlace.

Sistema A.13 Comunicaciones

Un conjunto de activos (medios de transmisión, los nodos de conmutación, interfaces
y dispositivos de control) que establecerá vínculos entre usuarios y dispositivos.
  Página 646 de 670 

TOGOF 9.1    

A.14 de aplicaciones compuestas

Un componente de aplicación que se crea mediante la composición de otras
aplicaciones atómicas o compuestos.

A.15 Configuration Management

Una disciplina aplicando dirección técnica y administrativa y la vigilancia de:
Identificar y documentar las características funcionales y físicas de un elemento
de configuración  Los cambios de control a esas características  Registrar y
comunicar los cambios en el procesamiento y el estado de aplicación 

Además, la gestión de la configuración de la arquitectura de la práctica de la

empresa (de propiedad intelectual) los activos y líneas de base y el control de
cambio a lo largo de esos activos.

A.16 Servicio de conectividad

Un área de servicio de la entidad ambiente externo del modelo de referencia técnica
(TRM) que proporciona conectividad de extremo a extremo para las comunicaciones a
través de tres niveles de transporte (global, regional y local). Proporciona
servicios generales y específicos de la aplicación a finales de plataforma
dispositivos.

Contrato A.17
Un acuerdo entre un consumidor de servicios y un proveedor de servicios que
establece los parámetros funcionales y no funcionales para la interacción.

Control A.18
Un paso de toma de decisiones con el acompañamiento de la lógica de decisión
utilizado para determinar el enfoque de ejecución de un proceso o para asegurar que
un proceso cumple con los criterios de gobierno. Por ejemplo, un control de cierre
de sesión en el proceso de tramitación de solicitud de compra que comprueba si el
valor total de la solicitud está dentro de los límites de sesión fuera de la
solicitante, o si necesita una escalada a la autoridad superior.
A.19 CxO
El oficial en jefe dentro de una función particular de la empresa; por ejemplo, el
Director Ejecutivo, Director Financiero, Director de Información, Director de
Tecnología.
  Página 647 de 670 

TOGOF 9.1    

Diccionario de datos A.20

Un tipo especializado de base de datos que contiene metadatos; un repositorio de
información que describe las características de los datos que se utilizan para
diseñar, monitorear, documentar, proteger y controlar los datos en los sistemas de
información y bases de datos; un sistema de aplicación de apoyo a la definición y
gestión de metadatos de la base de datos.

Elemento de datos A.21

Una unidad básica de información que tiene un significado y que puede tener
subcategorías (elementos de datos) de las unidades y valores distintos.

A.22 Entity Data

Una encapsulación de datos que es reconocido por un experto de dominio de negocios
como una cosa. entidades de datos lógicos se puede atar a las aplicaciones,
repositorios y servicios y puede ser estructurada de acuerdo a consideraciones de
implementación.

A.23 de datos de servicio de intercambio

Un servicio de la entidad de plataforma del modelo de referencia técnica (TRM) que
proporciona apoyo especializado para el intercambio de datos entre aplicaciones en
el mismo o en diferentes plataformas.

A.24 Servicio de Gestión de Datos

Un servicio de la entidad de plataforma del modelo de referencia técnica (TRM) que
brinda apoyo a la gestión, el almacenamiento, el acceso y la manipulación de los
datos en una base de datos.

Base de datos A.25

Una colección estructurada u organizada de entidades de datos, la cual se puede
acceder por un ordenador.

A.26 Sistema de Gestión de Base de Datos

Un programa de aplicación de ordenador que tenga acceso o manipula la base de
datos.

Servicio de directorio A.27

  Página 648 de 670 

TOGOF 9.1    

Un componente de tecnología que ofrece servicios de localización que se encuentran

la ubicación de un servicio, o la ubicación de los datos, o la traducción de un
nombre común en una dirección específica de la red. Es análogo a los libros de
teléfono y se puede implementar en esquemas centralizados o distribuidos.

Base de datos distribuida A.28

1. Una base de datos que no se almacena en una ubicación central, pero se dispersa
a través de una red de ordenadores interconectados.  2. Una base de datos bajo el
control total de un sistema de gestión de base de datos central
(DBMS), pero cuyos dispositivos de almacenamiento no están adscritos a un mismo
procesador. 

3. Una base de datos que se encuentra físicamente en dos o más lugares distintos. 

A.29 Conductor
Una condición externa o interna que motiva a la organización a definir sus metas.
Un ejemplo de un controlador externo es un cambio en la normativa que regula el
cumplimiento o que, por ejemplo, requieren cambios en la forma en que una
organización opera; es decir, la Ley Sarbanes-Oxley en los EE.UU..

A.30 para el usuario final

Persona que, en última instancia utiliza la aplicación informática o salida.

Planificación de recursos empresariales A.31 (PIR)

Una suite completa de aplicaciones integradas que soportan las principales
funciones de apoyo empresarial de una organización; por ejemplo, Financiera (AP /
AR / GL), recursos humanos, nómina, inventario, procesamiento de pedidos y
facturación, Compras, Logística, Producción, etc

A.32 Evento
Un cambio de estado de la organización que desencadena eventos de procesamiento
puede provenir de dentro o fuera de la organización y puede ser resuelto dentro o
fuera de la organización.

A.33 Interfaz Ambiente Externo (EEI)

La interfaz que soporta la transferencia de información entre la plataforma de
aplicación y el ambiente externo.
  Página 649 de 670 

TOGOF 9.1    

A.34 FORTRAN
Es el acrónimo de traductor fórmula, que es un lenguaje de programación de alto
nivel utilizado ampliamente en aplicaciones científicas y de ingeniería.

A.35 Descomposición Funcional

Una jerarquía de las funciones de una empresa u organización.

A.36 Meta
Una declaración de alto nivel de la intención o la dirección de una organización.
Normalmente se utiliza para medir el éxito de una organización.

Directriz A.37
Un documento de arquitectura que ofrece orientación sobre el mejor modo de llevar a
cabo actividades de diseño o de implementación.

A.38 Hardware
La infraestructura física necesaria para ejecutar el software; por ejemplo,
servidores, estaciones de trabajo, equipos de red, etc

A.39 Interfaz Hombre-Computadora (HCI)

Hardware y software que permite el intercambio de información entre el usuario y el
ordenador.

A.40 Información del dominio

Agrupación de la información (o entidades de datos) mediante una serie de criterios
tales como la clasificación de seguridad, propiedad, ubicación, etc En el contexto
de la seguridad, los dominios de información se definen como un conjunto de
usuarios, sus objetos de información, y una política de seguridad.

Sistema de Información A.41 (IS)

La porción de la computadora (o IT) basado en un sistema de negocio.

Servicio de Sistema de Información A.42

  Página 650 de 670 

TOGOF 9.1    

Los elementos automáticos de un servicio empresarial. Hay un servicio de sistema de

información pueden ofrecer o apoyar la totalidad o parte de uno o varios servicios
de oficina.

Interacción A.43
Una relación entre los bloques de construcción de arquitectura (es decir, servicios
o componentes) que encarna la comunicación o utilización.

A.44 Modelo de Interacción

Una vista arquitectónico, catálogo, o una matriz que muestra un tipo particular de
interacción. Por ejemplo, un diagrama que muestra la integración de aplicaciones.

A.45 Interface
Interconexión e interrelaciones entre, por ejemplo, personas, sistemas,
dispositivos, aplicaciones o el usuario y una aplicación o dispositivo.

A.46 ITIL
Es el acrónimo de Information Technology Infrastructure Library, que proporciona un
conjunto de mejores prácticas recomendadas para la gestión / administración de los
sistemas de información y tecnología.

A.47 indicador clave de rendimiento (KPI)

Una forma de cuantificar el desempeño del negocio o proyecto.

A.48 Ciclo de Vida

El período de tiempo que comienza cuando un sistema está concebido y termina cuando
el sistema ya no está disponible para su uso.

A.49 Ubicación
Un lugar donde la actividad empresarial se lleva a cabo y se puede descomponer
jerárquicamente.

Componente de aplicación A.50 Lógico

  Página 651 de 670 

TOGOF 9.1    

Una encapsulación de funcionalidad de la aplicación que es independiente de una

implementación particular. Por ejemplo, la clasificación de todas las aplicaciones
de procesamiento de solicitud de compra implementados en una empresa.

Componente de datos A.51 Lógico

Una zona de frontera que encapsula las entidades de datos relacionados para formar
una ubicación lógica que se celebrará. Por ejemplo, la información de
aprovisionamiento externo.

A.52 Lógico Componente Tecnología

Una encapsulación de la infraestructura de tecnología que es independiente de un
producto en particular. Una clase de producto de tecnología. Por ejemplo, el
software de gestión de la cadena de suministro, como parte de un sistema de
planificación de recursos empresariales (ERP) suite o una solicitud de compra
Commercial Off-The-Shelf (COTS) servicios de empresa de procesamiento.

A.53 Administración de Programas Exitosos (MSP)

Una metodología de mejores prácticas para la gestión del programa, desarrollado por
la Oficina del Reino Unido de Comercio Gubernamental (OGC).

Matrix A.54
Un formato para mostrar la relación entre dos (o más) elementos arquitectónicos en
un formato de cuadrícula.

A.55 Medida
Un indicador o factor que se puede controlar, por lo general en forma permanente,
para determinar el éxito o el alineamiento con los objetivos y metas.

A.56 Metaview
A MetaView actúa como un patrón o plantilla de la vista, desde el que desarrollar
puntos de vista individuales. A MetaView establece los propósitos y audiencias para
una vista, las formas en que se documenta la vista (por ejemplo, para el modelado
visual), y las formas en las que se utiliza (por ejemplo, para el análisis). Ver
también 3.76 Punto de vista en 3. Definiciones .

A.57 Servicio Multimedia

  Página 652 de 670 

TOGOF 9.1    

Un servicio del modelo de referencia técnica (TRM) que proporciona la capacidad

para manipular y administrar los productos de información que consta de texto,
gráficos, imágenes, vídeo y audio.

A.58 Especificaciones Abiertas

Especificaciones públicas que son mantenidos por un proceso de consenso abierto y
público para dar cabida a las nuevas tecnologías a través del tiempo y que son
consistentes con las normas internacionales.

A.59 Sistema Abierto

Un sistema que implementa las especificaciones abiertas suficientes para
interfaces, servicios y formatos de apoyo que permitan la aplicación de software
diseñada correctamente:
Para ser portado con cambios mínimos a través de una amplia gama de sistemas  Para
interoperar con otras aplicaciones en sistemas locales y remotos  Para interactuar
con los usuarios en un estilo que facilita la portabilidad de usuario 

Gobernanza Operacional A.60

Gobernabilidad Operacional analiza el desempeño operacional de los sistemas frente
a los niveles contratados rendimiento, la definición de los niveles de rendimiento
operativo y la implementación de sistemas que garanticen el funcionamiento eficaz
de los sistemas. Ver también 3.39 Gobernanza en 3. Definiciones .

A.61 Servicio del Sistema Operativo

Un servicio básico de la entidad plataforma de aplicación del Modelo de Referencia
Técnica (TRM) que se necesita para operar y administrar la plataforma de
aplicaciones y proporcionar una interfaz entre el software de aplicación y la
plataforma (por ejemplo, gestión de archivos, entrada / salida, colas de
impresión ).

Servicios A.62 Packaged

Servicios que se adquieren en el mercado de un Comercial Off-The-Shelf (COTS) de
los proveedores, en lugar de ser construido a través del código de construcción.

A.63 Física componente de aplicación

  Página 653 de 670 

TOGOF 9.1    

Una aplicación, módulo de aplicación, servicios de aplicaciones, u otro componente

de despliegue de la funcionalidad. Por ejemplo, una instancia de una Commercial
Off-TheShelf (COTS) Planificación de recursos empresariales (ERP) de alimentación
configurado y desplegado la aplicación de gestión de la cadena.

A.64 Componente Físico de Datos

Una zona de frontera que encapsula las entidades de datos relacionados para formar
un lugar físico que se celebrará. Por ejemplo, un objeto de negocio de la orden de
compra, que comprende encabezado de la orden de compra y nodos de objetos de
negocios artículo.

A.65 Tecnología Componente Físico

Un producto de infraestructura de tecnología o la tecnología instancia de producto
infraestructura. Por ejemplo, un determinado modelo de una solución comercial Off-
TheShelf (COTS), o de una marca específica y la versión del servidor.

A.66 Portabilidad
1. La facilidad con la que un sistema, componente, datos, o el usuario pueden ser
transferidos de un hardware o entorno de software a otro.  2. Una métrica de
calidad que se puede utilizar para medir el esfuerzo relativo para
transportar el software para su uso en otro entorno o para convertir de software
para su uso en otro entorno operativo, la configuración de hardware, o entorno de
sistema de software. 

A.67 Portafolio
El conjunto completo de las actividades de cambio o sistemas que existen dentro de
la organización o parte de la organización. Por ejemplo, la cartera de aplicaciones
y la cartera de proyectos.

A.68 PRINCE2
Es el acrónimo de proyectos en ambientes controlados, que es un método de gestión
de proyectos estándar.

Proceso A.69
Un proceso representa una secuencia de actividades que en conjunto logran un
resultado determinado, puede descomponerse en sub-procesos, y puede mostrar el
funcionamiento de una función o servicio (en el siguiente nivel de detalle). Los
procesos también pueden ser utilizados para conectar o componer organizaciones,
funciones, servicios y procesos.
  Página 654 de 670 

TOGOF 9.1    
A.70 Producto
La salida generada por el negocio. El producto de negocios de la ejecución de un
proceso.

A.71 Perfil
Un conjunto de una o más normas básicas y, en su caso, la identificación de las
anteriores clases, subconjuntos, opciones y parámetros de esas normas básicas,
necesarias para el cumplimiento de una función determinada.

A.72 Profiling
La identificación de las normas y características de un sistema en particular.

Programa A.73
Un conjunto coordinado de proyectos de cambio que ofrecen el beneficio empresarial
a la organización.

A.74 Proyecto
Un proyecto de cambio único, que ofrece el beneficio empresarial a la organización.

Gestión de Riesgos A.75

La gestión de los riesgos y problemas que pueden amenazar el éxito de la estructura
de funcionamiento de la empresa y su capacidad de cumplir es la visión, metas y
objetivos, y, sobre todo, de su prestación de servicios.
Nota:  La gestión de riesgos se describe en la Parte III ,
31. Gestión de Riesgos . 

A.76 Escalabilidad
La capacidad de usar el mismo software de aplicación en muchas clases diferentes de
plataformas de hardware / software de PC para-super computadoras (extiende el
concepto de portabilidad). La capacidad de crecer para dar cabida a mayores cargas
de trabajo.

A.77 Seguridad
Servicios que protegen los datos, garantizando su confidencialidad, disponibilidad
e integridad.
  Página 655 de 670 

TOGOF 9.1    

A.78 Servidor
Un componente de aplicación que responde a las peticiones de un cliente.

Servicio A.79
Una representación lógica de una actividad de negocio repetible que tiene un
resultado específico. Un servicio es autónomo, puede estar compuesto por otros
servicios, y es un "recuadro negro" a sus consumidores. Algunos ejemplos son
"verificación de crédito del cliente", "proporcionar datos meteorológicos", y
"consolidar los informes de perforación".

A.80 Servicio Calidad

Una configuración preestablecida de atributos no funcionales que pueden ser
asignadas a un servicio o contrato de servicio.

A.81 INTELIGENTE
Es el acrónimo de específicos, medibles, alcanzables, realistas y de duración
determinada, que es un enfoque para asegurar que las metas y objetivos se
establecen de manera que se puede lograr y medir.
Gestión de Proveedores A.82
La gestión de los proveedores de productos y servicios para la práctica de la
arquitectura de la empresa de común acuerdo con las actividades de adquisición de
empresas más grandes.

Sistema A.83
Una colección de componentes organizados para cumplir una función específica o un
conjunto de funciones (fuente: ISO / IEC 42010:2007).

Sistema A.84 y el Servicio de Gestión de Red

Un servicio de la entidad de plataforma de aplicación del Modelo de Referencia
Técnica (TRM), que proporciona la administración del sistema de información global
cruzada categoría. Estos servicios incluyen la gestión de la información, los
procesadores, redes, configuraciones, contabilidad y rendimiento.

A.85 Sistema Stakeholder

Un individuo, equipo u organización (o clases de los mismos) con intereses en, o
preocupaciones con respecto a un sistema (fuente: ISO / IEC 42010:2007).
  Página 656 de 670 

TOGOF 9.1    

A.86 Tecnología Componente

Una encapsulación de infraestructura tecnológica que representa una clase de
producto de la tecnología o producto de tecnología específica.

A.87 Período de tiempo

El plazo durante el cual el impacto potencial se va a medir.

A.88 Transacción
La interacción entre un usuario y un ordenador en el que el usuario introduce una
orden para recibir un resultado específico de la computadora.

Transacción Secuencia A.89

Orden de las operaciones necesarias para lograr los resultados deseados.

A.90 Use-Case
Una vista de la organización, aplicación o funcionalidad del producto que ilustra
las capacidades en contexto con el usuario de esa capacidad.

A.91 usuario
1. Cualquier persona, organización o unidad funcional que utiliza los servicios de
un sistema de procesamiento de información.  2. En un lenguaje de esquema
conceptual, cualquier persona o cualquier cosa que puede emitir o recibir órdenes y
mensajes hacia o desde el sistema de información. 

A.92 Servicio Interfaz de usuario

Un servicio de la entidad de plataforma de aplicación del Modelo de Referencia
Técnica (TRM) que soporta la interacción directa hombre-máquina mediante el control
del medio ambiente en el que los usuarios interactúan con las aplicaciones.

  Página 657 de 670 

TOGOF 9.1    

  
B. Abreviaturas
ABB  Arquitectura Bloque de construcción  Corriente alterna  Control de Acceso 
ACL  Lista de Control de Acceso  ACMM  Arquitectura Capability Maturity Model 
ACSE  Elemento de servicio de control de asociación  ADM  Arquitectura Método de
Desarrollo  ANSI  American National Standards Institute  API  Interface Application
Platform  ARTES  Asociación de Estándares de Tecnología Retail  BMM  Motivación
Modelo de Negocio  BPM  Gestión de Procesos de Negocio  BPMN  Business Process
Modeling Notation 

  Página 658 de 670 

TOGOF 9.1    
BTEP  El Programa Canadiense Enablement Transformación Empresas Gobierno  CAB 
Comité de Cambios  CCITT  Comité Consultivo sobre Telégrafos y Teléfonos, ahora
conocido como la Unión Internacional de Telecomunicaciones (UIT)  CI  Elementos de
Configuración  CIPR  Proceso Central de Información  CM  Gestión de la
Configuración  CMIP  Protocolo de Información de Gestión Común  CMIS  Gestión de la
Información del Servicio Común  CMM  Modelos de Madurez de Capacidad  CMMI 
Capability Maturity Model Integration  CN  Red de Comunicaciones  COBIT  Objetivos
de Control para la Información y Tecnologías Relacionadas  CODASYL  Conferencia
sobre Sistemas de Datos de Idiomas  CORBA 

  Página 659 de 670 

TOGOF 9.1    
Common Object Request Broker Architecture  COTS  Aplicaciones Comercial Off-The-
Shelf  CRM  Customer Relationship Management  CRUD  Crear / Leer / Actualizar /
Eliminar  CSF  Factor Clave de Éxito  DAI  Data Access Interface  DBA  Database
Administrator  DBMS  Sistema de Gestión de Base de Datos  DCE  Distributed
Computing Environment  DDL  Data Definition Language  DISA  Departamento de Defensa
de la Agencia de Sistemas de Información de EE.UU.  DMF  Utilidad de gestión de
datos  DML  Manipulación de datos Idioma  DMTF  Distributed Management Task Force 

  Página 660 de 670 

TOGOF 9.1    
DNS  Sistema de nombres de dominio  DdC  Departamento de Comercio de EE.UU.  DoD 
Departamento de Defensa de EE.UU.  DoDAF  Departamento de Defensa de Arquitectura
de Marco  DRDA  Distributed Relational Database Architecture  EA  Arquitectura
Empresarial  EAI  Integración de Aplicaciones Empresariales  EDI  Intercambio
Electrónico de Datos  EEI  Interfaz Ambiente Externo  ERP  Planificación de
Recursos Empresariales  ES  Fin del sistema  ESB  Enterprise Service Bus  ETL 
Extraer, Transformar, Cargar  FEAF 

  Página 661 de 670 

TOGOF 9.1    
Federal Enterprise Architecture Framework  FICO  Fair Isaac Corporation  FORTRAN 
Traductor FORmula  FTE  Equivalente a Tiempo Completo  GOTS  Gobierno aplicaciones
Off-The-Shelf  GUI  Interfaz gráfica de usuario  HIPAA  Ley de Responsabilidad de
Seguro de Salud de Portabilidad y  ICAM  Fabricación Asistida por Ordenador
Integrado  ICD  Documento de Control de Interfaz  ICOM  Entradas, salidas,
controles y mecanismos / Recursos  IDEF  Ayudado Integrated Computer Manufacturing
(ICAM) Definición  IDL  Interfaz de lenguaje de descripción  IEC  Comisión
Electrotécnica Internacional  IEEE  Instituto de Ingenieros Eléctricos y
Electrónicos 

  Página 662 de 670 

TOGOF 9.1    
III  Infraestructura de Información Integrado  III-RM  Integrado de Información
Infraestructura Modelo de Referencia  IMS  Sistema de Gestión de la Información 
ISA  Information Systems Architecture  ISACA  Sistemas de Información Asociación de
Auditoría y Control de  ISACF  Sistemas de Información de Auditoría y Control
Foundation  ISAM  Indexado Método de acceso secuencial  ISO  Organización
Internacional de Normalización  Informática  Tecnología de la Información  ITGI  IT
Governance Institute  ITIL  Information Technology Infrastructure Library  ITPMF 
IT Management Facility Portafolio  UIT  Unión Internacional de Telecomunicaciones 
JMS 

  Página 663 de 670 

TOGOF 9.1    
Java Message Service  JVM  Java Virtual Machine  KPI  Indicador clave de
rendimiento  LAN  Red de Área Local  LCS  Sistema de Comunicación Local  LIPR 
Proceso de Información Local  LSE  Red local de abonado  MAN  Red de área
metropolitana  MDA  Model Driven Architecture  MIB  Bases de Información de
Gestión  MIS  Sistemas de Información Gerencial  MLS  Multi-Nivel de Seguridad 
MTA  Agente de transferencia de mensajes  NASCIO  Oficiales de la Asociación
Nacional de Estado Jefe de Información 

  Página 664 de 670 

TOGOF 9.1    
NIST  Instituto Nacional de Estándares y Tecnología  OAG  Abra Aplicaciones Group 
OAGIS  Abra Aplicaciones Grupo de Integración de Especificaciones  ODBC  Open
Database Connectivity  OCDE  Organización para la Cooperación y el Desarrollo  OGC 
Oficina de Comercio Gubernamental del Reino Unido  OLA  Acuerdo de Nivel
Operacional  OMB  Oficina de Administración y Presupuesto  OMG  Object Management
Group  OODBMS  Sistema de gestión de base de datos orientada a objetos  ORB  Object
Request Broker  OS  Sistema Operativo  OSE  Abrir entorno del sistema  OSI 

  Página 665 de 670 

TOGOF 9.1    
Interconexión de sistemas abiertos  OSOA  Arquitectura orientada a servicios  P-
CMM  Gente Capability Maturity Model  PDA  Asistente Digital Personal  PDF  Formato
de Documento Portátil  PEX  Extensión PHIGS al sistema X Window  PHIGS  Sistema
Gráfico Interactivo jerárquica del programador  PMI  Iniciativa de Gestión de
Proyectos  PMBOK  Proyecto Organismo de Gestión del Conocimiento  PRINCE  Proyectos
en ambientes controlados  QoS  Calidad de servicio  RACI  Responsable, Responsable,
Consultado, Informado  RAS  Servicios de acceso remoto  RDA  Acceso base de datos
remota 

  Página 666 de 670 

TOGOF 9.1    
RDBMS  Relational Database Management System  REA  Recursos-Event-Agent  RFC 
Solicitud para el Cambio  RFI  Solicitud de Información  RFP  Solicitud de
Propuesta  RFQ  Solicitud de Cotización  RM  Modelo de Referencia  RM-ODP  Modelo
de referencia ISO para el Procesamiento distribuido abierto  RPC  Llamada a
procedimiento remoto  RS  Relay System  SA-CMM  Software de Adquisición de
Capability Maturity Model  SBB  Solución Módulo  SCAMPI  Estándar CMMI método de
valoración para la Mejora de Procesos  SDO 

  Página 667 de 670 

TOGOF 9.1    
Service Data Objects  SEI  Instituto de Ingeniería de Software  SGML  Standard
Generalized Markup Language  SIB  Normas de Información de Base  SCA  Service
Component Architecture  SCAMPI  CMMI método de valoración para la Mejora de
Procesos  SLA  Acuerdo de Nivel de Servicio  SMAP  Proceso de solicitud de Gestión
de la Seguridad  INTELIGENTE  Específicos, medibles, alcanzables, realistas y de
duración determinada  SMTP  Simple Mail Transfer Protocol  SNA  Arquitectura de red
de Sistema  SNMP  Simple Network Management Protocol  SOA  Arquitectura Orientada a
Servicios  SPEM  Processing Software Engineering Metamodel 

  Página 668 de 670 

TOGOF 9.1    
SQL  Structured Query Language  PASO  Estándar para el intercambio de datos y el
modelo del producto  SWG  Grupo de Trabajo Especial  SysML  Sistemas Modeling
Language  TADG  Tesoro Arquitectura Orientación Desarrollo  TAFIM  Marco de
Arquitectura Técnica para la Gestión de la Información  TCP / IP  / Protocolo de
Internet Transmission Control Protocol  TISAF  Sistema de Información de Hacienda
Architecture Framework  TRM  Referencia técnica del Modelo  TFA  Transparente de
acceso a archivos  TLSP  Protocolo de seguridad de nivel de transporte  TMF 
TeleManagement Forum  TP  Procesamiento de transacciones  UML 

  Página 669 de 670 

TOGOF 9.1    
Unified Modeling Language  UN / CEFACT  Centro de las Naciones Unidas para la
Facilitación del Comercio y las Transacciones Electrónicas  UN / EDIFACT  Naciones
Unidas / Intercambio Electrónico de Datos para la Administración, Comercio y
Transporte  WAN  Red de Área Amplia  WSDL  Web Services Description Language  XML 
Extensible Markup Language  XSD  Definición de esquemas XML 

  Página 670 de 670