Togaf 9 1 Parte Ii

The Open Group Architecture Framework
TOGOF9.1
PARTE II
Mtodo
Arquitectura
Desarrollo
Pgina41de670
TOGOF9.1
5. Introduccin
En este captulo se describe el ciclo de Arquitectura Mtodo de Desarrollo (ADM), la adaptacin de
la ADM, alcance la arquitectura, y la integracin de la arquitectura.
5.1 Descripcin general de ADM

El TOGAF ADM es el resultado de continuos aportes de un gran nmero de profesionales de la
arquitectura. En l se describe un mtodo para desarrollar y gestionar el ciclo de vida de una
empresa de arquitectura, y constituye el ncleo de TOGAF. Integra elementos de TOGAF descritos
en este documento, as como otros activos arquitectnicos disponibles, para cumplir con el negocio
y las necesidades de TI de una organizacin.
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 ejecucin 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 arquitectnico - tanto los contenidos de
la de la organizacin propios repositorios empresariales y el conjunto de modelos de referencia
disponibles relevantes y los estndares de la industria.
La aplicacin prctica de la Empresa Continuum normalmente tomar la forma de un depsito de

Arquitectura (vase 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 arquitectnica real realizado previamente dentro de la empresa. El arquitecto tratara de
volver a utilizar la mayor cantidad posible del Repositorio Arquitectura que era relevante para el
proyecto en cuestin. (Adems de la coleccin de material original de la arquitectura, el repositorio
contendr tambin 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 tecnologa - esto puede ser la
Fundacin 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 electrnico tomada de la industria en general.
Los criterios para la inclusin de los materiales bsicos de la arquitectura de repositorio de una
organizacin tpicamente formarn 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
Pgina42de670
TOGOF9.1
adaptar a las necesidades especficas de la empresa y tambin para determinar donde las
soluciones especficas se pueden generalizar a apoyar en general la reutilizacin.
Durante el uso de la ADM, el arquitecto est desarrollando una instantnea de las decisiones de la
empresa y sus implicaciones en puntos concretos de tiempo. Cada iteracin del ADM rellenar un
paisaje especfico de la organizacin con todos los activos de arquitectura identificados y ha
movilizado a travs del proceso, incluida la arquitectura especfica de la organizacin definitiva
entregada.
Arquitectura desarrollo es un proceso continuo y cclico, y en la ejecucin de la ADM repetidamente

en el tiempo, el arquitecto aade gradualmente ms y ms contenido a la Arquitectura del
repositorio de la organizacin. Aunque el objetivo principal de la ADM est en el desarrollo de la
arquitectura especfica de la empresa, en este contexto ms amplio de la ADM tambin puede ser
visto como el proceso de poblar propia arquitectura de repositorio de la empresa con bloques de
construccin reutilizables pertinentes tomadas de la "izquierda ", el lado ms genrico de la
Empresa Continuum.
De hecho, la primera ejecucin de la ADM a menudo ser la ms difcil, ya que los activos de
arquitectura disponibles para su reutilizacin sern 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 podran ser aprovechados para apoyar el
esfuerzo.
Ejecuciones posteriores sern ms fciles, ya que cada vez ms activos arquitectura identificarse,
se utilizan para rellenar Arquitectura Repositorio de la organizacin, y por tanto estn disponibles
para una futura reutilizacin.
5.1.2 El ADM y la Architecture Foundation
La ADM tambin 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 podra ser un conjunto de modelos
comunes reutilizables, definiciones de polticas y de gobierno, o incluso lo ms especfico anulando
selecciones tecnolgicas (por ejemplo, si el mandato de la ley). Poblacin 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 estn limitadas a las preocupaciones globales y
por lo tanto menos completa que para una empresa especfica.
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 Integracin .
5.1.3 ADM y lineamientos que apoyen y Tcnicas
Parte III: Directrices y Tcnicas de ADM es un conjunto de recursos - directrices, plantillas, listas
de verificacin y otros materiales detallados - que la aplicacin de soporte del TOGAF ADM.
Las directrices y las tcnicas individuales se describen por separado en la Parte III: Directrices y
Tcnicas 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 descripcin de la propia
ADM.
Pgina43de670
TOGOF9.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 (vase la
Parte III , 19. La aplicacin de iteracin para el ADM ). Para cada iteracin de la ADM, una
nueva decisin debe tomarse en cuanto a:
o La amplitud de la cobertura de la empresa a definir
o El nivel de detalle que se define
o La extensin del perodo de tiempo destinado a, incluyendo el nmero y extensin

de cualquier periodos de tiempo intermedios
o 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 deberan basarse en una evaluacin prctica 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 mtodo genrico, el ADM est destinado a ser utilizado por empresas en una
amplia variedad de diferentes geografas y se aplica en diferentes tipos de sectores
verticales / industria. Como tal, puede ser, pero no necesariamente tiene que ser, adaptado
a las necesidades especficas. Por ejemplo, puede ser utilizado en conjuncin con el
conjunto de entregables de otro marco, cuando stos han sido considerados para ser ms
apropiado para una organizacin especfica. (Por ejemplo, muchas agencias federales de
Estados Unidos han desarrollado marcos individuales que definen los entregables
especficos para sus necesidades del servicio en particular.)
Estas cuestiones se examinan en detalle en 5.3 Adaptacin de la ADM .
5.2.2 Estructura bsica
La estructura bsica de la ADM se muestra en la Figura 5-1 .
Pgina44de670
TOGOF9.1
A lo largo del ciclo de ADM, es necesario que haya validacin frecuente de resultados contra las
expectativas originales, tanto los de todo el ciclo de ADM, y aquellos para la fase particular del
proceso.
Figura51:ArquitecturaCiclodeDesarrollo
Las fases del ciclo de ADM se dividen adems 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 Descripcin
Desarrollar Arquitectura Target Descripcin
Realizar anlisis de las deficiencias
Definir los componentes de la hoja de ruta candidatos
Pgina45de670
TOGOF9.1

Resolver los impactos en la Arquitectura del Paisaje
Llevar a cabo una revisin formal de las partes interesadas
Finalizar la Arquitectura
Crear Arquitectura Definicin de documento
La fase de gestin de requisitos es una fase continua que asegura que cualquier cambio en los
requisitos son manejados a travs de los procesos de gobernanza adecuadas y reflejadas en todas
las dems fases.
Una empresa puede optar por grabar todos los nuevos requisitos, incluidos los que estn en el
mbito de la declaracin actual de Arquitectura de Trabajo a travs de un repositorio de requisitos
individuales.
Las fases del ciclo se describen en detalle en los siguientes captulos 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 travs de los nmeros de versin. En todos los casos, el esquema de numeracin de ADM se
proporciona como un ejemplo. Debe ser adaptado por el arquitecto para satisfacer las necesidades
de la organizacin y trabajar con las herramientas de arquitectura y bases empleadas por la
organizacin.
En particular, una convencin de numeracin de versiones se utiliza dentro de la ADM para ilustrar
la evolucin de la lnea de base y objetivo Arquitectura Definiciones. Tabla 5-1 describe cmo se
utiliza esta convencin.
Fase Entregable Contenido Versin Descripcin

A: Architecture Vision Arquitectura Negocios 0.1 Versin 0.1 indica que un esquema de
Visin Arquitectura alto nivel de la arquitectura est en su
lugar.
Datos 0.1 Versin 0.1 indica que un esquema de
Arquitectura alto nivel de la arquitectura est en su
lugar.
Aplicacin 0.1 Versin 0.1 indica que un esquema de
lugar.
Tecnologa de 0.1 Versin 0.1 indica que un esquema de
lugar.
B: Arquitectura de Arquitectura Negocios 1.0 Versin 1.0 indica una revisin formal, la
Negocios Definicin Arquitectura arquitectura detallada.
Documento
C: Sistemas de Arquitectura Datos 1.0 Versin 1.0 indica una revisin formal, la
Informacin Definicin Arquitectura arquitectura detallada.
Arquitectura Documento
Aplicacin 1.0 Versin 1.0 indica una revisin formal, la
Arquitectura arquitectura detallada.
D: Architecture Arquitectura Tecnologa de 1.0 Versin 1.0 indica una revisin formal, la
Pgina46de670
TOGOF9.1

Tecnologa Definicin Arquitectura arquitectura detallada.
Documento
Tabla51:Convencinde NumeracinADMVersion
5.3 Adaptacin de la ADM

El ADM es un mtodo genrico para el desarrollo de la arquitectura, que est diseado para hacer
frente a la mayor parte del sistema y los requisitos de organizacin. Sin embargo, a menudo ser
necesario modificar o ampliar el ADM para adaptarse a necesidades especficas. Una de las tareas
antes de aplicar la ADM es revisar sus componentes para la aplicabilidad y, a continuacin,
adaptarlos segn convenga a las circunstancias de la empresa individual. Esta actividad tambin
puede producir un ADM "especfica 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 continuacin, crear una visin de la Arquitectura es casi siempre esencial; y una
detallada arquitectura de negocio a menudo tiene que venir a continuacin, con el fin de apuntalar
la Architecture Vision, detalle el caso de negocios para el trabajo restante arquitectura, y asegurar
la participacin 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 lnea
de base se puede hacer antes de emprender la Arquitectura Empresarial.
El orden de las fases puede definirse tambin 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
solucin empaquetada, para que pueda implementarse rpidamente para permitir una respuesta
rpida a los cambios del mercado. En tal caso, la arquitectura de negocio (o al menos la realizacin
de la misma), as pueden seguir a la finalizacin de la Arquitectura de Sistemas de Informacin o
de la Tecnologa de la Arquitectura.
Otra razn 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 genrico en relacin con el Marco conocido
Zachman, u otro entorno de arquitectura empresarial que tiene un conjunto definido de
prestaciones especficas para un sector vertical, en particular: Gobierno, Defensa, e-Business ,
Telecomunicaciones, etc El ADM se ha diseado especficamente con este potencial de
integracin 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 gestin de los
programas estndar, tales como los de autorizacin, gestin de riesgos, la planificacin
empresarial y la presupuestacin, la planificacin del desarrollo, desarrollo de sistemas, y
las adquisiciones.
El ADM se encarg para su uso por un contratista principal o el plomo en una situacin de
la contratacin externa, y debe adaptarse para alcanzar un compromiso adecuado entre
las prcticas existentes del contratista y los requisitos de la empresa contratante.
Pgina47de670
TOGOF9.1
La empresa es una empresa pequea y mediana, y desea utilizar un mtodo "cut-down"

ms en sintona con el nivel reducido de recursos y la complejidad del sistema tpico de
dicho entorno.
La empresa es muy grande y complejo, que comprende muchas "empresas"

independientes, aunque interrelacionados dentro de un marco general de colaboracin de
negocios, y el mtodo de la arquitectura debe adaptarse a reconocer esto. Diferentes
enfoques para la planificacin y la integracin se pueden utilizar en tales casos, incluyendo
las siguientes (posiblemente en combinacin):
o La planificacin de arriba hacia abajo y el desarrollo - el diseo del conjunto de

meta-empresarial interconectado como una sola entidad (un ejercicio que
normalmente se extiende a los lmites del sentido prctico)
o Desarrollo de una arquitectura o "genrico" de "referencia", tpico de las empresas

dentro de la organizacin, pero que no representan ninguna empresa especfica,
que a su vez se espera que las empresas individuales de adaptacin con el fin de
producir una "instancia" arquitectura adaptada a la empresa de que se trate .
o Replicacin - el desarrollo de una arquitectura especfica 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 produccin, una arquitectura genrica para una

familia de productos se refiere a menudo como una "Lnea de Arquitectura ",y el proceso
anlogo al descrito anteriormente se denomina "(basado en la arquitectura) Lnea de
productos de ingeniera". El ADM se dirige principalmente a los arquitectos en las
empresas usuarias de TI, sino una organizacin de proveedores cuyos productos se basan
IT-bien podra desear para adaptarlo como un mtodo genrico para un desarrollo Lnea
de Producto Arquitectura.
5.4 Arquitectura de Gobierno

El ADM, ya sea adaptada por la organizacin 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 mtodo se est aplicando correctamente en todas las
fases de una arquitectura de desarrollo iteracin. 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 gestin de todos los artefactos arquitectnicos, la gobernanza y los procesos relacionados debe
apoyarse en un entorno controlado. Normalmente, esto se basa en uno o ms repositorios de
soporte de objeto con versiones y control de procesos y el estado.
Las principales reas de informacin que gestiona un repositorio de gobierno deben contener los
siguientes tipos de informacin:
Datos de referencia (garanta de los propios repositorios de la organizacin / empresa

Continuum, incluyendo los datos externos, por ejemplo, COBIT, ITIL): Se utiliza para la
orientacin y la instruccin durante la ejecucin del proyecto. Esto incluye los detalles de la
Pgina48de670
TOGOF9.1
informacin antes mencionados. Los datos de referencia incluye una descripcin de los
propios procedimientos de gobierno.
Estado de proceso : Toda la informacin 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.
Auditora de la informacin : 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
o Una referencia para la futura evolucin del proceso arquitectnico y el apoyo,

orientacin y prioridad
Los artefactos de gobierno y el proceso son ellos mismos parte de los contenidos de la
Arquitectura Repository.
5.5 La determinacin del alcance de la Arquitectura

Hay muchas razones para restringir (o restringir) el alcance de la actividad arquitectnica a realizar,
la mayora de los cuales se relacionan con los lmites en:
La autoridad para la organizacin del equipo de produccin 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 sera 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 estn trabajando
en actividades duplicadas o contradictorias.Tambin se requiere la definicin de reutilizacin y de
cumplimiento relaciones entre las particiones de arquitectura.
La divisin de la empresa y su actividad relacionada con la arquitectura-se analiza con ms detalle

en el 40. Arquitectura de particionamiento .
Cuatro dimensiones se suelen utilizar para definir y limitar el alcance de una arquitectura :
Amplitud : Cul 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
federacin de unidades organizativas que vlidamente podra considerarse
empresas en su propio derecho.
o La empresa moderna se extiende cada vez ms all de sus lmites tradicionales,

para abrazar una combinacin borrosa de la empresa comercial tradicional
combinado con proveedores, clientes y socios.
Pgina49de670
TOGOF9.1
Profundidad : En qu nivel de detalle debe ir el esfuerzo architecting? Cunto

arquitectura es "suficiente"? Cul es la adecuada delimitacin entre el esfuerzo de la
arquitectura y otras actividades relacionadas (diseo de sistemas, ingeniera de
sistemas, sistemas de desarrollo)?
Perodo de tiempo : Cul es el perodo de tiempo que debe ser articulada para la
Architecture Vision, y tiene sentido (en trminos de practicidad y recursos) para el mismo
perodo que se tratarn en la descripcin detallada arquitectura? Si no es as, cuntos
Arquitecturas Transicin se han de determinar, y cules son sus periodos de tiempo?
Arquitectura Dominios : Una descripcin completa de arquitectura empresarial debe

contener los cuatro dominios de la arquitectura (de negocios, datos, aplicaciones,
tecnologa), pero la realidad de los recursos y las limitaciones de tiempo a menudo
significan que no hay tiempo suficiente, la financiacin o los recursos para construir una de
arriba hacia abajo , todo incluido descripcin 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 trminos de amplitud,
profundidad y tiempo. Una vez que se comprendan estas dimensiones, una combinacin adecuada
de los dominios de arquitectura se puede seleccionar, apropiadas para el problema que se
aborde. Las tcnicas para el uso de la ADM para desarrollar una serie de arquitecturas
relacionadas se discuten en 20. Aplicando la ADM a travs de la arquitectura del paisaje .
Las cuatro dimensiones del alcance arquitectura se exploran en detalle a continuacin. En cada
caso, en particular en entornos de gran escala donde arquitecturas se desarrollan necesariamente
de una manera federada, existe el peligro de arquitectos optimizacin 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 mdulos escalables y reutilizables con el
fin de maximizar la reutilizacin a nivel de empresa.
5.5.1 Amplitud
Una de las decisiones ms 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
especficos, funciones, organizaciones, zonas geogrficas, 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 integracin - son tpicos. Dicho marco especifica los principios de interoperabilidad, la
migracin, y la conformidad. Esto permite que las unidades de negocio especficas que tienen
arquitecturas desarrolladas y reguladas como proyectos de arquitectura
independientes. Informacin adicional y orientacin sobre cmo especificar los requisitos de
interoperabilidad para las diferentes soluciones se pueden encontrar en la Parte
III , 29. Requisitos de interoperabilidad .
Pgina50de670
TOGOF9.1
La viabilidad de una nica arquitectura de toda la empresa para cada funcin de negocio o
propsito puede ser rechazada por ser demasiado complejo y difcil de manejar.En estas
circunstancias, se sugiere que un nmero 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 especficos de la organizacin. En tal caso, tenemos que crear
la arquitectura de la empresa global como una "federacin" de estas arquitecturas
empresariales. Una manera eficaz de gestionar y explotar estas arquitecturas empresariales es
adoptar un modelo de publicacin y suscripcin 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 arquitectnico es de buena calidad, hasta a la fecha, aptas para esta finalidad, y
publicado (examin y aprob que se hagan pblicos).
El uso de material de la arquitectura puede ser monitoreada, y el cumplimiento de las

normas, modelos y principios se puede exhibir, a travs de:
o Un proceso de evaluacin de la conformidad que describe lo que el usuario est

suscribiendo, y evala su nivel de cumplimiento
o Un proceso de dispensacin que pueden conceder dispensas de adhesin a las

normas de arquitectura y directrices en casos especficos (por lo general con un
fuerte imperativo de negocio)
Publicacin y suscripcin tcnicas se estn desarrollando como parte de generales de gobierno de

TI y especficamente 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 aplicacin, la tecnologa) 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 ms detalle en la 20. Aplicando
la ADM a travs de la arquitectura del paisaje .
Tambin 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 adaptacin
futura, la extensin o la reutilizacin. La profundidad y el detalle de la arquitectura de la empresa
tiene que ser suficiente para su propsito, y no ms.
Iteraciones de la ADM se basarn en los artefactos y las capacidades creadas durante la iteracin
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 continuacin, centrarse en la identificacin y la entrega del valor que
Pgina51de670
TOGOF9.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 inversin).
5.5.3 Perodo de tiempo
El ADM se describe en trminos de un nico ciclo de Architecture Vision, y un conjunto de

arquitecturas objetivo (de negocios, datos, aplicaciones, Tecnologa ) que permiten la aplicacin de
la visin.
En tales casos, una visin ms amplia se puede tomar, por lo que una empresa est representada
por varias instancias diferentes de arquitectura (por ejemplo, estratgica, segmento, capacidad),
cada uno en representacin 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 lnea de base). Otro
ejemplo de arquitectura, tal vez definida slo parcialmente, representar a la ltima meta de estado
final (la "visin"). En el medio, intermedio o instancias "Arquitectura de Transicin" puede definirse,
comprendiendo cada uno su propio conjunto de arquitectura objetivo Descripciones. Un ejemplo de
cmo esto puede lograrse se da en la Parte III , 20. Aplicando la ADM a travs de la arquitectura
del paisaje .
Por este mtodo, el trabajo Arquitectura objetivo se divide en dos o ms 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 perodo de tiempo relativamente distantes
(por ejemplo, un perodo de seis aos).
2. A continuacin, desarrollar una o ms descripciones de "Arquitectura de Transicin", como

incrementos o mesetas, cada uno de acuerdo con y convergen en las Descripciones de
Arquitectura de destino, y la descripcin de los detalles del incremento en cuestin.
En este enfoque, las arquitecturas de destino son de carcter evolutivo, y requieren una revisin
peridica y actualizacin de acuerdo con la evolucin de las necesidades y la evolucin de la
tecnologa de la empresa, mientras que las arquitecturas de transicin son (por diseo) incremental
en la naturaleza, y, en principio, no deberan evolucionar durante el fase de aplicacin del
incremento, a fin de evitar el sndrome del "blanco mvil". Esto, por supuesto, slo es posible si el
calendario de aplicacin est bajo un estricto control y relativamente corta (por lo general menos
de dos aos).
Las Arquitecturas objetivo siguen siendo relativamente genrico, y debido a que son menos
vulnerables a la obsolescencia de las arquitecturas de transicin. Ellos encarnan slo las
decisiones arquitectnicas estratgicas clave, que deben ser bendecidos por los interesados desde
el principio, mientras que las decisiones arquitectnicas detalladas en las arquitecturas de
transicin estn deliberadamente pospusieron la medida de lo posible (es decir, justo antes de la
aplicacin) a fin de mejorar la capacidad de respuesta frente a vis las nuevas tecnologas y
productos.
La empresa evoluciona mediante la migracin a cada una de estas arquitecturas de transicin a su

vez. Como se implementa cada Arquitectura Transicin, la empresa logra un estado coherente,
operativo en el camino a la visin final. Sin embargo, esta visin s se actualiza peridicamente
para reflejar los cambios en el entorno empresarial y la tecnologa, y en efecto puede en realidad
Pgina52de670
TOGOF9.1
nunca puede lograr, como se describe en un principio. Todo el proceso se prolonga durante todo el
tiempo que la empresa existe y contina cambiando.
Esta ruptura de la descripcin de la arquitectura en una familia de productos de arquitectura

relacionados de curso requiere una gestin 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, tecnologa), pero la realidad de las limitaciones de tiempo de recursos y, a menudo
significa que no hay tiempo suficiente, la financiacin o los recursos para construir una de arriba
hacia abajo, todo incluido descripcin de la arquitectura que abarca los cuatro dominios de la
arquitectura.
Descripciones Arquitectura normalmente se construyen con un propsito especfico en mente - un

conjunto especfico de factores de negocio que impulsan el desarrollo de la arquitectura - y
clarificacin de la cuestin especfica (s) que la descripcin de la arquitectura tiene la intencin 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
tecnolgicas para lograr una capacidad particular, y los procesos fundamentales de negocio no
estn abiertos a la modificacin, a continuacin, un completo Business Architecture bien puede no
estar justificada. Sin embargo, debido a que las arquitecturas de datos, aplicaciones y Tecnologa
Construir sobre la arquitectura de negocio, la arquitectura de negocio todava necesita ser pensado
y entendido.
Si bien las circunstancias a veces pueden dictar la construccin de una descripcin de la

arquitectura no contiene todos los cuatro dominios de arquitectura, debe entenderse que tales una
arquitectura no puede, por definicin, una arquitectura completa de la empresa. Uno de los riesgos
es la falta de consistencia y, por tanto, la capacidad de integrar. Integracin o bien tiene que venir
ms 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 gestin de la empresa.
5.6 Arquitectura de Integracin

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 lmite 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 integracin de muchas
arquitecturas . Figura 5-2 ilustra cmo diferentes tipos de arquitectura tienen que coexistir.
En la actualidad, el estado de la tcnica es tal que la integracin arquitectura puede llevarse a cabo
slo 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 arquitectnicas.
Pgina53de670
TOGOF9.1
Figura52:IntegracindelaArquitecturaArtefactos
Como las organizaciones a abordar temas comunes (como la Arquitectura Orientada a Servicios
(SOA), y la infraestructura de informacin integrada), y modelos de datos universales y estructuras
de datos estndar surgir, se facilitar la integracin hacia el extremo superior del espectro. Sin
embargo, siempre habr la necesidad de una gobernanza normas efectiva para reducir la
necesidad de manual de coordinacin y resolucin 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 organizacin, 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 iteracin. Cada iteracin se sumar recursos para Arquitectura
Repositorio de la organizacin.
Mientras que un marco completo es til (de hecho, esencial) para tener en cuenta como el ltimo
objetivo a largo plazo, en la prctica no es una decisin clave que hacerse en cuanto al alcance de
un esfuerzo de la arquitectura empresarial especfica. Siendo este el caso, es vital para
comprender la base sobre la cual se toman las decisiones de alcance estn 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 perodos de tiempo, en consecuencia. Si es o no es la primera
vez, entender que este ejercicio se repetir, y que las iteraciones futuras se basarn en lo que se
est creando en el esfuerzo actual, aadiendo mayor anchura y profundidad.
Pgina54de670
TOGOF9.1
6. Fase Preliminar
En este captulo se describen las actividades de preparacin e iniciacin necesarias para cumplir la
directiva de negocio para una nueva arquitectura de la empresa, incluyendo la definicin de un
marco de la Organizacin de una arquitectura especfica y la definicin de principios.

Figura61:EtapaPreliminar
Pgina55de670
TOGOF9.1
6.1 Objetivos
Los objetivos de la fase preliminar son los siguientes:
1. Determinar la capacidad Arquitectura deseada por la organizacin:

o Revisar el contexto de la organizacin para la realizacin de la arquitectura
empresarial
o Identificar y el alcance de los elementos de las organizaciones empresariales

afectadas por la Capacidad de Arquitectura
o Identificar los marcos establecidos, mtodos y procesos que se cruzan con la

capacidad de Arquitectura
o Establecer destino Capability Maturity
2. Establecer la Capacidad de Arquitectura:

o Definir y establecer el modelo de organizacin de la Arquitectura Empresarial
o Definir y establecer el proceso detallado y recursos para la gobernanza de la

arquitectura
o Seleccionar y aplicar herramientas que apoyan la capacidad Arquitectura
o Definir los principios de la arquitectura
6.2 Enfoque
Esta Fase Preliminar trata de definir "dnde, qu, por qu, quin, y cmo lo hacemos arquitectura"
en la empresa de que se trate. Los principales aspectos son los siguientes:
Definicin de la empresa
La identificacin de factores clave y elementos en el contexto de la organizacin
Definicin de los requisitos para la obra de arquitectura
Definicin de los principios de la arquitectura que informen de cualquier obra de

arquitectura
Definir el marco para ser utilizado
Definicin de las relaciones entre los marcos de gestin
La evaluacin de la madurez de arquitectura empresarial
La arquitectura de la empresa ofrece una visin estratgica de arriba hacia abajo de una
organizacin 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 estratgico de este equipo para operar dentro.
Pgina56de670
TOGOF9.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 estratgicas, provisionales, y tcticas 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 organizacin.
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
particin equipos, procesos y resultados. Enfoques para la arquitectura de particin 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 particin y establecer las bases para el enfoque
elegido para ser puesto en prctica.
La Fase Preliminar podr ser revisada, de la fase Architecture Vision (ver Parte III , 19. Aplicando
la iteracin a la ADM ), con el fin de garantizar que la arquitectura de Capacidad de la organizacin
es adecuada para hacer frente a un problema de arquitectura especfica.
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 derivarn

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 gestin empresarial. La empresa puede abarcar muchas
organizaciones y los deberes del patrocinador deben velar por que todas las partes interesadas se
incluyen en la definicin, 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 especficas a tener en cuenta seran:
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 inters para la arquitectura de la empresa; sus problemas y preocupaciones

clave.
Las intenciones y la cultura de la organizacin, 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 ejecucin de los cambios y el funcionamiento de la

empresa, incluyendo la estructura del proceso y tambin el nivel de rigor y formalidad
aplicada dentro de la organizacin reas de enfoque deben incluir:
Pgina57de670
TOGOF9.1
o Los mtodos actuales para la descripcin de la arquitectura
o Marcos y mtodos de gestin de proyectos actuales
o Marcos y mtodos de gestin de los sistemas actuales
o Procesos y mtodos de gestin de la cartera de proyectos actuales
o Procesos y mtodos de gestin de la cartera de aplicaciones actuales
o Procesos y mtodos de gestin de la cartera de tecnologa actuales
o Procesos y mtodos de gestin de carteras de informacin actuales
o Sistemas de diseo y desarrollo de esquemas y mtodos actuales
El paisaje Arquitectura de referencia, incluyendo el estado de la empresa y tambin cmo

el paisaje se representa actualmente en forma de documentacin.
Las habilidades y capacidades de la empresa y las organizaciones especficas que se

adopta el marco.
Revisin del contexto de la organizacin debera establecer requisitos valiosos sobre cmo adaptar
el marco de arquitectura en trminos de:
Nivel de formalidad y el rigor que se aplicar
El nivel de sofisticacin 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 detrs de la obra de arquitectura empresarial en coche de los

requisitos y parmetros 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 informacin 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 Organizacin
El propsito estratgico
Necesidades financieras de previsin
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 definicin y el
establecimiento de una capacidad de Arquitectura.
Pgina58de670
TOGOF9.1
6.2.4 Principios
La Fase Preliminar define los principios de la arquitectura que formarn parte de las limitaciones de
cualquier obra de arquitectura realizada en la empresa. Los desafos de este se explican en la
Parte III , 23. Arquitectura Principios .
La definicin 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 tambin estn normalmente basados en parte en
los principios de negocio. Definicin de los principios laborales normalmente queda fuera del
mbito de la funcin de la arquitectura. Sin embargo, dependiendo de cmo se definen y se
promulgaron estos principios dentro de la empresa, puede ser posible que el conjunto de
Arquitectura Principios de reexpresar tambin, o intersectoriales se refieren a un conjunto de
principios de actuacin, los objetivos de negocio, y los conductores de negocios estratgicos
definidos en otros lugares dentro la empresa. Dentro de un proyecto de arquitectura, el arquitecto
normalmente necesitar asegurarse de que la definicin de estos principios de negocio, las metas
y los conductores estratgicos estn al da, y para aclarar cualquier rea de ambigedad.
La cuestin de la gobernanza arquitectura est estrechamente ligada a la de Arquitectura

Principios. El organismo responsable de la gobernanza tambin normalmente se encargar de
aprobar los Principios de Arquitectura, y para resolver los problemas de la arquitectura. Los
desafos de la gobernabilidad se explican en la Parte VII , 50.Arquitectura de Gobierno .
6.2.5 Marcos de gestin
La Arquitectura Mtodo de Desarrollo de TOGAF (ADM) es un mtodo genrico, destinado a ser

utilizado por las empresas en una amplia variedad de tipos de industrias y geografas. Tambin
est diseado 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
adaptacin).
TOGAF tiene que coexistir con y mejorar las capacidades operativas de otros marcos de gestin
que estn presentes dentro de cualquier organizacin, ya sea formal o informalmente. Adems de
estos marcos, la mayora de las organizaciones tienen un mtodo para el desarrollo de soluciones,
la mayora de los cuales tienen un componente de TI. La importancia de los sistemas es que rene
a los diversos dominios (tambin conocidas como Personas, Procesos y Materiales / Tecnologa)
para ofrecer una capacidad de negocio.
Los principales marcos sugeridas para coordinarse con TOGAF son:
Gestin de Capacidad de Empresas (Direccin de Operaciones y Planificacin) que

determina lo que se requieren capacidades laborales para entregar valor de negocio que
incluye la definicin de rendimiento de la inversin y de las medidas de control /
rendimiento requeridos.
Mtodos de gestin de cartera / del proyecto que determinan cmo una empresa
gestiona sus iniciativas de cambio.
Mtodos de gestin de operaciones que describen cmo una empresa gestiona sus
operaciones del da a da, incluyendo IT.
Pgina59de670
TOGOF9.1
Mtodos 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 Administracin 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 aplicacin de TOGAF no se centran

casi exclusivamente en la implementacin de TI, sino que debe tener en cuenta el impacto que la
arquitectura tiene en toda la empresa.

Figura62:MarcosdegestinparacoordinarconTOGAF
As, la fase preliminar consiste en hacer cualquier trabajo necesario adaptar la ADM para definir un
marco especfico de la organizacin, ya sea utilizando los entregables TOGAF o las entregas de
otro marco. Los desafos de este son discutidos en 5.3 Adaptacin de la ADM .
6.2.6 Relacionar los marcos de gestin
La Figura 6-3 ilustra un conjunto ms detallado de dependencias entre los diversos marcos y la
actividad de planificacin de negocios que incorpora el plan y la direccin estratgica de la
empresa. La arquitectura de la empresa se puede utilizar para proporcionar una estructura para
Pgina60de670
TOGOF9.1
todas las iniciativas empresariales, el Marco de Gestin de la cartera se puede utilizar para
entregar los componentes de la arquitectura, y el Marco de Gestin de Operaciones apoya la
incorporacin de estos nuevos componentes dentro de la infraestructura corporativa.
Los planificadores de negocios estn presentes en todo el proceso y estn en condiciones de

apoyar y reforzar la arquitectura mediante la retencin de la aprobacin de los recursos en las
diversas etapas de la planificacin y el desarrollo.
La metodologa de desarrollo de la solucin se utiliza dentro del marco de gestin de cartera para
planificar, crear y entregar los componentes arquitectnicos 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 produccin, contratacin, marketing,
etc. Arquitectura empresarial potencialmente proporciona el contexto para todas las actividades de
la empresa.
Se requiere que los marcos de gestin para complementarse entre s y trabajar en estrecha
armona por el bien de la empresa.

Figura 63: Interoperabilidad y relaciones entre los marcos de gestin
La planificacin empresarial a nivel de estrategia proporciona la direccin inicial de la arquitectura

empresarial. Actualizaciones en el nivel anual de planificacin proporcionan un mayor nivel de
orientacin permanente. Planificacin basada en la capacidad es una de las muchas tcnicas
populares para la planificacin de negocios.
Estructuras de arquitectura de la empresa la planificacin 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 informacin 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 direccin estratgica. TOGAF proporciona un marco para la
arquitectura empresarial.
Gestin de la cartera / del proyecto es el marco de administracin que recibe la direccin

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) metodologas de gestin de
Pgina61de670
TOGOF9.1
proyectos. Arquitecturas de proyectos y detallada fuera del contexto de diseo suelen estar
basadas en metodologas de diseo de sistemas.
Gestin de operaciones recibe los entregables y luego integra y los sostiene dentro de la
infraestructura corporativa. A menudo, los servicios de gestin de servicios de TI se basan en ISO
20000 o BS15000 (ITIL).
6.2.7 Planificacin de la Arquitectura Empresarial / Cambio de negocios Evaluacin de

madurez
Modelos de Madurez de Capacidad (detallados en la Parte VII , 51. Arquitectura de Madurez

Modelos ) son formas tiles de evaluacin 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 organizacin para ejecutar factores especficos
proporciona una medida de la madurez y puede ser usado para recomendar una serie de pasos
secuenciales para mejorar una capacidad. Es una evaluacin que proporciona a los ejecutivos una
visin de mejorar pragmticamente una capacidad.
Un buen modelo de madurez de la arquitectura empresarial cubre las caractersticas 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 segn 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 seccin 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 Arquitectnicos

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 gestin de

proyectos
Pgina62de670
TOGOF9.1
Gobernanza y marcos legales, incluyendo la estrategia de gobierno arquitectura, cuando

pre-existente
Capacidad de Arquitectura
Los acuerdos de asociacin 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 incluira:
Modelo de organizacin de Arquitectura Empresarial (vase la Parte IV , 36.2.16 Modelo

de Organizacin de Empresa de Arquitectura ), incluyendo:
o mbito de las organizaciones afectadas
o La evaluacin gestacional, lagunas, y el enfoque de resolucin
o Roles y responsabilidades de equipo de arquitectura (s)
o Necesidades presupuestarias
o Gobernabilidad y estrategia de apoyo
Marco de arquitectura existente, en su caso, incluyendo:
o Mtodo de Arquitectura
o Contenido de Arquitectura
o Herramientas de configurar e implementar
o Principios Arquitectura
o Arquitectura Repositorio
6.4 Pasos
El TOGAF ADM es un mtodo genrico, destinado a ser utilizado por una amplia variedad de
diferentes empresas, y en conjuncin 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 especfico de la organizacin. Los desafos de la adaptacin
del ADM a un contexto organizativo concreto se analizan en detalle en 5.3 Adaptacin 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 (vase ms adelante), as como el momento en que
se inician formalmente y completaron deben adaptarse a la situacin en cuestin de acuerdo con el
gobierno arquitectura establecida.
Los pasos dentro de la fase preliminar son los siguientes:
Pgina63de670
TOGOF9.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 Organizacin
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 ms 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 bsicas, pero son de otra forma no directamente afectados
Identificar empresa extendida (unidades) - las unidades fuera de la empresa de mbito que
se vern afectados en su propia arquitectura de la empresa
Identificar las comunidades implicadas (empresas) - las partes interesadas que se vern
afectados y que estn en los grupos de las comunidades
Identificar gobierno involucrados, incluidos los marcos jurdicos y geografas (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 organizacin 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 cmo se lleva material arquitectnico (normas, directrices,
modelos, informes de cumplimiento, etc) bajo el gobierno; es decir, qu tipo de caractersticas del
repositorio de gobierno van a ser necesarios, lo que las relaciones y la grabacin de estado son
necesarios para determinar qu proceso de gobernanza (dispensacin, el cumplimiento, para llevar
adelante, la jubilacin, etc) tiene la propiedad de un artefacto arquitectnico.
Es probable que los modelos de gobierno y de apoyo existentes en una organizacin tendr que
cambiar para apoyar el marco de arquitectura recin adoptado.
Para gestionar tendr que ser evaluado para entender su forma general y el contenido del cambio
organizacional necesario para adoptar el nuevo marco arquitectnico, el gobierno de la empresa
actual y modelos de apoyo. Adems, tendr que ser consultado sobre los posibles impactos que
podran 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 Organizacin

Determinar la capacidad de la empresa y el negocio existente
Pgina64de670
TOGOF9.1
Llevar a cabo una evaluacin 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 gestin 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
o Solicitud de evaluacin de impacto en sus planes y el trabajo
o Identificar reas de inters comn
o Identifique las diferencias crticas y conflictos de inters
o Producir las solicitudes de cambio a las actividades de las partes interesadas
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 (vase la Parte III , 23. Arquitectura Principios ) se basan en los principios
de negocio y son fundamentales en la creacin de las bases para la gobernanza de la
arquitectura. Una vez que se entiende el contexto de la organizacin, 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 adaptacin de TOGAF se requiere. Considerar la necesidad de:
Terminologa Sastrera : Arquitectura practicantes deben usar terminologa que se

entiende en general en toda la empresa. Adaptacin debera producir una terminologa
acordado fijar para la descripcin de contenido arquitectnico.
Adaptacin del proceso : El TOGAF ADM proporciona un proceso genrico para la

realizacin de la arquitectura. La adaptacin del proceso ofrece la oportunidad de eliminar
las tareas que ya se llevan a cabo en otras partes de la organizacin, aadir tareas
especficas de la organizacin (por ejemplo, los puestos de control especficas) y alinear
los procesos de ADM a los marcos de procesos externos y puntos de contacto. puntos de
contacto clave para ser dirigida incluira:
o Enlaces a los procesos de gestin de carteras de proyectos (y de servicios)
o Enlaces a ciclo vital del proyecto
o Enlaces a los procesos de traspaso de las operaciones
Pgina65de670
TOGOF9.1
o Enlaces a los procesos de gestin de operaciones (incluyendo la gestin de

configuracin, gestin de cambios y gestin de servicios)
o Enlaces a los procesos de contratacin
Contenido Sastrera : Usando el TOGAF Arquitectura del marco de contenido y Empresa

Continuum como base, la adaptacin de la estructura del contenido y enfoque de
clasificacin permite la adopcin de marcos de contenido de terceros y tambin permite la
personalizacin del marco de apoyo a los requisitos especficos de la organizacin.
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 sofisticacin y la cultura de la funcin de la arquitectura dentro de la
organizacin. Con una comprensin de la aproximacin deseada a la arquitectura, es posible
seleccionar herramientas de arquitectura apropiados para apoyar la funcin de la arquitectura.
El acercamiento a las herramientas puede basarse en el uso relativamente informal de

aplicaciones de productividad de oficina estndar, o puede estar basada en una implementacin
personalizada de herramientas de arquitectura especializados. Dependiendo del nivel de
sofisticacin, la implementacin de herramientas puede variar de una tarea trivial para una
actividad de aplicacin del sistema ms complicado.
Problemas en las herramientas de estandarizacin 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:

o Las restricciones sobre el trabajo de arquitectura
Tailored Architecture Framework (vase la Parte IV , 36.2.21 Tailored Architecture

Framework ), que incluye:
o Mtodo de arquitectura adaptada
o Adaptado contenido de la arquitectura (entregables y artefactos)
o Arquitectura Principios (ver la Parte IV , 36.2.4 Principios de Arquitectura )
Pgina66de670
TOGOF9.1
Arquitectura repositorio inicial (ver la Parte IV , 36.2.5 Arquitectura del repositorio ),

poblada de contenidos marco
Reformulacin de, o referencia a los principios de negocio, objetivos de negocio, y los

conductores de negocios (vase la Parte IV , 36.2.9 Principios de Actuacin, objetivos de
negocio, y los impulsores del negocio )
Solicitud de Arquitectura de trabajo (opcional) (vase la Parte IV , 36.2.17 Solicitud de

Arquitectura de Trabajo )
Arquitectura Governance Framework (vase ( Parte VII , Governance Framework 50.2

Arquitectura )
Las salidas pueden incluir algunos o todos de los siguientes:
Catlogos:
o Catlogo de Principios
Pgina67de670
TOGOF9.1
. 7 Fase A: Architecture Vision

En este captulo se describe la fase inicial del desarrollo de mtodos Arquitectura (ADM). Incluye
informacin acerca de la definicin del alcance, la identificacin de las partes interesadas, la
creacin de la arquitectura de la Visin, y la obtencin de las aprobaciones.

Figura71:FaseA:ArchitectureVision
7.1 Objetivos
Los objetivos de la Fase A son:
Desarrollar una visin 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 aprobacin de una Declaracin de Arquitectura Trabajo que define un programa

de trabajos para desarrollar e implementar la arquitectura se indica en el Architecture
Vision
7.2 Enfoque
Pgina68de670
TOGOF9.1
7.2.1 Generalidades
Fase A se inicia con la recepcin de una Solicitud de Trabajo de Arquitectura de la organizacin

patrocinadora para la organizacin de la arquitectura.
Los desafos de garantizar el adecuado reconocimiento y aprobacin de la gestin empresarial, y el

apoyo y compromiso de la gerencia de lnea, se analizan en la Parte VII, 50.1.4 IT Governance .
Fase A tambin 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
evaluacin prctica 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
desafos de este son discutidos en 5.5 Alcance de la Arquitectura . Cuestiones scoping abordan en
la fase Architecture Vision estar restringido a los objetivos especficos de este ciclo de ADM y se
ver limitado dentro de la definicin 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 sern normalmente informadas por los principios de negocio y Arquitectura
Principios, desarrollado como parte de la Etapa Preliminar (vase 6. Fase Preliminar ).
Normalmente, los principios de negocio, objetivos de negocio, y los conductores estratgicos de la

organizacin ya estn definidas en la empresa en otros lugares. Si es as, la actividad en la Fase A
est relacionado con garantizar que las definiciones existentes estn al da, y la aclaracin de
cualquier rea de la ambigedad. De lo contrario, se trata de la definicin 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 (vase 6. Fase
Preliminar ). La actividad en la Fase A se ocupa de garantizar que las definiciones de los principios
existentes estn al da, y la aclaracin de cualquier rea de ambigedad. De lo contrario, implica la
definicin de los Principios de la configuracin por primera vez, como se explica en la Parte
III , 23. Principios de Arquitectura .
7.2.2 Creando la Visin 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 cmo la nueva capacidad se reunir con los objetivos de
negocio y los objetivos estratgicos y atender las preocupaciones de los interesados en su
aplicacin.
Aclarar y acordar el propsito del esfuerzo arquitectura es una de las piezas clave de esta
actividad, y el propsito debe reflejarse claramente en la visin que se crea.Proyectos de
arquitectura a menudo se llevan a cabo con un propsito especfico en mente - un conjunto
especfico de factores de negocio que representan el retorno de la inversin para las partes
interesadas en el desarrollo de la arquitectura. Aclarar ese propsito, y la demostracin de la forma
Pgina69de670
TOGOF9.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 Visin Arquitectura - como la misin de la empresa,

la visin, la estrategia y los objetivos - se han documentado como parte de alguna estrategia de
negocio ms amplio o de la actividad de planificacin 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 verificacin y la
comprensin 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 implcitos
en la actual arquitectura de la realidad.
En otros casos, poco o ningn 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 iniciacin de ADM (Fase Preliminar).
El Architecture Vision proporciona un primer corte, descripcin de alto nivel de la lnea de base y
Target Arquitecturas, que abarca los dominios de negocio, datos, aplicaciones y tecnologa. Estas
descripciones de contorno se desarrollan en fases posteriores.
Escenarios de negocios son una tcnica apropiada y til para descubrir y documentar los
requerimientos del negocio, y para articular una visin 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 visin de la Arquitectura est definido y documentado en la Declaracin 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 organizacin en su conjunto. El consenso est representado por la
organizacin patrocinadora que firma la Declaracin de Arquitectura Obra.
7.2.3 Escenarios empresariales
El ADM tiene su propio mtodo (un "mtodo-dentro-de-mtodo") para la identificacin y articulacin

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 implcitas. Este proceso se
conoce como "escenarios de negocio", y se describe en la Parte III , 26. Escenarios empresariales
y objetivos de la empresa . La tcnica puede ser usada de forma iterativa, a diferentes niveles de
detalle en la descomposicin jerrquica de la Arquitectura Empresarial.
7.3 Entradas
Esta seccin define las entradas a la Fase A.

Materiales de referencia Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio )
Pgina70de670
TOGOF9.1

Solicitud de Arquitectura de trabajo (vase la Parte IV , 36.2.17 Solicitud de Arquitectura
de Trabajo )
Principios de Actuacin, los objetivos de negocio, y los conductores de negocios (vase la

Parte IV , 36.2.9 Principios de Actuacin, objetivos de negocio, y los impulsores del
negocio )

o Requisitos de reutilizacin
o Las solicitudes de cambio

o Principios Arquitectura (ver la Parte IV , 36.2.4 Principios Arquitectura ), incluidos

los principios de negocios, al pre-existente
Poblado Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura Repositorio ) - la

documentacin existente de arquitectura (descripcin marco, descripciones
arquitectnicas, las descripciones de lnea 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 iteracin del
desarrollo de la arquitectura.
El orden de los pasos en la Fase A (vase ms adelante), as como el momento en que se inician
formalmente y completaron deben adaptarse a la situacin en cuestin de acuerdo con el gobierno
arquitectura establecida.
Pgina71de670
TOGOF9.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 inters, 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 preparacin para la Transformacin de Negocios
7.4.6 Definir el alcance
7.4.7 Confirmar y Arquitectura elaborar principios, incluidos los Principios de Actuacin
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 transformacin empresarial y Mitigacin Actividades
7.4.11 Desarrollar el Enunciado de Arquitectura de Trabajo; Aprobacin Secure
7.4.1 Establecer el Proyecto de Arquitectura
Ejecucin de los ciclos de ADM debe llevarse a cabo dentro del marco de gestin de proyectos de
la empresa. En algunos casos, los proyectos de arquitectura ser autnomo. En otros casos, las
actividades de arquitectura sern un subconjunto de las actividades dentro de un proyecto ms
amplio. En cualquier caso, la actividad de la arquitectura debe ser planeadas y manejadas con
prcticas aceptadas para la empresa.
Llevar a cabo los trmites necesarios para obtener el reconocimiento del proyecto, la aprobacin
de la gestin social, y el apoyo y compromiso de la gerencia de lnea es necesario. Incluye
referencias a otros marcos de gestin en el uso dentro de la empresa, explicando cmo este
proyecto se relaciona con esos marcos.
7.4.2 Identificar los grupos de inters, las preocupaciones y los Requerimientos del
Negocio
Identificar las partes interesadas clave y sus preocupaciones / objetivos, y definir los requisitos
empresariales clave que se abordarn en el compromiso de la arquitectura.Participacin de los
interesados en esta etapa se pretende lograr tres objetivos:
Para identificar los componentes y los requisitos para ser probados como Architecture
Vision visin candidatos se desarrolla
Para identificar los lmites de alcance candidatos para el compromiso de limitar el alcance
de la investigacin arquitectnica requerida
Pgina72de670
TOGOF9.1
Para identificar las preocupaciones de las partes interesadas, los problemas y los factores
culturales que darn forma a cmo 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
participacin y sus principales preocupaciones (ver Parte III , 24.3 Pasos en el proceso de gestin
de los grupos de inters 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 visin (ver la Parte IV , 36.2.8 Architecture Vision )
Los actores que estn 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 Declaracin 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. Gestin de los grupos de inters , la comprensin 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 Especificacin de Requisitos, y las nuevas necesidades que estn fuera del
alcance de los requisitos seleccionados deben ser introducidos a los requisitos del repositorio de
gestin a travs del proceso de gestin de requisitos.
7.4.3 Confirmar y Empresariales elaborada Objetivos, controladores de Negocios y

restricciones
Identificar los objetivos de negocio y los conductores estratgicos de la organizacin.
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 ambigedad. De lo contrario,
volver a los autores de la Declaracin de Arquitectura de trabajo y trabajar con ellos para definir
estos elementos esenciales y asegurar su aprobacin por parte de la gestin empresarial.
Definir las restricciones que deben ser tratados, incluidas las limitaciones de toda la empresa y las
limitaciones especficas 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 lnea de base y el nivel de capacidad objetivo de la empresa.
Pgina73de670
TOGOF9.1
Las lagunas identificadas en el Capability Arquitectura requieren iteracin 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 iteracin a la ADM ).
Las lagunas o limitaciones, que se identifican en la capacidad de la empresa para ejecutar el

cambio informarn al arquitecto en la descripcin de la arquitectura destino y sobre la aplicacin y
el Plan de Migracin (vase la Parte IV , 36.2.14 Implementacin y Plan de Migracin ) 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
abstraccin (ver 20. Aplicando la ADM a travs de la Arquitectura del Paisaje ). Consideracin de
la brecha entre la lnea 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 creacin de diagramas de cadena de valor que muestran la vinculacin de las capacidades
relacionadas.
Los resultados de la evaluacin se documentan en una Evaluacin de Capacidad (vase la Parte

IV , Evaluacin de Capacidad de 36.2.10 ).
7.4.5 evaluar la preparacin para la Transformacin de Negocios
Una Evaluacin de la preparacin de transformacin de negocios se puede utilizar para evaluar y

cuantificar la disposicin de la organizacin para experimentar un cambio.Esta evaluacin se basa
en la determinacin y el anlisis / calificacin de una serie de factores de preparacin, como se
describe en el 30. Evaluacin de la preparacin de transformacin de negocios .
Los resultados de la evaluacin de la preparacin se deben agregar a la evaluacin de la

capacidad (vase la Parte IV , Evaluacin 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 lnea de base y el objetivo no necesitan ser
descritos en el mismo nivel de detalle. En muchos casos, la lnea de base se describe en un nivel
de abstraccin ms alto, por lo que hay ms tiempo disponible para especificar el destino con
suficiente detalle. Los desafos 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 caractersticas de la particin de la arquitectura (vase la Parte V , 40. Arquitectura

de particionamiento para ms detalles)
Los dominios especficos de arquitectura para ser cubiertos (negocio, datos, aplicaciones,
tecnologa)
Pgina74de670
TOGOF9.1
La extensin del perodo de tiempo destinado a, ms el nmero y el alcance de cualquier

perodo de tiempo intermedio
Los activos de arquitectura para ser apalancadas, o considerados para su uso, de la

empresa Continuum de la organizacin:
o Activos creados en versiones anteriores del ciclo de ADM en la empresa
o 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 Actuacin
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 . Asegrese de
que las definiciones existentes son actuales, y aclarar cualquier rea de ambigedad. 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 aprobacin por parte de la
gestin 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 lnea de base y Target
Arquitecturas. El Architecture Vision general cubre la amplitud de alcance definido para el proyecto,
en un nivel alto. Tcnicas informales son a menudo empleados. Una prctica comn es dibujar un
diagrama de concepto de la solucin simple que ilustra en forma concisa los principales
componentes de la solucin y cmo la solucin se traducir en beneficios para la empresa.
Escenarios de negocios son una tcnica apropiada y til para descubrir y documentar los
requerimientos del negocio, y para articular una visin de la Arquitectura, que responda a esas
necesidades. Escenarios de negocios tambin se pueden usar en los niveles ms 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 informacin y tecnologa, segn 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 contratacin
Revisar y acordar las propuestas de valor con los patrocinadores y las partes interesadas
Pgina75de670
TOGOF9.1
Definir las mtricas y las medidas que se construirn en la arquitectura de la empresa para
satisfacer las necesidades empresariales de rendimiento
Evaluar el riesgo de negocios (vase la Parte III , 31. Gestin 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 transformacin empresarial y Mitigacin Actividades
Identificar los riesgos asociados con la Architecture Vision y evaluar el nivel de riesgo inicial (por
ejemplo, catastrfica, crtico, marginal o insignificante) y la frecuencia potencial asociado a
l. Asignar una estrategia de mitigacin para cada riesgo. Un marco de gestin de riesgos se
describe en la Parte III , 31. Gestin de Riesgos .
Hay dos niveles de riesgo que deben ser considerados, a saber:
Nivel Inicial del Riesgo : categorizacin del riesgo antes de determinar e implementar
acciones de mitigacin.
Nivel Residual de Riesgo : categorizacin del riesgo despus de la implementacin de

medidas de mitigacin (si los hay).
Actividades de mitigacin de riesgos deben ser considerados para su inclusin en el Estado de

Arquitectura Obra.
7.4.11 Desarrollar el Enunciado de Arquitectura de Trabajo; Aprobacin Secure
. Evaluar los productos de trabajo que se requieren para producir (y cundo) 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 especficos estn disponibles.
Luego, las actividades sern las siguientes:
Identificar nuevos productos de trabajo que tendr que ser cambiado
Proporcionar direccin en la que tendr que ser cambiado productos de trabajo existentes,
incluyendo bloques de construccin, 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 propsito, 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
Pgina76de670
TOGOF9.1
Evaluar las necesidades de recursos y disponibilidad para llevar a cabo la obra en el plazo
requerido; esto incluir la adhesin a los mtodos de planificacin de la organizacin y los
productos de trabajo para producir los planes para la realizacin 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 Declaracin de Arquitectura Trabajo
Definir las mtricas de rendimiento que deben cumplir durante este ciclo de la ADM por el
equipo de arquitectura de la empresa
Desarrollar el Plan y programa especfico de arquitectura empresarial Comunicaciones

dnde, cmo, 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 aprobacin formal de la
Declaracin de Arquitectura Obra bajo los procedimientos de gobierno que resulten
Obtener el cierre de sesin de patrocinador para proceder
7.5 Salidas
Las salidas de la Fase A pueden incluir, pero no se limitan a:
Declaracin aprobada de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin

de Arquitectura de Trabajo ), incluyendo, en particular:
o Arquitectura Descripcin y alcance del proyecto
o Descripcin general de Arquitectura Visin
o Plan de la configuracin y programacin del proyecto
Declaraciones refinadas de los principios de negocio, objetivos de negocio, y los

conductores de negocios (vase la Parte IV , 36.2.9 Principios de Actuacin, objetivos de
negocio, y los impulsores del negocio )
Principios Arquitectura (ver la Parte IV , 23. Arquitectura Principios )
Evaluacin de capacidades (vase la Parte IV , 36.2.10 Evaluacin de Capacidad )

Framework ) (para la contratacin), incluyendo:
Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ), incluyendo:
o Descripcin del problema
Pgina77de670
TOGOF9.1
o Objetivo de la Declaracin de Arquitectura de Trabajo
o Vistas de resumen
o Escenario empresarial (opcional)
o Requisitos clave refinados de interesados de alto nivel
Proyecto de Arquitectura de definicin de documento, incluyendo (cuando alcance):
o Lnea de base de Empresas Arquitectura, Versin 0.1
o Lnea de Base Tecnolgica de Arquitectura, Versin 0.1
o Arquitectura de datos de lnea de base, versin 0.1
o Lnea de base de arquitectura de aplicaciones, versin 0.1
o Objetivo Negocio Arquitectura, Versin 0.1
o Tecnologa Target Arquitectura, Versin 0.1
o Arquitectura de datos de destino, Versin 0.1
o Objetivo de Arquitectura de aplicaciones, Versin 0.1
Plan de comunicacin (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 )
Nota:
Escenarios de negocios mltiples pueden ser usados para generar una nica arquitectura
Visin.
Matrices:
o Matriz de los grupos de inters Mapa
Diagramas:
o Diagrama de la cadena de valor
o Diagrama conceptual de soluciones
Pgina78de670
TOGOF9.1
8 Fase B:. Arquitectura de Negocios

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

Figura81:FaseB:ArquitecturadeNegocios
8.1 Objetivos
Los objetivos de la Fase B son:
Desarrollar la arquitectura destino de negocios que describe cmo la empresa necesita

para operar para lograr los objetivos de negocio y responder a los conductores estratgicos
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 lnea de base y objetivo de negocio Arquitecturas
Pgina79de670
TOGOF9.1
8.2 Enfoque
En resumen, la arquitectura de negocio describe el producto y / o estrategia de servicios, y los
aspectos organizativos, funcionales, procesos, informacin y aspectos geogrficos 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, tecnologa), y por lo tanto es la primera
actividad de la arquitectura que debe llevarse a cabo, si no atendidos ya en otros procesos
organizativos (planificacin empresarial, la planificacin estratgica de negocios, proceso de
reingeniera de negocios, etc.)
En trminos prcticos, 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 inversin 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 misin de la empresa, la visin, la estrategia y los objetivos pueden
documentarse como parte de alguna estrategia de negocio ms amplio o de la actividad de
planificacin 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 especficas 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 mtricas de xito -
pero no cmo llegar hasta all. Ese es el rol de la Arquitectura Empresarial.
En otros casos, poco o ningn 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 tcnica de escenario de negocios (vase la Parte III , 26. Escenarios
empresariales y objetivos de la empresa
) Del TOGAF ADM, o cualquier otro mtodo que ilumina los requisitos clave de negocio e indica los
requisitos tcnicos implcitos para la arquitectura de TI, se puede utilizar.
Un objetivo clave es reutilizar el material existente tanto como sea posible. En ambientes
arquitectnicamente ms 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; vase la Parte V , 39.4.1 Arquitectura Continuum .
Pgina80de670
TOGOF9.1
Recopilar y analizar nicamente la informacin 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 definicin de (posiblemente) nuevos procesos de negocio, a continuacin, la fase B
necesariamente implicar una gran cantidad de trabajo detallado. Si la atencin se centra ms en
las arquitecturas objetivo en otros dominios (datos / informacin, 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 lnea de base Descripcin
Si una empresa ha descripciones arquitectura existente, se deben utilizar como base para la
descripcin de lnea de base. Esta entrada puede haber sido utilizado ya en la Fase A en el
desarrollo de una arquitectura de visin, e incluso puede ser suficiente en s mismo para la
descripcin de lnea de base.
Cuando no existan tales descripciones, la informacin deber ser recogida en el formato que viene
a mano.
La aproximacin normal al desarrollo Arquitectura objetivo es de arriba hacia abajo. En la

descripcin de lnea de base, sin embargo, el anlisis de la situacin 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 hiptesis de trabajo en
realidad, hasta que la ley de los rendimientos decrecientes establece pulg
Los procesos de negocio que no son trasladables tienen ningn valor intrnseco. Sin embargo,
cuando el desarrollo de descripciones de lnea de base en otros mbitos de arquitectura,
componentes arquitectnicos (principios, modelos, estndares y el inventario actual) que no son
trasladables todava puede tener un valor intrnseco, 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 informacin que permite tomar decisiones
con conocimiento de causa en relacin 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 lgicas 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 ms detallados.
Una variedad de herramientas y tcnicas de modelado se puede emplear, si se considera

apropiado (teniendo en cuenta la precaucin por encima de no entrar en detalles innecesarios). Por
ejemplo:
Modelos de actividad (tambin llamados Modelos de Procesos de Negocio ) describen

las funciones relacionadas con las actividades de la empresa de negocios, los datos y / o
informacin intercambiada entre las actividades (intercambios internos), y los datos y / o
informacin intercambiada con otras actividades que estn fuera del alcance de el modelo
(intercambios externos). Modelos de actividad son de naturaleza jerrquica. Capturan las
Pgina81de670
TOGOF9.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 explcitas de las reglas de negocio que representan
las relaciones entre los ICOM. Por ejemplo, una regla de negocio puede especificar quin
puede hacer qu en determinadas condiciones, la combinacin de entradas y controles
necesarios, y los productos resultantes. Una de las tcnicas para la creacin de modelos
de actividad es la IDEF (Integrated Computer Aided Manufacturing (ICAM) Definicin)
tcnica de modelado.
El Object Management Group (OMG) ha desarrollado el Business Process Modeling

Notation (BPMN), un estndar 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, segn el enfoque del esfuerzo de modelado. Un modelo de
casos de uso se describen los procesos de negocio de una empresa en trminos de casos
de uso y actores correspondientes a los procesos de negocio y los participantes de la
organizacin (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 lgicos. Un modelo de clase
describe la informacin esttica y de relaciones entre la informacin. Un modelo de clase
tambin se describen los comportamientos informativos. Como muchos de los otros
modelos, tambin se puede utilizar para modelar diversos niveles de
granularidad. Dependiendo de la intencin de la modelo, un modelo de clases puede
representar entidades de dominio empresarial o sistemas de clases de implementacin. Un
modelo de dominio de negocio representa la informacin clave del negocio (clases de
dominio), sus caractersticas (atributos), sus comportamientos (mtodos u operaciones) y
las relaciones (a menudo referida como la multiplicidad, que describe el nmero de clases
por lo general participan en la relacin), y cardinalidad ( describe la participacin requerida
u opcional en la relacin). Especificaciones informacin ms elaborada y detalle que no se
puede representar en el diagrama de clases.

Figura82:DiagramadeclasesUMLNegocios
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 generacin de este tipo de
modelos.
Pgina82de670
TOGOF9.1
Ciertos sectores de la industria tienen las tcnicas de modelado especficos 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 ubicacin y realizacin de los procesos de negocio se
vern 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 caractersticas de la informacin intercambiada. Conectividad
de nodo se puede describir en tres niveles: conceptuales, lgicos y fsicos. Cada needline
indica la necesidad de algn tipo de transferencia de informacin entre los dos nodos
conectados. Un nodo puede representar un papel (por ejemplo, un CIO), una unidad
organizativa, un lugar de negocios o instalacin, y as sucesivamente. Una flecha que
indica la direccin del flujo de informacin se anota para describir las caractersticas de los
datos o informacin - por ejemplo, su nivel de contenido, los medios de comunicacin, la
seguridad o la clasificacin, la puntualidad, y los requisitos de interoperabilidad del sistema
de informacin.
El Intercambio de Informacin Matrix documenta los requisitos de intercambio de

informacin para una empresa de arquitectura. Requisitos de intercambio de informacin
expresan las relaciones a travs de tres entidades bsicas (actividades, nodos de negocios
y sus elementos, y el flujo de informacin), y se centran en las caractersticas del
intercambio de informacin, como el rendimiento y la seguridad. Identifican que intercambia
la informacin con quin, por qu es necesaria la informacin, y de qu manera.
Aunque originalmente desarrollado para su uso en el sector de la Defensa, estos modelos estn
encontrando cada vez mayor uso en otros sectores del gobierno, y tambin 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 estn disponibles
en el repositorio de recursos Arquitectura Arquitectura Profesiones pertinentes (vase la Parte
V , 41. Arquitectura Repositorio ), en particular:
Modelos de negocio genricos relacionados con el sector de la industria de la

organizacin. Estos son "Arquitecturas Industria", en trminos de la Empresa
Continuum. Se llevan a cabo en la Biblioteca de la arquitectura de repositorio (vase la
Parte V , 41,3 Reference Library ). Por ejemplo:
o El Grupo de Gestin 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 especficos como la salud, Transporte,
Finanzas, etc
o El TeleManagement Forum (TMF) - www.tmforum.org - ha desarrollado modelos

de negocio detallados relevante para la industria de las Telecomunicaciones.
o Departamentos y agencias gubernamentales de los diferentes pases tienen

modelos y marcos de referencia obligatorios para el uso, la intencin de promover
la integracin entre departamentos y la interoperabilidad. Un ejemplo es el modelo
de negocio de referencia Federal Enterprise Architecture, que es un marco de la
funcin de guiado para la descripcin de las operaciones comerciales de la
independiente del Gobierno Federal de los organismos que los realizan.
Pgina83de670
TOGOF9.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 comprensin 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
electrnico.
o El Marco de STEP (estndar para el intercambio de datos del modelo del producto)
se ocupa de diseo de producto y el interfuncionamiento cadena de
suministro. STEP es un estndar ISO (ISO 10303). La aplicacin de la norma
STEP ha sido liderado por algunos grandes fabricantes aeroespaciales, y tambin
se ha tenido en otras industrias que tienen una necesidad de complejos datos
grficos y de proceso, tales como la industria de la construccin.
o RosettaNet - www.rosettanet.org - es un consorcio creado por las empresas

lderes en el ordenador, componentes electrnicos, semiconductores y las cadenas
de suministro de fabricacin. Su misin es desarrollar un conjunto completo de los
procesos de negocio electrnico estndar para estas cadenas de suministro, y
promover y apoyar su adopcin y uso.
Bloques de construccin especficas de la empresa (componentes de procesos, reglas de

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


de Trabajo )
Principios de Actuacin, los objetivos de negocio, y los conductores de negocios (vase la

Parte IV , 36.2.9 Principios de Actuacin, objetivos de negocio, y los impulsores del
negocio )

Pgina84de670
TOGOF9.1

Declaracin aprobada de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin

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 (vase la Parte V , 39. Empresa Continuum )
Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura del repositorio ),

incluyendo:
o Bloques de construccin reutilizables
o Modelos de referencia disponibles al pblico
o Modelos de referencia especficos de la organizacin
o Normas de la Organizacin
Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ), incluyendo:
o Descripcin del problema
o Objetivo de la Declaracin de Arquitectura de Trabajo
o Vistas de resumen
o Escenario empresarial (opcional)
o Requisitos clave refinados de interesados de alto nivel
Proyecto de Arquitectura de definicin de documento, incluyendo (cuando alcance):
o Lnea de base de Empresas Arquitectura, Versin 0.1
o Lnea de Base Tecnolgica de Arquitectura, Versin 0.1
Pgina85de670
TOGOF9.1
o Objetivo Negocio Arquitectura, Versin 0.1
o Tecnologa Target Arquitectura, Versin 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 estn 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
arquitectnico anterior; pero, si no, ellos tambin tendrn que ser definidos en la Fase B.
El orden de los pasos en la Fase B (vase ms adelante), as como el momento en que se inician
formalmente y completaron deben adaptarse a la situacin en cuestin, de acuerdo con el gobierno
arquitectura establecida. En particular, determinar si en esta situacin, es oportuno proceder a
lnea de base o Arquitectura objetivo el desarrollo en primer lugar, como se describe en la Parte
III , 19. Aplicando la iteracin 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
documentacin generada a partir de estas medidas debe ser publicada oficialmente en la
Arquitectura paso Crear definicin de documento (ver 8.4.9 Crear Arquitectura Definicin de
documento ).
Los pasos en la fase B son los siguientes:
8.4.1 Seleccin de modelos de referencia, puntos de vista y Herramientas
8.4.2 Desarrollar basal Arquitectura Descripcin
8.4.3 Desarrollar Target Arquitectura Descripcin
8.4.4 Realizar anlisis de brechas
8.4.5 Definir candidatos Componentes Hoja de Ruta
8.4.6 Impactos Resolver Across the Landscape Architecture
8.4.7 Revisin de Conducta de las partes interesadas Formal
8.4.8 Finalizar la Arquitectura de Negocios
Pgina86de670
TOGOF9.1
8.4.9 Crear Arquitectura Definicin de documento
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 inters y preocupaciones.
Seleccione los puntos de vista pertinentes Arquitectura empresarial (por ejemplo, operaciones,
gestin, financiera); es decir, los que le permitirn al arquitecto para demostrar cmo se estn
abordando las preocupaciones de los interesados en la arquitectura de negocio.
Identificar las herramientas y las tcnicas que se utilizarn para la captura, modelado y anlisis, en
asociacin con los puntos de vista seleccionados apropiados.Dependiendo del grado de
sofisticacin se justifica, stos pueden comprender documentos u hojas de clculo simples o
herramientas de modelado ms sofisticadas y tcnicas, 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
especfico necesario, utilizando la herramienta o mtodo seleccionado.
Asegrese de que todas las preocupaciones de los interesados estn cubiertos. Si no es as, crear
nuevos modelos para abordar las preocupaciones no estn cubiertos, o aumentar los modelos
existentes (vase 8.2.3 Modelado de Negocios ). Escenarios de negocios son una tcnica muy til
para descubrir y documentar los requerimientos del negocio, y se pueden utilizar de forma iterativa,
a diferentes niveles de detalle en la descomposicin jerrquica 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 tcnicas que permitan la definicin de la arquitectura de negocio de una
organizacin. En muchos casos, los tres enfoques pueden ser utilizados en secuencia para
descomponer progresivamente un negocio.
Anlisis Estructurado : Identifica las funciones clave de negocio en el mbito de la

arquitectura, y los mapas de aquellas funciones en las unidades de la organizacin dentro
de la empresa.
Use caso Anlisis : El detalle de las funciones de nivel empresarial a travs de actores y
organizaciones permite que los actores de una funcin para ser identificados y permite una
interrupcin en los servicios de apoyo / entrega de esa capacidad funcional.
Modelado de Procesos : El detalle de una funcin o servicio de negocio a travs de la

modelizacin de procesos permite que los elementos del proceso de ser identificados, y
permite la identificacin de los servicios a las empresas de menor nivel o funciones.
El nivel y el rigor de la descomposicin necesaria vara 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
Pgina87de670
TOGOF9.1
alcance y propsito del esfuerzo arquitectura de la empresa para determinar el nivel de

descomposicin.
8.4.1.2 Identificar Requerido granularidad de nivel de servicio, Lmites, 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 especficas que tienen lmites explcitos,
definidos que se rigen de manera explcita. 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, tendrn
lmites definidos explcitas, pero no pueden ser gobernados de forma explcita . Del mismo modo,
las funciones de negocio de macro pueden ser gobernados de manera explcita, pero no pueden
tener, lmites definidos explcitos.
Por tanto, la fase de arquitectura de negocio necesita identificar qu componentes de la

arquitectura son funciones y cules son los servicios. Los servicios se distinguen de las funciones a
travs de la definicin explcita de un contrato de servicios. Cuando se estn desarrollando
arquitecturas de referencia, puede darse el caso de que no existan contratos explcitos y por lo
tanto sera a discrecin del arquitecto para determinar si hay mrito 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 tambin la interfaz de tecnologa /

datos. Arquitectura Negocio definir el contrato de servicios en el / nivel funcional de negocios, que
se ampliar en la aplicacin y Arquitectura Tecnologa 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 administracin ms cercana y la medicin (y se pueden combinar para crear servicios
ms gruesos de grano), pero es necesario un mayor esfuerzo para gobernar. Directrices para la
identificacin de los servicios y la definicin de sus contratos se encuentran en la parte
III , 22. Usando TOGAF para definir y Gobierno SOAs .
8.4.1.3 Identificar Catlogos requeridos de Negocio Building Blocks
Catlogos capturan los inventarios de los principales activos de la empresa. Los catlogos son de
naturaleza jerrquica y capturan la descomposicin de un bloque de construccin, y tambin a
travs de descomposiciones bloques de construccin relacionados (por ejemplo, la organizacin /
actor).
Catlogos constituyen la materia prima para el desarrollo de matrices y puntos de vista y tambin
actan como un recurso clave para la gestin de la cartera de negocios y capacidad de TI.
Los siguientes catlogos deben ser considerados para el desarrollo dentro de una arquitectura de
negocios:
Catlogo de Organizacin / Actor
Conductor / Meta / Objetivo catlogo
Catlogo de funciones
Pgina88de670
TOGOF9.1
Catlogo de servicios de negocios / Funcin
Ubicacin catlogo
Proceso / Evento / Control / Catlogo de productos
Catlogo Contract / Medida
La estructura de catlogos se basa en los atributos de las entidades metamodelo, segn se define
en la Parte IV , 34. Metamodel contenido .
8.4.1.4 Identificar Matrices requeridos
Matrices muestran las relaciones bsicas entre las entidades del modelo relacionado.
Las matrices son la materia prima para el desarrollo de puntos de vista y tambin actan como un
recurso clave para la evaluacin del impacto, realizado como parte del anlisis de brecha.
Las siguientes matrices deben ser considerados para el desarrollo dentro de una arquitectura de
negocios:
Matriz de interaccin de negocios (mostrando la dependencia y la comunicacin 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, segn se
define en la Parte IV , 34. Metamodel contenido .
8.4.1.5 Identificar los diagramas requeridos
Diagramas presentan la informacin 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 descomposicin funcional
Meta / Objetivo diagrama / Servicio
Diagrama de casos de uso
Organizacin diagrama de descomposicin
Diagrama de Flujo del Proceso
Eventos diagrama
Pgina89de670
TOGOF9.1
La estructura de los diagramas se basa en los atributos de las entidades metamodelo, segn se
8.4.1.6 Identificar los tipos de Requisito para ser Collected
Una vez que los catlogos de Arquitectura de Negocios, matrices y diagramas han sido
desarrollados, modelado de arquitectura se completa mediante la formalizacin de los
requerimientos de negocio centrada en la implementacin 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

Tecnologa
Proporcionar orientaciones detalladas que se refleja en el diseo e implementacin para

asegurar que la solucin 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 definicin de la arquitectura no se pretende dar prescripciones detalladas o

generales para una solucin (ya que pueden ser abordados a travs de una mejor disciplina
general de gestin de requisitos). El alcance previsto de contenido requisitos debe establecerse
durante la fase de Visin Arquitectura y documentado en la Declaracin 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 gestin a
travs del proceso de gestin de requisitos gobernados.
8.4.2 Desarrollar basal Arquitectura Descripcin
Desarrollar una descripcin de lnea 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 construccin de arquitectura de negocios pertinentes, aprovechando la arquitectura de
repositorio (vase 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
gua para la creacin de nuevos contenidos arquitectura para describir la arquitectura de lnea de
base.
8.4.3 Desarrollar Target Arquitectura Descripcin
Desarrollar una descripcin 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
Pgina90de670
TOGOF9.1
pertinencia de los elementos de negocio a alcanzar el Objetivo Architecture Vision, y de si existen

descripciones arquitectnicas. En la medida de lo posible, identificar los bloques de construccin
de arquitectura de negocios pertinentes, aprovechando la arquitectura de repositorio (vase la
Parte V , 41. Arquitectura del repositorio ).
gua para la creacin de nuevos contenidos arquitectura para describir la arquitectura destino.
8.4.4 Realizar anlisis de brechas
Verifique los modelos de arquitectura para la coherencia y la precisin interna:
Realizar anlisis 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 lnea base y de destino, utilizando la tcnica de anlisis de carencias
como se describe en la Parte III , 27. Anlisis Gap .
Despus de la creacin de una arquitectura de referencia, Arquitectura objetivo y los resultados de

anlisis de carencias, se requiere un plan de negocios para dar prioridad a las actividades en las
prximas fases.
Esta hoja de ruta inicial Business Architecture se utilizar como materia prima para apoyar
definicin ms 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 ms 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 organizacin?
Pgina91de670
TOGOF9.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 Revisin de Conducta de las partes interesadas Formal
Compruebe la motivacin original para el proyecto de la arquitectura y la Declaracin de

Arquitectura de Trabajo contra la propuesta de arquitectura de negocio, preguntando si es apto
para el propsito de apoyar el trabajo posterior en los otros dominios de la arquitectura. Refinar la
propuesta de arquitectura de negocio slo si es necesario.
8.4.8 Finalizar la Arquitectura de Negocios

Seleccione estndares para cada uno de los bloques de construccin, reutilizando la mayor
cantidad posible de los modelos de referencia seleccionados del repositorio Arquitectura
Documentar completamente cada bloque de construccin
Realizar ltima comprobacin cruzada de la arquitectura global contra objetivos de

negocio; documento de justificacin de la construccin de las decisiones del bloque en el
documento de la arquitectura
Documento Final informe requisitos de trazabilidad
Documento de asignacin definitiva de la arquitectura dentro del Repositorio de

Arquitectura; de los bloques de construccin seleccionados, identificar las que podran ser
re-utilizado (las prcticas de trabajo, roles y relaciones de negocio, descripciones de
puestos, etc), y publican a travs del Repositorio de Arquitectura
Finalice todos los productos de trabajo, tales como los resultados de anlisis de carencias

Justificacin del documento para la construccin de bloquear decisiones en la definicin de
documento Arquitectura
Preparar las secciones de negocios de la definicin de documento de Arquitectura, que

comprende una parte o todos los siguientes:
o La huella de la empresa (una descripcin de alto nivel de la gente y los lugares que
participan en las funciones clave del negocio)
o Una descripcin detallada de las funciones de negocio y sus necesidades de

informacin
o La huella de la gestin (mostrando mbito de control y rendicin de cuentas)
o Normas, reglas y directrices que muestran prcticas de trabajo, legislacin,

medidas financieras, etc
o Una matriz de habilidades y un conjunto de descripciones de puestos
Pgina92de670
TOGOF9.1
En su caso, utilizar los informes y / o grficos generados por las herramientas para
demostrar puntos de vista clave de la arquitectura de modelado. Pase el documento para
su revisin por las partes interesadas pertinentes, e incorporar la retroalimentacin.
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 Visin, en

su caso, entre ellos:
o Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de

Arquitectura de Trabajo ), actualizado en caso necesario
o Validado principios de negocio, objetivos de negocio, y los conductores de

negocios (vase la Parte IV , 36.2.9 Principios de Actuacin, objetivos de
negocio, y los impulsores del negocio ), actualizadas si es necesario
o Principios Arquitectura (ver la Parte IV , 36.2.4 Principios de Arquitectura )
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura

de definicin de documento ), incluyendo:
o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado), si procede
o Objetivo Negocio Arquitectura, Version 1.0 (detallado), incluyendo:
Estructura de la organizacin - la identificacin de lugares de negocios y

relacionndolos 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

descomposicin 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 modificacin de las

necesidades de competencias
Modelo de datos de negocios
La correlacin de la organizacin y funciones - se relacionan las funciones

de negocio a las unidades organizativas en la forma de un informe de
matriz
o Vistas correspondiente a los puntos de vista seleccionados abordar las principales

preocupaciones de las partes interesadas
Pgina93de670
TOGOF9.1
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6

Arquitectura especificacin de requisitos ), incluyendo dichos requisitos y efectos
Arquitectura Profesiones como:
o Los resultados del anlisis de Gap
o Requisitos tcnicos - 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
especficos que se esperan a producirse (por ejemplo, expresado como primitivas
del Marco Zachman)
o Requisitos de negocio actualizados
Componentes de la arquitectura de negocios de una Arquitectura Roadmap (ver la Parte

IV , 36.2.7 Arquitectura Roadmap )
Catlogos:
o Catlogo de Organizacin / Actor
o Conductor / Meta / Objetivo catlogo
o Catlogo de funciones
o Catlogo de servicios de negocios / Funcin
o Ubicacin catlogo
o Proceso / Evento / Control / Catlogo de productos
o Catlogo Contract / Medida
Matrices:
o Matriz de interaccin de negocios
o Matriz Actor / Rol
Diagramas:
o Diagrama de Huella de negocios
o Diagrama de Business Service / Information
o Diagrama de descomposicin funcional
o Diagrama del ciclo de vida del producto
o Meta / Objetivo diagrama / Servicio
o Diagrama de casos de uso
Pgina94de670
TOGOF9.1
o Organizacin diagrama de descomposicin
o Diagrama de Flujo del Proceso
o Diagrama de eventos
Pgina95de670
TOGOF9.1
9 Fase C:. Arquitecturas de Sistemas de Informacin

En este captulo se describen las arquitecturas de los sistemas de informacin para un proyecto de
arquitectura, incluyendo el desarrollo de datos y aplicacin de arquitecturas.

Figura91:FaseC:ArquitecturasdeSistemasdeInformacin
9.1 Objetivos
Los objetivos de la Fase C son:
Desarrollar los sistemas de informacin del objetivo (datos y aplicaciones) Arquitectura,

describiendo cmo los Sistemas de Informacin 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

las brechas entre las arquitecturas de referencia y sistemas de informacin del objetivo
(Application Data y)
9.2 Enfoque
Pgina96de670
TOGOF9.1
Fase C implica una combinacin 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 planificacin de recursos
empresariales (ERP), Gestin de relaciones con clientes (CRM), etc - a menudo, ofrecen una
combinacin de la infraestructura de la tecnologa y la lgica de la aplicacin empresarial, y
algunas organizaciones toman una aplicacin impulsada enfoque, por el que se reconocen
determinadas aplicaciones clave como formando el fundamento bsico de los procesos de negocio
de misin crtica, y toman la implementacin e integracin de las aplicaciones bsicas como el foco
principal de los esfuerzos de arquitectura (los problemas de integracin a menudo constituyen un
reto importante).
9.3 Entradas
Esta seccin define las entradas para la fase C.


de Trabajo )


Pgina97de670
TOGOF9.1
Principios de la aplicacin (ver la Parte III , 23.6.3 Principios de Aplicacin ), si existe
Principios de datos (vase la Parte III , 23.6.2 Datos Principios ), si existe
Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de

Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision )

incluyendo:

o Objetivo Negocio Arquitectura, Version 1.0 (detallado)

Arquitectura especificacin de requisitos ), incluyendo:
o Los resultados del anlisis de Gap (de Arquitectura Empresarial)
o Requisitos tcnicos pertinentes que se aplicarn a la fase C

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 Informacin - Arquitectura de Datos
. 11 Fase C: Arquitecturas de Sistemas de Informacin - Arquitectura de la aplicacin
9.5 Salidas
Pgina98de670
TOGOF9.1
Los principales resultados de la Fase C son:

su caso, entre ellos:


o Objetivo de Arquitectura de aplicaciones, versin 1.0
o Puntos de vista de arquitectura de datos correspondientes a los puntos de vista

seleccionados abordar las principales preocupaciones de las partes interesadas
o Vistas Arquitectura Aplicacin correspondientes a los puntos de vista

seleccionados abordar las preocupaciones de inters clave

Arquitectura especificacin de requisitos ), incluyendo dichos requisitos de Sistemas de
Informacin Arquitectura como:
o Requisitos tcnicos pertinentes que se aplicarn a esta evolucin del ciclo de

desarrollo de la arquitectura
o Las restricciones en la Arquitectura de Tecnologa a punto de ser diseados
o Requisitos de negocio actualizados, en su caso
Componentes de los sistemas de informacin de una Arquitectura Roadmap (ver la Parte

Pgina99de670
TOGOF9.1
. 10 Fase C: Arquitecturas de Sistemas de Informacin - Arquitectura

de Datos
En este captulo 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

las brechas entre la lnea de base y datos de destino Arquitecturas
10.2 Enfoque
10.2.1 Consideraciones clave para la Arquitectura de Datos
10.2.1.1 Gestin de Datos
Cuando una empresa ha optado por realizar la transformacin arquitectnica gran escala, es
importante para comprender y abordar los problemas de gestin de datos. Un enfoque
estructurado y global de la gestin de datos permite el uso eficaz de los datos para sacar provecho
de sus ventajas competitivas.
Las consideraciones incluyen:
Una definicin clara de lo que los componentes de aplicacin en el paisaje servirn como
el sistema de registro o de referencia para los datos maestros de la empresa
Habr un estndar en toda la empresa que todos los componentes de la aplicacin,

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 cmo las entidades de datos son utilizados por las funciones de
negocio, procesos y servicios
Entender claramente cmo y cuando las entidades de datos de empresas se crean,

almacenan, transportan, e inform
Cul es el nivel y la complejidad de las transformaciones de datos requeridas para apoyar

las necesidades de intercambio de informacin entre las aplicaciones?
Cul ser el requisito para el software en el apoyo a la integracin de datos con los
clientes de la empresa y los proveedores (por ejemplo, el uso de herramientas de ETL
Pgina100de670
TOGOF9.1
durante la migracin de datos, los datos de perfiles de herramientas para evaluar la calidad
de datos, etc)?
10.2.1.2 migracin de datos
Cuando se sustituye una aplicacin existente, habr una necesidad crtica para migrar datos
(master, transaccionales y de referencia) para la nueva aplicacin. La Arquitectura de Datos debe
determinar las necesidades de migracin de datos y tambin proporcionar indicadores sobre el
nivel de la transformacin, la escarda, y la limpieza que se requiere para presentar los datos en un
formato que cumpla con las exigencias y limitaciones de la aplicacin de destino. El objetivo es que
la aplicacin de destino tiene datos de calidad cuando est poblado. Otra consideracin clave es
asegurarse de que una definicin comn de datos en toda la empresa se estableci para apoyar la
transformacin.
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 transformacin, de la siguiente manera:
Estructura : Esta dimensin se refiere a si la empresa tiene la estructura organizativa

necesaria y los organismos de normalizacin para gestionar aspectos de entidad de datos
de la transformacin.
Sistema de Gestin : Aqu las empresas deben tener el sistema de gestin 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 dimensin aborda cules son las habilidades y roles de la empresa
relacionadas con los datos requiere para la transformacin. Si la empresa carece de este
tipo de recursos y competencias, la empresa debe considerar o bien la adquisicin de esas
habilidades crticas o capacitacin de los recursos internos existentes para satisfacer las
necesidades a travs de un programa de aprendizaje bien definidos.
Como parte de esta fase, el equipo de arquitectura tendr que considerar qu recursos estn
disponibles arquitectura de datos pertinentes en la arquitectura de repositorio de la organizacin
(vase la Parte V , 41. Arquitectura Repositorio ), en particular, los modelos de datos genricos
relacionados con la industria de la organizacin "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 petrotcnicos.
10.3 Entradas
Esta seccin define las entradas a la Fase C (Arquitectura de Datos).

Pgina101de670
TOGOF9.1

de Trabajo )
10.3.3 Entradas arquitectnicos


Principios de datos (vase la Parte III , 23.6.2 Datos Principios ), si existe


incluyendo:
o Bloques de construccin reutilizables (en particular, las definiciones de los datos

actuales)

Pgina102de670
TOGOF9.1
o Arquitectura de datos de lnea de base, Versin 0.1, si est disponible
o Arquitectura de datos de destino, Versin 0.1, si est disponible
o Lnea de base de arquitectura de aplicaciones, versin 1.0 (detallada) o Versin

0.1 (Vision)
o Objetivo de Arquitectura de aplicaciones, versin 1.0 (detallada) o Versin 0.1

(Vision)
o Lnea de Base Tecnolgica de Arquitectura, Version 0.1 (Vision)
o Tecnologa Target Arquitectura, Version 0.1 (Vision)

o Los resultados del anlisis de Gap (de Arquitectura Empresarial)
o Requisitos tcnicos pertinentes que se aplicarn a esta fase

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 construccin de los datos que se introducen como parte de este esfuerzo
tendr que ser definido en detalle durante la Fase C. existentes bloques de construccin de datos y
que se incorporen y apoyados en el entorno de destino ya se hayan definido de manera adecuada
en la obra arquitectnica anterior; pero, si no, ellos tambin tendrn que ser definidos en la Fase C.
El orden de los pasos de esta fase (vase ms adelante), as como el momento en que se inician
arquitectura establecida. En particular, determinar si en esta situacin, es conveniente llevar a cabo
Descripcin de lnea de base o desarrollo Arquitectura objetivo primero, como se describe en la
Parte III , 19. Aplicando la iteracin de la ADM .
Finalizar la Arquitectura de Datos (ver 10.4.8 finalizar la Arquitectura de Datos ). La documentacin
generada a partir de estas medidas debe ser publicada oficialmente en la Arquitectura paso Crear
definicin de documento (ver 10.4.9 Crear Arquitectura Definicin de documento .
Los pasos en la Fase C (Arquitectura de datos) son los siguientes:
Pgina103de670
TOGOF9.1
10.4.2 Desarrollar Arquitectura de datos de lnea de base Descripcin
10.4.3 Desarrollar Arquitectura de Datos de Blanco Descripcin
10.4.4 Realizar el Anlisis Gap
Conducta 10.4.7 Stakeholder Formal Comentario
10.4.8 Finalizar la Arquitectura de Datos
Opina y validar (o generar, si es necesario) el conjunto de principios de datos. Estos normalmente

formarn 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 electrgenos, temas, auditores, etc,
una variedad de dimensiones de tiempo - en tiempo real, el perodo de presentacin de informes,
impulsado por eventos, etc; lugares, los procesos de negocio ); es decir, los que le permitirn al
arquitecto para demostrar cmo se estn abordando las preocupaciones de los interesados en la
arquitectura de datos.
Identificar las herramientas y tcnicas (incluyendo formas) que se utilizarn para la captura de
datos, el modelado, y el anlisis, en asociacin con los puntos de vista seleccionados
apropiados. Dependiendo del grado de sofisticacin se justifica, stos pueden comprender
documentos u hojas de clculo simples, o herramientas de modelado ms sofisticadas y tcnicas
tales como modelos de gestin de datos, modelos de datos, etc Ejemplos de tcnicas de modelado
de datos son:
Diagrama entidad-relacin
Los diagramas de clases
Pgina104de670
TOGOF9.1
existentes (vase ms 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 ningn catlogo de datos

empresariales existentes y modelos; esto permite el desarrollo de una relacin de
inventario de datos y de la entidad
Actualizar y desarrollar matrices a travs de la arquitectura, relacionando los datos de

servicio de negocio, funcin empresarial, los derechos de acceso, y la aplicacin
Elaborar vistas Arquitectura de datos mediante el examen de cmo se crean los datos,
distribuida, emigrado, asegurado, y se archivan
10.4.1.2 Identificar Catlogos requerido de datos Bloques de Construccin
Inventario de datos de la organizacin se captura como un catlogo dentro de la arquitectura de

repositorio. Los catlogos son de naturaleza jerrquica y capturan una descomposicin de una
entidad metamodelo y descomposiciones en todas las entidades del modelo relacionado (por
ejemplo, el componente lgico de datos -> componente fsico de datos ->] entidad de datos).
Catlogos constituyen la materia prima para el desarrollo de matrices y diagramas, y tambin

Durante la fase de arquitectura de negocio, un diagrama de Servicios de Negocio / Informacin 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 funcin 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 semntica y para eliminar las lagunas y las superposiciones.
Los siguientes catlogos deben ser considerados para el desarrollo dentro de una Arquitectura de
Datos:
Catlogo de Entity Data / componente de datos
Pgina105de670
TOGOF9.1
Las matrices son la materia prima para la elaboracin de diagramas y tambin actan como un
recurso clave para la evaluacin del impacto.
En esta etapa, una entidad a la matriz de aplicaciones podra ser producido para validar este
mapeo. Cmo 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 aplicacin o de datos creada pero nunca
utilizado, deben observarse para el anlisis de brecha ms tarde.
El inventario de datos racionalizada se puede utilizar para actualizar y refinar los diagramas de
arquitectura de cmo los datos se refiere a otros aspectos de la arquitectura.
Una vez realizados estos cambios, puede ser adecuado para caer en un corto iteracin 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 / Funcin comercial (que muestran qu datos apoyan que funciona y qu
funcin negocio posee qu datos)
Servicios de Negocio / Informacin (desarrollada durante la fase de Arquitectura

Empresarial)
Aplicacin / datos (desarrollado a travs de las fases de la arquitectura de aplicaciones y

arquitectura de datos)
10.4.1.4 Identificar Diagramas requeridos
Diagramas presentan la informacin Arquitectura de datos a partir de un conjunto de diferentes

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 sealar en este momento que la informacin puede ser una mezcla de los datos a
nivel de empresa (de los proveedores de servicios del sistema y la informacin el proveedor del
paquete) y los datos de nivel local celebradas en bases de datos personales y hojas de clculo.
El nivel de detalle el modelo debe evaluarse cuidadosamente. Existirn Algunos modelos de datos
fsicos del sistema a un nivel muy detallado; otros slo tendrn las entidades centrales
modelados. No todos los modelos de datos se han guardado hasta al da como las aplicaciones se
modificaron y extendieron en el tiempo. Es importante lograr un equilibrio en el nivel de detalle (por
ejemplo, la reproduccin del sistema detallados esquemas de datos fsicos existentes o presentar
los mapas de procesos de alto nivel y las necesidades de datos, destacar los dos puntos de vista
extremos).
Pgina106de670
TOGOF9.1
Los siguientes diagramas deben ser considerados para el desarrollo dentro de una Arquitectura de
Datos:
Diagrama conceptual de datos
Diagrama de lgica de datos
Diagrama de Divulgacin de Datos
Diagrama del ciclo de vida de datos
Diagrama de seguridad de datos
Diagrama de migracin de datos
Una vez que los catlogos de arquitectura de datos, matrices y diagramas han sido desarrollados,
modelado de arquitectura se completa mediante la formalizacin de los requisitos de datos
enfocada para la implementacin de la arquitectura destino.
Se relacionan con el dominio de datos
Proporcionar los requisitos de entrada en la aplicacin y Tecnologa Arquitecturas

10.4.2 Desarrollar Arquitectura de datos de lnea de base Descripcin
Desarrollar una descripcin de lnea 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 arquitectnicas,
como se describe en 10.2 Enfoque . En la medida de lo posible, identificar los bloques de
construccin de la arquitectura de datos pertinentes, aprovechando la arquitectura de repositorio
(vase la Parte V , 41. Arquitectura del repositorio ).
base.
Pgina107de670
TOGOF9.1
10.4.3 Desarrollar Arquitectura de Datos de Blanco Descripcin
Desarrollar una descripcin Meta para la Arquitectura de datos, en la medida necesaria para
apoyar la Arquitectura Meta y visin 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 consecucin de la
arquitectura destino y de si existen descripciones arquitectnicas. En la medida de lo posible,
identificar los bloques de construccin de la arquitectura de datos pertinentes, aprovechando la
arquitectura de repositorio (vase la Parte V , 41. Arquitectura del repositorio ).
de vista

Despus de la creacin de una arquitectura de referencia, Arquitectura objetivo y anlisis de

brechas, se requiere un plan de datos para dar prioridad a las actividades en las prximas fases.
Esta hoja de ruta inicial Arquitectura de datos se utilizar como materia prima para apoyar
Una vez que la Arquitectura de Datos ha finalizado, es necesario entender los impactos o
repercusiones ms amplias.
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?
Pgina108de670
TOGOF9.1
Hay oportunidades para aprovechar el trabajo de esta arquitectura de datos en otras

Impacta esta arquitectura de datos de otros proyectos (incluyendo los previstos, as como
Esto Arquitectura de Datos verse afectado por otros proyectos (incluidos los previstos, as
como los actualmente en curso)?

Arquitectura de Trabajo contra la arquitectura de datos propuesto. Llevar a cabo un anlisis de
impacto para identificar las reas donde las arquitecturas empresariales y de aplicaciones (por
ejemplo, prcticas 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 aplicacin

est revisando.
Identifique las reas en las que la arquitectura de la aplicacin (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 aplicacin a punto de ser diseados).
Si el impacto es significativo, puede ser apropiado para caer en una breve versin de la
arquitectura de aplicaciones en este punto.
Identificar las posibles limitaciones de la arquitectura de la tecnologa a punto de ser diseados, el

perfeccionamiento de la Arquitectura de Datos propuesta slo si es necesario.
10.4.8 Finalizar la Arquitectura de Datos

Realizar ltima comprobacin cruzada de la arquitectura general de los requerimientos del


reutilizados, y publicar a travs del Repositorio de Arquitectura
Finalice todos los productos de trabajo, tales como anlisis de las deficiencias
Pgina109de670
TOGOF9.1

documento Architecture.
Preparar arquitectura de datos de secciones de la definicin de documento Arquitectura, que

comprende algunos o todos de:
Modelo de datos lgicos
Modelo de proceso de gestin de datos
Entity Data / matriz de funciones de negocios
Requisitos de interoperabilidad de datos (por ejemplo, el esquema XML, las polticas de

seguridad)
En su caso, utilizar los informes y / o grficos 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 retroalimentacin
10.5 Salidas
Los resultados de la Fase C (Arquitectura de datos) pueden incluir, pero no se limitan a:

su caso:

o Principios datos validados (vase la Parte III , 23.6.2 Datos Principios ), o nuevos
principios de datos (si se generan aqu)

o Arquitectura de datos de lnea de base, la versin 1.0, en su caso
Modelo de datos lgicos
Modelos de procesos de gestin de datos
Entity Data / matriz de funciones de negocios

Pgina110de670
TOGOF9.1

Arquitectura especificacin de requisitos ), incluyendo dichos requisitos arquitectura de
datos como:
o Requisitos de interoperabilidad de datos

o Requisitos de las aplicaciones actualizadas, en su caso
Componentes de la arquitectura de datos de una Arquitectura Roadmap (ver la Parte

Catlogos:
o Catlogo de Entity Data / componente de datos
Matrices:
o Entity Data / matriz de funciones de negocios
o Aplicacin / matriz de datos
Diagramas:
o Diagrama conceptual de datos
o Diagrama de lgica de datos
o Diagrama de Divulgacin de Datos
o Diagrama de seguridad de datos
o Diagrama de migracin de datos
o Diagrama del ciclo de vida de datos
Pgina111de670
TOGOF9.1
. 11 Fase C: Arquitecturas de Sistemas de Informacin - Arquitectura

de la aplicacin
Contenidodelcaptulo
11.1 Objetivos|11.2 Enfoque|11.3 entradas|11.4 Pasos|11.5 Salidas
En este captulo se describe la parte Arquitectura de la aplicacin de la Fase C.
11.1 Objetivos
Los objetivos de la parte Arquitectura de la aplicacin de la Fase C son:
Desarrollar la Arquitectura de aplicacin 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

las brechas entre la lnea de base y objetivo de aplicacin de arquitecturas
11.2 Enfoque
Como parte de esta fase, el equipo de arquitectura tendr que considerar qu recursos estn
disponibles arquitectura de aplicaciones relevantes en la arquitectura de repositorio (vase la
Parte V , 41. Arquitectura del repositorio ).
En particular:
Modelos de negocio genricos relacionados con la industria del sector "vertical" de la

organizacin; por ejemplo:
o El TeleManagement Forum (TMF) - www.tmforum.org - ha desarrollado modelos

detallados aplicaciones relevantes para la industria de las Telecomunicaciones.
o El Grupo de Gestin 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 especficos como la salud, Transporte,
Finanzas, etc
Modelos de aplicacin pertinentes a las funciones de negocio de alto nivel comunes, tales
como el comercio electrnico, gestin de la cadena de suministro, etc
The Open Group cuenta con un modelo de referencia para la Informacin Integrada de
Infraestructura (III-RM) - vase la parte VI , 44. Integrado de Informacin Infraestructura Modelo
Pgina112de670
TOGOF9.1
de referencia - que se centra en los componentes de nivel de aplicacin y servicios necesarios

para proporcionar una infraestructura de informacin integrada.
11.3 Entradas
Esta seccin define las entradas a la Fase C (Arquitectura de la aplicacin).


de Trabajo )


Principios de la aplicacin (ver la Parte III , 23.6.3 Principios de Aplicacin ), si existe


incluyendo:
Pgina113de670
TOGOF9.1

o Arquitectura de lnea de base de datos, versin 1.0 (detallados), o la Versin 0.1

(Vision)
o Arquitectura Meta Data, versin 1.0 (detallados), o la Versin 0.1 (Vision)
o Lnea de base de arquitectura de aplicaciones, Versin 0.1, si est disponible

adecuado y si
o Objetivo de Arquitectura de aplicaciones, Versin 0.1, si est disponible
o Lnea de Base Tecnolgica de Arquitectura, Version 0.1 (Vision)
o Tecnologa Target Arquitectura, Version 0.1 (Vision)

o Los resultados del anlisis de Gap (de Arquitectura de Negocios y Arquitectura de

datos, si est disponible)
o Requisitos tcnicos pertinentes que se aplicarn a esta fase
Los componentes empresariales y arquitectura de datos de una hoja de ruta de la

Arquitectura, en su caso (vase 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 construccin de aplicaciones que se estn introduciendo en el marco de este

esfuerzo tendr que ser definido en detalle durante la Fase C. Existentes bloques de construccin
de aplicaciones y que se incorporen y apoyados en el entorno de destino ya se haya definido de
manera adecuada en la obra arquitectnica anterior; pero, si no, ellos tambin tendrn que ser
definidos en la Fase C.
El orden de los pasos de esta fase (ver a continuacin, as como el momento en que se inician
formalmente y completaron debe adaptarse a la situacin en cuestin de acuerdo con el gobierno
arquitectura establecida. En particular, determinar si en esta situacin, es apropiado realizar
Descripcin Lnea de Base o desarrollo Arquitectura objetivo primero, como se describe en la
Pgina114de670
TOGOF9.1
Finalizar la Arquitectura de la aplicacin (ver 11.4.8 finalizar la Arquitectura de la aplicacin ). La
documento ).
Los pasos en la Fase C (Arquitectura de aplicaciones) son las siguientes:
11.4.2 Desarrollar Lnea Base Application Architecture Descripcin
11.4.3 Desarrollar Target Application Architecture Descripcin
11.4.8 Finalizar la arquitectura de aplicaciones
Opina y validar (o generar, si es necesario) el conjunto de principios de aplicacin. Estos

normalmente formarn 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 aplicacin, 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 permitirn al arquitecto para demostrar
cmo se estn abordando las preocupaciones de los interesados en la arquitectura de la
aplicacin.
sofisticacin se justifica, stos pueden comprender documentos simples u hojas de clculo, o
herramientas de modelado ms sofisticadas y tcnicas.
Considere el uso de descripciones independientes de la plataforma de la lgica de negocio. Por

ejemplo, Model Driven Architecture del OMG (MDA) ofrece una aproximacin a las arquitecturas de
modelado de aplicaciones que conserva la lgica de negocio de los cambios en la plataforma
subyacente y la tecnologa de aplicacin.
Pgina115de670
TOGOF9.1
existentes (vase ms arriba).
El proceso recomendado para el desarrollo de una Arquitectura de la aplicacin es la siguiente:
Comprender la lista de aplicaciones o componentes de aplicaciones que se requieren,

sobre la base de la lnea de base del portafolio de aplicaciones, cules son los requisitos, y
el alcance de arquitectura empresarial
Simplifique aplicaciones complejas mediante la descomposicin en dos o ms solicitudes
Asegrese de que el conjunto de definiciones de aplicacin es internamente coherente,

mediante la eliminacin de la funcionalidad duplicado medida de lo posible, y la
combinacin de aplicaciones similares en uno
Identificar las aplicaciones lgicas y las aplicaciones fsicas ms adecuadas
Desarrollar matrices a travs 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 cmo funcionar la aplicacin, la captura de la integracin, la migracin, el
desarrollo y las preocupaciones operacionales
El nivel y el rigor de la descomposicin necesaria vara 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 propsito del esfuerzo arquitectura de la empresa para determinar el nivel de
descomposicin.
El nivel de granularidad debe ser suficiente para permitir la identificacin de brechas y el alcance
de los paquetes de trabajo candidatos.
11.4.1.2 Identificar Catlogos obligatorios de aplicacin Bloques de Construccin
Cartera de Aplicaciones de la organizacin se captura como un catlogo dentro de la arquitectura

de repositorio. Los catlogos son de naturaleza jerrquica y capturan una descomposicin de una
entidad metamodelo y descomposiciones en todas las entidades del modelo relacionado (por
ejemplo, el componente lgico de aplicacin -> componente de aplicacin fsica ->] servicio del
sistema de informacin).

Pgina116de670
TOGOF9.1
Los siguientes catlogos deben ser considerados para el desarrollo dentro de una arquitectura de
aplicaciones:
Catlogo de la cartera de aplicaciones
Catlogo de interfaz
Una vez que la lnea de base de carteras de aplicaciones ha sido montado, es necesario mapear
las aplicaciones para su propsito en el apoyo de la empresa. La asignacin inicial debe centrarse
en los servicios de negocio dentro de la arquitectura de negocio, ya que este es el nivel de
granularidad donde es ms probable que se necesiten decisiones de gran importancia
arquitectnica.
Una vez que las aplicaciones se asignan a los servicios a las empresas, sino que tambin ser
posible hacer asociaciones de las aplicaciones a los datos, a travs de los esquemas de negocio
de informacin desarrollados en Arquitectura Empresarial.
Si disponible, los modelos de datos de aplicaciones de lnea de base pueden ser utilizados para
validar la arquitectura de negocios y tambin 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 iteracin de Arquitectura de datos si se considera que es valioso
para el alcance de la participacin de la arquitectura.
El uso de la informacin existente en el catlogo de aplicaciones de lnea de base, la arquitectura

de la aplicacin debe identificar el usuario y las dependencias organizativas de aplicaciones. Esta
actividad apoyar la futura planificacin de estado mediante la determinacin de las comunidades
de usuarios afectados, as como facilitar la agrupacin de aplicacin segn el tipo de usuario o la
ubicacin del usuario.
Una comunidad de usuarios clave a considerar en concreto es la organizacin de apoyo

operacional. Esta actividad debe examinar las dependencias de aplicacin de las capacidades de
operaciones compartidas y producir un diagrama de la forma en que cada aplicacin es operado y
administrado de manera efectiva.
Considerando especficamente 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:
Aplicacin de la matriz / Organizacin
Pgina117de670
TOGOF9.1
Matriz de Papel / Aplicacin
Matriz de interaccin Aplicacin
Matriz de Aplicacin / Funcin
Diagramas presentan la informacin Arquitectura de la aplicacin de un conjunto de diferentes

Una vez conocida la funcionalidad deseada de una aplicacin, es necesario realizar una evaluacin
interna de cmo debe estructurarse la aplicacin para satisfacer sus necesidades.
En el caso de aplicaciones empaquetadas, es probable que sea el caso de que la aplicacin es

compatible con una serie de opciones de configuracin, mdulos adicionales, o los servicios de
aplicaciones que se pueden aplicar a la solucin. Para las aplicaciones desarrolladas a medida, es
necesario identificar la estructura de alto nivel de la aplicacin en trminos de mdulos o
subsistemas como base para organizar la actividad de diseo.
Los siguientes diagramas deben ser considerados para el desarrollo dentro de una arquitectura de
aplicaciones:
Diagrama de comunicaciones de la aplicacin
Aplicacin y usuario diagrama Ubicacin
Diagrama de administracin de Enterprise
Diagrama Realizacin de proceso / aplicacin
Diagrama de Migracin de aplicaciones
Diagrama de distribucin de software
Software diagrama de Ingeniera
Esquema de aplicacin de casos de uso
Una vez que los catlogos de arquitectura de la aplicacin, matrices y diagramas han sido
desarrollados, modelado de arquitectura se completa mediante la formalizacin de los requisitos de
las aplicaciones enfocadas para la implementacin de la arquitectura destino.
Pgina118de670
TOGOF9.1
Se relacionan con el dominio de aplicacin
Proporcionar los requisitos de entrada en las arquitecturas de datos y tecnologa

11.4.2 Desarrollar Lnea Base Application Architecture Descripcin
Desarrollar una descripcin de lnea 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 aplicacin 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 construccin de arquitectura de aplicacin pertinentes, aprovechando la arquitectura de
repositorio (vase la Parte V , 41. Arquitectura Repositorio ). Si no est ya existentes dentro de la
arquitectura de repositorio, definir cada aplicacin de acuerdo con el catlogo de la Cartera de
Aplicaciones (ver Parte IV , 34. Metamodel contenido ).
base.
11.4.3 Desarrollar Target Application Architecture Descripcin
Desarrollar una descripcin Meta para la arquitectura de la aplicacin, 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 consecucin del Objetivo Architecture Vision, y de si existen descripciones
arquitectnicas. En la medida de lo posible, identificar los bloques de construccin de arquitectura
de aplicacin pertinentes, aprovechando la arquitectura de repositorio (vase la Parte
V , 41. Arquitectura del repositorio ).
de vista
Pgina119de670
TOGOF9.1


brechas, se requiere un plan de aplicacin para dar prioridad a las actividades en las prximas
fases.
Esta hoja de ruta inicial Arquitectura de la aplicacin se utilizar como materia prima para apoyar
Una vez que la arquitectura de la aplicacin se finaliza, es necesario entender los impactos o
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 organizacin?
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)?

Arquitectura de Trabajo contra la propuesta de arquitectura de aplicaciones. Llevar a cabo un
anlisis de impacto, para identificar las reas donde las arquitecturas empresariales y de datos (por
ejemplo, prcticas de negocios) puede que tenga que cambiar para atender a los cambios en la
arquitectura de la aplicacin (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 tecnologa (especialmente la

infraestructura) a punto de ser diseado.
Pgina120de670
TOGOF9.1
11.4.8 Finalizar la arquitectura de aplicaciones

Realizar ltima comprobacin cruzada de la arquitectura general de los requerimientos del


reutilizados, y publicar a travs del Repositorio de Arquitectura

documento Arquitectura
Prepare secciones arquitectura de la aplicacin de la definicin de documento

Arquitectura; en su caso, utilizar los informes y / o grficos 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 retroalimentacin
11.5 Salidas
Los resultados de la Fase C (Arquitectura de la aplicacin) pueden incluir, pero no se limitan a:

su caso:

o Principios de aplicacin validados, o nuevos principios de aplicacin (si se generan

aqu)

o Lnea de base de arquitectura de aplicaciones, la versin 1.0, en su caso
o Objetivo de Arquitectura de aplicaciones, versin 1.0
Modelo de sistemas de proceso
Modelo de sistemas Place
Tiempo modelo de sistemas
Pgina121de670
TOGOF9.1
Modelo de sistemas Gente
o Vistas correspondiente a los puntos de vista seleccionados, abordar las

preocupaciones de inters clave

Arquitectura especificacin de requisitos ), incluyendo dichos requisitos arquitectura de
aplicaciones como:
o Aplicaciones requisitos de interoperabilidad

o Requisitos de datos actualizadas, en su caso
Componentes de la arquitectura de aplicacin de una Arquitectura Roadmap (ver la Parte

Catlogos:
o Catlogo de la cartera de aplicaciones
o Catlogo de interfaz
Matrices:
o Aplicacin de la matriz / Organizacin
o Matriz de Papel / Aplicacin
o Matriz de Aplicacin / Funcin
o Matriz de interaccin Aplicacin
Diagramas:
o Diagrama de comunicaciones de la aplicacin
o Aplicacin y usuario diagrama Ubicacin
o Esquema de aplicacin de casos de uso
o Diagrama de administracin de Enterprise
o Diagrama Realizacin de proceso / aplicacin
Pgina122de670
TOGOF9.1
o Software diagrama de Ingeniera
o Diagrama de Migracin de aplicaciones
o Diagrama de distribucin de software
Pgina123de670
TOGOF9.1
. 12 Fase D: Architecture Tecnologa

En este captulo se describe el desarrollo de una arquitectura de tecnologa para un proyecto de
arquitectura.

Figura121:FaseD:ArchitectureTecnologa
12.1 Objetivos
Los objetivos de la Fase D son:
Desarrollar la Arquitectura Tecnolgica Objetivo que permite la aplicacin lgica y fsica y

los componentes de datos y el Architecture Vision, dirigindose a la Solicitud de
Arquitectura Trabajo y preocupaciones de los interesados

las brechas entre la tecnologa objetivo Arquitecturas de referencia y
12.2 Enfoque
Pgina124de670
TOGOF9.1
Como parte de la fase D, el equipo de arquitectura tendr que considerar qu recursos estn
disponibles Arquitectura Tecnologa relevantes en la arquitectura de repositorio (vase la Parte
En particular:
Servicios de TI existentes tal como se documenta en el repositorio de IT o catlogo de

servicios de TI
TOGAF Modelo Referencia tcnica (TRM)
Modelos tecnolgicos genricos relacionados con la industria del sector "vertical" de la

organizacin
Por ejemplo, el TeleManagement Forum (TMF) - www.tmforum.org - ha desarrollado

modelos de tecnologa detallados relacionados con la industria de las Telecomunicaciones.
Modelos de tecnologa relevante para los sistemas comunes Arquitecturas
Por ejemplo, The Open Group cuenta con un modelo de referencia para la Informacin
Integrada de Infraestructura (III-RM) - vase la parte VI , 44. Integrado de Informacin
Infraestructura Modelo de referencia - que se centra en los componentes de nivel de
aplicacin y servicios bsicos necesarios para proporcionar una infraestructura de
informacin integrada.
12.3 Entradas
Esta seccin define las entradas para la Fase D.

Informacin del producto en productos candidatos

de Trabajo )

Pgina125de670
TOGOF9.1

Principios Tecnologa (ver Parte III , Principios Tecnolgicos 23.6.4 ), si existe


incluyendo:

o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado)
o Target Business Architecture Version 1.0 (detallado)
o Arquitectura de datos de lnea de base, versin 1.0 (detallado)
o Arquitectura de datos de destino, Versin 1.0 (detallado)
o Lnea de base de arquitectura de aplicaciones, versin 1.0 (detallado)
o Objetivo de Arquitectura de aplicaciones, versin 1.0 (detallado)
o Lnea de Base Tecnolgica de Arquitectura, Versin 0.1 (la visin)
o Tecnologa Target Arquitectura, Versin 0.1 (la visin)

Pgina126de670
TOGOF9.1
o Los resultados del anlisis de Gap (de negocios, datos, y aplicacin de

arquitecturas)
o Requisitos tcnicos pertinentes de las fases anteriores
Los componentes empresariales, datos y arquitectura de la aplicacin 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 construccin nueva tecnologa que se introducen como parte de este esfuerzo tendr
que ser definido en detalle durante la Fase D. existente bloques de construccin de tecnologa 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 tecnologa especfica.
El orden de los pasos en la Fase D (vase ms adelante), as como el momento en que se inician
arquitectura establecida. En particular, determinar si en esta situacin, es conveniente llevar a cabo
Descripcin de lnea de base o desarrollo Arquitectura objetivo primero, como se describe en la
Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante el finalizar
el paso Arquitectura Tecnologa (ver 12.4.8 finalizar la Arquitectura de Tecnologa ). La
documento ).
Los pasos en la Fase D son como sigue:
12.4.2 Desarrollar Lnea de Base Tecnolgica Arquitectura Descripcin
12.4.3 Desarrollar Tecnologa Target Arquitectura Descripcin
12.4.8 Finalizar la Arquitectura Tecnologa
Pgina127de670
TOGOF9.1
Revisar y validar el conjunto de principios tecnolgicos. Normalmente, stas formarn 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 tecnologa, se dan en la Parte III , 23. Arquitectura
Principios .
Seleccionar los recursos pertinentes Arquitectura Tecnologa (modelos de referencia, patrones, etc)
de la arquitectura de repositorio (vase 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 tecnolgica que permitan al arquitecto para
demostrar cmo se estn abordando las preocupaciones de los interesados en la arquitectura de la
tecnologa.
sofisticacin requerido, stos pueden comprender documentos y hojas de clculo simples, o
herramientas de modelado ms sofisticadas y tcnicas.
especfico necesario, utilizando la herramienta o mtodo seleccionado.Asegrese de que todas las
preocupaciones de los interesados estn cubiertos. Si no es as, crear nuevos modelos para hacer
frente a ellos, o aumentar los modelos existentes (vase ms arriba).
El proceso para desarrollar una arquitectura de tecnologa incorpora los siguientes pasos:
Definir una taxonoma de los servicios de la plataforma y componentes tecnolgicos

lgicas (incluidas las normas)
Identificar lugares pertinentes en que se despliega la tecnologa
Llevar a cabo un inventario fsico de la tecnologa desplegada y abstracto hasta encajar en

la taxonoma
Mira las aplicaciones y de negocios requisitos para la tecnologa
Es la tecnologa en el lugar apto para el propsito de cumplir con los nuevos requisitos
(es decir, no se cumplen los requisitos funcionales y no funcionales)?
o Refinar la taxonoma
o Seleccin de productos (incluidos los productos dependientes)
Determinacin de la configuracin de la tecnologa seleccionada
Determinar el impacto:
o Dimensionamiento y clculo de costos
Pgina128de670
TOGOF9.1
o La planificacin de capacidad
o Impactos Instalacin / governance / migracin
En las primeras fases de la ADM, ciertas decisiones que se toman en torno a la granularidad de
servicio y los lmites del servicio tendrn implicaciones en el componente de la tecnologa y el
servicio de la plataforma. Las reas en las que pueden verse afectadas la Arquitectura Tecnologa
incluirn 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. Adems, los servicios de granularidad gruesa a veces
puede contener ms informacin de la que realmente se requiere por el sistema solicitante.
Capacidad de mantenimiento : Si granularidad servicio es demasiado gruesa, entonces

la introduccin de cambios en los que el servicio se hace difcil y afecta el mantenimiento
del servicio y de la plataforma en la que se entrega.
Localizacin y Latencia : Servicios pueden interactuar entre s a travs de enlaces a

distancia y la comunicacin entre los servicios tendrn latencia en-construido.Dibujo lmites
de los servicios y el establecimiento de la granularidad de servicio debe considerar el
impacto de plataforma / ubicacin de estas comunicaciones entre los distintos servicios.
Disponibilidad : invocacin Servicio est sujeto a la red y / o deficiencia en el servicio. As

que la alta disponibilidad de comunicacin es una consideracin importante en la
descomposicin de servicio y la definicin de un servicio granular
Los procesos de seleccin del producto pueden ocurrir dentro de la fase de Arquitectura
Tecnolgica donde se reutilizan los productos existentes, se est agregando capacidad
incrementales o de las decisiones de seleccin de productos son un obstculo durante la iniciacin
del proyecto.
Cuando la seleccin 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 travs de las Oportunidades y fase Solutions.
12.4.1.2 Identificar Catlogos requeridos de Tecnologa Building Blocks
Los catlogos son los inventarios de los principales activos de la empresa. Los catlogos son de
naturaleza jerrquica y capturan una descomposicin de una entidad metamodelo y
descomposiciones en todas las entidades del modelo relacionado (por ejemplo, servicio de
plataforma -> componente de tecnologa lgica ->] componente de tecnologa fsica).

La arquitectura de tecnologa debe crear catlogos de tecnologa de la siguiente manera:
Sobre la base de los catlogos existentes en tecnologa y anlisis de las solicitudes

realizadas en la fase de Arquitectura de la aplicacin, se recoge una lista de los productos
en uso.
Pgina129de670
TOGOF9.1
Si los requisitos identificados en la arquitectura de la aplicacin 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 estndares
requeridos.
Clasifica los productos contra el TOGAF TRM en su caso, la extensin del modelo segn
sea necesario para ajustarse a la clasificacin de los productos de la tecnologa en uso.
Si los estndares de tecnologa estn actualmente en vigor, se aplican estos para el

catlogo de componentes de tecnologa para obtener una visin de lnea de base del
cumplimiento de los estndares tecnolgicos.
Los siguientes catlogos deben ser considerados para el desarrollo dentro de una Arquitectura de
Tecnologa:
Los estndares tecnolgicos
Cartera de Tecnologa
La siguiente matriz se debe considerar para el desarrollo dentro de una Arquitectura de

Tecnologa:
Matriz de Aplicacin / Tecnologa
Diagramas presentan la informacin Tecnologa de la Arquitectura de un conjunto de diferentes

Esta actividad proporciona un vnculo entre los requisitos de plataforma y necesidades de

alojamiento, ya que puede necesitar una sola aplicacin que se encuentra fsicamente en varios
ambientes para apoyar el acceso local, los ciclos de vida de desarrollo y necesidades de
alojamiento.
Para las principales aplicaciones de lnea de base o las plataformas de aplicacin (donde mltiples
aplicaciones se alojan en la misma pila de infraestructura), producir un diagrama de pila que
muestra cmo el hardware, sistema operativo, software de infraestructura y aplicaciones
empaquetadas combinan.
En su caso, ampliar los diagramas de arquitectura de aplicaciones de distribucin de software para

mostrar como un mapa de aplicaciones en la plataforma tecnolgica.
Pgina130de670
TOGOF9.1
Para cada medio ambiente, producir un diagrama lgico de la infraestructura de hardware y

software que muestra los contenidos del medio ambiente y las comunicaciones lgicas entre los
componentes. Cuando est disponible, recopilar informacin sobre la capacidad de la
infraestructura desplegada.
Para cada entorno, producen un diagrama fsico de la infraestructura de comunicaciones, tales

como routers, switches, firewalls, y los enlaces de red. Cuando est disponible, recopilar
informacin sobre la capacidad de la infraestructura de comunicaciones.
Los siguientes diagramas deben ser considerados para el desarrollo dentro de una Arquitectura de
Tecnologa:
Ambientes y zonas diagrama
Diagrama de descomposicin Plataforma
Diagrama de Procesamiento
Diagrama de Red Informtica / Hardware
Ingeniera de Comunicaciones diagrama
Una vez que los catlogos de arquitectura tecnolgica, matrices y diagramas han sido
desarrollados, modelado de arquitectura se completa mediante la formalizacin de los requisitos de
la tecnologa centrada en la implementacin de la arquitectura destino.
Se relacionan con el dominio de la tecnologa

12.4.1.6 Seleccione Servicios
Las carteras de servicios son combinaciones de los servicios bsicos de las categoras de servicios
en el TOGAF TRM que no entren en conflicto. La combinacin de los servicios son ms probado
para asegurar el apoyo a las aplicaciones. Este es un requisito previo a la etapa posterior de la
definicin de la arquitectura completamente.
Los requisitos previamente identificados pueden proporcionar informacin ms detallada sobre:
Pgina131de670
TOGOF9.1
Requisitos para los elementos especficos de la organizacin o de las decisiones pre-

existentes (segn corresponda)
Elementos de organizacin preexistentes e invariables (segn corresponda)
Limitaciones del entorno externo hereditarias
Cuando los requisitos exigen definicin de servicios especializados que no son identificados en
TOGAF, debe considerarse la posibilidad de cmo podran ser reemplazados si los servicios
normalizados estarn disponibles en el futuro.
Para cada bloque de construccin, construir una descripcin 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 aplicacin.
12.4.2 Desarrollar Lnea de Base Tecnolgica Arquitectura Descripcin
Desarrollar una descripcin de lnea de base de la arquitectura de la tecnologa existente, para

apoyar la tecnologa 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 Tecnologa
Arquitectura de componentes de tecnologa existentes, y de si existen descripciones
arquitectnicas, como se describe en 12.2 Enfoque .
Identificar los componentes bsicos Arquitectura Tecnologa pertinentes, aprovechando cualquier

artefacto, celebrada en la arquitectura de repositorio. Si nada existe dentro de la arquitectura de
repositorio, definir cada solicitud en lnea con el catlogo Cartera Tecnolgica (vase la Parte
IV , 34. Metamodel contenido ).
Comience por la conversin de la descripcin del ambiente existente en los trminos de la

Fundacin de Arquitectura de la organizacin (por ejemplo, la TRM de la Fundacin 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
definicin arquitectnica anterior, pero se supone que alguna adaptacin puede ser requerido para
que coincida con las tcnicas de definicin de arquitectura que se describen como parte de este
proceso. Otra tarea importante es establecer una lista de preguntas clave que se pueden utilizar
ms adelante en el proceso de desarrollo para medir la eficacia de la nueva arquitectura.
base.
12.4.3 Desarrollar Tecnologa Target Arquitectura Descripcin
Desarrollar una descripcin Meta para la Tecnologa 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 tecnologa para el logro de la arquitectura destino y de si existen descripciones
arquitectnicas. En la medida de lo posible, identificar los bloques de construccin de arquitectura
de la tecnologa pertinentes, aprovechando la arquitectura de repositorio (vase la Parte
Pgina132de670
TOGOF9.1
Un proceso clave en la creacin de un amplio modelo de arquitectura del sistema de destino es la

conceptualizacin de los bloques de construccin. Arquitectura Bloques de Construccin (Abs)
describen la funcionalidad y la forma en que pueden ponerse en prctica sin el detalle presentado
por la configuracin o diseo detallado. El mtodo de definicin de bloques de construccin, junto
con algunas pautas generales para su uso en la creacin de un modelo arquitectnico, se describe
en la Parte IV , 37.3 Bloques de Construccin y de la ADM .
de vista


brechas, una hoja de ruta tecnolgica es necesaria para dar prioridad a las actividades en las
prximas fases.
Esta hoja de ruta inicial Arquitectura Tecnologa ser utilizado como materia prima para apoyar
Una vez que la Tecnologa de la Arquitectura est finalizado, es necesario entender los impactos o
para identificar:
Crea esto Arquitectura Tecnolgica un impacto en las arquitecturas preexistentes?
Se han hecho los cambios recientes que impactan la Arquitectura de Tecnologa?
Pgina133de670
TOGOF9.1
Hay oportunidades para aprovechar el trabajo de esta Arquitectura Tecnologa en otras

Impacta esta Arquitectura Tecnolgica otros proyectos (incluidos los previstos, as como
Esto Arquitectura Tecnologa verse afectado por otros proyectos (incluidos los previstos,
as como los actualmente en curso)?

Arquitectura de Trabajo contra la Arquitectura de Tecnologa propuesto, preguntando si es apto
para el propsito de apoyar el trabajo posterior en los otros dominios de la arquitectura. Refinar la
Arquitectura de Tecnologa propuesto slo si es necesario.
12.4.8 Finalizar la Arquitectura Tecnologa

Realizar ltima comprobacin cruzada de la arquitectura global contra objetivos de


re-utilizado (las prcticas de trabajo, roles y relaciones de negocio, descripciones de
puestos, etc), y publican a travs del Repositorio de Arquitectura
Documentar las razones para la creacin de bloquear decisiones en la definicin de documento

Architecture.
Preparar las secciones de tecnologa de la definicin de documento de Arquitectura, que

comprende una parte o todos los siguientes:
Funcionalidad y atributos Fundamental -, incluyendo la capacidad de seguridad sin

ambigedades semnticas y manejabilidad
Bloques de construccin dependientes con la funcionalidad requerida y llamado interfaces
Interfaces - conjunto elegido, suministrado (APIs, formatos de datos, protocolos, interfaces

de hardware, estndares)
Mapa de negocios / entidades organizativas y polticas
Pgina134de670
TOGOF9.1
En su caso, utilizar los informes y / o grficos generados por las herramientas para demostrar
puntos de vista clave de la arquitectura de modelado. Pase el documento para su revisin por las
partes interesadas pertinentes, e incorporar la retroalimentacin.
12.5 Salidas
Los resultados de la Fase D pueden incluir, pero no se limitan a:

su caso:

o Principios tecnolgicos validados, o nuevos principios tecnolgicos (si se generan

aqu)

o Tecnologa Target Arquitectura, Version 1.0 (detallado), incluyendo:
Componentes tecnolgicos y sus relaciones con los sistemas de

informacin
Las plataformas tecnolgicas y su descomposicin, que muestra las

combinaciones de tecnologa necesarios para hacer realidad una
tecnologa de "pila" en particular
Entornos y localizaciones - una agrupacin de la tecnologa necesaria en

entornos de computacin (por ejemplo, desarrollo, produccin)
Carga de procesamiento esperado y la distribucin de la carga entre los

componentes de tecnologa
(Red) de las comunicaciones fsicas
Las especificaciones de hardware y de red
o Lnea de Base Tecnolgica de Arquitectura, Version 1.0 (detallado), si procede


Arquitectura especificacin de requisitos ), incluyendo dichos requisitos Arquitectura
Tecnologa como:
o Requisitos de salida de las fases B y C
o Requisitos tecnolgicos actualizados
Pgina135de670
TOGOF9.1
Componentes Arquitectura de Tecnologa de la Arquitectura Roadmap (ver la Parte

Catlogos:
o Catlogo de Normas de Tecnologa
o Catlogo Cartera Tecnolgica
Matrices:
o Matriz de Aplicacin / Tecnologa
Diagramas:
o Ambientes y zonas diagrama
o Diagrama de descomposicin Plataforma
o Diagrama de Procesamiento
o Diagrama de Red Informtica / Hardware
o Ingeniera de Comunicaciones diagrama
12.6 PostScript
La eleccin del mbito de un ciclo de desarrollo de la arquitectura cuidadosamente acelerar la
amortizacin. Por el contrario, es poco probable que conduzca a la implementacin exitosa de un
alcance excesivamente grande.
Pgina136de670
TOGOF9.1
. 13 Fase E: Oportunidades y Soluciones

En este captulo se describe el proceso de identificacin de los vehculos de reparto (proyectos,
programas o portafolios) que cumplir efectivamente con la arquitectura destino identificado en las
fases anteriores.

Figura131:FaseE:OportunidadesySoluciones
13.1 Objetivos
Los objetivos de la Fase E son para:
Generar la versin completa inicial de la Hoja de Ruta de la Arquitectura, en base al

anlisis 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

transicin que ofrecer un valor empresarial continuo
Pgina137de670
TOGOF9.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 lgica 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 disposicin de la empresa de transformacin de negocios,
oportunidades y soluciones identificadas, y las limitaciones de ejecucin definidas. La clave est en
centrarse en el objetivo final, mientras que la realizacin de valor de negocio incrementales.
Fase E es el paso inicial en la creacin de la aplicacin y el Plan de Migracin, que se completa en

la Fase F. Proporciona la base de una implementacin bien considerado y Plan de Migracin que
se integra en la cartera de la empresa en la fase F.
Los siguientes cuatro conceptos son clave para la transicin de desarrollo para la entrega de una
Arquitectura de destino:
Arquitectura Roadmap
Paquetes de Trabajo
Arquitecturas de transicin
Implementacin y Plan de Migracin
La Arquitectura Roadmap enumera los paquetes de trabajo individuales en una lnea de tiempo
que se dar cuenta de la arquitectura destino.
Cada paquete de trabajo identifica un grupo lgico de los cambios necesarios para darse cuenta de
la arquitectura destino.
Una arquitectura de transicin se describe la empresa en un estado de gran importancia

arquitectnica entre la lnea de base y Target Arquitecturas. Arquitecturas de transicin
proporcionan arquitecturas objetivo intermedio sobre el cual la organizacin puede converger.
La aplicacin y el Plan de Migracin ofrece un calendario de los proyectos que realizarn la

arquitectura destino.
13.3 Entradas
Esta seccin define las entradas para la fase E.

Informacin sobre producto

de Trabajo )
Pgina138de670
TOGOF9.1
Metodologas de planificacin

Los modelos de gobernanza y los marcos para:
o Planificacin Ejecutiva
o Arquitectura Empresarial
o Portafolio, Programa, Gestin de Proyectos
o Desarrollo de Sistemas / Ingeniera
o Operaciones (Servicio)



incluyendo:
Pgina139de670
TOGOF9.1

o Lnea de Base Tecnolgica de Arquitectura, Version 1.0 (detallado)
o Tecnologa Target Arquitectura, Version 1.0 (detallado)

o Requisitos arquitectnicos
o Los resultados del anlisis de Gap (de negocios, datos, aplicaciones, y

Arquitectura de Tecnologa)
o Requisitos de gestin de servicios de TI
Solicitudes de cambio para los programas y proyectos de negocios existentes (vase 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 (vase ms adelante), as como el momento en que se inician
Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante el paso de
crear la Arquitectura Roadmap e Implementacin y Plan de Migracin (ver 13.4.11 Crear la Hoja de
Ruta de Arquitectura e Implementacin y Plan de Migracin ).
Los pasos en la Fase E son como sigue:
Principales cambios corporativos Atributos 13.4.1 Determinar / Confirmar
Pgina140de670
TOGOF9.1
13.4.2 Determinar restricciones comerciales para la Implementacin
13.4.3 Revisar y consolidar Anlisis Gap Resultados de las Fases B a D
13.4.4 Requisitos revisin 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 Preparacin y el riesgo para la Transformacin de Negocios
13.4.8 Formular Implementacin y Estrategia de migracin
13.4.9 Identificar y Grupo de Trabajo de los principales paquetes
13.4.10 Identificar Arquitecturas de transicin
13.4.11 Cree la Arquitectura Roadmap e Implementacin y Plan de Migracin
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 organizacin. Esto debe incluir la creacin de una
evaluacin de la instrumentacin Factor y la matriz de la deduccin (vase la Parte III , Evaluacin
Factor 28.1 Implementacin & Matrix Deduccin ) para servir como un repositorio de
implementacin de la arquitectura y las decisiones de migracin. El paso tambin incluye la
evaluacin de las capacidades de transicin de las unidades de la organizacin 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 evaluacin de la

instrumentacin Factor y la matriz de deduccin. 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 Implementacin
Identificar los factores de negocio que limitaran la secuencia de ejecucin. Esto debe incluir una
revisin de los planes de negocio y estratgicos, tanto a nivel corporativo y de lnea de negocio, y
una revisin de la Evaluacin de Madurez de Arquitectura Empresarial.
13.4.3 Revisar y consolidar Anlisis Gap Resultados de las Fases B a D
Consolidar e integrar los resultados del anlisis de brecha de los Negocios, Sistemas de
Informacin y Tecnologa 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
creacin 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 identificacin de las soluciones de Bloques de Construccin (SBB) que potencialmente
podran abordar uno o ms huecos y sus asociados Bloques Arquitectura Edificios (Abs).
Pgina141de670
TOGOF9.1
Revise la Fase B, C, y D gap resultados de los anlisis y consolidarlas en una sola lista. Las
lagunas deben ser consolidados, junto con las posibles soluciones a las deficiencias y
dependencias. Una tcnica recomendada para la determinacin de las dependencias es el uso de
conjuntos de puntos de vista tales como la matriz de interaccin de negocios, la matriz de
funciones de Entity Data / de negocios, y la matriz de Uso / funcin 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 vacos, consulte la evaluacin de la instrumentacin Factor y la matriz de
deduccin y revisar los factores de implementacin.Cualquier factores adicionales deben aadirse
a la evaluacin de la instrumentacin Factor y la matriz de deduccin.
13.4.4 Requisitos revisin consolidada Across Funciones comerciales relacionadas
Evaluar las necesidades, las carencias, las soluciones y los factores para identificar un conjunto
mnimo de requisitos cuya integracin en paquetes de trabajo dara lugar a una aplicacin ms
eficiente y eficaz de la arquitectura destino a travs de las funciones de la empresa que estn
participando en la arquitectura. Esta perspectiva funcional conduce a la satisfaccin de mltiples
necesidades a travs de la provisin de soluciones y servicios compartidos. Las implicaciones de
esta consolidacin de los requisitos con respecto a los componentes de la arquitectura pueden ser
significativos en relacin con la provisin de recursos. Por ejemplo, varios requisitos planteados por
varias lneas de negocio se pueden resolver a travs de la provisin de un conjunto de servicios de
oficina y servicios de informacin 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 visin Arquitecturas, as como la evaluacin de la instrumentacin Factor y la matriz de
deduccin y Lagunas consolidados, Soluciones, y la matriz de dependencias, se deben consolidar
y crtica para identificar las limitaciones en materia de interoperabilidad exigidos por el conjunto
potencial de las soluciones.
Un resultado clave es reducir al mnimo los conflictos de interoperabilidad, o para asegurar este
tipo de conflictos se tratan en la arquitectura. Re-Solution utilizan bloques de construccin (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 Tecnologa).
Hay dos enfoques bsicos para los conflictos de interoperabilidad; o bien crear un bloque de
construccin que transforma o convierte entre bloques de construccin en conflicto, o hacer un
cambio a la especificacin de los bloques de construccin en conflicto.
13.4.6 Afinar y Validate Dependencias
Refinar las dependencias iniciales, asegurando que se identifican las posibles limitaciones en la
aplicacin y los planes de migracin. Hay varias dependencias clave que deben tenerse en cuenta,
como las dependencias en las implementaciones existentes de servicios de oficina y servicios de
informacin del sistema o cambios en ellos.Dependencias deben utilizarse para determinar la
Pgina142de670
TOGOF9.1
secuencia de la ejecucin y la identificacin de la coordinacin necesaria. Un estudio de las

dependencias deberan agrupar actividades, la creacin de una base para proyectos que se
establezcan. Examinar los proyectos pertinentes y ver si los incrementos lgicos de entregables
pueden ser identificados. Las dependencias tambin ayudar a identificar cuando los incrementos
sealados pueden ser entregados. Una vez terminado, una evaluacin de estas dependencias
debe documentarse como parte de la Hoja de Ruta de la Arquitectura y las arquitecturas de
transicin necesarios.
Abordar dependencias sirve de base para la mayor parte de planificacin de la migracin.
13.4.7 Confirmar la Preparacin y el riesgo para la Transformacin de Negocios
Revise los resultados de la Evaluacin de la preparacin de transformacin de negocios realizado

previamente en la Fase A y determinar su impacto en la Hoja de Ruta de la Arquitectura y la
aplicacin y estrategia de migracin. Es importante identificar, clasificar y mitigar los riesgos
asociados con el esfuerzo de transformacin. Los riesgos se deben documentar los boquetes
consolidados, soluciones, y la matriz de dependencias.
13.4.8 Formular Implementacin y Estrategia de migracin
Crear una aplicacin global y estrategia de migracin que guiar la implementacin de la

arquitectura destino, y estructurar las arquitecturas de transicin. La primera actividad consiste en
determinar un enfoque estratgico global para la implementacin de las soluciones y / o
aprovechamiento de las oportunidades. Hay tres enfoques bsicos como sigue:
Greenfield: Una completamente nueva implementacin.
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 continuacin, determine un enfoque para la direccin estratgica general que tratar y mitigar los
riesgos identificados en las lagunas consolidados, soluciones, y la matriz de dependencias. Las
metodologas de implementacin ms comunes son:
Victoria rpida (instantneas)
Metas alcanzables
Mtodo de la cadena de valor
Estos enfoques y las dependencias identificadas deberan ser la base para la creacin de los
paquetes de trabajo. Esta actividad termina con un acuerdo sobre la aplicacin y estrategia de
migracin 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.
Pgina143de670
TOGOF9.1
Uso de las Lagunas consolidados, soluciones, y la matriz de dependencias, junto con la evaluacin
de la instrumentacin Factor y la matriz de deduccin, lgicamente agrupar las diversas actividades
en paquetes de trabajo.
Rellene la columna "Solucin" los boquetes consolidados, Soluciones, y la matriz de dependencias

para recomendar los mecanismos de solucin propuestos. Indique para cada hueco / actividad si la
solucin debe orientarse hacia un nuevo desarrollo, o basarse en un producto ya existente, y / o el
uso de una solucin 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 travs de un contrato.
Clasifique cada sistema actual que se est considerando como:
Mainstream: Parte de un futuro sistema de informacin.
Contener: Se espera que sea reemplazado o modificado en el horizonte de planificacin

(prximos tres aos).
Vuelva a colocar: Se sustituir en el horizonte de planificacin.
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 transformacin empresarial y el enfoque estratgico
de implementacin. 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 estratgico de
implementacin.
13.4.10 Identificar Arquitecturas de transicin
Si el mbito del cambio para implementar la Arquitectura objetivo requiere un enfoque incremental,
entonces una o ms arquitecturas de transicin pueden ser necesarios.Estos proporcionan la
capacidad de identificar objetivos claros a lo largo de la hoja de ruta para la realizacin de la
arquitectura destino. Las arquitecturas de transicin deben proporcionar un valor comercial
mensurable. El lapso de tiempo entre las arquitecturas de transicin sucesivos no tiene que ser de
duracin uniforme.
Desarrollo de Transicin Arquitecturas debe basarse en el enfoque de implementacin 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 difciles, y salvo que existan razones de peso, aplicarlas
despus de que otras actividades que proporcionan ms fcilmente la capacidad faltante.
13.4.11 Cree la Arquitectura Roadmap e Implementacin y Plan de Migracin
Consolidar los paquetes de trabajo y transicin Arquitecturas en la Hoja de Ruta de la Arquitectura,

Versin 0.1, que describe una lnea de tiempo de la progresin de la Arquitectura de referencia
para la arquitectura destino. La lnea de tiempo informa a la aplicacin y el Plan de Migracin. La
Arquitectura Roadmap enmarca la planificacin de la migracin en la Fase F. Identificado
Transicin Arquitecturas y paquetes de trabajo deben tener un claro conjunto de resultados. La
Pgina144de670
TOGOF9.1
Hoja de Ruta de la Arquitectura debe demostrar cmo la seleccin y el calendario de transicin

Arquitecturas y paquetes de trabajo se da cuenta de la arquitectura destino.
El detalle de la Arquitectura Roadmap, Versin 0.1 debe expresarse en un nivel de detalle similar a
la definicin de documento Arquitectura desarrollado en las fases B, C y D. Cuando se requiere el
detalle adicional significativa antes de la implementacin de la arquitectura es probable que la
transicin a un nivel diferente . Ver Parte III , 19.Aplicando la iteracin de la ADM y 20. Aplicando
la ADM a travs de la Arquitectura del Paisaje de tcnicas para manejar la iteracin y los
diferentes niveles de detalle.
La aplicacin y el Plan de Migracin deben demostrar la actividad necesaria para darse cuenta de
la Arquitectura Roadmap. La aplicacin y el Plan de Migracin es la base de la planificacin de la
migracin en la Fase F. El detalle de la aplicacin y el Plan de Migracin, Versin 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 aplicacin y el Plan de Migracin hay muchos enfoques a tener en cuenta, como una
secuencia basada en datos, donde los sistemas de aplicacin que crean datos se aplican en primer
lugar, a continuacin, las aplicaciones que procesan los datos. Se requiere una comprensin clara
de las dependencias y del ciclo de vida de SBB en el lugar para una aplicacin efectiva y el Plan de
Migracin.
Finalmente, actualice la Architecture Vision, Arquitectura Definicin de documento, y Arquitectura

Requisitos Especificacin con ningn resultado pertinentes adicionales de esta fase.
13.5 Salidas
Los resultados de la Fase E pueden incluir, pero no se limitan a:
Versin refinada y actualizada de los entregables de la fase Arquitectura Visin, en su

caso, entre ellos:
o Architecture Vision, incluyendo la definicin de los tipos y grados de

interoperabilidad


o Lnea de base de Empresas Arquitectura, versin 1.0 actualiza si es necesario
o Objetivo Negocio Arquitectura, versin 1.0 actualiza si es necesario
o Arquitectura de datos de lnea de base, versin 1.0 actualiza si es necesario
o Arquitectura de datos de destino, versin 1.0 actualiza si es necesario
o Lnea de base de arquitectura de aplicaciones, la versin 1.0 actualiza si es

necesario
Pgina145de670
TOGOF9.1
o Objetivo de Arquitectura de aplicaciones, la versin 1.0 actualiza si es necesario
o Lnea de Base Tecnolgica de la Arquitectura, la versin 1.0 actualiza si es

necesario
o Tecnologa Target Arquitectura, versin 1.0 actualiza si es necesario
o Arquitectura de transicin, el nmero y el alcance que sea necesario


o Brechas consolidados, soluciones y Dependencias de Evaluacin
Evaluaciones de capacidad, entre ellos:
o Evaluacin de la capacidad del negocio
o Evaluacin de Capacidad de TI
Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap ), incluyendo:
o Cartera Paquete de trabajo:
Trabajo descripcin del paquete (nombre, descripcin, objetivos)
Requisitos funcionales
Dependencias
Relacin con la oportunidad
Relacin a la Arquitectura de definicin de documento y Arquitectura

Especificacin de Requisitos
Relacin con cualesquiera incrementos de capacidad
El valor del negocio
Evaluacin Factor Implementacin y Matrix Deduccin
Impacto
o Identificacin de Transicin Arquitecturas, en su caso, incluyendo:
Relacin a la Arquitectura de definicin de documento
o Recomendaciones para la implementacin:
Criterios de valoracin de la eficacia
Riesgos y problemas
Pgina146de670
TOGOF9.1
Bloques de Solucin de construccin (SBB)
Implementacin y Plan de Migracin, Versin 0.1, incluyendo:
o Implementacin y Estrategia de migracin
Diagramas:
o Diagrama de Contexto del Proyecto
o Diagrama de Beneficios
Pgina147de670
TOGOF9.1
14 Fase F:. Planeamiento de migracin

Este captulo se ocupa de la planificacin de la migracin; es decir, cmo pasar de la lnea de base
para las arquitecturas objetivo al finalizar una implementacin detallada y Plan de Migracin.

Figura141:FaseF:planeamientodemigracin
14.1 Objetivos
Los objetivos de la Fase F son para:
Finalizar la Arquitectura Hoja de Ruta y la aplicacin de soporte y Plan de Migracin
Asegrese de que la aplicacin y el Plan de Migracin se coordina con el enfoque de la

empresa para la gestin y la implementacin de cambios en la cartera de cambio general
de la empresa
Asegrese de que el valor para el negocio y el costo de los paquetes de trabajo y

transicin Arquitecturas Se entiende por las partes interesadas clave
Pgina148de670
TOGOF9.1
14.2 Enfoque
El objetivo de la Fase F es la creacin de un Plan de Implementacin y Migracin, en cooperacin
con la cartera y los directores de proyectos.
Fase E proporciona una hoja de ruta de la Arquitectura incompleta e Implementacin y Plan de

Migracin que se ocupan de la Solicitud de Arquitectura Obra. En la Fase F esta hoja de ruta y la
aplicacin y el Plan de Migracin se integran con otras actividades de cambio de la empresa.
Las actividades incluyen la evaluacin de las dependencias, los costos y beneficios de los diversos
proyectos de migracin en el contexto de de la empresa cualquier otra actividad. La Hoja de Ruta
de la Arquitectura, Versin 0.1 e Implementacin y Plan Migracin, Versin 0.1 de la Fase E
formarn la base de la aplicacin final y plan de migracin 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 seccin define las entradas para la fase F.


de Trabajo )

Los modelos de gobernanza y los marcos para:
o Planificacin Ejecutiva
Pgina149de670
TOGOF9.1
o Arquitectura Empresarial
o Portafolio, Programa, Gestin de Proyectos
o Desarrollo de Sistemas / Ingeniera
o Operaciones (Servicio)



incluyendo:

o Lnea de Base Tecnolgica de Arquitectura, Version 1.0 (detallado)
o Tecnologa Target Arquitectura, Version 1.0 (detallado)
o Arquitecturas de transicin, si los hay

Pgina150de670
TOGOF9.1
o Los resultados del anlisis de Gap (de negocios, datos, aplicaciones, y

Arquitectura de Tecnologa)
o Requisitos de gestin de servicios de TI
Solicitudes de cambio para los programas y proyectos de negocios existentes (vase la

Parte IV , 36.2.11 Solicitud de cambio )
Arquitectura Roadmap, Versin 0.1 (vase la Parte IV , 36.2.7 Arquitectura Roadmap ),

incluyendo:
o Identificacin de los paquetes de trabajo
o Identificacin de transicin Arquitecturas
o Evaluacin Factor Implementacin y Matrix Deduccin
Evaluacin de capacidades (vase la Parte IV , Evaluacin 36.2.10 Capability ),

incluyendo:
o Evaluacin de la capacidad del negocio
o Evaluacin de Capacidad de TI
Implementacin y Plan de Migracin, Versin 0.1 (vase la Parte IV , 36.2.14

Implementacin y Plan de Migracin ), incluyendo la aplicacin de alto nivel y la estrategia
de migracin
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 (vase ms adelante), as como el momento en que se inician
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 Aplicacin y el Plan de

Migracin
14.4.2 Asignar un valor de negocio para cada paquete de trabajo
14.4.3 Requisitos de Recursos de Estimacin, Proyecto sincronizaciones, y la

disponibilidad / vehculo Entrega
Pgina151de670
TOGOF9.1
14.4.4 Dar prioridad a los proyectos de migracin a travs de la realizacin de una

evaluacin costo / beneficio y Validacin de Riesgos
14.4.5 Confirmar Arquitectura Roadmap y Actualizacin Arquitectura Definicin de

documento
14.4.6 Generar la aplicacin y el Plan de Migracin
14.4.7 Completar el Ciclo de Desarrollo de Arquitectura y documentar las lecciones

aprendidas
14.4.1 Confirmar Management Framework Interacciones para la Aplicacin y el Plan de

Migracin
Este paso es sobre la coordinacin de la aplicacin y el Plan de Migracin con los marcos de
gestin dentro de la organizacin. En general, existen cuatro marcos de gestin que tienen que
trabajar en estrecha colaboracin para la Aplicacin y el Plan de Migracin para tener xito:
Planificacin 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 / Gestin de Proyectos que coordina, disea y construye los sistemas de

negocio que ofrecen los resultados de negocio concretos.
Gestin de Operaciones , que integra, opera y mantiene las prestaciones que ofrecen los
resultados de negocio concretos.
La aplicacin y el Plan de Migracin tendrn 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 organizacin y asegurar que estos planes estn 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 aplicacin y el Plan de Migracin podra ser parte de
un plan diferente producido por otro de los marcos con la participacin 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 intencin es
establecer primero lo constituye el valor del negocio dentro de la organizacin, cmo se puede
medir el valor, y luego aplicar esto a cada uno de los proyectos y los incrementos de los proyectos.
Si la planificacin de capacidades basada se ha utilizado, a continuacin, 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:
Pgina152de670
TOGOF9.1
Criterios de evaluacin de rendimiento son utilizados por la cartera y la capacidad de

los gestores para aprobar y supervisar el progreso de la transformacin de la arquitectura.
Retorno de la Inversin Criterios tienen que ser detallado y firmado por las distintas
partes interesadas ejecutivos.
Valor de negocio tiene que ser definido, as como las tcnicas, 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
relacin con el retorno de la inversin se puede utilizar para determinar si un esfuerzo
avanza, se retrasa o se cancela.
Factores Crticos 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 implementacin 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 cmo estos criterios se debern agrupar.
Fit Estratgico basado en la arquitectura de la empresa en general (todos los niveles)

ser el factor clave para permitir a la aprobacin de cualquier nuevo proyecto o iniciativa y
para la determinacin del valor de cualquier entrega.
Utilice los paquetes de trabajo como base de la identificacin de proyectos que estarn en la
aplicacin y el Plan de Migracin. Los proyectos identificados se desarrollarn plenamente en otras
etapas de la Fase F. Los proyectos, y los incrementos de los proyectos, puede requerir el ajuste de
la definicin 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
agregacin 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 tcnica de evaluacin de valor de
negocio (vase la Parte III , 28,5 Business Value Tcnica de Evaluacin ).
14.4.3 Requisitos de Recursos de Estimacin, Proyecto sincronizaciones, y la

disponibilidad / vehculo 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.
Pgina153de670
TOGOF9.1
14.4.4 Dar prioridad a los proyectos de migracin a travs de la realizacin de una

evaluacin costo / beneficio y Validacin de Riesgos
Dar prioridad a los proyectos por parte de la determinacin de su valor comercial contra el costo de
la entrega de ellos. El enfoque consiste en determinar en primer lugar, lo ms claramente posible,
el beneficio neto de todos los dispositivos SBB entregados por los proyectos, a continuacin,
compruebe que los riesgos se han mitigado y factor in Posteriormente efectivamente, la intencin
es ganar el requisito de consenso para crear una lista priorizada de proyectos que servirn de base
para la asignacin 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 inters de acuerdo en un orden de prioridad de los proyectos. Criterios de
importancia utilizarn elementos identificados en la creacin del proyecto de Arquitectura Roadmap
en la Fase E, as como los relativos a las agendas de los grupos de inters individuales. Tenga en
cuenta que es posible que un proyecto para ganar una alta prioridad si proporciona un entregable
crtico en el camino a algunos grandes beneficios, incluso si el beneficio inmediato del proyecto en
s es pequeo.
Formalmente revisar la evaluacin de riesgos y revisarlo si es necesario garantizar que exista una
plena comprensin del riesgo residual asociado con el establecimiento de prioridades y la lnea de
financiacin proyectada.
14.4.5 Confirmar Arquitectura Roadmap y Actualizacin Arquitectura Definicin de

documento
Actualizacin de la Hoja de Ruta de la Arquitectura incluidas las arquitecturas de

transicin. Revisar el trabajo hasta la fecha para evaluar lo que los lapsos de tiempo entre la
arquitectura de transicin 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 consolidacin 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 simultneas de las
diversas arquitecturas. Una transicin Arquitectura Estado Tabla Evolution (ver Parte III , 28,4
Transicin 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 ejecucin ha cambiado como resultado de la confirmacin de los incrementos de

aplicacin, actualice la definicin de documento Architecture. Esto puede incluir la asignacin de
los objetivos del proyecto y la alineacin de los proyectos y sus entregables con las arquitecturas
de transicin para crear una definicin de Arquitectura Incrementos tabla (ver la Parte III , 28,3
Arquitectura Definicin Tabla Incrementos ).
Pgina154de670
TOGOF9.1
14.4.6 Generar la aplicacin y el Plan de Migracin
Generar la aplicacin completada y el Plan de Migracin. Muchos de los detalles para el plan ya ha
sido reunida y este paso trae todo junto usando la planificacin aceptado y tcnicas de gestin.
Esto debera incluir la integracin de todos los proyectos y actividades, as como las dependencias
y los efectos del cambio en un plan de proyecto. Cualquier Arquitecturas transicin actuarn 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 aplicacin y
el Plan de Migracin.
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 realizacin de la

arquitectura. Si el vencimiento de las rdenes de Arquitectura de capacidad, un Modelo de
Gobierno La implementacin puede ser producido (vase la Parte IV , 36.2.15 Implementacin
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 gestin de
la capacidad de Arquitectura.
El detalle de la hoja de ruta de la Arquitectura y la aplicacin y el Plan de Migracin debe

expresarse en un nivel de detalle similar a la definicin de documento Arquitectura desarrollada en
las fases B, C y D. Cuando se requiera el detalle adicional significativo para la prxima fase de la
arquitectura es probable la transicin a un nivel diferente.Dependiendo del nivel de la arquitectura
seleccionada y ejecucin y el Plan de Migracin puede ser necesario para repetir otro ciclo de ADM
en un nivel ms bajo de detalle.Ver Parte III , 19. Aplicando la iteracin de la
ADM y 20. Aplicando la ADM a travs de la Arquitectura del Paisaje de tcnicas para manejar la
iteracin y los diferentes niveles de detalle.
14.5 Salidas
Los resultados de la Fase F pueden incluir, pero no se limitan a:
Implementacin y Plan de Migracin, Versin 1.0 (vase la Parte IV , 36.2.14

Implementacin y Plan de Migracin ), incluyendo:
o Implementacin y Estrategia de migracin
o Proyectos y Distribucin de la cartera de la aplicacin:
Asignacin de los paquetes de trabajo para proyectar y de cartera
Capacidades entregados por proyectos
Relacin a la Arquitectura de destino y cualquier Arquitecturas de

transicin
Pgina155de670
TOGOF9.1
Hitos y calendario
Estructura de desglose del trabajo
o Cartas del proyecto (opcional):
Paquetes de trabajo relacionados
El valor del negocio
Riesgo, problemas, hiptesis, dependencias
Las necesidades de recursos y los costes
Beneficios de la migracin
Estimacin de los gastos de las opciones de migracin
Finalizada Arquitectura definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de

definicin de documento ), incluyendo:
o Arquitecturas transicin finalizados, en su caso
Arquitectura Requisitos Finalizada la especificacin (vase la Parte IV , 36.2.6

Arquitectura especificacin de requisitos )
Finalizado Arquitectura Roadmap (vase la Parte IV , 36.2.7 Arquitectura Roadmap )
Reutilizables Arquitectura Bloques de construccin (vase 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 iteracin del ciclo de ADM (si los hay)
Implementacin Modelo de Gobierno (si las hubiera) (vase la Parte IV , 36.2.15

Implementacin Modelo de Gobierno )
Solicitudes de cambio para la capacidad de la arquitectura que surge de las lecciones

aprendidas
Pgina156de670
TOGOF9.1
. 15 Fase G: Gobernanza Aplicacin

Este captulo proporciona una supervisin de arquitectura de la aplicacin.

Figura151:FaseG:GobernanzaAplicacin
15.1 Objetivos
Los objetivos de la Fase G son para:
Asegurar la conformidad con la arquitectura destino por los proyectos de implementacin
Realizar funciones de arquitectura de gobernanza adecuadas para la solucin y cualquier

arquitectura de solicitudes de cambio de aplicacin impulsada
15.2 Enfoque
Es aqu que toda la informacin para la gestin exitosa de los diversos proyectos de
implementacin se uni. Tenga en cuenta que, en paralelo con la fase G, est la realizacin de un
proceso de desarrollo organizacional especfica, donde ocurre el desarrollo real.
Pgina157de670
TOGOF9.1
Para habilitar la rpida obtencin de valor para el negocio y los beneficios, y para minimizar el
riesgo en el programa de transformacin y la migracin, el enfoque preferido es el despliegue de la
arquitectura destino como una serie de transiciones. Cada transicin representa un paso ms 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 aplicacin que permita la entrega de las arquitecturas de

transicin acordado para la implementacin durante la fase de planeamiento de migracin
Adoptar un programa de implementacin por fases que refleja las prioridades de la

empresa contenidos en la Hoja de Ruta de la Arquitectura
Siga estndar de la organizacin para las empresas, informtica, arquitectura y gobierno
Utilice establecido enfoque de gestin de cartera / programa de la organizacin, siempre

que exista
Definir un marco de operaciones para garantizar una larga vida til de la solucin
implementada
Fase G establece la conexin entre la arquitectura y la organizacin de la ejecucin, a travs del

Contrato de Arquitectura.
Detalles del proyecto se desarrollan, entre ellas:
Nombre, descripcin y objetivos
mbito de aplicacin, prestaciones y limitaciones
Medidas de efectividad
Los criterios de aceptacin
Riesgos y problemas
Gobernabilidad ejecucin 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 slo

por los proyectos de implementacin, sino tambin 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 seccin define las entradas para la fase G.

Pgina158de670
TOGOF9.1

de Trabajo )




incluyendo:
Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin

de documento )
Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura

especificacin de requisitos ), incluyendo:
Pgina159de670
TOGOF9.1
o Los resultados del anlisis de Gap (de negocios, datos, aplicaciones y

arquitecturas tecnolgicas)
Arquitectura Roadmap (vase la Parte IV , 36.2.7 Arquitectura Roadmap )
Gobierno Modelo de Implementacin (vase la Parte IV , 36.2.15 Implementacin Modelo

de Gobierno )
Arquitectura Contrato (estndar) (vase la Parte VII , 49. Contratos de Arquitectura )

Trabajo ) identificados durante las fases E y F
Implementacin y Plan de Migracin (vase la Parte IV , 36.2.14 Implementacin y Plan

de Migracin )
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 (vase ms adelante), as como el momento en que se inician
Los pasos en la Fase G son como sigue:
15.4.1 Confirmar alcance y las prioridades para la implementacin con la Gestin del
Desarrollo
15.4.2 Identificar recursos de implementacin y Habilidades
15.4.3 Gua de desarrollo de la implementacin de soluciones
15.4.4 Realizar revisiones Arquitectura Empresarial de Cumplimiento
15.4.5 Implementacin de Negocios y Operaciones de TI
15.4.6 Realizar Revisin Post-Implementacin y Cierre la Implementacin
15.4.1 Confirmar alcance y las prioridades para la implementacin con la Gestin del
Desarrollo
Revise los resultados de planificacin de migracin y producir recomendaciones sobre la
implementacin
Identificar las prioridades de arquitectura empresarial para los equipos de desarrollo
Identificar los problemas de implementacin y hacer recomendaciones
Identificar los bloques de construccin para la sustitucin, actualizacin, etc
Realizar anlisis de las deficiencias en la arquitectura institucional y de soluciones
Pgina160de670
TOGOF9.1
Las lagunas en el marco de soluciones empresariales existentes necesitan ser

identificadas y las soluciones de Bloques de Construccin especficos (SBB) necesarios
para llenar estos vacos sern identificados por los arquitectos de soluciones. Estos
dispositivos SBB pueden tener un uno-a-uno o muchos-a-uno la relacin con los
proyectos. Los arquitectos de soluciones tienen que definir exactamente cmo 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 anlisis de brecha
15.4.2 Identificar recursos de implementacin y Habilidades
Los recursos del proyecto se incluyen los recursos de desarrollo que tendrn que ser educados en
los entregables de arquitectura empresarial en general y expectativas de los proyectos de
desarrollo y de implementacin especficos.
Las siguientes consideraciones deben ser abordados en este paso:
Identificar los mtodos de desarrollo de sistemas necesarios para el desarrollo de

soluciones
Nota:
Hay una serie de mtodos y herramientas disponibles para los equipos de proyectos de
desarrollo de sistemas. El mtodo ideal debera ser capaz de interoperar con las salidas de
la arquitectura; por ejemplo, generar cdigo desde artefactos arquitectura entregadas hasta
la fecha. Esto se podra 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.
Asegrese de que el mtodo de desarrollo de sistemas permite retroalimentacin

al equipo de arquitectura en diseos
15.4.3 Gua de desarrollo de la implementacin de soluciones

Formular recomendacin proyecto
Para cada proyecto de implementacin y despliegue independiente, haga lo siguiente:
o Alcance del documento de proyecto individual en el anlisis del impacto
o Documentar las necesidades estratgicas (desde el punto de vista arquitectnico)

en el anlisis de impacto
o Las solicitudes de cambio de documento (como el soporte para una interfaz

estndar) en el anlisis de impacto
o Reglas del documento para la conformidad en el anlisis del impacto
o Requisitos de la lnea de tiempo del documento de hoja de ruta en materia de

anlisis de impacto
Pgina161de670
TOGOF9.1
Arquitectura de documento de contrato
o Obtenga la firma de desarrollo de las organizaciones y el patrocinio de toda la

organizacin
Directorio Enterprise Update Continuum y el repositorio de soluciones
Gua de desarrollo de negocio y de TI modelos operativos para los servicios
Proporcionar los requisitos de servicio derivadas de la arquitectura empresarial
Definicin Gua de negocios y de TI requisitos operativos
Llevar a cabo anlisis de brechas entre la arquitectura de soluciones y operaciones
Producir Plan de Implementacin
15.4.4 Realizar revisiones Arquitectura Empresarial de Cumplimiento

Revise la gobernanza aplicacin en curso y la arquitectura de cumplimiento para cada
bloque de construccin
Una vez puestos en desarrollo
Cerrar desarrollo parte de los proyectos de implementacin
15.4.5 Implementacin de Negocios y Operaciones de TI

Llevar a cabo los proyectos de implementacin, incluyendo: servicios de TI la
implementacin del parto; aplicacin la prestacin de servicios empresariales; el desarrollo
de competencias y la implementacin de capacitacin; publicacin de documentacin
comunicaciones
Publicar nuevas arquitecturas de referencia para la arquitectura de repositorio y actualizar

otros repositorios afectadas, tales como tiendas de gestin de la configuracin operativa
15.4.6 Realizar Revisin Post-Implementacin y Cierre la Implementacin

Una vez puestos en ejecucin
Publicar comentarios y proyectos cercanos
Cierre de Fase G ser cuando las soluciones estn totalmente desplegados una vez.
15.5 Salidas
Las salidas de Fase G pueden incluir, pero no se limitan a:
Arquitectura contrato (firmado) (vase 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 , Evaluacin del Cumplimiento

36.2.13 )
Solicitudes de cambio (vase la Parte IV , 36.2.11 Solicitud de cambio )
Pgina162de670
TOGOF9.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
participacin directa del personal de la arquitectura en la aplicacin variar de acuerdo con
la poltica de la organizacin, como se describe en la Parte VII, 50. Arquitectura de
Gobierno .
o Poblado Repositorio Arquitectura
o Recomendaciones Arquitectura de cumplimiento y dispensas
o Recomendaciones sobre los requisitos de prestacin de servicios
o Recomendaciones sobre las medidas de rendimiento
o Acuerdos de Nivel de Servicio (SLAs)
o Architecture Vision, posterior a la ejecucin de actualizacin
o Arquitectura Definicin de documento, posterior a la ejecucin de

actualizacin
o Modelos operativos de TI y de negocios de la solucin implementada
Pgina163de670
TOGOF9.1
16 Fase H:. Gestin Arquitectura Cambio

Este captulo se centra en el establecimiento de procedimientos para la gestin del cambio a la
nueva arquitectura.

Figura161:FaseH:GestinArquitecturaCambio
16.1 Objetivos
Los objetivos de la Fase H son:
Asegrese de que se mantiene la arquitectura del ciclo de vida
Asegrese de que se ejecute el Marco de Gobierno Arquitectura
Asegrese de que la capacidad de la empresa Arquitectura cumple los requisitos actuales
Pgina164de670
TOGOF9.1
16.2 Enfoque
El objetivo de un proceso de gestin del cambio arquitectura es garantizar que la arquitectura
alcanza su valor de negocio objetivo original. Esto incluye la gestin 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 tecnologa y los cambios en el entorno empresarial. Cuando
se identifican los cambios, la gestin del cambio determinar si ha de iniciar formalmente un nuevo
ciclo de la evolucin de la arquitectura.
Adems, el proceso de gestin de cambios de arquitectura tiene como objetivo establecer y apoyar
la arquitectura de la empresa implementa como una arquitectura dinmica; es decir, uno que tiene
la flexibilidad para evolucionar rpidamente en respuesta a cambios en el entorno de la tecnologa
y de negocios.
Monitoreo de crecimiento del negocio y la decadencia es un aspecto crtico de esta fase. El uso de
la arquitectura de la empresa es la parte ms importante del ciclo de desarrollo de la
arquitectura. Con demasiada frecuencia, el negocio se ha quedado con una arquitectura
empresarial que trabaja para la organizacin de ayer, pero no puede dar vuelta la capacidad
suficiente para satisfacer las necesidades de la empresa de hoy y del maana.
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 renovacin constante de la
arquitectura.
Medicin y recomendaciones para la planificacin 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 disminucin en el uso es necesario evaluar continuamente para
asegurar que se consigue el mximo valor empresarial.
Por ejemplo, algunos Solution Architectures no se prestan para ser escalable en un factor grande -
digamos 10 - o soluciones alternativas puede ser ms econmico 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 gestin y la informacin de rendimiento se ha incorporado en los productos de trabajo a travs

de las fases anteriores, a continuacin, esta fase se trata de garantizar la efectividad de los
mismos. Si es necesario que haya supervisin o informes adicionales, entonces esta fase se
encargar de los cambios.
El proceso de gestin 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 despus de la implementacin, y el proceso por el cual que va a pasar
Pgina165de670
TOGOF9.1
Las circunstancias bajo las cuales se iniciar de nuevo el ciclo de desarrollo de

arquitectura para desarrollar una nueva arquitectura
La gestin del cambio arquitectura proceso est muy estrechamente relacionado con los procesos
de gobernanza de la arquitectura de la empresa, y para la gestin del Contrato de Arquitectura
(vase la Parte VII , 49. Contratos de Arquitectura ) entre la funcin 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 slo una actualizacin arquitectura o si amerita iniciar un nuevo ciclo
del Mtodo 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 exencin puede concederse con fundamento vlido. Si
el cambio tiene un alto impacto en la arquitectura, a continuacin, una estrategia para gestionar su
impacto debe ser definido.
Directrices para el establecimiento de estos criterios son difciles 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 pondrn de manifiesto para necesidades
especficas.
16.2.1 Drivers for Change
El objetivo principal para el desarrollo de la arquitectura de la empresa hasta ahora ha sido la

direccin estratgica y la arquitectura de arriba hacia abajo y la generacin de proyectos para
lograr las capacidades empresariales. Sin embargo, la arquitectura de la empresa no opera en el
vaco. Por lo general, una infraestructura y negocio existente que ya est proporcionando valor.
Hay tambin, probablemente, los impulsores del cambio que a menudo son de abajo hacia arriba,
en base a la modificacin de la infraestructura existente para mejorar la funcionalidad. Arquitectura
empresarial cambia este paradigma de un enfoque estratgico de arriba hacia abajo en un grado,
aunque la entrega de los incrementos hace que la ecuacin ms compleja.
Hay tres formas de cambiar la infraestructura existente que tiene que estar integrados:
De arriba hacia abajo Cambio estratgico, dirigido a mejorar o crear nuevas capacidades
(capital)
Cambios de abajo hacia arriba para corregir o mejorar la capacidad (operacin y

mantenimiento) para la infraestructura bajo la gestin de operaciones
Experiencias con los incrementos de los proyectos entregados previamente en el cuidado

de la gestin de operaciones, pero an siendo entregada por los proyectos en curso
Gobierno tendr que manejar la coordinacin de estas solicitudes para el cambio, adems 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 diseado y planificado.
Pgina166de670
TOGOF9.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 (estratgico, definicin de arquitectura empresarial,
la transicin, o proyecto). A menudo, una leccin relacionada con la arquitectura de la empresa
puede ser un resultado indirecto de una leccin aprendida en la organizacin en otro lugar.
La Junta de Arquitectura (vase la Parte VII , 47. Architecture Board ) evala y aprueba las
solicitudes para el Cambio (RFC). Un RFC es tpicamente en respuesta a problemas conocidos,
pero tambin puede incluir mejoras. Un reto para el Consejo de Arquitectura de la manipulacin de
un RFC es para determinar si se debe aprobar o si un proyecto en una Arquitectura Transicin
resolver el problema.
Cuando la evaluacin de proyecto o solucin de ajuste en la arquitectura, tambin puede ser el

caso cuando una solucin innovadora o RFC impulsa un cambio en la arquitectura.
Adems, hay muchos conductores relacionados con la tecnologa para la arquitectura solicitudes
de cambio. Por ejemplo:
Informes Nueva tecnologa
La reduccin de costes de gestin de activos
Retirada Tecnologa
Las iniciativas de estandarizacin
Este tipo de solicitud de cambio es normalmente manejable principalmente a travs de la gestin

de cambios de una empresa y los procesos de gobernanza de la arquitectura.
Adems, hay factores de negocio para el cambio de arquitectura, incluyendo:
Business-as-usual desarrollos
Excepciones empresariales
Innovaciones empresariales
Innovaciones tecnolgicas de negocios
El cambio estratgico
Este tipo de solicitud de cambio a menudo resulta en una re-desarrollo completo de la arquitectura,
o al menos en una iteracin de una parte del ciclo de desarrollo de la arquitectura, como se explica
a continuacin.
16.2.2 Arquitectura Empresarial Proceso de Gestin del Cambio
El proceso de gestin de cambios de arquitectura empresarial necesita determinar cmo los

cambios han de ser administrado, qu tcnicas se deben aplicar, y qu metodologas utilizadas. El
proceso tambin tiene una funcin de filtro que determina qu fases del proceso de desarrollo de la
Pgina167de670
TOGOF9.1
arquitectura se ven afectados por los requisitos. Por ejemplo, los cambios que afectan slo a la
migracin pueden ser de inters en las fases de desarrollo de la arquitectura.
Hay muchos enfoques vlidos para el cambio de gestin, y de diversas tcnicas y metodologas
que se pueden utilizar para gestionar el cambio de gestin; por ejemplo, los mtodos de gestin de
proyectos como PRINCE2, mtodos de gestin de servicios, tales como ITIL, los mtodos de
consultora de gestin, como catalizador, y muchos otros. Una empresa que ya cuenta con una
gestin de cambio proceso en su lugar en un campo distinto de la arquitectura (por ejemplo, en el
desarrollo de sistemas o la gestin de proyectos) puede muy bien ser capaz de adaptarlo para su
uso en relacin con la arquitectura.
A continuacin se describe un enfoque para la gestin del cambio, dirigido especialmente a la

ayuda de una arquitectura empresarial dinmico, que puede ser considerado para su uso si hay un
proceso similar existe en la actualidad.
El enfoque se basa en la clasificacin de cambios en la arquitectura requeridos en una de tres

categoras:
Simplificacin del cambio : Un cambio simplificacin normalmente se puede manejar a

travs de tcnicas de gestin del cambio.
Cambio incremental : Un cambio incremental puede ser susceptible de ser manejado a

travs de tcnicas de gestin del cambio, o puede requerir una reestructuracin de parcial,
dependiendo de la naturaleza del cambio (ver 16.2.3 Directrices para Mantenimiento frente
Arquitectura Rediseo de directrices).
Re-arquitectura de cambio : Un cambio re-arquitectura de requiere poner toda la

arquitectura a travs del ciclo de desarrollo de la arquitectura de nuevo.
Otra forma de ver estas tres opciones es decir que un cambio de la simplificacin de la arquitectura
es a menudo impulsada por una necesidad de reducir la inversin; un cambio incremental es
impulsado por un requisito para obtener un valor adicional de la inversin existente; y un cambio
re-arquitectura de es impulsado por una necesidad de aumentar la inversin con el fin de crear un
nuevo valor para la explotacin.
Para determinar si un cambio es la simplificacin, incremental o una reestructuracin de, se

realizarn las siguientes actividades:
1. Registro de todos los eventos que puedan afectar a la arquitectura
2. La asignacin de recursos y la gestin de las tareas de arquitectura
3. El proceso o funcin responsable de recursos de arquitectura tiene que hacer balance de

lo que se debe hacer
4. Evaluacin de los impactos
16.2.3 Directrices para Mantenimiento frente Arquitectura Rediseo
Una buena regla emprica es:
Pgina168de670
TOGOF9.1
Si los efectos del cambio de dos o ms grupos de inters, entonces es probable que
requiera un rediseo arquitectura y el reingreso a la ADM.
Si los impactos del cambio slo una de las partes interesadas, entonces es ms probable
que sea un candidato para la gestin del cambio.
Si el cambio se puede permitir bajo una dispensacin, entonces es ms probable que sea
un candidato para la gestin 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
reestructuracin de.
Si una nueva tecnologa o normas surgen, entonces puede haber una necesidad de
actualizar la arquitectura de Tecnologa, 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 fsica, sino que va a cambiar la descripcin de lnea de base de la arquitectura
de la tecnologa. Esto sera un cambio simplificacin manejado a travs de tcnicas de
gestin del cambio.
En particular, un ciclo de refresco (re-Architecting parcial o completa) puede ser necesario si:
La Fundacin 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 continuacin, una nueva solicitud de Arquitectura
de trabajo deber expedirla (para pasar a otro ciclo).
16.3 Entradas
Esta seccin define las entradas para la Fase H.


de Trabajo )
Pgina169de670
TOGOF9.1




incluyendo:
Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin

de documento )
Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura

especificacin de requisitos ), incluyendo:
o Los resultados del anlisis de Gap (de negocios, datos, aplicaciones y

arquitecturas tecnolgicas)
Arquitectura Roadmap (vase la Parte IV , 36.2.7 Arquitectura Roadmap )
Solicitud de cambio (vase la Parte IV , 36.2.11 Solicitud de cambio ), - los cambios

tecnolgicos:
Pgina170de670
TOGOF9.1
o Informes Nueva tecnologa
o Iniciativas de reduccin de costes de gestin de activos
o Informes de abstinencia Tecnologa
o Las iniciativas de estandarizacin
Solicitud de cambio (vase la Parte IV , 36.2.11 Solicitud de cambio ), - los cambios del
negocio:
o Evolucin de los negocios
o Excepciones empresariales
o Innovaciones empresariales
o Innovaciones tecnolgicas de negocios
o Desarrollos del cambio estratgico
Solicitud de cambio (vase la Parte IV , 36.2.11 Solicitud de cambio ), - a partir de las

lecciones aprendidas
Gobierno Modelo de Implementacin (vase la Parte IV , 36.2.15 Implementacin Modelo

de Gobierno )
Arquitectura contrato (firmado) (vase la Parte VII , 49. Contratos de Arquitectura )
Las evaluaciones de cumplimiento (ver la Parte IV , Evaluacin del Cumplimiento

36.2.13 )
Implementacin y Plan de Migracin (vase la Parte IV , 36.2.14 Implementacin y Plan

de Migracin )
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 (vase ms adelante), as como el momento en que se inician
Los pasos en la Fase H son los siguientes:
16.4.1 Establecer proceso de realizacin del valor
16.4.2 Para desplegar Herramientas de Monitoreo
16.4.3 Administrar Riesgos
16.4.4 Proporcionar Anlisis de Arquitectura de Gestin del Cambio
Pgina171de670
TOGOF9.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 realizacin del valor
Influencia proyectos empresariales de explotacin de la arquitectura de la empresa para la

realizacin 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 tecnolgicos que podran afectar la arquitectura de lnea de base
Vigilar los cambios del negocio que podran afectar la arquitectura de lnea de base
Seguimiento de valor de negocios; por ejemplo, el mtodo de evaluacin de la inversin

para determinar las mtricas de valor para los objetivos de negocio
Monitorear la empresa Arquitectura Capability Maturity
Seguimiento y evaluacin de los programas de gestin 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 Anlisis de Arquitectura de Gestin del Cambio
Proporcionar un anlisis de la gestin de cambios de arquitectura:
Analizar el rendimiento
Llevar a cabo revisiones de desempeo de la empresa con la arquitectura de gestin de

servicios
Evaluar las solicitudes de cambio y presentacin de informes para garantizar que se

cumplan la realizacin valor esperado y el Acuerdo de Nivel de Servicio (SLA) expectativas
de los clientes
Llevar a cabo un anlisis de las deficiencias de la actuacin de la arquitectura de la

empresa
Pgina172de670
TOGOF9.1
Asegrese de solicitudes de administracin 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 reunin de la Junta de Arquitectura con el objetivo de la reunin para decidir
sobre los cambios de manejo (la tecnologa 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 inversin
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 (vase la Parte IV , 36.2.17 Solicitud de

Arquitectura Trabajo ), para pasar a otro ciclo (para cambios importantes)

Arquitectura contrato (vase la Parte IV , 49. Contratos de Arquitectura ), actualizado en

caso necesario
Evaluaciones de cumplimiento (vase la Parte IV , Evaluacin del Cumplimiento 36.2.13 ),

actualizado en caso necesario
Pgina173de670
TOGOF9.1
17. Arquitectura ADM Gestin de Requisitos

Este captulo se centra en el proceso de gestin de requisitos de arquitectura en todo el ADM.

GestindeADMArquitecturaRequisitos:Figura171
17.1 Objetivos
Los objetivos de la fase de gestin de requisitos son los siguientes:
Asegrese de que el proceso de gestin de requisitos es sostenido y funciona para todas

las fases pertinentes de ADM
Gestione requisitos de arquitectura identificadas durante cualquier ejecucin del ciclo ADM
o una fase
Asegrese de que los requisitos de arquitectura relevantes estn disponibles para uso de
cada fase que se ejecuta la fase
17.2 Enfoque
Pgina174de670
TOGOF9.1
17.2.1 general
Como se indica por el crculo "Gestin de Requisitos" en el centro de la grfica ADM, el ADM es
impulsado continuamente por el proceso de gestin de requisitos.
Es importante sealar que el crculo de Gestin de Requisitos denota no un conjunto esttico de

requisitos, sino un proceso dinmico 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 Tambin 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 diseado como una
solucin. Requisitos de arquitectura son, por tanto, siempre sujeto a cambios en la prctica. Por
otra parte, la arquitectura a menudo se ocupa de los conductores y las limitaciones, muchas de las
cuales por su propia naturaleza estn ms 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 tambin que el proceso de gestin de requisitos en s no dispone de, direccin, o
priorizar los requisitos; esto se hace dentro de la fase correspondiente de la ADM. No es ms que
el proceso de gestin de requisitos en todo el ADM general.
Se recomienda que un repositorio de requisitos (vase la Parte IV , 41.6.1 Requisitos

Repositorio ) se utiliza para registrar y administrar todos los requisitos de arquitectura. A diferencia
de la Especificacin de Requerimientos Arquitectura, y los requisitos de evaluacin de impacto, los
requisitos de depsito puede contener la informacin de mltiples ciclos de ADM.
Desarrollo 17.2.2 Requisitos
Los primeros requisitos de alto nivel se articulan como parte de la arquitectura de la Visin,
generado mediante el escenario de negocios o una tcnica 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 Especificacin de
Requisitos. A la finalizacin de la fase de la situacin de estos requisitos tiene que ser
actualizado. Durante la ejecucin de fase nuevas necesidades generadas para el futuro trabajo de
arquitectura en el marco de la Declaracin de la corriente de Arquitectura de Trabajo han de estar
documentados dentro de la arquitectura de Especificacin de Requisitos, y las nuevas necesidades
que se encuentran fuera del mbito de aplicacin de la Declaracin de la corriente de Arquitectura
Trabajo deben introducirse a los requisitos de depsito para la gestin a travs del proceso de
gestin 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 definicin de los requisitos del arquitecto debera tener en cuenta:
Pgina175de670
TOGOF9.1
Supuestos para requisitos
Restricciones para los requisitos
Principios de dominio especfico que impulsan requisitos
Las polticas que afectan los requisitos
Normas que deben cumplir los requisitos
Directrices de la Organizacin para los requisitos
Las especificaciones para los requisitos
Entregas en fases posteriores de ADM tambin contienen asignaciones a los requisitos de diseo,
y tambin pueden generar nuevos tipos de requisitos (por ejemplo, los requisitos de
conformidad, tiempo ventanas para la implementacin).
17.2.3 Recursos
El mundo de la ingeniera de requisitos es rico con las recomendaciones emergentes y procesos

para la gestin de requisitos. TOGAF no exige ni recomienda ningn proceso o herramienta
especfica; que se limita a establecer lo que es un proceso de gestin de requisitos efectiva debe
lograr (es decir, los "requisitos de los requisitos", si se quiere).
17.2.3.1 Escenarios empresariales
Una tcnica efectiva que se describe en s mismo es TOGAF escenarios de negocio, que son una
tcnica apropiada y til para descubrir y documentar los requerimientos del negocio, y para
articular una visin 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 nmero de Commercial Off-The-Shelf (COTS) herramientas disponibles

para el apoyo de la gestin de requisitos, aunque no necesariamente diseado 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 gestin de requisitos son:
Un poblado Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura del

repositorio ),

Pgina176de670
TOGOF9.1



Requisitos de arquitectura, que pueblan una especificacin de Arquitectura requisitos

(ver la Parte IV , 36.2.6 Arquitectura especificacin de requisitos )
Requisitos de Evaluacin de Impacto (vase la Parte IV , 36.2.18 Requisitos de

Evaluacin de Impacto )
17.4 Pasos
Los pasos en la fase de gestin de requisitos se describen en la siguiente tabla:
Pasos de Gestin de Requisitos ADM Fase Pasos

Paso Identificar los requisitos / documentos - utilizar
1 escenarios de negocios, o una tcnica anloga
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
Pgina177de670
TOGOF9.1

Requisitos Repositorio
Paso Monitorear los requisitos bsicos

3
Paso Identificar requisitos modificados:
4
a. Retire o re-evaluar las prioridades
b. Aadir 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. Asegrese de que los conflictos son

identificados y gestionados a travs de las
fases de una conclusin exitosa y
priorizacin
d. Generar Requisitos Declaracin de Impacto

(ver 36.2.18 Requisitos de Evaluacin de
Impacto ) para dirigir el equipo de
arquitectura
Notas
Requisitos modificados pueden entrar a

travs de cualquier va. Para asegurarse de
que los requisitos se evalan
adecuadamente y se priorizan, este
proceso necesita dirigir las fases de ADM y
registrar las decisiones relacionadas con
los requisitos.
La fase de gestin de requisitos es

necesario para determinar la satisfaccin
de las partes interesadas con las
decisiones. Donde hay insatisfaccin, la
fase sigue siendo responsable de
garantizar la resolucin de los problemas y
determinar los prximos pasos.
Paso a. Evaluar el impacto de las nuevas exigencias

6 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 despus; si la

Pgina178de670
TOGOF9.1

decisin es implementar, evaluar
Cronograma de implantacin de gestin del
cambio
d. Declaracin de Impacto Requisitos Edicin,

Versin n 1
Paso Implementar los requisitos derivados de la Fase H

7
La arquitectura se puede cambiar a travs de su ciclo
de vida por la fase de Arquitectura de Gestin del
Cambio (Fase H). El proceso de gestin 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 informacin
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 anlisis de las deficiencias en las
10 fases anteriores
El anlisis de las deficiencias en las fases de ADM B a

D identifica las brechas entre la lnea 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 lnea de base,

pero no en el de destino (es decir, eliminado
- por accidente o diseo)
Algo no est en la lnea 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 anlisis 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.
Pgina179de670
TOGOF9.1
17.5 Salidas
Los resultados del proceso de gestin de requisitos pueden incluir, pero no se limitan a:
Evaluacin de Impacto 36.2.18 Requisitos
36.2.6 Arquitectura Especificacin de Requisitos , si es necesario
El Repositorio de Requisitos se actualizar como parte de la fase de gestin de requisitos y debe

contener toda la informacin de los requisitos.
Cuando surgen nuevas necesidades, o las existentes se cambian, se genera una Declaracin de
Impacto Requisitos, que identifica las fases de la ADM de que es necesario revisar el hacer frente a
los cambios. La declaracin contina a travs de diversas iteraciones hasta que la versin final,
que incluye todas las implicaciones de los requisitos (por ejemplo, costos, plazos, y mtricas 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 especificacin de requisitos debe ser actualizada.
Pgina180de670

Togaf 9 1 Parte Ii

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Togaf 9 1 Parte Ii

Uploaded by

Copyright:

Available Formats

The Open Group Architecture Framework

5.1 Descripcin general de ADM

5.1.1 El ADM, Enterprise Continuum, y Arquitectura Repositorio

La aplicacin prctica de la Empresa Continuum normalmente tomar la forma de un depsito de

Arquitectura desarrollo es un proceso continuo y cclico, y en la ejecucin de la ADM repetidamente

5.1.2 El ADM y la Architecture Foundation

5.1.3 ADM y lineamientos que apoyen y Tcnicas

5.2 Arquitectura del Ciclo de Desarrollo

5.2.1 Puntos clave

Los siguientes son los puntos clave de la ADM:

o La amplitud de la cobertura de la empresa a definir

o El nivel de detalle que se define

o La extensin del perodo de tiempo destinado a, incluyendo el nmero y extensin

o 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

Estas decisiones deberan basarse en una evaluacin prctica de los recursos y la

Estas cuestiones se examinan en detalle en 5.3 Adaptacin de la ADM .

5.2.2 Estructura bsica

La estructura bsica de la ADM se muestra en la Figura 5-1 .

Seleccione los modelos de referencia, puntos de vista, y herramientas

Desarrollar Arquitectura de referencia Descripcin

Desarrollar Arquitectura Target Descripcin

Realizar anlisis de las deficiencias

Definir los componentes de la hoja de ruta candidatos

Llevar a cabo una revisin formal de las partes interesadas

Crear Arquitectura Definicin de documento

Fase Entregable Contenido Versin Descripcin

5.3 Adaptacin de la ADM

Otras posibles razones para querer adaptar el ADM incluyen:

El ADM es uno de los muchos procesos empresariales que conforman el modelo de

La empresa es una empresa pequea y mediana, y desea utilizar un mtodo "cut-down"

La empresa es muy grande y complejo, que comprende muchas "empresas"

o La planificacin de arriba hacia abajo y el desarrollo - el diseo del conjunto de

o Desarrollo de una arquitectura o "genrico" de "referencia", tpico de las empresas

o Replicacin - el desarrollo de una arquitectura especfica para una empresa,

En un entorno de varios proveedores o de produccin, una arquitectura genrica para una

5.4 Arquitectura de Gobierno

Datos de referencia (garanta de los propios repositorios de la organizacin / empresa

Estado de proceso : Toda la informacin sobre el estado de todos los procesos de

o Las decisiones clave y el personal responsable para cualquier proyecto de

o Una referencia para la futura evolucin del proceso arquitectnico y el apoyo,

5.5 La determinacin del alcance de la Arquitectura

La autoridad para la organizacin del equipo de produccin de la arquitectura

La disponibilidad de las personas, las finanzas y otros recursos

La divisin de la empresa y su actividad relacionada con la arquitectura-se analiza con ms detalle

Amplitud : Cul es la magnitud de la empresa, y qu parte de esa medida ser esta

o La empresa moderna se extiende cada vez ms all de sus lmites tradicionales,

Profundidad : En qu nivel de detalle debe ir el esfuerzo architecting? Cunto

Arquitectura Dominios : Una descripcin completa de arquitectura empresarial debe

Una de las decisiones ms importantes es el foco de los esfuerzos de la arquitectura, en cuanto a

Para las grandes empresas complejas arquitecturas federados - desarrollados de forma

El uso de material de la arquitectura puede ser monitoreada, y el cumplimiento de las

o Un proceso de evaluacin de la conformidad que describe lo que el usuario est

o Un proceso de dispensacin que pueden conceder dispensas de adhesin a las

Publicacin y suscripcin tcnicas se estn desarrollando como parte de generales de gobierno de

5.5.3 Perodo de tiempo

El ADM se describe en trminos de un nico ciclo de Architecture Vision, y un conjunto de

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

2. A continuacin, desarrollar una o ms descripciones de "Arquitectura de Transicin", como

La empresa evoluciona mediante la migracin a cada una de estas arquitecturas de transicin a su

Esta ruptura de la descripcin de la arquitectura en una familia de productos de arquitectura

5.5.4 Arquitectura Dominios