Togaf 91ES

The Open Group Architecture Framework
TOGOF9.1
FASE I Introduccin
Pgina1de670

TOGOF9.1
1. Introduccin
TOGAF es un marco - un mtodo detallado y un conjunto de herramientas de apoyo - para el desarrollo de una empresa de arquitectura. Puede ser utilizado libremente por cualquier organizacin que desee desarrollar una empresa de arquitectura para su uso dentro de esa organizacin TOGAF es desarrollado y mantenido por miembros de The Open Group, trabajando dentro del Foro de Arquitectura. El desarrollo original de TOGAF Versin 1 en 1995 se bas en el Marco de Arquitectura Tcnica para la Gestin de la Informacin (TAFIM), desarrollado por el Departamento de Defensa de EE.UU. ( DoD ). El Departamento de Defensa dio el permiso explcito Open Group y el estmulo para crear TOGAF apoyndose en la TAFIM, que a su vez fue el resultado de muchos aos de esfuerzo de desarrollo y muchos millones de dlares de inversin Gobierno de los EE.UU.. A partir de esta slida base, los miembros de El Foro Open Group Architecture han desarrollado versiones sucesivas de TOGAF y publicado cada uno en el sitio web pblico Open Group. Si usted es nuevo en el campo de la arquitectura de la empresa y / o TOGAF, se recomienda leer el Resumen Ejecutivo (consulte 1.2 Resumen Ejecutivo ), donde encontrar respuestas a preguntas tales como: Qu es una empresa? Por qu necesito una empresa de arquitectura? Por qu necesito TOGAF como marco para la arquitectura de la empresa?
1.1 Estructura del documento TOGAF

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

TOGOF9.1
Figura 1-1: Estructura del documento TOGAF

Hay siete partes en el documento de TOGAF: PARTE I (Introduccin) Esta parte proporciona una introduccin de alto nivel a los conceptos clave de la arquitectura de la empresa y, en particular, el enfoque TOGAF.Contiene las definiciones de los trminos utilizados en TOGAF y notas de la versin que detallan los cambios entre esta versin y la versin anterior de TOGAF. PARTE II (Arquitectura Mtodo de Desarrollo) Esta parte es el ncleo de TOGAF. En l se describe la Arquitectura Mtodo de Desarrollo de TOGAF (ADM) - un enfoque paso a paso para el desarrollo de una empresa de arquitectura. PARTE III (Directrices de ADM y Tcnicas) Esta parte contiene una coleccin de guas y tcnicas disponibles para su uso en la aplicacin de TOGAF y el TOGAF ADM. PARTE IV (Marco de Arquitectura de contenido) Esta parte describe el marco de contenido TOGAF, incluyendo un metamodelo estructurado para artefactos arquitectnicos, el uso de bloques de la arquitectura de construccin reutilizables, y una visin general de los entregables arquitectura tpica.
Pgina3de670

TOGOF9.1
PARTE V (Enterprise Continuum y Herramientas) Esta parte trata sobre las taxonomas y las herramientas apropiadas para clasificar y almacenar los resultados de la actividad de la arquitectura dentro de una empresa. PARTE VI (Modelos de referencia de TOGAF) Esta parte ofrece una seleccin de los modelos de referencia de arquitectura, que incluye la Fundacin Arquitectura TOGAF y el Integrado de Informacin de Referencia Infraestructura Modelo (III-RM). PARTE VII (Capability Framework Architecture) Esta parte se analiza la organizacin, procesos, habilidades, roles y responsabilidades necesarias para establecer y operar una funcin de la arquitectura dentro de una empresa. La intencin de dividir la especificacin TOGAF en estas partes independientes es permitir que diferentes reas de especializacin que se considerarn en detalle y potencialmente abordados de manera aislada. Aunque todas las partes funcionan juntos como un todo, tambin es factible seleccionar determinadas partes para su aprobacin y se excluyan otros. Por ejemplo, una organizacin podra adoptar el proceso de ADM, sino optar por no utilizar cualquiera de los materiales relacionados con la Arquitectura de Capacidad. Como un marco abierto, se recomienda este uso, en especial en las siguientes situaciones: Se espera que las organizaciones que son nuevas para TOGAF y desean adoptar progresivamente conceptos TOGAF para centrarse en determinadas partes de la especificacin para su aprobacin inicial, con otras reas presentadas para su consideracin posterior. Las organizaciones que ya han implementado marcos de arquitectura pueden optar por combinar estos marcos con los aspectos de la especificacin TOGAF.
1.2 Resumen Ejecutivo

En esta seccin se ofrece un panorama general ejecutivo de la arquitectura empresarial, los conceptos bsicos de lo que es (no slo otro nombre para la Arquitectura de TI), y por qu es necesario. Proporciona un resumen de los beneficios del establecimiento de una empresa y la adopcin de la arquitectura TOGAF para lograrlo.
Qu es una empresa?
TOGAF define la "empresa" tal como cualquier conjunto de organizaciones que tiene un conjunto de objetivos comunes. Por ejemplo, una empresa podra ser una agencia del gobierno, toda una corporacin, una divisin de una corporacin, un solo departamento, o una cadena de organizaciones geogrficamente distantes unidos entre s por la propiedad comn. El trmino "empresa" en el contexto de la "arquitectura de la empresa" puede ser utilizado para designar tanto toda la empresa - que abarca la totalidad de sus servicios de informacin y tecnologa, los procesos y la infraestructura - y un dominio especfico dentro de la empresa. En ambos casos, la arquitectura cruza mltiples sistemas, y mltiples grupos funcionales dentro de la empresa. La confusin surge a menudo de la naturaleza evolutiva del trmino "empresa". Una empresa extendida incluye hoy en da con frecuencia socios, proveedores y clientes. Si el objetivo es la integracin de una empresa extendida, entonces la empresa cuenta con los socios, proveedores y clientes, as como las unidades de negocio internas.
Pgina4de670

TOGOF9.1
El concepto de modelo de funcionamiento empresarial es til para determinar la naturaleza y alcance de la arquitectura de la empresa dentro de una organizacin. Las grandes corporaciones y agencias gubernamentales pueden comprender varias empresas, y pueden desarrollar y mantener una serie de arquitecturas empresariales independientes para abordar cada uno. Sin embargo, a menudo hay mucho en comn acerca de los sistemas de informacin en cada empresa, y por lo general hay un gran potencial para el aumento en el uso de un marco de arquitectura comn. Por ejemplo, un marco comn puede proporcionar la base para el desarrollo de un repositorio de Arquitectura para la integracin y la reutilizacin de modelos, diseos y datos de referencia.
Por qu necesito una empresa de arquitectura?
El propsito de la arquitectura de la empresa es la optimizacin de toda la empresa el legado menudo fragmentado de los procesos (tanto manuales como automatizadas) en un entorno integrado que es sensible a los cambios y de apoyo de la aplicacin de la estrategia de negocios. CEOs de hoy saben que la gestin y explotacin de la informacin eficaz a travs de TI es un factor clave para el xito del negocio, y un medio indispensable para el logro de ventajas competitivas. Una empresa direcciones arquitectura esta necesidad, proporcionando un marco estratgico para la evolucin del sistema de TI en respuesta a las necesidades en constante cambio del entorno empresarial. Por otra parte, una buena arquitectura de la empresa le permite lograr el equilibrio adecuado entre la eficiencia de TI y la innovacin empresarial. Permite a las unidades de negocios individuales para innovar de forma segura en su bsqueda de la ventaja competitiva. Al mismo tiempo, se asegura que las necesidades de la organizacin de una estrategia de TI integrada se cumplen, lo que permite la sinergia ms cercano posible a travs de la empresa extendida. Las ventajas que se derivan de una buena arquitectura de la empresa aportar beneficios importantes de negocios, que son claramente visibles en la utilidad o prdida neta de una empresa u organizacin: Una operacin de negocio ms eficiente: o o o o o o Menores costos de operacin de negocios Organizacin ms gil Capacidades empresariales compartidos a travs de la organizacin Costos de gestin del cambio Inferior Fuerza de trabajo ms flexible Mejora de la productividad de las empresas
Una operacin de TI ms eficiente: o o o o Bajo desarrollo de software, soporte y mantenimiento de los costos El aumento de la portabilidad de las aplicaciones Interoperabilidad mejorada y ms fcil sistema y red de gestin Mejora de la capacidad para abordar cuestiones crticas a nivel de empresa como la seguridad
Pgina5de670

TOGOF9.1
o Ms fcil actualizacin y el intercambio de los componentes del sistema Mejor retorno de la inversin existente, menor riesgo para la inversin futura: o o Reduccin de la complejidad en el negocio y TI Mximo rendimiento de la inversin en la infraestructura de TI de negocios existentes y La flexibilidad de hacer, comprar o subcontratar las soluciones de negocio y de TI Reduccin del riesgo general en las nuevas inversiones y su coste de propiedad
o o
Ms rpido, ms sencillo y ms barato de adquisiciones: o Las decisiones de compra son ms simples, ya que la informacin que rige la contratacin est fcilmente disponible en un plan coherente El proceso de contratacin es ms rpido - maximizar la velocidad de adquisicin y flexibilidad sin sacrificar la coherencia arquitectnica La capacidad de suministro de los sistemas abiertos heterogneos de mltiples proveedores La capacidad de asegurar las capacidades ms econmicos
Especficamente, qu me incitara a desarrollar una empresa de arquitectura?
Por lo general, la preparacin para las necesidades de transformacin de negocios o de cambios en la infraestructura radicales inicia una revisin o desarrollo de arquitectura empresarial. A menudo las personas clave a identificar reas de cambio necesarios para que los nuevos objetivos de negocio que debe cumplir. Estas personas se conocen comnmente como las "partes interesadas" en el cambio. El papel del arquitecto es hacer frente a sus preocupaciones a travs de: La identificacin y el perfeccionamiento de los requisitos que los interesados tienen Desarrollo de vistas de la arquitectura que muestran cmo las preocupaciones y necesidades van a ser tratados Mostrando las compensaciones que se van a realizar en la conciliacin de los intereses potencialmente conflictivos de las distintas partes interesadas
Sin la arquitectura de la empresa, es muy poco probable que todas las inquietudes y requerimientos sern consideradas y se reunieron.
Qu es un marco de la arquitectura?
Un marco de arquitectura es una estructura fundamental, o conjunto de estructuras, que pueden ser utilizados para el desarrollo de una amplia gama de diferentes arquitecturas. Debe describir un mtodo para el diseo de un estado objetivo de la empresa en trminos de un conjunto de bloques de construccin, y para mostrar cmo los bloques de construccin encajan. Debe contener un conjunto de herramientas y proporcionar un vocabulario comn. Tambin debe incluir una lista de estndares recomendados y los productos compatibles que se pueden utilizar para implementar los bloques de construccin.
Pgina6de670

TOGOF9.1
Por qu necesito TOGAF como marco para la arquitectura de la empresa?
TOGAF se ha desarrollado gracias a la colaboracin de ms de 300 empresas miembros del Foro de Arquitectura de algunas de las principales empresas y organizaciones del mundo. Utilizando los resultados TOGAF en arquitectura empresarial que sea coherente, refleja las necesidades de las partes interesadas, emplea las mejores prcticas, y le da la debida atencin tanto a las necesidades actuales y las necesidades futuras percibidas de la empresa. Desarrollar y mantener una empresa de arquitectura es un proceso tcnicamente complejo que implica a muchos interesados y los procesos de decisin en la organizacin.TOGAF juega un papel importante en la normalizacin y de-riesgo el proceso de desarrollo de la arquitectura. TOGAF proporciona un marco de mejores prcticas para agregar valor, y permite a la organizacin para construir soluciones viables y econmicas que permitan atender a sus problemas de negocio y necesidades.
Quin se beneficiara del uso de TOGAF?
Toda empresa de organizacin o planificacin para llevar a cabo el desarrollo e implementacin de una empresa de arquitectura para el soporte de la transformacin del negocio se beneficiarn del uso de TOGAF. Las organizaciones que buscan sin fronteras Flujo de informacin pueden usar TOGAF para definir y poner en prctica las estructuras y procesos para permitir el acceso a la informacin integrada dentro de y entre las empresas. Las organizaciones que disean e implementan arquitecturas empresariales utilizando TOGAF tienen la garanta de un diseo y una especificacin de adquisiciones que pueden facilitar una puesta en prctica de sistemas abiertos, permitiendo as que los beneficios de los sistemas abiertos con un menor riesgo.
Pgina7de670

TOGOF9.1
2. Conceptos Bsicos
A los efectos de TOGAF 9, los conceptos bsicos proporcionados en este captulo se aplican.
2.1 Qu es TOGAF?
TOGAF es un marco de arquitectura. TOGAF proporciona los mtodos y herramientas para ayudar en la aceptacin, la produccin, el uso y el mantenimiento de una empresa de arquitectura. Se basa en un modelo de proceso iterativo con el apoyo de las mejores prcticas y un conjunto reutilizable de activos arquitectura existente.
2.2 Qu es la arquitectura en el contexto de TOGAF?

ISO / IEC 42010:2007 define "arquitectura" como: "La organizacin fundamental de un sistema, encarnada en sus componentes, sus relaciones entre s y con el medio ambiente, y los principios que rigen su diseo y evolucin." TOGAF abarca pero no se adhiere estrictamente a la norma ISO / IEC 42010:2007 terminologa. En TOGAF, "arquitectura" tiene dos significados, dependiendo del contexto:
1. Una descripcin formal de un sistema, o un plan detallado del sistema a nivel de componente para orientar su aplicacin 2. La estructura de los componentes, sus interrelaciones, y los principios y directrices que rigen su diseo y evolucin en el tiempo
TOGAF considera la empresa como un sistema y se esfuerza por lograr un equilibrio entre la promocin de los conceptos y la terminologa de la norma ISO / IEC 42010:2007 - garantizar que el uso de los trminos definidos por la norma ISO / IEC 42010:2007 es compatible con la norma - y retener otra frecuencia aceptado la terminologa que es familiar para la mayora de los lectores TOGAF. Para ms informacin sobre la terminologa, consulte 3. Definiciones y Parte IV , 35. Architectural Artifacts .
2.3 Qu tipo de arquitectura TOGAF El trato con?

Hay cuatro campos de arquitectura que son comnmente aceptadas como subconjuntos de un conjunto de arquitectura empresarial, todo lo cual TOGAF est diseado para soportar: La arquitectura de negocio define la estrategia empresarial, el gobierno, la organizacin y los procesos clave del negocio. La Arquitectura de Datos describe la estructura de los activos de datos lgicos y fsicos de una organizacin y los recursos de gestin de datos.
Pgina8de670

TOGOF9.1
La Arquitectura de la aplicacin proporciona un modelo para las aplicaciones individuales que se desplegarn, sus interacciones y su relacin con los procesos de negocio de la organizacin. La Tecnologa de la Arquitectura describe las capacidades de software y hardware lgicos que se requieren para apoyar el despliegue de servicios de negocio, datos y aplicaciones. Esto incluye la infraestructura de TI, middleware, redes, comunicaciones, procesamiento, normas, etc
2.4 Arquitectura Mtodo de Desarrollo

La Arquitectura Mtodo de Desarrollo de TOGAF (ADM) proporciona un probado y proceso repetible para el desarrollo de arquitecturas. La ADM incluye el establecimiento de un marco de arquitectura, desarrollo de contenidos arquitectura, la transicin, y que rige la realizacin de arquitecturas. Todas estas actividades se llevan a cabo dentro de un ciclo iterativo de definicin de la arquitectura y la realizacin continua que permite a las organizaciones a transformar sus empresas de una manera controlada en respuesta a los objetivos de negocio y oportunidades. Fases dentro de la ADM son los siguientes: La fase preliminar describe las actividades de preparacin e iniciacin necesarios para crear una capacidad de Arquitectura incluyendo personalizacin de TOGAF y definicin de Arquitectura Principios. Fase A: Arquitectura Visin describe la fase inicial de un ciclo de desarrollo de la arquitectura. Incluye informacin sobre cmo definir el alcance de la iniciativa de desarrollo de la arquitectura, la identificacin de las partes interesadas, la creacin de la arquitectura de la Visin, y obtener la aprobacin para proceder con el desarrollo de la arquitectura. Fase B: Arquitectura de Negocios describe el desarrollo de una arquitectura de negocios para apoyar el acuerdo Architecture Vision. Fase C: Sistemas de Informacin Arquitecturas describe el desarrollo de Sistemas de Informacin Arquitecturas para apoyar el acuerdo Architecture Vision. Fase D: Architecture Tecnologa describe el desarrollo de la arquitectura de la tecnologa para apoyar el acuerdo Architecture Vision. Fase E: Oportunidades y Soluciones lleva a cabo la planificacin de la implementacin inicial y la identificacin de los vehculos de reparto para la arquitectura se define en las fases anteriores. Fase C: planeamiento de migracin aborda cmo pasar de la lnea de base a las arquitecturas objetivo al finalizar una implementacin detallada y Plan de Migracin. Fase G: Gobernanza Aplicacin proporciona una supervisin de arquitectura de la aplicacin. Fase H: Arquitectura de Gestin del Cambio , establece los procedimientos para la gestin del cambio a la nueva arquitectura.
Pgina9de670

TOGOF9.1
Gestin de Requisitos examina el proceso de gestin de requisitos de arquitectura en todo el ADM.
2.5 Entregables, Artefactos y bloques de construccin

Arquitectos ejecutores del ADM producirn una serie de resultados, como resultado de sus esfuerzos, como los flujos de procesos, requisitos arquitectnicos, planes de proyectos, evaluaciones de cumplimiento de proyectos, etc El marco de contenido TOGAF Arquitectura (ver la Parte IV , 33. Introduccin ) proporciona una modelo estructural para el contenido de arquitectura que permite a los principales productos de trabajo para definir consistentemente, estructurados y presentados. La Arquitectura del marco de contenido usa las siguientes tres categoras para describir el tipo de producto de trabajo de arquitectura dentro del contexto de uso: Un entregable es un producto de trabajo que se especifica y, a su vez revisado formalmente, de acuerdo, y firmado por las partes interesadas contractualmente.Entregables representan la salida de los proyectos y los resultados que se tenga en forma de documentacin sern tpicamente archivadas en la finalizacin de un proyecto, o la transicin hacia un repositorio arquitectura como un modelo de referencia, estndar o instantnea de la arquitectura del paisaje en un punto en el tiempo. Un artefacto es un producto del trabajo arquitectnico que describe un aspecto de la arquitectura. Los artefactos se clasifican generalmente como catlogos (listas de cosas), matrices (que muestran las relaciones entre las cosas), y diagramas (imgenes de las cosas). Los ejemplos incluyen un catlogo de necesidades, matriz de interaccin de negocios, y un diagrama de casos de uso. Un entregable arquitectnica puede contener muchos objetos y artefactos formarn el contenido de la Arquitectura Repository. Un bloque de construccin representa un (potencialmente reutilizable), componente de negocio, TI, o la capacidad de la arquitectura que se puede combinar con otros bloques de construccin para ofrecer arquitecturas y soluciones. Bloques de construccin se pueden definir en varios niveles de detalle, dependiendo de la etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una etapa temprana, un bloque de construccin puede consistir simplemente en un nombre o una breve descripcin. Ms tarde, un bloque de construccin se puede descomponer en varios bloques de edificios de apoyo y puede ir acompaada de una especificacin completa. Bloques de construccin pueden relacionarse con "arquitecturas" o "soluciones". o Arquitectura Bloques de Construccin (Abs) suelen describir la capacidad requerida y dar forma a la especificacin de soluciones de Bloques de Construccin (SBB). Por ejemplo, una capacidad de servicio al cliente puede ser necesaria dentro de una empresa, con el apoyo de muchos SBB, como los procesos, datos y software de aplicacin. Solucin Building Blocks (SBB) representan los componentes que se utilizarn para implementar la capacidad requerida. Por ejemplo, una red es un bloque de construccin que se puede describir a travs de artefactos complementarios y luego objeto de un uso para darse cuenta de las soluciones para la empresa.
Pgina10de670

TOGOF9.1
Las relaciones entre los entregables, artefactos y bloques de construccin se muestran en la Figura 2-1 .
Figura21:Lasrelacionesentrelosentregables,Artefactosybloquesdeconstruccin
Por ejemplo, una definicin de documento La arquitectura es un entregable que documenta una descripcin de la arquitectura. Este documento contendr una serie de artefactos complementarios que son puntos de vista de los componentes bsicos de inters para la arquitectura. Por ejemplo, un diagrama de flujo del proceso (un artefacto) puede ser creado para describir el proceso de gestin de llamadas de destino (un bloque de construccin). Este artefacto puede tambin describir otros bloques de construccin, tales como los actores involucrados en el proceso (por ejemplo, un representante de servicios al cliente). Un ejemplo de las relaciones entre los entregables, artefactos y bloques de construccin se ilustra en la Figura 2-2 .
Figura22:EjemploArquitecturadedefinicindedocumento Pgina11de670

TOGOF9.1
Continuum 2.6 Empresa

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

Apoyo a la Empresa Continuum es el concepto de un Repositorio de Arquitectura que se puede utilizar para almacenar las diferentes clases de la produccin arquitectnica en diferentes niveles de abstraccin, creado por el ADM. De esta manera, TOGAF facilita la comprensin y la cooperacin entre las partes interesadas y los profesionales en los diferentes niveles. Por medio del Continuum Empresa y Arquitectura de repositorio, se anima a los arquitectos para aprovechar todos los recursos y bienes arquitectnicos relevantes en el desarrollo de una arquitectura de organizacin especfica. En este contexto, el TOGAF ADM puede ser considerada como la descripcin de un ciclo de vida proceso que opera en mltiples niveles dentro de la organizacin, que operan dentro de un marco global de gobernanza y la produccin de resultados alineados que residen en un repositorio de
Pgina12de670

TOGOF9.1
Arquitectura. The Enterprise Continuum proporciona un contexto til para la comprensin de los modelos arquitectnicos: muestra bloques de construccin y sus relaciones entre s, y las limitaciones y requisitos en el ciclo de desarrollo de la arquitectura. La estructura de la arquitectura TOGAF repositorio se muestra en la Figura 2-4 .
Figura24:TOGAFArquitecturaEstructuradelrepositorio
Los componentes principales dentro de un repositorio de Arquitectura son los siguientes: La Arquitectura Metamodel describe la aplicacin organizativo adaptado de un marco de arquitectura, incluyendo un metamodelo para el contenido de la arquitectura. La Capacidad de Arquitectura define los parmetros, estructuras y procesos que ayuden a la gobernabilidad de la arquitectura de repositorio. La arquitectura del paisaje es la representacin arquitectnica de activos desplegados dentro de la empresa de explotacin en un punto determinado en el tiempo.El paisaje es probable que exista en mltiples niveles de abstraccin para adaptarse a diferentes objetivos de la arquitectura.
Pgina13de670

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

Con el fin de llevar a cabo la actividad arquitectnica con eficacia dentro de una empresa, es necesario poner en marcha una capacidad de negocio apropiado para la arquitectura, a travs de las estructuras de organizacin, funciones, responsabilidades, habilidades y procesos. Una visin general de la capacidad TOGAF Arquitectura se muestra en la Figura 2-5 .
Figura25:IntroduccinalaarquitecturaTOGAFCapability
2.9 Establecimiento de la Capacidad de Arquitectura como una
Entidad Operacional
Salvo capacidades de arquitectura creados para apoyar exclusivamente los programas de prestacin de cambio, se reconoce cada vez ms que una prctica exitosa de la arquitectura empresarial debe sentarse sobre una base operativa firme. En efecto, una prctica de la
Pgina14de670

TOGOF9.1
arquitectura empresarial debe funcionar como cualquier otra unidad operativa dentro de un negocio; es decir, se debe tratar como un negocio. Con este fin, y por encima de los procesos bsicos definidos en el ADM, una prctica de la arquitectura empresarial debe establecer capacidades en las siguientes reas: Gestin Financiera Gestin del rendimiento (vase 3.52 Performance Management ) Gestin de Servicios Gestin de Riesgos (vase Gestin de Riesgos A.75 ) Gestin de Recursos Comunicaciones y Gestin de los interesados (vase 3.29 Comunicaciones y Gestin de los grupos de inters ) Gestin de la Calidad Gestin de Proveedores (vase Gestin de Proveedores A.82 ) Gestin de la Configuracin (ver Gestin de la Configuracin A.15 ) Gestin Ambiental
Central a la idea de operar una arquitectura en curso es la ejecucin del bien definido y un gobierno eficaz, por lo que toda la actividad de gran importancia arquitectnica es controlado y alineado en un marco nico. Como el gobierno se ha convertido en un requisito cada vez ms visible de la gestin organizacional, la inclusin de la gobernabilidad dentro de TOGAF alinea el marco de las mejores prcticas de negocio actual y tambin asegura un nivel de visibilidad, orientacin y control que apoyar todos los requisitos y obligaciones de las partes interesadas de la arquitectura. Los beneficios de la gobernabilidad arquitectura incluyen: El aumento de la transparencia de la rendicin de cuentas, y la delegacin inform de la autoridad La gestin del riesgo controlado Proteccin de la base de activos existente a travs de la maximizacin de la reutilizacin de los componentes arquitectnicos existentes Mecanismos de control proactivo, monitoreo y gestin Proceso, concepto, y el componente de reutilizacin a travs de todas las unidades de negocio de la organizacin La creacin de valor a travs del monitoreo, medicin, evaluacin y retroalimentacin
Pgina15de670

TOGOF9.1
Mayor visibilidad apoyo a los procesos internos y los requisitos de las partes externas; en particular, el aumento de la visibilidad de la toma de decisiones en los niveles inferiores es supervisado a un nivel adecuado dentro de la empresa de las decisiones que pueden tener importantes consecuencias estratgicas para la organizacin Gran valor para el accionista; en particular, la arquitectura empresarial representa cada vez ms la propiedad intelectual del ncleo de la empresa - los estudios han demostrado una correlacin entre el aumento de valor para los accionistas y las empresas bien gobernadas Se integra con los procesos y las metodologas existentes y complementa la funcionalidad mediante la adicin de capacidades de control
Mayores detalles sobre el establecimiento de una capacidad de arquitectura empresarial se da en la parte VII , 45. Introduccin .
2.10 El uso de TOGAF con otros marcos

Dos de los elementos clave de cualquier marco de arquitectura de la empresa son: Una definicin de los entregables que la actividad architecting debera producir Una descripcin del mtodo por el cual esto se debe hacer
Con algunas excepciones, la mayora de los marcos de arquitectura empresarial se centran en el primero de ellos - el conjunto especfico de prestaciones - y son relativamente en silencio acerca de los mtodos que se utilizarn para generarlos (intencionalmente as, en algunos casos). Debido TOGAF es un marco genrico y destinados a ser utilizados en una amplia variedad de entornos, proporciona un marco de contenidos flexible y extensible que sustenta un conjunto de entregables arquitectura genricos. Como resultado, TOGAF se puede utilizar ya sea en su propio derecho, con las prestaciones genricas que en l se describen; o bien estas prestaciones podrn ser sustituidos o ampliados por un conjunto ms especfico, definido en cualquier otro marco que el arquitecto considera pertinente. En todos los casos, se espera que el arquitecto se adaptar y se basar en el marco TOGAF con el fin de definir un mtodo a medida que se integra en los procesos y estructuras de organizacin de la empresa. Esta arquitectura adaptacin puede incluir la adopcin de elementos de otros marcos de arquitectura, o la integracin de mtodos TOGAF con otros marcos estndar, tales como ITIL, CMMI, COBIT, PRINCE2, PMBOK, y MSP. Directrices para la adaptacin de la TOGAF ADM de tal manera se proporcionan en la Parte II , 5.3 Adaptacin de la ADM . Como un marco genrico y un mtodo para la arquitectura empresarial, TOGAF proporciona la capacidad y el entorno de colaboracin para la integracin con otros marcos.Las organizaciones son capaces de utilizar plenamente los dominios verticales de negocios, reas tecnolgicas horizontales (como la seguridad o la capacidad de gestin), o reas de aplicacin (por ejemplo, eCommerce) para producir un marco de arquitectura empresarial competitivo que maximiza sus oportunidades de negocio.
Pgina16de670

TOGOF9.1
3. Definiciones
A los efectos de TOGAF 9, los siguientes trminos y definiciones. A. Glosario de Definiciones complementarias debe ser referido para las definiciones suplementarios no definidos en el presente captulo. Collegiate Dictionary de Merriam-Webster debe ser referido para los trminos no definidos en esta seccin o A. Glosario de definiciones complementarias .
3.1 Abstraccin
La tcnica de proporcionar descripciones resumidas o generalizadas de contenido detallado y complejo. La abstraccin, como en "nivel de abstraccin", tambin puede significar que proporciona un enfoque de anlisis que tiene que ver con un nivel consistente y comn de detalle o la abstraccin. Abstraccin en este sentido se utiliza normalmente en la arquitectura para permitir un nivel consistente de la definicin y la comprensin que deben alcanzarse en cada rea de la arquitectura con el fin de apoyar la comunicacin eficaz y la toma de decisiones. Es especialmente til cuando se trata de arquitecturas grandes y complejas ya que permite a cuestiones relevantes para ser identificados antes de que se intent ms detalle.
3.2 Actor
Una persona, organizacin o sistema que tiene un papel que inicia o interacta con las actividades; por ejemplo, un representante de ventas que viaja a visitar a los clientes.Actores puede ser interno o externo a la organizacin. En la industria automotriz, un fabricante de equipo original se considera un actor por un concesionario de automviles que interacta con sus actividades de la cadena de suministro.
3.3 Aplicacin
Un sistema informtico desplegado y operativo que soporte las funciones y servicios a las empresas; por ejemplo, una nmina. Las aplicaciones utilizan los datos y son apoyados por mltiples componentes de la tecnologa, pero son distintos de los componentes tecnolgicos que apoyan la solicitud.
3.4 Arquitectura de la aplicacin

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

Pgina17de670

TOGOF9.1
La coleccin de componentes de tecnologa de hardware y software que proporcionan los servicios utilizados para apoyar las aplicaciones.
3.6 Plataforma de Aplicaciones (API)

La interfaz o conjunto de funciones, entre el software de aplicacin y / o de la plataforma de aplicaciones.
3.7 Estilo arquitectnico

La combinacin de caractersticas distintivas en que se realiza o se expresa la arquitectura.
3.8 Arquitectura
1. Una descripcin formal de un sistema, o un plan detallado del sistema a nivel de componente, para orientar su aplicacin (fuente: ISO / IEC 42010:2007). 2. La estructura de los componentes, sus interrelaciones, y los principios y directrices que rigen su diseo y evolucin en el tiempo.
3.9 Arquitectura Bloque de construccin (ABB)

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

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

El ncleo de TOGAF. Un enfoque paso a paso para desarrollar y utilizar una empresa de arquitectura. Nota: El ADM se describe en la Parte II: Arquitectura Mtodo de Desarrollo (ADM) .
Pgina18de670

TOGOF9.1
3.12 Arquitectura de dominio

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

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

La prctica y la orientacin en la que las arquitecturas empresariales y otras arquitecturas son gestionados y controlados a nivel de toda la empresa. Tiene que ver con los procesos de cambio de gobierno (de diseo) y la operacin de sistemas de productos (gobernanza operativa). Ver tambin 3.39 Gobernabilidad .
3.15 Arquitectura del Paisaje

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

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

UnadescripcinsucintadelaArquitecturaobjetivoquedescribesuvalorparaelnegocioy loscambiosenlaempresa,queserelresultadodesuimplementacinexitosa.Sirve
comounavisinpolticayunlmiteparaeldesarrollodetalladodela arquitectura.
Pgina19de670

TOGOF9.1
Nota: Fase A (Architecture Vision) se describe en la Parte II , 7. Fase A: Architecture Vision .
3.18 Artefacto
Un producto del trabajo arquitectnico que describe un aspecto de la arquitectura. Ver tambin 3.21 Mdulo .
3.19 Lnea de Base

Una especificacin que ha sido revisado formalmente y acordado, que a partir de entonces, sirve como la base para un mayor desarrollo o el cambio y que slo se puede cambiar a travs de los procedimientos de control de cambios formales o de un tipo de procedimiento como la gestin de la configuracin.
3.20 Flujo de Informacin sin fronteras

1. Una marca registrada de The Open Group. 2. Una representacin abreviada de "acceso a la informacin integrada para apoyar mejoras
en los procesos de negocio", que representan un estado deseado de la infraestructura de una empresa especfica a las necesidades de negocio de la organizacin. Una infraestructura que ofrece sin fronteras Flujo de Informacin cuenta con componentes estndares abiertos que ofrecen servicios en la empresa extendida que de un cliente: Nota: La necesidad de flujo de informacin sin fronteras se describe en la Parte VI , 44. Integrado de Informacin de Referencia Infraestructura Modelo . Combine mltiples fuentes de informacin Segura entregar la informacin cuando y donde sea necesario, en el contexto adecuado para las personas o sistemas que utilicen dicha informacin.
3.21 Mdulo
Representa un (potencialmente reutilizable), componente de negocio, TI, o la capacidad de la arquitectura que se puede combinar con otros bloques de construccin para ofrecer arquitecturas y soluciones.
Pgina20de670

TOGOF9.1
Bloques de construccin se pueden definir en varios niveles de detalle, dependiendo de la etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una etapa temprana, un bloque de construccin puede consistir simplemente en un nombre o una breve descripcin. Ms tarde, un bloque de construccin se puede descomponer en varios bloques de edificios de apoyo y puede ir acompaada de una especificacin completa. Bloques de construccin pueden relacionarse con "arquitecturas" o "soluciones". Ver tambin 3.18 Artefacto . Nota: Bloques de construccin se describen en la Parte IV , 37. Building Blocks .
3.22 Arquitectura de Negocios

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

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

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

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

Una descripcin muy detallada de la propuesta de arquitectura para darse cuenta de una solucin particular o una solucin de aspecto.
Pgina21de670

TOGOF9.1
Incremento de 3,28 Capacidad

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

La gestin de las necesidades de las partes interesadas de la prctica de la arquitectura empresarial. Tambin gestiona la ejecucin de la comunicacin entre la prctica y los grupos de inters y la prctica y los consumidores de sus servicios. Nota: Arquitectura gestin de los interesados se describe en el 24. Gestin de las partes interesadas .
3.30 Las preocupaciones

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

Una descripcin de la estructura y la interaccin de los principales tipos de la empresa y las fuentes de datos, los activos de datos lgicos, los activos fsicos de datos y recursos de gestin de datos. Nota: Arquitectura de datos se describe en la Parte II , 10. Fase C: Arquitecturas de Sistemas de Informacin - Arquitectura de Datos .
3.33 Disponible
Un producto de la obra arquitectnica que se especifica y, a su vez revisado formalmente, de acuerdo, y firmado por las partes interesadas contractualmente. Entregables representa la salida de los proyectos y los resultados que se tenga en forma de documentacin normalmente se
Pgina22de670

TOGOF9.1
archiva en la finalizacin de un proyecto, o de transicin a un repositorio de arquitectura como un modelo de referencia, estndar o instantnea de la arquitectura del paisaje en un punto en el tiempo.
3.34 Empresa
El nivel ms alto (por lo general) de la descripcin de una organizacin y por lo general cubre todas las misiones y funciones. Una empresa a menudo abarcar varias organizaciones.
Continuum 3.35 Empresa

Un mecanismo til para la clasificacin de la arquitectura y la solucin artefactos, tanto internos como externos a la arquitectura de repositorio, a medida que evolucionan a partir de genricos Arquitecturas Fundacin a las arquitecturas Organizacin especficas de categorizacin. Ver tambin 3.10 Arquitectura Continuum y 3.67 Soluciones Continuum .
3.36 Fundacin Arquitectura

Bloques genricos de construccin, sus interrelaciones con otros bloques de construccin, junto con los principios y directrices que proporcionan una base sobre la que las arquitecturas ms especficas se pueden construir.
3.37 Marco
Una estructura para el contenido o proceso que se puede utilizar como una herramienta para estructurar el pensamiento, asegurando la consistencia e integridad.
3.38 Gap
Una declaracin de la diferencia entre los dos estados. Utilizado en el contexto del anlisis de las lagunas, donde se identifica la diferencia entre la lnea de base y Arquitectura Target. Nota: El anlisis de brechas se describe en la Parte III , 27. Anlisis Gap .
3.39 Gobierno
La disciplina de controlar, gestionar y dirigir un negocio (o IS / paisaje IT) para entregar los resultados de negocio requiere. Ver tambin 3.14 Arquitectura Gobernabilidad , Gobernanza 3.24 Negocios y A.60 Gobierno Operacional en A. Glosario de definiciones complementarias .
Pgina23de670

TOGOF9.1
3.40 Informacin
Cualquier comunicacin o representacin de hechos, datos u opiniones, en cualquier medio o forma, incluyendo textual, numrico, grfico, cartogrfico, la narrativa, o formas audiovisuales.
3,41 Tecnologa de la Informacin (IT)

1. La gestin del ciclo de vida de la informacin y la tecnologa relacionada utilizado por una organizacin. 2. Un trmino general que incluye todas o algunas de las materias relacionadas con la
industria de la computacin, tales como la Continuidad del Negocio, Negocio Interfaz IT, Business Process Modeling y Gestin, Comunicacin, Cumplimiento y Legislacin, Informtica, Gestin de Contenidos, Hardware, Gestin de la Informacin, Internet , Offshoring, Redes, Programacin y Software, Asuntos Profesionales, Gestin de Proyectos, Seguridad, Estndares, almacenamiento, voz y comunicaciones de datos. Varios pases e industrias emplean otros trminos paraguas para describir esta misma coleccin.
3. Un trmino comnmente asignada a un departamento dentro de una organizacin

encargada de aprovisionamiento de algunos o todos los dominios descritos en (2) anteriormente.
4. Los nombres alternativos comnmente adoptadas incluyen Servicios de Informacin, Gestin de la Informacin, et al.
3.42 Interoperabilidad
1. La capacidad de compartir informacin y servicios. 2. La capacidad de dos o ms sistemas o componentes para intercambiar y utilizar la informacin. 3. La capacidad de los sistemas para ofrecer y recibir servicios de otros sistemas y para
utilizar los servicios de manera intercambiada para que puedan funcionar juntos de manera efectiva.
3.43 Lgico
Una definicin independiente de la implementacin de la arquitectura, a menudo agrupar entidades fsicas relacionadas en funcin de su finalidad y estructura. Por ejemplo, los productos de mltiples proveedores de software de infraestructura pueden ser agrupados de forma lgica como plataformas de servidor de aplicaciones Java.
Pgina24de670

TOGOF9.1
3.44 Metadatos
Los datos acerca de los datos, de cualquier tipo en cualquier medios de comunicacin, que describe las caractersticas de una entidad.
3.45 Metamodel
Un modelo que describe cmo y con qu la arquitectura se describir de una manera estructurada.
3.46 Mtodo
Un enfoque repetible definida para hacer frente a un tipo particular de problema. Ver tambin 3.47 Metodologa .
3.47 Metodologa
A definido, serie repetible de medidas para abordar un determinado tipo de problema, que por lo general se centra en un proceso definido, pero tambin puede incluir la definicin de los contenidos. Ver tambin Mtodo 3,46 .
3.48 Modelo
Una representacin de un tema de inters. Un modelo proporciona una escala ms pequea y simplificada, y / o representacin abstracta de la materia. Un modelo se construye como un "medio para un fin". En el contexto de la arquitectura de la empresa, el tema es un todo o parte de la empresa y el final es la capacidad de construir "vistas" que aborden las preocupaciones de los grupos de inters particulares; es decir, sus "puntos de vista" en relacin con el tema en cuestin. Ver tambin 3.68 Stakeholder , 3.75 Vista , y 3.76 Viewpoint .
3.49 Modelado
Una tcnica a travs de la construccin de modelos que permite a un sujeto para ser representados en una forma que permite el razonamiento, perspicacia y claridad en cuanto a la esencia de la materia.
3.50 Objetivo
Un hito de tiempo limitado para que una organizacin utiliza para demostrar el progreso hacia una meta; por ejemplo, "Aumentar la utilizacin de la capacidad en un 30% a finales de 2009 para apoyar el aumento previsto en el mercado de la cuota ".
Pgina25de670

TOGOF9.1
3.51 Patrones
Una tcnica para poner bloques de construccin en su contexto; ., por ejemplo, para describir una solucin reutilizable a un problema de construccin bloques son lo que usted utiliza: patrones pueden decir cmo usarlos, cundo, por qu, y qu ventajas y desventajas que tiene que hacer con ello. Ver tambin 3.21 Mdulo .
3.52 Gestin del Rendimiento

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

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

Un modelo de referencia es un marco abstracto para comprender las relaciones significativas entre las entidades de [un] medio ambiente y para el desarrollo de los estndares o especificaciones que apoyan ese ambiente consistentes. Un modelo de referencia se basa en un pequeo nmero de conceptos unificadores y puede ser utilizado como base para la educacin y las normas que explican a un no especialista. Un modelo de referencia no est directamente ligada a las normas, tecnologas u otros detalles de implementacin concretos, pero s busca proporcionar semntica comn que se pueden utilizar de forma inequvoca a travs y entre diferentes implementaciones.
Pgina26de670

TOGOF9.1
3.58 Repositorio
Un sistema que gestiona todos los datos de una empresa, incluidos los modelos de proceso de datos y la informacin de la empresa y otra. Por lo tanto, los datos de un repositorio es mucho ms extensa que la de un diccionario de datos, que por lo general slo define los datos que componen una base de datos .
3.59 Requisito
Una declaracin de la necesidad que debe ser satisfecha por una arquitectura o paquete de trabajo en particular.
3.60 Hoja de Ruta

Un plan abstracto para el cambio de negocios o tecnologa, por lo general operan a travs de mltiples disciplinas largo de varios aos. Normalmente se utiliza en las frases Technology Roadmap, Arquitectura Roadmap, etc
3.61 Papel
1. La funcin habitual o esperado de un actor, o la parte que alguien o algo juega en una accin o evento en particular. Un actor puede tener una serie de funciones. 2. La parte de un individuo desempea en una organizacin y la contribucin que hacen a travs de la aplicacin de sus habilidades, conocimientos, experiencia y habilidades.
3.62 Segmento de Arquitectura

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

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

. Un estilo arquitectnico que apoya la orientacin al servicio Tiene las siguientes caractersticas distintivas:
Pgina27de670

TOGOF9.1
Se basa en el diseo de los servicios - que reflejan las actividades empresariales del mundo real - que comprenden la empresa (o entre empresas) los procesos de negocio. Representacin del Servicio utiliza descripciones empresariales para proporcionar el contexto (es decir, los procesos de negocio, meta, regla, poltica, interfaz de servicio, y el componente de servicio) e implementa servicios utilizando la orquestacin de servicios. Coloca los requisitos nicos de la infraestructura -, se recomienda que las implementaciones utilizan estndares abiertos para darse cuenta de la interoperabilidad y la transparencia de ubicacin. Las implementaciones son favorables al medio especfico - se ven limitados o habilitadas por el contexto y deben ser descritas dentro de ese contexto. Se requiere un gobierno fuerte de la representacin de servicios y la ejecucin. Se requiere de una "prueba de fuego", lo que determina un "buen servicio".
3.65 Arquitectura de la solucin

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

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

Una parte del Continuum Enterprise. Un repositorio de soluciones reutilizables para los futuros esfuerzos de aplicacin. Contiene implementaciones de las definiciones correspondientes en la Arquitectura Continuum.
3.68 Stakeholder
Un individuo, equipo u organizacin (o clases de los mismos) con intereses en, o preocupaciones en relacin con el resultado de la arquitectura. Diferentes actores con diferentes roles tienen diferentes preocupaciones.
3.69 Normas de Informacin de Base (SIB)

Una base de datos de normas que se pueden utilizar para definir los servicios particulares y otros componentes de una arquitectura de organizacin especfica.
Pgina28de670

TOGOF9.1
3.70 Arquitectura Estratgica

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

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

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

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

Una descripcin formal de un estado de la arquitectura en un punto de vista arquitectnico significativa en el tiempo. Uno o ms arquitecturas de transicin puede ser usado para describir la progresin en el tiempo desde la lnea base hasta la arquitectura destino.
3.75 Ver
La representacin de un conjunto relacionado de preocupaciones. Un punto de vista es lo que se ve desde un punto de vista. Una vista de la arquitectura puede ser representado por un modelo de demostrar a las partes interesadas de sus reas de inters en la arquitectura. Un punto de vista no tiene por qu ser visual o grfica en la naturaleza.
3.76 Punto de vista

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

Pgina29de670

TOGOF9.1
Un conjunto de acciones identificadas para alcanzar uno o ms objetivos para el negocio. Un paquete de trabajo puede ser una parte de un proyecto, un proyecto completo, o un programa.
Pgina30de670

TOGOF9.1
4. Notas de la versin
A los efectos de TOGAF 9, las notas de la versin se proporcionan en este captulo se aplican.
4.1 Qu hay de nuevo en TOGAF 9?

En esta seccin se ofrece un panorama general de las principales caractersticas nuevas en TOGAF 9.
Estructura Modular
Uno de los focos de TOGAF 9 desarrollo ha sido asegurar que el contenido de la especificacin se ha estructurado de forma modular. La estructura modular de siete partes de TOGAF permite que los conceptos en cada parte para ser desarrolladas con impactos limitados en otras partes. El contenido que estaba contenida dentro de la base de recursos TOGAF 8.1.1 est catalogado y trasladado a las partes que tienen un propsito definido (por oposicin a los "recursos" genricas). La estructura modular de TOGAF se pretende contribuir a una mayor facilidad de uso, ya que cada parte tiene un propsito definido y puede leerse de manera aislada como un stand-alone conjunto de directrices. Se espera que la estructura modular para apoyar la adopcin gradual de la especificacin TOGAF. Finalmente, la estructura modular soporta gestin de versiones ms sofisticadas de la especificacin TOGAF. En el futuro, las partes individuales pueden evolucionar a diferentes velocidades y la estructura actual especificacin tiene por objeto permitir cambios en un rea que se llevan a cabo con un impacto limitado en toda la especificacin.
Marco de Contenido
Una importante adicin de nuevos contenidos a la especificacin TOGAF es el marco de contenido. El marco de contenido TOGAF proporciona un modelo detallado de los productos de trabajo de arquitectura, incluyendo entregables, artefactos dentro de los entregables, y los bloques de construccin arquitectnicos que representan los artefactos. La intencin de incluir un marco de contenidos dentro de TOGAF es impulsar una mayor coherencia en las salidas que se crean cuando se sigue un mtodo de desarrollo de la arquitectura (ADM). La ventaja de incluir un marco de contenido se aplica a un nmero de niveles. En primer lugar, dentro de una sola iniciativa de desarrollo de la arquitectura del marco de contenido proporciona una lista completa de los productos de arquitectura que podra crearse y en consecuencia reducir el riesgo de brechas dentro de la arquitectura final conjunto entregable. La segunda ventaja importante de la inclusin de un marco de contenido se aplica cuando se trata de integrar los productos de trabajo de arquitectura en una empresa. El marco de contenido est destinado a ser adaptado y adoptado por una empresa con el fin de ordenar conceptos estndares arquitectnicos, trminos y entregables. Si todas las iniciativas de arquitectura utilizan los mismos modelos de contenido, sus salidas se pueden combinar con mayor facilidad que en situaciones en que cada arquitecto utiliza un enfoque completamente diferente. Por ltimo, un beneficio importante de la inclusin de un marco contenido dentro de TOGAF es que proporciona (por primera vez) un estndar abierto detallada de cmo se deben describir
Pgina31de670

TOGOF9.1
arquitecturas. La existencia de esta norma permite a los proveedores de herramientas, proveedores de productos y proveedores de servicios para que adopten formas consistentes de trabajo, que a su vez se traducir en una mayor coherencia entre las herramientas de arquitectura, una mejor interoperabilidad de herramientas, arquitecturas de referencia ms coherentes y mejor comparabilidad entre las arquitecturas de referencia relacionados .
Orientacin extendido en adopcin TOGAF dentro de una empresa
Dentro de las organizaciones ms grandes, la prctica de la arquitectura de la empresa requiere de una serie de personas y equipos que trabajan juntos en muchas arquitecturas . Aunque cada arquitectura abordar un problema especfico, en un ideal arquitecturas situacin se puede considerar como un grupo con el fin de desarrollar una visin integrada global de cmo la empresa est cambiando. Esta versin de TOGAF cuenta con un amplio conjunto de conceptos y directrices para apoyar el establecimiento de una jerarqua integrada de las arquitecturas estn siendo desarrollados por los equipos que operan dentro de un modelo de gobernanza arquitectnico general. En particular, se presentan los siguientes conceptos: Particionamiento : Con el fin de desarrollar arquitecturas que tienen niveles manejables de coste y la complejidad, es necesario particionar la empresa en las arquitecturas especficas. TOGAF discute el concepto de la separacin y ofrece una variedad de tcnicas y consideraciones de cmo particionar las diversas arquitecturas dentro de una empresa. Arquitectura Repositorio : TOGAF proporciona un modelo de informacin lgica para un repositorio Arquitectura, que puede ser utilizado como un almacn integrado para todas las salidas creados por la ejecucin de la ADM. Marco Capacidad : Esta versin de TOGAF ofrece una definicin ms estructurado a la organizacin, competencias, funciones y responsabilidades que se requieren para operar una capacidad efectiva de arquitectura empresarial. Los nuevos materiales TOGAF tambin proporcionan orientacin sobre un proceso que se puede seguir para identificar y establecer una capacidad Arquitectura apropiado.
Consideracin explcita de estilos arquitectnicos, incluyendo SOA y Arquitectura de Seguridad
La nueva parte III: Directrices y Tcnicas ADM rene un conjunto de materiales que muestran con ms detalle cmo el ADM se puede aplicar a las situaciones especficas de apoyo. Las nuevas pautas discuten: Los diversos usos de iteracin que son posibles dentro de la ADM y cuando cada tcnica se deben aplicar Los vnculos entre el TOGAF ADM y Arquitectura Orientada a Servicios (SOA) Las consideraciones especficas que se requieren para hacer frente a la arquitectura de seguridad dentro de la ADM
Pgina32de670

TOGOF9.1
Los diversos tipos de desarrollo de la arquitectura necesarios dentro de una empresa y cmo se relacionan entre s
Detalle adicional ADM
Esta versin de la especificacin TOGAF incluye informacin ms detallada apoyo a la ejecucin de la ADM. reas particulares de mejora son: La fase preliminar, que cuenta con una gua extendida en el establecimiento de un marco de arquitectura de la empresa y la planificacin para el desarrollo de la arquitectura. La Fase Preliminar extendido tambin ofrece consejos para la definicin de un modelo de gobernanza para la realizacin arquitectura beneficio y tambin analiza la vinculacin entre TOGAF y otros marcos de gestin. Las Oportunidades y fase Soluciones y planeamiento de migracin de fase, que cuentan con un mtodo ms detallado y slido para la definicin y planificacin de transformacin de la empresa, con base en los principios de la planificacin basada en la capacidad.
4.1.1 Los cambios aplicados en esta edicin

Esta edicin de TOGAF 9 incluye un conjunto de actualizaciones de mantenimiento en base a los comentarios recibidos en la publicacin de 2009. . Un documento detallado por separado de los cambios est disponible como TOGAF 9 Rectificacin Tcnica N 1 (Documento U112) se incluye a continuacin una lista resumida de los cambios: Se han eliminado las definiciones de los trminos en que el uso por TOGAF no es distintivo de la definicin de diccionario comn. El uso de los trminos "aplicacin" contra "el sistema" se han revisado y hecho consistente. Las descripciones de la Fase E y F se han modificado para que coincida con el nivel de detalle en otras fases. Los usos de la terminologa para la transicin Arquitectura / Roadmap Estrategia / Implementacin han aclarado y hecho consistente. Los conceptos de niveles / iteraciones / particiones han aclarado y hecho consistente. Esto incluye una reorganizacin de material en la parte III , 19. La aplicacin de la iteracin de la ADM y 20. La aplicacin de la ADM a travs de la arquitectura del paisaje , y la Parte V , 40. Arquitectura de particionamiento . Los "Objetivos" secciones de las fases se han revisado a fin de centrarse en los objetivos reales en lugar de las tcnicas o una lista de pasos. Los artefactos posibles (puntos de vista) para cada fase se muestran ahora en la descripcin de esa fase, no slo en la Parte IV , 35. Architectural Artifacts . Los trminos "artefacto" en comparacin con "punto de vista" se han aclarado y hecho consistente. Esto incluye una reestructuracin de la Parte IV , 35.Architectural Artifacts . El captulo SOA ( Parte III , 22. Uso de TOGAF para definir y Gobierno SOAs ) ha sido actualizado para describir la ltima salida de grupo de trabajo de SOA.
Pgina33de670

TOGOF9.1
Texto introductorio adicional sobre los estilos arquitectnicos se ha aadido en la Parte III , 18. Introduccin . Pequeos cambios se han hecho para el captulo de la arquitectura de seguridad ( Parte III , 21. Arquitectura de Seguridad y el ADM ) para mantener la coherencia con el ADM. Se han realizado correcciones a metamodelo diagramas. Las correcciones se han aplicado a los aspectos del metamodelo. En el ejemplo de bloques de construccin se ha eliminado. La categorizacin de modelo de documento se ha eliminado. Duplicar texto en varios lugares ha sido reemplazado con una referencia adecuada: o Anlisis de brechas en las fases B, C y D ahora referencia a la Parte III , 27. Anlisis Gap . Gestin de Requisitos en varias fases ahora hace referencia la parte II , 17.2.2 Requisitos para el Desarrollo en la fase de gestin de requisitos.
Algunos de los artefactos han sido renombrados para reflejar mejor su uso: o o Matriz System / Data se convierte en matriz de aplicaciones / datos Diagrama de clases ha sido reemplazado con el diagrama conceptual de datos y el diagrama de lgica de datos Matriz del sistema / Organizacin convierte matriz Aplicacin / Organizacin Matriz de Papel / System convierte matriz Papel / Aplicacin Matriz de Sistema / Funcin convierte en matriz de Aplicacin / Funcin Diagrama Realizacin de proceso / sistema convierte diagrama Realizacin de proceso / aplicacin Diagrama del sistema de casos de uso se convierte en el diagrama de casos de uso de aplicaciones Matriz del sistema / tecnologa se convierte en matriz de Aplicacin / Tecnologa
o o o o
La descripcin de la arquitectura de principios ahora los divide en dos nicos tipos Enterprise y Arquitectura -, mientras que antes de que llamaran a los Principios de TI por separado. IT Principios ahora son vistos como slo una parte de los Principios Empresariales. El Stakeholder Mapa incorporado en el captulo de gestin de los interesados ( Parte III , 24. Gestin de los grupos de inters ) que ahora se hace referencia explcita a modo de ejemplo, la tabla se ha puesto de relieve para referirse a las preocupaciones de las partes interesadas, y la lista de objetos para cada grupo de inters actualizada.
Pgina34de670

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

TOGAF 9 proporciona un conjunto amplio de revisiones de la especificacin TOGAF. Cuando se combinan, estas ediciones buscan lograr un conjunto de objetivos para mejorar el valor del marco TOGAF.
Mayor usabilidad
Una serie de mejoras dentro de TOGAF 9 apoyo mayor facilidad de uso de la especificacin general. En primer lugar, la estructura modular de la especificacin hace que sea ms fcil para un arquitecto para que considere la posibilidad de un aspecto especfico de la Capacidad de Arquitectura. En todas las reas, la especificacin pretende agregar el detalle y la claridad por encima y ms all de las versiones anteriores TOGAF.
Ms de enfoque sobre el cambio de empresa Holstica
TOGAF tiene una slida historia en la arquitectura de TI, teniendo en cuenta las formas en que se puede apoyar el cambio de empresa. Sin embargo, como TOGAF ha crecido en profundidad y madurez se ha convertido en un marco para la gestin de todo el espectro de los cambios necesarios para transformar una empresa hacia un modelo operativo de destino. TOGAF 9 contina esta evolucin e incorpora una perspectiva ms amplia de cambio que permite a la arquitectura empresarial que se utiliza para especificar la transformacin a travs de los dominios de negocio, datos, aplicaciones y tecnologa.
Ms Consistencia de salida
Las versiones anteriores de TOGAF centran en proporcionar un proceso coherente para el desarrollo de arquitecturas. TOGAF 9 incluye una consideracin muy mejorada de los productos arquitectnicos de trabajo para asegurar que un proceso coherente se utiliza para producir salidas coherentes. El Marco de Arquitectura de contenidos proporciona un modelo detallado de las salidas que se creen por el ADM. Adems, las secciones de la empresa Continuum, Arquitectura de particiones, y arquitectura de repositorio proporcionan orientacin detallada sobre cmo entregables arquitectnicos pueden estar al alcance, rigen, e integradas.
Pgina35de670

TOGOF9.1
4.3 Mapeo de la Estructura TOGAF 8.1.1 a TOGAF 9

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

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

La siguiente tabla muestra los puntos de TOGAF 9 captulos se asignan a los de TOGAF 8.1.1:
TOGAF 9 Captulo Parte I: Introduccin 1 Introduccin 2 Conceptos Bsicos 3 Definiciones 4 Notas de la versin Parte II: Arquitectura Mtodo de Desarrollo 5 Introduccin 6 Fase Preliminar 7 Fase A: Architecture Vision 8 Fase B: Arquitectura de Negocios Derivacin de TOGAF 8.1.1 Material revisado; basado en el captulo 1 Nuevo captulo El material derivado de Captulo 36, vuelto a trabajar en las definiciones formales y abreviaturas secciones Nuevo captulo Material revisado; basado en el Captulo 3 Material revisado; basado en el Captulo 4 Material revisado; basado en el Captulo 5 Material revisado; basado en el Captulo 6
Pgina37de670

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

TOGOF9.1
47 Architecture Board 48 Arquitectura Cumplimiento 49 Arquitectura contratos 50 Arquitectura de Gobierno 51 Modelos de Madurez Arquitectura 52 Arquitectura Skills Framework La Glosario de Definiciones complementarias B Abreviaturas Con cambios mnimos; mapas del captulo 23 Con cambios mnimos; mapas para el Captulo 24 Con cambios mnimos; mapas para el Captulo 25 Con cambios mnimos, se asigna al Captulo 26 Con cambios mnimos; mapas del captulo 27 Algunos cambios cosmticos; mapas del captulo 30 Derivado del Captulo 36 Derivado del Captulo 36
4.5 Utilizar TOGAF

4.5.1 Condiciones de uso
La documentacin TOGAF est libremente disponible para ver en lnea sin licencia. Alternativamente, el conjunto completo de documentacin TOGAF puede ser descargado y almacenado bajo licencia, como se explica en el sitio web la informacin TOGAF. En cualquier caso, la documentacin TOGAF puede ser utilizado libremente por cualquier organizacin que as lo deseen para desarrollar una arquitectura para su uso dentro de esa organizacin. Ninguna parte de ella puede ser reproducida, almacenada en un sistema de recuperacin, o transmitida de ninguna forma ni por ningn medio, ya sea electrnico, mecnico, fotocopia, grabacin, o de otra manera, para cualquier otro propsito, incluyendo, pero no a modo de limitacin, cualquier utilizacin con fines comerciales, sin el permiso previo de los propietarios de derechos de autor.
4.5.2 Cunto cuesta TOGAF?

The Open Group opera como un consorcio sin fines de lucro comprometida con la entrega de una mayor eficiencia de las empresas, reuniendo a compradores y proveedores de sistemas de informacin para reducir las barreras de la integracin de las nuevas tecnologas en la empresa. Su objetivo es hacer realidad la visin de Flujo de informacin sin fronteras. TOGAF es una parte clave de su estrategia para lograr este objetivo, y The Open Group quiere TOGAF que deben abordarse y se utiliza en los proyectos de arquitectura prcticos y la experiencia de su uso realimenta a ayudar a mejorarlo. Por tanto, el Open Group publica TOGAF en su servidor web pblico, y permite y alienta la reproduccin y el uso libre de cargo por cualquier organizacin que desee utilizarlo internamente para desarrollar una arquitectura empresarial. (Existen restricciones para su explotacin comercial, sin embargo, ver 4.5.1 Condiciones de uso .)
4.5.3 Descargas
Descargas de la documentacin TOGAF, incluyendo un archivo PDF para imprimir, estn disponibles bajo licencia desde el sitio web la informacin TOGAF (consultewww.opengroup.org / Arquitectura / togaf ). La licencia es libre para cualquier organizacin que desee utilizar TOGAF exclusivamente para fines internos (por ejemplo, para desarrollar una empresa de arquitectura para su uso dentro de la organizacin).
Pgina39de670

TOGOF9.1
4.6 Por qu unirse The Open Group?

Las organizaciones que deseen reducir el tiempo, costo y riesgo de la implementacin de soluciones de mltiples proveedores que se integran dentro de y entre las empresas necesitan The Open Group como su socio clave. The Open Group rene a los compradores y proveedores de sistemas de informacin en todo el mundo, y les permite trabajar juntos, tanto para garantizar que las soluciones de TI a cumplir las necesidades de los clientes, y para hacer ms fcil la integracin de TI en toda la empresa. TOGAF es un factor clave en esta tarea. S, s TOGAF est disponible gratuitamente. Pero, cunto va a gastar en el desarrollo o la actualizacin de su arquitectura empresarial utilizando TOGAF? Y cunto va a gastar en adquisiciones en base a que la arquitectura? El precio de la membresa de The Open Group es insignificante en comparacin con estas cantidades. Adems de los beneficios generales de la pertenencia, como miembro de The Open Group usted ser elegible para participar en el Foro de Arquitectura Open Group, que es el programa de desarrollo en el que se desarroll TOGAF, y en el que los usuarios TOGAF reunirse para intercambiar informacin y la retroalimentacin. Los miembros de la ganancia Architecture Forum: Acceso inmediato a los frutos del actual programa de trabajo TOGAF (no disponible para el pblico hasta la publicacin de la prxima edicin del documento TOGAF) - de hecho, la ltima informacin sobre TOGAF El intercambio de experiencias con otras organizaciones de clientes y proveedores que participan en la arquitectura empresarial en general, y la creacin de redes con los arquitectos que utilizan TOGAF en proyectos de desarrollo de arquitectura importantes de todo el mundo La revisin por pares de la caja material de estudio arquitectura especfica
Pgina40de670

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 o o La amplitud de la cobertura de la empresa a definir El nivel de detalle que se define La extensin del perodo de tiempo destinado a, incluyendo el nmero y extensin de cualquier periodos de tiempo intermedios Los activos de arquitectura para ser movilizados, entre ellos: Activos creados en versiones anteriores del ciclo de ADM en la empresa Activos disponibles en la industria en otras partes (otros marcos, modelos de sistemas, modelos industriales verticales, etc)
Estas decisiones 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 A: Architecture Vision Entregable Arquitectura Visin Contenido Negocios Arquitectura Datos Arquitectura Aplicacin Arquitectura Tecnologa de Arquitectura B: Arquitectura de Negocios C: Sistemas de Informacin Arquitectura Arquitectura Definicin Documento Arquitectura Definicin Documento Negocios Arquitectura Datos Arquitectura Aplicacin Arquitectura Tecnologa de Versin Descripcin 0.1 Versin 0.1 indica que un esquema de alto nivel de la arquitectura est en su lugar. 0.1 Versin 0.1 indica que un esquema de alto nivel de la arquitectura est en su lugar. 0.1 Versin 0.1 indica que un esquema de alto nivel de la arquitectura est en su lugar. 0.1 Versin 0.1 indica que un esquema de alto nivel de la arquitectura est en su lugar. 1.0 Versin 1.0 indica una revisin formal, la arquitectura detallada. 1.0 Versin 1.0 indica una revisin formal, la arquitectura detallada. Versin 1.0 indica una revisin formal, la arquitectura detallada. Versin 1.0 indica una revisin formal, la
1.0 1.0
D: Architecture
Arquitectura
Pgina46de670

TOGOF9.1
Tecnologa Definicin Documento Arquitectura arquitectura detallada.
Tabla51:ConvencindeNumeracinADMVersion
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) 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 . 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 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. 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 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 Identificar y el alcance de los elementos de las organizaciones empresariales afectadas por la Capacidad de Arquitectura Identificar los marcos establecidos, mtodos y procesos que se cruzan con la capacidad de Arquitectura Establecer destino Capability Maturity
2. Establecer la Capacidad de Arquitectura:

o o Definir y establecer el modelo de organizacin de la Arquitectura Empresarial Definir y establecer el proceso detallado y recursos para la gobernanza de la arquitectura Seleccionar y aplicar herramientas que apoyan la capacidad Arquitectura Definir los principios de la arquitectura
o o
6.2 Enfoque
Esta Fase Preliminar trata de definir "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 o o o o o o o Los mtodos actuales para la descripcin de la arquitectura Marcos y mtodos de gestin de proyectos actuales Marcos y mtodos de gestin de los sistemas actuales Procesos y mtodos de gestin de la cartera de proyectos actuales Procesos y mtodos de gestin de la cartera de aplicaciones actuales Procesos y mtodos de gestin de la cartera de tecnologa actuales Procesos y mtodos de gestin de carteras de informacin actuales 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.
Figura63:Interoperabilidadyrelacionesentrelosmarcosdegestin
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 o o o o mbito de las organizaciones afectadas La evaluacin gestacional, lagunas, y el enfoque de resolucin Roles y responsabilidades de equipo de arquitectura (s) Necesidades presupuestarias Gobernabilidad y estrategia de apoyo
Marco de arquitectura existente, en su caso, incluyendo: o o o o o Mtodo de Arquitectura Contenido de Arquitectura Herramientas de configurar e implementar Principios Arquitectura 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 Solicitud de evaluacin de impacto en sus planes y el trabajo Identificar reas de inters comn Identifique las diferencias crticas y conflictos de inters Producir las solicitudes de cambio a las actividades de las partes interesadas
o o o o
Determine las restricciones sobre el trabajo de arquitectura empresarial Revise y estoy de acuerdo con los patrocinadores y junta Evaluar las necesidades presupuestarias
6.4.4 Identificar y establecer Arquitectura Principios

Arquitectura Principios (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 o o Enlaces a los procesos de gestin de carteras de proyectos (y de servicios) Enlaces a ciclo vital del proyecto 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) 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: Modelo de organizacin de Arquitectura Empresarial (vase la Parte IV , 36.2.16 Modelo de Organizacin de Empresa de Arquitectura ), incluyendo: o o o o o o mbito de las organizaciones afectadas La evaluacin gestacional, lagunas, y el enfoque de resolucin Roles y responsabilidades de equipo de arquitectura (s) Las restricciones sobre el trabajo de arquitectura Necesidades presupuestarias Gobernabilidad y estrategia de apoyo
Tailored Architecture Framework (vase la Parte IV , 36.2.21 Tailored Architecture Framework ), que incluye: o o o Mtodo de arquitectura adaptada Adaptado contenido de la arquitectura (entregables y artefactos) Arquitectura Principios (ver la Parte IV , 36.2.4 Principios de Arquitectura )
Pgina66de670

TOGOF9.1
o Herramientas de configurar e implementar
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.
7.3.1 Materiales de Referencia Externa a la Empresa Materiales de referencia Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio )
Pgina70de670

TOGOF9.1
7.3.2 Entradas para no Arquitectnicos 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 )
7.3.3 Entradas de arquitectura Modelo de organizacin de Arquitectura Empresarial (vase la Parte IV , 36.2.16 Modelo de Organizacin de Empresa de Arquitectura ), incluyendo:
o o o o o o o o mbito de las organizaciones afectadas La evaluacin gestacional, lagunas, y el enfoque de resolucin Roles y responsabilidades de equipo de arquitectura (s) Las restricciones sobre el trabajo de arquitectura Requisitos de reutilizacin Necesidades presupuestarias Las solicitudes de cambio Gobernabilidad y estrategia de apoyo
Tailored Architecture Framework (vase la Parte IV , 36.2.21 Tailored Architecture Framework ), que incluye: o o o Mtodo de arquitectura adaptada Adaptado contenido de la arquitectura (entregables y artefactos) Principios Arquitectura (ver la Parte IV , 36.2.4 Principios Arquitectura ), incluidos los principios de negocios, al pre-existente Herramientas de configurar e implementar
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 o Activos creados en versiones anteriores del ciclo de ADM en la empresa Activos disponibles en la industria en otras partes (otros marcos, modelos de sistemas, modelos industriales verticales, etc)
7.4.7 Confirmar y Arquitectura elaborar principios, incluidos los Principios de 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 o o Arquitectura Descripcin y alcance del proyecto Descripcin general de Arquitectura Visin 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 ) Tailored Architecture Framework (vase la Parte IV , 36.2.21 Tailored Architecture Framework ) (para la contratacin), incluyendo: o o o Mtodo de arquitectura adaptada Adaptado contenido de la arquitectura (entregables y artefactos) Herramientas de configurar e implementar
Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ), incluyendo: o Descripcin del problema
Pgina77de670

TOGOF9.1
o o o o Objetivo de la Declaracin de Arquitectura de Trabajo Vistas de resumen Escenario empresarial (opcional) Requisitos clave refinados de interesados de alto nivel
Proyecto de Arquitectura de definicin de documento, incluyendo (cuando alcance): o o o o o o o o Lnea de base de Empresas Arquitectura, Versin 0.1 Lnea de Base Tecnolgica de Arquitectura, Versin 0.1 Arquitectura de datos de lnea de base, versin 0.1 Lnea de base de arquitectura de aplicaciones, versin 0.1 Objetivo Negocio Arquitectura, Versin 0.1 Tecnologa Target Arquitectura, Versin 0.1 Arquitectura de datos de destino, Versin 0.1 Objetivo de Arquitectura de aplicaciones, Versin 0.1
Nota:
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 )
Escenarios de negocios mltiples pueden ser usados para generar una nica arquitectura Visin. Las salidas pueden incluir algunos o todos de los siguientes: Matrices: o Matriz de los grupos de inters Mapa
Diagramas: o o Diagrama de la cadena de valor 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 El TeleManagement Forum (TMF) - www.tmforum.org - ha desarrollado modelos de negocio detallados relevante para la industria de las Telecomunicaciones. Departamentos y agencias gubernamentales de los diferentes 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. 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. 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.
8.3.1 Materiales de Referencia Externa a la Empresa Materiales de referencia Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 8.3.2 Entradas para no Arquitectnicos 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 ) Evaluacin de capacidades (vase la Parte IV , 36.2.10 Evaluacin de Capacidad ) Plan de comunicacin (ver la Parte IV , 36.2.12 Plan de Comunicaciones )
o mbito de las organizaciones afectadas
Pgina84de670

TOGOF9.1
o o o o o La evaluacin gestacional, lagunas, y el enfoque de resolucin Roles y responsabilidades de equipo de arquitectura (s) Las restricciones sobre el trabajo de arquitectura Necesidades presupuestarias Gobernabilidad y estrategia de apoyo
Tailored Architecture Framework (vase la Parte IV , 36.2.21 Tailored Architecture Framework ), que incluye: o o o Mtodo de arquitectura adaptada Adaptado contenido de la arquitectura (entregables y artefactos) Herramientas de configurar e implementar
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 o o o Bloques de construccin reutilizables Modelos de referencia disponibles al pblico Modelos de referencia especficos de la organizacin Normas de la Organizacin
Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ), incluyendo: o o o o o Descripcin del problema Objetivo de la Declaracin de Arquitectura de Trabajo Vistas de resumen Escenario empresarial (opcional) Requisitos clave refinados de interesados de alto nivel
Proyecto de Arquitectura de definicin de documento, incluyendo (cuando alcance): o o Lnea de base de Empresas Arquitectura, Versin 0.1 Lnea de Base Tecnolgica de Arquitectura, Versin 0.1
Pgina85de670

TOGOF9.1
o o o o o o Arquitectura de datos de lnea de base, versin 0.1 Lnea de base de arquitectura de aplicaciones, versin 0.1 Objetivo Negocio Arquitectura, Versin 0.1 Tecnologa Target Arquitectura, Versin 0.1 Arquitectura de datos de destino, Versin 0.1 Objetivo de Arquitectura de aplicaciones, 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
8.4.1 Seleccin de modelos de referencia, puntos de vista y Herramientas

Seleccionar los recursos pertinentes Arquitectura Profesiones (modelos de referencia, patrones, etc) desde el repositorio de Arquitectura, sobre la base de los impulsores del negocio, y los grupos de 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 define en la Parte IV , 34. Metamodel contenido .
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 ). 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 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 .
8.4.5 Definir candidatos Componentes Hoja de Ruta

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
8.4.9 Crear Arquitectura Definicin de documento 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) Una descripcin detallada de las funciones de negocio y sus necesidades de informacin La huella de la gestin (mostrando mbito de control y rendicin de cuentas) Normas, reglas y directrices que muestran prcticas de trabajo, legislacin, medidas financieras, etc Una matriz de habilidades y un conjunto de descripciones de puestos
o o
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 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 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 o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado), si procede 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
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 o Los resultados del anlisis de Gap 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) Requisitos de negocio actualizados
Componentes de la arquitectura de negocios de una Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap )
Las salidas pueden incluir algunos o todos de los siguientes: Catlogos: o o o o o o o Catlogo de Organizacin / Actor Conductor / Meta / Objetivo catlogo Catlogo de funciones Catlogo de servicios de negocios / Funcin Ubicacin catlogo Proceso / Evento / Control / Catlogo de productos Catlogo Contract / Medida
Matrices: o o Matriz de interaccin de negocios Matriz Actor / Rol
Diagramas: o o o o o o Diagrama de Huella de negocios Diagrama de Business Service / Information Diagrama de descomposicin funcional Diagrama del ciclo de vida del producto Meta / Objetivo diagrama / Servicio Diagrama de casos de uso
Pgina94de670

TOGOF9.1
o o o Organizacin diagrama de descomposicin Diagrama de Flujo del Proceso 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 Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de 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.
Evaluacin de capacidades (vase la Parte IV , 36.2.10 Evaluacin de Capacidad ) Plan de comunicacin (ver la Parte IV , 36.2.12 Plan de Comunicaciones )
o o o o o o mbito de las organizaciones afectadas La evaluacin gestacional, lagunas, y el enfoque de resolucin Roles y responsabilidades de equipo de arquitectura (s) Las restricciones sobre el trabajo de arquitectura Necesidades presupuestarias Gobernabilidad y estrategia de apoyo
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 Arquitectura de Trabajo ) Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ) Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo: o o o Bloques de construccin reutilizables Modelos de referencia especficos de la organizacin Normas de la Organizacin
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o o o o o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado), si procede Objetivo Negocio Arquitectura, Version 1.0 (detallado) Arquitectura de datos de lnea de base, versin 0.1 Arquitectura de datos de destino, Versin 0.1 Lnea de base de arquitectura de aplicaciones, versin 0.1 Objetivo de Arquitectura de aplicaciones, Versin 0.1
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo: o o Los resultados del anlisis de Gap (de Arquitectura Empresarial) 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: 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
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o o o o Arquitectura de datos de lnea de base, versin 1.0 Arquitectura de datos de destino, Versin 1.0 Lnea de base de arquitectura de aplicaciones, versin 1.0 Objetivo de Arquitectura de aplicaciones, versin 1.0 Puntos de vista de arquitectura de datos correspondientes a los puntos de vista seleccionados abordar las principales preocupaciones de las partes interesadas Vistas Arquitectura Aplicacin correspondientes a los puntos de vista seleccionados abordar las preocupaciones de inters clave
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo dichos requisitos de Sistemas de Informacin Arquitectura como: o o Los resultados del anlisis de Gap Requisitos tcnicos pertinentes que se aplicarn a esta evolucin del ciclo de desarrollo de la arquitectura Las restricciones en la Arquitectura de Tecnologa a punto de ser diseados Requisitos de negocio actualizados, en su caso
o o
Componentes de los sistemas de informacin de una Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap )
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 Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de 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
10.3.3 Entradas arquitectnicos Modelo de organizacin de Arquitectura Empresarial (vase la Parte IV , 36.2.16 Modelo de Organizacin de Empresa de Arquitectura ), incluyendo:
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 Arquitectura de Trabajo ) Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ) Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo: o Bloques de construccin reutilizables (en particular, las definiciones de los datos actuales) Modelos de referencia disponibles al pblico Modelos de referencia especficos de la organizacin Normas de la Organizacin
o o o
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo:
Pgina102de670

TOGOF9.1
o o o o o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado), si procede Objetivo Negocio Arquitectura, Version 1.0 (detallado) Arquitectura de datos de lnea de base, Versin 0.1, si est disponible Arquitectura de datos de destino, Versin 0.1, si est disponible Lnea de base de arquitectura de aplicaciones, versin 1.0 (detallada) o Versin 0.1 (Vision) Objetivo de Arquitectura de aplicaciones, versin 1.0 (detallada) o Versin 0.1 (Vision) Lnea de Base Tecnolgica de Arquitectura, Version 0.1 (Vision) Tecnologa Target Arquitectura, Version 0.1 (Vision)
o o
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo: o o Los resultados del anlisis de Gap (de Arquitectura Empresarial) 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 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 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 . Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante el paso Finalizar la Arquitectura de Datos (ver 10.4.8 finalizar la Arquitectura de Datos ). La 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: 10.4.1 Seleccin de modelos de referencia, puntos de vista y Herramientas
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 10.4.5 Definir candidatos Componentes Hoja de Ruta 10.4.6 Impactos Resolver Across the Landscape Architecture Conducta 10.4.7 Stakeholder Formal Comentario 10.4.8 Finalizar la Arquitectura de Datos 10.4.9 Crear Arquitectura Definicin de documento

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
Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de vista especfico necesario, utilizando la herramienta o mtodo seleccionado.
Pgina104de670

TOGOF9.1
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 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 actan como un recurso clave para la gestin de la cartera de negocios y capacidad de TI. 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
Matrices muestran las relaciones bsicas entre las entidades del modelo relacionado.
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 perspectivas (puntos de vista) de acuerdo a los requisitos de las partes interesadas. Una vez que las entidades de datos se han refinado, un diagrama de las relaciones entre las entidades y sus atributos se puede producir. Es importante 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. Estos requisitos pueden: Se relacionan con el dominio de datos Proporcionar los requisitos de entrada en la aplicacin y Tecnologa Arquitecturas 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 ).
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 ). 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.
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 ). 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 destino.
10.4.4 Realizar el Anlisis Gap


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 definicin ms detallada de un plan de trabajo interdisciplinario consolidado dentro de las Oportunidades y fase Solutions.

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

TOGOF9.1
Hay oportunidades para aprovechar el trabajo de esta arquitectura de datos en otras reas de la organizacin? Impacta esta arquitectura de datos de otros proyectos (incluyendo los previstos, as como los actualmente en curso)? Esto Arquitectura de Datos verse afectado por otros proyectos (incluidos los previstos, as como los actualmente en curso)?
Conducta 10.4.7 Stakeholder Formal Comentario

Compruebe la motivacin original para el proyecto de la arquitectura y la Declaracin de 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 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 general de los requerimientos del 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 reutilizados, y publicar a travs del Repositorio de Arquitectura Finalice todos los productos de trabajo, tales como anlisis de las deficiencias
Pgina109de670

TOGOF9.1
Justificacin del documento para la construccin de bloquear decisiones en la definicin de documento Architecture. Preparar arquitectura de datos de secciones de la definicin de documento Arquitectura, que comprende algunos o todos de: Modelo de datos de negocios 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: Las versiones refinadas y actualizadas de los entregables de la fase Arquitectura Visin, en su caso: o Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ), actualizado en caso necesario Principios datos validados (vase la Parte III , 23.6.2 Datos Principios ), o nuevos principios de datos (si se generan aqu)
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o Arquitectura de datos de lnea de base, la versin 1.0, en su caso Arquitectura de datos de destino, Versin 1.0 o Modelo de datos de negocios Modelo de datos lgicos Modelos de procesos de gestin de datos Entity Data / matriz de funciones de negocios
Vistas correspondiente a los puntos de vista seleccionados abordar las principales preocupaciones de las partes interesadas
Pgina110de670

TOGOF9.1
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo dichos requisitos arquitectura de datos como: o o o Los resultados del anlisis de Gap Requisitos de interoperabilidad de datos Requisitos tcnicos pertinentes que se aplicarn a esta evolucin del ciclo de desarrollo de la arquitectura Las restricciones en la Arquitectura de Tecnologa a punto de ser diseados Requisitos de negocio actualizados, en su caso Requisitos de las aplicaciones actualizadas, en su caso
o o o
Componentes de la arquitectura de datos de una Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap )
Las salidas pueden incluir algunos o todos de los siguientes: Catlogos: o Catlogo de Entity Data / componente de datos
Matrices: o o Entity Data / matriz de funciones de negocios Aplicacin / matriz de datos
Diagramas: o o o o o o Diagrama conceptual de datos Diagrama de lgica de datos Diagrama de Divulgacin de Datos Diagrama de seguridad de datos Diagrama de migracin de datos 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 Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de 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. 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).
Principios de la aplicacin (ver la Parte III , 23.6.3 Principios de Aplicacin ), si existe Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ) Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ) Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo: o Bloques de construccin reutilizables
Pgina113de670

TOGOF9.1
o o o Modelos de referencia disponibles al pblico Modelos de referencia especficos de la organizacin Normas de la Organizacin
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado), si procede Objetivo Negocio Arquitectura, Version 1.0 (detallado) Arquitectura de lnea de base de datos, versin 1.0 (detallados), o la Versin 0.1 (Vision) Arquitectura Meta Data, versin 1.0 (detallados), o la Versin 0.1 (Vision) Lnea de base de arquitectura de aplicaciones, Versin 0.1, si est disponible adecuado y si Objetivo de Arquitectura de aplicaciones, Versin 0.1, si est disponible Lnea de Base Tecnolgica de Arquitectura, Version 0.1 (Vision) Tecnologa Target Arquitectura, Version 0.1 (Vision)
o o
o o o
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo: o Los resultados del anlisis de Gap (de Arquitectura de Negocios y Arquitectura de datos, si est disponible) 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 Parte III , 19. Aplicando la iteracin de la ADM .
Pgina114de670

TOGOF9.1
Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante el paso Finalizar la Arquitectura de la aplicacin (ver 11.4.8 finalizar la Arquitectura de la aplicacin ). La documentacin generada a partir de estas medidas debe ser publicada oficialmente en la Arquitectura paso Crear definicin de documento (ver 11.4.9 Crear Arquitectura Definicin de documento ). Los pasos en la Fase C (Arquitectura de aplicaciones) son las siguientes: 11.4.1 Seleccin de modelos de referencia, puntos de vista y Herramientas 11.4.2 Desarrollar Lnea Base Application Architecture Descripcin 11.4.3 Desarrollar Target Application Architecture Descripcin 11.4.4 Realizar el Anlisis Gap 11.4.5 Definir candidatos Componentes Hoja de Ruta 11.4.6 Impactos Resolver Across the Landscape Architecture Conducta 11.4.7 Stakeholder Formal Comentario 11.4.8 Finalizar la arquitectura de aplicaciones 11.4.9 Crear Arquitectura Definicin de documento

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. 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 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
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 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). Catlogos constituyen la materia prima para el desarrollo de matrices y diagramas, y tambin actan como un recurso clave para la gestin de la cartera de negocios y capacidad de TI. La estructura de catlogos se basa en los atributos de las entidades metamodelo, segn se define en la Parte IV , 34. Metamodel contenido .
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
Matrices muestran las relaciones bsicas entre las entidades del modelo relacionado. Las matrices son la materia prima para la elaboracin de diagramas y tambin actan como un recurso clave para la evaluacin del impacto. 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 perspectivas (puntos de vista) de acuerdo a los requisitos de las partes interesadas. 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. Estos requisitos pueden:
Pgina118de670

TOGOF9.1
Se relacionan con el dominio de aplicacin Proporcionar los requisitos de entrada en las arquitecturas de datos y tecnologa Proporcionar orientaciones detalladas que se refleja en el diseo e implementacin para asegurar que la solucin satisface los requisitos de arquitectura originales
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 ). 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.
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 ). 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 destino.

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
Pgina119de670

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

Despus de la creacin de una arquitectura de referencia, Arquitectura objetivo y anlisis de 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 definicin ms detallada de un plan de trabajo interdisciplinario consolidado dentro de las Oportunidades y fase Solutions.

Una vez que la arquitectura de la aplicacin se finaliza, es necesario entender los impactos o repercusiones ms amplias. En esta etapa, otros artefactos de arquitectura en la arquitectura del paisaje deben ser examinados para identificar: Crea esta arquitectura de aplicaciones un impacto en las arquitecturas preexistentes? Se han hecho los cambios recientes que impactan la arquitectura de aplicaciones? Hay oportunidades para aprovechar el trabajo de esta arquitectura de aplicaciones en otras reas de la 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)?

Compruebe la motivacin original para el proyecto de la arquitectura y la Declaracin de 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 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 general de los requerimientos del 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 reutilizados, y publicar a travs del Repositorio de Arquitectura Finalice todos los productos de trabajo, tales como anlisis de las deficiencias
11.4.9 Crear Arquitectura Definicin de documento Justificacin del documento para la construccin de bloquear decisiones en la definicin de 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: Las versiones refinadas y actualizadas de los entregables de la fase Arquitectura Visin, en su caso: o Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ), actualizado en caso necesario Principios de aplicacin validados, o nuevos principios de aplicacin (si se generan aqu)
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o Lnea de base de arquitectura de aplicaciones, la versin 1.0, en su caso Objetivo de Arquitectura de aplicaciones, versin 1.0 Modelo de sistemas de proceso Modelo de sistemas Place Tiempo modelo de sistemas
Pgina121de670

TOGOF9.1
o Modelo de sistemas Gente
Vistas correspondiente a los puntos de vista seleccionados, abordar las preocupaciones de inters clave
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo dichos requisitos arquitectura de aplicaciones como: o o o Los resultados del anlisis de Gap Aplicaciones requisitos de interoperabilidad Requisitos tcnicos pertinentes que se aplicarn a esta evolucin del ciclo de desarrollo de la arquitectura Las restricciones en la Arquitectura de Tecnologa a punto de ser diseados Requisitos de negocio actualizados, en su caso Requisitos de datos actualizadas, en su caso
o o o
Componentes de la arquitectura de aplicacin de una Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap )
Las salidas pueden incluir algunos o todos de los siguientes: Catlogos: o o Catlogo de la cartera de aplicaciones Catlogo de interfaz
Matrices: o o o o Aplicacin de la matriz / Organizacin Matriz de Papel / Aplicacin Matriz de Aplicacin / Funcin Matriz de interaccin Aplicacin
Diagramas: o o o o o Diagrama de comunicaciones de la aplicacin Aplicacin y usuario diagrama Ubicacin Esquema de aplicacin de casos de uso Diagrama de administracin de Enterprise Diagrama Realizacin de proceso / aplicacin
Pgina122de670

TOGOF9.1
o o o Software diagrama de Ingeniera Diagrama de Migracin de aplicaciones 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 Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de 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 V , 41. Arquitectura del repositorio ). 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
o o mbito de las organizaciones afectadas La evaluacin gestacional, lagunas, y el enfoque de resolucin
Pgina125de670

TOGOF9.1
o o o o Roles y responsabilidades de equipo de arquitectura (s) Las restricciones sobre el trabajo de arquitectura Necesidades presupuestarias Gobernabilidad y estrategia de apoyo
Principios Tecnologa (ver Parte III , Principios Tecnolgicos 23.6.4 ), si existe Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ) Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ) Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo: o o o o Bloques de construccin reutilizables Modelos de referencia disponibles al pblico Modelos de referencia especficos de la organizacin Normas de la Organizacin
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o o o o o o o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado) Target Business Architecture Version 1.0 (detallado) Arquitectura de datos de lnea de base, versin 1.0 (detallado) Arquitectura de datos de destino, Versin 1.0 (detallado) Lnea de base de arquitectura de aplicaciones, versin 1.0 (detallado) Objetivo de Arquitectura de aplicaciones, versin 1.0 (detallado) Lnea de Base Tecnolgica de Arquitectura, Versin 0.1 (la visin) Tecnologa Target Arquitectura, Versin 0.1 (la visin)
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo:
Pgina126de670

TOGOF9.1
o Los resultados del anlisis de Gap (de negocios, datos, y aplicacin de arquitecturas) 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 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 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 . 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 documentacin generada a partir de estas medidas debe ser publicada oficialmente en la Arquitectura paso Crear definicin de documento (ver 12.4.9 Crear Arquitectura Definicin de documento ). Los pasos en la Fase D son como sigue: 12.4.1 Seleccin de modelos de referencia, puntos de vista y Herramientas 12.4.2 Desarrollar Lnea de Base Tecnolgica Arquitectura Descripcin 12.4.3 Desarrollar Tecnologa Target Arquitectura Descripcin 12.4.4 Realizar el Anlisis Gap 12.4.5 Definir candidatos Componentes Hoja de Ruta 12.4.6 Impactos Resolver Across the Landscape Architecture Conducta 12.4.7 Stakeholder Formal Comentario 12.4.8 Finalizar la Arquitectura Tecnologa 12.4.9 Crear Arquitectura Definicin de documento
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. 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 requerido, stos pueden comprender documentos y hojas de clculo simples, o herramientas de modelado ms sofisticadas y tcnicas.
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 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 o Refinar la taxonoma 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 o La planificacin de capacidad 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). Catlogos constituyen la materia prima para el desarrollo de matrices y diagramas, y tambin actan como un recurso clave para la gestin de la cartera de negocios y capacidad de TI. 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
Matrices muestran las relaciones bsicas entre las entidades del modelo relacionado. Las matrices son la materia prima para la elaboracin de diagramas y tambin actan como un recurso clave para la evaluacin del impacto. 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 perspectivas (puntos de vista) de acuerdo a los requisitos de las partes interesadas. 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. Estos requisitos pueden: Se relacionan con el dominio de la tecnologa Proporcionar orientaciones detalladas que se refleja en el diseo e implementacin para asegurar que la solucin satisface los requisitos de arquitectura originales
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 preexistentes (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. 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.
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 V , 41. Arquitectura del repositorio ).
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 . 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 destino.


Despus de la creacin de una arquitectura de referencia, Arquitectura objetivo y anlisis de 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 definicin ms detallada de un plan de trabajo interdisciplinario consolidado dentro de las Oportunidades y fase Solutions.

Una vez que la Tecnologa de la Arquitectura est finalizado, es necesario entender los impactos o repercusiones ms amplias. En esta etapa, otros artefactos de arquitectura en la arquitectura del paisaje deben ser examinados 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 reas de la organizacin? Impacta esta Arquitectura Tecnolgica otros proyectos (incluidos los previstos, as como los actualmente en curso)? Esto Arquitectura Tecnologa verse afectado por otros proyectos (incluidos los previstos, as como los actualmente en curso)?

Compruebe la motivacin original para el proyecto de la arquitectura y la Declaracin de 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 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 anlisis de las deficiencias

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: Las versiones refinadas y actualizadas de los entregables de la fase Arquitectura Visin, en su caso: o Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ), actualizado en caso necesario Principios tecnolgicos validados, o nuevos principios tecnolgicos (si se generan aqu)
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: 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 o
Lnea de Base Tecnolgica de Arquitectura, Version 1.0 (detallado), si procede Vistas correspondiente a los puntos de vista seleccionados abordar las principales preocupaciones de las partes interesadas
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo dichos requisitos Arquitectura Tecnologa como: o o o Los resultados del anlisis de Gap Requisitos de salida de las fases B y C Requisitos tecnolgicos actualizados
Pgina135de670

TOGOF9.1
Componentes Arquitectura de Tecnologa de la Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap )
Las salidas pueden incluir algunos o todos de los siguientes: Catlogos: o o Catlogo de Normas de Tecnologa Catlogo Cartera Tecnolgica
Matrices: o Matriz de Aplicacin / Tecnologa
Diagramas: o o o o o Ambientes y zonas diagrama Diagrama de descomposicin Plataforma Diagrama de Procesamiento Diagrama de Red Informtica / Hardware 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
Pgina138de670

TOGOF9.1
Evaluacin de capacidades (vase la Parte IV , 36.2.10 Evaluacin de Capacidad ) Plan de comunicacin (ver la Parte IV , 36.2.12 Plan de Comunicaciones ) Metodologas de planificacin
Los modelos de gobernanza y los marcos para: o o o o o Planificacin Ejecutiva Arquitectura Empresarial Portafolio, Programa, Gestin de Proyectos Desarrollo de Sistemas / Ingeniera Operaciones (Servicio)
Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ) Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ) Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo: o o o Bloques de construccin reutilizables Modelos de referencia disponibles al pblico Modelos de referencia especficos de la organizacin
Pgina139de670

TOGOF9.1
o Normas de la Organizacin
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o o o o o o o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado) Objetivo Negocio Arquitectura, Version 1.0 (detallado) Arquitectura de datos de lnea de base, versin 1.0 (detallado) Arquitectura de datos de destino, Versin 1.0 (detallado) Lnea de base de arquitectura de aplicaciones, versin 1.0 (detallado) Objetivo de Arquitectura de aplicaciones, versin 1.0 (detallado) Lnea de Base Tecnolgica de Arquitectura, Version 1.0 (detallado) Tecnologa Target Arquitectura, Version 1.0 (detallado)
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo: o o Requisitos arquitectnicos Los resultados del anlisis de Gap (de negocios, datos, aplicaciones, y Arquitectura de Tecnologa) 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 formalmente y completaron deben adaptarse a la situacin en cuestin de acuerdo con el gobierno arquitectura establecida. Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante el paso de crear la Arquitectura Roadmap e 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 Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ), actualizado en caso necesario
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o o o o Lnea de base de Empresas Arquitectura, versin 1.0 actualiza si es necesario Objetivo Negocio Arquitectura, versin 1.0 actualiza si es necesario Arquitectura de datos de lnea de base, versin 1.0 actualiza si es necesario Arquitectura de datos de destino, versin 1.0 actualiza si es necesario Lnea de base de arquitectura de aplicaciones, la versin 1.0 actualiza si es necesario
Pgina145de670

TOGOF9.1
o o Objetivo de Arquitectura de aplicaciones, la versin 1.0 actualiza si es necesario Lnea de Base Tecnolgica de la Arquitectura, la versin 1.0 actualiza si es necesario Tecnologa Target Arquitectura, versin 1.0 actualiza si es necesario Arquitectura de transicin, el nmero y el alcance que sea necesario Vistas correspondiente a los puntos de vista seleccionados abordar las principales preocupaciones de las partes interesadas
o o o
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo: o Brechas consolidados, soluciones y Dependencias de Evaluacin
Evaluaciones de capacidad, entre ellos: o o Evaluacin de la capacidad del negocio Evaluacin de Capacidad de TI
Arquitectura Roadmap (ver la Parte IV , 36.2.7 Arquitectura Roadmap ), incluyendo: o Cartera Paquete de trabajo: o 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
Identificacin de Transicin Arquitecturas, en su caso, incluyendo: Relacin a la Arquitectura de definicin de documento
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
Las salidas pueden incluir algunos o todos de los siguientes: Diagramas: o o Diagrama de Contexto del Proyecto 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.
Los modelos de gobernanza y los marcos para: o Planificacin Ejecutiva
Pgina149de670

TOGOF9.1
o o o o Arquitectura Empresarial Portafolio, Programa, Gestin de Proyectos Desarrollo de Sistemas / Ingeniera Operaciones (Servicio)
Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ) Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ) Arquitectura repositorio (vase la Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo: o o o o Bloques de construccin reutilizables Modelos de referencia disponibles al pblico Modelos de referencia especficos de la organizacin Normas de la Organizacin
Proyecto de Arquitectura de definicin de documento (ver la Parte IV , 36.2.3 Arquitectura de definicin de documento ), incluyendo: o o o o o o o o o Lnea de base de Empresas Arquitectura, Version 1.0 (detallado) Objetivo Negocio Arquitectura, Version 1.0 (detallado) Arquitectura de datos de lnea de base, versin 1.0 (detallado) Arquitectura de datos de destino, Versin 1.0 (detallado) Lnea de base de arquitectura de aplicaciones, versin 1.0 (detallado) Objetivo de Arquitectura de aplicaciones, versin 1.0 (detallado) Lnea de Base Tecnolgica de Arquitectura, Version 1.0 (detallado) Tecnologa Target Arquitectura, Version 1.0 (detallado) Arquitecturas de transicin, si los hay
Proyecto de Arquitectura Especificacin de Requisitos (vase la Parte IV , 36.2.6 Arquitectura especificacin de requisitos ), incluyendo:
Pgina150de670

TOGOF9.1
o o Requisitos arquitectnicos Los resultados del anlisis de Gap (de negocios, datos, aplicaciones, y Arquitectura de Tecnologa) 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 o o Identificacin de los paquetes de trabajo Identificacin de transicin Arquitecturas Evaluacin Factor Implementacin y Matrix Deduccin
Evaluacin de capacidades (vase la Parte IV , Evaluacin 36.2.10 Capability ), incluyendo: o o Evaluacin de la capacidad del negocio 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 formalmente y completaron deben adaptarse a la situacin en cuestin de acuerdo con el gobierno arquitectura establecida. Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante las clases completar el ciclo de desarrollo de la arquitectura y documentar paso aprendido (ver 14.4.7 completar el ciclo de desarrollo de la arquitectura y de documentar las lecciones aprendidas ). Los pasos en la Fase F son como sigue: 14.4.1 Confirmar Management Framework Interacciones para la 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 o Implementacin y Estrategia de migracin 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
o Hitos y calendario Estructura de desglose del trabajo
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
Evaluacin de capacidades (vase la Parte IV , 36.2.10 Evaluacin de Capacidad )
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 Requisitos arquitectnicos
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 ) Solicitud de Arquitectura de trabajo (vase la Parte IV , 36.2.17 Solicitud 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 formalmente y completaron deben adaptarse a la situacin en cuestin de acuerdo con el gobierno arquitectura establecida. Los pasos en la Fase G son como sigue: 15.4.1 Confirmar alcance y las prioridades para la 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 o Alcance del documento de proyecto individual en el anlisis del impacto Documentar las necesidades estratgicas (desde el punto de vista arquitectnico) en el anlisis de impacto Las solicitudes de cambio de documento (como el soporte para una interfaz estndar) en el anlisis de impacto Reglas del documento para la conformidad en el anlisis del impacto Requisitos de la lnea de tiempo del documento de hoja de ruta en materia de anlisis de impacto
o o
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 o o o o o o
Poblado Repositorio Arquitectura Recomendaciones Arquitectura de cumplimiento y dispensas Recomendaciones sobre los requisitos de prestacin de servicios Recomendaciones sobre las medidas de rendimiento Acuerdos de Nivel de Servicio (SLAs) Architecture Vision, posterior a la ejecucin de actualizacin Arquitectura Definicin de documento, posterior a la ejecucin de actualizacin 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.
Pgina169de670

TOGOF9.1
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) Requisitos arquitectnicos
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 o o o Informes Nueva tecnologa Iniciativas de reduccin de costes de gestin de activos Informes de abstinencia Tecnologa Las iniciativas de estandarizacin
Solicitud de cambio (vase la Parte IV , 36.2.11 Solicitud de cambio ), - los cambios del negocio: o o o o o Evolucin de los negocios Excepciones empresariales Innovaciones empresariales Innovaciones tecnolgicas de negocios 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 formalmente y completaron deben adaptarse a la situacin en cuestin de acuerdo con el gobierno arquitectura establecida. 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) Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ), actualizado en caso necesario 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 ), 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
Pgina176de670

TOGOF9.1
o o o o o La evaluacin gestacional, lagunas, y el enfoque de resolucin Roles y responsabilidades de equipo de arquitectura (s) Las restricciones sobre el trabajo de arquitectura Necesidades presupuestarias Gobernabilidad y estrategia de apoyo
Declaracin de Arquitectura de trabajo (vase la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo ) Architecture Vision (vase la Parte IV , 36.2.8 Architecture Vision ) 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 Paso 1 Paso Requisitos de referencia: 2 a. Determine las prioridades que surgen de la fase actual de ADM b. Confirme los interesados buy-in a las prioridades resultantes c. Registros Requisitos prioridades y lugar en ADM Fase Pasos Identificar los requisitos / documentos - utilizar escenarios de negocios, o una tcnica anloga
Pgina177de670

TOGOF9.1
Requisitos Repositorio Paso Monitorear los requisitos bsicos 3 Paso 4
Identificar requisitos modificados: 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. a. Evaluar el impacto de las nuevas exigencias de la fase actual (activo) b. Evaluar el impacto de las nuevas exigencias en las fases anteriores . c Determinar si se debe implementar el cambio, o diferir el ciclo ADM despus; si la
Paso 6
Pgina178de670

TOGOF9.1
decisin es implementar, evaluar Cronograma de implantacin de gestin del cambio d. Declaracin de Impacto Requisitos Edicin, Versin n 1 Paso 7 Implementar los requisitos derivados de la Fase H 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

TOGOF9.1
PARTEIII DirectricesyTcnicas deADM

Pgina181de670

TOGOF9.1
18. Introduccin
Este captulo proporciona una visin general de los contenidos de la parte III .
18.1 Pautas para adaptar el proceso de ADM

El proceso de Arquitectura Mtodo de Desarrollo (ADM) se pueden adaptar para hacer frente a una serie de diferentes escenarios de uso, incluyendo diferentes estilos de proceso (por ejemplo, el uso de la iteracin) y tambin las arquitecturas especializadas especficas (como la seguridad). Directrices incluidos dentro de esta parte de TOGAF son los siguientes: La aplicacin de la iteracin a la ADM (vase 19. Aplicando la iteracin a la ADM ) discute el concepto de iteracin y muestra las posibles estrategias para la aplicacin de conceptos iterativos a la ADM. La aplicacin de la ADM a travs de la arquitectura del paisaje (ver 20. Aplicando la ADM a travs de la Arquitectura del Paisaje ) discute los diferentes tipos de participacin de arquitectura que pueden ocurrir en diferentes niveles de la empresa. Esta seccin tambin discute a continuacin, cmo el proceso de ADM se puede enfocar para soportar diferentes tipos de compromiso. Arquitectura de Seguridad y la ADM (vase 21. Arquitectura de Seguridad y el ADM ) proporciona una visin general de las consideraciones especficas de seguridad que deben tenerse en cuenta durante las diferentes fases de la ADM. Usando TOGAF para definir y Gobierno SOAs (ver 22. Uso TOGAF para definir y Gobierno SOAs ) muestra cmo los conceptos de SOA pueden ser apoyadas por el marco TOGAF y las consideraciones SOA especficos para las diferentes fases de la ADM.
18.2 Tcnicas para el Desarrollo de la Arquitectura

Las siguientes tcnicas se describen en la Parte III: Directrices y Tcnicas de ADM para apoyar tareas especficas dentro de la ADM: Arquitectura Principios (ver 23 Arquitectura Principios. ) - los principios para la utilizacin y el despliegue de los recursos de TI en toda la empresa - Describe cmo desarrollar el conjunto de normas y directrices para la arquitectura se desarrolla en general. Gestin de los interesados (vase 24. Gestin de las partes interesadas ) describe la Administracin de los interesados, una disciplina importante que los profesionales de la arquitectura de xito puede utilizar para ganar apoyo para sus proyectos. Arquitectura Patrones (ver 25. Arquitectura Patrones ) proporciona orientacin sobre el uso de patrones de arquitectura. Escenarios empresariales (vase 26. Escenarios empresariales y objetivos de la empresa ) se describe la tcnica de escenarios empresariales, un mtodo para derivar los requisitos de negocio para la arquitectura y los requisitos tcnicos implicados.
Pgina182de670

TOGOF9.1
Anlisis de Vacos (ver 27. Anlisis Gap ) describe la tcnica conocida como anlisis de brechas. Es ampliamente utilizado en el TOGAF ADM para validar una arquitectura que se est desarrollando. Tcnicas de Planificacin Migraciones (ver Tcnicas de Planificacin 28. Migracin ) describe una serie de tcnicas para apoyar la planificacin de la migracin en las fases E y F. Requisitos de interoperabilidad (vase 29. Requisitos de interoperabilidad ) describe una tcnica para determinar los requisitos de interoperabilidad. Evaluacin de la preparacin de transformacin de negocios (vase 30. Empresas Evaluacin de la preparacin de Transformacin ) describe una tcnica para la identificacin de problemas de transformacin empresarial. Gestin del Riesgo (ver 31. Gestin de Riesgos ) describe una tcnica para la gestin de riesgos durante un proyecto de transformacin de la arquitectura / negocio. Capacidad basada en Planificacin (ver 32. Planificacin de Capacidad basada ) describe la tcnica de la planificacin basada en la capacidad.
18.3 Uso de TOGAF con diferentes estilos arquitectnicos

TOGAF est diseado para ser flexible y puede ser utilizado con diversos estilos arquitectnicos. Esta parte de TOGAF incluye dos captulos que pretenden ser ejemplos tiles. Arquitectura de Seguridad y la ADM (vase 21. Arquitectura de Seguridad y el ADM ) Usando TOGAF para definir y Gobierno SOAs (ver 22. Uso TOGAF para definir y Gobierno SOAs )
Los estilos arquitectnicos se diferencian en trminos de enfoque, la forma, las tcnicas, los materiales, el asunto y el perodo de tiempo. Algunos estilos pueden ser considerados como de moda, otros se centraron en aspectos particulares de la arquitectura empresarial. TOGAF es un marco genrico y destinado a ser utilizado en una amplia variedad de entornos. Es un marco flexible y extensible que se puede adaptar fcilmente a un nmero de estilos arquitectnicos. Arquitectura del Paisaje de una organizacin se puede esperar para contener obra de arquitectura que se desarrolla en diversos estilos arquitectnicos. TOGAF asegura que las necesidades de cada grupo de inters se abordan adecuadamente en el contexto de otras partes interesadas y la Arquitectura de Referencia. Al usar TOGAF para apoyar un estilo arquitectnico especfico el profesional debe tener en cuenta la combinacin de caractersticas distintivas en que se realiza o se expresa la arquitectura. Como primera medida, los rasgos distintivos de un estilo deben ser identificados. Por ejemplo, la definicin de Open Group para SOA identifica las siguientes caractersticas distintivas: Se basa en el diseo de los servicios - que reflejan las actividades empresariales del mundo real - que comprenden la empresa (o entre empresas) los procesos de negocio.
Pgina183de670

TOGOF9.1
Representacin del Servicio utiliza descripciones empresariales para proporcionar el contexto (es decir, los procesos de negocio, meta, regla, poltica, interfaz de servicio, y el componente de servicio) e implementa servicios utilizando la orquestacin de servicios. Coloca los requisitos nicos de la infraestructura -, se recomienda que las implementaciones utilizan estndares abiertos para darse cuenta de la interoperabilidad y la transparencia de ubicacin. Las implementaciones son favorables al medio especfico - se ven limitados o habilitadas por el contexto y deben ser descritas dentro de ese contexto.
El segundo paso es determinar cmo se abordarn estas caractersticas distintivas. Dirigindose a un estilo distintivo no debe pedir cambios significativos en TOGAF; sino que debe ajustar los modelos, puntos de vista y las herramientas utilizadas por el profesional. En la fase B, fase C y la fase D se espera que el practicante para seleccionar los recursos arquitectura pertinentes, incluidos los modelos, puntos de vista y herramientas, para describir adecuadamente el dominio arquitectura y demostrar que las preocupaciones de los interesados se dirigen (ver Parte II , 8.4.1 Seleccionar modelos de referencia, puntos de vista y las herramientas , 10.4.1 Seleccin de modelos de referencia, puntos de vista y las herramientas , 11.4.1 Seleccin de modelos de referencia, puntos de vista y las herramientas , y 12.4.1 Seleccin de modelos de referencia, puntos de vista y herramientas ). Dependiendo de las caractersticas distintivas, diferentes estilos arquitectnicos aadirn nuevos elementos que se har una descripcin, resalte los elementos existentes, ajuste la notacin utilizada para describir la arquitectura, y el enfoque del arquitecto en algunos grupos de inters o preocupacin de las partes interesadas. Dirigindose a los rasgos distintivos suele incluir extensiones al Metamodel Arquitectura de contenidos y el uso de la notacin especfica o tcnicas de modelado y la identificacin de puntos de vista. Si el estilo es dominante determinar si es necesario volver a examinar la Etapa Preliminar y realizar cambios en la capacidad de Arquitectura o si el apoyo a la caracterstica distintiva es posible en el mbito de la seleccin se espera dentro de un solo ciclo de ADM. Modelos de referencia-estilo especfico y modelos de madurez son herramientas que apoyan a un practicante de uso comn. Con el tiempo se espera que los nuevos estilos arquitectnicos que surjan para abordar los problemas clave que enfrentan los practicantes. Algunos estilos estarn transitoria, algunos se aguantan en un nicho, y algunos se funden en la corriente principal. Existen los Foros Open Group y Grupos de Trabajo para abordar los desafos que enfrenta la industria. Estos organismos producen una amplia gama de material que sea til a una practicante interesado en adaptar TOGAF, o un ciclo de ADM en particular, a un estilo arquitectnico particular para los materiales actuales, incluyendo libros blancos y normas aplicables (ver www.opengroup.org/ togaf_docs ).
Pgina184de670

TOGOF9.1
19. La aplicacin de iteracin para el ADM 19.1 Informacin general

La representacin grfica de la TOGAF ADM, como se muestra en la Figura 5-1 , y la descripcin de las fases de ADM discretamente en orden en la Parte II , se puede leer que implica una metodologa de cascada determinista. Este mtodo se proporciona de presentacin para el propsito de comunicar rpidamente los conceptos bsicos de desarrollo de la arquitectura y la arquitectura del ciclo de vida. En la prctica, dos conceptos clave se utilizan para gestionar la complejidad del desarrollo de una empresade arquitectura y gestin de su ciclo de vida - la iteracin y los niveles (vase . 20 La aplicacin de la ADM a travs de la arquitectura del paisaje .) Los dos conceptos estn estrechamente vinculados. El ADM es compatible con una serie de conceptos que se caracterizan como iteracin. En primer lugar, la iteracin describe el proceso tanto de la descripcin de un Arquitectura del Paisaje integral a travs de mltiples ciclos de ADM sobre la base de iniciativas individuales ligados al mbito de la Solicitud de Arquitectura Obra. En segundo lugar, la iteracin describe el proceso integrado de desarrollo de una arquitectura en la que las actividades descritas en las diferentes fases de ADM interactan para producir una arquitectura integrada. Con el fin de describir de manera concisa la actividad y salidas, esta ltima iteracin se describe en trminos secuenciales. En tercer lugar, la iteracin describe el proceso de gestin del cambio a la Arquitectura de Capacidad de la organizacin. Iteracin para desarrollar una arquitectura de paisaje integral: Proyectos ejercern a travs de todo el ciclo de ADM, comenzando con la Fase A. Cada ciclo de la ADM estar obligado por una Solicitud de Arquitectura Obra. La salida de la arquitectura rellenar la Arquitectura del Paisaje, ya sea ampliando el panorama descrito, o cambiando el paisaje en el que se requiera. Proyectos separados pueden operar sus propios ciclos de ADM al mismo tiempo, con las relaciones entre los diferentes proyectos. Un proyecto puede desencadenar el inicio de otro proyecto. Normalmente, esto se usa cuando las iniciativas de arquitectura de alto nivel a identificar oportunidades o soluciones que requieren una arquitectura ms detallada, o cuando un proyecto identifica impactos paisajsticos fuera del alcance de su solicitud de Arquitectura Obra.
La iteracin dentro de un ciclo de ADM (iteracin Arquitectura Desarrollo): Los proyectos pueden operar mltiples fases ADM simultneamente. Normalmente, esto se utiliza para gestionar la interrelacin entre la arquitectura de negocio, Sistemas de Informacin Arquitectura, Arquitectura y Tecnologa. Proyectos puede realizar un ciclo entre las fases de ADM, en ciclos planificados abarcan mltiples fases. Normalmente, esto se usa para converger en una arquitectura detallada Target cuando la arquitectura de alto nivel no existe para proporcionar contexto y restriccin. Los proyectos pueden volver a etapas anteriores con el fin de crculo hacia atrs y actualizar los productos de trabajo con la nueva informacin. Normalmente, esto se usa
Pgina185de670

TOGOF9.1
para converger en un ejecutable Arquitectura Roadmap o Ejecucin y Plan de Migracin, cuando los detalles de la implementacin y el alcance del cambio desencadenan un cambio o re-priorizacin de necesidades de los interesados. Iteracin para gestionar la Arquitectura Capability (Capacidad Arquitectura iteracin): Los proyectos pueden requerir una nueva iteracin de la Fase Preliminar (re) establecer los aspectos de la capacidad Arquitectura identificados en la Fase A a dirigir una solicitud de Arquitectura Obra. Los proyectos pueden requerir una nueva iteracin de la Fase Preliminar para ajustar Arquitectura Capacidad de la organizacin como resultado de la identificacin de requisitos nuevos o modificados para Arquitectura capacidad como resultado de una solicitud de cambio en la Fase H.
19.2 Iteracin Ciclos

Los ciclos de iteracin sugeridas para el TOGAF ADM se muestran en la Figura 19-1 , y se pueden utilizar de manera efectiva a los grupos relacionados con actividades de arquitectura para lograr un propsito especfico. Estos ciclos de iteracin se hace referencia en 19.3 Clases de Arquitectura de compromiso y 19,5 iteracin Consideraciones .
Figura191:ciclosdeiteracin
Pgina186de670

TOGOF9.1
Arquitectura Capacidad iteraciones apoyan la creacin 1 y la evolucin de la capacidad Arquitectura necesario. Esto incluye la movilizacin inicial de la actividad de la arquitectura para un propsito o una arquitectura de tipo de compromiso dado al establecer o ajustar el enfoque de la arquitectura, los principios, el alcance, la visin y la gobernabilidad. Arquitectura de Desarrollo iteraciones permiten la creacin de contenido de la arquitectura por el ciclismo a travs de, o integrar, Negocios, Sistemas de Informacin y Tecnologa de la Arquitectura fases. Estas iteraciones asegurar que la arquitectura se considera como un todo. En este tipo de comentarios de las partes interesadas iteracin son tpicamente ms amplio. A medida que las iteraciones convergen en un objetivo, extensiones en las oportunidades y soluciones y las fases de planeamiento de migracin de asegurar que aplicabilidad de la arquitectura se considera que la arquitectura est finalizado. Planificacin de Transicin iteraciones apoyan la creacin de hojas de ruta del cambio formales para una arquitectura definida. Arquitectura de Gobierno iteraciones apoyar la gobernabilidad de la actividad de cambio avanzar hacia una Arquitectura objetivo definido.
19.3 Clases de Arquitectura de compromiso

Una funcin o servicios de organizacin de la arquitectura puede ser llamado para ayudar a una empresa en una serie de contextos diferentes, como las arquitecturas desarrolladas pueden variar de resumen al detalle, amplia cobertura estrecha, y el estado actual de estado futuro. En estos contextos, el concepto de iteracin se debe utilizar en el desarrollo de la arquitectura. Por lo general, hay tres reas de participacin para los arquitectos: Identificacin de Cambio Requerido : Fuera del contexto de cualquier iniciativa de cambio, la arquitectura puede ser utilizado como una tcnica para proporcionar la mayor visibilidad de la capacidad de TI con el fin de apoyar la toma de decisiones y la alineacin de la ejecucin estratgica. Definicin de Cambio : Dnde se ha identificado la necesidad de cambiar, la arquitectura puede ser utilizado como una tcnica para definir la naturaleza y el alcance de los cambios de una manera estructurada. Dentro de las iniciativas de cambio gran escala, las arquitecturas pueden ser desarrollados para proporcionar informacin detallada Arquitectura Definicin de las iniciativas de cambio que estn delimitadas por el mbito de un programa o cartera. Implementacin del Cambio : Arquitectura en todos los niveles de la empresa puede ser utilizado como una tcnica para proporcionar la gobernabilidad de diseo para cambiar iniciativas, proporcionando visibilidad panorama general, el suministro de las limitaciones estructurales, y la definicin de los criterios sobre los que evaluar las decisiones tcnicas.
Figura 19-2 y la tabla siguientes muestran las clases de arquitectura de la participacin de la empresa.
Pgina187de670

TOGOF9.1
Figura192:Clasesdearquitecturaempresarialdecompromiso
Cada uno de estos tipos de compromiso de la arquitectura se describe en la siguiente tabla.
rea de Compromiso Identificacin de Cambio Requerido Arquitectura Compromiso Apoyo a Estrategia de Negocios Descripcin Como las estrategias de negocio, objetivos, metas y de cambio de conductores, es necesario para que la empresa cambie con el fin de mantener la alineacin. La creacin de nuevas estrategias de negocio puede ser apoyado por la arquitectura empresarial a travs de:

Architectural Gestin de la cartera del Paisaje
Proporcionar visibilidad de las oportunidades de cambio Proporcionar elaboracin en los impactos prcticos de una eleccin estratgica particular, Ofrecer pruebas sobre la viabilidad o la viabilidad de una direccin estratgica particular,
Es una prctica comn en las grandes organizaciones para una organizacin de gestin de servicios para proporcionar informacin operativa y de gestin de la cartera de TI. Arquitectura empresarial puede aadir una nueva dimensin a los informes de gestin de servicios, mediante el apoyo a la vinculacin entre el rendimiento operativo y la necesidad estratgica de TI. Uso de la trazabilidad entre TI y el negocio inherente a la arquitectura empresarial, es posible evaluar la cartera de TI
Pgina188de670

TOGOF9.1
frente a los datos de rendimiento operacional y las necesidades del negocio (por ejemplo, el coste, la funcionalidad, la disponibilidad, la capacidad de respuesta) para determinar las reas donde est ocurriendo la desalineacin y el cambio tiene que tener lugar. Es una prctica comn en las grandes organizaciones para una organizacin de gestin de programas para proporcionar informacin operativa y de gestin de la cartera de cambio. Arquitectura empresarial puede aadir una nueva dimensin a los informes de gestin de cartera de proyectos, mediante el apoyo a la vinculacin entre el alcance del proyecto, el impacto arquitectnico y el valor del negocio. Factores arquitectnicos se pueden aadir a otros factores cuantitativos de proyectos para apoyar la toma de decisiones estratgicas en la prioridad del proyecto y los niveles de financiacin. Definicin de Cambio Architectural Definicin de Iniciativas de cambio fundacionales son los esfuerzos de Fundacionales iniciativas de cambio que tienen un objetivo conocido, pero no son cambio estrictamente cuyo mbito o delimitadas por una visin o requisitos compartida. En las iniciativas de cambio fundamentales, la prioridad inicial es comprender la naturaleza del problema y de una estructura a la definicin del problema. Una vez que el problema se entiende de manera ms eficaz, es posible definir soluciones apropiadas y para alinear las partes interesadas en torno a una visin y un propsito comn. Iniciativas de cambio delimitadas son los esfuerzos de cambio que por lo general surgen como el resultado de una estrategia antes de arquitectura, la evaluacin o la visin.
Architectural Gestin de Cartera de Proyectos
Architectural Definicin de Iniciativas de Cambio delimitadas
En las iniciativas de cambio acotadas, el resultado deseado ya est entendido y acordado. El foco de los esfuerzos de arquitectura en esta clase de compromiso es elaborar eficazmente una solucin de lnea base que responda a las necesidades identificadas, problemas, los controladores y las restricciones. Implementacin del Gobernanza arquitectnico Una vez que un modelo de solucin arquitectnica ha sido Cambio de Cambio Implementacin definida, proporciona una base para el diseo y la implementacin. Con el fin de garantizar que los objetivos y el valor de la arquitectura definida se realizan adecuadamente, es necesario para la continuacin de la gobernanza arquitectura del proceso de implementacin para facilitar la revisin del diseo, la arquitectura refinamiento, y el problema de ampliacin.
Pgina189de670

TOGOF9.1
Las diferentes clases de participacin arquitectura en diferentes niveles de la empresa requerirn atencin en reas especficas, como se muestra a continuacin.
Ciclos de Enfoque Alcance iteracin Focus Apoyo a Estrategia de Negocios Arquitectura Amplio, consideracin superficial dado a la arquitectura del Capability paisaje a fin de abordar una cuestin estratgica especfica y definir los trminos de los esfuerzos ms detallados de arquitectura para hacer frente a la estrategia de realizacin. Arquitectura Desarrollo (Lnea de base primero) Architectural Gestin de la cartera Arquitectura del Paisaje Capability Tipo de compromiso
Arquitectura Desarrollo (Lnea de base primero) Architectural Gestin de Cartera Planificacin de la Centrarse en los proyectos, las dependencias del proyecto, y los impactos paisajsticos de alinear secuenciacin proyecto de Proyectos Transicin de manera que se optimiza arquitectnicamente. Arquitectura de Gobierno Arquitectura Capability Arquitectura Desarrollo (Lnea de base primero) Planificacin de la Transicin Centrarse en la elaboracin de la meta de satisfacer una Architectural Definicin de Arquitectura visin previamente definido y acordado, el alcance, o un Iniciativas de Cambio delimitadas Desarrollo (Target primero) conjunto de restricciones. Use el destino como una base para el anlisis para evitar la perpetuacin de la lnea de Planificacin de la base, arquitecturas sub-ptimos. Gobernanza arquitectnico de Cambio Implementacin Transicin Arquitectura de Gobierno Utilice la Architecture Vision, limitaciones, principios, requisitos, Arquitectura Target definicin, y un plan de transicin para asegurar que los proyectos se dan cuenta de su beneficio previsto, estn alineados entre s, y estn alineados con las necesidades de negocio ms amplio.
Centrarse en la evaluacin fsica de las aplicaciones de lnea de base y de la infraestructura de tecnologa para identificar oportunidades de mejora, por lo general dentro de las limitaciones de mantenimiento de los negocios como de costumbre.
Architectural Definicin de Fundacionales iniciativas de cambio
Centrarse en la elaboracin de una visin a travs de la definicin de la lnea de base e identificar lo que debe cambiar para hacer la transicin de la lnea base a la meta.
19.4 Enfoques para el Desarrollo de la Arquitectura

Dos enfoques se pueden adoptar dentro de la ADM para el desarrollo de arquitecturas: Lnea de Base Primera : En este estilo, se utiliza una evaluacin del paisaje de referencia para identificar las reas problemticas y oportunidades de mejora. Este proceso es ms adecuado cuando la lnea de base es compleja, no se entiende claramente, o que
Pgina190de670

TOGOF9.1
convengan. Este enfoque es comn en el que las unidades de organizacin han tenido un alto grado de autonoma. Objetivo Primero : En este estilo, la solucin objetivo se elabora en detalle y luego asigna de nuevo a la lnea de base, con el fin de identificar la actividad de cambio. Este proceso es adecuado cuando un estado de destino est de acuerdo en un nivel alto y cuando la empresa desea hacer la transicin eficazmente a la modelo de destino.
Tpicamente, si la lnea de base se entiende en lneas generales un valor ms alto ser obtenido se centra en el objetivo primero y luego la lnea de base en la medida necesaria para identificar los cambios. En trminos prcticos, un equipo de la arquitectura siempre dar consideracin informal a la lnea de base en el anlisis de la meta (y viceversa ). En situaciones donde se espera que la lnea de base y el objetivo a considerar en paralelo por los interesados, se recomienda que el equipo de arquitectura se centra prioritaria en un Estado con el fin de mantener el enfoque y la coherencia de la ejecucin.
19.5 Iteracin Consideraciones

Algunos ciclos de iteracin puede ser ejecutado una vez, mientras que otros tienen un nmero mnimo natural de los ciclos. Para algunos ciclos de iteracin, cada iteracinsigue el mismo proceso; donde hay ms de una iteracin dentro de un ciclo, el proceso difiere ligeramente para cada una de las iteraciones. Cuando se considera el uso de ciclos de iteracin, tambin es necesario considerar dnde colocar los puntos de control apropiados dentro del proceso. Si el nivel esperado de participacin de los interesados es alto, puede ser razonable para llevar a cabo los puntos de control muy frecuentes pero informales para garantizar que el proceso se est moviendo en la direccin deseada. Si las partes interesadas no estn tan estrechamente involucrados, entonces los puntos de control pueden ser menos frecuentes pero ms formal. Los puestos de control en la finalizacin de cada ciclo de iteracin, o al final de varios ciclos de iteracin, son comunes.
19.5.1 La iteracin entre Ciclos ADM

Cada iteracin completa un ciclo de ADM en un solo nivel de descripcin de la arquitectura. Este enfoque de la ADM utiliza la Fase F (Migration Planning) para iniciar nuevos proyectos ms detallados de desarrollo de la arquitectura. Este enfoque se ilustra en la Figura 19-3 . Este tipo de iteracin destaca la necesidad de una arquitectura de alto nivel para orientar y limitar la arquitectura ms detallada. Tambin destaca que la arquitectura del paisaje completo ha sido desarrollado por mltiples iteraciones ADM.
Pgina191de670

TOGOF9.1

Figura193:UnaJerarquadeADMProcesosEjemplo
19.5.2 La iteracin dentro de un ciclo de ADM
Cada ciclo de iteracin pase por varias fases TOGAF ADM. Las siguientes tablas muestran a un alto nivel que las fases se deben completar para que el ciclo de iteracin, que muestra la actividad que es el ncleo (es decir, el enfoque principal de la iteracin), actividad que es la luz (es decir, el objetivo secundario de la iteracin), y actividad que puede llevarse a cabo de manera informal (es decir, algn tipo de actividad puede llevarse a cabo, pero no se menciona explcitamente en el ADM).
Pgina192de670

TOGOF9.1

Figura194:ActividadporiteracindeLneadeBasePrimeraArquitecturaDefinicin
Pgina193de670

TOGOF9.1
Figura195:ActividadporiteracinparaTargetPrimeraArquitecturaDefinicin
Los ciclos de iteracin sugeridas asignados a las fases TOGAF se describen en la siguiente tabla:
La iteracin Iteracin Propsito del ciclo Arquitectura Iteracin Definir la Arquitectura de Desarrollo 1 Referencia. (Lnea de base primero) Descripcin Esta iteracin comprende un paso a travs de la arquitectura de negocios, Sistemas de Informacin Arquitectura y Arquitectura Tecnologa fases de la ADM, centrndose en la definicin de la lnea de base.
Oportunidades, soluciones y planes de migracin tambin se consideran para sacar el foco para el cambio y la viabilidad de prueba. Iteracin Definir la arquitectura destino Esta iteracin comprende un paso a 2 y las lagunas. travs de la arquitectura de negocios, Sistemas de Informacin Arquitectura y Arquitectura Tecnologa fases de la ADM, centrndose en la definicin de los objetivos y anlisis de brechas en contra de la lnea de base. Oportunidades, soluciones y planes de migracin tambin se consideran para probar la viabilidad. Iteraciones Arquitectura de desarrollo posteriores intentan corregir y
Iteracinn Refinar la lnea de base, el objetivo, y las lagunas.
Pgina194de670

TOGOF9.1
perfeccionar el objetivo de lograr un resultado que sea beneficioso, factible y viable. Esta iteracin comprende un paso a travs de la arquitectura de negocios, Sistemas de Informacin Arquitectura y Arquitectura Tecnologa fases de la ADM, centrndose en la definicin de la meta. Oportunidades, soluciones y planes de migracin tambin se consideran para sacar el foco para el cambio y la viabilidad de prueba. Esta iteracin comprende un paso a travs de la arquitectura de negocios, Sistemas de Informacin Arquitectura y Arquitectura Tecnologa fases de la ADM, centrndose en la definicin de los espacios de referencia y anlisis contra el objetivo.
Arquitectura Desarrollo (Target primero)
Iteracin Definir la arquitectura 1 destino.
Iteracin Definir la Arquitectura y las 2 lagunas de lnea de base.
Oportunidades, soluciones y planes de migracin tambin se consideran para probar la viabilidad. Iteracinn Refinar la lnea de base, el Iteraciones Arquitectura de desarrollo objetivo, y las lagunas. posteriores intentan corregir y perfeccionar el objetivo de lograr un resultado que sea beneficioso, factible y viable. Planificacin de Iteracin Definir y acordar una serie de La primera iteracin de la planificacin la Transicin 1 oportunidades de mejora, de la transicin busca ganar buy-in a alineados contra una una cartera de oportunidades con arquitectura provisional de soluciones para las Oportunidades y transicin. Soluciones fase de ADM. Esta iteracin tambin ofrece un plan de migracin provisional. Iteracinn Acordar la arquitectura de Iteraciones posteriores de planificacin transicin, el de la transicin tratan de perfeccionar perfeccionamiento de las el plan de migracin, la alimentacin oportunidades de mejora de los nmeros anteriores en las identificadas para adaptarse. oportunidades y soluciones para la fase de refinamiento. Arquitectura de Iteracin Movilizar gobernabilidad La arquitectura de la gobernanza Gobierno 1 arquitectura y cambiar los iteracin inicial establece un proceso procesos de gestin. para la gobernanza del cambio y tambin pone en su lugar a las personas adecuadas, procesos ytecnologa para apoyar el acceso controlado a y el cambio de la arquitectura definida. Iteracinn Llevar a cabo la Iteraciones posteriores de la Arquitectura enfoque de ciclo de gobernabilidad y la Gobierno en la revisin peridica de arquitectura de control de las iniciativas de cambio para resolver cambios. los problemas y garantizar su cumplimiento. Los resultados de una
Pgina195de670

TOGOF9.1
solicitud de cambio pueden desencadenar otra fase a ser revisado; por ejemplo, la alimentacin de nuevo un nuevo requisito para la Etapa Preliminar para mejorar la Capacidad de Arquitectura, o un nuevo requisito para la arquitectura en las fases de desarrollo de la arquitectura.
19.6 Conclusiones
Todas estas tcnicas son aplicaciones vlidas de la ADM. Combinado juntos, representan cmo el ADM se puede utilizar en la prctica. El ADM siempre se debe utilizar en un proceso iterativo. . Cmo se ejerce este proceso depende de factores organizativos factores particulares a considerar incluyen: La formalidad y la naturaleza de los puestos de control de procesos establecidos dentro de la organizacin. El mandato de la organizacin de que ciertos grupos de actividades se llevan a cabo entre los puestos de control? Tiene el mandato de la organizacin de que ciertas actividades deben finalizarse antes de que otras actividades se puede realizar? El nivel de participacin de los interesados se esperaba dentro del proceso. Estn interesados esperando a participar estrechamente en el desarrollo de una solucin, o estn a la espera de ver un conjunto completo de prestaciones para su revisin y aprobacin? El nmero de equipos participantes y de las relaciones entre los diferentes equipos. Es toda la arquitectura est siendo desarrollado por un equipo especfico, o hay una jerarqua de equipos con las relaciones de gobierno entre ellos? La madurez del rea de la solucin y la cantidad esperada de la reanudacin y el refinamiento necesario para llegar a una solucin aceptable. Se puede lograr la solucin en un solo paso, o requiere un extenso trabajo de prueba de concepto y prototipos para evolucionar un resultado adecuado ? Actitud hacia el riesgo. Reacciona la cultura organizacional negativamente a parcialmente los productos de trabajo completas se distribuyen? Requiere la cultura organizacional soluciones que deben probarse en un entorno de prueba antes de que puedan ser implementadas por la aplicacin general? La clase de compromiso. Cul es el contexto para el desarrollo de la arquitectura de la empresa?
Pgina196de670

TOGOF9.1
20. Aplicando la ADM a travs de la Arquitectura del Paisaje 20.1 Informacin general
En una empresa tpica, muchas arquitecturas se describirn en la arquitectura del paisaje en cualquier punto en el tiempo. Algunas arquitecturas abordarn necesidades muy especficas; otros sern ms general. Algunos abordar detalle; Algunos pueden ofrecer una gran imagen. Para hacer frente a esta complejidad TOGAF utiliza los conceptos de niveles y Enterprise Continuum para proporcionar un marco conceptual para la organizacin de la Arquitectura del Paisaje. Estos conceptos estn estrechamente vinculados con la organizacin de contenido real en la arquitectura de repositorio y cualquier particin de arquitectura se discuten en la Parte V .

Niveles proporcionan un marco para dividir la arquitectura del paisaje en tres niveles de granularidad:
1. Arquitectura Estratgico proporciona un marco de organizacin de la actividad operativa y el cambio y permite la configuracin de direccin a nivel ejecutivo. 2. Arquitectura Segmento proporciona un marco de organizacin de la actividad operativa y
el cambio y permite la configuracin de la direccin y el desarrollo de los planes de trabajo de arquitectura eficaces a nivel de programa o cartera.
3. Arquitectura Capability ofrece un marco organizativo para la actividad de cambio y el

desarrollo de planes de trabajo eficaces arquitectura realizando incrementos de capacidad. La Figura 20-1 muestra un resumen del modelo de clasificacin de Arquitectura Paisajes.
Pgina197de670

TOGOF9.1
Figura201:ResumenClasificacinModelodeArquitecturaPaisajes
La Arquitectura Continuum proporciona un mtodo de dividir cada nivel de la arquitectura del paisaje (ver 39.4.1 Arquitectura Continuum ) por la abstraccin. Ofrece una forma coherente de definir y entender las reglas genricas, las representaciones y las relaciones en una arquitectura , incluyendo las relaciones de trazabilidad y de derivacin. La Arquitectura Continuum muestra las relaciones de elementos de cimentacin a la arquitectura especfica de la organizacin, como se muestra en la Figura 20-2 . La Arquitectura Continuum es una herramienta til para descubrir en comn y eliminar la redundancia innecesaria.
Figura202:ResumendeArquitecturaContinuum
Los niveles y la Continuum Arquitectura proporcionan un mecanismo amplio para describir y clasificar la Arquitectura del Paisaje. Estos conceptos pueden ser usados para organizar la arquitectura del paisaje en un conjunto de arquitecturas relacionadas con: Complejidad manejable para cada arquitectura o solucin individual
Pgina198de670

TOGOF9.1
Agrupaciones definidas Jerarquas definidas y estructuras de navegacin Procesos adecuados, roles y responsabilidades adjuntas a cada agrupacin
No existe un modelo de organizacin definitiva de la arquitectura, ya que cada empresa debe adoptar un modelo que refleje su propio modelo de funcionamiento.
20.3 Organizacin de la Arquitectura del Paisaje para comprender el estado de la Empresa

Las siguientes caractersticas se utilizan normalmente para organizar la Arquitectura del Paisaje: Amplitud : El rea de amplitud (objeto) es por lo general la caracterstica de organizacin primaria para la descripcin de una arquitectura del paisaje. Arquitecturas estn funcionalmente descomponerse en una jerarqua de reas o segmentos de materias especficas. Profundidad : Con reas ms amplias, se necesita menos detalle para asegurar que la arquitectura tiene un tamao y una complejidad manejable. reas temticas ms especficas, generalmente permitir (y requerir) arquitecturas ms detalladas. Tiempo : Para una amplitud y profundidad especfica de una empresa puede crear una arquitectura de referencia y un conjunto de arquitecturas objetivo que se extienden hacia el futuro. Arquitecturas ms amplios y menos detallados sern generalmente vlidas por perodos ms largos de tiempo y pueden proporcionar una visin de la empresa, que se extiende ms hacia el futuro. Fecha reciente : Finalmente, cada vista de la arquitectura va a progresar a travs de un ciclo de desarrollo donde aumenta la precisin hasta que finalmente aprobado. Despus de la aprobacin, una arquitectura comenzar a disminuir en precisin si no se mantiene activa. En algunos casos de experiencia reciente se puede utilizar como un factor de la organizacin para las arquitecturas histricas.
Utilizando los criterios anteriores, las arquitecturas se pueden agrupar en, por segmentos y niveles de Arquitectura de la capacidad estratgica, tal como se describe en la Figura 20-1 .
20.4 Desarrollo de arquitecturas en diferentes niveles

Las secciones anteriores han identificado que se requieren diferentes tipos de arquitectura para estudiar las distintas necesidades de los interesados en los diferentes niveles de la organizacin. Cada arquitectura tpicamente no existe de manera aislada y por lo tanto debe sentarse dentro de una jerarqua de gobierno. Amplio, arquitecturas de sntesis que figura la direccin para arquitecturas estrechas y detalladas. . Un nmero de tcnicas se puede emplear para utilizar el ADM como un proceso que apoya tales jerarquas de arquitecturas Esencialmente hay dos estrategias que se pueden aplicar:
Pgina199de670

TOGOF9.1 1. Arquitecturas en los diferentes niveles se pueden desarrollar a travs de iteraciones dentro de un solo ciclo del proceso de ADM. 2. Arquitecturas en los diferentes niveles se pueden desarrollar a travs de una jerarqua de procesos de ADM, ejecutado simultneamente.
En los extremos de la escala, cualquiera de estas dos opciones se pueden adoptar plenamente. En la prctica, un arquitecto es probable que tenga que combinar elementos de cada uno para adaptarse a los requisitos exactos de su Solicitud de Arquitectura Obra. Cada uno de estos enfoques se describe en 19. La aplicacin de iteracin para el ADM .
Pgina200de670

TOGOF9.1
21. Arquitectura de Seguridad y el ADM 21.1 Informacin general

El objetivo de este captulo es explicar las consideraciones de seguridad que deben ser abordados durante la aplicacin del Mtodo de Desarrollo de Arquitectura TOGAF (ADM).
21.2 Introduccin
Mtodos de desarrollo de la arquitectura son herramientas en las manos del practicante de seguridad que se utilizarn para crear las mejores prcticas y la capacidad de seguridad especficas de cada organizacin. La orientacin que se incluye aqu es ayudar a los dos arquitectos de la empresa y los profesionales de seguridad para evitar la prdida de los problemas de seguridad crticos. En este captulo se informa a la empresa artfice de lo que necesitar el arquitecto de seguridad para llevar a cabo durante los trabajos de arquitectura de seguridad. A menudo, la arquitectura de seguridad es tratado como un dominio de la arquitectura independiente dentro de la arquitectura de la empresa, mientras que necesitan ser integrados plenamente en el mismo. El enfoque del arquitecto de seguridad es la ejecucin de las polticas de seguridad de la empresa, sin inhibir valor. Arquitecturas de seguridad generalmente tienen las siguientes caractersticas: Arquitectura de seguridad tiene su propia metodologa de seguridad discreto. Arquitectura de seguridad compone sus propias opiniones y puntos de vista diferenciados. Arquitectura de seguridad se ocupa de los flujos no normativos a travs de sistemas y entre las aplicaciones. Arquitectura de seguridad presenta sus propios flujos normativos a travs de sistemas y entre las aplicaciones. Arquitectura de seguridad presenta, componentes de una sola funcin nica en el diseo. Arquitectura de seguridad requiere su propio conjunto nico de habilidades y competencias de la empresa y los arquitectos de TI.
21.3 Orientacin de Seguridad para los Dominios Arquitectura

Los problemas de seguridad son omnipresentes en todo los mbitos de la arquitectura y en todas las fases del desarrollo de la arquitectura. Seguridad es declarado out por separado debido a que es una infraestructura que no suele ser visible a la funcin empresarial. Su propsito fundamental es proteger el valor de los sistemas y activos de informacin de la empresa. Con frecuencia, la
Pgina201de670

TOGOF9.1
naturaleza de la seguridad en la empresa es que se considera exitoso si bien no ocurre nada es visible para el usuario u otro observador, y / o no hay daos o prdidas ocurren a la empresa. Por ejemplo, los datos en una base de datos de los registros de clientes no se filtraron o daados - o un tema intangible, como el nombre de la empresa aparece en un artculo en las noticias diciendo que sus sistemas de datos haban sido comprometidos. La arquitectura de seguridad tiene sus propios componentes de un solo uso y se experimenta como una cualidad de los sistemas en la arquitectura. El punto de vista de Seguridad Empresarial de la arquitectura tiene sus propios bloques nicos de construccin, colaboraciones, y las interfaces. Estos elementos de seguridad-nica deben interconectar con los sistemas de negocio de una manera equilibrada y rentable, a fin de mantener las polticas de seguridad de la empresa, an no interferir con las operaciones del sistema y funciones. Es menos costoso y ms eficaz para planificar y ejecutar funciones especficas de seguridad en la arquitectura de destino lo antes posible en el ciclo de desarrollo para evitar la costosa adaptacin o reelaborar porque los bloques de construccin necesarios para la seguridad no se aadieron o se utilizan durante el desarrollo de sistemas y despliegue . El enfoque del arquitecto de seguridad en cuenta no slo el flujo normal de la aplicacin, sino tambin los flujos anormales, modos de falla, y las formas de los sistemas y las aplicaciones pueden ser interrumpidos y fallan. Todos los grupos de partes interesadas en la empresa se tienen problemas de seguridad y es deseable para traer un arquitecto de seguridad en el proyecto lo antes posible.A lo largo de las fases de la ADM, la orientacin se ofrecer en la informacin especfica de la seguridad que deben ser reunidos, los pasos que se deben tomar, y los artefactos que se deben crear. Arquitectura decisiones relacionadas con la seguridad deben realizarse de conformidad con las decisiones comerciales y polticas y su gestin de riesgos. Las reas generalmente aceptadas de la preocupacin por el arquitecto de seguridad son: Autenticacin : La fundamentacin de la identidad de una persona o entidad relacionada con la empresa o el sistema de alguna manera. Autorizacin : La definicin y la aplicacin de las capacidades permitidas para una persona o entidad cuya identidad ha sido establecida. Auditora : La capacidad de proporcionar datos forenses que conste que los sistemas se han utilizado de acuerdo con las polticas de seguridad establecidas. Aseguramiento : La capacidad de probar y demostrar que la arquitectura de la empresa tiene los atributos de seguridad necesarias para defender las polticas de seguridad establecidas. Disponibilidad : La capacidad de la empresa para funcionar sin interrupcin del servicio o el agotamiento a pesar de acontecimientos anormales o maliciosos. Proteccin de Activos : La proteccin de los activos de informacin de la prdida o divulgacin no intencional, y los recursos de un uso no autorizado y no deseado. Administracin : La capacidad de agregar y cambiar las polticas de seguridad, agregar o cambiar cmo se implementan las polticas de la empresa, y aadir o cambiar las personas o entidades vinculados a los sistemas. Gestin de Riesgos : actitud y tolerancia al riesgo de la organizacin. (Esta gestin del riesgo es diferente de la definicin especial que se encuentra en los mercados financieros
Pgina202de670

TOGOF9.1
y las instituciones de seguros que cuentan con departamentos formales de gestin de riesgo.) Tpicos artefactos arquitectura de seguridad se incluyen: Las reglas de negocio con respecto al manejo de los activos de datos / informacin Poltica de seguridad Escrito y publicado Datos codificados / informacin de propiedad y custodia de activos Documentacin de anlisis de riesgos Documentacin poltica de clasificacin de datos
Gestin Arquitectura 21,4 ADM Requisitos

La poltica de seguridad y las normas de seguridad se convierten en parte del proceso de gestin de requisitos empresariales. La poltica de seguridad se establece en un nivel ejecutivo de la empresa, es de larga duracin y resistente al cambio caprichoso. La poltica de seguridad no est ligado a ninguna tecnologa especfica. Una vez que se establecen las polticas de seguridad, pueden ser referidos como requisitos para todos los proyectos de arquitectura. Las normas de seguridad cambian con ms frecuencia y las preferencias tecnolgicas estatales utilizados para apoyar las polticas de seguridad. Las nuevas tecnologas que apoyan la implementacin de polticas de seguridad de una mejor manera se pueden adoptar, segn sea necesario. Las mejoras pueden estar en la reduccin de costos o el aumento de los beneficios. Las normas de seguridad se manifestarn como bloques de construccin relacionados con la seguridad en la Empresa Continuum. Patrones de seguridad para el despliegue de estos bloques de construccin relacionadas con la seguridad se hace referencia en la Gua de Seguridad para la Fase E. Nuevos requisitos de seguridad surgen de muchas fuentes:
1. Un nuevo mandato estatutario o reglamentario 2. Una nueva amenaza se dio cuenta o experimentado 3. Una nueva iniciativa de la arquitectura de TI descubre nuevas partes interesadas y / o nuevos requerimientos
En el caso en que 1. y 2. arriba ocurren, estos nuevos requisitos seran los conductores para la entrada al sistema de gestin del cambio discutido en la Fase H. Una nueva iniciativa de la arquitectura podra ser lanzado para examinar la infraestructura y las aplicaciones existentes para determinar el alcance de los cambios necesarios para satisfacer las nuevas demandas. En el caso de 3. arriba , un nuevo requisito de seguridad entrar en el sistema de gestin de requisitos.
Es nuestra buena seguridad?
Esta pregunta surge inevitablemente de la administracin para el arquitecto de seguridad. No hay medidas de seguridad son siempre perfecto, y existe la posibilidad de que la cantidad de dinero y
Pgina203de670

TOGOF9.1
esfuerzo realizado para llegar a ser muy grande para poca rentabilidad adicional. Pruebas de control de seguridad debe estar en su lugar para que los sistemas de seguridad se pueden medir para asegurarse de que se mantienen las polticas de seguridad para el que fueron diseados. Auditoras de polticas de seguridad deben mantenerse y puede ser obligatorio por ley o reglamento. Estas auditoras de seguridad y los posibles cambios en las polticas de seguridad son la razn exacta por la separacin de la aplicacin de la poltica del cdigo de la aplicacin es tan fuertemente enfatizado.
Nada til se puede decir de una medida de seguridad fuera del contexto de una aplicacin o de un sistema y su entorno
La eficacia de una medida de seguridad se considera en relacin con el riesgo que mitiga. Una empresa no puede determinar cunto va a estar dispuesto a gastar en la obtencin de un activo hasta que se comprende el valor de los activos. Por ejemplo, el uso de ese activo en una aplicacin y el riesgo concomitante el activo est expuesto a como resultado, determinar los verdaderos requisitos para la seguridad. Adems, la tolerancia de la organizacin para el riesgo es un factor. En otras palabras, la pregunta que no debera ser: "Est seguro?" sino ms bien: "Es lo suficientemente seguro?" Este ltimo es en ltima instancia una pregunta que debe responderse mediante el anlisis de riesgos.
21.5 Fase Preliminar

Alcance de las organizaciones empresariales afectadas por la arquitectura de seguridad
Identificar empresa de la base (unidades) - aquellos que son los ms afectados y lograr mayor valor de los trabajos de seguridad Identificar empresariales blandos (unidades) - los que se ven el cambio a su capacidad y trabajar con unidades bsicas, pero son de otra forma no directamente afectados Identificar empresariales extendidas (unidades) - aquellas unidades fuera de la empresa de mbito que necesitar para mejorar su arquitectura de seguridad para fines de interoperabilidad Identificar las comunidades implicadas (empresas) - las partes interesadas que se vern afectados por las capacidades de seguridad y que se encuentran en los grupos de las comunidades Identifique la gobernanza de la seguridad involucrados, incluidos los marcos jurdicos y geografas (empresas)
Si el modelo de negocio de la organizacin hace abarcar federacin con otras organizaciones, en la medida de la federacin de seguridad debe establecerse en este punto en el proceso. Acuerdos de federacin contractuales deben ser examinados por sus implicaciones y acuerdos de seguridad. Puede que sea necesario establecer reuniones arquitectura conjuntas con otros miembros de una federacin para establecer interfaces y protocolos para el intercambio de informacin de seguridad relacionada con la identidad federada, autenticacin y autorizacin.
Definir y documentar los requisitos reglamentarios y de poltica de seguridad aplicables
El marco y los principios rara vez cambian, por lo que las implicaciones de seguridad llamados en los objetivos de esta fase debera ser bastante sencillo. Una poltica de seguridad por escrito de la
Pgina204de670

TOGOF9.1
organizacin debe estar en su lugar, y no debe haber notificacin regular y la educacin establecidos para los empleados. ISO / IEC 17799:2005 es un buen lugar para comenzar la formacin de una poltica de seguridad, y se puede utilizar para evaluar la disposicin de seguridad de una organizacin. Sin una poltica de seguridad por escrito y publicado, su aplicacin es difcil. Las polticas de seguridad se refieren a muchos aspectos de la seguridad de la organizacin - como la seguridad locales fsicos - que son remotamente relacionadas con la seguridad de los sistemas y aplicaciones. La poltica de seguridad debe ser examinada para encontrar secciones pertinentes, y se actualiza si es necesario. Arquitectura limitaciones establecidas en la poltica de seguridad deben ser comunicados a los dems miembros del equipo de arquitectura. De manera similar, puede haber requisitos reglamentarios que especifican las obligaciones del sistema debe cumplir o acciones que se deben tomar. Si el sistema estar sujeto a la regulacin depender de la funcionalidad del sistema y los datos recogidos o mantenidas. Adems, la jurisdiccin donde se despliega el sistema o servicio, donde residen los usuarios, o en virtud de la cual la entidad est desplegando fletados o incorporados informar de esta decisin. Puede ser aconsejable obtener asesoramiento legal con respecto a estas obligaciones al inicio de las actividades.
Definir la capacidad de seguridad requerido como parte de la arquitectura de Capacidad
Acuerdo sobre el papel del arquitecto de seguridad en el proceso de arquitectura de la empresa y en la arquitectura y el gobierno de TI tambin deben establecerse. Las consideraciones de seguridad pueden entrar en conflicto con consideraciones funcionales y se requiere un defensor de la seguridad para garantizar que todas las cuestiones se abordan y los conflictos de intereses no impiden la consideracin explcita de temas difciles. Decisiones polticas ejecutivas deben establecerse en este punto acerca de lo que las polticas de seguridad puede ser negociable y qu polticas deben hacerse cumplir por razones reglamentarias o estatutarias.
Implementar herramientas de arquitectura de seguridad
El nivel de formalidad utilizado para definir y gestionar la seguridad de contenidos arquitectura ser altamente dependiente de la escala, la sofisticacin y la cultura de la funcin de la arquitectura de seguridad. El acercamiento a las herramientas de seguridad puede estar basado en el uso relativamente informal de aplicaciones de productividad de oficina estndar, o puede estar basada en una implementacin personalizada de herramientas de arquitectura de seguridad especializadas y tcnicas.
21.5.1 Entradas de seguridad La poltica de seguridad por escrito

Estatutos pertinentes Lista de las jurisdicciones aplicables
Las salidas de seguridad 21.5.2 Lista de los reglamentos aplicables

Lista de las polticas de seguridad aplicables Equipo de seguridad roster
Pgina205de670

TOGOF9.1
Lista de los supuestos de seguridad y condiciones de frontera
21.6 Fase A: Architecture Vision

Las consideraciones de seguridad tienen un impacto en las Fases A a H del TOGAF ADM. Las siguientes especificaciones de seguridad adecuadas para la arquitectura de seguridad deben abordarse en cada fase, adems de las actividades de eliminacin de genricos. Las etapas de la fase de Visin Arquitectura son aplicables a garantizar que los requisitos de seguridad se abordan en las fases posteriores de la ADM. Las consideraciones de seguridad tendrn un efecto en la empresa de tal manera que todo el desarrollo de la arquitectura empresarial debe ser informada y utilizar la poltica de seguridad, las limitaciones, la gobernanza, los artefactos, y bloques de construccin. Despus de establecer cualquier proyecto de arquitectura de la empresa, las siguientes actividades relacionadas con la seguridad especficas deben llevarse a cabo. Definicin de los grupos de inters y de descubrimiento pertinentes de sus preocupaciones y objetivos requerir el desarrollo de un escenario de alto nivel. Requisitos de negocio clave Tambin se establecern a travs de este trabajo de escenarios temprano. El proceso de escenario empresarial TOGAF ADM puede ser til aqu y en etapas posteriores.
Obtener el apoyo de la gestin de las medidas de seguridad
En forma similar a obtener el reconocimiento y la gestin de aval para el proyecto en general la arquitectura, as tambin la aprobacin de los aspectos relacionados con la seguridad de las actividades de desarrollo de arquitectura debe ser obtenido. Reconocimiento de que el proyecto podra tener el desarrollo y el impacto de infraestructuras que no son fcilmente visibles por mirar nicamente a los sistemas en cuestin debe quedar claro. Examinar a fondo y la mitigacin de los problemas relacionados con el riesgo y la seguridad pueden ser percibidos como un desperdicio de recursos y de tiempo; el nivel de apoyo a la gestin debe entenderse y comunicarse en todo el equipo.
Definir gestin hitos sign-off en materia de seguridad necesarias de este ciclo de desarrollo de la arquitectura
La trazabilidad de decisiones de arquitectura relacionados con la seguridad debe ser documentado y los ejecutivos apropiados y gestin de la lnea que necesitan para estar informado de los aspectos relacionados con la seguridad del proyecto deben ser identificados y la frecuencia de los informes debe ser establecido. Se debe reconocer que existe la tensin entre la entrega de la nueva funcin empresarial y la ejecucin de polticas de seguridad, y que un proceso para resolver tales disputas que surjan deben establecerse al principio del proyecto. Estas tensiones tienen a menudo el resultado de poner el arquitecto de seguridad aparentemente "en la forma de completar el proyecto." Se necesita ser entendido por la direccin y los dems arquitectos involucrados que el papel del arquitecto de seguridad es el de salvaguardar los activos de la empresa.
Determinar y documentar la recuperacin de desastres y continuidad de negocio aplicable planes / requisitos
Cualquier recuperacin de desastres existentes y los planes de continuidad de negocio deben ser comprendidas y su relacin con el sistema de planificacin definidos y documentados.
Pgina206de670

TOGOF9.1
Identificar y documentar el / / ambiente anticipado fsica negocio regulatorio (s) en que se implementar el sistema (s)
Todas las decisiones de arquitectura deben hacerse en el contexto de los entornos en los que el sistema se puede colocar y operar. Entornos fsicos que deben ser documentados pueden incluir entornos de batalla, ambientes comerciales, ambientes al aire libre, los entornos mviles y similares. De manera similar, el entorno empresarial se debe definir. Entornos empresariales potenciales pueden incluir diferentes supuestos sobre los usuarios y las interfaces de usuarios, y stos o interfaces pueden llevar la carga de los entornos regulatorios en que debe operar el sistema (usuarios de menores de trece aos en los EE.UU., por ejemplo).
Determinar y documentar la criticidad del sistema: safety-critical/mission-critical/non-critical
Establecer sistemas de seguridad crtica vive en peligro en caso de avera o mal funcionamiento. Establecer sistemas de dinero de misin crtica, la cuota de mercado, o el capital en riesgo en caso de fallo. Los sistemas no crticos tienen pocas o ninguna consecuencia en caso de fracaso.
21.6.1 Entradas de seguridad Lista de las polticas de seguridad aplicables

Lista de las jurisdicciones aplicables Planes de recuperacin de desastres completa y la continuidad del negocio
Las salidas de seguridad 21.6.2 Declaracin entorno de seguridad fsica

Declaracin entorno de seguridad de negocios Declaracin Entorno regulatorio Carta de la poltica de seguridad firmado por el consejero delegado o delegada Lista de los puntos de control de desarrollo de la arquitectura de seguridad de cierre de sesin Lista de los planes de recuperacin de desastres y continuidad de negocio aplicable Declaracin Sistemas criticidad
21.7 Fase B: Arquitectura de Negocios

Determinar quines son los actores legtimos que interactuarn con el producto / servicio / proceso
Elaboracin de los escenarios de negocio y posteriores de alto nivel casos de uso del proyecto en cuestin traer a la atencin de las personas protagonistas y actores del sistema implicados. Muchos ulteriores decisiones sobre la autorizacin se basar en una slida comprensin de los presuntos usuarios, administradores y operadores del sistema, adems de sus capacidades y caractersticas esperadas. Se debe tener en cuenta que los usuarios pueden no ser
Pgina207de670

TOGOF9.1
los seres humanos; aplicaciones de software pueden ser los usuarios legtimos. Los que cuidaban a las necesidades administrativas, tales como operadores de copia de seguridad, tambin deben ser identificados, ya que los usuarios deben lmites externos de confianza, tales como los clientes basados en Internet.
Evaluar y los procesos de negocio especficos de seguridad de lnea de base actuales (mejora de objetivo existente)
El proceso de negocio con respecto a cmo los actores son investigados ya que los usuarios adecuados del sistema debe documentarse. Tambin se debe hacer para los actores de fuera de la organizacin que son usuarios propios del sistema. Las entidades externas se determinarn a partir de los escenarios de alto nivel desarrollados como parte de la Fase A.
Determinar los cuales / cunto es aceptable para inconveniente en la utilizacin de medidas de seguridad
Las medidas de seguridad, si bien son importantes, pueden imponer una carga sobre los usuarios y el personal administrativo. Algunos respondern a esa carga mediante la bsqueda de formas de burlar las medidas. Algunos ejemplos son los administradores de encontrar maneras de crear "puertas traseras" o los clientes que eligen un competidor para evitar la carga percibida de la infraestructura. Las compensaciones pueden requerir equilibrar las ventajas de seguridad en contra de ventajas comerciales y exigir una eleccin juiciosa informado.
Identificar y documentar los sistemas de interconexin ms all del control del proyecto
Cada sistema ciberntico o negocio debe basarse en los sistemas existentes ms all del control del proyecto. Estos sistemas tienen ventajas y desventajas, riesgos y beneficios. Los ejemplos incluyen el sistema de nombres de dominio (DNS) que resuelve nombres de equipos y de servicios a las direcciones de Internet, o el papel moneda emitido por la Tesorera local. La direccin devuelta por el anfitrin o el servicio DNS no siempre puede ser digno de confianza; papel moneda no siempre puede ser genuina, y el recurso vara en la eficacia entre las jurisdicciones. Estas interfaces deben ser entendidos y documentados.
Determinar los activos en riesgo, si algo sale mal - "Qu estamos tratando de proteger?"
Activos no siempre son tangibles y no siempre son fciles de cuantificar. Algunos ejemplos son: la prdida de la vida, la prdida de la buena voluntad del cliente, la prdida de una calificacin de bonos AAA, la prdida de cuota de mercado.
Determinar el costo (tanto cualitativa como cuantitativa) de la prdida de activos / impacto en casos de insuficiencia
Hay que recordar que dichos activos ms difciles de cuantificar pueden ser el ms valioso y no debe ser descuidado. Incluso las estimaciones cualitativas resultar tiles en la evaluacin de los riesgos comparativos.
Identificar y documentar la propiedad de los activos
Los activos pueden ser propiedad de entidades externas, o por entidades de su interior. Dentro entidades pueden ser propiedad de los individuos o de las organizaciones.Determine:
Pgina208de670

TOGOF9.1
Dnde se supone que la confianza Cmo se establece Cmo se comunica
Siempre rastrearlo con el mundo real; es decir: Evaluacin (bsquedas de crdito, que d fe personal) Responsabilidad civil (daos monetarios, penas de crcel, sanciones)
Todas las decisiones de seguridad se basan en la confianza que se ha establecido de alguna manera. No hay supuestos fiduciarios tienen ningn valor si no pueden tener sus races en la evaluacin y la responsabilidad en el mundo real. En la mayora de los entornos de negocio, la confianza se establece a travs de contratos que definen la responsabilidad cuando se rompe la confianza. La responsabilidad de la evaluacin de la confianza es la responsabilidad de los que decidan entrar en los contratos y sus abogados. Es importante tener en cuenta que la tecnologa (por ejemplo, certificados digitales, SAML, etc) no puede crear confianza, pero slo se puede transmitir en el mundo de la electrnica de la confianza que ya existe en el mundo real a travs de las relaciones comerciales, acuerdos legales y consistencias de poltica de seguridad .
Determinar y documentar los procesos forenses de seguridad apropiado
Para ser capaces de hacer cumplir las polticas de seguridad, infracciones de seguridad deben ser adecuadamente capturados por lo que la determinacin de problemas y posibles polticas o acciones legales se pueden tomar contra la entidad que causa el incumplimiento. Prcticas forenses adecuados para proporcionar evidencia en su caso la necesidad de ser establecida y documentada. El personal de seguridad deben estar capacitados para seguir los procedimientos forenses y material de capacitacin sobre la necesidad de reunir pruebas debe ser considerado para la educacin de seguridad estndar proporcionada a los trabajadores.
Identificar la criticidad de la disponibilidad y el correcto funcionamiento del servicio en general
Los riesgos asociados con la prdida de la disponibilidad pueden ya han sido adecuadamente considerados en la evaluacin mission-critical/safety-critical anterior.
Determinar y documentar cunta seguridad (coste) se justifica por las amenazas y el valor de los activos en riesgo
Un anlisis de riesgos (la comprensin del valor de los activos en riesgo y la probabilidad de las amenazas potenciales) proporciona una gua importante para las inversiones en estrategias de mitigacin para las amenazas identificadas.
Vuelva a evaluar y confirmar las decisiones Architecture Vision
Pgina209de670

TOGOF9.1
El anlisis de negocios implica una serie de ejercicios de pensamiento riguroso y puede poner en cuestin los supuestos iniciales identificadas en el Architecture Vision.
Evaluar la alineacin o conflicto de las polticas de seguridad identificados con los objetivos empresariales
Las polticas de seguridad identificadas en la Fase Preliminar pueden tener disposiciones que son difciles o imposibles de conciliar con los objetivos de negocio a la luz de los riesgos identificados. Las posibles respuestas incluyen la alteracin de los aspectos del entorno empresarial, la modificacin de la poblacin de usuarios prevista, o tcnico de mitigacin de riesgos (tratados en la Fase C).
Determinar "lo que puede salir mal?"
Realizar un anlisis de las amenazas que identifica las amenazas de alto nivel que influyan en el sistema y su probabilidad.
21.7.1 Entradas de seguridad Declaraciones de negocios y el medio ambiente de seguridad reglamentario inicial
Lista de los planes de recuperacin de desastres y continuidad de negocio aplicable Lista de las polticas y normas de seguridad aplicables
Las salidas de seguridad 21.7.2 Lista de los procesos forenses

Lista de los nuevos requisitos de recuperacin de desastres y continuidad del negocio Declaraciones de negocios y de entorno regulatorio validados Lista de las polticas y normas de seguridad validadas Lista de los procesos de seguridad de destino Lista de los procesos de seguridad de lnea de base Lista de los actores de la seguridad Lista de los sistemas de interconexin Declaracin de la tolerancia de seguridad para cada clase de agente de seguridad Lista de activos con los valores y los propietarios Lista de rutas de confianza Declaracin de impacto Disponibilidad (s) Matriz de anlisis de amenazas
21.8 Fase C: Arquitecturas de Sistemas de Informacin

Pgina210de670

TOGOF9.1
Evaluar y elementos de referencia actuales de seguridad especficas de la arquitectura (de mejora de objetivo existente)
Un inventario completo de los elementos de la arquitectura que implementan servicios de seguridad debe ser compilado en la preparacin de un anlisis de brecha.
Identificar acciones predeterminadas seguras y estados de fallo
Cada cambio de estado en cualquier sistema se precipita por algn disparador. Por lo general, un conjunto enumerado de los valores esperados de ese gatillo inicia un cambio en el estado. Sin embargo, hay probablemente otras entradas de disparo potenciales que deben ser acomodados en los casos no normativas. Adems, un fallo del sistema puede tener lugar en cualquier momento en el tiempo. Acciones predeterminadas seguras y modos de falla deben ser definidas para el sistema informado por el estado actual, el entorno empresarial, las polticas aplicables y obligaciones reglamentarias. Modos predeterminados de seguros para un automvil a velocidad cero ya no sean aplicables a toda velocidad. Estados de insuficiencia de seguros para los dispositivos mdicos difieren notablemente de los estados de fallo de seguridad para la electrnica de consumo.
Identificar y evaluar las directrices y normas reconocidas aplicables
Las normas son justamente acredita para la reduccin de costes, la mejora de la interoperabilidad, y el aprovechamiento de la innovacin. Desde el punto de vista de seguridad, protocolos estndar, bibliotecas de objetos estndares e implementaciones estndar que han sido examinados por expertos en sus campos ayudan a asegurar que los errores no encuentran su camino en las implementaciones. Desde un punto de vista de la seguridad, los errores son las vulnerabilidades de seguridad.
Revisar las suposiciones relativas a los sistemas de interconexin ms all del control del proyecto
A la luz de las evaluaciones de riesgos realizadas, supuestos relativos a los sistemas de interconexin puede ser necesario modificar.
Determinar y documentar el nivel de sensibilidad o de la clasificacin de la informacin almacenada / creado / usado
La informacin almacenada, creado o manipulado por el sistema puede o no puede ser objeto de una clasificacin oficial que define su sensibilidad y las obligaciones a las que el sistema y sus propietarios estn sometidas. La ausencia de una clasificacin oficial no exime necesariamente la responsabilidad en el mantenimiento de la confidencialidad de los datos. La consideracin se debe hacer para los diferentes carga legislativa que pueda sostener la jurisdiccin sobre el sistema y los datos almacenados.
Identificar y custodia de documentos de los activos
Todos los activos de valor sean conservados y mantenidos en nombre del propietario. Las personas u organizaciones especficas encargadas de esta responsabilidad deben ser identificados.
Identificar la criticidad de la disponibilidad y el correcto funcionamiento de cada funcin
Pgina211de670

TOGOF9.1
Es de suponer que, en caso de fallo del sistema o la prdida de funcionalidad, algn valor se pierde a los interesados. El costo de esta prdida de oportunidad debe ser cuantificada, si es posible, y se documenta.
Determinar la relacin del sistema en fase de diseo de los planes de negocios de desastres / continuidad existentes
Planes de desastre en el negocio / de continuidad existentes pueden acomodar el sistema considerado. Si no, algunos anlisis se llama para determinar la brecha y el costo si esa brecha se va sin llenar.
Identificar qu aspectos del sistema debe ser configurable para reflejar los cambios en el control de la poltica de medio ambiente / negocio / acceso
Sin medio ambiente es esttica y sistemas debe evolucionar para adaptarse a los cambios. Sistemas con arquitectura de listo reconfiguracin se reflejan mejor que el cambio y el resultado en un menor costo durante la vida til del sistema. La seguridad se mejora cuando los cambios relacionados con la seguridad se pueden implementar a bajo costo y son, por lo tanto, no dejados de lado. La seguridad tambin se ve reforzada cuando los cambios no requieren cambios en el cdigo; cambios en el cdigo introducen insectos y bichos introducir vulnerabilidades de seguridad.
Identificar la vida til de la informacin utilizada segn la definicin de las necesidades del negocio y los requisitos reglamentarios
La informacin mantenida ms all de su vida til representa un desperdicio de recursos y, potencialmente, las decisiones de negocio basadas en datos subptimos.Reglamento, sin embargo, a veces obliga el calendario de mantenimiento de la informacin como datos de archivo.
Determinar los enfoques para hacer frente a los riesgos identificados:
Mitigar Aceptar Transferencia Evitar
Hay varias formas estndar para hacer frente a los riesgos identificados y cuantificados. La lista anterior no pretende ser exhaustiva de todos los enfoques.
Identificar las acciones / eventos que merecen el registro para su posterior revisin o desencadenar procesos forenses
Acciones anmalas y estados superarn en nmero a las acciones y los estados previstos. Estas transiciones se justifica la tala de reconstruir cadenas de eventos, facilitar el anlisis de la causa raz, y, posiblemente, establecer pruebas para la accin civil o penal. Hay que tener en cuenta que los registros deben ser revisados regularmente para ser introducido como evidencia en una corte de la ley en algunas jurisdicciones.
Pgina212de670

TOGOF9.1
Identificar y los requisitos de documentacin para demostrar el rigor en la precisin de los eventos registrados (no repudio)
Desde manipulacin malintencionada de los sistemas comnmente se acompaa de alteracin de los datos registrados para frustrar la investigacin y de la aprehensin, la capacidad de proteger y establecer la veracidad de los registros a travs de mtodos criptogrficos eliminar la incertidumbre de las investigaciones e impulsar los casos en los procedimientos judiciales.
Identificar potenciales probables vas de ataque /
Pensar como un adversario preparar el arquitecto para la creacin de un sistema robusto que resiste la manipulacin maliciosa y, providencialmente, mal funcionamiento derivado de error aleatorio.
21.8.1 Entradas de seguridad Matriz de anlisis de amenazas

El anlisis de riesgos Procesos forenses Documentados Polticas y regulaciones comerciales validados Lista de los sistemas de interconexin Nuevos requisitos de recuperacin de desastres y continuidad del negocio
Las salidas de seguridad 21.8.2 Evento de la matriz y los requisitos de nivel de registro
Estrategia de gestin de riesgos Definiciones de ciclo de vida de datos Lista de los elementos del sistema configurables Lista bsica de los elementos relacionados con la seguridad del sistema Elementos nuevos o aumentados relacionados con la seguridad del sistema Seguridad modelos de casos de uso: o o Los modelos normativos Los modelos no normativos
Relacin de normas de seguridad aplicables:
Pgina213de670

TOGOF9.1
o o o Protocolos Bibliotecas de objetos Otros ...
Lista del sistema interconectado Validado Informe de clasificacin Informacin Lista de los depositarios de activos Instruccin Function criticidad Planes de recuperacin de desastres y continuidad del negocio revisado Matriz de anlisis de amenazas refinado
21.9 Fase D: Architecture Tecnologa

Evaluar y tecnologas especficas de seguridad actuales de referencia (mejora de objetivo existente) Revisar las suposiciones relativas a los sistemas de interconexin ms all del control del proyecto Identificar y evaluar las directrices y normas reconocidas aplicables Identificar los mtodos para regular el consumo de los recursos
Cada sistema se basar en los recursos que puede estar agotada en los casos que pueden o no pueden preverse en el punto de diseo del sistema. Los ejemplos incluyen el ancho de banda de red, carga de la batera, espacio en disco, la memoria disponible, y as sucesivamente. Como se utilizan los recursos que se acerca el agotamiento, la funcionalidad puede verse afectada o puede fallar por completo. Pasos de diseo que identifican los recursos no renovables, mtodos que pueden reconocer el agotamiento de recursos, y las medidas que pueden responder a travs de la limitacin de los factores causales, oa travs de la limitacin de los efectos del agotamiento de los recursos a la funcionalidad no crtica, pueden mejorar la fiabilidad y la disponibilidad generales de la sistema.
Disear un mtodo por el cual se medir la eficacia de las medidas de seguridad y se comunica de forma continua
Dado que los sistemas se despliegan y operan en entornos dinmicos, las medidas de seguridad funcionan segn distintos grados de eficacia que surgen amenazas inesperadas y como amenazas esperados cambian en el medio ambiente. Un mtodo que facilita la evaluacin continua del valor de las medidas de seguridad informar a los cambios en curso en el sistema en respuesta a las cambiantes necesidades de los usuarios, patrones de amenaza y los problemas encontrados.
Identificar la confianza (holgura) nivel de:
Todos los usuarios del sistema Todos los administradores del sistema
Pgina214de670

TOGOF9.1
Todos los sistemas de interconexin ms all del control del proyecto
Los requisitos reglamentarios, los niveles de clasificacin de la informacin, y las necesidades empresariales de los propietarios de activos influirn el nivel requerido de confianza que se necesitarn todas las entidades interactivas que cumplir para calificar para el acceso a datos o servicios.
Identificar los privilegios mnimos necesarios para cualquier entidad para lograr un objetivo tcnico o empresarial
La concesin de las capacidades de radicales a cualquier usuario, aplicacin, u otra entidad puede simplificar finalizacin transaccin exitosa a costa de complicar o que impiden el control y la auditora eficaz. Muchas obligaciones reglamentarias son ms difciles de demostrar el cumplimiento donde los privilegios estn barriendo y los controles estn sueltos.
Identificar las medidas de mitigacin de seguridad, cuando est justificado por la evaluacin de riesgos
Este objetivo es donde los servicios de seguridad clsicos de identificacin, autenticacin, autorizacin, confidencialidad de datos, integridad de los datos, no repudio, la seguridad y la auditora se ponen en juego, despus de que se determine su aplicabilidad y la relacin costo / valor de la proteccin de su identificacin.
21.9.1 Entradas de seguridad Lista de elementos relacionados con la seguridad del sistema
Lista de los sistemas interconectados Relacin de normas de seguridad aplicables Lista de los actores de la seguridad Estrategia de gestin de riesgos Polticas de seguridad validadas Requisitos reglamentarios validados Polticas de negocio validados relacionados con la confianza requisitos
Las salidas de seguridad 21.9.2 Lista bsica de las tecnologas de seguridad

Lista de sistemas interconectados Validado Lista de las normas de seguridad seleccionadas Plan de conservacin de recursos Mtricas de seguridad y plan de monitoreo
Pgina215de670

TOGOF9.1
Las polticas de autorizacin del usuario Plan de gestin de riesgos La confianza del usuario requisitos (despacho)
21.10 Fase E: Oportunidades y Soluciones

Identificar los servicios de seguridad existentes disponibles para su reutilizacin
A partir de la arquitectura de seguridad de lnea de base y la empresa Continuum, habr infraestructura de seguridad existente y bloques de construccin de la seguridad que se puede aplicar a las exigencias derivadas de este compromiso el desarrollo de la arquitectura. Por ejemplo, si existe el requisito para el control de acceso de la aplicacin externa a una aplicacin en desarrollo, y ya existe un sistema de este tipo, que puede ser utilizado de nuevo. Los requisitos legales o reglamentarios pueden exigir la separacin fsica de los dominios que puede eliminar la posibilidad de volver a utilizar la infraestructura existente. Los productos conocidos, herramientas, bloques de construccin, y los patrones se pueden utilizar, aunque de reciente aplicacin.
Medidas de mitigacin que aborden Ingeniero riesgos identificados
Habiendo determinado los riesgos susceptibles de mitigacin y evaluado la inversin apropiada en que la mitigacin en lo que respecta a los activos en riesgo, las medidas de mitigacin deben ser diseados, implementados, desplegados y / u operados.
Evaluar software de seguridad reutilizables y recursos del sistema de seguridad probado y
Desde el diseo, cdigo, y los errores de configuracin son las races de muchas vulnerabilidades de seguridad, aprovechando cualquier solucin de problemas ya diseada, revisados, probados y probados en campo reducir la exposicin a la seguridad y mejorar la fiabilidad.
Identificar nuevos cdigos / recursos / activos que son apropiados para la reutilizacin
Rellenar el repositorio Arquitectura con nuevos bloques de construccin de la seguridad.

21.11 Fase F: planeamiento de migracin

Evaluar el impacto de las nuevas medidas de seguridad sobre otros componentes nuevos o sistemas apalancados existentes
En una aplicacin gradual de los nuevos componentes de seguridad son generalmente parte de la infraestructura en la que se implementa el nuevo sistema. La infraestructura de seguridad tiene que estar en una primera fase o principios para apoyar adecuadamente el proyecto.
Implementar mtodos de supervisin mediante las cuales se medir la eficacia de las medidas de seguridad y comunicada en forma permanente
Pgina216de670

TOGOF9.1
Durante las fases de operacin, mecanismos son utilizados para monitorear el desempeo de muchos aspectos del sistema. Su seguridad y la disponibilidad no son una excepcin.
Identificar parmetros correctos seguras de instalacin, las condiciones iniciales y las configuraciones
La seguridad de cualquier sistema que no depende del diseo y puesta en prctica por s sola, sino tambin despus de la instalacin y el estado operativo. Estas condiciones deben ser definidas y controladas no slo en la implementacin, sino tambin en toda la operacin.
Implementar la recuperacin de desastres y planes de continuidad del negocio o modificaciones Determinar "lo que puede salir mal?"
21.12 Fase G: Gobernanza Aplicacin

Establecer artefacto arquitectura, el diseo, y las revisiones de cdigo y definir los criterios de aceptacin para la implementacin exitosa de los hallazgos
Muchas vulnerabilidades de seguridad se originan como diseo o errores de cdigo y el mtodo ms simple y menos costosa para localizar y encontrar estos errores es generalmente una pronta revisin por pares con experiencia en el oficio. Localizacin de tales errores, por supuesto, es el primer paso y la aplicacin de correcciones a un punto apropiado en el ciclo de vida de desarrollo es necesaria para beneficiarse de la inversin. Seguimiento de las inspecciones o revisiones de aceptacin formalizados puede justificarse en entornos de alta seguridad o de seguridad crticos.
Implementar mtodos y procedimientos para revisar las pruebas aportadas por el sistema que refleja la estabilidad operativa y la adhesin a las polticas de seguridad
Si bien es necesario que todos los aspectos de una empresa exitosa planificacin y especificacin, son insuficientes ante la ausencia de pruebas y auditora para garantizar el cumplimiento de que la planificacin y especificacin tanto por su despliegue y operacin. Entre los mtodos que se deben ejercer son: Configuraciones del sistema de revisin con impacto en la seguridad que pueden ser modificados para garantizar los cambios de configuracin no se han puesto en peligro la seguridad del diseo Auditar el diseo, la implementacin y las operaciones contra las polticas de seguridad Auditar el diseo, la implementacin y las operaciones contra objetivos de negocio Ejecutar casos de prueba en contra de sistemas que garanticen los sistemas de seguridad se han implementado tal como fue diseado Ejecute las pruebas de recuperacin de desastres Ejecute las pruebas de continuidad de negocio
Implementar la capacitacin necesaria para asegurar la implementacin correcta, la configuracin y el funcionamiento de los subsistemas y componentes relevantes para la seguridad; garantizar la
Pgina217de670

TOGOF9.1
formacin de la conciencia de todos los usuarios y los operadores no privilegiados del sistema y / o sus componentes
La formacin no es necesario simplemente para impedir vulnerabilidades introducidas a travs de operaciones y error de configuracin, aunque esto es crtica para corregir el rendimiento seguro en curso. En muchas jurisdicciones, una formacin adecuada debe realizarse y documentarse para demostrar la debida diligencia y justificar las medidas correctivas o sanciones en los casos en que explota o los objetivos de negocio de compromiso de error o para absolver a la responsabilidad contributiva para los eventos que provocan un dao o lesin.
Determinar "lo que ha ido mal?"
El propsito mismo de la gobernanza es el establecimiento de un sistema de retroalimentacin que determina la eficacia de la ejecucin del plan y aplica correcciones, cuando se requiera. Hay que tener en cuenta que las imperfecciones en los planes ejecutados estn arraigadas tanto en los procesos humanos y los procesos cibernticos.
21.13 Fase H: Gestin Arquitectura Cambio

Como se indica en la Parte II , 17. Arquitectura ADM Requisitos de gestin (gestin de requisitos), el cambio se debe a las nuevas necesidades. Los cambios en los requisitos de seguridad son a menudo ms perjudicial que una simplificacin o cambio incremental. Los cambios en la poltica de seguridad pueden ser conducidos por el estatuto, reglamento, o algo que se ha hecho mal. Los cambios en las normas de seguridad son por lo general menos perjudicial desde el trade-off para su adopcin se basa en el valor de cambio. Sin embargo, los cambios en estndares tambin pueden ser obligatorias. Enfoques similares a estos cambios, como se menciona ms arriba son buenas reglas de oro para la seguridad tambin. Sin embargo, los cambios de seguridad son a menudo los cambios de infraestructura, y pueden tener un mayor impacto. Un cambio aparentemente pequeo requisito de seguridad puede provocar fcilmente un nuevo ciclo de desarrollo de la arquitectura.
Determinar "lo que ha ido mal?"
Buenas prcticas forenses de seguridad en conjunto con una poltica de seguridad publicada por escrito hacen determinacin de lo que ha ido mal posible. Adems, hacen que la aplicacin sea posible. A medida que la orientacin anterior sugiere, pequeos cambios se pueden hacer en el contexto de la gestin del cambio y los principales cambios requerirn un nuevo esfuerzo de la arquitectura.
Incorporar los cambios pertinentes a la seguridad para el medio ambiente en los requisitos para la futura mejora (mejora de objetivo existente)
Los cambios que surgen como consecuencia de un problema de seguridad o una nueva tecnologa de seguridad se utilizarn en el proceso de gestin de requisitos.
21,14 Referencias
NIST 80018: Gua para el desarrollo de Planes de Seguridad para Sistemas Informticos
Pgina218de670

TOGOF9.1
NIST 80027: Principios de Ingeniera de Tecnologas de Seguridad Informtica (una lnea de base para el logro de la seguridad) NIST 80030: Gua para la Gestin de Riesgos de Sistemas Informticos
Pgina219de670

TOGOF9.1
22. Uso de TOGAF para definir y Gobierno SOAs 22.1 Informacin general
En este captulo se describen: Service-Oriented Architecture (SOA) como un estilo arquitectnico Factores relacionados con la adopcin y la implementacin de SOA en la empresa Usando el TOGAF Arquitectura Mtodo de Desarrollo (ADM) para desarrollar su SOA
En este captulo, en su caso, se incluyen referencias a las Normas Tcnicas y Guas desarrolladas por el Grupo de Trabajo SOA Open Group.
22.2 Introduccin
A medida que el ambiente de negocios se vuelve ms sofisticada, los desafos que enfrentan las organizaciones estn pasando de cuestiones de eficiencia y automatizacin hacia las cuestiones de la gestin de la complejidad y la agilidad del negocio. Redes complejas de aplicaciones e interfaces existentes crean paisajes de gran complejidad donde el cambio se vuelve ms y ms difcil y los impactos del cambio se vuelven ms difciles de predecir y entender. El concepto de SOA ofrece un estilo arquitectnico que se destina especficamente para simplificar el negocio y la interoperacin de diferentes partes de ese negocio. Al estructurar la capacidad de los servicios significativos, granulares en oposicin a, unidades de negocio silo'ed opacos, se hace posible identificar rpidamente las capacidades funcionales de una organizacin, evitar la duplicacin de funciones similares a travs de la organizacin y de montar rpidamente nuevas capacidades. Al estandarizar el comportamiento y la interoperabilidad de los servicios, es posible limitar los efectos del cambio y tambin para entender por adelantado la cadena de probabilidades de impactos. Desde una perspectiva de desarrollo de software, SOA se centra en las aplicaciones de la estructuracin de una manera que facilita la flexibilidad del sistema y la agilidad - Una necesidad en el entorno complejo y de rpido movimiento de hoy del negocio. SOA pretende romper los silos de aplicaciones tradicionales en las carteras de servicios ms granulares que operan en formas abiertas e interoperables, mientras que la extraccin de la capacidad de los productos bsicos en una plataforma de infraestructura virtual de los servicios pblicos reutilizables compartidos.
Pgina220de670

TOGOF9.1
22.3 SOA Definicin

Nota: Esta seccin se proporciona para conveniencia del lector. Parte I , 3. Definiciones deberan remitirse a las definiciones formales. Arquitectura Orientada a Servicios (SOA) es un estilo arquitectnico que apoya la orientacin a servicios. La orientacin a servicios es una manera de pensar en trminos de servicios y el desarrollo basado en el servicio y los resultados de los servicios. Un servicio es una representacin lgica de una actividad de negocio repetible que tiene un resultado especfico (por ejemplo, verificacin de crdito del cliente, proporcionar datos meteorolgicos, consolidar los informes de perforacin, etc) y: Es autnomo Puede estar compuesto de otros servicios Es un "recuadro negro" para los consumidores del servicio
Un estilo arquitectnico es la combinacin de caractersticas distintivas en que se realiza o se expresa la arquitectura.
22.4 Caractersticas de SOA

SOA se basa en el diseo de los servicios - que reflejan las actividades empresariales del mundo real - que comprenden la empresa (o entre empresas) los procesos de negocio. Representacin del Servicio utiliza descripciones empresariales para proporcionar el contexto (es decir, los procesos de negocio, meta, regla, poltica, interfaz de servicio, componente de servicio, etc.) SOA coloca requisitos nicos de la infraestructura. Debido a esto, se recomienda que las implementaciones utilizan estndares abiertos para darse cuenta de la interoperabilidad y la transparencia de ubicacin. Por ejemplo, la disponibilidad de servicios de alguna manera debe ser documentado en un lugar de fcil acceso en las que requieren el uso de esos servicios. Un servicio de directorio en SOA especfico y un Enterprise Service Bus (ESB) son dos ejemplos de implementaciones de tecnologa que requieren la adhesin a los estndares abiertos relevantes para la interoperabilidad que SOA promete. Las implementaciones son especfica del entorno de la empresa - que se ven limitados o habilitadas por el contexto y deben ser descritas dentro de ese contexto. Teniendo en cuenta que, SOA requiere un gobierno fuerte de la representacin de servicios y la ejecucin.
22.5 Arquitectura Empresarial y SOA
Pgina221de670

TOGOF9.1
Arquitectura Enterprise proporciona marcos, herramientas y tcnicas para ayudar a las organizaciones en el desarrollo y mantenimiento de sus SOAs. Algunos de los beneficios clave que la arquitectura empresarial ofrece son: Abstracciones coherentes de estrategias de alto nivel y las prestaciones de apoyo a la planificacin y el anlisis Vinculacin de las diferentes perspectivas a un problema de negocio nico (por ejemplo, los negocios, los sistemas de informacin, la tecnologa, la amplitud, la profundidad, el nivel de detalle, etc) que proporcionan un modelo coherente para hacer frente a diversos dominios y pruebas de integridad Identificacin de las hojas de ruta claras para lograr el estado futuro Trazabilidad que las TI y otros activos se vincula a los negocios que apoyan El apoyo a la evaluacin del impacto, anlisis de riesgo / valor, y la gestin de carteras Principios identificados y documentados, las limitaciones, los marcos, patrones y normas Los marcos de gobernanza y procesos que aseguren la autoridad competente para la toma de decisiones
Arquitectura empresarial se convierte en una base para el servicio-orientar una organizacin, porque vincula partes interesadas, asegurando que las necesidades de cada comunidad de partes interesadas que se cumplan y que cada comunidad de interesados es consciente del contexto apropiado. Esta vinculacin es la base para la interoperabilidad y la reutilizacin. A travs de su vinculacin al contexto empresarial para TI, arquitectura empresarial permite identificar con facilidad y proporciona justificacin para el costo de los programas de cambio en relacin con el valor de negocio que se derivan de la pena. Arquitectura empresarial puede proporcionar las capacidades de contexto y anlisis de: Mostrar cmo las soluciones de SOA pueden con arquitectura eficaz para apoyar las capacidades empresariales Mostrar que los servicios deben ser construidos y que se debe volver a utilizar Mostrar cmo los servicios deben ser diseados
Sin arquitectura de la empresa, los efectos negativos pueden incluir uno o ms de los siguientes: Agilidad Limited Dificultad para la identificacin y la orquestacin de servicios SOA La expansin de servicios Crecimiento exponencial desafos de la gobernanza Limited interoperabilidad de servicios SOA SOA servicio de reutilizacin limitada
Pgina222de670

TOGOF9.1
Mltiple silo'ed SOAs Dificultad evolucionando y cambiando las implementaciones de SOA
22.6 SOA y Niveles

El tamao y la complejidad de una empresa afecta a la forma en que la EA desarrolla su arquitectura. Donde hay muchos diferentes modelos organizativos y empresariales, no es prctico para integrarlos dentro de una nica arquitectura. Hay muy pocos elementos de la infraestructura, con la excepcin de la Internet y la World Wide Web, quese pueden aplicar en la totalidad de una gran organizacin. Incluso stos slo proporcionan un nivel bsico de apoyo a los procesos de negocio. En general, puede no ser apropiado para desarrollar un nico SOA integrada para una empresa grande y compleja. Para tal empresa, asumiendo una arquitectura del paisaje como se muestra en la Figura 20-1 , el arquitecto debe buscar primero en el desarrollo de una arquitectura estratgica que da un resumen descripcin formal de la empresa, proporcionando un marco de organizacin de la actividad operativa y el cambio, y un ejecutivo nivel, visin a largo plazo para el ajuste de la direccin. Esto podra, por ejemplo, identificar segmentos particulares donde se debe utilizar SOA, y la convocatoria de uso de los servicios para la interaccin entre los segmentos, pero es muy poco probable para especificar determinados servicios o grupos de servicios, o para prescribir una infraestructura detallada para SOA. El arquitecto podra entonces desarrollar arquitecturas de segmentos, cada uno de los cuales da una descripcin detallada y formal de las reas dentro de una empresa, que se utiliza a nivel de programa o de una cartera de organizar y alinear la actividad de cambio. Cada una de estas arquitecturas segmento podra ser un nico, SOA integrada. Para una empresa pequea y menos compleja cuyo negocio operaciones puede compartir una infraestructura comn, puede usar TOGAF para crear una SOA integrada con grupos de servicios de apoyo a las actividades empresariales. A partir de aqu se supone que el alcance sea una empresa de este tipo. Podra ser autopermanente o de un segmento de una empresa ms grande.
22.6.1 Nivel de detalle de Especificacin de Implementacin

Cmo se debe por completo la arquitectura de definir lo que para poner en prctica? En un extremo, se podra especificar el futuro de la empresa, y definir todos los cambios para alcanzar el objetivo, incluidos los proyectos que producirn los cambios, y un plan detallado de tiempo. En el otro extremo, slo puede indicar reas donde se necesita trabajo, y sugerir prioridades para abordarlos. Arquitectura desarrollo podra caer en cualquier lugar entre estos dos extremos. Para el tipo de SOA empresarial que estamos considerando aqu, es probable que se especificara la infraestructura y definir los proyectos para su ejecucin, con un plan detallado de tiempo. Usted puede hacer lo mismo para todas o algunas de las soluciones. Por otra parte, en particular cuando la agilidad es importante, es posible identificar las soluciones, y tal vez especifica las versiones iniciales de los mismos, pero permiten soluciones adicionales para ser identificados ms tarde, y para los proyectos de implementacin para desarrollar ms versiones de las soluciones sin tener que pedir cambios en el arquitectura.
Pgina223de670

TOGOF9.1
22.6.2 Actividades de SOA en los diferentes niveles
En el mbito de la arquitectura estratgica de la cuestin bsica de SOA es identificar si necesita SOA y en la que los segmentos. En la arquitectura estratgica que identifique: Las relaciones de alto nivel y los lmites dentro de la organizacin (Se necesita qu informacin y funcionalidad a travs de segmentos) los requisitos de capacidad SOA Cross-segmento Entre las principales funcionalidades mejor tratadas por SOA Las capacidades clave necesarias para SOA Segmentos mejor abordados por SOA Principios y patrones de desarrollo de los servicios SOA y la descripcin, que pueden ser definidas a nivel de segmento y la capacidad Las funciones, responsabilidades, procesos y herramientas de gobierno de SOA La Arquitectura de referencia especfica de la organizacin
A nivel de segmento la cuestin bsica de SOA describe la estructura de la arquitectura SOA. En las Arquitecturas Segmento definimos: Qu capacidades utilizarn SOA como un estilo de la arquitectura (Se necesita qu informacin y funcionalidad a travs de capacidades) relaciones cruzadas de capacidad (Se necesita qu informacin y funcionalidad a travs de segmentos) relaciones ms detalladas segmentacin cruzada Servicios SOA Cross-capacidad de las posibilidades de reutilizacin Principios y patrones de desarrollo de los servicios SOA y la descripcin, que pueden ser definidos en el Plan Estratgico y los niveles de capacidad; es ms comn para definir estos como parte de la arquitectura del Segmento
Para Arquitectura Capability la cuestin bsica de SOA es que los servicios estarn disponibles. En las arquitecturas de capacidad describiremos: Los requisitos funcionales y no funcionales de la capacidad Requisitos de servicio SOA Cross-capacidad Servicios SOA que permiten cruzada capacidad de reutilizacin Servicios SOA que permiten la capacidad Principios y patrones de desarrollo de los servicios SOA y la descripcin, que pueden ser definidos a nivel estratgico y de segmento
Pgina224de670

TOGOF9.1
Independientemente del nivel de ser perseguido arquitectura es posible identificar soluciones SOA que mejor servicio de las necesidades de la empresa.
22.7 Uso de TOGAF para SOA

En esta seccin se describe, para cada fase del TOGAF ADM, lo que debe considerarse cuando se busca aplicar el principio de la orientacin a servicios, y cmo esto afecta a la fase. Esto no pretende ser una descripcin autnomo y debe leerse en conjuncin con otras secciones de este documento.
22.7.1 Fase Preliminar

La fase preliminar es cuando la capacidad Arquitectura est adaptado para soportar SOA. Los resultados clave de esta fase son los principios, la estructura organizativa, la gobernanza y el contenido inicial de la arquitectura de repositorio.
22.7.1.1 Principio de la Orientacin a Servicios
El punto de partida para el desarrollo de SOA con TOGAF es que la empresa adopta la orientacin a servicios, como principio la arquitectura (vase el Principio 6: Servicio de Orientacin ). Una empresa que desee utilizar TOGAF para SOA debe incluir este principio, ya sea en su forma actual o con modificaciones, en su conjunto de principios de arquitectura. Si el arquitecto es la introduccin de TOGAF a una empresa que ya est comprometido con SOA, o que es parte de una empresa ms grande que se ha tomado la decisin estratgica de utilizar SOA, a continuacin, la adopcin del principio de la orientacin a servicios es sencillo. Si, por el contrario, SOA se est introduciendo a una empresa que no est comprometido con l, entonces la decisin de adoptar este principio no debe tomarse a la ligera. El xito de SOA depende en parte de la disposicin de la empresa para convertirse orientada a servicios. La organizacin puede llevar a cabo una evaluacin de la madurez de SOA en la fase preliminar, utilizando el Modelo de Madurez de Integracin de Servicios Open Group (OSIMM) como parte de la revisin del contexto de la organizacin para la realizacin de la arquitectura empresarial. Esto ayudar a establecer los fundamentos de la empresa a adoptar el principio de la orientacin a servicios. A pesar de que una empresa puede estar comprometida con SOA, no siempre es conveniente utilizar el estilo SOA para hacer frente a todos los problemas de la arquitectura. A medida que la seccin sobre los niveles identificados segmentos especficos o capacidades pueden ser mejor servidos por SOA en una organizacin de otra manera no comprometida; o segmentos o capacidades especficas pueden no ser adecuados para SOA en una organizacin comprometida con SOA. A partir de aqu se supone que se adopta el principio de la orientacin a servicios.
22.7.1.2 Gobernabilidad y estrategia de apoyo
Una revisin debe ocurrir de los procedimientos de gobierno existentes, lo que confirma que son apropiadas para SOA. Si no lo son, entonces se deben hacer recomendaciones para el cambio para que sean apropiadas.
Pgina225de670

TOGOF9.1
The Open Group cuenta con un marco de gobernanza estandarizado que se centra en la SOA y puede ser utilizada para mejorar los marcos de gobernanza existentes (ver El Gobierno Open Grupo SOA Framework Norma Tcnica). Esto proporciona un modelo de referencia de alto nivel de cmo se extiende el gobierno de SOA y es compatible tanto con la arquitectura empresarial y de gobierno de TI. Tambin incluye un mtodo de vitalidad Gobernabilidad SOA (SGVM) que se puede utilizar para definir un rgimen especfico de gobierno de SOA adaptado a la visin de la organizacin de la gobernanza.
Figura221:ElMarcodeGobernabilidadSOAOpenGrupo
22.7.1.3 Particiones y Centros de Excelencia
Diferentes equipos trabajarn en los diferentes elementos de la arquitectura al mismo tiempo. Las particiones permiten a grupos especficos de los arquitectos a poseer y desarrollar elementos especficos de la arquitectura. Se sugiere que el equipo se inicia con una iniciativa enfocada antes de implementar en una amplia escala. El equipo responsable de SOA inicialmente debe estar estructurado como un Centro de Excelencia (CoE). Un xito CoE tendr varios atributos clave: Una clara definicin de la misin del Consejo de Europa: por qu existe, de su mbito de responsabilidad, y lo que la organizacin y la prctica de la arquitectura debe esperar del Consejo de Europa. Metas claras para el Consejo de Europa, incluyendo mediciones e indicadores clave de rendimiento (KPI). Es importante asegurarse de que las medidas y KPI del Consejo de Europa no conducen la seleccin inadecuada de SOA como el estilo de la arquitectura. El CoE ofrecer la "prueba de fuego" de un buen servicio. El CoE difundir los conocimientos, experiencia y capacidades del Centro de SOA para el resto de la prctica de la arquitectura.
Pgina226de670

TOGOF9.1
Identificar cmo los miembros del Consejo de Europa, y otros profesionales de la arquitectura, sern recompensados por el xito. El reconocimiento de que, al comienzo, es poco probable que la organizacin va a tener las habilidades necesarias para crear un Centro de Excelencia en pleno funcionamiento. Las habilidades y la experiencia necesarias deben ser cuidadosamente identificados, y donde no estn presentes, adquirieron. Una habilidad fundamental para destacados profesionales dentro del Consejo de Europa es la capacidad de guiar a otros profesionales de la transferencia de conocimientos, habilidades y experiencia. Primer plan de cuenta cuando el Consejo de Europa ha cumplido su propsito.

22.7.1.4 Arquitectura Repositorio
. Hay una serie de recursos SOA que se debe considerar cuando inicialmente poblar el repositorio de Arquitectura como se describe en la arquitectura de referencia SOA Open Group (vase La SOA Source Book Open Group) Estos incluyen: Los ladrillos de la SOA , que describe un conjunto de ABBS que representan los elementos clave de SOA Una perspectiva de alto nivel de la arquitectura de referencia de SOA , lo que da una visin general de las nueve capas de la arquitectura de referencia, con ejemplos y razones que describen las principales responsabilidades de las capas y sus bloques de construccin primarios Detalladas bloques de construccin de la arquitectura de referencia de SOA , que presenta modelos detallados que muestran cmo algunas de las caractersticas de SOA se puede implementar utilizando la arquitectura de referencia Infraestructura para SOA , que describe Arquitectura Bloques de Construccin (Abs) que corresponden a los productos de infraestructura que estn disponibles hoy para apoyar las aplicaciones orientadas a servicios Industria Normas de SOA , como el marco de integracin de TeleManagement Forum
Un grfico de alto nivel que se describe la arquitectura de referencia SOA Open Group sigue:
Pgina227de670

TOGOF9.1
Figura222:LaarquitecturadereferenciaSOAOpenGroup
22.7.2 Fase A: Architecture Vision
La descripcin de alto nivel se produce en la fase A reflejar la naturaleza orientada al servicio de la arquitectura que se prevea. Una diferencia obvia entre una descripcin de la arquitectura SOA y una descripcin de una arquitectura de otro estilo es el idioma. La descripcin SOA utiliza un lenguaje diferente, con palabras tales como "poltica", "composicion", y "tarea", y cuenta con diferentes modelos, tales como matrices que muestran el uso de los servicios por parte de los procesos de negocio y el uso de aplicaciones de servicios. The Open Group SOA ontologa proporciona una taxonoma y ontologa para SOA. En un proyecto de SOA es importante para garantizar que las partes interesadas comprendan las implicaciones de SOA y se preparan para el impacto de la organizacin de los servicios de SOA componibles. Este impacto es aplicable si los servicios de SOA estn disponibles como aplicaciones heredadas envueltos, utilizando los servicios expuestos a los productos comprados, servicios a medida, Cloud Computing Software as a Service (SaaS), etc
22.7.2.1 Las partes interesadas, inquietudes y requerimientos de negocio
Los interesados que consulten los requisitos para hacer frente, y los modelos, artefactos y puntos de vista para el desarrollo varan de un compromiso de la arquitectura a otra. Existen algunas preocupaciones que son especficos de SOA, o que son ms propensos a surgir en la evolucin de SOA. Las preocupaciones de los interesados direccionamiento en SOA seccin de la SOA Source Book Open Group es un buen recurso para hacer frente a este tema.
Pgina228de670

TOGOF9.1
22.7.3 Arquitectura de Desarrollo: Fases B, C, y D
En esta seccin se considera el impacto de SOA en las fases B, C y D, los dominios de desarrollo de arquitectura. La siguiente grfica de los TOGAF identifica el contenido Metamodel (sealados en rojo) las entidades que son clave para SOA.
Figura223:EntidadesdeSOAenelMetamodelcontenido
Personas clave incluyen: Evento Proceso Servicios de Negocio Es el servicio Plataforma de servicios
Pgina229de670

TOGOF9.1
Lgico Aplicacin y Tecnologa de componentes Aplicacin y Tecnologa Componente Fsico Entidad de datos Papel Calidad de Servicio Contrato Ubicacin Informacin de contacto (no en el metamodelo) Lgico Componentes de la informacin (no en metamodelo) Reglas de Negocio (no en el metamodelo)
Extensiones del metamodelo son tpicamente necesarios para apoyar plenamente SOA. Lo que sigue para cada dominio es una descripcin de los artefactos que son apropiados para el desarrollo de la empresa del arquitecto de una SOA.
Fase B: Arquitectura de Negocios
El punto de partida de los artefactos que se desarrollan en esta fase es el conjunto de requisitos empresariales clave identificadas en la Fase A. Para el tipo de SOA empresarial que estamos discutiendo aqu, los siguientes artefactos deben ser considerados para SOA, ya que contribuyen a la definicin de bloques de construccin de SOA en la fase C y la fase D.
Artefacto Business Service Interaction Diagrama Propsito Entidades Metamodel
Este diagrama muestra todos los Servicios comerciales, contratos, servicios a las empresas en el alcance informacin de negocios y sus relaciones y de la informacin que fluye entre los servicios de (Business Information es mencionado en la oficina. Se indicar cules son los Fase B, pero no hay una entidad servicios de negocio son comnmente metamodelo.) reutilizados por otros servicios de negocios que indica las oportunidades para su posible reutilizacin de apoyo a los servicios de SI.
El diagrama tambin se utiliza para definir los procesos de negocio y las relaciones entre los procesos de negocio, ya que cada proceso est compuesto por un subconjunto de este modelo. Diagrama de Procesos Se trata de un conjunto de diagramas de Negocio que muestran los procesos de negocio y su descomposicin, sus interacciones, as como la informacin con la que se refiere.
Subconjunto de Servicio Modelo de Negocio que muestra los servicios de negocios y contratos involucrados en los procesos y la informacin de la empresa pas entre las Empresas de Servicios.
Pgina230de670

TOGOF9.1
Catlogo de vocabulario Esta es una lista de los principales Esta es una lista de elementos de de negocios trminos utilizados en la descripcin de informacin de negocios y las los procesos de negocio y la descripciones de los elementos. informacin. Es importante que la fase de la arquitectura de negocios (Business Information es mencionado en la establece el contexto de informacin Fase B, pero no hay una entidad para los servicios de software, segn metamodelo.) se describe en la Arquitectura de la Informacin para SOA seccin del libro Fuente Open Group, y un catlogo de trminos de negocios es una parte importante de este contexto. El vocabulario de negocios puede derivarse mientras que el desarrollo del modelo de servicio de negocio. Servicios comerciales Esta es una lista de los servicios de Listado de Empresas de Servicios y sus catlogo negocio de la empresa y sus requisitos calidades de servicio no funcionales. Se utiliza para analizar los requisitos no funcionales. Business Service / Para entender de dnde los servicios Business Service, Ubicacin Location Catlogo empresariales deben ser ejecutados. Catlogo Evento / Para entender qu proceso se ejecuta Listas de eventos y sus negocios efectuada Proceso en relacin con un evento. Proceso Catlogo Calidad Para entender las propiedades no Listas de contratos y sus calidades de contrato / servicio funcionales de un contrato. servicio pertinentes Business Service Para mostrar las relaciones entre los Servicios comerciales en ambos ejes y Interaction Matrix servicios empresariales. Contratos en el punto de cruce Business Service / Para mostrar cmo los elementos de Servicios comerciales y elementos de Matrix Informacin informacin son utilizados por Servicios Informacin Empresarial (CRUD) comerciales y de encontrar fallas en ese modelo. (Business Information es mencionado en la Fase B, pero no hay una entidad actual metamodelo TOGAF.) Para definir la estructura lgica de la Elementos de informacin de negocios, informacin en la organizacin. Puede Componentes de la informacin lgica y ser utilizado como insumo para el sus relaciones modelo de intercambio de definir las entradas y salidas de los servicios (Ninguno de ellos existe en el metamodelo SOA. actual.)
Informacin de los componentes del modelo
Los puntos de vista apropiados se deben producir para poder demostrar a las partes interesadas sobre cmo se tratan sus preocupaciones en SOA especficos relacionados con la Arquitectura Empresarial. Al hacer esto, el arquitecto se ocupa de las necesidades que pueden ser satisfechas por la Arquitectura Empresarial. Los requisitos de arquitectura restantes se abordarn en la fase C y la fase D.
Fase C: Arquitecturas de Sistemas de Informacin
La fase se divide en dos sub-fases, Arquitectura de datos y aplicaciones de arquitectura. SOA hace poca diferencia a la sub-fase de Arquitectura de datos, pero tiene un impacto importante en la arquitectura de aplicaciones. Adems de afectar los artefactos que se desarrollan, las vistas que se producen, las preocupaciones que se discuten, y los requisitos que se identifican, SOA afecta la manera en que el arquitecto hace el anlisis de la brecha entre la lnea de base y las arquitecturas objetivo en la Fase C.
Pgina231de670

TOGOF9.1
Con SOA, las aplicaciones de software tradicionales se sustituyen por conjuntos de servicios dbilmente acoplados. Las aplicaciones existentes todava deben describirse, como deberan las nuevas aplicaciones de las especies tradicionales que se requieren, y estas aplicaciones deben ser incluidos en la cartera de aplicaciones. Adems, se deben identificar las reas de funcionalidad de las aplicaciones que estn cubiertos por los servicios. Estos sern (probablemente como parte de la implementacin) pueden descomponer en los servicios, que se incluirn en la cartera de servicios. Pero SOA no es slo acerca de los servicios, es tambin las soluciones creadas mediante el uso de combinaciones de servicios. Estas soluciones se suelen estructurarse utilizando los procesos de negocio y servicios de negocio definidos en la Fase B.
Fase C artefactos SOA especfico Artefacto Es el servicio de Interaccin Diagrama Propsito Uso Metamodel Entidad Esto muestra los requisitos para los servicios Son los servicios y los contratos entre potenciales de SOA (IS Services) y las ellos interacciones entre ellos, y su uso de la informacin. Se utiliza para mostrar el conjunto Los contratos indican lo Business completo de los requisitos para la solucin y Information es las relaciones entre los requisitos. comunicado.Preferiblemente, la entidad
de Calidad de Servicio para los dos es el de servicios y los contratos se deriva de las actividades empresariales y sus contratos y las calidades de servicio relacionados. Business Process / IS Esta matriz muestra la relacin entre cada uno Procesos de Negocio y su relacin con el Matrix Servicio de Procesos de Negocio y de los servicios es servicio IS (s) apoyar el proceso. Se utiliza para mostrar el conjunto completo de los requisitos para los servicios de SOA para un negocio determinado proceso. ES Catalog Service El catlogo muestra todos es el de servicios, Lista de servicios de SI y sus calidades de Contract sus contratos, y las calidades de servicio servicio relacionados relacionados para permitir el anlisis de los requisitos no funcionales (por ejemplo, la Adems, son los contratos de servicio seguridad, el rendimiento, la carga, la para cada uno es el servicio estn disponibilidad, polticas, etc) para los posibles incluidos. servicios SOA. Este catlogo es un insumo importante para el proceso de la Cartera de Servicios de Gestin en la gobernabilidad de SOA. Es el servicio / Este catlogo se conecta es el de servicios Es el servicio (s), Contratos relacionados, aplicacin de catlogo (potenciales servicios SOA), Contratos, y y calidades de servicio relacionados con (existente) calidades de servicio con las aplicaciones tal y como son componentes de aplicacin existentes (tal cual Fsica componentes de la fsica aplicacin). Se utiliza para especificar los escenarios envolventes en las aplicaciones existentes y analizar los requisitos no funcionales. ES Servicio / Data Esta matriz muestra qu datos est a cargo de ES Services y sus entidades de datos Matrix Entidad los posibles servicios SOA (es el de relacionados servicios). Se utiliza para identificar potenciales de tratamiento de datos Servicios de SOA. Lgico SOA Matriz de Esta matriz muestra la relacin entre la SOA Es el de servicios, Logical componentes
Pgina232de670

TOGOF9.1
componentes componentes lgicos (Logical componentes de de aplicacin, y los principios y Drivers aplicacin) y los potenciales servicios SOA (es negocios (utilizadas para encontrar el de servicios). Se utiliza para estructurar los criterios que realiza una agrupacin) componentes lgicos de los requisitos. Un SOA componentes lgicos (componente de aplicacin de lgica), sera un candidato para un servicio en arquitecturas SOA a nivel de capacidad. Este diagrama muestra las relaciones entre los Componentes y Contratos aplicacin componentes lgicos de SOA (componentes lgica y sus calidades de servicio de la aplicacin lgica) y otras soluciones lgicas (Logical componentes de la Componentes tecnolgicos lgicas y su aplicacin). Se utiliza para mostrar y analizar asignacin a los contratos se utilizan para los requisitos funcionales y no funcionales de los mecanismos de interfaz. las interfaces entre las soluciones. Esta matriz muestra los servicios distribuidos Es el servicio, Logical componente de en ubicaciones fsicas para satisfacer el aplicacin, Fsica componente de requisito legal o de otro tipo. El objetivo es aplicacin, y ubicacin mostrar y analizar si existen requisitos de ubicacin en servicios. Esto se puede hacer en cualquiera de estos casos los servicios o componentes de aplicacin lgicos.
Lgico SOA Solution Diagrama
Matriz de distribucin de Servicio
El uso de los artefactos, el arquitecto debe desarrollar puntos de vista que muestran a los interesados cmo se tratan sus preocupaciones en SOA especficos relacionados con la Arquitectura de Aplicaciones. Los modelos que permitan la discusin de las preocupaciones relacionadas con la Arquitectura de datos tambin deben desarrollarse como parte de la Fase C. Estos son similares a los modelos que se desarrollaran de una arquitectura tradicional basada en las aplicaciones de software. Al hacer esto, esto responde a las necesidades que pueden ser satisfechas por los sistemas de informacin Arquitecturas. Los requisitos de arquitectura restantes se abordarn en la Fase D: Architecture Tecnologa. En cada una de las fases B, C, y D un anlisis de brechas se debe realizar entre la lnea de base y Target Arquitecturas para determinar lo que hay que hacer para pasar de la lnea de base a la meta. Para las fases B y D, y la sub-fase Arquitectura de datos de la Fase C, esto no se ve muy afectado por la SOA. Para las aplicaciones Arquitectura subfase de la Fase C, sin embargo, SOA hace una diferencia en la forma en que se realiza el anlisis de las lagunas. Los ABBS definidos en la Fase C se incluyen aplicaciones y grupos de servicios que cubren las reas de funcionalidad de las aplicaciones tradicionales. Ambos tipos de bloque de construccin deben ser incluidos en el anlisis de las lagunas. Sin embargo, puede ser la intencin de que un grupo de servicios puede implementar como una "envoltura" sobre las aplicaciones existentes. Esta situacin, que es especial para SOA, debe indicarse en el anlisis de las deficiencias, as como las situaciones en que han de ser removido o sustituido, o nuevas aplicaciones se vayan a aadir aplicaciones antiguas.
Fase D: Architecture Tecnologa
Para SOA, la arquitectura de la tecnologa define el software y la infraestructura de hardware necesaria para apoyar la cartera de servicios. Un punto de partida para la Tecnologa de la
Pgina233de670

TOGOF9.1
Arquitectura es la arquitectura de referencia SOA Open Group, que contiene la mayora de los servicios posibles plataformas para una infraestructura SOA.Cada organizacin tendr que personalizar la arquitectura de referencia de SOA a sus necesidades.
Artefactos Fase D-SOA especfico Artefacto Propsito Uso Metamodel Entidad Tecnologa Lgica Este esquema se utiliza para mostrar y Servicio de Plataforma (Capability), Diagrama de la analizar el caso de la arquitectura de Logical Componente Tecnologa (ABB) arquitectura referencia SOA Open Group. Contendr todos ABBS y capacidades que se consideren necesarias para la solucin SOA. Lgico Aplicacin y Esta matriz se utiliza para mostrar y analizar Componentes aplicacin lgica y sus Tecnologa Matrix las relaciones entre los componentes de relaciones con los componentes lgicos aplicacin lgicos y los componentes de tecnologa, incluyendo derivaciones tecnolgicos lgicas para asegurar el de las calidades de servicio arquitecto entienda lo que la tecnologa se utilizar para los componentes de aplicacin lgicos. Tambin se utiliza para obtener y validar los requisitos no funcionales para los componentes tecnolgicos.
The Open Group ha producido informacin adicional relativa a la adaptacin de la infraestructura de una organizacin para la orientacin a servicios, incluida la infraestructura orientada a servicios Open Group (SOI) Modelo de referencia (consulte El SOA Source Book Open Group para gua). El uso de los artefactos y SOI modelo de referencia, el arquitecto debe desarrollar puntos de vista que muestran a los interesados cmo se tratan sus preocupaciones en SOA especficos relacionados con la Tecnologa de la Arquitectura. Al hacer esto, el arquitecto aade requisitos adicionales a los identificados en las Fases A, B y C, y se ocupa de las necesidades que pueden ser satisfechas por la Arquitectura de Tecnologa. Todos los requisitos de arquitectura deberan haber sido abordados por el final de esta fase. Si todava hay requisitos de arquitectura pendientes, entonces es necesario volver a la Fase B o Fase C para hacerles frente. Requisitos para la aplicacin sern abordados por los proyectos que se han identificado en la Fase E.
Fase E: Oportunidades y Soluciones
La identificacin de soluciones SOA es una tarea clave para SOA. Las preguntas de qu soluciones SOA de la empresa tendr, y cmo van a ser gestionados, deben ser considerados en esta fase. Opciones de entrega de soluciones se consideran normalmente como parte de esta fase. Una opcin de la entrega que se debe considerar en particular para SOA es el uso de los servicios prestados por empresas externas, en comparacin con el desarrollo de los servicios en la empresa o la adquisicin de productos de software que realizan los servicios.
Fase artefactos SOA especfico E Artefacto Fsica SOA Solution Matrix Propsito Uso Metamodel Entidad Esta matriz muestra la relacin entre las SE Services, componentes de aplicacin soluciones fsicas SOA (Fsica lgica, fsica componentes de la aplicacin
Pgina234de670

TOGOF9.1
componentes de la aplicacin) y la lgica y los principios y Negocio Drivers (usado SOA Componentes. Se utiliza para definir para encontrar criterios que hacer la estructura fsica de la solucin de SOA. estructuracin) Fsica Solucin Este diagrama muestra las relaciones Componentes y Contratos aplicacin fsica Diagrama de SOA entre la solucin SOA fsica (Physical y sus calidades de servicio componentes de aplicacin) y otras soluciones (componentes de la aplicacin Tecnologa Fsica Componentes y su fsica). Se utiliza para mostrar y analizar correlacin con los contratos se utilizan los requisitos funcionales y no para los mecanismos de interfaz. funcionales de las interfaces entre las soluciones. Servicio de Fsica Esta matriz muestra que se vuelven a ES Servicios, Fsica componentes de Matrix Solution utilizar los servicios existentes, que aplicacin (tal y como son los servicios de servicios pueden ser proporcionados por SOA para su reutilizacin), otra aplicacin los servicios externos (SaaS), y que los fsica Componentes (nuevos y existentes servicios deben desarrollarse como aplicaciones que pueden envolver), y envolturas de nuevas aplicaciones / nuevos componentes de aplicacin fsica existentes y cuales necesitan ser (nuevos servicios a ser desarrollados o desarrolladas. adquiridos externamente) Se trata de una contribucin al proceso de Gestin de la cartera de servicios de Gobierno SOA. Pautas de Este documento proporciona directrices aplicacin sobre cmo desarrollar soluciones y servicios SOA. Sugerencias de posibles directrices se pueden encontrar en el Apndice A del marco de gobernanza Open Grupo SOA. Tecnologa Fsica Este diagrama se utiliza para mostrar y Plataforma de Servicios, Tecnologa Diagrama de la analizar la solucin tcnica fsica para la Componente lgico, Tecnologa arquitectura infraestructura SOA. Componente Fsico Aplicacin y Esta matriz se utiliza para mostrar y Componentes de aplicaciones fsicas y sus Tecnologa Fsica analizar la infraestructura fsica se utiliza relaciones con Componentes tecnologa Matrix para ejecutar la aplicacin fsica y para fsica, incluyendo derivaciones de las garantizar que los requisitos no calidades de servicio funcionales son derivados adecuadamente y entendidas. Catlogo Cartera Esta es una lista de productos y tipos de Fsica componentes de aplicacin y su Tecnolgica productos que se utilizarn en la relacin con calidades de servicio ejecucin, incluida la infraestructura de SOA en tiempo de ejecucin, entorno de desarrollo de SOA, la tecnologa de componentes de servicio, y la interfaz de servicio (portal, el canal, etc) la tecnologa. Tambin incluir los requisitos no funcionales. Directrices Este documento proporciona directrices Tecnologa sobre el uso de la infraestructura SOA.Sugerencias de posibles directrices se pueden encontrar en el Apndice A del marco de gobernanza Open Grupo SOA.
Los proyectos de implementacin que se identifican, y la estrategia de implementacin y migracin, dependern de las decisiones tomadas en el nivel de detalle de la especificacin de implementacin, cuando el equipo de arquitectos de mbito del desarrollo de la arquitectura en la Fase A.
Pgina235de670

TOGOF9.1
Fase C: planeamiento de migracin
El modelo de gobierno de aplicacin se revisa en la Fase F con el fin de asegurarse de que est en su lugar antes de la siguiente fase - Gobierno Implementacin - comienza. SOA requiere de reglas y procedimientos de gobierno en particular. La estrategia de gobierno y el apoyo se revisa en la Etapa Preliminar. Si necesita ser actualizado para SOA, entonces esto debe hacerse antes de que comience la ejecucin. Esto debera utilizar los mismos recursos identificados en 22.7.1.2 Gobernabilidad y Estrategia de apoyo .
Fase G: Gobernanza Aplicacin
Las actividades que se realizan en la fase de implementacin de Gobierno depender en parte de las decisiones tomadas en el nivel de detalle de la especificacin de implementacin, cuando el equipo de arquitectos de mbito del desarrollo de la arquitectura en la Fase A. Durante la fase de implementacin de Gobierno, la parte control de la SGVM debe ser poner en funcionamiento para asegurar que las actividades de gobierno de SOA se realizan en el nivel correcto.
Fase H: Gestin Arquitectura Cambio
Es en este punto que el arquitecto debe determinar si es necesario revisar la Etapa Preliminar para ajustar la capacidad de la Arquitectura. Dnde SOA previamente no se ha utilizado dentro de una empresa, la Fase H de un desarrollo de la arquitectura es una oportunidad para evaluar la contribucin que podra hacer SOA, y para considerar la adopcin del principio de la orientacin a servicios.
22.8 Resumen
Hay una serie de mtodos de SOA, herramientas y materiales de referencia disponibles para ayudar al Enterprise Architect desarrollar SOA. Se sugieren las normas y publicaciones Open Group. Algunos se centran directamente en SOA - como el Source Book SOA, OSIMM o la SGVM otros no estn directamente enfocados pero regularmente tiles, tales como salidas de El Foro de Seguridad de Open Group. . Usando TOGAF para crear SOA requiere la adaptacin de TOGAF para atender las exigencias de un estilo particular Abordar un estilo requerir: La identificacin de las entradas clave metamodelo La identificacin de extensiones al metamodelo contenido La identificacin de los artefactos clave La identificacin de los materiales de referencia de estilo especfico y modelos de madurez
La adaptacin de una capacidad de Arquitectura para apoyar SOA requiere una considerable actividad en la fase preliminar de TOGAF. Estas actividades y herramientas SOA especficas del Grupo de Trabajo SOA Open Group incluyen: Adaptar el principio de la orientacin a servicios La determinacin de la organizacin la preparacin para SOA: OSIMM
Pgina236de670

TOGOF9.1
Gobernanza: The Open Group SGVM Particiones: Utilizar un Centro especializado de excelencia para apoyar SOA
En el resto de las fases TOGAF ADM, lo que cambia es la forma de una arquitectura es descrito, analizado y documentado. Durante una iteracin de la ADM el practicante debe tener en cuenta las entidades metamodelo clave identificados, y los artefactos identificados. En diferentes niveles de granularidad el fin del ciclo de ADM variar. En el trabajo a nivel estratgico el objetivo es identificar si se necesita SOA, y en el que los segmentos. En el trabajo a nivel de segmento el propsito es describir la estructura y las capacidades de SOA. Por ltimo, en el trabajo a nivel de capacidades para identificar y describir los requisitos de los servicios SOA que estarn disponibles. Cuando la entrega de SOA con TOGAF, el mdico nunca debe perder de vista el objetivo final: soluciones SOA que se ocupan de la gestin de la complejidad de la empresa y proporcionar la agilidad del negocio.
Pgina237de670

TOGOF9.1
23. Principios de Arquitectura

En este captulo se describen los principios para el uso en el desarrollo de una empresa de arquitectura.
23.1 Introduccin
Los principios son normas generales y directrices, destinadas a ser duradera y rara vez modificada, que informan y apoyan la forma en que una organizacin se marca sobre el cumplimiento de su misin. A su vez, los principios pueden ser slo un elemento de un conjunto estructurado de ideas que en conjunto definen y guas de la organizacin, a partir de los valores a travs de acciones y resultados. Dependiendo de la organizacin, los principios pueden ser establecidos dentro de los diferentes mbitos y en diferentes niveles. Dos dominios clave informan al desarrollo y la utilizacin de la arquitectura: Enterprise principios proporcionan una base para la toma de decisiones en toda la empresa, e informar de cmo la organizacin se marca sobre el cumplimiento de su misin. Tales principios se encuentran comnmente como medio de armonizar la toma de decisiones en toda la organizacin. En particular, son un elemento clave para una estrategia exitosa de gobernabilidad arquitectura (ver 50. Arquitectura de Gobierno ). Dentro del amplio dominio de los principios empresariales, es comn tener principios subsidiarios dentro de una empresa o unidad organizativa. Los ejemplos incluyen informtica, recursos humanos, operaciones nacionales, o de las operaciones en el extranjero. Estos principios proporcionan una base para la toma de decisiones dentro del dominio subsidiario e informarn desarrollo de la arquitectura dentro del dominio. Se debe tener cuidado para asegurar que los principios utilizados para informar el desarrollo de arquitectura se alinean con el contexto organizativo de la Capacidad de Arquitectura. Arquitectura principios son un conjunto de principios que se relacionan con el trabajo de la arquitectura. Son el reflejo de un nivel de consenso en toda la empresa, y encarnan el espritu y el pensamiento de los principios empresariales existentes. Arquitectura principios rigen el proceso de arquitectura, que afecta el desarrollo, mantenimiento y uso de la arquitectura de la empresa.
Es comn tener conjuntos de principios forman una jerarqua, en ese segmento principios sern informados por, y elaboran sobre los principios a nivel de empresa.Principios Arquitectura sern informados y limitados por principios empresariales. Principios Arquitectura pueden repetir otra orientacin de la empresa en trminos y forma que orientar eficazmente el desarrollo de la arquitectura. El resto de esta seccin se refiere exclusivamente a los principios de la arquitectura.
Pgina238de670

TOGOF9.1
23.2 Caractersticas de Arquitectura Principios

Arquitectura principios definen las normas y directrices para el uso y despliegue de todos los recursos y activos de TI en toda la empresa generales subyacentes. Son el reflejo de un nivel de consenso entre los distintos elementos de la empresa, y constituyen la base para la toma de decisiones de TI en el futuro. Cada principio la arquitectura debe estar claramente relacionado de nuevo a los objetivos de negocio y los conductores de arquitectura clave.
23,3 Componentes de Principios de Arquitectura

Es til tener una forma estndar de principios que definen. Adems de una instruccin de definicin, cada principio debe tener asociado declaraciones justificacin e implicaciones, tanto para promover el entendimiento y la aceptacin de los principios mismos, y para apoyar el uso de los principios en la explicacin y justificacin de por qu se toman las decisiones especficas. Una plantilla recomendada se da en la Tabla 23-1 .
En caso ambos representan la esencia de la norma, as como ser fcil de recordar. Plataformas tecnolgicas especficas no deben ser mencionadas en el nombre o la declaracin de un principio. Evite las palabras ambiguas en el nombre y en el Estado, tales como: el "apoyo", "Abrir", "considerar", y por falta de una buena medida de la palabra "evitar", por s mismo, tenga cuidado con " administrar ( cin) ", y buscar adjetivos y adverbios (pelusa) innecesarios. Declaracin Sucinta y sin ambigedades deben comunicar la regla fundamental. En su mayor parte, las declaraciones de principios para la gestin de la informacin son similares de una organizacin a otra. Es de vital importancia que la declaracin de principios sea inequvoca. Razn Har hincapi en los beneficios de negocio de adherirse al principio, utilizando fundamental la terminologa de negocios. Apunte a la similitud de los principios de informacin y tecnologa a los principios que rigen las operaciones de negocio. Describa tambin la relacin con otros principios y las intenciones con respecto a una interpretacin equilibrada. Describir situaciones en las que un principio se dara prioridad o tener ms peso que otro para tomar una decisin. Implicaciones Har hincapi en los requisitos, tanto para el negocio y de TI, para llevar a cabo el principio - en trminos de recursos, costos y actividades / tareas. A menudo ser evidente que los actuales sistemas, normas o prcticas seran incongruentes con el principio sobre la adopcin. El impacto para el negocio y las consecuencias de la adopcin de un principio debe quedar claro. El lector debe discernir fcilmente la respuesta a: "Cmo afecta esto a m?" Es importante no simplificar demasiado, trivializar o juzgar el mrito del impacto.Algunas de las consecuencias sern identificados como slo los impactos potenciales, y puede ser especulativa en lugar de totalmente analizado. Nombre
Tabla231:Formatorecomendadoparalosprincipiosquedefinen
Un ejemplo conjunto de arquitectura siguientes principios de esta plantilla se da en el 23,6 Ejemplo Conjunto de Principios de Arquitectura .
Pgina239de670

TOGOF9.1
23.4 Desarrollo Principios Arquitectura

Arquitectura principios se desarrollan tpicamente por los arquitectos de la empresa, en conjunto con las principales partes interesadas, y son aprobados por el Consejo de Arquitectura. Principios Arquitectura sern informados por principios en el mbito de la empresa, si es que existen. Principios Arquitectura deben estar claramente detectable y claramente articulado para orientar la toma de decisiones. Son elegidos con el fin de asegurar la alineacin de la arquitectura y la implementacin de la arquitectura destino con las estrategias de negocios y visiones. En concreto, el desarrollo de los principios de la arquitectura es tpicamente influenciado por el siguiente: Misin de la empresa y los planes : la misin, planes e infraestructura organizativa de la empresa. Enterprise iniciativas estratgicas : las caractersticas de la empresa - sus fortalezas, debilidades, oportunidades y amenazas - y sus iniciativas en toda la empresa actuales (tales como la mejora de procesos y gestin de la calidad). La restriccin externa : factores de mercado (time-to-market imperativos, las expectativas de los clientes, etc); legislacin actual y potencial. Sistemas y tecnologas actuales : el conjunto de recursos de informacin desplegados dentro de la empresa, incluyendo la documentacin de sistemas, inventarios de equipos, diagramas de configuracin de red, polticas y procedimientos. Nuevas tendencias de la industria : las predicciones sobre los factores econmicos, polticos, tcnicos y de mercado que influyen en el entorno empresarial.
23.4.1 Cualidades de Principios

Simple hecho de tener una declaracin escrita que se llama un principio no significa que el principio es bueno, incluso si todo el mundo est de acuerdo con l. Un buen conjunto de principios se fund en las creencias y valores de la organizacin y se expresa en un lenguaje que la empresa entiende y utiliza. Principios deben ser pocos en nmero, orientada hacia el futuro, y respaldado y defendido por la alta direccin. Ellos proporcionan una base slida para la toma de decisiones de arquitectura y planificacin, formulacin de polticas, procedimientos y normas, y el apoyo a la resolucin de situaciones contradictorias. Un pobre conjunto de principios se convertir rpidamente en desuso, y las arquitecturas resultantes, polticas y normas aparecer arbitrario o egosta, y por lo tanto carecen de credibilidad. Esencialmente, principios impulsan el comportamiento. Hay cinco criterios que distinguen a un buen conjunto de principios: Comprensible : los principios subyacentes pueden ser captadas y entendidas por las personas en toda la organizacin de forma rpida. La intencin del principio es clara e inequvoca, de modo que violacines, ya sea intencional o no, se reducen al mnimo.
Pgina240de670

TOGOF9.1
Robusto : permitir decisiones de buena calidad sobre arquitecturas y planes que se hacer, y las polticas y normas de obligado cumplimiento que se creen. Cada principio debe ser lo suficientemente definitivo y preciso para apoyar la toma de decisiones coherentes en situaciones complejas y potencialmente controversiales. Completa :. todo principio potencialmente importante que rige la gestin de la informacin y la tecnologa para la organizacin se define Los principios cubren cada situacin percibida. De acuerdo : la estricta adhesin a un principio puede requerir una interpretacin libre de otro principio. El conjunto de principios debe ser expresado de una manera que permite un equilibrio de las interpretaciones. Los principios no deben estar en contradiccin con el punto en el que se adhiere a un principio violara el espritu del otro. Cada palabra en un comunicado principio debe elegirse cuidadosamente para permitir una interpretacin coherente, pero flexible. Estable : principios deben ser duraderos, sin embargo, capaz de adaptarse a los cambios. Un proceso de enmienda debe ser establecido para agregar, eliminar o alterar los principios despus de haber sido ratificadas inicialmente.
23.5 Aplicacin de Principios de Arquitectura

Arquitectura principios se utilizan para capturar las verdades fundamentales acerca de cmo la empresa va a utilizar y desplegar los recursos de TI y los activos. Los principios se utilizan en un nmero de diferentes maneras:
1. Para proporcionar un marco en el que la empresa puede empezar a tomar decisiones

conscientes acerca de la arquitectura y proyectos que implementan la arquitectura de la empresa objetivo de la empresa
2. Como gua para el establecimiento de criterios de evaluacin pertinentes, ejerciendo as

una fuerte influencia en la seleccin de productos, soluciones y arquitecturas de soluciones en las ltimas etapas de la gestin del cumplimiento de la arquitectura de la empresa
3. Como los controladores para la definicin de los requisitos funcionales de la arquitectura 4. Como aporte a la evaluacin de ambas implementaciones existentes y la cartera
estratgica, para el cumplimiento de las arquitecturas definidas; estas evaluaciones proporcionarn informacin valiosa sobre las actividades de transicin necesarios para implementar una arquitectura, en apoyo de los objetivos y prioridades de la empresa
5. Las declaraciones Justificacin dentro de un Principio Arquitectura destacan el valor de

negocio de las implementaciones consistentes con el principio y proporcionar orientacin para las decisiones difciles con los conductores o los objetivos en conflicto
6. Las declaraciones Implicaciones dentro de un Principio Arquitectura proporcionan un

esquema de las principales tareas, recursos y costos potenciales para la empresa de seguir el principio; sino que tambin proporcionan una valiosa aportacin a las futuras actividades de la iniciativa de transicin y planificacin
7. Apoyar las actividades de gobierno de la arquitectura en trminos de: Pgina241de670

TOGOF9.1
o Proporcionar un "back-stop" para las evaluaciones Arquitectura cumplimiento de estndares donde se permite o requiere alguna interpretacin El apoyo a la decisin de iniciar una solicitud de dispensa, donde las consecuencias de una modificacin particular arquitectura no se pueden resolver dentro del procedimiento operativo local
Principios estn interrelacionados y deben ser aplicadas como un conjunto. Principios a veces competir; por ejemplo, los principios de la "accesibilidad" y "seguridad" tienden a decisiones contradictorias. Cada principio debe considerarse en el contexto de "todas las cosas en igualdad". A veces se requiere una decisin sobre a qu principio tendr prioridad sobre un tema en particular. La justificacin de este tipo de decisiones siempre debe ser documentado. Una reaccin comn en la primera lectura de un principio es "esto es obvio y no necesita ser documentado". El hecho de que un principio parece obvio no significa que la orientacin en un principio se sigui. Tener principios que aparecen evidentes ayuda a asegurar que las decisiones que en realidad siguen el resultado deseado. Aunque las sanciones especficas no se prescriben en una declaracin de principios, violacines de los principios generalmente causan problemas operativos e inhiben la capacidad de la organizacin para cumplir su misin.
23.6 Ejemplo Conjunto de Principios de Arquitectura

Demasiados principios pueden reducir la flexibilidad de la arquitectura. Muchas organizaciones prefieren definir slo los principios de alto nivel, y para limitar el nmero a entre 10 y 20. El siguiente ejemplo ilustra tanto el contenido tpico de un conjunto de principios de la arquitectura, y el formato recomendado para definirlos, como se explic anteriormente.

23.6.1 Principios de Negocio
Principio 1: Primaca de Principios
Declaracin: Estos principios de gestin de la informacin se aplican a todas las organizaciones dentro de la empresa.
Pgina242de670

TOGOF9.1
Justificacin: La nica manera de que podamos proporcionar un nivel consistente y medible de informacin de calidad a los tomadores de decisiones es si todas las organizaciones se rigen por los principios. Implicaciones: Sin este principio, las exclusiones, el favoritismo y la inconsistencia socavara rpidamente la gestin de la informacin. iniciativas de gestin de la informacin no comenzarn hasta que se examinan para el cumplimiento de los principios. Un conflicto con un principio se resuelve cambiando el marco de la iniciativa.
Principio 2: Maximizar beneficios a la Empresa
Declaracin: Decisiones de gestin de la informacin se hacen para proporcionar el mximo beneficio a la empresa en su conjunto. Justificacin: Este principio encarna "servicio por encima de uno mismo". Las decisiones tomadas desde una perspectiva de toda la empresa tienen un mayor valor a largo plazo de las decisiones tomadas desde cualquier punto de vista organizativo particular. Mximo rendimiento de la inversin requiere decisiones de gestin de la informacin a que se adhieran a los conductores y las prioridades de toda la empresa. Ningn grupo minoritario redundar en detrimento de la prestacin de la totalidad. Sin embargo, este principio no impedir cualquier grupo minoritario de conseguir hacer su trabajo. Implicaciones: Lograr el mximo beneficio de toda la empresa requerir cambios en la forma en que planificamos y gestionar la informacin. sola tecnologa no va a producir este cambio. Algunas organizaciones pueden tener que reconocer sus propias preferencias para el mayor beneficio de toda la empresa. las prioridades de desarrollo de aplicaciones deben ser establecidos por toda la empresa para toda la empresa. Componentes Aplicaciones deben ser compartidos a travs de las fronteras organizacionales. las iniciativas de gestin de la informacin debe realizarse de acuerdo con el plan de empresa. Las distintas organizaciones deben perseguir iniciativas de gestin de la informacin que se ajustan a los planos y las prioridades establecidas por la empresa. Vamos a cambiar el plan, ya que necesitamos.
Pgina243de670

TOGOF9.1
A medida que surjan las necesidades, las prioridades deben ser ajustados. Un foro con representacin global de la empresa debe tomar estas decisiones.
Principio 3: Gestin de la informacin es asunto de todos
Declaracin: Todas las organizaciones de la empresa participan en las decisiones de gestin de informacin necesarios para lograr los objetivos de negocio. Justificacin: Usuarios de la informacin son las principales partes interesadas, o clientes, en la aplicacin de tecnologa para hacer frente a una necesidad de negocio. Con el fin de garantizar la gestin de la informacin est alineada con el negocio, todas las organizaciones en la empresa deben participar en todos los aspectos del entorno de la informacin. Los expertos en negocios de toda la empresa y el personal tcnico responsable del desarrollo y la preservacin del entorno de informacin tienen que venir juntos como un equipo para definir conjuntamente los objetivos y metas de TI. Implicaciones: Para operar como un equipo, todos los grupos de inters, o cliente, tendr que aceptar la responsabilidad de desarrollar el entorno de la informacin. Compromiso de los recursos se requiere para poner en prctica este principio.
Principio 4: Continuidad del Negocio
Declaracin: Las operaciones de la empresa se mantienen a pesar de las interrupciones del sistema. Justificacin: Como las operaciones del sistema se torna ms difundido, nos volvemos ms dependientes de ellos; Por lo tanto, debemos tener en cuenta la fiabilidad de estos sistemas a travs de su diseo y uso. Locales comerciales en toda la empresa debe proporcionar la capacidad de continuar con sus funciones de negocios, independientemente de los acontecimientos externos. Error de hardware, desastres naturales, y la corrupcin de datos no se debe permitir que interrumpir o detener las actividades empresariales. Las funciones de negocio de la empresa debe ser capaz de operar sobre los mecanismos de entrega de informacin alternativos. Implicaciones: La dependencia de las aplicaciones compartidas mandatos del sistema que los riesgos de la interrupcin del negocio se deben establecer de antemano y gestionados. El manejo incluye pero no se limita a las revisiones peridicas, control de la vulnerabilidad y la exposicin, o el diseo de servicios de misin crtica para
Pgina244de670

TOGOF9.1
asegurar la continuidad del negocio a travs de la funcin de las capacidades redundantes o alternativos. Recuperabilidad, redundancia y capacidad de mantenimiento deben ser abordadas en el momento del diseo. Las solicitudes deben ser evaluados por la criticidad e impacto en la misin de la empresa, con el fin de determinar qu nivel de continuidad que se requiere y lo que el plan de recuperacin correspondiente es necesario.
Principio 5: Common Use Aplicaciones
Declaracin: Desarrollo de aplicaciones de uso en toda la empresa se prefiere sobre el desarrollo de aplicaciones similares o duplicados que se proporcionan nicamente a una organizacin en particular. Justificacin: Capacidad de duplicacin es costosa y prolifera datos contradictorios. Implicaciones: Las organizaciones que dependen de una capacidad que no sirve a toda la empresa debe cambiar a la capacidad de toda la empresa de reemplazo. Para ello ser necesario el establecimiento de y la adhesin a una poltica que exige esto. Organizaciones No se permitir el desarrollo de capacidades para su propio uso, que son similares / duplicacin de las capacidades de toda la empresa. De esta manera, se reducirn los gastos de los escasos recursos para desarrollar esencialmente la misma capacidad en marginalmente diferentes maneras. Los datos y la informacin utilizada para apoyar a las empresas la toma de decisiones se normalizarn en mucha mayor medida que antes. Esto se debe a las capacidades de la organizacin, ms pequeas que producen diferentes datos (que no fue compartida por otras organizaciones) sern reemplazadas por las capacidades de toda la empresa. El impulso para la adicin a la serie de capacidades en toda la empresa bien puede provenir de una organizacin que hace un caso convincente para el valor de los datos / informacin producida anteriormente por su capacidad de organizacin, pero la capacidad resultante pasar a formar parte del sistema en toda la empresa , y los datos que produce ser compartida en toda la empresa.
Principio 6: Orientacin al Servicio
Declaracin: La arquitectura se basa en un diseo de los servicios que reflejan las actividades empresariales del mundo real que comprenden la empresa (o entre empresas) los procesos de negocio.
Pgina245de670

TOGOF9.1
Justificacin: La orientacin a servicios ofrece la agilidad empresarial y sin fronteras Flujo de Informacin. Implicaciones: Representacin de servicio utiliza descripciones empresariales para proporcionar el contexto (es decir, los procesos de negocio, meta, regla, poltica, interfaz de servicio, y el componente de servicio) e implementa servicios utilizando la orquestacin de servicios. Orientacin al servicio pone requisitos nicos de la infraestructura, y las implementaciones deben utilizar estndares abiertos para darse cuenta de la interoperabilidad y la transparencia de ubicacin. Las implementaciones son favorables al medio especfico; se ven limitados o habilitadas por el contexto y deben ser descritas dentro de ese contexto. Se requiere un gobierno fuerte de la representacin de servicios y la ejecucin. Una "prueba de fuego", lo que determina un "buen servicio", se requiere.
Principio 7: El cumplimiento de la Ley
Declaracin: Procesos de gestin de informacin de la empresa cumplen con todas las leyes, polticas y regulaciones. Justificacin: La poltica de empresa es cumplir con las leyes, polticas y regulaciones. Esa disposicin no impedir la mejora de procesos de negocio que conducen a cambios en las polticas y regulaciones. Implicaciones: La empresa debe tener en cuenta para cumplir con las leyes, regulaciones y polticas exteriores relativas a la recogida, retencin y gestin de datos. La educacin y el acceso a las normas. Eficiencia, la necesidad y el sentido comn no son los nicos pilotos. Los cambios en la ley y los cambios en las regulaciones pueden conducir los cambios en los procesos o aplicaciones.
Principio 8: IT Responsabilidad
Declaracin: La organizacin de TI es responsable de la propiedad y la implementacin de los procesos de TI y de infraestructura que permitan soluciones para satisfacer los requisitos definidos por el usuario para la funcionalidad, los niveles de servicio, costo y tiempo de entrega.
Pgina246de670

TOGOF9.1
Justificacin: Alinear eficazmente las expectativas con las capacidades y los costos de manera que todos los proyectos son rentables. Soluciones eficientes y eficaces tienen costos razonables y claros beneficios. Implicaciones: Un proceso debe ser creado para dar prioridad a los proyectos. La funcin de TI debe definir los procesos para manejar las expectativas de las unidades de negocio. Los datos, aplicaciones y modelos de tecnologa deben ser creados para permitir soluciones integradas de calidad y para maximizar los resultados.
Principio 9: Proteccin de la Propiedad Intelectual
Declaracin: Propiedad intelectual de la empresa (IP) debe ser protegido. Esta proteccin debe reflejarse en la arquitectura de TI, implementacin y procesos de gobernanza. Justificacin: Una parte importante de IP de una empresa se encuentra alojado en el dominio de TI. Implicaciones: Si bien la proteccin de los activos de propiedad intelectual es un asunto de todos, gran parte de la proteccin real se implementa en el dominio de TI.Incluso confiar en los procesos de TI no pueden ser manejados por los procesos de TI (correo electrnico, notas obligatorias, etc.) Una poltica de seguridad, el gobierno y los actores humanos de TI, se requerir que puede mejorar sustancialmente la proteccin de la propiedad intelectual. Esta debe ser capaz de tanto evitando compromisos y la reduccin de pasivos. Recursos sobre estas polticas se pueden encontrar en el Instituto SANS (consulte www.sans.org/security-resources/policies/ ).
23.6.2 Principios de datos

Principio 10: Los datos son un activo
Declaracin: Los datos son un activo que tiene valor para la empresa y se gestiona en consecuencia. Justificacin: Los datos son un recurso valioso corporativa; que tiene un valor real y medible. En trminos simples, el propsito de los datos es para facilitar la toma de decisiones. Precisa,
Pgina247de670

TOGOF9.1
los datos a tiempo es fundamental para las decisiones precisas y oportunas. La mayora de los activos de la empresa se utilizan cuidadosamente, y los datos no es una excepcin. Los datos son el fundamento de nuestra toma de decisiones, por lo que tambin debe gestionar cuidadosamente los datos para asegurarse de que sabemos donde est, puede confiar en su exactitud, y puede obtenerlo cuando y donde lo necesitamos. Implicaciones: Se trata de uno de los tres principios estrechamente relacionados con las relativas a los datos: los datos son un activo; los datos se comparten; y los datos de fcil acceso. La implicacin es que no es una tarea de educacin para garantizar que todas las organizaciones dentro de la empresa a entender la relacin entre el valor de los datos, intercambio de datos, y la accesibilidad a los datos. Administradores deben tener la autoridad y los medios para gestionar los datos de los que son responsables. Hay que hacer la transicin cultural de "propiedad de los datos" pensar que "la administracin de datos" de pensar. El papel del administrador de datos es crtica porque los datos obsoletos, inexactos o incoherentes podran ser pasados a personal de la empresa y afectan negativamente a las decisiones en toda la empresa. Parte de la funcin de administrador de datos, que gestiona los datos, es garantizar la calidad de los datos. Los procedimientos deben ser desarrollados y utilizados para prevenir y corregir errores en la informacin y mejorar los procesos que producen la informacin errnea. Tendr que ser medido y las medidas adoptadas para mejorar la calidad de los datos de calidad de datos - es probable que tendrn las polticas y procedimientos que se han desarrollado para esto tambin. Un foro con representacin integral de toda la empresa debe decidir sobre cambios en los procesos sugeridos por el mayordomo. Dado que los datos son un activo de valor para toda la empresa, los administradores de datos responsables de la gestin adecuada de los datos deben ser asignados a nivel de empresa.
Principio 11: Los datos se Compartido
Declaracin: Los usuarios tienen acceso a los datos necesarios para llevar a cabo sus funciones; Por lo tanto, los datos se comparten a travs de las funciones y de las organizaciones empresariales. Justificacin: El acceso oportuno a datos precisos es esencial para mejorar la calidad y eficiencia de la empresa la toma de decisiones. Es menos costoso de mantener datos precisos y oportunos en una sola aplicacin, y luego compartirlo, de lo que es para mantener los
Pgina248de670

TOGOF9.1
datos duplicados en mltiples aplicaciones. La empresa tiene una gran cantidad de datos, sino que se almacena en bases de datos de cientos de tubos de la estufa incompatibles. La velocidad de recopilacin de datos, la creacin, la transferencia y la asimilacin es impulsado por la capacidad de la organizacin para compartir de manera eficiente estas islas de datos en toda la organizacin. Los datos compartidos se traducir en la mejora de las decisiones ya que vamos a contar con un menor nmero (en ltima instancia, uno virtual) de las fuentes de datos ms precisos y gestionados oportuna para toda nuestra toma de decisiones. Datos compartidos electrnicamente tendrn como resultado una mayor eficiencia cuando se pueden utilizar las entidades de datos existentes, y sin volver a escribir, a crear nuevas entidades. Implicaciones: Se trata de uno de los tres principios estrechamente relacionados con las relativas a los datos: los datos son un activo; los datos se comparten; y los datos de fcil acceso. La implicacin es que no es una tarea de educacin para garantizar que todas las organizaciones dentro de la empresa a entender la relacin entre el valor de los datos, intercambio de datos, y la accesibilidad a los datos. Para permitir el intercambio de datos que debemos desarrollar y cumplir con un conjunto comn de polticas, procedimientos y normas que rigen la gestin de datos y el acceso tanto a corto como a largo plazo. Para el corto plazo, para preservar nuestra importante inversin en sistemas de legado, tenemos que invertir en software capaz de migrar los datos del sistema legado en un entorno de datos compartido. Tambin vamos a necesitar desarrollar modelos estndares de datos, elementos de datos, y otros metadatos que define a este entorno compartido y desarrollar un sistema de depsito para el almacenamiento de estos metadatos para que sea accesible. Para el largo plazo, ya que los sistemas antiguos se sustituyen, debemos adoptar y hacer cumplir las polticas y directrices para los nuevos desarrolladores de aplicaciones comunes de acceso a datos para asegurar que los datos en nuevas aplicaciones queda disponible para el medio ambiente que compartimos y que los datos en el entorno compartido puede seguir ser utilizados por las aplicaciones nuevas. Tanto para el corto plazo y el largo plazo debemos adoptar mtodos y herramientas comunes para crear, mantener y acceder a los datos compartidos en toda la empresa. El intercambio de datos requerir un cambio cultural significativo. El principio de intercambio de datos continuamente "se topan con" el principio de seguridad de los datos. En ningn caso, el principio de intercambio de datos ocasionar que los datos confidenciales sean comprometidos. Los datos puestos a disposicin para el intercambio tendrn que confiar todos los usuarios a ejecutar sus respectivas tareas. Esto asegurar que slo los datos ms
Pgina249de670

TOGOF9.1
precisa y oportuna que se invoque para la toma de decisiones. Los datos compartidos se convertir en la "fuente nica virtual" en toda la empresa de datos.
Principio 12: Los datos son accesibles
Declaracin: Los datos son accesibles a los usuarios realizar sus funciones. Justificacin: Amplio acceso a los datos conduce a la eficiencia y la eficacia en la toma de decisiones, y ofrece respuesta oportuna a las solicitudes de informacin y prestacin de servicios. Utilizando la informacin debe ser considerado desde el punto de vista de la empresa para permitir el acceso de una amplia variedad de usuarios. Se ahorra tiempo del personal y la consistencia de los datos se ha mejorado. Implicaciones: Se trata de uno de los tres principios estrechamente relacionados con las relativas a los datos: los datos son un activo; los datos se comparten; y los datos de fcil acceso. La implicacin es que no es una tarea de educacin para garantizar que todas las organizaciones dentro de la empresa a entender la relacin entre el valor de los datos, intercambio de datos, y la accesibilidad a los datos. Accesibilidad consiste en la facilidad con la que los usuarios obtengan informacin. La forma en que se accede y visualiza la informacin debe ser suficientemente adaptable para satisfacer una amplia gama de usuarios de la empresa y sus correspondientes mtodos de acceso. El acceso a los datos no constituye la comprensin de los datos. El personal debe tener cuidado de no malinterpretar la informacin. El acceso a los datos no otorga necesariamente los derechos de acceso de usuario para modificar o divulgar los datos. Para ello ser necesario un proceso de educacin y un cambio en la cultura organizacional, el cual actualmente es compatible con la creencia en la "propiedad" de los datos por unidades funcionales.
Principio 13: Depositario de datos
Declaracin: Cada elemento de dato tiene un administrador responsable de la calidad de datos. Justificacin: Uno de los beneficios de un entorno Diseada es la capacidad de compartir los datos (por ejemplo, texto, vdeo, sonido, etc) a travs de la empresa. A medida que el grado de intercambio de datos crece y las unidades de negocio se basan en la informacin comn, es esencial que slo el administrador de datos toma las decisiones sobre el contenido de
Pgina250de670

TOGOF9.1
los datos. Puesto que los datos se pueden perder su integridad cuando se introduce varias veces, el administrador de datos ser el nico responsable de la introduccin de datos que elimina el esfuerzo humano redundante y los recursos de almacenamiento de datos. Nota: Un fiduciario es diferente de un mayordomo - un fiduciario es responsable de la exactitud y actualidad de los datos, mientras que las responsabilidades de un administrador pueden ser ms amplias e incluyen la estandarizacin de datos y tareas de definicin. Implicaciones: tutela real disuelve los problemas de la "propiedad" de datos y permite que los datos estn disponibles para satisfacer las necesidades de todos los usuarios. Esto implica que un cambio cultural a partir de datos de la "propiedad" de los datos de "tutela" puede ser requerida. El administrador de datos ser responsable de cumplir con las exigencias de calidad impuestas a los datos para los que el fiduciario es responsable. Es esencial que el fiduciario tiene la capacidad de proporcionar la confianza del usuario en los datos en base a atributos tales como "fuente de datos". Es esencial identificar la verdadera fuente de los datos con el fin de que la autoridad de datos se puede asignar esta responsabilidad fiduciaria. Esto no significa que las fuentes de anuncios sern revelados ni significa la fuente ser el fiduciario. La informacin debe ser capturada electrnicamente una vez e inmediatamente validada tan cerca de la fuente como sea posible. Medidas de control de calidad deben ser implementadas para garantizar la integridad de los datos. Como resultado del intercambio de datos en toda la empresa, el fiduciario es responsable y responsable de la exactitud y actualidad de su elemento de datos designado (s) y, posteriormente, a continuacin, debe reconocer la importancia de esta responsabilidad fiduciaria.
Principio 14: vocabulario comn y definiciones de datos
Declaracin: Los datos que se define consistentemente en toda la empresa, y las definiciones son comprensibles y estar disponibles para todos los usuarios. Justificacin: Los datos que se va a utilizar en el desarrollo de aplicaciones debe tener una definicin comn en toda la sede para permitir el intercambio de datos. Un vocabulario comn facilitar las comunicaciones y de dilogo habilitado para ser eficaz. Adems, se requiere para interfaz de los sistemas y los datos de cambio.
Pgina251de670

TOGOF9.1
Implicaciones: Estamos adormecidos en el pensamiento de que esta cuestin se aborde adecuadamente porque hay gente con "Gestin de datos" ttulos de trabajo y foros con las cartas que implica responsabilidad. Energa y recursos adicionales significativos deben estar comprometidos con esta tarea. Es clave para el xito de los esfuerzos para mejorar el entorno de la informacin. Esto es independiente de, pero relacionado con el tema de la definicin del elemento de datos, que est dirigida por una amplia comunidad - esto es ms como un vocabulario y una definicin comn. La empresa debe establecer el vocabulario comn inicial para el negocio. Las definiciones se utilizarn de manera uniforme en toda la empresa. Siempre que se requiera una nueva definicin de datos, el esfuerzo de definicin ser coordinada y reconciliada con el "glosario" corporativo de descripciones de datos. El administrador de datos de la empresa proporcionar esta coordinacin. Las ambigedades resultantes de mltiples definiciones parroquiales de datos deben dar paso a las definiciones aceptadas en toda la empresa y la comprensin. Mltiples iniciativas de estandarizacin de los datos tienen que ser coordinados. las responsabilidades de administracin de datos funcionales deben ser asignados.
Principio 15: Seguridad de datos
Declaracin: Los datos estn protegidos por el uso y la divulgacin no autorizada. Adems de los aspectos tradicionales de clasificacin de seguridad nacional, esto incluye, pero no se limita a, la proteccin de la pre-decisional, sensible, la fuente de seleccin sensible, informacin y propietaria. Justificacin: Libre intercambio de informacin y la divulgacin de informacin a travs de la legislacin pertinente debe equilibrarse con la necesidad de restringir la disponibilidad de la informacin clasificada, de propiedad y confidencial. Leyes y reglamentos existentes requieren la salvaguardia de la seguridad nacional y la privacidad de los datos, al tiempo que permite el acceso libre y abierto.Informacin previa a la toma de decisiones (trabajo en progreso, an no autorizados para la liberacin) debe ser protegida para evitar la especulacin injustificada, la mala interpretacin y el uso inapropiado.
Pgina252de670

TOGOF9.1
Implicaciones: La agregacin de los datos, tanto clasificado, y no, va a crear un objetivo grande que requiere revisin y los procedimientos de clasificacin DE para mantener un control adecuado. Los propietarios de datos y / o usuarios funcionales deben determinar si los resultados de la agregacin en un mayor nivel de clasificacin. Vamos a necesitar de polticas y procedimientos adecuados para manejar esta revisin y clasificacin DE. Acceso a la informacin sobre la base de una poltica de la necesidad de conocer obligar a revisiones peridicas de la cantidad de informacin. La prctica actual de tener sistemas separados para contener diferentes clasificaciones necesita ser repensado. Hay una solucin de software para la separacin de los datos clasificados y no clasificados? La solucin de hardware actual es difcil de manejar, ineficaz y costosa. Es ms caro para gestionar datos no clasificados en un sistema clasificado. Actualmente, la nica manera de combinar los dos es para colocar los datos no clasificados en el sistema clasificado, donde debe permanecer. Con el fin de proveer adecuadamente el acceso para abrir la informacin, manteniendo la informacin segura, las necesidades de seguridad deben ser identificados y desarrollados a nivel de datos, no el nivel de aplicacin. medidas de seguridad de datos se pueden poner en marcha para restringir el acceso a "slo vista", o "no ver nunca". Etiquetado de sensibilidad para el acceso a la clasificada, informacin previa a la toma de decisiones, toma de decisiones, sensible, ni de la propiedad debe ser determinado. La seguridad debe ser diseado en elementos de datos desde el principio; que no se puede aadir ms tarde. Sistemas, datos y tecnologas deben ser protegidos contra el acceso y la manipulacin no autorizada. Informacin de la Sede debe salvaguardarse contra la alteracin involuntaria o no autorizada, el sabotaje, el desastre o la divulgacin. Necesidad de nuevas polticas sobre la gestin de la duracin de la proteccin de la informacin pre-decisional y otras obras en curso, teniendo en cuenta la actualizacin del contenido.

23.6.3 Principios de Aplicacin
Principio 16: Tecnologa de la Independencia
Declaracin: Las solicitudes son independientes de las opciones tecnolgicas especficas y por lo tanto pueden operar en una variedad de plataformas tecnolgicas.
Pgina253de670

TOGOF9.1
Justificacin: Independencia de las aplicaciones de la tecnologa subyacente permite que las aplicaciones a desarrollar, actualizar y operar de la manera ms costo-efectiva y oportuna. De lo contrario, la tecnologa, la cual est sujeta a continua obsolescencia y proveedor de la dependencia, se convierte en el controlador en lugar de los propios requisitos de los usuarios. Al darse cuenta de que cada decisin tomada con respecto a IT nos hace depender de que la tecnologa, la intencin de este principio es garantizar que el software de aplicacin no depende de hardware especfico y software de sistemas operativos. Implicaciones: Este principio requiere normas que apoyan la portabilidad. Para Commercial Off-The-Shelf (COTS) y Gobierno Off-The-Shelf (GOTS) aplicaciones, no se podr limitar las opciones actuales, ya que muchas de estas aplicaciones son la tecnologa y dependiente de la plataforma. tendrn que ser desarrolladas para permitir que las aplicaciones de legado para interoperar con aplicaciones y entornos operativos desarrollados bajo la arquitectura de la empresa las interfaces del subsistema. Middleware debera utilizarse para separar las aplicaciones de soluciones de software especficas. A modo de ejemplo, este principio podra llevar al uso de Java, y los protocolos de Java como futuras, que le dan un alto grado de prioridad a la independencia de la plataforma.
Principio 17: Facilidad de Uso
Declaracin: Las aplicaciones son fciles de usar. La tecnologa subyacente es transparente para los usuarios, para que puedan concentrarse en las tareas a mano. Justificacin: Cuanto ms un usuario tiene que entender la tecnologa subyacente, menos productiva que el usuario es. La facilidad de uso es un incentivo positivo para el uso de aplicaciones. Se anima a los usuarios a trabajar dentro del entorno integrado de informacin en lugar de desarrollar sistemas aislados para realizar la tarea fuera del entorno de la informacin integrada de la empresa. La mayor parte de los conocimientos necesarios para operar un sistema ser similar a los dems. Formacin se mantiene a un mnimo, y el riesgo de usar un sistema de forma incorrecta es baja. Usando una aplicacin debe ser lo ms intuitivo como conducir un coche diferente.
Pgina254de670

TOGOF9.1
Implicaciones: Se requiere aplicaciones para tener un "look-and-feel" comn y apoyar a los requisitos ergonmicos. Por lo tanto, el estndar de look-and-feel comn debe ser diseado y criterios de prueba de usabilidad debe ser desarrollado. Directrices para las interfaces de usuario no deben ser limitados por supuestos estrechos acerca de la ubicacin del usuario, el idioma, la formacin de sistemas, o capacidad fsica. Factores tales como la lingstica, los clientes achaques fsicos (agudeza visual, capacidad de utilizar el teclado / ratn), y competencia en el uso de la tecnologa tienen amplias ramificaciones en la determinacin de la facilidad de uso de una aplicacin.
23.6.4 Principios Tecnolgicos

Cambio de base-Requisitos: Principio 18
Declaracin: Slo en respuesta a las necesidades del negocio son cambios en las aplicaciones y la tecnologa realizada. Justificacin: Este principio ser fomentar un ambiente en el que el entorno de la informacin cambia en respuesta a las necesidades de la empresa, en lugar de tener el cambio de negocio en respuesta a los cambios de TI. Esto es para asegurar que el objetivo de la ayuda la informacin - la operacin de los negocios - es la base de cualquier cambio propuesto. Los efectos no intencionales en los negocios debido a que los cambios se reducen al mnimo. Un cambio en la tecnologa puede proporcionar una oportunidad para mejorar los procesos de negocio y, por tanto, cambiar las necesidades del negocio. Implicaciones: Cambios en la aplicacin seguirn examen completo de los cambios propuestos que utilizan la arquitectura empresarial. No financiamos una mejora o un sistema de desarrollo tcnico a menos que exista una necesidad de negocio documentado. los procesos de gestin del cambio que se ajusten a este principio sern desarrollados e implementados. Este principio puede chocar contra el principio de un cambio sensible. Debemos asegurar el proceso de documentacin requisitos no impide el cambio de respuesta para satisfacer las necesidades comerciales legtimos. El propsito de este principio es mantenernos enfocados en los negocios, no las necesidades de tecnologa - Cambio de respuesta es tambin una necesidad de negocio.
Pgina255de670

TOGOF9.1
Principio 19: Cambio Responsive Gestin
Declaracin: Los cambios en el entorno de la informacin empresarial se implementan de una manera oportuna. Justificacin: Si las personas son de esperar para trabajar en el entorno de la informacin empresarial, ese entorno la informacin debe ser sensible a sus necesidades. Implicaciones: Tenemos que desarrollar procesos para gestionar e implementar el cambio que no generan retrasos. Un usuario que sienta la necesidad de cambio tendr que conectar con un "experto en los negocios" para facilitar la explicacin y la aplicacin de esa necesidad. Si vamos a hacer cambios, debemos mantener las arquitecturas actualizado. La adopcin de este principio podra requerir recursos adicionales. Este entrar en conflicto con otros principios (por ejemplo, el mximo beneficio de toda la empresa, las aplicaciones en toda la empresa, etc.)
Principio 20: Diversidad Tcnica de Control
Declaracin: La diversidad tecnolgica es controlado para minimizar el costo no trivial de acumular conocimientos especializados y la conectividad entre mltiples entornos de procesamiento. Justificacin: Existe un verdadero costo, no trivial de la infraestructura necesaria para apoyar las tecnologas alternativas para entornos de procesamiento. Hay otros costos de infraestructura incurridos para mantener mltiples construcciones de procesadores interconectados y mantenidos. La limitacin del nmero de componentes soportados va a simplificar y reducir los costos de mantenimiento. Las ventajas comerciales de la diversidad tcnicos mnimos son: un empaquetado estndar de los componentes; impacto de la implantacin predecible;valoraciones y retornos predecibles; redefinido las pruebas; estado de utilidad; y aumento de la flexibilidad para acomodar los avances tecnolgicos. Tecnologa Comn en toda la empresa brinda los beneficios de las economas de escala para la empresa. Costos de administracin y de apoyo tcnico se controlan mejor cuando los recursos limitados pueden centrarse en este conjunto compartido de la tecnologa.
Pgina256de670

TOGOF9.1
Implicaciones: Las polticas, normas y procedimientos que rigen la adquisicin de la tecnologa deben estar vinculados directamente a este principio. Las opciones tecnolgicas se vern limitados por las opciones disponibles dentro del plan de tecnologa. Procedimientos para aumentar la tecnologa aceptable establecido para satisfacer las nuevas necesidades tendrn que ser desarrollado y puesto en marcha. No estamos congelando nuestra lnea de base tecnolgica. Damos la bienvenida a los avances tecnolgicos y cambiaremos el plan de tecnologa cuando la compatibilidad con la infraestructura actual, la mejora en la eficiencia operativa, o una capacidad requerida ha sido demostrada.
Principio 21: Interoperabilidad
Declaracin: Software y hardware deben ajustarse a las normas definidas que promuevan la interoperabilidad de los datos, las aplicaciones y la tecnologa. Justificacin: Las normas ayudan a garantizar la coherencia, mejorando as la capacidad de administrar los sistemas y mejorar la satisfaccin del usuario, y proteger las inversiones existentes, maximizando as la rentabilidad de la inversin y la reduccin de costos. Los estndares para la interoperabilidad, adems, ayudan a asegurar el apoyo de mltiples proveedores para sus productos, y facilitan la integracin de la cadena de suministro. Implicaciones: Los estndares de interoperabilidad y estndares de la industria sern seguidas a menos que exista una razn de negocios para implementar una solucin no estndar. Un proceso para el establecimiento de normas, examinar y revisar peridicamente, y la concesin de excepciones debe ser establecido. Las plataformas existentes deben ser identificados y documentados.
Pgina257de670

TOGOF9.1
24. Gestin de las partes interesadas 24.1 Introduccin

Gestin de las partes interesadas es una disciplina importante que los profesionales de la arquitectura de xito puede utilizar para ganar el apoyo de los dems. Esto les ayuda a garantizar que sus proyectos tengan xito donde otros fracasan. Los beneficios de la exitosa gestin de los interesados son las siguientes: Los ms poderosos partes interesadas pueden ser identificados temprano y su entrada a continuacin, se pueden utilizar para dar forma a la arquitectura; esto asegura su apoyo y mejora la calidad de los modelos producidos. El apoyo de los grupos de inters ms poderosos ayudar a que el compromiso de ganar ms recursos, con lo que la participacin de la arquitectura ms probabilidades de xito. Mediante la comunicacin con las partes interesadas temprano y con frecuencia, el equipo de arquitectura puede asegurarse de que comprenden plenamente el proceso de la arquitectura, y los beneficios de la arquitectura de la empresa; esto significa que pueden apoyar al equipo de arquitectura ms activa cuando es necesario. El equipo de arquitectura se puede anticipar con mayor eficacia probables reacciones a los modelos de arquitectura e informes, y se puede incorporar en el plan de las acciones que sern necesarias para sacar provecho de reaccin positiva, evitando o tratar cualquier reaccin negativa. El equipo de arquitectura puede identificar objetivos en conflicto o en competencia entre las partes interesadas temprana y desarrollar una estrategia para resolver los problemas que surgen de ellos.
Es esencial en cualquier iniciativa para identificar a los individuos y grupos dentro de la organizacin que contribuyan al desarrollo de la arquitectura, identificar aquellos que ganar y los que perdern a partir de su introduccin, y luego desarrollar una estrategia para tratar con ellos.
24.2 Enfoque de gestin de los interesados

Anlisis de los interesados se debe utilizar durante la Fase A (Architecture Vision) para identificar los actores clave en el compromiso, y tambin se actualizar a lo largo de cada fase; diferentes grupos de inters pueden ser descubiertos como el compromiso progresa a travs en oportunidades y soluciones, de planeamiento de migracin, y Arquitectura de Gestin del Cambio. Arquitecturas complejas son muy difciles de manejar, no slo en trminos del propio proceso de desarrollo de la arquitectura, sino tambin en trminos de obtener el acuerdo de la gran cantidad de grupos de inters afectados por ella. Por ejemplo, al igual que un arquitecto de la construccin va a crear esquemas elctricos, planos de planta y elevaciones para describir las distintas facetas de un edificio para sus diferentes grupos
Pgina258de670

TOGOF9.1
de inters (electricistas, propietarios, funcionarios de planificacin), por lo que un arquitecto de la empresa debe crear diferentes puntos de vista de la empresa, arquitectura de sistemas de informacin y tecnologa para los grupos de inters que tienen inquietudes relacionadas con estos aspectos. TOGAF identifica especficamente este tema en todo el ADM a travs de los siguientes conceptos (como se define en 35.1 Conceptos Bsicos ): Las partes interesadas Preocupaciones Vistas Puntos de Vista
24.3 Pasos en el proceso de gestin de los grupos de inters

Las siguientes secciones detallan recomienda la actividad de gestin de los grupos de inters.
24.3.1 Identificar a los Interesados

Identificar los grupos de inters clave de la arquitectura de la empresa. La primera tarea es la de una lluvia de ideas que los principales grupos de inters de arquitectura empresarial son. Como parte de esto, piensa en todas las personas que se ven afectados por ella, que tienen influencia o poder sobre l, o tienen un inters en su conclusin exitosa o no. Puede incluir los altos ejecutivos, los roles de organizacin de proyectos, roles de la organizacin cliente, los desarrolladores de sistemas, socios de la alianza, los proveedores, las operaciones de TI, clientes, etc En la identificacin de los interesados, existe el peligro de concentrarse demasiado en la estructura formal de una organizacin como la base para la identificacin. Los grupos informales de partes interesadas pueden ser tan poderosos e influyentes como los formales. La mayora de los individuos pertenecen a ms de un grupo de interesados, y estos grupos tienden a surgir como resultado de eventos especficos. Mira quin est afectado por el proyecto de arquitectura de la empresa: Quin gana y quin pierde con este cambio? Quin controla la gestin del cambio de los procesos? Quin disea nuevos sistemas? Quin tomar las decisiones? Quin adquiere sistemas de TI y quin decide qu comprar?
Pgina259de670

TOGOF9.1
Quin controla los recursos? Quin tiene habilidades especiales que necesita el proyecto? Quin tiene influencia?
En particular, los influyentes deben ser identificados. Estos sern muy respetados y se mueve hacia arriba, participar en las reuniones y comits importantes (ver actas de reuniones), saben lo que est pasando en la empresa, ser valorado por sus compaeros y superiores, y no necesariamente estar en cualquier posicin formal de poder. Aunque los interesados pueden ser tanto organizaciones como personas, en ltima instancia, el equipo de arquitectura de la empresa tendr que comunicarse con la gente.Se trata de los actores individuales correctas dentro de una organizacin de las partes interesadas que necesitan ser identificados formalmente.
Anlisis de los actores 24.3.1.1 Muestra
Un anlisis de los actores muestra que distingue 22 tipos de grupos de inters en cinco grandes categoras, se muestra en la Figura 24-1 . Cualquier proyecto de arquitectura en particular puede tener ms, menos o diferentes grupos de inters; y pueden ser agrupadas en ms, menos, o de diferentes categoras.
Figura241:LaspartesinteresadasdelamuestrayCategoras Pgina260de670

TOGOF9.1
Tenga en cuenta tanto el Visible equipo - los obviamente asociado al proyecto / cambio - y el equipo Invisible - los que tienen que hacer una verdadera contribucin al proyecto / cambio para que sea un xito, pero que no han estado vinculadas al mismo (por ejemplo, los proveedores de servicios de apoyo).
24.3.2 Posiciones Clasifique las partes interesadas

Desarrollar una buena comprensin de los actores ms importantes y grabar este anlisis para referencia y refrescarse durante el proyecto. Un anlisis de los interesados ejemplo se muestra en la Tabla 24-1 .
Grupo de Tenedor de Capacidad partes apuestas de alterar el interesadas Cambio CIO John Smith H CFO Jeff Brown M Actual comprensin M M Se requiere la comprensin H M -Promiso actual L L -Promiso Apoyo Requerido Requerido M M H M
Ejemplodeanlisisdelaspartesinteresadas:Tabla241
Tambin es importante evaluar la disposicin de cada uno de los interesados que se comporten de una manera que apoye (es decir, demostrar su compromiso con la iniciativa de arquitectura de la empresa).
Esto se puede hacer haciendo una serie de preguntas: Es esa persona dispuesta a cambiar de direccin y comenzar a moverse hacia la Arquitectura objetivo? Si es as, listo? Es esta persona capaz de ser un defensor creble o agente de la iniciativa de la arquitectura empresarial propuesto? Si es as, cmo es capaz? Qu tan involucrado est el individuo en la iniciativa de arquitectura de la empresa? Son simplemente un observador interesado, o qu tienen que estar involucrados en los detalles? Esa persona ha hecho un compromiso contractual para el desarrollo de la arquitectura de la empresa, y su papel en la gobernanza del desarrollo de la organizacin?
Luego, para cada persona cuyo compromiso es fundamental para garantizar el xito, hacer un juicio acerca de su actual nivel de compromiso y el nivel deseado de compromiso futuro.
24.3.3 Determinar el enfoque de gestin de las partes interesadas

Los pasos anteriores identificaron una larga lista de personas y organizaciones que se ven afectadas por el proyecto de arquitectura empresarial. Algunos de ellos pueden tener el poder, ya sea para bloquear o avanzar. Algunos pueden estar interesados en lo que la iniciativa de arquitectura de la empresa que est haciendo; otros no
Pgina261de670

TOGOF9.1
pueden cuidar. Este paso permite al equipo ver fcilmente que se espera que los interesados para ser bloqueantes o los crticos, y que son susceptibles de ser defensores y partidarios de la iniciativa de las partes interesadas. Calcula el poder de las partes interesadas, la influencia y los intereses, a fin de enfocar la participacin de arquitectura empresarial de los individuos clave. Estos se pueden asignar a una matriz de poder / inters, lo que tambin indica la estrategia a adoptar para colaborar con ellos. Figura 24-2 muestra un ejemplo de matriz red elctrica.
Figura242:StakeholderPowerGrid
24.3.4 Tailor Engagement Entregables
Identificar los catlogos, matrices y diagramas que el compromiso arquitectura necesita para producir y validar con cada grupo de inters para ofrecer un modelo de arquitectura eficaz. Es importante prestar especial atencin a los intereses de los participantes mediante la definicin de los catlogos especficos, matrices y diagramas que son relevantes para un modelo de arquitectura de la empresa en particular. Esto permite que la arquitectura se comunique a, y entendida por todos los interesados, y les permite verificar que la iniciativa de arquitectura de la empresa se ocupar de sus preocupaciones.
24.4 Plantilla Stakeholder Mapa

La siguiente tabla proporciona un ejemplo mapa de las partes interesadas para un proyecto de arquitectura TOGAF que tiene grupos de inters identificados en la Figura 24-1 .
Tenedor de apuestas CxO (Funciones Corporativas), por ejemplo, el CEO, CFO, CIO, COO Preocupaciones claves Clase Catlogos, matrices y diagramas Diagrama de Huella de negocios Meta / Objetivo diagrama / Servicio Organizacin diagrama de descomposicin Catlogo de Requisitos
Los pilotos de alto nivel, las MANTENGA metas y objetivos de la SATISFECHO organizacin, y cmo stos se traducen en un proceso efectivo y la arquitectura de TI para avanzar en el negocio. Priorizar, la financiacin, y MANTENGA la alineacin de la actividad SATISFECHO
Oficina del Programa de Gestin
Pgina262de670

TOGOF9.1
(Funciones Corporativas), por ejemplo, los Gerentes de Cartera de Proyectos de cambio. La comprensin de los contenidos del proyecto y las dependencias tcnicas entre los proyectos apoya la gestin de carteras de toma de decisiones. Diagrama de Contexto del Proyecto Diagrama de Beneficios Diagrama de Huella de negocios Diagrama de comunicaciones de la aplicacin Diagrama de descomposicin funcional Adquisiciones Entender lo que los bloques JUGADORES CLAVE Catlogo Cartera (Funciones de construccin de la Tecnolgica Corporativas); arquitectura se pueden por ejemplo, los comprar, y qu Catlogo de Normas de compradores restricciones (o reglas) son Tecnologa relevantes para la compra. Los compradores harn compras con mltiples proveedores en busca de la mejor solucin de coste, si bien respetando las restricciones (o reglas) derivados de la arquitectura, como las normas. La principal preocupacin es hacer que las decisiones de compra que se ajustan a la arquitectura. Recursos Humanos (HR) Se requieren los roles y MANTENGA Organizacin diagrama de (Funciones actores para apoyar la INFORMADO descomposicin Corporativas), arquitectura y los cambios a por ejemplo, directores de la misma. La principal Catlogo de Organizacin recursos humanos, preocupacin es la gestin / Actor Formacin y Gerentes de de las personas Desarrollo transiciones. Ubicacin catlogo Aplicacin y usuario diagrama Ubicacin Asegurar que la JUGADORES CLAVE Diagrama del ciclo de vida informacin, los datos y los del producto sistemas de la organizacin estn disponibles slo para Diagrama de Divulgacin aquellos que tienen el de Datos permiso, y la proteccin de la informacin, los datos y Diagrama de seguridad los sistemas de de datos manipulacin no autorizada. Matriz Actor / Rol Diagrama de Hardware en
Enterprise Security (Funciones Corporativas), por ejemplo, Gestin de Riesgo Corporativo, Oficiales de Seguridad, Gerentes de Seguridad
Pgina263de670

TOGOF9.1
Red Informtica Ingeniera de Comunicaciones diagrama QA / Standards Group Asegurar la gobernabilidad JUGADORES CLAVE Proceso / Evento / Control (Funciones consistente de negocio de / Catlogo de productos Corporativas), la organizacin, datos, por ejemplo, los aplicaciones y activos de Catlogo Contract / propietarios de los datos, tecnologa. Medida los dueos de procesos, normas tcnicas Cuerpos Catlogo de la cartera de aplicaciones Catlogo de interfaz Catlogo de Normas de Tecnologa Catlogo Cartera Tecnolgica Diagrama de Huella de negocios Meta / Objetivo diagrama / Servicio Organizacin diagrama de descomposicin Diagrama de Flujo del Proceso Diagrama de comunicaciones de la aplicacin Gestin de lneas Funciones de nivel superior JUGADORES CLAVE Diagrama de Huella de (Organizacin para el y los procesos de la negocios usuario final); organizacin, y cmo las por ejemplo, los altos aplicaciones clave de Organizacin diagrama de directivos empresariales, apoyar estos procesos. descomposicin Gerentes Regionales de Operaciones, Gerentes de Diagrama de TI descomposicin funcional Diagrama de Flujo del Proceso Diagrama de comunicaciones de la aplicacin Aplicacin y usuario diagrama Ubicacin
Ejecutivo Los pilotos de alto nivel, las MANTENGA (End User Organization); metas y objetivos de la SATISFECHO por ejemplo, los organizacin, y cmo stos Directores de Unidad de se traducen en un proceso Negocio, CxOs Unidad de y la arquitectura para Negocios, Business Unit avanzar en el negocio Director de TI / eficaz. Arquitectura
Pgina264de670

TOGOF9.1
Negocios Expertos de dominio (Organizacin para el usuario final); por ejemplo, expertos de procesos de negocio, Business Analyst / Proceso, Proceso Arquitecto, Diseador de procesos, gerentes funcionales, Analista de Negocios Aspectos funcionales de los JUGADORES CLAVE procesos y sistemas de apoyo. Esto puede cubrir los actores humanos involucrados en el sistema, los procesos de usuario que intervienen en el sistema, las funciones que se requieren para apoyar los procesos y la informacin necesarios para fluir en apoyo de los procesos. Matriz de interaccin de negocios Matriz Actor / Rol Diagrama de Business Service / Information Diagrama de descomposicin funcional Diagrama del ciclo de vida del producto Negocios diagrama de casos de uso Esquema de aplicacin de casos de uso Diagrama de comunicaciones de la aplicacin Entity Data / matriz de funciones de negocios Catlogo de Normas de Tecnologa Catlogo Cartera Tecnolgica Catlogo Contract / Medida Diagrama Realizacin de proceso / aplicacin Diagrama de administracin de Enterprise Enfoque de Desarrollo, la JUGADORES CLAVE Diagrama Realizacin de modularidad del software y proceso / aplicacin la reutilizacin, portabilidad de migracin, y la Aplicacin / matriz de interoperabilidad. datos Diagrama de Migracin de aplicaciones Software diagrama de Ingeniera
IT Service Management Asegurar que los servicios MANTENGA (Operaciones de de TI proporciona a la INFORMADO Sistemas), organizacin a cumplir con por ejemplo, el los niveles de servicio Administrador de servicios requeridos por la de entrega organizacin para tener xito en los negocios.
Operaciones de TI Aplicaciones (Operaciones de sistema); por ejemplo, la arquitectura de aplicaciones, sistemas y software Ingenieros
Pgina265de670

TOGOF9.1
Diagrama de la descomposicin Plataforma Diagrama de Red Informtica / Hardware Diagrama de distribucin de software Operaciones de TI Ubicacin, modificabilidad, JUGADORES CLAVE Diagrama de Infraestructura reusabilidad y la descomposicin (Operaciones de disponibilidad de todos los Plataforma sistema); componentes del por ejemplo, Arquitecto de sistema.Asegurar que los Catlogo de Normas de Infraestructura, apoyo componentes adecuados se Tecnologa Wintel, soporte de gama desarrollan y despliegan media, DBA Operacional, dentro del sistema de una Catlogo Cartera Service Desk manera ptima. Tecnolgica Diagrama de administracin de Enterprise Diagrama de Red Informtica / Hardware Diagrama de Procesamiento Ambientes y zonas diagrama Comunicaciones de datos Ubicacin, modificabilidad, JUGADORES CLAVE Ingeniera de / voz - Operaciones de TI reusabilidad y la Comunicaciones ; (Operaciones del disponibilidad de servicios diagrama sistema) de comunicaciones y de por ejemplo, redes. Asegurar que las administracin de red correspondientes comunicaciones y los servicios de redes se desarrollan y despliegan dentro del sistema de una manera ptima. Ejecutivo En tiempos, entrega en el MANTENGA Catlogo de Requisitos (Organizacin del presupuesto de una INFORMADO proyecto); iniciativa de cambio que va Catlogo de Principios por ejemplo, el a darse cuenta de los Patrocinador, el beneficios esperados para Diagrama de la cadena de Administrador de la organizacin. valor programas Diagrama conceptual de soluciones Diagrama de
Pgina266de670

TOGOF9.1
descomposicin funcional Aplicacin y usuario diagrama Ubicacin Diagrama de comunicaciones de la aplicacin Diagrama de descomposicin funcional
Administracin de Lnea (Organizacin del proyecto); por ejemplo, Gerente de Proyectos
El logro de vista operativo a MANTENGA tiempo, entrega del INFORMADO presupuesto de una iniciativa de cambio con un alcance acordado.
Ambientes y zonas diagrama Business Process / La adicin de ms detalle a JUGADORES CLAVE Diagrama de Flujo del Experto Funcional las necesidades funcionales Proceso (Organizacin del de una iniciativa de cambio proyecto); basado en la experiencia y Negocios diagrama de por ejemplo, Finanzas la interaccin con expertos casos de uso FICO Consultor en el dominio de negocio de Funcional, HR Consultor la organizacin del usuario Diagrama de Business Funcional final. Service / Information Diagrama de descomposicin funcional Diagrama de comunicaciones de la aplicacin Especialista de Producto Especificacin de diseos JUGADORES CLAVE Software diagrama de (Organizacin del de productos de tecnologa Ingeniera proyecto); con el fin de cumplir con los por ejemplo, Especialista requisitos del proyecto y Aplicacin / matriz de Product Portal cumplir con la Visin de datos Arquitectura de la solucin. En un entorno de paquetes y servicios empaquetados, experiencia con el producto se puede utilizar para identificar las capacidades de productos que se pueden aprovechar fcilmente y pueden proporcionar orientacin sobre las estrategias de personalizacin del producto. Especificacin de diseos JUGADORES CLAVE de productos de tecnologa con el fin de cumplir con los requisitos del proyecto y cumplir con la Visin de Arquitectura de la solucin.
Tcnico Especialista (Organizacin del proyecto); por ejemplo, la solicitud de Arquitecto
Software diagrama de Ingeniera Diagrama de descomposicin Plataforma Diagrama Realizacin de
Pgina267de670

TOGOF9.1
proceso / aplicacin Aplicacin / matriz de datos Diagrama de Migracin de aplicaciones Diagrama de Huella de negocios Diagrama de comunicaciones de la aplicacin
Organismos Reguladores (Servicios exteriores); por ejemplo, Regulador Financiero, Reguladora de la Industria
La recepcin de la MANTENGA informacin que necesitan SATISFECHO con el fin de regular la organizacin del cliente, y asegurar que sus requisitos de informacin se satisfacen correctamente. Interesado en los procesos de informacin, y los datos y las aplicaciones que se utilizan para proporcionar informacin de retorno reguladora. Proveedores Asegurarse de que sus MANTENGA (Servicios exteriores); necesidades de intercambio SATISFECHO por ejemplo, la Alianza de informacin se reunieron socios, proveedores clave con el fin de que los contratos de servicio de acuerdo con las organizaciones de los clientes se pueden cumplir.
Diagrama de Huella de negocios Diagrama de Business Service / Information Diagrama de comunicaciones de la aplicacin
25. Patrones Arquitectura

Este captulo proporciona directrices para el uso de patrones de arquitectura.
25.1 Introduccin
Patrones para architecting sistema son muy mucho en su infancia. Ellos se han introducido en TOGAF esencialmente para atraerlos a la atencin de la comunidad de arquitectura de sistemas como un importante recurso emergente, y como marcador de posicin para las descripciones de esperar ms rigurosos y las referencias a los recursos ms abundantes en las futuras versiones de TOGAF. Han no (todava) han integrado en TOGAF. Sin embargo, en la siguiente, se intenta indicar el valor potencial de TOGAF, y qu partes de la Arquitectura Mtodo de Desarrollo de TOGAF (ADM) que podran ser relevantes.
Pgina268de670

TOGOF9.1
25.1.1 Antecedentes
Un "modelo" se ha definido como: "una idea que ha sido til en un contexto prctico y probablemente ser til para los dems" [ Los patrones de anlisis - modelos de objetos reutilizables ]. En TOGAF, los patrones son considerados como una forma de poner bloques de construccin en su contexto; por ejemplo, para describir una solucin reutilizable a un problema. Bloques de construccin son lo que usted utiliza: patrones pueden decir cmo usarlos, cundo, por qu, y qu ventajas y desventajas que tiene que hacer con ello. Los patrones ofrecen la promesa de ayudar al arquitecto a identificar combinaciones de Arquitectura y / o solucin de Building Blocks (Abs / SBB) que han sido probados para ofrecer soluciones eficaces en el pasado, y pueden proporcionar la base para soluciones eficaces en el futuro. Tcnicas patrn generalmente se reconoce que se han establecido como una valiosa tcnica de diseo de la arquitectura de Christopher Alexander, arquitecto de los edificios, que describi este enfoque en su libro The Way intemporal de la Construccin , publicado en 1979. Este libro ofrece una introduccin a las ideas detrs de la uso de patrones, y Alexander sigui con dos libros ms ( un lenguaje de patrones y el experimento de Oregon ) en la que se expandi en su descripcin de las caractersticas y beneficios de un enfoque patrones de arquitectura. Software y edificios los arquitectos tienen muchos problemas similares a la direccin, y por lo que era natural para los arquitectos de software que se interesan por los patrones como una herramienta arquitectnica. Muchos artculos y libros han sido publicados en ellos desde 1979 el libro de Alexander, quizs los ms reconocidos bienestar Patrones de diseo: Elementos de la Reusable de Software Orientado a Objetos . Este libro describe las soluciones simples y elegantes a problemas especficos en el diseo de software orientado a objetos.
25.1.2 Contenido de un Patrn

Varios formatos se utilizan en la literatura para describir los patrones, y hay un formato nico ha logrado una aceptacin generalizada. Sin embargo, existe un amplio acuerdo sobre los tipos de cosas que un patrn debe contener. Los ttulos que siguen estn tomadas de Pattern-Oriented Architecture Software: Un sistema de modelos .Los elementos que se describen a continuacin se pueden encontrar en la mayora de los patrones, aunque diferentes partidas se usan para describirlos. Nombre Una manera significativa y memorable para referirse al patrn, por lo general una sola palabra o frase corta. Problema Una descripcin del problema que indica la intencin de aplicar el patrn - las metas y objetivos previstos que han de alcanzarse en el contexto y las fuerzas se describen a continuacin (quizs con alguna indicacin de sus prioridades). Contexto
Pgina269de670

TOGOF9.1
Las condiciones en las que el patrn es aplicable - una descripcin de la situacin inicial antes de que el patrn se aplican. Fuerzas Una descripcin de las fuerzas y limitaciones correspondientes, y cmo interactan / conflicto entre s y con las metas y objetivos previstos. La descripcin debe aclarar las complejidades del problema y hacer explcitos los tipos de compensaciones que se deben considerar. (La necesidad de tales concesiones es tpicamente lo que hace que el problema difcil, y genera la necesidad de que el patrn en el primer lugar.) La nocin de "fuerzas" equivale en muchos aspectos a las "cualidades" que los arquitectos buscan la optimizacin, y las preocupaciones que tratan de direccin, en el diseo de arquitecturas. Por ejemplo: Seguridad, robustez, fiabilidad, tolerancia a fallos Capacidad de administracin La eficiencia, el rendimiento, el rendimiento, los requisitos de ancho de banda, la utilizacin del espacio Escalabilidad (crecimiento gradual en la demanda) extensibilidad, capacidad de evolucin, mantenibilidad La modularidad, la independencia, la reutilizacin, la apertura, la componibilidad (plug-and-play), la portabilidad Integridad y exactitud Facilidad de construccin Facilidad de uso etc, ...
Solucin Una descripcin, el uso de texto y / o grficos, de cmo alcanzar las metas y objetivos previstos. La descripcin debe identificar tanto la estructura de la solucin esttica y su comportamiento dinmico - el pueblo y los actores de computacin y sus colaboraciones. La descripcin puede incluir instrucciones para implementar la solucin. Variantes o especializaciones de la solucin tambin se pueden describir. Resultando Contexto Los post-condiciones despus el patrn ha sido aplicada. La implementacin de la solucin suele requerir compensaciones entre las fuerzas de la competencia.Este elemento describe que las fuerzas se han resuelto y cmo, y que siguen sin resolverse. Tambin puede indicar otros patrones que pueden ser aplicables en el nuevo contexto. (Un patrn puede ser un paso ms en el cumplimiento de una meta ms grande.) Ninguno de estos otros modelos se describen en detalle en los patrones relacionados.
Pgina270de670

TOGOF9.1
Ejemplos Una o ms aplicaciones de ejemplo del patrn que ilustran cada uno de los otros elementos: un problema especfico, el contexto y conjunto de fuerzas; cmo se aplica el patrn; y el contexto resultante. Razn fundamental Una explicacin / justificacin del modelo en su conjunto, o de los componentes individuales dentro de ella, lo que indica cmo funciona realmente el patrn, y por qu cmo resuelve los esfuerzos para alcanzar las metas y objetivos deseados, y por qu es "bueno". El elemento de la solucin de un patrn describe la estructura externa y el comportamiento de la solucin: la Razn da una idea de su funcionamiento interno. Patrones Relacionados . Las relaciones entre este patrn y otros Estos pueden ser patrones predecesoras, cuyos contextos resultantes corresponden al contexto inicial de ste; o patrones sucesores, cuyos contextos iniciales corresponden al contexto resultante de ste; o patrones alternativos, que describen una solucin diferente para el mismo problema, pero bajo diferentes fuerzas; o patrones de co-dependientes, que pueden / deben ser aplicadas junto con este patrn. Usos conocidos Aplicaciones conocidas del patrn dentro de los sistemas existentes, la verificacin de que el patrn de hecho describe una solucin probada a un problema recurrente. Usos conocido tambin puede servir de ejemplo. Los patrones tambin pueden comenzar con un resumen de proporcionar una visin general de la estructura y la indicacin de los tipos de problemas que trata. El Resumen tambin puede identificar el pblico objetivo y qu suposiciones se hacen del lector.
25.1.3 Terminologa
Aunque los patrones de diseo han sido el centro de gran inters en la industria del software por varios aos, particularmente en los campos de orientacin a objetos y software basado en componentes, es slo recientemente que se ha producido un creciente inters en los patrones de la arquitectura - la ampliacin de los principios y conceptos de patrones de diseo al dominio de la arquitectura. La literatura tcnica relacionada con este campo es complicado por el hecho de que muchas personas en los campos de software usan el trmino "arquitectura" para referirse al software, y muchos patrones se describe como "patrones de arquitectura" son los patrones de diseo de software de alto nivel. Esto simplemente hace que sea an ms importante para ser precisos en el uso de la terminologa.
25.1.3.1 patrones de arquitectura y patrones de diseo
El trmino "patrn de diseo" se usa con frecuencia para referirse a cualquier modelo que trata temas de arquitectura de software, el diseo o la implementacin de programacin. En Pattern-
Pgina271de670

TOGOF9.1
Oriented Software Architecture: Un sistema de modelos , los autores definen estos tres tipos de patrones de la siguiente manera: Un modelo de arquitectura expresa una organizacin estructural fundamental o esquema para sistemas de software. Proporciona un conjunto de subsistemas predefinidos, especifica sus responsabilidades, e incluye reglas y directrices para la organizacin de las relaciones entre ellos. Un patrn de diseo proporciona un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. En l se describe una estructura comnmente recurrentes de comunicar componentes que resuelve un problema de diseo general en un contexto particular. Un Idiom es un patrn de bajo nivel especficos de un lenguaje de programacin. Un modismo describe cmo implementar aspectos particulares de los componentes o las relaciones entre ellas utilizando las caractersticas de la lengua dada.
Estas distinciones son tiles, pero es importante tener en cuenta que los patrones de la arquitectura en este contexto todava se refiere nicamente a la arquitectura de software. La arquitectura de software es sin duda una parte importante del enfoque de TOGAF, pero no es su nico objetivo. En esta seccin nos ocupamos de las pautas architecting sistema de la empresa. Estos son anlogos a la arquitectura de software y patrones de diseo, y piden prestado muchos de sus conceptos y la terminologa, sino que se centran en la prestacin de los modelos y mtodos reutilizables especficamente para el architecting de los sistemas de informacin de la empresa que comprende software, hardware, redes, y la gente - en oposicin puramente a los sistemas de software.
25.1.3.2 Los patrones y el Continuum Arquitectura
Aunque los patrones de arquitectura han no (todava) han integrado en TOGAF, cada una de las primeras cuatro fases principales de la ADM (fases A a D) da una indicacin de la etapa en que los activos de arquitectura reutilizables relevantes del Continuum Arquitectura empresa debe ser considerado para el uso. Patrones de arquitectura son uno de esos activos. Una empresa que adopta un enfoque formal para el uso y re-uso de patrones de arquitectura normalmente integrar su uso en el Continuum Arquitectura empresarial.
25.1.3.3 Patrones y Vistas
Arquitectura vistas son partes de uno o ms modelos que representan seleccionan una completa arquitectura del sistema, centrndose en los aspectos que abordan las preocupaciones de uno o ms grupos de inters. Los patrones pueden proporcionar ayuda en el diseo de este tipo de modelos, y en la composicin de puntos de vista basados en ellos.
25.1.3.4 Los patrones y escenarios empresariales
Patrones de arquitectura pertinentes pueden tambin ser identificados en el trabajo sobre los escenarios de negocio.
Pgina272de670

TOGOF9.1
25.1.4 patrones de arquitectura en uso
Dos ejemplos de patrones de arquitectura en uso se describen en los apartados siguientes, uno por el dominio de la propia estructura la arquitectura de una empresa cliente de TI, y el otro de un proveedor del sistema principal que ha hecho un montn de trabajo en los ltimos aos en el campo de la arquitectura patrones. La Gua de Desarrollo de Arquitectura del Tesoro de EE.UU. (TADG) documento (ver 25.2 del Tesoro de EE.UU. Arquitectura Orientacin para el Desarrollo (TADG) ) proporciona una serie de patrones de arquitectura explcitas, adems de explicar la razn de ser, la estructura, y la taxonoma de patrones de arquitectura y su relacin con los EE.UU. Tesoro. Los Patrones de IBM para el sitio web de e-Business (ver 25.3 Patrones de IBM para eBusiness ) da una serie de patrones de arquitectura que van desde el problema de negocio para soluciones especficas, en primer lugar, a nivel genrico y luego en trminos de soluciones especficas de productos de IBM. Un recurso de apoyo es del conjunto de IBM Libros Rojos .
El siguiente material est diseado para dar a los punteros del lector a algunos de los lugares en los que ya estn siendo utilizados y puestos a disposicin patrones de arquitectura, con el fin de ayudar a los lectores a tomar sus propias opiniones en cuanto a la utilidad de esta tcnica para sus propios entornos.
25.2 del Tesoro de EE.UU. Arquitectura Orientacin para el Desarrollo (TADG)

El Tesoro de EE.UU. Arquitectura Orientacin para el Desarrollo (TADG) documento - antes conocido como el Sistema de Informacin Arquitectura de Marco Tesoro (TISAF) - ofrece una serie de patrones de arquitectura explcitas. Seccin 7 del documento TADG describe una razn de ser, la estructura, y la taxonoma de patrones de arquitectura, mientras que los patrones en s se documentan formalmente en el Apndice D. Los patrones de arquitectura presentados abarcan un conjunto ms amplio de los sistemas que slo los sistemas orientados a objetos.Algunos patrones de arquitectura se centran en los sistemas de legado, algunos en sistemas concurrentes y distribuidos, y algunos de los sistemas en tiempo real.
25.2.1 TADG contenido Pattern

El contenido de un patrn de arquitectura como se define en el documento de TADG contiene los siguientes elementos: Nombre Cada patrn de arquitectura tiene un nombre descriptivo nico, corto. La coleccin de nombres de los motivos arquitectura se puede utilizar como un vocabulario para describir, verificar y validar la informacin de arquitecturas de sistemas. Problema
Pgina273de670

TOGOF9.1
Cada patrn de arquitectura contiene una descripcin del problema a resolver. El planteamiento del problema puede describir una clase de problemas o un problema especfico. Razn fundamental La justificacin describe y explica un problema especfico tpico que es representativa de la amplia clase de problemas a resolver por el patrn de la arquitectura.Para un problema especfico, puede proporcionar informacin adicional sobre la naturaleza del problema y los requisitos para su resolucin. Supuestos Los supuestos son condiciones que deben cumplirse para que el patrn de arquitectura que pueda utilizarse en la solucin del problema. Incluyen restricciones en la solucin y los requisitos que pueden hacer que la solucin ms fcil de usar.

Estructura El patrn de la arquitectura se describe en los diagramas y palabras en el mayor detalle que se requiere para transmitir al lector los componentes del patrn y sus responsabilidades. Interacciones Las relaciones e interacciones importantes entre los componentes del patrn se describen y limitaciones sobre estas relaciones e interacciones se identifican. Consecuencias Las ventajas y desventajas del uso de este patrn se describen, en particular en trminos de otros patrones (ya sea necesaria o excluidos), as como las limitaciones de recursos que puedan surgir de su uso. Implementacin Asesoramiento sobre la ejecucin adicional que puede ayudar a los diseadores en modificar este patrn de diseo arquitectnico para los mejores resultados.
25.2.2 TADG Arquitectura Patrones

El documento TADG contiene los siguientes patrones.
Diseo Arquitectnico Nombre del patrn -Client Proxy Server
Sinopsis Acta como un concentrador para muchos enlaces de baja velocidad para acceder a un servidor.
Pgina274de670

TOGOF9.1
Atencin al cliente Reactor Servidores replicados Arquitectura en capas Pipe y filtro de Arquitectura Interfaz Subsistema Soporta complejo contacto con el cliente a travs de mltiples organizaciones. Desacopla un evento de su procesamiento. Replica los servidores para reducir la carga en el servidor central. Una descomposicin de los servicios tales que la mayora de las interacciones ocurren slo entre capas vecinas. Transforma la informacin en una serie de pasos o procesos incrementales. Administra las dependencias entre grupos cohesivos de funciones (subsistemas).
25.3 Patrones de IBM para e-Business

Los Patrones de IBM para e-Business web site (consulte www.ibm.com / framework / patrones ) proporciona un grupo de activos reutilizables destinada a acelerar el proceso de desarrollo de aplicaciones de e-business. A apoyar el sitio web de IBM est Patrones de Recursos eBusiness (consulte www.ibm.com / developerworks / patrones / biblioteca ). Esto tambin se conoce como los "Libros Rojos". La razn fundamental para la prestacin de estos patrones de IBM es: Proporciona una manera simple y consistente para traducir las prioridades y requerimientos de negocio en soluciones tcnicas Asistir y acelerar el desarrollo de la solucin y el proceso de integracin, facilitando el montaje de una solucin y minimizando personalizada implementaciones uno-de-unobueno Captura el conocimiento y las mejores prcticas de los expertos y ponerla a disposicin para su uso por personal menos experimentados Facilitar la reutilizacin del capital intelectual, como las arquitecturas de referencia, marcos y otros activos de arquitectura
Patrones de IBM se centran especficamente en soluciones para e-Business; es decir, los que permiten a una organizacin para aprovechar las tecnologas web para negocios redisear los procesos, mejorar las comunicaciones y las fronteras organizacionales inferiores con: Los clientes y los accionistas (a travs de Internet) Los empleados y grupos de inters (a travs de una Intranet corporativa) Los vendedores, proveedores y socios (a travs de una Extranet)
Tienen la finalidad de abordar los siguientes desafos encontrados en este tipo de entorno: Alto grado de integracin con sistemas heredados dentro de la empresa y con los sistemas fuera de la empresa Las soluciones tienen que llegar a los usuarios ms rpido; esto no significa sacrificar la calidad, pero s significa dar con maneras mejores y ms rpidos para desarrollar estas soluciones
Pgina275de670

TOGOF9.1
Acuerdos de Nivel de Servicio (SLAs) son crticos Necesidad de adaptarse a las tecnologas y los ciclos de produccin reducido drsticamente cambiando rpidamente Direccin una aguda escasez de las habilidades clave necesarias para desarrollar soluciones de calidad
IBM define cinco tipos de patrn: Patrones de Negocios , que identifican a los actores principales de negocio, y describen las interacciones entre ellos en trminos de las diferentes interacciones de negocios arquetpicos tales como: o Servicio (aka-user-to-business) - Los usuarios que acceden a las transacciones sobre una base 24x7 Colaboracin (alias de usuario a usuario) - los usuarios que trabajan con otros para compartir datos e informacin Informacin Aggregation (aka de usuario a los datos) - datos de mltiples fuentes agregan y se present a travs de mltiples canales Extended Enterprise (tambin conocido como de empresa a empresa) - integracin de datos y procesos a travs de las fronteras empresariales
Patrones de Integracin , que proporcionan el "pegamento" para combinar negocios patrones para formar soluciones. Caracterizan el problema de negocio, procesos de negocio / rules y el entorno existente para determinar si se requiere front-end o back-end de la integracin. o Integracin Front-end (aka la integracin de acceso) - centrado en proporcionar un acceso transparente y coherente para funciones de negocios. Funciones tpicas incluyen siempre de sesin nico, personalizacin, transcodificacin, etc Back-end de integracin (tambin conocido como la integracin de aplicaciones) se centr en la conexin, interfaces, o la integracin de bases de datos y sistemas. Integracin tpica se puede basar en la funcin, el tipo de la integracin, el modo de integracin, y por topologa.
Patrones compuestos , que son previamente identificados combinaciones y selecciones de patrones comerciales y de integracin, para las situaciones previamente identificados como: soluciones de comercio electrnico, (pblicos) de portales empresariales, portal de intranet de la empresa, la colaboracin ASP, etc Patrones de aplicaciones : Cada patrn de negocios e integracin puede ser implementada utilizando uno o ms patrones de aplicacin. Un patrn de aplicacin caracteriza la estructura de grano grueso de la aplicacin - los principales componentes de la aplicacin, la asignacin de funciones de procesamiento y las interacciones entre ellos, el grado de integracin entre ellos, y la colocacin de los datos relativos a las aplicaciones. Los patrones de tiempo de ejecucin : los patrones de aplicaciones pueden ser implementadas por los patrones de tiempo de ejecucin, lo que demuestra, las caractersticas de nivel de servicio no funcionales, como el rendimiento, capacidad,
Pgina276de670

TOGOF9.1
escalabilidad y disponibilidad. Identifican las principales limitaciones de recursos y las mejores prcticas. El sitio web de IBM tambin proporciona (IBM) las asignaciones de productos especficos para los patrones de tiempo de ejecucin, lo que indica las opciones tecnolgicas especficas para su implementacin.
25.4 Algunos Recursos Patrn

Los patrones Home Page (consulte hillside.net / patrones ) organizada por el Grupo de Hillside proporciona informacin acerca de los patrones, enlaces a modelos en lnea, artculos y libros relacionados con los patrones y patrones relacionados con las listas de correo. El Patrones-Discusin FAQ (consulte g.oswego.edu / dl / pd-FAQ / pd-FAQ.html ) mantenido por Doug Lea ofrece un FAQ muy completa y de fcil lectura sobre los patrones. Modelos y Software: Conceptos Esenciales y Terminologa de Brad Appleton (se refieren a www.bradapp.com / docs / patrones intro.html ) proporciona otra cuenta completa y legible del campo patrones.
Pgina277de670

TOGOF9.1
26. Escenarios empresariales y objetivos de la empresa

En este captulo se describe un mtodo para derivar los requisitos de negocio para la arquitectura y los requisitos tcnicos implicados. Tambin proporciona directrices sobre la definicin de metas y objetivos para el desarrollo de la arquitectura.
26.1 Introduccin
Un factor clave en el xito de una empresa de arquitectura es la medida en la que est vinculada a los requerimientos del negocio, y se puede demostrar el apoyo y permite a la empresa a alcanzar sus objetivos de negocio. Escenarios de negocios son una tcnica importante que puede ser utilizado en diversas etapas de la arquitectura de la empresa, principalmente la Visin Arquitectura y Arquitectura de negocios, sino tambin en otros dominios de la arquitectura, as, si es necesario, para deducir las caractersticas de la arquitectura directamente de la alta los requisitos de nivel de la empresa. Se utilizan para ayudar a identificar y entender las necesidades del negocio, y por lo tanto para obtener los requisitos de negocio que el desarrollo de la arquitectura tiene que abordar. Un escenario de negocios describe: Un proceso de negocio, una aplicacin o conjunto de aplicaciones que pueden ser habilitadas por la arquitectura El ambiente de negocios y la tecnologa El pueblo y componentes informticos (llamados "actores") que ejecutan el escenario El resultado deseado de la correcta ejecucin
Un buen escenario de negocios es representativo de una necesidad de negocio importante o problema, y permite a los proveedores a comprender el valor de la organizacin del cliente de una solucin desarrollada. Un buen escenario de negocios es tambin "SMART": Especfico , mediante la definicin de lo que hay que hacer en el negocio Medible , a travs de mtricas claras para el xito Actionable , a travs de: o o Claramente segmentar el problema Proporcionar la base para determinar los elementos y los planes para la solucin
Realista , en que el problema puede resolverse dentro de los lmites de la realidad fsica, el tiempo, y las limitaciones de costo
Pgina278de670

TOGOF9.1
De duracin determinada , en el que hay una declaracin clara de cundo caduca la oportunidad solucin
26.9 Directrices sobre Metas y Objetivos proporciona ejemplos detallados sobre los objetivos que se podran considerar. Independientemente objetivos que utilice, la idea es hacer que los objetivos de SMART.
26.2 Beneficios de escenarios empresariales

Un escenario de negocios es esencialmente una descripcin completa de un problema de negocio, tanto en los negocios como en trminos de arquitectura, que permite a los requisitos individuales para ser visto en relacin unos con otros, en el contexto del problema general. Sin una descripcin tan completa a servir como contexto : Existe el peligro de la arquitectura se basa en un conjunto incompleto de los requisitos que no se suman a una descripcin del problema en conjunto, y por lo tanto que puede confundir a obra de arquitectura. El valor de negocio de la solucin del problema no est clara. La relevancia de las posibles soluciones es clara.
Tambin, debido a que la tcnica requiere de la participacin de la gerencia de lnea de negocios y otras partes interesadas en una fase temprana en el proyecto de arquitectura, sino que tambin desempea un papel importante en la obtencin de la buy-in de este personal clave para el proyecto en general y su producto final - la arquitectura de la empresa. Una ventaja adicional de escenarios de negocios se encuentra en comunicacin con los proveedores. La mayora arquitectura hoy en da se lleva a cabo haciendo uso mximo de Commercial Off-The-Shelf (COTS) de soluciones de software, a menudo de mltiples proveedores, adquirido en el mercado abierto. El uso de escenarios de negocio por un cliente que puede ser una ayuda importante para los proveedores de TI en la entrega de soluciones adecuadas. Los vendedores deben asegurarse de que sus componentes de soluciones agregan valor a una solucin abierta y son negociables. Escenarios de negocio proporcionan un lenguaje con el que la comunidad de proveedores puede vincular los problemas del cliente y soluciones tcnicas. Adems de hacer evidente lo que se necesita, y por qu, que permiten a los proveedores para resolver problemas de manera ptima, usando estndares abiertos y el aprovechamiento de las habilidades de cada uno.
26.3 Crear el escenario de negocios

26.3.1 Proceso general
Creacin de un escenario de negocio consiste en la siguiente, como se ilustra en la Figura 26-1 :
1. Identificar, documentar y clasificar el problema de conducir el escenario 2. Identificar el entorno empresarial y tcnica del escenario y documentarla en modelos de escenarios Pgina279de670

TOGOF9.1 3. Identificar y documentar los objetivos deseados (los resultados de la manipulacin de los problemas con xito); conseguir "SMART" 4. La identificacin de los actores humanos (participantes) y su lugar en el modelo de negocio 5. La identificacin de los actores de ordenador (elementos de computacin) y su lugar en el modelo de la tecnologa 6. Identificar y documentar los roles, responsabilidades y medidas de xito por el actor; la
documentacin de los scripts requeridos por el actor, y los resultados del manejo de la situacin
7. Comprobacin de la "aptitud para el propsito" y refinacin slo si es necesario
Figura261:Crearunescenariodenegocios
Un escenario empresarial se desarrolla en una serie de fases iterativas de la recopilacin, anlisis y revisin de la informacin en el escenario de negocios. En cada fase, cada una de las reas antes mencionadas se mejora sucesiva. El refinamiento paso consiste en decidir si se debe considerar el escenario completo y pasar a la siguiente fase, o si un mayor refinamiento es necesario. Esto se logra al preguntar si el estado actual del escenario de negocio es apto para el propsito de llevar a los requerimientos aguas abajo en el proceso de la arquitectura.
Pgina280de670

TOGOF9.1
Las tres fases del desarrollo de un escenario de negocios se describen en detalle ms adelante, y representan en la Figura 26-2 .
Figura262:Fasesdeldesarrollodeescenariosempresariales
26.3.2 Reunin
La fase de recopilacin es donde se recoge informacin sobre cada una de las reas en la Figura 26-1 . Si los procedimientos y las prcticas de recopilacin de informacin ya estn en su lugar en una organizacin - por ejemplo, para reunir informacin para la planificacin estratgica - que se debe utilizar segn el caso, ya sea durante los talleres de escenarios de negocios o en lugar de los talleres de escenarios de negocios. Mltiples tcnicas se pueden utilizar en esta fase, como la bsqueda de informacin, el anlisis cualitativo, anlisis cuantitativo, encuestas, solicitudes de informacin, etcComo la mayor informacin posible se debe reunir y pre-procesado "off-line" antes de cualquier cara a cara, talleres de cara (descritos a continuacin). Por ejemplo, una solicitud de informacin pueden incluir una solicitud de planes estratgicos y operativos. Estos documentos suelen ofrecer grandes ideas, pero la informacin que contienen por lo general requiere preprocesamiento significativo. La informacin puede ser utilizada para generar un proyecto inicial de la situacin empresarial antes del taller, si es posible. Esto aumentar la comprensin y la confianza del arquitecto, y el valor del taller a sus participantes. Una manera muy til para recopilar informacin es la realizacin de talleres de escenarios de negocio, por lo que un consultor escenario de negocios lleva a un grupo selecto y pequeo de representantes de las empresas a travs de una serie de preguntas para obtener la informacin que rodea el problema que se aborda por el esfuerzo de la arquitectura. Los asistentes al taller deben ser cuidadosamente seleccionados de altos niveles en los lados empresariales y tcnicos de la organizacin. Es importante que la gente que puede y va a proporcionar informacin abierta y
Pgina281de670

TOGOF9.1
honestamente. Si ya existe un borrador del escenario de negocios - por ejemplo, como resultado de la decodificacin previa informacin recogida durante esta fase, tal como se describe ms arriba - el taller tambin se puede usar para examinar el estado del proyecto de escenario de negocios. A veces es necesario tener varios talleres: en algunos casos, para separar la recoleccin de informacin en la parte comercial de la recogida de informacin sobre los aspectos tcnicos; y en otros casos simplemente para obtener ms informacin de ms personas. Cuando la recoleccin de informacin, el arquitecto puede fortalecer enormemente el escenario de negocios mediante la obtencin de "ejemplos de la vida real"; es decir, los estudios de casos para los que el lector puede relacionar fcilmente. Al citar ejemplos del mundo real, es importante para mantener un nivel de anonimato de las partes involucradas, para evitar la culpa.
26.3.3 Analizar
La fase de Anlisis es donde una gran cantidad de trabajo de Arquitectura de negocios de bienes se hace realidad. Aqu es donde la informacin que se recopila es procesada y documentada, y donde se crean los modelos para representar esa informacin, por lo general visualmente. La fase de Anlisis se aprovecha de los conocimientos y la experiencia del consultor escenario de negocios utilizando trabajos anteriores y experiencia para desarrollar los modelos necesarios para representar la informacin capturada. Tenga en cuenta que los modelos y documentos producidos no son necesariamente reproducen textualmentelas entrevistas, sino que se filtran y se traducen de acuerdo a las necesidades reales subyacentes. En la fase de Anlisis es importante para mantener los vnculos entre los elementos clave de la situacin empresarial. Una tcnica que ayuda en el mantenimiento de tales enlaces es la creacin de matrices que se utilizan para relacionar los procesos de negocio de cada uno de: Circunscripciones Actores Humanos Actores Informtica Cuestiones Objetivos
De esta manera, el proceso de negocio se convierte en el punto focal de unin, lo que hace que una gran cantidad de sentido, ya que en la mayora de los casos, es la mejora de procesos de negocio que se est buscando.
26.3.4 Revisin
La fase de Revisin es donde los resultados son alimentados de nuevo a los patrocinadores del proyecto para asegurar que existe un entendimiento compartido de todo el alcance del problema, y la profundidad potencial del impacto tcnico. Se recomiendan varios talleres de escenarios de negocios o reuniones de "lectura" con los patrocinadores y las partes involucradas. Las reuniones deben ser configurados para ser abierto e
Pgina282de670

TOGOF9.1
interactivo. Se recomienda contar con ejercicios incorporados en las agendas de reuniones, con el fin de probar la comprensin de los asistentes y de los niveles de inters, as como para poner a prueba los propios supuestos y resultados del arquitecto. Esta fase es muy importante, ya que la ausencia de expectativas compartidas en muchos casos es la causa fundamental del fracaso de los proyectos.
26.4 Contenido de un escenario de negocios

La documentacin de un escenario de negocios debe contener todos los detalles importantes sobre el escenario. Debe capturar, y la secuencia, los pasos crticos e interacciones entre actores que se ocupan de la situacin. Tambin debe declarar toda la informacin relevante acerca de todos los actores, en concreto: las diferentes responsabilidades de los actores; las condiciones previas fundamentales que han de cumplirse antes de la funcionalidad correcta del sistema; y los requisitos tcnicos para el servicio sean de calidad aceptable. Hay dos tipos principales de contenido:. Grficas (modelos), y un texto descriptivo Ambos tienen un papel que desempear. Modelos escenario empresarial vistas captura de negocios y tecnologa en una forma grfica, para facilitar la comprensin. En concreto, se relacionan los actores e interacciones, y dan un punto de partida para confirmar los requisitos especficos. Descripciones de escenarios de negocios capturar detalles en forma textual. Una lista del contenido tpico de un escenario de negocios es la siguiente.
Tabla de contenidos PRLOGO RESUMEN EJECUTIVO DOCUMENTO DE HOJA DE RUTA ESCENARIO DE NEGOCIO Visin general del escenario NEGOCIO ANTECEDENTES DE ESCENARIO PROPSITO DEL ESCENARIO DEFINICIONES / DESCRIPCIN DE LOS TRMINOS UTILIZADOS OPINIONES DE LOS ENTORNOS Y PROCESOS ENTORNO EMPRESARIAL Circunscripciones Descripciones de procesos Proceso de "a" etc .... ENTORNO TCNICO Entorno tcnico "a" etc .... ACTORES Y SUS ROLES Y RESPONSABILIDADES ACTORES Y ROLES DEL ORDENADOR RELACIN DE LOS COMPONENTES Y PROCESOS ACTORES Y ROLES HUMANOS RELACIN DE LAS PERSONAS Y LOS PROCESOS ANLISIS DE FLUJO DE INFORMACIN PRINCIPIOS Y LIMITACIONES
Pgina283de670

TOGOF9.1
Principios de TI Restricciones REQUISITOS ANLISIS DE ESCENARIOS DE NEGOCIO Resumen del problema Cuestiones Objetivos RESUMEN ANEXOS ANEXO A: ESCENARIOS DE NEGOCIOS - INFORMACIN ADICIONAL APNDICE Bn: NOTAS ESCENARIO DEL TALLER
26.5 Las contribuciones al Escenario de Empresas

Es importante darse cuenta de que la creacin de un escenario de negocios no es el nico de la provincia del arquitecto. Como se mencion anteriormente, la gestin de la lnea de negocios y otras partes interesadas en la empresa estn involucrados, para asegurar que los objetivos de negocio se capturan con precisin. Adems, dependiendo de la relacin que la organizacin tiene con sus proveedores de TI, estos ltimos tambin pueden estar involucrados, para garantizar que las funciones de las soluciones tcnicas tambin se capturan con precisin, y para asegurar la comunicacin con los proveedores. Por lo general, la participacin de la gestin empresarial es mayor en las primeras etapas, mientras que los problemas de las empresas se estn explorando y capturados, mientras que la participacin del arquitecto es mayor en las etapas posteriores, y cuando se estn describiendo soluciones arquitectnicas. Del mismo modo, si los vendedores estn involucrados en el proceso de escenarios de negocio, la participacin del lado del cliente (gestin empresarial, ms arquitectos de la empresa) es mayor en las primeras etapas, mientras que la de los vendedores es el mayor en las etapas posteriores, cuando el papel de la tcnica especfica soluciones se estn explorando y capturaron. Este concepto se ilustra en la Figura 26-3 .
Figura263:Contribucionesrelacinconunescenariodenegocios
Pgina284de670

TOGOF9.1
Arquitectos de TI de proveedores podran ser capaces de ayudar a los arquitectos de TI de la empresa con la integracin de los productos de los vendedores en la arquitectura de la empresa. Esta asistencia muy probablemente cae en medio de la lnea de tiempo en la Figura 263.
26.6 Escenarios de Negocio y el TOGAF ADM

Escenarios empresariales figura ms prominente en la fase inicial del Mtodo Arquitectura Desarrollo (ADM), Architecture Vision, cuando se utilizan para definir los requisitos de negocio relevantes, y para construir un consenso con la gestin de las empresas y otros grupos de inters. Sin embargo, los requerimientos del negocio se hace referencia a lo largo de todas las fases del ciclo de ADM, como se ilustra en la Figura 26-4 .
Pgina285de670

TOGOF9.1

Figura264:ImportanciadelosRequisitosAlolargodelaADM
Debido a los requerimientos del negocio son importantes en todas las fases del ciclo de ADM, la tcnica de escenario de negocios tiene un papel importante que desempear en el TOGAF ADM, al asegurar que los propios requerimientos del negocio son completos y correctos.
26.7 Desarrollo de Escenarios empresariales

26.7.1 Directrices Generales
Las partes interesadas (por ejemplo, administradores de empresas, usuarios finales) le dirn lo que quieran, pero como arquitecto que an deben obtener una comprensin de los negocios, por lo que deben saber los actores ms importantes en el sistema. Si las partes interesadas no saben lo que quieren: Tmese su tiempo, observar y grabar cmo estn trabajando hoy Estructura de informacin de tal manera que se puede utilizar ms tarde Destape las reglas de negocio crticos de los expertos de dominio Mantngase enfocado en lo que se necesita lograr, y cmo se va a lograr
Este esfuerzo proporciona el ancla para una cadena de la razn a partir de los requerimientos del negocio a travs de soluciones tcnicas. Se dar sus frutos ms adelante ser diligente y crtica en la salida.
26.7.2 Preguntas que debe hacer para cada rea

El escenario de negocios talleres mencion anteriormente en la fase de recopilacin de entrevistas son muy estructurados. Si bien no existe un nico conjunto de preguntas apropiadas para preguntar en todas las situaciones, lo siguiente puede servir de orientacin para ayudar a los consultores de escenarios de negocio en hacer preguntas.
La identificacin, documentacin, y Clasificacin del Problema
El problema se describe como una declaracin de lo que se necesita hacer, como los pasos de un proceso, y no la forma (con la tecnologa "push")? Si el problema es demasiado especfico o un "cmo": Levantar una bandera roja Pregunte "Por qu necesita para hacerlo de esa manera?" preguntas
Pgina286de670

TOGOF9.1
Si el problema es demasiado vaga o no recurribles: Levantar una bandera roja Pregunta "Qu es lo que hay que hacer, o va a ser capaz de hacer si se resuelve este problema?" preguntas
Haga preguntas que ayuden a identificar dnde y cundo existe el problema: Adnde experimentando este problema en particular? En qu negocio proceso? Cundo se encuentra con estos problemas? Durante el inicio del proceso, el medio, el extremo?
Haga preguntas que ayuden a identificar los costos del problema: Cmo se explica por los costos asociados con este problema? Si es as, cules son? Hay costos ocultos? Si es as, cules son? El costo de este problema cubierto por el costo de algo ms? Si es as, qu y cunto? El problema se manifiesta en trminos de mala calidad o una percepcin de una organizacin ineficaz?
Identificar el entorno empresarial y Tcnico y Documentacin de Modelos
Preguntas que debe hacer sobre el entorno empresarial: Qu proceso clave sufre de los problemas? Cules son los pasos principales que necesitan ser procesados? Ubicacin / escala de departamentos internos de negocios? Ubicacin / escala de socios de negocios externos? Cualquier reglas y regulaciones de negocios especficos relacionados con la situacin?
Preguntas que debe hacer sobre el entorno tecnolgico actual: Qu componentes de tecnologa ya se presuponen estar relacionados con este problema? Existen limitaciones de la tecnologa? Existen principios tecnolgicos que se aplican?
Identificar y documentar los objetivos
Es el "qu" suficientemente respaldada con la justificacin de "por qu"? Si no, pida razn de ser medible en las siguientes reas:
Pgina287de670

TOGOF9.1
Retorno de la inversin Escalabilidad Necesidades de rendimiento Conformidad con las normas La facilidad de uso de las medidas de
La identificacin de los actores humanos y su lugar en el Modelo de Negocio
Un actor representa cualquier cosa que interacta con o dentro del sistema. Esto puede ser una un programa de ordenador humano, o una mquina, o. Actores iniciar la actividad con el sistema, por ejemplo: Usuario de la computadora con el ordenador Usuario del telfono con el telfono Empleado de la nmina con el sistema de nmina Suscriptor de Internet con el navegador web
Un actor representa un rol que un usuario juega; es decir, el usuario es una persona que juega un papel mientras se utiliza el sistema (por ejemplo, John (usuario) es un despachador (actor)). Cada actor utiliza el sistema de diferentes maneras (de lo contrario, debe ser el mismo actor). Pregunte acerca de los seres humanos que van a participar, desde diferentes puntos de vista, tales como: Revelador Mantenedor Operador Administrador Usuario
La identificacin de los actores de ordenador y su lugar en el Modelo de Tecnologa
Pregunte acerca de los componentes que pueden intervenir, de nuevo desde diferentes puntos de vista de la computadora. Qu deben hacer?
Roles Documentar, responsabilidades Medidas de xito, Scripts Requeridos
En la definicin de los roles, hacer preguntas como: Cules son las principales tareas del actor? Ser que el actor tenga que leer / escribir / modificar la informacin?
Pgina288de670

TOGOF9.1
Ser que el actor tiene que informar al sistema acerca de los cambios externos? Desea el actor para ser informado sobre cambios inesperados?
Comprobacin de Aptitud para el propsito, y el perfeccionamiento de si es necesario
Hay suficiente informacin para identificar a quin / qu podra cumplir el requisito? Si no es as, indagar ms a fondo. Hay una descripcin de cundo y con qu frecuencia, el requisito debe ser abordado? Si no, pregunte acerca de la sincronizacin.
26.8 Documentacin Escenario empresarial

26.8.1 Pruebas de documentacin
La documentacin efectiva escenario empresarial requiere un equilibrio entre la garanta de que el detalle es accesible, y evitando que eclipsa los resultados y abrumar al lector. Con este fin, el documento de escenario de negocios debe tener los principales hallazgos en el cuerpo del documento y los detalles en los apndices. En los apndices: Capture todos los detalles importantes acerca de un escenario de negocios: o o o o Descripcin Situacin y razn Todas las mediciones Todos los roles de actor y sub-mediciones Todos los servicios requeridos
Capture los pasos crticos entre los actores que se ocupan de la situacin, y la secuencia de las interacciones Declarar la informacin relevante acerca de todos los actores: o o Se reparte la responsabilidad de los actores Lista de condiciones previas que deben cumplirse antes del funcionamiento correcto del sistema Proporcionar los requisitos tcnicos para que el servicio sea de calidad aceptable
En el cuerpo principal del escenario de negocios: Generalizar todos los datos relevantes de los detalles en los apndices
26.8.2 Modelos escenario empresarial Recuerde que el propsito de la utilizacin de modelos:
Pgina289de670

TOGOF9.1
o o o Ayuda comprensin Dar un punto de partida para confirmar los requisitos Relacionar los actores y las interacciones
Mantenga dibujos clara y ordenada: o o No ponga demasiado en un diagrama Diagramas ms simples son ms fciles de entender
Esquemas numricos para una fcil referencia: o Mantener un catlogo de los nmeros para evitar duplicados
26.9 Directrices sobre Metas y Objetivos

26.9.1 Importancia de los Objetivos de
Uno de los primeros pasos en el desarrollo de una arquitectura es definir los objetivos generales y los objetivos para el desarrollo. Los objetivos deben derivarse de los objetivos de negocio de la organizacin, y la forma en que se ve a contribuir al logro de esos objetivos. Cada organizacin se comporta de manera diferente en este sentido, algunas de verlo como la fuerza motriz de la empresa y los dems ver que en un papel de apoyo, simplemente automatizar los procesos de negocio ya existentes. Lo esencial es que los objetivos arquitectnicos deben ser muy estrechamente alineados con las metas y objetivos de la organizacin de negocios.
26.9.2 Importancia de Objetivos SMART

No slo deben metas sean expresados en trminos generales, sino tambin medidas especficas necesitan ser unidos a ellos para que sean de SMART, como se describe anteriormente. La cantidad de esfuerzo empleado en hacer esto dar lugar a una mayor claridad para los patrocinadores del ciclo de la evolucin de la arquitectura. Se pagar por la conduccin soluciones propuestas mucho ms de cerca a los objetivos en cada etapa del ciclo. Es extremadamente til para los diferentes grupos de inters dentro de la organizacin, as como para los proveedores y consultores, para tener un criterio claro para medir la aptitud para el propsito. Si se hace bien, el ADM se puede utilizar para rastrear las decisiones especficas de regreso a los criterios, por lo que no darn su justificacin. Las metas de abajo han sido adaptados de los que figuran en las versiones anteriores de TOGAF. Estas son las categoras de objetivos, cada uno con una lista de posibles objetivos. Cada uno de estos objetivos debe hacerse de SMART con medidas y mtricas especficas para la tarea. Sin embargo, ya que el trabajo real que hacer ser especfica para el proyecto de arquitectura que se trate, no es posible proporcionar una lista de objetivos SMART genricos que relacionarse con cualquier proyecto. En su lugar, ofrecemos aqu algunos ejemplos de objetivos SMART.
Pgina290de670

TOGOF9.1
Ejemplo de hacer objetivos SMART
En el marco del objetivo general de la rbrica "Mejorar la productividad del usuario" a continuacin, hay un objetivo de proporcionar una "interfaz de usuario uniforme" y se describe como sigue: "Una interfaz de usuario consistente garantizar que todas las funciones y servicios accesibles para el usuario aparecern y se comportan de una manera predecible similares independientemente de la aplicacin o el sitio. Esto dar lugar a una mayor eficiencia y un menor nmero de errores de los usuarios, que a su vez puede resultar en menor recuperacin costos ". Para realizar este objetivo de SMART, nos preguntamos si el objetivo es especfico, medible y aplicable, realistas y de duracin determinada, y luego aumentar el objetivo de manera apropiada. La siguiente captura de un anlisis de estos criterios para el objetivo declarado: Especfico :. El objetivo de proporcionar "una interfaz de usuario coherente que asegure todas las funciones y servicios accesibles para el usuario aparecern y se comportan de una manera predecible similares independientemente de la aplicacin o el sitio" es bastante especfico. Sin embargo, las medidas que figuran en la segunda frase podra ser ms especfico ... Medible : Como se indic anteriormente, el objetivo es medible, pero podra ser ms especfico. La segunda frase podra modificarse para leer (por ejemplo): "Esto llevar a un 10% de mayor eficiencia del usuario y de la orden de 20% menos de errores de usuario de entrada, que a su vez puede dar lugar a un 5% ms bajos costos de entrada de pedidos." Actionable : El objetivo parece ser procesable. Parece claro que se debe proporcionar la consistencia de la interfaz de usuario, y que podra ser manejado por los responsables de proporcionar la interfaz de usuario para el dispositivo del usuario. Realista : El objetivo de proporcionar "una interfaz de usuario coherente que asegure todas las funciones y servicios accesibles para el usuario aparecern y se comportan de una manera predecible similares independientemente de la aplicacin o el sitio" podra no ser realista. Teniendo en cuenta el uso actual de la PDA al final el usuario podra llevarnos a aumentar este objetivo de asegurar que los desarrolladores de aguas abajo no crean indebidamente diseos que dificultan el uso de las nuevas tecnologas. El objetivo podra ser re-declar como "una interfaz consistente usuario, a travs de dispositivos de interfaz de usuario que proporcionan similares funcionalidades, que se asegurar de ... ", etc Limitado en el Tiempo : El objetivo como se ha dicho, no es de duracin determinada. Para ser de duracin determinada el objetivo podra ser re-declar como "Al final de la Q3, proporcionar una constante ... ".
Los resultados anteriores en un objetivo de SMART que se parece ms a esto (de nuevo recuerda que esto es un ejemplo): "Para el final de la Q3, proporcionar una interfaz de usuario consistente a travs de dispositivos de interfaz de usuario que proporcionan una funcionalidad similar para asegurar aparecen todas las funciones y servicios accesibles para el usuario y se comportan de una manera similar cuando se utilizan estos dispositivos en una forma predecible independientemente de la aplicacin o el sitio. Esta dar lugar a un 10% de mayor eficiencia de los usuarios y el 20% menos de errores de
Pgina291de670

TOGOF9.1
usuario de entrada de pedidos, que a su vez puede dar lugar a un 5% ms bajos costos de entrada de pedidos. "
26.9.3 Categoras de Metas y Objetivos

Aunque cada organizacin tendr su propio conjunto de objetivos, algunos ejemplos pueden ayudar en el desarrollo de una lista especfica de la organizacin. Los objetivos que figuran a continuacin son categoras de objetivos, cada uno con una lista de posibles objetivos, los cuales han sido adaptados a partir de los objetivos que figuran en las versiones anteriores de TOGAF. Cada uno de los objetivos que figuran a continuacin deben hacerse de SMART con medidas y mtricas especficas para la tarea en cuestin, como se ilustra en el ejemplo anterior. Sin embargo, el trabajo real que hacer ser especfica para el proyecto de arquitectura que se trate, y no es posible proporcionar una lista de objetivos SMART genricos que relacionarse con cualquier proyecto.
Objetivo: Mejorar el rendimiento de procesos de negocio
Mejoras en los procesos de negocios se pueden realizar a travs de los siguientes objetivos: Mayor rendimiento proceso Calidad de impresin consistente Costes del proceso predecibles El aumento de la reutilizacin de los procesos existentes Reduccin del tiempo de envo de informacin comercial de un proceso a otro proceso
Meta: Reducir Costos
Las mejoras en costes se pueden realizar a travs de los siguientes objetivos: Menores niveles de redundancia y la duplicacin de los activos en toda la empresa Disminucin de la dependencia de los proveedores de servicios de TI externos para integracin y personalizacin Menores costos de mantenimiento
Objetivo: Mejorar Operaciones de Negocios
Mejoras de operaciones comerciales se pueden realizar a travs de los siguientes objetivos: Aumento del presupuesto disponible para las nuevas caractersticas de negocio Reduccin de costes de funcionamiento de la empresa Disminucin del tiempo de salida al mercado para los productos o servicios
Pgina292de670

TOGOF9.1
Aumento de la calidad de los servicios a los clientes Mejora de la calidad de la informacin empresarial
Objetivo: Mejorar la Eficacia de Gestin
Mejoras de eficacia de gestin se pueden realizar a travs de los siguientes objetivos: Mayor flexibilidad de los negocios Menos tiempo para tomar decisiones Decisiones de mayor calidad
Meta: Reducir el Riesgo
Mejoras de riesgo se pueden realizar a travs de los siguientes objetivos: Facilidad de implementacin de nuevos procesos Errores introducidos en los procesos de negocio a travs de sistemas complejos y defectuosos Disminucin Riesgos para la seguridad del mundo real disminuy (incluidos los peligros que causan la prdida de la vida)
Objetivo: Mejorar la Efectividad de la organizacin de TI
Organizacin de TI efectividad puede ser realizado a travs de los siguientes objetivos: El aumento de lanzamiento de nuevos proyectos Disminucin de tiempo a la implantacin de nuevos proyectos Menor costo en el despliegue de nuevos proyectos Disminucin de la prdida de continuidad de servicio cuando el despliegue de nuevos proyectos El desarrollo comn: las aplicaciones que son comunes a mltiples reas de negocio sern desarrollados o adquiridos una vez y reutilizarse en lugar de desarrollar por separado por cada rea de negocio. Los sistemas abiertos de entorno: un entorno operativo comn basado en estndares, que da cabida a la inyeccin de nuevos estndares, tecnologas y aplicaciones de nivel de toda la organizacin, se establecern. Este entorno basado en estndares, servir de base para el desarrollo de aplicaciones comunes y facilitar la reutilizacin de software. El uso de productos: en la medida de lo posible, independiente del hardware, elementos fuera de la plataforma deben ser utilizados para satisfacer los requisitos con el fin de reducir la dependencia de desarrollos a medida y para reducir los costes de desarrollo y mantenimiento.
Pgina293de670

TOGOF9.1
Software reutilizacin: para aquellas aplicaciones que se deben desarrollar, desarrollo de aplicaciones mviles a medida reducir la cantidad de software desarrollado y aadir al inventario de software adecuado para su reutilizacin por otros sistemas. Compartir recursos: los recursos de procesamiento de datos (hardware, software y datos) ser compartido por todos los usuarios que requieren los servicios de dichos recursos. El intercambio de recursos se lleva a cabo en el contexto de la seguridad y las consideraciones operativas.
Objetivo: Mejorar la productividad de los usuarios
Mejoras en la productividad del usuario se pueden realizar a travs de los siguientes objetivos: Interfaz de usuario consistente: una interfaz de usuario consistente garantizar que todas las funciones y servicios accesibles para el usuario aparecern y se comportan de una manera predecible similares independientemente de la aplicacin o el sitio. Esto dar lugar a una mayor eficiencia y un menor nmero de errores de los usuarios, que a su vez puede resultar en menores costos de recuperacin. Aplicaciones integradas: las aplicaciones disponibles para el usuario se comportar de una manera lgicamente consistente a travs de entornos de usuario, lo que conducir a los mismos beneficios que una interfaz de usuario consistente. El intercambio de datos: bases de datos se comparten a travs de la organizacin en el contexto de la seguridad y las consideraciones operacionales, lo que aumenta la facilidad de acceso a los datos requeridos.
Objetivo: mejorar la portabilidad y escalabilidad
La portabilidad y escalabilidad de las aplicaciones ser a travs de los siguientes objetivos: Portabilidad: aplicaciones que se adhieren a los estndares abiertos de sistemas sern portables, lo que aumenta la facilidad de movimiento-a travs de plataformas informticas heterogneas. Aplicaciones porttiles pueden permitir que los sitios para actualizar sus plataformas conforme tengan lugar mejoras tecnolgicas, con un impacto mnimo en las operaciones. Escalabilidad: las aplicaciones que se ajustan al modelo ser configurable, lo que permite el funcionamiento en todo el espectro de plataformas requeridas.
Objetivo: Mejorar la interoperabilidad
Mejoras de interoperabilidad entre aplicaciones y reas de negocio se pueden realizar a travs de los siguientes objetivos: Infraestructura comn: la arquitectura debe promover una infraestructura de comunicaciones y computacin basados en sistemas abiertos y sistemas de transparencia, incluyendo, pero no limitado a, sistemas operativos, administracin de bases de datos, intercambio de datos, servicios de red, gestin de redes e interfaces de usuario.
Pgina294de670

TOGOF9.1
Normalizacin: mediante la implementacin de las plataformas basadas en estndares, las aplicaciones se le proporcionar y ser capaz de utilizar un conjunto comn de servicios que mejoren las oportunidades de interoperabilidad.
Objetivo: Aumentar el proveedor de la Independencia
La independencia del proveedor se incrementar a travs de los siguientes objetivos: Componentes intercambiables: slo el hardware y el software que tiene las interfaces basadas en estndares se seleccionarn, por lo que las actualizaciones o la insercin de nuevos productos darn lugar a una interrupcin mnima en el entorno del usuario. Especificaciones no propietarias: capacidades se definen en trminos de especificaciones no propietarias que soportan una competencia plena y abierta, y estn a disposicin de cualquier fabricante para su uso en el desarrollo de productos comerciales.
Meta: Reducir los costos de ciclo de vida
Los costos de ciclo de vida se puede reducir a travs de la mayor parte de los objetivos mencionados anteriormente. Adems, los siguientes objetivos se refieren directamente a la reduccin de los costes del ciclo de vida: Reduccin de la duplicacin: la sustitucin de los sistemas y las islas de automatizacin con sistemas abiertos interconectados aislados conducir a la reduccin de la funcionalidad de superposicin, duplicacin de datos y la redundancia innecesaria porque los sistemas abiertos pueden compartir datos y otros recursos. Los costos de mantenimiento de software Reducido: reducciones en la cantidad y variedad de software utilizado en la organizacin dar lugar a reducciones en la cantidad y el costo de mantenimiento del software. El uso de software estndar off-the-shelf conducir a nuevas reducciones de costes, ya que los proveedores de este tipo de software distribuyen sus costos de mantenimiento del producto a travs de una base de usuarios mucho mayor. Sustitucin incremental: interfaces comunes a los componentes de infraestructura compartida permite la sustitucin gradual o actualizar con una perturbacin operativa mnima. Reduccin de costos de formacin, con sistemas comunes y compatibles Interfaces Hombre-Computadora (HCI) conducirn a la reduccin de los costes de formacin.
Objetivo: Mejorar la Seguridad
La seguridad puede ser mejorada en la informacin de la organizacin a travs de los siguientes objetivos: Interfaces de seguridad consistentes para aplicaciones: las interfaces de seguridad consistentes y procedimientos dar lugar a un menor nmero de errores en el desarrollo de aplicaciones y la portabilidad de aplicaciones aumentado. No todas las aplicaciones tienen el mismo conjunto de caractersticas de seguridad, pero las caractersticas utilizadas sern consistentes en todas las aplicaciones.
Pgina295de670

TOGOF9.1
Interfaces de seguridad consistentes para los usuarios: una interfaz de usuario comn a las caractersticas de seguridad dar lugar a una reduccin del tiempo de aprendizaje cuando se pasa de un sistema a otro. Independencia de Seguridad: la implementacin de aplicaciones pueden utilizar la poltica de seguridad y los mecanismos apropiados para el entorno en particular si hay una buena estratificacin en la arquitectura. Una reduccin del 25% en las llamadas a la mesa de ayuda en relacin con las cuestiones de seguridad. Una reduccin del 20% en los "falsos positivos" detectados en la red (un falso positivo es un evento que parece ser un evento de seguridad procesable, pero en realidad es una falsa alarma).
Objetivo: Mejorar la capacidad de administracin
Mejora de la gestin se puede realizar a travs de los siguientes objetivos: Consistente interfaz de gestin: las prcticas y procedimientos de gestin coherentes facilitarn la gestin a travs de todas las aplicaciones y sus estructuras de soporte subyacentes. Una interfaz consistente puede simplificar la tarea de gestin, lo que aumenta la eficiencia del usuario. El servicio reducido, administracin y mantenimiento de los costos: el funcionamiento, la administracin y los costos de mantenimiento se pueden reducir a travs de la disponibilidad de productos mejorados de gestin y una mayor estandarizacin de los objetos que se manejan.
26.10 Resumen
Escenarios empresariales ayudan a abordar uno de los problemas ms comunes que enfrentan los ejecutivos de TI: la alineacin de TI con el negocio. El xito de cualquier gran proyecto de TI se mide por el grado en que se vincula a los requerimientos del negocio, y se puede demostrar apoya y permite a la empresa a alcanzar sus objetivos de negocio. Escenarios de negocios son una tcnica importante que puede ser utilizado en diversas etapas de la definicin de arquitectura de la empresa, o de cualquier otro gran proyecto de TI, para deducir las caractersticas de la arquitectura directamente de los requisitos de alto nivel de la empresa. Escenarios de negocio se utilizan para ayudar a identificar y entender las necesidades del negocio, y por lo tanto para derivar los requerimientos de negocio que el desarrollo de la arquitectura, y en ltima instancia, la tecnologa informtica, ha de abordar. Sin embargo, es importante recordar que los escenarios de negocios son slo una herramienta, no el objetivo. Son una parte de, y permiten, el proceso ms amplio de desarrollo de la arquitectura. El arquitecto debe usarlos, pero no perderse en ellos. La clave es mantener la concentracin cuidado con los "invasin de caractersticas", y abordar los temas ms importantes que tienden a devolver el valor ms grande.
Pgina296de670

TOGOF9.1
27. Anlisis Gap

La tcnica conocida como anlisis de brechas se utiliza ampliamente en el TOGAF Arquitectura Mtodo de Desarrollo (ADM) para validar una arquitectura que se est desarrollando. La premisa bsica es poner de relieve un dficit entre la arquitectura de lnea de base y de la arquitectura de destino; es decir, los elementos que se han omitido deliberadamente, accidentalmente dejados de lado, o an no definidas.
27.1 Introduccin
Un paso clave en la validacin de una arquitectura es considerar lo que pudo haber sido olvidado. La arquitectura debe ser compatible con todas las necesidades de procesamiento de la informacin esenciales de la organizacin. La fuente ms importante de las brechas que se deben considerar es preocupaciones de los interesados que no han sido abordados en la obra arquitectnica previa. Las fuentes potenciales de lagunas incluyen: Lagunas de dominio de negocios: o o o Gente lagunas (por ejemplo, los requisitos de entrenamiento cruzado) Lagunas de proceso (por ejemplo, las ineficiencias del proceso) Herramientas lagunas (por ejemplo, duplicar o falta de funcionalidad de la herramienta) Los vacos de informacin Lagunas de medicin Brechas financieras Instalaciones lagunas (edificios, oficinas, etc)
o o o o
Lagunas de dominio de datos: o o o o o o o Datos no de moneda suficiente Los datos que no se encuentren donde se necesita No los datos que se necesita Datos no disponibles cuando se necesiten Los datos no se ha creado Los datos no se consume Lagunas relacin de datos
Pgina297de670

TOGOF9.1
Aplicaciones afectados, eliminados, o creados Tecnologas afectados, eliminados, o creados
27.2 Pasos sugeridos

Los pasos sugeridos son los siguientes: Elaborar una matriz con todos los Arquitectura Bloques de Construccin (Abs) de la Arquitectura de referencia en el eje vertical, y todo el ABBS de la arquitectura seleccionada en el eje horizontal. Aadir a la Arquitectura de referencia eje A ltima fila con la etiqueta "Nuevo", y al eje de Arquitectura Target una ltima columna etiquetada "Eliminado". Cuando un ABB est disponible tanto en la lnea de base y Target Arquitecturas, grabar esto con "incluido" en la celda de interseccin. Cuando un ABB de la Arquitectura de referencia no se encuentra en la arquitectura destino, cada uno debe ser revisado. Si se elimina correctamente, lo marca como tal en el apropiado "Eliminado" clula. Si no lo fuera, una omisin accidental en la Arquitectura objetivo se ha descubierto que debe abordarse mediante el restablecimiento de la ABB en la prxima iteracin del diseo de la arquitectura - marcarlo como tal en el apropiado "Eliminado" clula. Cuando un ABB de la Arquitectura objetivo no se puede encontrar en la arquitectura de referencia, marcarlo en la interseccin con la lnea "Nuevo", como una brecha que hay que cubrir, ya sea mediante el desarrollo o adquisicin de la piedra angular.
Cuando el ejercicio se ha completado, cualquier cosa bajo "Eliminado" o "Nuevo" es una brecha, que debera o bien ser explicado como correctamente eliminado o marcado como ser abordado mediante el restablecimiento o el desarrollo / adquisicin de la funcin.
27.3 Ejemplo
La Figura 27-1 muestra un ejemplo de anlisis de ABBS que son los servicios de la categora de servicios de red del modelo de referencia tcnica (TRM), y muestra una serie de servicios a partir de la arquitectura de referencia que faltan de la arquitectura destino.
Pgina298de670

TOGOF9.1
Figura271:Ejemplodeanlisisdecarencias
Pgina299de670

TOGOF9.1
28. Tcnicas de Planificacin Migracin

Este captulo contiene una serie de tcnicas que se utilizan para apoyar la planificacin de la migracin en las fases E y F.
Evaluacin Factor 28.1 Implementacin & Matrix Deduccin

La tcnica de creacin de una evaluacin de la instrumentacin Factor y la matriz de deduccin se puede utilizar para documentar los factores que afectan la implementacin de la arquitectura y el Plan de Migracin. La matriz debe incluir una lista de los factores a tener en cuenta, sus descripciones, y las deducciones que indican las acciones o las limitaciones que deben ser tenidas en cuenta a la hora de formular los planes. Los factores incluyen tpicamente: Riesgos Cuestiones Supuestos Dependencias Acciones Impactos
Una matriz de ejemplo se muestra en la Figura 28-1 .
Figura281:EvaluacinFactorImplementacinyMatrixDeduccin
Pgina300de670

TOGOF9.1
28.2 Las lagunas consolidados, soluciones, y Matrix Dependencias

La tcnica de creacin de unas lagunas consolidados, soluciones, y la matriz de dependencias permite al arquitecto grupo de las lagunas identificadas en la arquitectura de dominio resultados de anlisis de carencias y evaluar las posibles soluciones y las dependencias a uno o ms espacios. Esta matriz se puede utilizar como una herramienta de planificacin cuando la creacin de paquetes de trabajo. Las dependencias identificadas impulsarn la creacin de proyectos y planificacin de la migracin en las fases E y F. Una matriz de ejemplo se muestra en la Figura 28-2 .
Figura282:ConsolidadoGaps,solucionesyMatrixDependencias
28.3 Arquitectura Definicin Incrementos Tabla

La tcnica de creacin de una tabla de incrementos de definicin de la arquitectura permite al arquitecto para planear una serie de Transicin Arquitecturas esbozar el estado de la arquitectura de la empresa en los momentos especificados. Una tabla debe elaborarse, como se muestra en la Figura 28-3 , que enumera los proyectos y la asignacin de sus entregas incrementales a travs de las arquitecturas de transicin.
Figura283:IncrementosdeArquitecturadefinicindelatabla Pgina301de670

TOGOF9.1
28.4 Transicin Arquitectura Estado Tabla de la Evolucin

La tcnica de creacin de la tabla de transicin Architecture Evolution Estado permite que el arquitecto que muestra el estado de las arquitecturas propuestas en varios niveles utilizando el Modelo de Referencia Tcnica (TRM). Una tabla debe ser dibujada, una lista de los servicios de la TRM se utiliza en la empresa, las arquitecturas de transicin, y las transformaciones propuso, como se muestra en la Figura 28-4 . Todos los bloques de construccin de la solucin (SBB) deben ser descritos con respecto a su entrega y el impacto en estos servicios. Tambin deben estar marcados para mostrar el progreso de la arquitectura empresarial. En el ejemplo, donde se ha alcanzado la capacidad objetivo, esto se muestra como "nuevos" o "retener"; donde la capacidad es la transicin a una nueva solucin, esta se marca como "de transicin"; y donde una capacidad va a ser reemplazado, esta se marca como "sustituir".
Figura284:ArquitecturadetransicindeestadosTablaEvolution
Otra tcnica (no mostrado aqu) es el uso de la codificacin de color en la matriz; por ejemplo: Verde: Servicio de SBB en su lugar (ya sea nuevo o retenido). Amarillo: Servicio realiza la migracin a una nueva solucin. Rojo: Servicio a sustituir.
Pgina302de670

TOGOF9.1
28.5 Evaluacin del Valor de Negocio Tcnica

Una tcnica para evaluar el valor del negocio es la elaboracin de una matriz basada en una dimensin ndice de valor y una dimensin de ndice de riesgo. Un ejemplo se muestra en la Figura 28-5 . El ndice de valor debe incluir criterios tales como el cumplimiento de los principios, la contribucin financiera, la alineacin estratgica, y la posicin competitiva. El ndice de riesgo debera incluir criterios tales como el tamao y la complejidad, la tecnologa, la capacidad de organizacin, y el impacto de un fracaso. A cada criterio se le debe asignar un peso individual. El ndice y sus criterios y ponderacin deben ser elaborados y aprobados por la alta direccin. Es importante establecer los criterios para la toma de decisiones antes de conocer las opciones.
Figura285:EjemplodeEvaluacindeProyectosconrespectoalosnegociosdevalorydeRiesgo
Pgina303de670

TOGOF9.1
29. Requisitos de interoperabilidad

Este captulo proporciona directrices para la definicin y el establecimiento de requisitos de interoperabilidad.
29.1 Informacin general

Una definicin de la interoperabilidad es "la capacidad de compartir informacin y servicios". Definir el grado en que la informacin y los servicios han de ser compartidos es un requisito arquitectnico de gran utilidad, sobre todo en una organizacin compleja y / o de la empresa extendida. La determinacin de la interoperabilidad est presente en todo el Mtodo de desarrollo de la arquitectura (ADM) de la siguiente manera: En el Architecture Vision (Fase A), la naturaleza y las consideraciones de seguridad de los intercambios de informacin y de servicios se revel por primera vez dentro de los escenarios de negocio. En la arquitectura de negocios (Fase B), los intercambios de informacin y de servicios se definen ms en trminos de negocio. En la arquitectura de datos (fase C), el contenido de los intercambios de informacin se detallan el uso de los datos de la empresa y / o modelo de intercambio de informacin. En se especifica la arquitectura de la aplicacin (fase C), la forma en que las distintas aplicaciones son para compartir la informacin y los servicios. En la arquitectura de la tecnologa (Fase D), se especifican los mecanismos tcnicos adecuados que permitan el intercambio de informacin y servicios. En Oportunidades y Soluciones (Fase E), se seleccionan las soluciones reales (por ejemplo, paquetes de Commercial Off-The-Shelf (COTS)). En planeamiento de migracin (Fase V), la interoperabilidad es implementado con lgica.
29.2 Definicin de Interoperabilidad

Hay muchas maneras de definir la interoperabilidad y el objetivo es definir una que se aplicar de manera uniforme dentro de la empresa y de la empresa extendida. Lo mejor es que tanto la empresa y la empresa extendida usan las mismas definiciones. Muchas organizaciones consideran que es til para categorizar la interoperabilidad de la siguiente manera: Operacional o de negocios Interoperabilidad define cmo los procesos de negocio han de ser compartidos. Informacin sobre interoperabilidad define cmo es la informacin para ser compartida.
Pgina304de670

TOGOF9.1
Interoperabilidad Tcnica define cmo los servicios tcnicos han de ser compartidos o al menos conectar entre s.
Desde una perspectiva de TI, sino que tambin es til tener en cuenta la interoperabilidad en una lnea similar a la Integracin de Aplicaciones Empresariales (EAI);especficamente: Presentacin de integracin / interoperabilidad es que un enfoque comn look-and-feel travs de una solucin de portal comn gua al usuario a la funcionalidad subyacente del conjunto de sistemas. Integracin de la Informacin / Interoperabilidad es donde la informacin corporativa est perfectamente compartida entre las distintas aplicaciones de la empresa para lograr, por ejemplo, un conjunto comn de informacin del cliente. Normalmente, esto se basa en una ontologa corporativa comnmente aceptado y servicios compartidos para la estructura, la calidad, el acceso y la seguridad / privacidad de la informacin. Integracin de Aplicaciones / Interoperabilidad es donde la funcionalidad corporativa est integrada y compartida de modo que las aplicaciones no estn duplicados (por ejemplo, un cambio de servicio de direccin / componente; no una para cada aplicacin) y estn perfectamente conectados entre s a travs de la funcionalidad como el flujo de trabajo. Esto afecta a las aplicaciones de negocio y de infraestructura, y est muy estrechamente vinculados a las empresas de procesos de negocio unificacin / la interoperabilidad. Tcnica de integracin / interoperabilidad incluye mtodos comunes y servicios compartidos para la comunicacin, el almacenamiento, el procesamiento y el acceso a los datos sobre todo en la plataforma de aplicaciones y dominios de la infraestructura de comunicaciones. Esta interoperabilidad se basa en el grado de racionalizacin de la infraestructura de TI de la empresa, sobre la base de normas y / o plataformas comunes. Por ejemplo, varias aplicaciones compartiendo una infraestructura o 10.000 sitios web corporativos mediante uno de gestin de contenidos / servidor web centralizado (en lugar de miles de servidores y webmasters extienden por todo el pas / mundo).
Muchas organizaciones crean sus propios modelos de interoperabilidad, como se ilustra en el siguiente ejemplo del Gobierno de Canad. Tienen una definicin de alto nivel de las tres clases de interoperabilidad e identificar la naturaleza de la informacin y servicios que desean compartir. La interoperabilidad se acu en trminos de los facilitadores electrnicos para la eAdministracin. Su desglose interoperabilidad es el siguiente: Informacin sobre interoperabilidad: o o o o Gestin del conocimiento La inteligencia empresarial Gestin de la informacin Identidad de confianza
Interoperabilidad del comercio: o Redes de entrega
Pgina305de670

TOGOF9.1
o o o o e-Democracia e-Business Gestin de recursos empresariales Gestin de las relaciones y el caso
Interoperabilidad Tcnica: o Infraestructura de TI
En ciertos enfoques arquitectnicos, tales como sistema de sistemas o un modelo federado, la interoperabilidad es una prctica muy recomendable que va a determinar cmo los sistemas interactan entre s. Una consideracin clave ser el modelo operativo de negocio de la empresa.
29.3 Empresa Modelo Operativo

La clave para el establecimiento de la interoperabilidad es la determinacin del modelo de funcionamiento empresarial, donde el modelo de funcionamiento es "el nivel necesario de la integracin de procesos de negocio y la normalizacin para la entrega de los bienes y servicios a los clientes. Un modelo operativo se describe cmo una empresa quiere prosperar y crecer. Por proporcionando una visin ms estable y procesable de la empresa de estrategia, el modelo operativo impulsa el diseo de la base para su ejecucin. " 1 Por ejemplo, si las lneas de unidades de negocio o comerciales slo necesitan compartir documentos, la Arquitectura y Soluciones Building Blocks (ABBS y SBB) puede ser ms sencillo que si hay una necesidad de compartir datos de transacciones estructuradas. Del mismo modo, si el Architecture Vision incluye un entorno de servicios compartidos, entonces es til para definir el nivel de los servicios que se van a compartir. El modelo de funcionamiento empresarial normalmente indica qu tipo de enfoque de interoperabilidad ser apropiado. Este modelo debe ser determinado en la Fase A (Architecture Vision) si no est en la Fase B (Arquitectura de negocios), y, definitivamente, por la Fase E (Oportunidades y Soluciones). Empresas complejas y / o las empresas extendidas (por ejemplo, la cadena de suministro) pueden tener ms de un tipo de modelo de funcionamiento. Por ejemplo, es comn para el modelo de funcionamiento interno (y apoyar modelo de interoperabilidad) a diferir de la utilizada para la empresa extendida.
29.4 Interoperabilidad Refinacin

La implementacin de la interoperabilidad requiere de la creacin, la gestin, la aceptacin y cumplimiento de las normas realistas que sean SMART (especficos, mensurables, acciones concretas, realistas y de duracin determinada). Medidas claras de interoperabilidad son clave para el xito. La arquitectura es la clave para la identificacin de las normas y sesiones facilitadas (lluvia de ideas), examinar posibles formas pragmticas (que caben dentro de la cultura empresarial actual o emergente) para alcanzar el grado requerido de interoperabilidad.
Pgina306de670

TOGOF9.1
La interoperabilidad debe ser refinado para que cumpla con las necesidades de la empresa y / o empresa extendida de una manera inequvoca. Las medidas de interoperabilidad refinados (grados, tipos y objetivos de alto nivel) deben ser parte de o remitirse a la direccin estratgica de la arquitectura empresarial. Estas medidas se crean instancias dentro de una estrategia de transformacin que deben ser incrustado dentro de la definicin de la arquitectura de destino y pragmticamente a cabo en el Arquitecturas Transicin. Al finalizar, tambin actualizar los resultados del anlisis de brecha consolidados y dependencias para asegurarse de que todas las pepitas de brainstorming son capturados. Un ejemplo de la especificacin de interoperabilidad es el grado de interoperabilidad (utilizados en el Departamento de la Defensa Nacional y la OTAN canadiense). Estas organizaciones se han centrado en el intercambio de informacin y se acerc con cuatro grados de interoperabilidad de la siguiente manera: Grado 1: No estructurado de intercambio de datos implica el intercambio de datos no estructurados-humanos interpretable, como el texto libre que se encuentra en las estimaciones operacionales, anlisis y documentos. Grado 2: Structured Data Exchange implica el intercambio de datos estructuradoshumanos interpretable destinados manual y / o tratamiento automatizado, pero requiere de la compilacin manual, la recepcin y / o envo de mensajes. Grado 3: Distribucin transparente de datos implica el intercambio automtico de datos entre los sistemas basados en un modelo de intercambio comn. Grado 4: Distribucin transparente de la Informacin es una extensin de grado 3 a la interpretacin universal de la informacin a travs del procesamiento de datos basada en aplicaciones de co-operacin.
Estos ttulos deben ser perfeccionado y hecho tcnicamente significativo para cada uno de los grados. Un ejemplo refinamiento de grado 3 con cuatro subclasificaciones sigue: 3A: Formal de mensajes de Exchange 3B: Intercambio de datos comunes 3C: Completa el intercambio de datos 3D: en tiempo real de intercambio de datos
El propsito es especificar los grados detallados de interoperabilidad al nivel requerido de detalle de manera que sean tcnicamente significativa. Estos grados son muy tiles para especificar la forma en que la informacin debe ser intercambiada entre los distintos sistemas y proporcionar orientacin crtica a los proyectos de ejecucin de los sistemas. Medidas similares se deben establecer para determinar el servicio / negocio y la interoperabilidad tcnica.
Pgina307de670

TOGOF9.1
29.5 Determinacin de los requisitos de interoperabilidad

La coexistencia entre los pases emergentes y los sistemas existentes, sobre todo durante la transformacin, ser un gran desafo y de intercambio de ideas debe tratar de averiguar lo que hay que hacer para reducir el dolor. Es imperativo involucrar al personal y los arquitectos de gestin de las operaciones en este paso, ya que ser responsable de la operacin de los entregables de la cartera. Por ejemplo, puede haber una necesidad de una aplicacin de "contenedor" (una aplicacin que acta como interfaz [intrprete alias] entre el uso de la herencia y de la infraestructura emergente). De hecho, pragmticamente, en el "si funciona, no lo arregles" mundo, el "envoltorio" podra llegar a ser una solucin permanente. En cualquier caso, el uso de los resultados de anlisis de carencias y escenarios de negocio como una fundacin, una lluvia de ideas de los problemas de TI y trabajar a travs de ellos para asegurarse de que todas las respuestas estn claramente identificadas y tratadas y verificar que se cumplan los requisitos especficos de la organizacin. Es importante sealar que el proceso de desarrollo posterior debe incluir el reconocimiento de las dependencias y los lmites de las funciones y debe tener en cuenta qu productos estn disponibles en el mercado. Un ejemplo de cmo esto puede ser expresado se puede ver en el ejemplo de bloques de construccin (vase la Parte III , 37.Building Blocks ). Si se utiliza un mecanismo como los grados de interoperabilidad, a continuacin, una matriz que muestra los requisitos de interoperabilidad es una herramienta til, como se ilustra en la Figura 291 y Figura 29-2 , y seal que el grado de intercambio de informacin no es necesariamente simtrica o bidireccional entre los sistemas y / o grupos de inters. La siguiente matriz se puede utilizar dentro de la empresa y / o dentro de la empresa extendida como una forma de detallar que la informacin y / o servicios pueden ser compartidos. La matriz debe comenzar en la Arquitectura de Negocios (Fase B) para capturar la naturaleza del intercambio de informacin entre las partes interesadas, y evolucionar para determinar la cuota de lo que los sistemas de informacin que en la Fase C.
Figura291:BusinessInformationMatrizdeinteroperabilidad
Pgina308de670

TOGOF9.1
La figura 29-1 muestra que los grupos de inters requiere un intercambio estructurado de datos (nivel 2) con los interesados / Sistemas B y D, y el intercambio fluido de datos (grado 3) con las partes interesadas / Sistemas C, E, F y G. La matriz de interoperabilidad de la informacin del negocio debe ser refinado dentro de la arquitectura de sistemas de informacin utilizando medidas refinados y especificando los sistemas actuales utilizados por los grupos de inters. Un ejemplo se muestra en la Figura 29-2 .
Figura292:SistemasdeInformacinMatrizdeinteroperabilidad
En la Figura 29-2 , tanto la naturaleza del cambio es ms detallada (por ejemplo, Grado 3A frente nico grado 3) y el intercambio entre los sistemas especficos en lugar de las partes interesadas. Por ejemplo, la informacin de las acciones del Sistema de A con los dems sistemas de conformidad con las normas tcnicas de la empresa. En muchas organizaciones las arquitecturas empresariales describen la naturaleza de la informacin compartida entre las partes interesadas y / u organizaciones (por ejemplo, en defensa del trmino es "nodo operativo"), y la arquitectura de datos especifica la informacin que se comparte entre los sistemas. Actualizar los datos de destino definido y Arquitectura de la aplicacin (versin 1.0) con los problemas de interoperabilidad que se plantearon.
29.6 Requisitos de Conciliacin de interoperabilidad con las soluciones potenciales

El arquitecto de la empresa tendr que asegurarse de que no hay conflictos de interoperabilidad, sobre todo si existe la intencin de reutilizar SBB y / o cunas existentes. La cuestin ms importante a abordar es, de hecho, la interoperabilidad empresarial. La mayora de SBB o COTS tendrn sus propios procesos empresariales incrustados.El cambio de los procesos de negocio integrados menudo requerir mucho trabajo, que se perdern las ventajas de las soluciones de reutilizacin de. Hay numerosos ejemplos de esto en el pasado. Adems, no es el aspecto de flujo de trabajo entre los diversos sistemas que tiene que ser tomada en cuenta. El arquitecto de la empresa tendr que asegurarse de que cualquier cambio en los
Pgina309de670

TOGOF9.1
requisitos de interoperabilidad de negocios est firmado por los arquitectos comerciales y patrocinadores de arquitectura en una declaracin revisada de Arquitectura Obra.
29.7 Resumen
Definicin de interoperabilidad de forma clara e inequvoca en varios niveles (negocio / servicio, la informacin, y tcnicos) es una herramienta de planificacin de la arquitectura de utilidad. Las nociones de interoperabilidad sern cada vez ms importante en la arquitectura orientada a servicios (SOA), donde los servicios sern compartidos internamente y externamente en las empresas cada vez ms interdependientes extendidas.
Pgina310de670

TOGOF9.1
30. Evaluacin de la preparacin de transformacin de negocios

En este captulo se describe una tcnica conocida como Evaluacin de la preparacin de transformacin de negocios, que se utiliza para evaluar y cuantificar la disposicin de una organizacin a sufrir modificaciones. En este captulo se basa en el trabajo por la de su Programa de capacitacin de la transformacin del negocio (BTEP) Gobierno Canadiense y. 1
30.1 Introduccin
Arquitectura empresarial es una tarea importante dentro de una organizacin y la mayora de las veces un innovador Architecture Vision (Fase A) y apoyando Definicin Arquitectura (Fases B a D) supondr un cambio considerable. Hay muchas dimensiones de cambiar, pero con mucho, el ms importante es el elemento humano. Por ejemplo, si la empresa prev una consolidacin de las explotaciones de la informacin y el paso a un nuevo paradigma como la orientacin de servicios para la prestacin de servicios integrados, entonces las consecuencias para los recursos humanos son importantes. Potencialmente, junto con una cultura de cambio adverso y una fuerza de trabajo por poco calificada, la arquitectura ms slida y innovador podra ir a ninguna parte. La comprensin de la disposicin de la organizacin para aceptar el cambio, la identificacin de los problemas, y luego tratar con ellos en la Implementacin y planes de migracin es clave para la transformacin lograda arquitectura en las fases E y F. Este ser un esfuerzo conjunto entre las empresas (especialmente los recursos humanos) personal, lneas de negocio, y los planificadores de TI. Las actividades recomendadas en una evaluacin de la preparacin de la organizacin para hacer frente a la transformacin del negocio son: Determinar los factores de preparacin que tendrn impacto en la organizacin Presentar los factores de preparacin para el uso de modelos de madurez Evaluar los factores de preparacin, incluida la determinacin de las calificaciones de los factores de preparacin Evaluar los riesgos para cada factor de preparacin e identificar acciones de mejora para mitigar el riesgo El trabajo de estas acciones en la Fase E y F Implementacin y Plan de Migracin
30.1.1 Programa de capacitacin de la transformacin del negocio (BTEP)

El Programa de capacitacin de la transformacin del negocio Gobierno canadiense (BTEP) se proporciona orientacin sobre la manera de identificar las cuestiones relacionadas con la transformacin de los negocios.
Pgina311de670

TOGOF9.1
El BTEP recomienda que todos los proyectos llevan a cabo una evaluacin de la preparacin de transformacin, al menos, descubrir los problemas de transformacin empresarial. Esta evaluacin se basa en la determinacin y el anlisis / calificacin de una serie de factores de preparacin. El resultado es una mayor comprensin de los desafos y oportunidades que se podran presentar en el transcurso de la tarea. Muchos de los desafos que se traducen directamente en los riesgos que tienen que ser abordados, supervisado, y, si es posible, mitigados. Las siguientes secciones describen Evaluacin de la preparacin de transformacin de negocios usando el mtodo BTEP, incluyendo algunas de las lecciones aprendidas.Los lectores deben tener en cuenta que la mayora de las organizaciones tienen su propio conjunto nico de factores y criterios, pero la mayora son similares.
30.2 Determinar los factores de Preparacin

El primer paso es determinar qu factores tendrn un impacto en la transformacin de los negocios asociados a la migracin desde la lnea de base a Target Arquitecturas. Esto puede lograrse mejor a travs de la realizacin de un taller dirigido a personas de diferentes partes de la organizacin. Es importante que todas las perspectivas son buscados como se variarn los temas. En este taller, es muy til empezar con una lista tentativa de los factores que los participantes puedan reutilizar, rechazar, aumentar o reemplazar. Un ejemplo conjunto de factores extrados de la BTEP sigue: Visin es la capacidad de definir y comunicar lo que se quiere lograr con claridad. Aqu es donde la gestin es capaz de definir con claridad los objetivos, tanto en trminos estratgicos y especficos. El liderazgo en la definicin de la visin y necesidades proviene de la parte comercial de IT de entrada. Existen procesos predecibles y probadas para pasar de la visin a la exposicin de las necesidades. Los principales impulsores de la iniciativa son claros. El alcance y el enfoque de la iniciativa de transformacin se han definido claramente en toda la organizacin. Deseo, Voluntad, y resolver es la presencia de un deseo de alcanzar los resultados, la disposicin a aceptar el impacto de hacer el trabajo, y la decisin de seguir adelante y completar la tarea. Hay una discusin activa sobre el impacto que la ejecucin del proyecto pueda tener en la organizacin, con indicacin clara de la intencin de aceptar las consecuencias. Recursos clave (por ejemplo, financieros, humanos, etc) se asignan para el esfuerzo y los altos ejecutivos proyectar el mensaje claro de que la organizacin va a seguir adelante; un mensaje que identifica el esfuerzo, as como los beneficios. Vista organizativo hay antecedentes de terminar lo que est en marcha y de llegar a un cierre en temas en los plazos necesarios y hay un consenso en toda la organizacin que la iniciativa de transformacin es la cosa "correcta" de hacer. Necesita , en que hay una necesidad imperiosa de ejecutar la tarea. Hay declaraciones claras en cuanto a lo que la organizacin no va a ser capaz de hacer si el proyecto no avanza, y las declaraciones igualmente claras de lo que el proyecto permitir a la organizacin a hacer. Hay consecuencias visibles y ampliamente entendido de criterios de fallo esfuerzo y xito han sido claramente identificada y comunicada. Caso de Negocio existe eso crea un fuerte enfoque en el proyecto, la identificacin de los beneficios que se deben alcanzar y creando con ello un imperativo para tener xito. El documento de modelo de negocio identifica beneficios concretos (ingresos o ahorros) que
Pgina312de670

TOGOF9.1
la organizacin se compromete a entregar y con claridad y, sin duda, los puntos a los objetivos que la organizacin se ha comprometido a lograr. La financiacin , en forma de una clara fuente de recursos fiscales, existe que cumple una inversin potencial del emprendimiento. Patrocinio y Liderazgo existe y es ampliamente compartido, pero no tan amplio como para difundir la rendicin de cuentas. Liderazgo mantiene a todos "a bordo" y mantiene todas ellas centradas en los objetivos estratgicos. El esfuerzo es patrocinado por un ejecutivo que est alineado adecuadamente para proporcionar el liderazgo de las necesidades empeo y capaz de articular y defender las necesidades de la empresa a nivel de la alta direccin. Estos patrocinadores ejecutivos son y seguirn siendo participar en todo. Gobernabilidad es la capacidad de involucrar a la participacin y el apoyo de todas las partes con un inters o responsabilidad de la empresa con el objetivo de garantizar que se sirven a los intereses corporativos y los objetivos alcanzados. Es evidente que hay grupos de inters identificados y un sentido claro de su inters y responsabilidad con el proyecto; una cultura que fomenta la participacin hacia objetivos corporativos en lugar de locales; una historia de ser capaces de gestionar con xito las actividades que cruzan reas de inters; una cultura que fomenta significativa, en comparacin con simblica, la participacin en los procesos de gestin; y un compromiso de constante revisin y desafo y la apertura a asesoramiento externo del proyecto. Responsabilidad es la asignacin de responsabilidades especficas y apropiadas, el reconocimiento de las expectativas medibles por todas las partes interesadas, y la alineacin de la toma de decisiones con reas de responsabilidad y con el lugar donde se sentir el impacto de las decisiones. Rendicin de cuentas est alineada con la zona en la que se harn sentir los beneficios del xito o consecuencias del fracaso del esfuerzo, as como con las reas de responsabilidad. Enfoque y Ejecucin Modelo realizable es un enfoque que tiene sentido en relacin con la tarea, con un ambiente de apoyo, el modelo de un mtodo de probada eficacia. Hay nociones claras del cliente y del cliente papel en relacin con el constructor o contratista principal y la organizacin tiene experiencia con los esfuerzos de este tipo para que los procesos, las disciplinas, los conocimientos y la gobernabilidad ya estn en marcha, probado y disponible para aplicar para el esfuerzo de transformacin. Todos los jugadores saben su papel porque los han jugado antes con xito. En particular, las funciones de "cliente" y "constructor de sistemas" son maduros y estables. Hay un plan de comunicacin que cubren todos los niveles de la organizacin y la satisfaccin de las necesidades que van desde la conciencia de la disponibilidad de los detalles tcnicos. Hay una recompensa y el plan de reconocimiento en lugar de reconocer los equipos y los individuos que utilizan buenas prcticas de gestin del cambio, la planificacin y la prevencin de conductas de crisis, y que reforzar las conductas apropiadas para la nueva forma de hacer negocios. Es claro para todos cmo se producir la aplicacin, cmo va a ser monitoreada, y cmo las acciones reajuste se har y hay suficientes recursos dedicados a la vida de la transformacin. Capacidad de TI para ejecutar es la capacidad de realizar todas las tareas de TI que requiere el proyecto, incluyendo las habilidades, herramientas, procesos y capacidad de gestin. Ha habido una reciente ejecucin exitosa de un esfuerzo similar de tamao y complejidad similar y existen procesos adecuados, la disciplina, las habilidades, y un modelo justificacin para decidir qu habilidades y actividades a la fuente externa.
Pgina313de670

TOGOF9.1
Empresa capacidad de ejecucin es la capacidad de la empresa para llevar a cabo todas las tareas requeridas por la empresa, en reas fuera de las TI, incluyendo la capacidad de tomar decisiones dentro de las limitaciones de tiempo tpicos para entornos basados en la reciente ejecucin exitosa de un proyecto similar esfuerzo de por lo menos la mitad del tamao y complejidad. Existen procesos no-IT-especficos, disciplina y habilidades para hacer frente a este tipo de esfuerzo. La empresa tiene una capacidad demostrada para tratar con el tipo de problemas de gestin de la cartera en curso / proyecto y los requisitos. Hay un reconocimiento de la necesidad de conocimientos y desarrollo de habilidades para la nueva forma de trabajar, as como el valor de un anlisis de las deficiencias formales sobre las capacidades y comportamientos. Capacidad empresarial para implementar y operar los elementos de transformacin y de sus procesos de negocio relacionados, absorber los cambios derivados de la aplicacin, y la capacidad continua para operar en el nuevo entorno. La empresa tiene una capacidad probada recientemente para hacer frente a los problemas de gestin de cambios derivados de nuevos procesos y sistemas y que ha establecido un programa slido y disciplinado proceso impulsado por los servicios de gestin que facilite las operaciones, el mantenimiento y el apoyo a los sistemas existentes.
Una vez que se han identificado y definido los factores, es til para llamar a un taller de seguimiento en donde se evaluarn los factores con ms detalle en trminos de su impacto / riesgo. En la siguiente seccin se ocupar de la preparacin para una evaluacin eficaz de estos factores.
30.3 Factores de preparacin actuales

Una vez que se determinan los factores, es necesario presentar de una manera tal que la evaluacin es clara y el valor mximo se deriva de los participantes. Uno de tales presentacin es a travs del uso de modelos de madurez. Si cada factor se convierte en un modelo de madurez (un activo reutilizable gobierno tambin) acompaado de una plantilla de hoja de clculo estndar que contiene toda la informacin y las deducciones que deben ser reunidos, puede ser una herramienta muy til. El modelo de madurez debe permitir a los participantes: Evale su (Arquitectura de referencia) nivel de madurez actual Determinar el nivel de madurez de destino que tendra que ser alcanzado a darse cuenta de la arquitectura destino Determine un objetivo intermedio que seran realizables en un plazo menor
El cuidado empleado en la preparacin de los modelos (que no es insignificante) ser recuperado por un taller enfocado que rpidamente pasar a travs de un nmero importante de factores. Es importante que cada factor sea bien definido y que el alcance de la empresa de arquitectura empresarial (planificacin preliminar) se reflejarn en los modelos para mantener a los participantes del taller enfocado y productivo.
Pgina314de670

TOGOF9.1
Circulacin de los modelos antes del taller para los comentarios sera til, aunque slo sea para asegurarse de que estn completos, as como permitir a los participantes a prepararse para el taller. Tenga en cuenta que el modelo que figura a continuacin tambin ha estado objetivo recomendado realizado por el arquitecto empresarial; esta vez acta como gobierno. Un ejemplo de un modelo de madurez se muestra en la Figura 30-1 para uno de los factores BTEP:
Figura301:NegocioEvaluacindelapreparacindeTransformacinModelodeMadurez
30.4 Evaluar los factores de Preparacin

Lo ideal es que los factores deben ser evaluados en un taller multidisciplinario. El uso de un mecanismo como modelos de madurez, arquitectos de la empresa normalmente tiene que cubrir una gran cantidad de terreno en poco tiempo. El uso de una serie de plantillas para cada factor acelerara la evaluacin, y garantizar la coherencia entre la amplia gama de factores. La evaluacin debe abordar tres cosas, a saber: Factor de Preparacin Vision Factor de Preparacin Clasificacin Factor de Preparacin Riesgos y Acciones
30.4.1 Factor de Preparacin Vision

La visin de un factor de disposicin es la determinacin de cuando la empresa tiene que evolucionar para abordar el factor. En primer lugar, el factor debe evaluarse con respecto a su estado base y entonces su estado de destino.
Pgina315de670

TOGOF9.1
Por ejemplo, si la "capacidad de TI para ejecutar" factor se califica como baja, el factor debe estar preferentemente a "alto" para realizar el objetivo Architecture Vision. Un objetivo intermedio podra ser til para dirigir la puesta en prctica. Los modelos de madurez son excelentes vehculos para guiar a esta determinacin.
30.4.2 Factor de Preparacin Clasificacin

Una vez establecidas las visiones de los factores, entonces es til para determinar la importancia de cada factor es a la consecucin de la arquitectura destino, as como lo difcil que ser para migrar el factor en un estado visionario aceptable. El BTEP utiliza un esquema de preparacin de Calificacin que puede ser utilizado como un punto de inicio para cualquier organizacin en cualquier vertical. Cada uno de los factores de preparacin son clasificados con respecto a: Urgencia , de forma que si un factor de disposicin es urgente, que significa que es necesario actuar antes de que pueda comenzar una iniciativa de transformacin. Estado de disponibilidad , que est clasificado como sea baja (necesita trabajo importante antes de proceder), Feria (necesita un poco de trabajo antes de proceder), aceptable (existen algunos problemas de preparacin, no hay motivos para desistir), Bueno (existen cuestiones relativamente menores) o Alta (sin preparacin cuestiones). Grado de dificultad para corregir las tasas de esfuerzo requerido para superar los problemas identificados como bien No Accin Necesaria, Fcil, Moderado o Difcil.
Aunque una plantilla ms amplia se puede utilizar en el taller, es til para crear una tabla resumen de los resultados de consolidar los factores y ofrecer una visin de gestin. Un resumen como se muestra en la Figura 30-2 .
Figura302:CuadroResumendeEvaluacindelapreparacindetransformacindenegocios Pgina316de670

TOGOF9.1
30.4.3 Factor de Preparacin Riesgos y Acciones
Una vez que los factores han sido valorados y evaluados, se derivan una serie de acciones que permitan a los factores de cambiar a un estado favorable. Cada factor debe evaluarse en relacin con el riesgo de utilizar el proceso de relieve en la parte III , 31. Gestin de Riesgos , que incluye una estimacin del impacto y frecuencia. Cada factor debe ser evaluado de forma discreta y una serie de acciones de mejora se indica. Antes de comenzar de nuevo, las acciones existentes descritos en las arquitecturas deben ser revisados antes de crear otros nuevos. Estas acciones recientemente identificados deben luego ser incorporados formalmente a la Implementacin emergentes y Plan de Migracin. Desde una perspectiva de riesgo, estas acciones estn diseadas para mitigar los riesgos y producir un riesgo residual aceptable. Como riesgos, deben ser parte del proceso de gestin de riesgos y un estrecho seguimiento como se est implementando la arquitectura empresarial.
30.5 Preparacin y planeamiento de migracin

El ejercicio de evaluacin proporcionar una evaluacin realista de la organizacin y ser un aporte importante para la planificacin de la migracin estratgica que se inici en la fase E y se termin en Fase F. Es importante tener en cuenta si las acciones de transformacin de negocio estarn en la visin de ruta crtica y, de ser as, determinar cmo van a afectar a la ejecucin. No tiene sentido el despliegue de nueva capacidad de TI sin empleados formados para ello y apoyar al personal listo para sostenerlo. Los factores de preparacin, como parte de una implementacin global y el Plan de Migracin, tendrn que ser supervisados de forma continua (Fase G) y las acciones correctivas rpidas tomadas a travs del marco de gobierno de TI para asegurar que las arquitecturas definidas se pueden implementar. La evaluacin de los factores de preparacin ser un documento vivo y durante la planificacin y ejecucin de las arquitecturas de Transicin de migracin, las actividades de transformacin empresarial desempear un papel clave.
30.6 La comercializacin del Plan de Implementacin

La definicin de la arquitectura no debe ser ampliamente difundido hasta que los problemas de transformacin de negocio sean identificados y mitigados, y acciones parte asociada de un plan general de "marketing" para la visin y la aplicacin y el Plan de Migracin. Por ejemplo, la concentracin parcelaria de la informacin podra resultar en cientos de puestos de trabajo perdidos y esta visin no debe ser anunciado antes de que un plan de recursos de la transformacin del negocio / humanos de apoyo est formulado para una nueva formacin o apoyar los esfuerzos de los trabajadores para el nuevo empleo. Los talleres de transformacin de negocio son una parte fundamental del Plan de Comunicacin mediante el cual los individuos clave dentro de la organizacin se renen para evaluar las
Pgina317de670

TOGOF9.1
consecuencias de la transformacin de la empresa. Para ello van a tomar conciencia de la Arquitectura Visin y definicin de la arquitectura (si no estaban ya involucrados a travs de los escenarios de negocios y Arquitectura de Negocios). Este grupo se sentir la propiedad de la arquitectura de la empresa, el reconocimiento de la EA como mayordomo valioso. Su determinacin de los factores que volver a crear una cultura de entendimiento entre la empresa y proporcionar informacin til para la aplicacin y el Plan de Migracin. Este ltimo plan debe incluir un plan de comunicacin, sobre todo para mantener al personal afectado informado. En muchos casos, la colaboracin con los sindicatos y delegados sindicales asistir nuevamente a una transicin integridad personal (y pacfica) al estado de destino.
30.7 Conclusin
En resumen, la implementacin de arquitectura empresarial requiere un profundo conocimiento y la conciencia de toda la transformacin del negocio los factores que impactan la transicin al estado visionario. Con la evolucin de las TI, la tecnologa actual no es el verdadero problema ms en la arquitectura de la empresa, pero los factores crticos son ms a menudo las culturales. Cualquier aplicacin y el Plan de Migracin tiene que tener tanto en cuenta. Descuidar estos y centrndose en los aspectos tcnicos, invariablemente resultar en una aplicacin mediocre que no llega a darse cuenta de la verdadera promesa de un visionario de arquitectura empresarial.
Pgina318de670

TOGOF9.1
31. Gestin de Riesgos

En este captulo se describe la gestin del riesgo, que es una tcnica que se utiliza para mitigar el riesgo en la aplicacin de un proyecto de arquitectura.
31.1 Introduccin
Siempre habr riesgo con cualquier esfuerzo de transformacin arquitectura / negocio. Es importante identificar, clasificar y mitigar estos riesgos antes de empezar, para que puedan realizar un seguimiento durante todo el esfuerzo de transformacin. La mitigacin es un esfuerzo en curso y, a menudo los factores desencadenantes de riesgo puede estar fuera del alcance de los planificadores de transformacin (por ejemplo, la fusin, de adquisicin) para los planificadores deben monitorear el contexto de transformacin constante. Tambin es importante sealar que la empresa arquitecto puede identificar los riesgos y mitigar ciertas personas, pero est dentro del marco de gobernanza que los riesgos tienen que ser primero aceptado y luego logr. Hay dos niveles de riesgo que deben ser considerados, a saber:
1. Nivel Inicial del Riesgo : categorizacin del riesgo antes de determinar e implementar acciones de mitigacin. 2. Nivel Residual de Riesgo : categorizacin del riesgo despus de la implementacin de medidas de mitigacin (si los hay).
El proceso para la gestin de riesgos se describe en las siguientes secciones y consta de las siguientes actividades: La clasificacin de riesgo Identificacin de riesgos Evaluacin del riesgo inicial La mitigacin del riesgo y evaluacin del riesgo residual Seguimiento del riesgo
31.2 Clasificacin de Riesgo

El riesgo es omnipresente en cualquier actividad arquitectura de la empresa y est presente en todas las fases en el desarrollo de mtodos de Arquitectura (ADM). Desde una perspectiva de gestin, es til para clasificar los riesgos para que la mitigacin de los riesgos se puede ejecutar con la mayor rapidez posible.
Pgina319de670

TOGOF9.1
Una forma comn de riesgos para ser clasificado es con respecto al impacto sobre la organizacin (como se explica en 31.4 Evaluacin del riesgo inicial ), por el cual los riesgos con ciertos impactos tienen que ser abordadas por ciertos niveles de gobernanza. Los riesgos se clasifican normalmente como el tiempo (horario), el costo (presupuesto), y alcance, sino que tambin podran incluir riesgos de relacin de transformacin de cliente, los riesgos contractuales, riesgos tecnolgicos, riesgos alcance y complejidad, los riesgos ambientales (de empresa), los riesgos del personal, y la aceptacin del cliente riesgos. Otra forma de delegar la gestin de riesgos es clasificar an ms los riesgos de los dominios de la arquitectura. La clasificacin de los riesgos como los negocios, la informacin, las aplicaciones y la tecnologa es til, pero puede haber formas organizativo-especficas de expresar el riesgo de que la empresa corporativa arquitectura direccin debe adoptar o ampliar en lugar de modificar. En ltima instancia, la arquitectura riesgos de la empresa son los riesgos corporativos y deben clasificarse y segn proceda manejadas en el mismo o prolongado camino.
31.3 Identificacin de Riesgos

Las evaluaciones de preparacin y transformacin de vencimiento generarn una gran cantidad de riesgos. Identificar los riesgos y determinar la estrategia para hacer frente a ellos a travs de la transformacin. El uso de Modelos de Madurez de Capacidad (CMM) es adecuada para los factores especficos asociados con la entrega de la arquitectura para identificar primera referencia y objetivos estados y luego identificar las acciones necesarias para pasar al estado de destino. Las consecuencias de no alcanzar el estado de destino pueden resultar en el descubrimiento de los riesgos. Consulte 30. Transformacin del Negocio Evaluacin de preparacin para los detalles especficos. Documentacin de riesgos se realiza en el contexto de un Plan de Gestin de Riesgos, para los que existen plantillas en las metodologas de gestin de proyectos estndar (por ejemplo, gestin de proyectos libro del conocimiento y PRINCE2), as como con las diferentes metodologas de gobierno. Normalmente estas metodologas implican procedimientos para la planificacin de contingencia, el seguimiento y la evaluacin de los niveles de riesgo; reaccionar a los cambios en factores de nivel de riesgo, as como los procesos de documentacin, informacin y comunicacin de los riesgos a los interesados.
31.4 Evaluacin del riesgo inicial

El siguiente paso consiste en clasificar los riesgos con respecto a los efectos y frecuencia de acuerdo con los baremos empleados dentro de la organizacin. Combine efecto y la frecuencia para llegar a una evaluacin preliminar del riesgo. No hay reglas duras y rpidas con respecto a los efectos y frecuencia de medicin. Las siguientes directrices se basan en las mejores prcticas de gestin de riesgos existentes. efecto podra ser evaluada utilizando los siguientes criterios de ejemplo:
Pgina320de670

TOGOF9.1
Catastrfico infiere la prdida financiera crtica que podra resultar en la quiebra de la organizacin. Crtica infiere graves prdidas econmicas en ms de una lnea de negocio que lleva a una prdida de la productividad y no retorno de la inversin en la inversin en TI. Marginal infiere una prdida financiera de menor importancia en una lnea de negocio y un retorno de la inversin en la reduccin de la inversin en TI. Insignificante infiere un impacto mnimo en una lnea de negocio 'capacidad de prestar servicios y / o productos.
Frecuencia podra indicarse como sigue: Frecuente : Probabilidad de que ocurra muy a menudo y / o de manera continua. Probable : ocurre varias veces en el transcurso de un ciclo de transformacin. Ocasionales : Ocurre espordicamente. Rara vez : remotamente posible y probablemente se producira no ms de una vez en el curso de un ciclo de transformacin. Improbable : probablemente no ocurrir durante el curso de un ciclo de transformacin.
La combinacin de los dos factores para inferir el impacto se llevar a cabo utilizando una heurstica basada en el esquema de clasificacin pero consistente para los riesgos. Un esquema de potencial para evaluar el impacto corporativa podra ser como sigue: Extremadamente Alto Riesgo (E) : El esfuerzo de transformacin lo ms probable es un error con consecuencias graves. Riesgo alto (H) : insuficiencia significativa de partes del esfuerzo de transformacin que resulta en ciertas metas no estn alcanzados. Riesgo Moderado (M) : insuficiencia notoria de partes del esfuerzo de transformacin que amenaza el xito de ciertas metas. Riesgo bajo (L) : Ciertas metas no sern un xito completo.
Estos impactos se pueden derivar utilizando un esquema de clasificacin, como se muestra en la Figura 31-1 .
Pgina321de670

TOGOF9.1 Figura311:EsquemadeClasificacindeRiesgo
31.5 Mitigacin de Riesgos y Evaluacin de Riesgo Residual

La mitigacin del riesgo se refiere a la identificacin, planificacin y ejecucin de acciones que reduzcan el riesgo a un nivel aceptable. El esfuerzo de mitigacin podra ser un sistema de seguimiento y / o simple aceptacin del riesgo para un plan de contingencia en toda regla llamando para la redundancia completa en un Plan de Continuidad de Negocio (con todo el alcance de dicha reglamentacin, el coste y las implicaciones de tiempo). Debido a las implicaciones de esta evaluacin de riesgos, tiene que llevarse a cabo de una manera pragmtica, pero sistemtica. Con prioridad va a riesgos de alto impacto frecuentes, cada riesgo debe ser mitigado a su vez.
31.6 Conducta Evaluacin del Riesgo Residual

Una vez que el esfuerzo de mitigacin se ha identificado para cada uno de los riesgos, re-evaluar el efecto y la frecuencia y luego volver a calcular los impactos y ver si el esfuerzo de mitigacin realmente ha hecho una diferencia aceptable. Los esfuerzos de mitigacin suelen consumir muchos recursos y un desembolso importante para poco o ningn riesgo residual debe ser impugnada. Una vez que se mitiga el riesgo inicial, entonces el riesgo que queda se llama el "riesgo residual". La consideracin clave es que el esfuerzo atenuante reduce realmente el impacto empresarial y no slo pasar el riesgo a otra igualmente alto cuadrante. Por ejemplo, cambiar el riesgo de frecuentes / catastrfico frecuentes / crtico todava ofrece un extremadamente de riesgo elevado. Si esto ocurre, entonces el esfuerzo de mitigacin tiene que ser re-examinado. El entregable final debe ser una evaluacin del riesgo de transformacin que podra ser estructurado como una hoja de clculo, como se muestra en la Figura 31-2 .
Figura312:EjemplodeIdentificacindeRiesgosyMitigacinHojadeevaluacin
Monitoreo 31.7 Riesgos y Gobierno (Fase G)

Los riesgos residuales tienen que ser aprobados por el marco de gobierno de TI y, potencialmente, en el gobierno corporativo, donde se requiere la aceptacin comercial de los riesgos residuales.
Pgina322de670

TOGOF9.1
Una vez que se han aceptado los riesgos residuales, la ejecucin de las acciones de mitigacin tiene que ser controlada cuidadosamente para asegurarse de que la empresa est tratando con residual en lugar de riesgo inicial. Las hojas de trabajo de evaluacin de la identificacin y mitigacin de riesgos se mantienen como los artefactos de gobierno y se mantienen al da en la Fase G (Gobernanza Aplicacin) donde se lleva a cabo el seguimiento del riesgo. Gobernabilidad implementacin puede identificar los riesgos crticos que no estn siendo mitigados y podran requerir otro ciclo ADM total o parcial.
31.8 Resumen
Gestin de riesgos es una parte integral de la arquitectura empresarial. Se anima a los profesionales a utilizar su metodologa de gestin de riesgos corporativos o ampliarlo mediante la orientacin de este captulo. En ausencia de una metodologa corporativa formal, los arquitectos pueden utilizar las instrucciones de este captulo como una buena prctica.
Pgina323de670

TOGOF9.1
32. Planificacin de Capacidad basada en

Este captulo proporciona una visin general de la planificacin basada en la capacidad, una tcnica de planificacin de negocios que se centra en los resultados de negocio.Tambin arregla bien con la friccin de coordinar proyectos a travs de dominios funcionales empresariales que en conjunto permiten a la empresa para lograr esa capacidad (por ejemplo, la prestacin de servicios electrnicos).

Planificacin basada en la capacidad se centra en la planificacin, la ingeniera, y la entrega de las capacidades estratgicas de negocio para la empresa. Es impulsada por los negocios y las empresas dirigidas y combina los esfuerzos necesarios de todas las lneas de negocio para alcanzar la capacidad deseada. Planificacin basada en la capacidad de alojar la mayora, si no todos, de los modelos de negocio de las empresas y es especialmente til en las organizaciones donde se requiere una capacidad latente para responder (por ejemplo, una unidad de preparacin para emergencias) y los mismos recursos estn implicados en mltiples capacidades. A menudo, lanecesidad de que estas capacidades se descubri y perfeccion el uso de escenarios de negocios (vase la Parte III , 26. Escenarios empresariales y objetivos de la empresa ). Desde una perspectiva de TI, la planificacin basada en la capacidad es particularmente relevante. Por ejemplo, la creacin de un centro de datos es realmente acerca de la consolidacin de los datos corporativos y de la prestacin de los servicios relacionados. Arquitectos de la empresa de entrega para esta capacidad se vern involucrados en la gestin de la construccin, la capacitacin del personal, y otras tareas de gestin del cambio, as como las tareas de arquitectura de TI. En el pasado, muchos proyectos de TI fueron menos de xito a pesar de la implementacin de TI real era brillante, pero las otras tareas asociadas (proceso de reingeniera de negocios, formacin de clientes, apoyo a la formacin, las infraestructuras, etc) fueron no controlados por la empresa arquitectos y planificadores ya menudo no se completaron satisfactoriamente. Por otra parte, los proyectos de TI a menudo se describen en trminos de prestaciones tcnicas y no como resultados de negocio, lo que hace difcil para las empresas para apreciar lo que se est entregando ya menudo los arquitectos de TI perdi de vista el objetivo empresarial fundamental. Marcos de planificacin basado en la capacidad de todas las fases del desarrollo de la arquitectura en el contexto de los resultados del negocio, vinculando claramente la visin de TI, arquitecturas (ABBS y SBB), y la aplicacin y los planes de migracin con la estratgica corporativa, de negocios, y la lnea de planes de negocios. En muchos gobiernos, la interoperabilidad horizontal y servicios compartidos se perfilan como piedras angulares de sus implementaciones de e-gobierno y la gestin basada en la capacidad es tambin prominente aunque bajo muchos disfraces. En el sector privado, los conceptos de gestin de la cadena de suministro y la Arquitectura Orientada a Servicios (SOA) estn obligando cada vez ms planificadores / gestores de gobernar tanto horizontal como verticalmente.
32,2 capacidad basada en Planificacin Paradigma

Planificacin basada en la capacidad de mucho tiempo se ha afianzado en el mbito de Defensa de los EE.UU., Reino Unido, Australia y Canad. Los mecanismos de gobernanza asociados, as
Pgina324de670

TOGOF9.1
como la capacidad de derivacin rigurosa (ingeniera de la capacidad), estn surgiendo sobre todo en el dominio de la ingeniera de sistemas.Estos conceptos son fcilmente transferibles a otros mbitos, como el de TI.
32.3 Concepto de Planificacin de Capacidad basada en

De una arquitectura empresarial y la perspectiva de TI, la planificacin basada en la capacidad es un poderoso mecanismo para asegurar que el plan estratgico de negocios conduce la empresa desde un enfoque de arriba hacia abajo. Tambin es adaptable a la ingeniera la capacidad de aprovechar las innovaciones emergentes de abajo hacia arriba. No importa cmo las estructuras de la corporacin en s , tendr que hacer frente a la entrega de capacidades de negocio cuya entrega se requerir la coordinacin y la alineacin a travs de verticales de negocio. Las capacidades son los negocios impulsados y lo ideal sera impulsado por las empresas. Uno de los principales retos es que los beneficios son recogidos muy a menudo en la empresa y no la lnea de nivel de negocios. En consecuencia, los proyectos dentro de la lnea de carteras de negocios dirigidas tienden a adoptar una lnea de negocio en lugar de la perspectiva empresarial. Gestin de la entrega de una capacidad es un reto, pero el afianzamiento de una perspectiva basada en la capacidad de una organizacin es un poderoso mecanismo para proporcionar un valor comercial derivado sinrgica que resonar en la rentabilidad y el valor de las acciones. Capacidades deben especificarse utilizando la misma disciplina en la especificacin de los objetivos como en los escenarios de negocio; concretamente, se deben seguir las pautas de SMART para evitar ambigedades. Como se muestra en la Figura 32-1 , muchas capacidades son "horizontal" y van a contrapelo de gobierno corporativo vertical normal. Muy a menudo, la gestin de la direccin, as como el marco de rendicin de cuentas de gestin empresarial se basan en la lnea de las mtricas de negocio, no mtricas empresariales. Arquitectura empresarial es tambin una funcin horizontal que se ve a nivel de empresa (as como la lnea de nivel empresarial) la optimizacin y la prestacin de servicios. Como era de esperar, la planificacin basada en la capacidad y la arquitectura de la empresa se apoyan mutuamente. Ambos suelen operar contra la corriente corporativa y ambos tienen que hacer frente a entornos empresariales exigentes. Apoyo a las empresas de arquitectura de la empresa es crucial para su xito y es lgico que se alinea con los planificadores de capacidad de las empresas, as como proporcionar apoyo a las personas dentro de las lneas verticales de negocio.
Pgina325de670

TOGOF9.1
Figura321:Conceptodeplanificacinbasadoencapacidad
Las capacidades tambin pueden ser verticales y manejado en el contexto de la estructura de organizacin de negocios. De hecho, los requisitos de capacidad a menudo conducen el diseo organizacional, pero dentro de una organizacin en el proceso de transformacin de la empresa, la organizacin pueden estar detrs de las necesidades de capacidad. Capacidades verticales son ms fciles de manejar y el apoyo de la funcin de la arquitectura empresarial, pero todava desafiante cuando los servicios se racionalizan a nivel de empresa y de las lneas de negocio reciben servicios compartidos que no controlan directamente (proporcionan un control indirecto a travs de la gobernanza de TI en el Consejo de Arquitectura tal como fue creado en la planificacin preliminar y se utiliza en la fase G (Gobernanza de Implementacin). Para la planificacin basada en la capacidad de tener xito, tiene que ser controlada con respecto a las dimensiones y los incrementos, tal como se explica en las dos secciones siguientes.
32.3.1 Capacidad Dimensiones

Las capacidades estn diseadas / generan teniendo en cuenta las diversas dimensiones que se sitan en las carteras funcionales corporativas. Cada organizacin tiene un conjunto de dimensiones diferentes pero similares. Un ejemplo de ajuste (con base en el Departamento de Defensa Nacional de Canad) podra incluir personal, investigacin y desarrollo, infraestructura / instalaciones, conceptos / procesos, gestin de la informacin y material. Lo que se seleccionan las dimensiones, deben ser bien explicadas y entendidas.
Pgina326de670

TOGOF9.1
Figura322:IncrementosdeCapacidadyDimensiones
32.3.2 Los incrementos de capacidad
Una capacidad se llevar un tiempo prolongado para entregar (detalles estarn en funcin de la organizacin y de la industria vertical) y participar normalmente muchos proyectos que entregan numerosos incrementos. Adems, la capacidad debe proporcionar un valor empresarial real a los interesados lo antes posible y mantener el impulso para lograr el Objetivo de Arquitectura, as como el apoyo ejecutivo asociado y la financiacin de las empresas. Por lo tanto, es til para romper la capacidad en incrementos de capacidad que permitan conseguir resultados discretos, visibles y cuantificables, as como proporcionar el foco para la Transicin Arquitecturas y los entregables de numerosos proyectos interdependientes. Estos resultados son los factores crticos de xito (CSF) para apoyo constante capacidad. Comunicar la potencialmente compleja evolucin incremental de una capacidad de la comunidad de partes interesadas es esencial para establecer un buy-in en el inicio y para mantener su buy-in durante la transicin. El Incremento de Capacidad diagrama "Radar" (ver Figura 32-3 ) es un mtodo de probada eficacia para describir cmo una capacidad evolucionar con el tiempo. El arquitecto selecciona los aspectos de capacidad que son importantes para la comunidad de interesados como las lneas que irradian desde el centro. Contra cada lnea, el arquitecto dibuja puntos que representan importantes "puntos de capacidad" (puntos de "inferiores" de capacidad ms cercanas al centro, "superior" puntos de capacidad ms lejanos del centro). Con estos "marcadores" en su lugar el arquitecto puede, uniendo los puntos de capacidad en un circuito cerrado, demostrar de una forma sencilla cmo cada "incremento de capacidades" se extender sobre el incremento anterior. Esto, por supuesto, requiere que cada punto de la capacidad se define formalmente y "etiqueta" de una manera que tenga sentido para los grupos de inters. En el siguiente diagrama, que hemos representado Capacidad Incremento 0 como la capacidad de arranque.
Pgina327de670

TOGOF9.1
Figura323:IncrementodeCapacidad"Radar"
32.4 Capacidades en un Contexto de Arquitectura Empresarial

Las capacidades se derivan directamente de la plan estratgico corporativo por los planificadores estratgicos corporativos que son y / o incluyen los arquitectos de la empresa y satisfacer las metas de la empresa, objetivos y estrategias. La mayora de las organizaciones tambin tendrn un plan de negocios anual que describe cmo la organizacin tiene la intencin de continuar durante el prximo ejercicio fiscal con el fin de cumplir con los objetivos estratgicos de la empresa. La figura 32-4 ilustra las relaciones cruciales entre la planificacin basada en la capacidad, la arquitectura empresarial y gestin de la cartera / del proyecto. Por el lado de la mano izquierda, la gestin de la capacidad est alineada con la arquitectura empresarial. La clave es que todas las arquitecturas se expresar en trminos de resultados empresariales y de valor ms que en trminos de TI (por ejemplo, el establecimiento de una granja de servidores), asegurando as la alineacin de TI con el negocio. La intencin es que la direccin estratgica corporativa impulsa la visin de la Arquitectura en la Fase A, as como la organizacin de la empresa, que ser la base para la creacin de carteras. Las capacidades especficas dirigidas para la finalizacin ser el tema central de la definicin de la arquitectura (las fases B, C y D) y, en base a la labor mencionadapaquetes, se concibieron proyectos Fase E.
Pgina328de670

TOGOF9.1
Los incrementos de capacidad sern los controladores para las arquitecturas de transicin (Fase E) que estructurarn los incrementos de los proyectos. La entrega real ser coordinado a travs de la aplicacin y los planes de migracin (Fase F).
Figura324:RelacinEntreCapacidades,ArquitecturaEmpresarialyProyectos
Gerentes de capacidad al desarrollo de tareas similares a las de los gestores de carteras, pero a travs de las carteras de la alineacin de los proyectos y los incrementos del proyecto para entregar valor de negocio continuo. Considerando que los gestores de cartera se ocupar de la coordinacin de sus proyectos para disear de manera ptima, construir y entregar los bloques de construccin de la solucin (SBB). Lo ideal sera que los administradores de capacidad tambin gestionarn los fondos que pueden utilizar las arquitecturas de transicin como puertas. La coordinacin entre la cartera y los administradores de capacidad tendr que ser proporcionada a nivel corporativo.
32.5 Resumen
Planificacin basada en la capacidad es un paradigma de la planificacin empresarial verstil que es muy til desde el punto de vista de arquitectura empresarial. Ayuda a la alineacin de TI con el negocio y ayuda a los arquitectos de TI se centran en la creacin continua de valor para el negocio.
Pgina329de670

TOGOF9.1
PARTEIV Marcode Arquitecturade contenido

Pgina330de670

TOGOF9.1
33. Introduccin 33.1 Informacin general

Arquitectos ejecutar el mtodo de Desarrollo Arquitectura (ADM) producirn una serie de resultados, como resultado de sus esfuerzos, como los flujos de procesos, requisitos arquitectnicos, planes de proyectos, evaluaciones de cumplimiento de proyectos, etc El marco de contenido proporciona un modelo estructural para el contenido arquitectnico que permite a los principales productos de trabajo que un arquitecto crea que definirse constantemente, estructurada y presentada. El marco de contenido provedo aqu tiene por objeto permitir TOGAF para ser utilizado como un marco independiente para la arquitectura dentro de una empresa. Sin embargo, existen otros marcos de contenido (como el Marco Zachman) y se prev que algunas empresas pueden optar por usar un marco externo en conjunto con TOGAF.En estos casos, el marco de contenido proporciona una referencia til y punto de partida para el contenido TOGAF estar asignada a otros marcos. La Arquitectura del marco de contenido usa las siguientes tres categoras para describir el tipo de producto de trabajo de arquitectura dentro del contexto de uso: Un entregable es un producto de trabajo que se especifica y, a su vez revisado formalmente, de acuerdo, y firmado por las partes interesadas contractualmente.Entregables representan la salida de los proyectos y los resultados que se tenga en forma de documentacin sern tpicamente archivadas en la finalizacin de un proyecto, o la transicin hacia un repositorio arquitectura como un modelo de referencia, estndar o instantnea de la arquitectura del paisaje en un punto en el tiempo. Un artefacto es un producto del trabajo arquitectnico que describe un aspecto de la arquitectura. Los artefactos se clasifican generalmente como catlogos (listas de cosas), matrices (que muestran las relaciones entre las cosas), y diagramas (imgenes de las cosas). Los ejemplos incluyen un catlogo de necesidades, matriz de interaccin de negocios, y un diagrama de casos de uso. Un entregable arquitectnica puede contener muchos objetos y artefactos formarn el contenido de la Arquitectura Repository. Un bloque de construccin representa un (potencialmente reutilizable), componente de negocio, TI, o la capacidad de la arquitectura que se puede combinar con otros bloques de construccin para ofrecer arquitecturas y soluciones. Bloques de construccin se pueden definir en varios niveles de detalle, dependiendo de la etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una etapa temprana, un bloque de construccin puede consistir simplemente en un nombre o una breve descripcin. Ms tarde, un bloque de construccin se puede descomponer en varios bloques de edificios de apoyo y puede ir acompaada de una especificacin completa. Bloques de construccin pueden relacionarse con "arquitecturas" o "soluciones". o Arquitectura Bloques de Construccin (Abs) suelen describir la capacidad requerida y dar forma a la especificacin de soluciones de Bloques de Construccin (SBB). Por ejemplo, una capacidad de servicio al cliente puede ser
Pgina331de670

TOGOF9.1
necesaria dentro de una empresa, con el apoyo de muchos SBB, como los procesos, datos y software de aplicacin. o Solucin Building Blocks (SBB) representan los componentes que se utilizarn para implementar la capacidad requerida. Por ejemplo, una red es un bloque de construccin que se puede describir a travs de artefactos complementarios y luego objeto de un uso para darse cuenta de las soluciones para la empresa.
Las relaciones entre los entregables, artefactos y bloques de construccin se muestran en la Figura 33-1 .

Figura331:Lasrelacionesentrelosentregables,Artefactosybloquesdeconstruccin
Por ejemplo, una definicin de documento La arquitectura es un entregable que documenta una descripcin de la arquitectura. Este documento contendr una serie de artefactos complementarios que son puntos de vista de los componentes bsicos de inters para la arquitectura. Por ejemplo, un diagrama de flujo del proceso (un artefacto) puede ser creado para describir el proceso de gestin de llamadas de destino (un bloque de construccin). Este artefacto puede tambin describir otros bloques de construccin, tales como los actores involucrados en el proceso (por ejemplo, un representante de servicios al cliente). Un ejemplo de las relaciones entre los entregables, artefactos y bloques de construccin se ilustra en la Figura 2-2 .
Pgina332de670

TOGOF9.1
Figura332:EjemploArquitecturadedefinicindedocumento
33.2 Metamodel contenido

El metamodelo de contenidos proporciona una definicin de todos los tipos de bloques de construccin que puedan existir dentro de una arquitectura, que muestra cmo estos bloques de construccin pueden ser descritos y relacionados entre s. Por ejemplo, al crear una arquitectura , un arquitecto identificar las aplicaciones, "entidades de datos", realizado dentro de las aplicaciones y tecnologas que implementan esas aplicaciones. Estas aplicaciones sern a su vez apoyar a determinados grupos de usuarios de negocios o actor, y se utilizarn para cumplir con los "servicios empresariales". El metamodelo contenido identifica todas estas preocupaciones (es decir, la aplicacin, entidad de datos, tecnologa, actor, y servicios empresariales), muestra las relaciones posibles entre ellos (por ejemplo, los actores consumen servicios de negocios), y, finalmente, identifica los artefactos que se pueden utilizar para que los represente. La Figura 33-3 muestra una visin general del metamodelo contenido.
Pgina333de670

TOGOF9.1
Figura333:ContenidoMetamodelInformacingeneral
33.3 Marco de Contenido y el TOGAF ADM

El TOGAF ADM describe el proceso de pasar de un estado de la lnea de base de la empresa a un estado objetivo de la empresa. El ADM se abordar una necesidad de negocio a travs de un proceso de la visin, la definicin de la arquitectura, la planificacin de la transformacin, y la gobernanza de la arquitectura. En cada etapa de este proceso, el ADM requiere informacin como entradas y salidas crear como resultado de la ejecucin de un nmero de pasos. El marco de contenido proporciona una estructura subyacente para el ADM que define las entradas y salidas con ms detalle y pone cada resultado en el contexto de la vista de la arquitectura global de la empresa. Por tanto, el marco de contenidos debe ser utilizado como un complemento de la ADM. El ADM se describe lo que hay que hacer para crear una arquitectura y el marco de contenido describe lo que la arquitectura debe ser similar, una vez que se hace.
33.4 Estructura de la Parte IV

Parte IV: Arquitectura del marco de contenido est estructurado de la siguiente manera: Introduccin (este captulo)
Pgina334de670

TOGOF9.1
Metamodel contenido (vase 34. Metamodel contenido ) Architectural Artifacts (ver 35. Architectural Artifacts ) Arquitectura Entregables (ver 36. Arquitectura entregables ) Bloques de construccin (ver 37. Building Blocks )
Pgina335de670

TOGOF9.1
34. Metamodel contenido

La Arquitectura Mtodo de Desarrollo de TOGAF (ADM) brinda un ciclo de vida de procesos para crear y gestionar arquitecturas dentro de una empresa. En cada fase dentro de la ADM, una discusin de entradas, salidas, y los pasos se describen una serie de productos o artefactos de trabajo de arquitectura, como proceso y aplicacin. El metamodelo contenido provedo aqu define una estructura formal de estos trminos para garantizar la coherencia dentro de la ADM y tambin para proporcionar una gua para las organizaciones que desean implementar su arquitectura dentro de una herramienta de arquitectura.
34.2 Contenido Metamodel Visin y Conceptos

Esta seccin proporciona una visin general de los objetivos del metamodelo contenido, los conceptos que sustentan el metamodelo, y una visin general de la propia metamodelo. En las secciones siguientes y luego ir a discutir cada rea del metamodelo con ms detalle. Contenido de esta seccin son los siguientes: Conceptos del metamodelo de contenido bsico (ver 34.2.1 Conceptos bsicos Metamodel contenido ) identifica los conceptos clave dentro del metamodelo contenido bsico, que incluye: o o o o Core y contenido extensin Modelado formal e informal Entidades metamodelo Core Catlogo, matriz, y el concepto de diagrama
Informacin general sobre el contenido metamodelo TOGAF (ver 34.2.2 Descripcin general del Metamodel contenido ) proporciona una visin general de alto nivel del contenido del metamodelo.
34.2.1 Conceptos bsicos Metamodel contenido

A TOGAF arquitectura se basa en la definicin de una serie de bloques de construccin de arquitectura dentro de la arquitectura catlogos, especificando las relaciones entre esos bloques de construccin de matrices de arquitectura, y luego la presentacin de los diagramas de comunicacin que muestran de una manera precisa y concisa lo que la arquitectura es. En esta seccin se presentan los conceptos principales que conforman el contenido metamodelo TOGAF, a travs de los siguientes apartados:
Pgina336de670

TOGOF9.1
Core y Extensin de contenido proporciona una introduccin a la forma en que TOGAF emplea un metamodelo ncleo bsico y luego se aplica una serie de mdulos de extensin para abordar los problemas arquitectnicos especficos en ms detalle. Entidades Metamodel Core introduce las centrales entidades metamodelo TOGAF, que muestra el propsito de cada entidad y las relaciones claves que apoyan la trazabilidad arquitectnico. Catlogo, Matrix, y rbol conceptual describe el concepto de catlogos, matrices y diagramas.
Core y Contenido de Extensin
El papel de TOGAF es proporcionar un estndar abierto para la arquitectura, que es aplicable en muchos escenarios y situaciones. Con el fin de cumplir con esta visin, es necesario proporcionar una completa empresa metamodelo arquitectura destacado de contenido y tambin para proporcionar la capacidad de evitar la realizacin de actividades innecesarias mediante el apoyo a la adaptacin. El metamodelo debe proporcionar un modelo bsico con el conjunto mnimo de caractersticas y luego apoyar la inclusin de extensiones opcionales durante el enganche sastrera. El ncleo TOGAF contenido metamodelo y sus extensiones se ilustran en la Figura 34-1 .
Figura341:TOGAFMetamodelcontenidoysusextensiones
El metamodelo ncleo proporciona un conjunto mnimo de contenido arquitectnico para apoyar la trazabilidad a travs de artefactos. Conceptos adicionales metamodelo para apoyar el modelado ms especfico o ms detallado estn contenidas dentro de un grupo de extensiones que los catlogos lgicamente racimo de extensin, matrices y diagramas, lo que permite el enfoque en reas de inters y el enfoque especfico.
Pgina337de670

TOGOF9.1
Todos los mdulos de extensin son opcionales y deben seleccionarse durante la Etapa Preliminar del desarrollo de la arquitectura para satisfacer las necesidades de la organizacin. Adems, los grupos de extensin descritos por el metamodelo contenido son slo una sugerencia y, adems de sastrera se pueden llevar a cabo para adaptarse a las necesidades especficas a la discrecin de los arquitectos. Este ncleo y el concepto de extensin se pretende como un paso hacia el apoyo a los enfoques de extensin de mtodos formales dentro TOGAF, tales como el mtodo de plug-in concepto que se encuentra dentro del Proceso de Ingeniera de Software Metamodel (SPEM) desarrollado por el Object Management Group (OMG). 1
Entidades Metamodel Core
El metamodelo de contenido utiliza la terminologa debatido en el TOGAF ADM como base para un metamodelo formal. Se utilizan los siguientes trminos bsicos: Actor : Una persona, organizacin o sistema que est fuera de la consideracin del modelo de arquitectura, sino que interacta con l. Componente de aplicacin : Una encapsulacin de funcionalidad de la aplicacin que est alineado con la estructuracin de la implementacin. Business Service : Soporta capacidades de negocio a travs de una interfaz definida explcitamente y se rige explcitamente por una organizacin. Entity Data : Una encapsulacin de datos que es reconocido por un experto dominio del negocio como un concepto discreto. Entidades de datos pueden estar vinculados a las aplicaciones, repositorios y servicios y pueden ser estructurados de acuerdo con las consideraciones de implementacin. Funcin : Proporciona capacidades de negocio estrechamente alineadas a una organizacin, pero no rige explcitamente por la organizacin. Servicio de Sistema de Informacin : Los elementos automticos de un servicio empresarial. Un servicio del sistema de informacin puede ofrecer o apoyar la totalidad o parte de uno o varios servicios de oficina. Unidad de Organizacin : Una unidad autnoma de los recursos con las metas, objetivos y medidas. Unidades organizativas pueden incluir partes externas y las organizaciones asociadas de negocios. Plataforma de Servicios : Una capacidad tcnica requerida para proporcionar la infraestructura que permite que apoya la entrega de aplicaciones. Rol : Un actor asume un papel para realizar una tarea. Componente Tecnologa : Una encapsulacin de la infraestructura de tecnologa que representa una clase de producto de la tecnologa o producto de tecnologa especfica.
Una definicin ms detallada de los trminos utilizados en el metamodelo contenido se puede encontrar en la parte I , 3. Definiciones .
Pgina338de670

TOGOF9.1
Algunos de los conceptos clave relacionados con la relacin de las entidades metamodelo fundamentales se describen a continuacin: Proceso normalmente debe ser usado para describir el flujo de Un proceso es un flujo de interacciones entre las funciones y servicios, y no se puede implementar fsicamente. Todos los procesos deben describir el flujo de ejecucin de una funcin y, por tanto, el despliegue de un proceso es a travs de la funcin que soporta; es decir, una aplicacin implementa una funcin que tiene un proceso, no una aplicacin implementa un proceso. Funcin describe unidades de capacidad de negocio en todos los niveles de granularidad El trmino "funcin" se utiliza para describir una unidad de capacidad de negocio en todos los niveles de granularidad, encapsulando trminos tales como cadena de valor, rea de proceso, la capacidad, la funcin empresarial, etc Cualquier unidad acotado de la funcin empresarial debe ser descrito como una funcin. Servicios a empresas apoyan los objetivos organizacionales y se definen a un nivel de granularidad en consonancia con el nivel de la gobernabilidad necesaria Un servicio de negocio opera como un lmite para una o ms funciones. La granularidad de los servicios de negocio depende del enfoque y el nfasis de la empresa (como se refleja en sus controladores, metas y objetivos). Un servicio en la Arquitectura Orientada a Servicios (SOA) terminologa (por ejemplo, una unidad de despliegue de la funcionalidad de la aplicacin) es en realidad mucho ms cerca de un servicio de aplicacin, componente de la aplicacin o componente de tecnologa, lo que puede implementar o apoyar a un servicio de negocio. Servicios a empresas se han desplegado en los componentes de aplicaciones Servicios a empresas puedan ser realizados por la actividad empresarial que no se refiere a l, o pueden ser apoyados por TI. Servicios a empresas que son apoyados por TI se despliegan en los componentes de la aplicacin. Componentes de aplicacin se pueden descomponer jerrquicamente y pueden soportar uno o ms servicios de oficina. Es posible que un servicio de negocio a ser apoyado por mltiples componentes de la aplicacin, pero esto es problemtico desde el punto de vista de la gobernabilidad y es sintomtico de servicios a las empresas que son demasiado grano grueso, o componentes de aplicaciones que son demasiado fino. Los componentes de aplicacin se despliegan en los componentes tecnolgicos Un componente de la aplicacin se lleva a cabo por un conjunto de componentes de tecnologa. Por ejemplo, una aplicacin, como "Sistema de Recursos Humanos" normalmente se llevara a cabo en varios componentes de la tecnologa, incluyendo el hardware, el software de servidor de aplicaciones y servicios de aplicacin. La figura 34-2 ilustra las entidades centrales y sus relaciones.
Pgina339de670

TOGOF9.1
Figura342:Lasentidadescentralesysusrelaciones
Catlogo, Matriz y Diagrama Concept
El metamodelo de contenido se utiliza como una tcnica para estructurar la informacin de arquitectura de una forma ordenada de manera que se puede procesar para satisfacer las necesidades de los interesados. La mayora de los grupos de inters de arquitectura en realidad no necesita saber lo que la arquitectura metamodelo es y slo se preocupan de temas especficos, tales como "Qu funcionalidad de este soporte de aplicaciones?", "Qu procesos se vern afectadas por este proyecto? ", etc Con el fin de satisfacer las necesidades de estos grupos de inters, se utilizan los conceptos TOGAF de bloques de construccin, catlogos, matrices y diagramas. Bloques de construccin son entidades de un tipo particular en el metamodelo (por ejemplo, un servicio de negocio llamado "Orden de Compra"). Bloques de construccin llevan metadatos segn el metamodelo, que apoya la consulta y anlisis. Por ejemplo, los servicios de negocios tienen un atributo de metadatos para el propietario, el cual permite que un grupo de inters para consultar todos los servicios a las empresas de propiedad de una organizacin en particular. Bloques de construccin tambin pueden incluir las entidades dependientes o contenidos, segn corresponda al contexto de la arquitectura (por ejemplo, un servicio de negocio llamado "Orden de Compra" puede incluir implcitamente una serie de procesos, entidades de datos, componentes de la aplicacin, etc.) Los catlogos son listas de bloques de construccin de un tipo especfico, o de que lo incluya, que se utilizan para los propsitos de gobierno o de referencia (por ejemplo, un organigrama, que
Pgina340de670

TOGOF9.1
muestra la ubicacin y los actores). Al igual que con bloques de construccin, catlogos llevan metadatos segn el metamodelo, que apoya la consulta y anlisis. Las matrices son redes que muestran las relaciones entre dos o ms entidades de modelo. Las matrices se utilizan para representar las relaciones que son basados en la lista en lugar de grfica en su uso (por ejemplo, una matriz que muestra qu aplicaciones CRUD crear, leer, actualizar y eliminar un determinado tipo de datos es difcil de representar visualmente). Los diagramas son representaciones de contenido arquitectnico en un formato grfico para permitir a las partes interesadas para recuperar la informacin requerida.Diagramas tambin se pueden utilizar como una tcnica para poblar grficamente contenido de arquitectura o para comprobar la integridad de la informacin que se ha recogido. TOGAF define un conjunto de diagramas de arquitectura que se creen (por ejemplo, el organigrama). Cada uno de estos diagramas se pueden crear varias veces para una arquitectura con un estilo diferente o la cobertura de contenido de acuerdo a las preocupaciones de las partes interesadas. Bloques de construccin, catlogos, matrices y diagramas son conceptos que estn bien apoyados por los principales herramientas de arquitectura empresarial. En los entornos donde se utilizan herramientas para modelar la arquitectura, estas herramientas suelen apoyar mecanismos para buscar, filtrar y consultar la Arquitectura Repository. Consultas a peticin del Repositorio Arquitectura (como el ejemplo de la propiedad de servicio de negocio se ha mencionado anteriormente) se puede utilizar para generar ad hoc, catlogos, matrices y diagramas de la arquitectura. Como este tipo de consulta es, por naturaleza, exige ser flexible, es, por tanto, no se limita o define dentro del metamodelo contenido. Las interacciones entre bloques metamodelo, construccin, diagramas, y las partes interesadas se muestran en la Figura 34-3 .
Pgina341de670

TOGOF9.1
Figura343:InteraccionesentreMetamodel,bloquesdeconstruccin,diagramas,ylaspartes interesadas
34.2.2 Descripcin general del Metamodel contenido
El metamodelo de contenido define un conjunto de entidades que permiten a los conceptos arquitectnicos que se capturen, almacenen, se filtr, consultan, y se representan en una manera que apoye la consistencia, integridad y trazabilidad. Al ms alto nivel, el marco de contenido se divide de acuerdo con las fases TOGAF ADM, como se muestra en la Figura 34-4 .
Pgina342de670

TOGOF9.1 Figura344:ContenidoMarcoporFasesADM
Principios Arquitectura, Visin y Requerimientos artefactos estn destinados a captar el contexto que lo rodea de modelos de arquitectura formales, incluyendo los principios generales de arquitectura, el contexto estratgico que constituye la entrada para el modelado de la arquitectura, y los requisitos generados a partir de la arquitectura. El contexto arquitectura tpicamente queda recogida en las fases preliminares y Arquitectura de la visin. Arquitectura Profesiones artefactos captan los modelos arquitectnicos de la operacin del negocio, centrndose especficamente en los factores que motivan a la empresa, cmo se estructura organizativamente la empresa, y tambin lo que las capacidades funcionales de la empresa tiene. Sistemas de Informacin Arquitectura modelos artefactos arquitectura de captura de los sistemas de TI, mirando a las aplicaciones y datos de acuerdo con las fases TOGAF ADM. Arquitectura Tecnologa artefactos captura adquiri los activos tecnolgicos que se utilizan para poner en prctica y hacer realidad soluciones de sistemas de informacin. Arquitectura Realizacin hojas de ruta del cambio artefactos de captura que muestran la transicin entre los estados de arquitectura y estados de enlace que se utilizan para dirigir y gobernar una implementacin de la arquitectura.
Una representacin ms detallada de la metamodelo contenido se muestra en la Figura 34-5 .
Pgina343de670

TOGOF9.1 Figura345:RepresentacindetalladadelaMetamodelcontenido
34.3 Metamodel contenido al detalle

Esta seccin contiene los siguientes apartados: Metamodel contenido Core (ver 34.3.1 Contenido Core Metamodel ) describe las entidades metamodelo que forman el metamodelo contenido bsico. Artefactos arquitectura de ncleo (vase 34.3.2 Arquitectura del ncleo Artifacts ) enumera el conjunto de artefactos destinados a acompaar el metamodelo contenido bsico. Metamodel contenido completo (vase 34.3.3 completa Metamodel contenido ) describe las entidades metamodelo que forman extensiones al metamodelo contenido.
34.3.1 Contenido Core Metamodel

La figura 34-6 muestra las entidades metamodelo y relaciones que estn presentes dentro del metamodelo contenido bsico.

Figura346:EntidadesyrelacionespresentesenelMetamodelcontenidoCore
Pgina344de670

TOGOF9.1
34.3.2 Arquitectura del ncleo Artefactos
35. Architectural Artifacts discute en detalle la forma en que el metamodelo contenido subyacente puede ser utilizado para presentar un conjunto de catlogos, matrices y diagramas para hacer frente a las preocupaciones de las partes interesadas. El siguiente conjunto de artefactos estn destinadas a acompaar el metamodelo contenido bsico:
ADM Fase Preliminar Architecture Vision Artefactos Principios Catlogo Stakeholder Mapa Matrix Diagrama de la Cadena de Valor Solucin Concepto Diagrama Catlogo Organizacin / Actor Catlogo de funciones Business Service / Funcin catlogo Matriz de Interaccin de Negocios Matrix Actor / Rol Negocios Huella Diagrama Business Service / Diagrama de Informacin Diagrama de Descomposicin Funcional Diagrama del ciclo de vida del producto Catlogo de Entity Data / componente de datos Entity Data / Matrix Funcin comercial Aplicacin / Data Matrix Diagrama conceptual de datos Diagrama de lgica de datos Diagrama de Divulgacin de Datos Catlogo cartera de aplicaciones Catlogo de interfaz Aplicacin / Matrix Organizacin Matrix Papel / Aplicacin Matrix Aplicacin / Funcin Aplicacin matriz de interaccin Aplicacin Diagrama Comunicacin Solicitud y usuario Ubicacin Diagrama Diagrama de Casos de Uso Catlogo de Estndares de Tecnologa Catlogo Cartera Tecnolgica Aplicacin / Matrix Tecnologa Entornos y diagrama de las ubicaciones Plataforma Descomposicin Diagrama Proyecto Diagrama de Contexto Diagrama de Beneficios Requisitos del catlogo
Arquitectura de Negocios
Sistemas de Informacin (Arquitectura de Datos)
Sistemas de Informacin (Solicitud de Arquitectura)
Arquitectura Tecnologa
Oportunidades y Soluciones Gestin de Requisitos
34.3.3 completa Metamodel contenido

Cuando todas las extensiones se aplican al metamodelo contenido bsico, se introducen una serie de nuevas entidades metamodelo. Figura 34-7 muestra qu entidades estn contenidos en el metamodelo contenido bsico y que nuevas entidades se introducen mediante el cual la extensin.
Pgina345de670

TOGOF9.1
Figura347:Metamodelcontenidoconextensiones
Las relaciones entre las entidades del metamodelo completo se muestran en la Figura 34-8 .
Pgina346de670

TOGOF9.1
Figura348:Lasrelacionesentrelasentidadesdelmetamodelocompleto
Pgina347de670

TOGOF9.1
34.4 Extensiones Metamodel contenido

Como se seal anteriormente, el contenido metamodelo TOGAF es compatible con una serie de mdulos de extensin que permiten una reflexin ms profunda para las preocupaciones particulares de la arquitectura. Figura 34-9 muestra el metamodelo contenido bsico y mdulos de extensin predefinidos.
Figura349:CoreMetamodelContenidoyMdulosdeExtensinpredefinidos
Durante la fase de Visin Arquitectura de un compromiso en particular, el alcance del trabajo se puede utilizar para hacer una determinacin sobre extensiones adecuadas para ser utilizadas con el fin de abordar adecuadamente los requisitos de arquitectura. Por ejemplo, el alcance de un compromiso podra ser definida como el contenido de ncleo, adems de las extensiones de gobierno, como se muestra en la figura 34-10 .
Figura3410:ContenidoCoreconextensionesdeGobierno
Las siguientes secciones proporcionan una descripcin ms detallada de la finalidad y el contenido de cada uno de los mdulos de ampliacin.
Pgina348de670

TOGOF9.1
34.4.1 Extensiones de Gobierno
Propsito
La extensin de gobierno tiene la intencin de permitir que los datos estructurados adicionales que se celebrarn con los objetivos y servicios a las empresas, el apoyo a la gobernabilidad operacional del paisaje. El alcance de esta extensin es como sigue: La posibilidad de aplicar medidas destinadas a objetivos y vincular estas medidas a los servicios La capacidad de aplicar los contratos para el servicio de comunicaciones o de servicios de interaccin con los usuarios y los sistemas externos La capacidad de definir calidades de servicio reutilizables definir un perfil de nivel de servicio que se puede utilizar en los contratos Creacin de diagramas adicionales para mostrar la propiedad y gestin de los sistemas
Esta ampliacin se debe utilizar en las siguientes situaciones: Cuando una organizacin est considerando cambios de TI que se traducir en un impacto significativo en los modelos de gobernanza operacionales existentes Cuando una organizacin tiene requisitos granulares para los niveles de servicio que difieren de un servicio a otro Cuando una organizacin est tratando de transformar su prctica de gobierno operativa Cuando una organizacin tiene muy fuerte enfoque en los impulsores del negocio, las metas y objetivos y cmo se traza en los niveles de servicio
Los beneficios de usar esta extensin son los siguientes: Los niveles de servicio se definen de una manera ms estructurada, con: o o o Ms detalles La capacidad de reutilizar los perfiles de servicio a travs de contratos Ms fuerte rastreo de objetivos de negocio
Impactos a las operaciones y modelos de gobernanza operacionales se consideran de una manera ms estructurada, con: o o Diagramas adicionales del sistema y los datos de propiedad Diagramas adicionales de funcionamiento del sistema y las dependencias en los procesos de operaciones
Pgina349de670

TOGOF9.1
Adems de las extensiones descritas aqu, las organizaciones que deseen centrarse en la gobernanza arquitectura tambin deben consultar: El marco COBIT para la gobernanza de TI proporcionados por los Sistemas de Informacin de Auditora y Control Association (ISACA); consulte www.isaca.org El Fondo para el IT Portfolio Management (ITPMF) del OMG; consulte www.omg.org / spec / ITPMF
Cambios necesarios en el Metamodel
Los cambios en las entidades metamodelo y relaciones se muestran en la Figura 34-11 .
Figura3411:ExtensionesdeGobierno:CambiosenMetamodel
Los cambios en las entidades metamodelo y relaciones son las siguientes:
Pgina350de670

TOGOF9.1
Medida se aade como una nueva entidad que une objetiva y servicio de negocio. Calidad de servicio se aade como una nueva entidad que ofrece un servicio de plantilla de perfil genrico que se aplica a los servicios empresariales o contratos. Contrato se aade como una nueva entidad que formaliza las caractersticas funcionales y no funcionales de una interaccin de servicio con otros servicios, aplicaciones externas, o los usuarios.
Los cambios en los atributos metamodelo son los siguientes: Los atributos se aaden a las nuevas entidades metamodelo de Medida, Calidad de Servicio y Contrato de Servicios
Diagramas adicionales que se creen son los siguientes: Diagrama de administracin de Enterprise
34.4.2 Servicios Extensiones

Propsito
La extensin de los servicios tiene por objeto permitir ms sofisticado modelado de la cartera de servicios mediante la creacin de un concepto de los servicios es, adems del concepto bsico de servicios de oficina. SE servicios estn soportados directamente por las aplicaciones y la creacin de la capa de abstraccin relaja las restricciones en los servicios empresariales al tiempo que permite a la vez actores tcnicos que ponen ms formalidad en un catlogo de servicios de SI. El alcance de esta extensin es como sigue: Creacin de servicios de SI como una extensin del servicio de negocio
Esta ampliacin se debe utilizar en las siguientes situaciones: Cuando la empresa tiene una definicin preestablecida de sus servicios que no se alinea as con las necesidades tcnicas y arquitectnicas Cuando el negocio y TI utilizan un lenguaje diferente para describir capacidades similares Cuando el servicio de TI est desalineado con necesidad de negocio, especialmente en torno a las reas de calidad de servicio, la visibilidad del rendimiento y granularidad de gestin Dnde est tomando las primeras medidas para la participacin del comercio en los debates sobre la arquitectura de TI
Los beneficios de usar esta extensin son los siguientes: Servicios de negocios se pueden definir fuera de las limitaciones que existen en el metamodelo bsico. Esto permite una participacin ms natural con accionistas de la empresa.
Pgina351de670

TOGOF9.1
Servicios de SI pueden ser definidos de acuerdo a un modelo que correlaciona estrechamente con la aplicacin, proporcionando una abstraccin solucin ms realista para dar soporte a la toma de decisiones. Relaciones de servicios de negocios y es muestran donde la vista de negocios se alinea con la vista y donde hay desajustes.
Adems de las extensiones descritas aqu, las organizaciones que deseen centrarse en arquitecturas de servicios centrada tambin deben consultar: El Service Component Architecture (SCA) especificacin desarrollada por la Arquitectura Orientada a Servicios Abiertos colaboracin (OSOA); consulte www.oasis-opencsa.org/sca Los Service Data Objects (SDO) de la especificacin desarrollada por la Arquitectura Orientada a Servicios Abiertos colaboracin (OSOA); consulte www.oasisopencsa.org/sdo
Figura3412:ServiciosdeExtensin:LoscambiosenMetamodel
Pgina352de670

TOGOF9.1
Es el servicio se aade como una nueva entidad metamodelo, extender el servicio de negocio. ES Servicio hereda todas las relaciones de un servicio de negocio. Se crea una nueva relacin que conecte a un servicio es un servicio de negocio.
Los cambios en los atributos metamodelo son los siguientes: Es el servicio se aade como un nuevo tipo de servicio de negocio.
Diagramas adicionales que se creen son los siguientes: Diagrama de negocios de casos de uso Organizacin Descomposicin Diagrama
34.4.3 Extensiones de modelado de procesos

Propsito
La extensin de modelado de procesos tiene por objeto permitir el modelado detallado de los flujos de procesos mediante la adicin de eventos, productos y controles para el metamodelo. Tpicamente, arquitectura de la empresa no perforar en el flujo de proceso, pero en ciertas organizaciones proceso-cntrica o-centrado de eventos puede ser necesario para la elaboracin de proceso de una manera mucho ms formal utilizando este mdulo de extensin. El alcance de esta extensin es como sigue: Creacin de eventos como desencadenantes de procesos Creacin de controles que la lgica de negocio y de gobierno puertas para la ejecucin de procesos Creacin de productos para representar la salida de un proceso de Creacin de diagramas de eventos para realizar un seguimiento de los disparadores y los cambios de estado en toda la organizacin
Esta ampliacin se debe utilizar en las siguientes situaciones: Cuando la arquitectura debe prestar especial atencin a estado y eventos Cuando se requiera la arquitectura para identificar de manera explcita y medidas de control de proceso de almacenamiento; por ejemplo, para apoyar el cumplimiento regulatorio Cuando la arquitectura cuenta con crticos o fluye elaborado proceso
Los beneficios de usar esta extensin son los siguientes:
Pgina353de670

TOGOF9.1
Esta extensin permite el modelado de procesos detallado y la catalogacin de los artefactos de proceso. Puede ser utilizado para apoyar las actividades de cumplimiento normativo. Se puede utilizar para volver a propsito de la herencia o el anlisis de descomposicin de procesos no-arquitectnico.
Adems de las extensiones descritas aqu, las organizaciones que deseen centrarse en arquitecturas basadas en procesos tambin deben consultar: El Business Process Modeling Notation (BPMN) especificacin, proporcionada por el OMG; consulte www.bpmn.org El Proceso de Ingeniera de Software Metamodel (SPEM) especificacin, proporcionada por el OMG; consulte www.omg.org / Spec / SPEM
Figura3413:ProcesoExtensionesModelado:CambiosenMetamodel
Pgina354de670

TOGOF9.1
Evento se aade como una entidad metamodelo, sentado entre Actor, proceso y servicio El control se agrega como una entidad metamodelo, relativa a un proceso. El producto se aade como una entidad metamodelo, vinculando Organizacin y Procesos.
Los cambios en los atributos metamodelo son los siguientes: Los atributos se aaden a las nuevas entidades metamodelo de eventos, control y del producto.
Diagramas adicionales que se creen son los siguientes: Diagramas de flujo del proceso, que muestran la forma en que las funciones de negocios, eventos, controles y productos estn relacionados con apoyar un escenario de negocios en particular Diagramas de eventos, mostrando los acontecimientos, se que se reciben, y qu procesos se desencadenan
34.4.4 de Extensiones
Propsito
La extensin de datos est destinado a permitir el modelado ms sofisticado y la encapsulacin de datos. El modelo bsico ofrece un concepto de entidad de datos que soporta la creacin de modelos de datos, que se extendi luego por esta extensin para incluir el concepto de un componente de datos. Los componentes de datos forman un encapsulamiento lgica o fsica de las entidades de datos abstractos en unidades que pueden ser gobernados y desplegados en las aplicaciones. El alcance de esta extensin es como sigue: Creacin de componentes de datos lgicos que las entidades de datos de grupo en mdulos encapsulados con fines de gobernabilidad, seguridad y despliegue Creacin de componentes fsicos de datos que implementan los componentes de datos lgicos y son anlogas a las bases de datos, registros, depsitos, esquemas y otras tcnicas de segmentacin de datos Creacin del ciclo de vida de los datos, seguridad de datos y diagramas de migracin de datos de la arquitectura para mostrar las preocupaciones de datos con ms detalle
Esta ampliacin se debe utilizar en las siguientes situaciones: Cuando la arquitectura cuenta con complejidad y riesgo significativo en torno a la ubicacin, la encapsulacin, y la gestin o el acceso a los datos
Los beneficios de usar esta extensin son los siguientes:
Pgina355de670

TOGOF9.1
La estructura de los datos se modela independientemente de su ubicacin, lo que permite modelos de datos que deben desarrollarse que abarcan mltiples sistemas sin estar atado a las preocupaciones fsicas. Agrupaciones lgicas de datos pueden ser utilizados para establecer la gobernabilidad, la seguridad, o lmites de despliegue alrededor de los datos, proporcionando una apreciacin mucho ms holstica de los problemas de datos en torno a la arquitectura.
Figura3414:Extensionesdedatos:LoscambiosenMetamodel
Los cambios en las entidades metamodelo y relaciones son las siguientes: Componente lgica de datos se agrega como una nueva entidad metamodelo, encapsulando las entidades de datos. Componente Fsico de Datos se aade como una nueva entidad metamodelo, que se extiende de componentes lgica de datos. Se crea una relacin entre el Componente Fsico de Datos y componente de aplicacin. Si se aplica la extensin de consolidacin de la infraestructura, esta debe ser fsica componente de aplicacin. Si se aplica la extensin de consolidacin de la infraestructura, componentes de datos fsica tendr una relacin con Location.
Los cambios en los atributos metamodelo son los siguientes: Los atributos se aaden a las nuevas entidades metamodelo de lgica de componentes de datos y componentes de datos fsicos.
Diagramas adicionales que se creen son los siguientes:
Pgina356de670

TOGOF9.1
Diagrama de seguridad de datos Diagrama de migracin de datos Diagrama del ciclo de vida de datos
34.4.5 Extensiones de Consolidacin de Infraestructura

Propsito
La extensin de la consolidacin de la infraestructura est destinado a ser utilizado en los paisajes donde las aplicaciones y tecnologa carteras hayan fragmentado y la arquitectura busca consolidar el negocio como de costumbre en la capacidad de un menor nmero de ubicaciones, aplicaciones o componentes de tecnologa. El alcance de esta extensin es como sigue: La creacin de una entidad de ubicacin para mantener la ubicacin de los activos de TI y consumidores externos de servicio Creacin de componentes de la aplicacin lgica y fsica para abstraer la capacidad de una aplicacin fuera de las aplicaciones reales de existencia Creacin de componentes de la aplicacin lgica y fsica a Tipo de producto abstracto de los productos de tecnologa de reales en existencia Creacin de diagramas adicionales centrados en la ubicacin de los activos, cumplimiento de las normas, la estructura de las aplicaciones, migracin de la aplicacin, y configuracin de la infraestructura
Esta ampliacin se debe utilizar en las siguientes situaciones: Donde muchos productos tecnolgicos estn en su lugar con el duplicado o la capacidad de superposicin Donde muchas aplicaciones estn en su lugar, con duplicado o funcionalidad de superposicin Cuando las solicitudes estn geogrficamente dispersos y la lgica de decisin para determinar la ubicacin de una aplicacin no se conoce bien Cuando las aplicaciones se van a migrar a una plataforma consolidada Cuando las funciones de aplicacin van a migrar en una aplicacin consolidada
Los beneficios de usar esta extensin son los siguientes: Permite la visibilidad y anlisis de la duplicacin redundante de la capacidad en los mbitos de aplicacin y tecnologa Soporta anlisis del cumplimiento de las normas
Pgina357de670

TOGOF9.1
Soporta el anlisis del impacto de la migracin de aplicaciones o tecnologa consolidacin Soporta definicin arquitectnica detallada de la estructura de la aplicacin
Adems de las extensiones descritas aqu, las organizaciones que deseen centrarse en la consolidacin de la infraestructura deben tambin consultar: El Lenguaje de Modelado Unificado (UML), proporcionado por el OMG; consulte www.uml.org El Sistemas de Lenguaje de Modelado (SysML) - www.sysml.org - que reduce la complejidad y el software de enfoque de ingeniera de UML para los propsitos de modelado de sistemas El Fondo para el IT Portfolio Management (ITPMF) del OMG; consulte www.omg.org / spec / ITPMF
Figura3415:InfraestructuraExtensionesdeconsolidacin:CambiosenMetamodel
Los cambios en las entidades metamodelo y relaciones son las siguientes: Ubicacin atributos de Organizacin, Actor, componente de aplicacin, el componente de datos y componentes de Tecnologa se han mejorado para crear una entidad de la ubicacin dentro del metamodelo. Componentes de aplicacin se amplan para incluir Lgico componentes de aplicacin (una clase de aplicacin) y Fsica componentes de aplicacin (una aplicacin real). Componentes tecnolgicos se amplan para incluir componentes lgicos Tecnologa (una clase de producto de tecnologa) y componentes Tecnologa Fsicas (un producto de la tecnologa actual).
Pgina358de670

TOGOF9.1
Los cambios en los atributos metamodelo son los siguientes: Creacin de atributos para las nuevas entidades Metamodel de Logical componente de aplicacin, Fsica componente de aplicacin, lgica Componente Tecnologa, Tecnologa del componente fsico y Ubicacin La eliminacin de ubicacin como un atributo de las entidades que tienen un lugar y su sustitucin por una relacin con la entidad Ubicacin
Diagramas adicionales que se creen son los siguientes: Diagrama Realizacin de proceso / aplicacin Software diagrama de Ingeniera Diagrama de Migracin de aplicaciones Diagrama de distribucin de software Diagrama de Procesamiento Diagrama de Red Informtica / Hardware Ingeniera de Comunicaciones diagrama
34.4.6 Extensiones Motivacin

Propsito
La extensin de la motivacin tiene por objeto permitir la modelizacin estructurada adicional de los controladores, las metas y objetivos que influyen en una organizacin para proporcionar servicios de negocio a sus clientes. Esto a su vez permite la definicin ms efectiva de los contratos de servicios y una mejor medicin de los resultados empresariales. El alcance de esta extensin es como sigue: Creacin de una nueva entidad metamodelo para el conductor que muestra los factores que motivan o limitan generalmente a una organizacin Creacin de una nueva entidad metamodelo para el objetivo que muestra el propsito estratgico y la misin de una organizacin Creacin de una nueva entidad metamodelo para el objetivo que se muestra cerca de los logros a mediano plazo que una organizacin desea alcanzar Creacin de un diagrama de Meta / Objetivo / servicio que muestra la trazabilidad de los conductores, las metas y objetivos a travs de los servicios
Esta ampliacin se debe utilizar en las siguientes situaciones:
Pgina359de670

TOGOF9.1
Cuando la arquitectura tiene que entender la motivacin de las organizaciones con ms detalle que los principios de negocios o de compromiso de estndares y objetivos que se modelan de manera informal dentro del metamodelo contenido bsico Cuando las organizaciones tienen los conductores y los objetivos en conflicto y que el conflicto tiene que ser entendido y tratado en una forma estructurada Cuando los niveles de servicio son desconocidos o poco clara
Los beneficios de usar esta extensin son los siguientes: Destacados desalineacin de las prioridades de toda la empresa y cmo stas se cruzan con los servicios compartidos (por ejemplo, algunas organizaciones pueden estar tratando de reducir los costos, mientras que otros estn tratando de aumentar la capacidad) Muestra la demanda de servicios empresariales que compiten de manera ms estructurada, permitiendo niveles de servicio de compromiso para definir
Adems de las extensiones descritas aqu, las organizaciones que deseen centrarse en la arquitectura de modelado de motivacin empresarial, tambin deben consultar: El Modelo Motivacin Negocio (BMM) especificacin, proporcionada por el OMG; consulte www.omg.org / tecnologa / documents / bms_spec_catalog.htm
Pgina360de670

TOGOF9.1
Extensionesdemotivacin:Figura3416CambiosenMetamodel
Los cambios en las entidades metamodelo y relaciones son las siguientes: Conductor, Meta y Objetivo se agregan como nuevas entidades que enlazan Unidad de Organizacin de Servicios de Negocio.
Los cambios en los atributos metamodelo son los siguientes: Los atributos se aaden a las nuevas entidades metamodelo de Conductor, Meta y Objetivo.
Diagramas adicionales que se creen son los siguientes: Meta / Objetivo diagrama / Servicio
Pgina361de670

TOGOF9.1
34.5 Contenido Entidades Metamodel

La siguiente tabla muestra y describe las entidades dentro del metamodelo contenido.
Metamodel Entidad Actor Descripcin
Una persona, organizacin o sistema que tiene un papel que inicia o interacta con las actividades; por ejemplo, un representante de ventas que viaja a visitar a los clientes. Los actores pueden ser internos o externos a la organizacin. En la industria automotriz, un fabricante de equipo original se considera un actor por un concesionario de automviles que interacta con sus actividades de la cadena de suministro. Componente de Una encapsulacin de funcionalidad de la aplicacin alineado con aplicacin estructura de ejecucin. Por ejemplo, una aplicacin de procesamiento de solicitud de compra. Ver tambin lgico componente de aplicacin y Fsica componente de aplicacin . Una declaracin de un hecho probable de que no ha sido plenamente validado en esta etapa, debido a las restricciones externas. Por ejemplo, se puede suponer que una aplicacin existente apoyar un cierto conjunto de requisitos funcionales, sin que tal exigencia an no hayan sido validados de forma individual. Soporta capacidades de negocio a travs de una interfaz definida explcitamente y se rige explcitamente por una organizacin. Un resultado centrado en las empresas que se entrega por la realizacin de uno o ms paquetes de trabajo. El uso de un enfoque de planificacin basado en las capacidades, las actividades de cambio pueden ser secuenciados y se agrupan con el fin de proporcionar un valor empresarial continuo e incremental. Un factor externo que impide que una organizacin de la bsqueda de enfoques particulares para cumplir sus objetivos. Por ejemplo, los datos del cliente no est armonizada dentro de la organizacin, regional o nacional, lo que limita la capacidad de la organizacin para ofrecer un servicio al cliente eficaz. Un acuerdo entre un consumidor de servicios y un proveedor de servicios que establece los parmetros funcionales y no funcionales para la interaccin. Un paso de toma de decisiones con el acompaamiento de la lgica de decisin utilizado para determinar el enfoque de ejecucin de un proceso o para asegurar que un proceso cumple con los criterios de gobierno. Por ejemplo, un control de cierre de sesin en el proceso de tramitacin de solicitud de compra que comprueba si el valor total de la solicitud est dentro de los lmites de sesin fuera de la solicitante, o si necesita una escalada a la autoridad superior. Una encapsulacin de datos que es reconocido por un experto de dominio de negocios como una cosa. Entidades de datos lgicos pueden estar vinculados a las aplicaciones, repositorios y servicios y pueden ser estructurados de acuerdo con las consideraciones de implementacin. Una condicin externa o interna que motiva a la organizacin a definir sus metas. Un ejemplo de un controlador externo es un cambio en la reglamentacin o normas de cumplimiento que, por ejemplo, requieren cambios en la forma en que una organizacin opera; es decir, la Ley Sarbanes-Oxley en los EE.UU.. Un cambio de estado de la organizacin que desencadena eventos de procesamiento; puede provenir de dentro o fuera de la organizacin y
Asuncin
Servicios de Negocio Capacidad
Restriccin
Contrato
Control
Entity Data
Conductor
Evento
Pgina362de670

TOGOF9.1
Funcin puede ser resuelto dentro o fuera de la organizacin. Proporciona capacidades de negocio estrechamente alineadas a una organizacin, pero no necesariamente gobernadas de forma explcita por la organizacin. Tambin se conoce como "funcin empresarial". Una declaracin de la diferencia entre los dos estados. Se utiliza en el contexto de anlisis de las carencias, donde se identifica la diferencia entre la lnea de base y Arquitectura Target.
Brecha
Nota: El anlisis de brechas se describe en la Parte III , 27.Anlisis Gap .

Una declaracin de alto nivel de la intencin o la direccin de una organizacin. Normalmente se utiliza para medir el xito de una organizacin. Sistema de Los elementos automticos de un servicio empresarial. Un servicio del Informacin de sistema de informacin puede ofrecer o apoyar la totalidad o parte de uno Servicio o varios servicios de oficina. Ubicacin Un lugar donde la actividad empresarial se lleva a cabo y se puede descomponer jerrquicamente. Lgico Una encapsulacin de funcionalidad de la aplicacin que es independiente Aplicacin de una implementacin particular. Por ejemplo, la clasificacin de todas Componente las aplicaciones de procesamiento de solicitud de compra implementados en una empresa. Lgica de datos Una zona de frontera que encapsula las entidades de datos relacionados de componentes para formar una ubicacin lgica que se realizar; por ejemplo, la informacin de aprovisionamiento externo. Lgico Una encapsulacin de la infraestructura de tecnologa que es Tecnologa independiente de un producto en particular. Una clase de producto de la Componente tecnologa; por ejemplo, el software de gestin de la cadena de suministro, como parte de un paquete de planificacin de recursos empresariales (ERP), o un servicio de la empresa de procesamiento de solicitud de compra Commercial Off-The-Shelf (COTS). Medida Un indicador o factor que se puede controlar, por lo general en forma permanente, para determinar el xito o el alineamiento con los objetivos y metas. Objetivo Un hito de tiempo limitado para que una organizacin utiliza para demostrar el progreso hacia una meta; por ejemplo, "Aumentar la utilizacin de la capacidad en un 30% a finales de 2009 para apoyar el aumento previsto de la cuota de mercado". Unidad de Una unidad autnoma de los recursos con metas, objetivos y Organizacin medidas.Unidades organizativas pueden incluir partes externas y las organizaciones asociadas de negocios. Fsica Una aplicacin, mdulo de aplicacin, servicios de aplicaciones, u otro componente de despliegue de la funcionalidad. Por ejemplo, una instancia Aplicacin de componentes de una planificacin de recursos empresariales (ERP) de suministro Comercial Off-The-Shelf (COTS) configurado y desplegado la aplicacin de gestin de la cadena. Datos fsicos Una zona de frontera que encapsula las entidades de datos relacionados de componentes para formar un lugar fsico que se celebrar. Por ejemplo, un objeto de negocio de la orden de compra, que comprende encabezado de la orden de compra y nodos de objetos de negocios artculo. Tecnologa Un producto de infraestructura de tecnologa o la tecnologa instancia de Fsica producto infraestructura. Por ejemplo, un determinado modelo de una Componente solucin comercial Off-The-Shelf (COTS), o de una marca especfica y la versin del servidor. Meta
Pgina363de670

TOGOF9.1
Plataforma de Servicios Principio Una capacidad tcnica que se requiere para proporcionar la infraestructura que permite que apoya la entrega de aplicaciones. Una declaracin de intenciones cualitativo que debe ser satisfecha por la arquitectura. Tiene al menos un sustento racional y una medida de importancia.
Nota: Un conjunto de muestras de principios de arquitectura se define en la Parte III , 23. Arquitectura Principios .
Proceso Un proceso representa flujo de control entre o dentro de las funciones y / o servicios (depende de la granularidad de la definicin). Los procesos representan una secuencia de actividades que en conjunto logran un resultado determinado, puede descomponerse en sub-procesos, y pueden mostrar el funcionamiento de una funcin o servicio (en el siguiente nivel de detalle). Los procesos tambin pueden ser utilizados para conectar o componer organizaciones, funciones, servicios y procesos. La salida generada por el negocio. El producto de negocios de la ejecucin de un proceso. Una declaracin cuantitativa de las necesidades de negocio que debe ser cumplida por una arquitectura o paquete de trabajo en particular. La funcin habitual o esperado de un actor, o la parte que alguien o algo juega en una accin o evento en particular. Un actor puede tener una serie de funciones. Ver tambin Actor . Un elemento de comportamiento que proporciona una funcionalidad especfica en respuesta a las peticiones de los actores o otros servicios.Un servicio de entrega o apoya las capacidades de negocio, tiene una interfaz definida explcitamente, y se rige de forma explcita. Los servicios se definen para los negocios, los sistemas de informacin y plataformas. Una configuracin preestablecida de atributos no funcionales que pueden ser asignadas a un servicio o contrato de servicio. Una encapsulacin de infraestructura tecnolgica que representa una clase de producto de la tecnologa o producto de tecnologa especfica. Un conjunto de acciones identificadas para alcanzar uno o ms objetivos para el negocio. Un paquete de trabajo puede ser una parte de un proyecto, un proyecto completo, o un programa.
Producto Requisito Papel
Servicio
Calidad de Servicio Componente Tecnologa Paquete de Trabajo
34.6 Contenido Atributos Metamodel

La siguiente tabla muestra los atributos tpicos para cada una de las entidades metamodelo descritos anteriormente.
Metamodel Descripcin Entidad Atributo Todas las Identificacin Entidades
Identificador nico para la entidad la arquitectura
Pgina364de670

TOGOF9.1
Metamodel Nombre Descripcin Categora Fuente Propietario El valor del negocio Incrementos Restriccin Brecha Ubicacin No hay atributos adicionales No hay atributos adicionales Categora Breve nombre de la entidad arquitectura Descripcin textual de la entidad arquitectura. Taxonoma de categorizacin definible por el usuario para cada entidad metamodelo. Lugar desde donde se obtuvo la informacin. Propietario de la entidad arquitectura. Describe cmo esta capacidad proporciona valor a la empresa. Enumera los posibles niveles de madurez / calidad para la capacidad. Esta entidad metamodelo slo tiene atributos bsicos. Esta entidad metamodelo slo tiene atributos bsicos.
Capacidad
Principio
Requisito
Actor
Servicios de Negocio
Las siguientes categoras de ubicacin aplican: Regin (se aplica a un grupo de pases o territorio, por ejemplo, el sudeste de Asia, Reino Unido e Irlanda), Pas (se aplica a un solo pas, por ejemplo, EE.UU.), Construccin (se aplica a un sitio de operacin, donde se recogen varias oficinas en una sola ciudad, esta categora puede representar una ciudad), y la ubicacin especfica (se aplica a cualquier ubicacin especfica dentro de un edificio, como una sala de servidores). La naturaleza de la empresa puede introducir otras ubicaciones: Nave o puerto para una compaa de ferry, Minas para una compaa de oro, coches de polica, el Hotel para los trabajadores que viajan de cualquier empresa, y as sucesivamente. Categora Las siguientes categoras de principios se aplican: Principio Rector, Principio de negocio, el Principio de datos, el principio de aplicacin, el principio de integracin, Tecnologa Principio. Prioridad Prioridad de este principio en relacin con otros principios. Declaracin de principios Declaracin de lo que el principio es. Razn fundamental Declaracin de por qu es necesario el principio y el resultado a alcanzar. Implicacin Declaracin de lo que significa el principio en trminos prcticos. Mtrico Identifica los mecanismos que se utilizarn para medir si el principio se ha cumplido o no. Norma de exigencia Declaracin de lo que el requisito es, incluyendo una definicin de si se cumple el requisito, debe cumplirse, o puede cumplirse. Razn fundamental Declaracin de por qu existe el requisito. Los criterios de aceptacin Declaracin de qu pruebas se llevarn a cabo para garantizar que se cumpla el requisito. # ETC Nmero estimado de FTE que operan como este actor. Objetivo Actor Los objetivos que este actor tiene, en trminos generales. Tareas Actor Las tareas que realiza este actor, en trminos generales. Clase de Normas No estndar, de Norma, Norma Provisional, Standard, phasing-out estndar, Jubilado estndar.
Pgina365de670

TOGOF9.1
Fecha de creacin del estndar ltima fecha de revisin estndar La prxima fecha de revisin estndar Fecha de jubilarse Caractersticas de comportamiento Nombre del servicio "el que llama" Nombre del servicio "llama" Caractersticas de calidad de servicio Caractersticas Disponibilidad Los tiempos de servicio Caractersticas de manejabilidad Caractersticas Facilidad de servicio Caractersticas de rendimiento Requisitos de respuesta Caractersticas de confiabilidad Calidad de la informacin requerida Requisitos de control de Contrato Los requisitos de control de resultados Si el producto es un estndar, cuando se cre la norma. ltima fecha en que la norma fue revisada. La prxima fecha para que la norma sea revisada. Fecha en la que la norma se ser retirado /. Comportamiento funcional para ser soportado dentro del alcance del contrato. El consumo de servicios. Proporcionar servicio. El comportamiento no funcional para el apoyo en el mbito del contrato. Grado en que algo est disponible para su uso. Horas en las que el servicio debe estar disponible. Capacidad de recopilar informacin sobre el estado de algo y controlarlo. Capacidad para identificar problemas y tomar medidas correctivas, tales como reparar o actualizar un componente en un sistema en funcionamiento. Capacidad de un componente para realizar sus tareas en un tiempo apropiado. Los tiempos de respuesta que el proveedor de servicios debe cumplir para operaciones particulares. Resistencia al fracaso.
Contrato
Requisitos contratados sobre la exactitud e integridad de la informacin. Nivel de gobierno y aplicacin de aplicarse a los parmetros contractuales para el servicio en general. Las medidas previstas para asegurar que cada solicitud de servicio cumple con los criterios contratados. Caractersticas Capacidad para restaurar un sistema a un estado de Recuperabilidad trabajo despus de una interrupcin. Caractersticas estado de Capacidad de un sistema que se encuentran cuando localizacin sea necesario. Caractersticas de Capacidad de un sistema para evitar el acceso no seguridad autorizado a las funciones y datos. Caractersticas Privacidad Proteccin de datos de accesos no autorizados. Caractersticas de Capacidad de un sistema para asegurar que los datos integridad no se ha daado. Caractersticas de Capacidad de un sistema para asegurar que la credibilidad solicitud de servicio se origina de una fuente autorizada. Caractersticas de Capacidad de un servicio para apoyar las variantes localizacin localizadas para diferentes grupos de consumidores. Caractersticas de Capacidad de un servicio para soportar las internacionalizacin variaciones internacionales en la lgica empresarial y la representacin de datos (como conjunto de caracteres). Caractersticas de La capacidad del servicio para interactuar con interoperabilidad diferentes entornos tcnicos, dentro y fuera de la organizacin.
Pgina366de670

TOGOF9.1
Caractersticas de escalabilidad Capacidad del servicio para aumentar o reducir su rendimiento o capacidad adecuada a las exigencias del entorno en el que opera. Portabilidad caractersticas De datos, personas, aplicaciones y componentes. Caractersticas de Capacidad para aceptar la nueva funcionalidad. extensibilidad Caractersticas de Capacidad contratada del proveedor de servicios para capacidad atender las solicitudes. Rendimiento Capacidad de produccin requerida. Perodo de rendimiento El periodo de tiempo necesario para entregar la capacidad de rendimiento. Crecimiento Tasa de crecimiento futuro esperado de solicitud de servicio. Perodo de crecimiento El periodo de tiempo necesario para alcanzar la tasa de crecimiento esperada. Perfil pico a corto plazo Perfil de corto plazo del trfico de las horas pico. Perfil pico largo plazo Perfil a largo plazo del trfico de las horas pico. No hay atributos Esta entidad metamodelo slo tiene atributos bsicos. adicionales No hay atributos Esta entidad metamodelo slo tiene atributos bsicos. adicionales No hay atributos Esta entidad metamodelo slo tiene atributos bsicos. adicionales Clase de Normas No estndar, de Norma, Norma Provisional, Standard, phasing-out estndar, Jubilado estndar. Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. No hay atributos Esta entidad metamodelo slo tiene atributos bsicos. adicionales No hay atributos Esta entidad metamodelo slo tiene atributos bsicos. adicionales No hay atributos Esta entidad metamodelo slo tiene atributos bsicos. adicionales Nmero de empleados Nmero de FTE que trabajan dentro de la organizacin. Clase de Normas No estndar, de Norma, Norma Provisional, Standard, phasing-out estndar, Jubilado estndar. Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Criticidad del proceso La criticidad de este proceso para las operaciones comerciales. Manuales o automticas, Si este proceso es apoyado por IT o es un proceso manual. Volumetra Proceso Los datos sobre la frecuencia de ejecucin de procesos. No hay atributos Esta entidad metamodelo slo tiene atributos bsicos.
Control Conductor Evento Funcin
Meta Medida Objetivo Unidad de Organizacin Proceso
Producto
Pgina367de670

TOGOF9.1
adicionales Nmero estimado de FTE Esta entidad metamodelo slo tiene atributos bsicos. que operan en este Rol Calidad de No hay atributos Esta entidad metamodelo slo tiene atributos bsicos. Servicio adicionales Servicio Clase de Normas No estndar, de Norma, Norma Provisional, Standard, phasing-out estndar, Jubilado estndar. Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Componente de Clase de Normas No estndar, de Norma, Norma Provisional, Standard, aplicacin phasing-out estndar, Jubilado estndar. Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Sistema de Clase de Normas No estndar, de Norma, Norma Provisional, Standard, Informacin de phasing-out estndar, Jubilado estndar. Servicio Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Lgico Aplicacin Clase de Normas No estndar, de Norma, Norma Provisional, Standard, Componente phasing-out estndar, Jubilado estndar. Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Fsica Aplicacin El estado del ciclo de vida Propuso en el Desarrollo, en vivo, eliminacin de componentes gradual, jubilado . Clase de Normas No estndar, de Norma, Norma Provisional, Standard, phasing-out estndar, Jubilado estndar. Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Fecha vivo inicial Fecha en la que la primera versin de la aplicacin fue / ser lanzado en la produccin. Fecha de la ltima versin Fecha en la que la ltima versin de la aplicacin fue Papel
Pgina368de670

TOGOF9.1
Fecha de la prxima versin Fecha de retiro Caractersticas Disponibilidad Los tiempos de servicio Caractersticas de manejabilidad Caractersticas Facilidad de servicio Caractersticas de rendimiento Caractersticas de confiabilidad Caractersticas Recuperabilidad Caractersticas estado de localizacin Caractersticas de seguridad Caractersticas Privacidad Caractersticas de integridad Caractersticas de credibilidad lanzada en la produccin. Fecha en la que la prxima versin de la aplicacin se dar a conocer en produccin. Fecha en la que la solicitud fue / ser retirado. Grado en que algo est disponible para su uso. Horas en las que la aplicacin debe estar disponible. Capacidad de recopilar informacin sobre el estado de algo y controlarlo. Capacidad para identificar problemas y tomar medidas correctivas, tales como reparar o actualizar un componente en un sistema en funcionamiento. Capacidad de un componente para realizar sus tareas en un tiempo apropiado. Resistencia al fracaso.
Entity Data
Capacidad para restaurar un sistema a un estado de trabajo despus de una interrupcin. Capacidad de un sistema que se encuentran cuando sea necesario. Capacidad de un sistema para evitar el acceso no autorizado a las funciones y datos. Proteccin de datos de accesos no autorizados. Capacidad de un sistema para asegurar que los datos no se ha daado. Capacidad de un sistema para asegurar que la solicitud de servicio se origina de una fuente autorizada. Caractersticas de Capacidad de un servicio para apoyar las variantes localizacin localizadas para diferentes grupos de consumidores. Caractersticas de Capacidad de un servicio para soportar las internacionalizacin variaciones internacionales en la lgica empresarial y la representacin de datos (como conjunto de caracteres). Caractersticas de La capacidad del servicio para interactuar con interoperabilidad diferentes entornos tcnicos, dentro y fuera de la organizacin. Caractersticas de Capacidad del servicio para aumentar o reducir su escalabilidad rendimiento o capacidad adecuada a las exigencias del entorno en el que opera. Portabilidad caractersticas De datos, personas, aplicaciones y componentes. Caractersticas de Capacidad para aceptar la nueva funcionalidad. extensibilidad Caractersticas de Capacidad contratada del proveedor de servicios para capacidad atender las solicitudes. Rendimiento Capacidad de produccin requerida. Perodo de rendimiento El periodo de tiempo necesario para entregar la capacidad de rendimiento. Crecimiento Tasa de crecimiento futuro esperado de solicitud de servicio. Perodo de crecimiento El periodo de tiempo necesario para alcanzar la tasa de crecimiento esperada. Perfil pico a corto plazo Perfil de corto plazo del trfico de las horas pico. Perfil pico largo plazo Perfil a largo plazo del trfico de las horas pico. Categora Las siguientes categoras de entidad de datos se aplican: Mensaje, internamente almacenados Entidad.
Pgina369de670

TOGOF9.1
Clasificacin de Privacidad Nivel de restriccin puesta sobre el acceso a los datos. Clasificacin de Retencin Duracin de la retencin que se colocar en los datos. Lgica de datos Clase de Normas No estndar, de Norma, Norma Provisional, Standard, de componentes phasing-out estndar, Jubilado estndar. Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Datos fsicos Clase de Normas No estndar, de Norma, Norma Provisional, Standard, de componentes phasing-out estndar, Jubilado estndar. Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Lgico Clase de Normas No estndar, de Norma, Norma Provisional, Standard, Tecnologa phasing-out estndar, Jubilado estndar. Componente Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Categora Componentes tecnolgicos lgicos se clasifican de acuerdo a la TOGAF TRM, que podr ampliarse para satisfacer las necesidades de una organizacin individual. Tecnologa Clase de Normas No estndar, de Norma, Norma Provisional, Standard, Fsica phasing-out estndar, Jubilado estndar. Componente Fecha de creacin del Si el producto es un estndar, cuando se cre la estndar norma. ltima fecha de revisin ltima fecha en que la norma fue revisada. estndar La prxima fecha de La prxima fecha para que la norma sea revisada. revisin estndar Fecha de jubilarse Fecha en la que la norma se ser retirado /. Categora Componentes tecnolgicos fsicas se clasifican de acuerdo con el TOGAF TRM, que podr ampliarse para satisfacer las necesidades de una organizacin individual. Nombre del producto Nombre del producto que constituyen el componente de tecnologa. Nombre del mdulo Mdulo u otro sub-producto, el nombre que constituyen el componente de tecnologa. Vendedor Vendor proporcionar el componente de tecnologa. Versin Versin del producto que constituyen el componente de tecnologa.
Pgina370de670

TOGOF9.1
Plataforma de Servicios Clase de Normas Categora No estndar, de Norma, Norma Provisional, Standard, phasing-out estndar, Jubilado estndar. Servicios de la Plataforma se clasifican de acuerdo con el TOGAF TRM, que podr ampliarse para satisfacer las necesidades de una organizacin individual. No estndar, de Norma, Norma Provisional, Standard, phasing-out estndar, Jubilado estndar. Las siguientes categoras de paquete de trabajo se aplican: Paquete de Trabajo, Arroyo trabajo, proyecto, programa, Portfolio . Describe la contribucin de este paquete de trabajo hace a la entrega de capacidades.
Componente Tecnologa Paquete de Trabajo
Clase de Normas Categora
Capacidad de entrega
34.7 Metamodel Relaciones

Entidad Fuente Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Capacidad Contrato Contrato Control Entity Data Entity Data Entity Data Entity Data Entity Data Conductor Conductor Conductor Evento Evento Evento Evento Evento Funcin Funcin Funcin Funcin Entidad Target Evento Evento Funcin Funcin Ubicacin Unidad de Organizacin Proceso Papel Servicio Actor Entity Data Paquete de Trabajo Servicio Calidad de Servicio Proceso Lgico Aplicacin Componente Lgica de datos de componentes Servicio Entity Data Entity Data Meta Unidad de Organizacin Conductor Actor Actor Proceso Proceso Servicio Actor Actor Unidad de Organizacin Proceso Mdulo de extensin Genera Proceso Resuelve Proceso Interacta con Ncleo Realiza Ncleo Opera en Infraestructura Consolidacin Pertenece a Ncleo Participa en Ncleo Realiza tareas en Ncleo Consume Ncleo Se descompone Ncleo Suministros / Consume Ncleo Se entrega por Ncleo Gobierna y Medidas Gobernancia Cumple Gobernancia Asegura el correcto funcionamiento de Proceso los Es procesado por Ncleo Reside en Se accede y actualizada a travs de Se descompone Se relaciona con Crea Motiva Se descompone RESUELVE Es generado por RESUELVE Es generado por RESUELVE Apoyos Se realiza por Es propiedad de Apoyos Datos Ncleo Ncleo Ncleo Motivacin Motivacin Motivacin Proceso Proceso Proceso Proceso Proceso Ncleo Ncleo Ncleo Ncleo Nombre
Pgina371de670

TOGOF9.1
Funcin Funcin Funcin Funcin Funcin Meta Meta Meta Ubicacin Ubicacin Ubicacin Ubicacin Ubicacin Ubicacin Lgico Aplicacin Componente Lgico Aplicacin Componente Lgico Aplicacin Componente Lgico Aplicacin Componente Lgico Aplicacin Componente Lgica de datos de componentes Lgica de datos de componentes Lgico Tecnologa Componente Lgico Tecnologa Componente Lgico Tecnologa Componente Lgico Tecnologa Componente Lgico Tecnologa Componente Medida Medida Medida Objetivo Objetivo Objetivo Unidad de Organizacin Unidad de Organizacin Proceso Papel Servicio Funcin Funcin Conductor Objetivo Meta Actor Unidad de Organizacin Fsica Aplicacin de componentes Componente Fsico de Datos Tecnologa Fsica Componente Ubicacin Entity Data Fsica Aplicacin de componentes Servicio Lgico Aplicacin Componente Lgico Aplicacin Componente Entity Data Componente Fsico de Datos Tecnologa Fsica Componente Plataforma de Servicios Servicio Lgico Tecnologa Componente Lgico Tecnologa Componente Objetivo Servicio Medida Meta Medida Objetivo Actor Conductor Se realiza por Se puede acceder por Est delimitada por Se descompone Se comunica con Direcciones Se realiza a travs Se descompone Contiene Contiene Contiene Contiene Contiene Se descompone Funciona con Est extendida por Implementos Se descompone Se comunica con Encapsula Est extendida por Est extendida por Suministros Proporciona plataforma para Se descompone Depende Establece criterios de desempeo para Establece criterios de desempeo para Se descompone Se da cuenta de Se realiza un seguimiento en contra Se descompone Contiene Est motivada por Ncleo Ncleo Ncleo Ncleo Ncleo Motivacin Motivacin Motivacin Infraestructura Consolidacin Infraestructura Consolidacin Infraestructura Consolidacin Infraestructura Consolidacin Infraestructura Consolidacin Infraestructura Consolidacin Ncleo Infraestructura Consolidacin Ncleo Ncleo Ncleo Datos Datos Infraestructura Consolidacin Ncleo Ncleo Ncleo Ncleo Gobernancia Gobernancia Gobernancia Motivacin Gobernancia Motivacin Ncleo Ncleo
Pgina372de670

TOGOF9.1
Unidad de Organizacin Unidad de Organizacin Unidad de Organizacin Unidad de Organizacin Unidad de Organizacin Fsica Aplicacin de componentes Fsica Aplicacin de componentes Fsica Aplicacin de componentes Fsica Aplicacin de componentes Fsica Aplicacin de componentes Fsica Aplicacin de componentes Datos fsicos de componentes Datos fsicos de componentes Datos fsicos de componentes Datos fsicos de componentes Tecnologa Fsica Componente Tecnologa Fsica Componente Tecnologa Fsica Componente Tecnologa Fsica Componente Tecnologa Fsica Componente Plataforma de Servicios Proceso Proceso Proceso Proceso Proceso Proceso Proceso Proceso Proceso Proceso Proceso Producto Producto Papel Funcin Ubicacin Producto Servicio Unidad de Organizacin Ubicacin Lgico Aplicacin Componente Datos fsicos de componentes Tecnologa Fsica Componente Fsica Aplicacin de componentes Fsica Aplicacin de componentes Ubicacin Lgica de datos de componentes Datos fsicos de componentes Fsica Aplicacin de componentes Ubicacin Fsica Aplicacin de componentes Lgico Tecnologa Componente Tecnologa Fsica Componente Tecnologa Fsica Componente Lgico Tecnologa Componente Actor Control Evento Evento Funcin Funcin Producto Servicio Servicio Proceso Proceso Unidad de Organizacin Proceso Actor Posee Opera en Produce Posee y gobierna Se descompone Est alojado en Extiende Encapsula Se realiza por Se descompone Se comunica con Est alojado en Extiende Se descompone Encapsula Est alojado en Se da cuenta de Extiende Se descompone Depende Se suministra por Involucra Se gua por Genera Resuelve Orquesta Se descompone Produce Orquesta Se descompone Se descompone Precede / Follows Es producido por Es producido por Se realiza por Ncleo Ncleo Ncleo Ncleo Ncleo Infraestructura Consolidacin Infraestructura Consolidacin Modelado de Datos Ncleo Ncleo Ncleo Infraestructura Consolidacin Datos Ncleo Modelado de Datos Consolidacin de Infraestructura Ncleo Infraestructura Consolidacin Ncleo Ncleo Ncleo Ncleo Proceso Proceso Proceso Ncleo Ncleo Proceso Ncleo Ncleo Ncleo Ncleo Proceso Proceso Ncleo
Pgina373de670

TOGOF9.1
Papel Papel Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Calidad de Servicio Calidad de Servicio Paquete de Trabajo Funcin Papel Actor Contrato Entity Data Entity Data Evento Funcin Lgico Aplicacin Componente Lgico Tecnologa Componente Medida Unidad de Organizacin Proceso Proceso Calidad de Servicio Servicio Servicio Contrato Servicio Capacidad Accesos Se descompone Se proporciona a Se rige y se mide por Proporciona Consume Resuelve Proporciona una interfaz gobernado al acceso Se realiza a travs Se implementa en Se realiza un seguimiento en contra Es propiedad y est regulado por la Apoyos Se realiza por Cumple Consume Se descompone Se aplica a los Se aplica a los Entrega Ncleo Ncleo Ncleo Gobernancia Ncleo Ncleo Proceso Ncleo Ncleo Ncleo Gobernancia Ncleo Ncleo Ncleo Gobernancia Ncleo Ncleo Gobernancia Gobernancia Ncleo
Pgina374de670

TOGOF9.1
35. Architectural Artifacts

Este captulo trata de los conceptos que rodean arquitectura artefactos y luego describe los artefactos que se recomiendan que se crear para cada fase en el Mtodo de Desarrollo de Arquitectura (ADM). Tambin se presenta una gua para el desarrollo de un conjunto de puntos de vista, algunos o todos de los cuales pueden ser apropiadas en un desarrollo de la arquitectura en particular.
35.1 Conceptos bsicos

Artefactos arquitectnicos se crean con el fin de describir un sistema, solucin, o el estado de la empresa. Los conceptos tratados en esta seccin han sido adaptados de las definiciones ms formales contenidos en la norma ISO / IEC 42010:2007 e ilustrados en la Figura 35-1 . Nota: La notacin utilizada es del Lenguaje Unificado de Modelado (UML) especificacin.
Figura351:Conceptosbsicosdelaarquitectura
Un "sistema" es una coleccin de componentes organizados para llevar a cabo una funcin o conjunto de funciones especficas.
Pgina375de670

TOGOF9.1
La "arquitectura" de un sistema es la organizacin fundamental del sistema, encarnada en sus componentes, sus relaciones entre s y con el medio ambiente, y los principios que guan su diseo y evolucin. Una "descripcin de la arquitectura" es una coleccin de artefactos que documentan una arquitectura . En TOGAF, vistas de arquitectura son los artefactos claves en una descripcin de la arquitectura. "Las partes interesadas" son personas que tienen un papel clave en, o preocupaciones sobre el sistema; por ejemplo, como usuarios, desarrolladores o administradores.Diferentes actores con diferentes roles en el sistema tendrn diferentes inquietudes. Las partes interesadas pueden ser individuos, grupos u organizaciones (o clases de los mismos). "La preocupacin" son los intereses dominantes que son de crucial importancia para las partes interesadas en el sistema, y determinar la aceptabilidad del sistema. Las preocupaciones pueden referirse a cualquier aspecto de funcionamiento del sistema, el desarrollo o la operacin, incluyendo consideraciones tales como el rendimiento, la fiabilidad, la seguridad, la distribucin y capacidad de evolucin. Una "vista" es una representacin de todo un sistema desde la perspectiva de un conjunto relacionado de preocupaciones. Al capturar o representar el diseo de un sistema de arquitectura, el arquitecto normalmente crear uno o ms modelos de arquitectura, posiblemente utilizando diferentes herramientas. Una vista comprender partes seleccionadas de uno o ms modelos, elegidos con el fin de demostrar a un actor o grupo de actores que sus preocupaciones estn siendo abordadas adecuadamente en el diseo de la arquitectura del sistema. Un "punto de vista", define la perspectiva desde la cual se toma una vista. Ms especficamente, un punto de vista define: cmo construir y utilizar un punto de vista (por medio de un esquema o plantilla adecuada); la informacin que debe aparecer en la vista; las tcnicas de modelado para expresar y analizar la informacin; y una justificacin de estas decisiones (por ejemplo, describiendo el propsito y destinatario de la vista). Un punto de vista es lo que ves. Un punto de vista es donde se busca desde - el punto de vista o perspectiva que determina lo que ves. Puntos de vista son genricos, y pueden ser almacenados en las bibliotecas para la reutilizacin. Un punto de vista es siempre especfica a la arquitectura para la que se cre. Cada posicin tiene un punto de vista asociada que describe, al menos implcitamente. ISO / IEC 42010:2007 anima a los arquitectos para definir los puntos de vista de forma explcita. Hacer esta distincin entre el contenido y el esquema de una vista puede parecer a primera vista una sobrecarga innecesaria, sino que proporciona un mecanismo para que los puntos de vista reutilizar en diferentes arquitecturas.
En resumen, pues, vistas de arquitectura son representaciones de la arquitectura global en trminos significativos para las partes interesadas. Permiten a la arquitectura que se comunicar a y entendido por las partes interesadas, para que puedan verificar que el sistema se ocupar de sus preocupaciones.
Pgina376de670

TOGOF9.1
Nota: Los trminos "preocupacin" y "requisito" no son sinnimos. Una preocupacin es un rea de inters. Por lo tanto, la fiabilidad del sistema podra ser una preocupacin / rea de inters para algunos interesados. La razn por la que los arquitectos deberan identificar las preocupaciones y asociarlos con los puntos de vista, es garantizar que esas preocupaciones sern abordadas de alguna manera por los modelos de la arquitectura. Por ejemplo, si el nico punto de vista seleccionado por un arquitecto es un punto de vista estructural, a continuacin, problemas de fiabilidad es casi seguro que no se abordan, ya que no pueden ser representados en un modelo estructural. Dentro de esa preocupacin, los interesados pueden tener muchas necesidades distintas: diferentes clases de usuarios pueden tener diferentes requisitos de fiabilidad para las diferentes capacidades del sistema. Las preocupaciones son la raz del proceso de descomposicin en los requisitos. Las preocupaciones estn representados en la arquitectura de estos requisitos.Los requisitos deben ser SMART (por ejemplo, las mtricas especficas).
35.1.1 Ejemplo simple de un Mirador y Vista

Para muchas arquitecturas , un punto de vista til es la de los dominios de negocio, que se puede ilustrar con un ejemplo tomado de The Open Group en s. El punto de vista se especifica de la siguiente manera:
Elemento Viewpoint Las partes interesadas Preocupaciones Tcnica de modelado Descripcin Consejo de Administracin, Director General Mostrar las relaciones de alto nivel entre los sitios geogrficos y funciones de negocios. Anidado diagrama de cajas. cajas exterior = lugares; cajas internas = funciones de negocios. Semntica de anidacin = funciones realizadas en las localidades.
La vista correspondiente de The Open Group (en 2008) se muestra en la Figura 35-2 .
Pgina377de670

TOGOF9.1
Figura352:EjemploViewTheOpenGroupNegocioDominiosen2008
35.2 Vistas desarrollo en el ADM

35.2.1 Directrices Generales
La eleccin de qu puntos de vista particulares de arquitectura para desarrollar es una de las decisiones clave que el arquitecto tiene que hacer. El arquitecto tiene la responsabilidad de asegurar la integridad (aptitud para el propsito) de la arquitectura, en trminos de abordar adecuadamente todos los intereses pertinentes de las partes interesadas; y la integridad de la arquitectura, en cuanto a la conexin de todos los diferentes puntos de vista de la otra, la conciliacin de forma satisfactoria las preocupaciones conflictivas de los diferentes grupos de inters, y que muestra las compensaciones hechas en hacerlo (como entre la seguridad y el rendimiento, por ejemplo). La eleccin tiene que ser limitada por consideraciones de orden prctico, y por el principio de la aptitud para el propsito (es decir, la arquitectura debe ser desarrollado slo hasta el punto en el que es apto para el propsito, y no reiter el infinito como un ejercicio acadmico). Como se explica en la Parte II: Arquitectura Mtodo de Desarrollo (ADM) , el desarrollo de puntos de vista de arquitectura es un proceso iterativo. La progresin tpica es de negocio a la tecnologa, el uso de una tcnica como escenarios de negocios (vase la Parte III , 26. Escenarios empresariales y objetivos de la empresa ) para identificar correctamente todas las preocupaciones pertinentes; y de introduccin de alto nivel a los detalles de bajo nivel, refirindose continuamente de nuevo a las preocupaciones y necesidades de las partes interesadas en todo el proceso.
Pgina378de670

TOGOF9.1
Por otra parte, cada una de estas progresiones tiene que ser hecho por dos ambientes distintos: el entorno existente (conocida como la lnea de base en el ADM) y el entorno de destino. El arquitecto debe desarrollar puntos de vista pertinentes de arquitectura, tanto de la arquitectura de lnea de base y la arquitectura destino. Esto proporciona el contexto para el anlisis de las deficiencias en el final de las fases B, C y D de la ADM, que establece los elementos de la arquitectura de referencia que deban traspasarse y los elementos que pueden aadir, eliminar o sustituir. Todo este proceso se explica en la Parte III , 27. Anlisis Gap .
35.2.2 Ver Proceso de Creacin

Como se mencion anteriormente, en el momento actual TOGAF alienta pero no obliga a la utilizacin de la norma ISO / IEC 42010:2007. Por tanto, la siguiente descripcin se refiere tanto a la situacin en la ISO / IEC 42010:2007 ha sido adoptado y en las que no tiene. ISO / IEC 42010:2007 en s no requiere ningn proceso especfico para el desarrollo de puntos de vista o la creacin de puntos de vista de ellos. Cuando la norma ISO / IEC 42010:2007 ha sido adoptado y convertido en una prctica bien establecida dentro de una organizacin, a menudo ser posible crear los puntos de vista necesarios para una arquitectura particular, siguiendo estos pasos:
1. Consulte una biblioteca existente de puntos de vista 2. Seleccione los puntos de vista apropiados (basados en los grupos de inters y preocupaciones que deben ser cubiertos por los puntos de vista) 3. Generar vistas del sistema mediante el uso de los puntos de vista seleccionados como plantillas
Este enfoque se puede esperar para llevar a los siguientes beneficios: Menos trabajo para los arquitectos (debido a que los puntos de vista ya se han definido, por lo que las vistas se pueden crear ms rpido) Una mejor comprensin de las partes interesadas (debido a que los puntos de vista ya estn familiarizados) Mayor confianza en la validez de los puntos de vista (debido a que sus puntos de vista tienen una trayectoria conocida)
Sin embargo, las situaciones siempre pueden surgir en los que se necesita una vista para la que ningn punto de vista adecuado ha predefinido. Esta es tambin la situacin, por supuesto, cuando una organizacin an no ha incorporado la norma ISO / IEC 42010:2007 en su prctica de la arquitectura y establecido una biblioteca de puntos de vista. En cada caso, el arquitecto puede elegir para desarrollar un nuevo punto de vista que cubrir la necesidad excepcional y, a continuacin, generar una vista de ella. (Esta es la norma ISO / IEC 42010:2007 prctica recomendada.) Por otra parte, un enfoque ms pragmtico puede ser igualmente exitosa: el arquitecto puede crear un especialpunto de vista de un sistema especfico y luego considerar si una forma generalizada de la perspectiva implcita debera definirse
Pgina379de670

TOGOF9.1
explcitamente y guardado en una biblioteca, de modo que pueda ser reutilizado. (Esta es una manera de establecer una biblioteca de puntos de vista inicialmente.) Sea cual sea el contexto, el arquitecto debe ser consciente de que cada punto de vista tiene un punto de vista, al menos implcitamente, y que define el punto de vista de una manera sistemtica (segn lo recomendado por la norma ISO / IEC 42010:2007) ayudar en la evaluacin de su eficacia; es decir, cubre el punto de vista de las preocupaciones de las partes interesadas pertinentes?.
35.3 Vistas, Herramientas y lenguajes

La necesidad de puntos de vista de arquitectura, y el proceso de desarrollo de ellos despus de la ADM, se explicaron anteriormente. Esta seccin describe las relaciones entre puntos de vista de arquitectura, las herramientas utilizadas para desarrollar y analizarlos, y una que permite la interoperabilidad entre lenguajes estndar entre las herramientas.
35.3.1 Informacin general

Con el fin de alcanzar los objetivos de la integridad y la integridad en una arquitectura , vistas de arquitectura suelen ser desarrollados, visualizar, comunican y gestionan mediante una herramienta. En el estado actual del mercado, diferentes herramientas normalmente tienen que ser utilizados para desarrollar y analizar diferentes puntos de vista de la arquitectura. Es altamente deseable que una descripcin de la arquitectura se codifica en un lenguaje estndar, para permitir un enfoque estndar para la descripcin de la arquitectura semntica y su reutilizacin entre distintas herramientas. Un punto de vista tambin se desarroll normalmente, visualizar, comunicar y administrar mediante una herramienta, y tambin es muy deseable que se desarrollen puntos de vista estndar (por ejemplo, plantillas o esquemas), de modo que las diferentes herramientas que se ocupan en los mismos puntos de vista pueden interoperar, la elementos fundamentales de una arquitectura pueden ser reutilizados, y la descripcin de la arquitectura pueden ser compartidas entre las herramientas. Las cuestiones relativas a la evaluacin de las herramientas para el trabajo de la arquitectura se discuten en detalle en la Parte V , 42. Herramientas para el desarrollo de la arquitectura .
35.4 Puntos de vista y Puntos de Vista

35.4.1 Ejemplo de Tendencias y Puntos de Vista
Para ilustrar los conceptos de opiniones y puntos de vista, considere el ejemplo de un sistema aeroportuario muy simple con dos partes diferentes: el piloto y el controlador de trnsito areo. Un punto de vista se puede desarrollar desde el punto de vista del piloto, que se ocupa de las preocupaciones del piloto. Igualmente, otro punto de vista se puede desarrollar desde el punto de vista del controlador de trnsito areo. Ni vista describe completamente el sistema en su totalidad, porque el punto de vista de cada una de las partes interesadas restricciones (y reduce) cmo cada uno ve el sistema global.
Pgina380de670

TOGOF9.1
El punto de vista del piloto comprende algunas preocupaciones que no son relevantes para el controlador, como pasajeros y combustible, mientras que el punto de vista del controlador comprende algunas preocupaciones que no son pertinentes para el piloto, como otros aviones. Tambin hay elementos comunes entre los dos puntos de vista, tales como el modelo de comunicacin entre el piloto y el controlador, y la informacin vital sobre el avin en s. Un punto de vista es un modelo (o descripcin) de la informacin contenida en una vista. En nuestro ejemplo, un punto de vista es la descripcin de cmo el piloto ve el sistema, y el otro punto de vista es cmo el controlador ve el sistema. Pilotos describen el sistema desde su perspectiva, utilizando un modelo de su posicin y el vector hacia o lejos de la pista de aterrizaje. Todos los pilotos utilizar este modelo, y el modelo tiene un lenguaje especfico que se utiliza para capturar la informacin y rellenar el modelo. Controladores describen el sistema de forma diferente, utilizando un modelo del espacio areo y los lugares y vectores de aeronave dentro del espacio areo. Una vez ms, todos los controladores utilizan un lenguaje comn derivada del modelo comn con el fin de capturar y comunicar la informacin pertinente a su punto de vista. Afortunadamente, cuando los controladores de hablar con los pilotos, que utilizan un lenguaje comn de comunicacin. (En otras palabras, los modelos que representan sus puntos de vista individuales se cruzan parcialmente.) Parte de este lenguaje comn es acerca de la ubicacin y vectores de aeronaves, y es esencial para la seguridad. As que, en esencia, cada punto de vista es un modelo abstracto de cmo todas las partes interesadas de un tipo particular - todos los pilotos, o todos los controladores - Ver el sistema aeroportuario. Existen herramientas para ayudar a las partes interesadas, sobre todo cuando estn interactuando con los modelos complejos, como el modelo de un espacio areo , o el modelo de vuelo del aire. La interfaz para el usuario humano de una herramienta es tpicamente cerca de la del modelo y de idioma asociado con el punto de vista. Las herramientas nicas de la prueba piloto son el combustible, la altitud, la velocidad y los indicadores de lugar. La herramienta principal del controlador es el radar. La herramienta comn es una radio. Para resumir el ejemplo anterior, podemos ver que una vista puede subconjunto del sistema a travs de la perspectiva de la parte interesada, como el piloto contra el controlador. Este subconjunto puede ser descrito por un modelo abstracto llamado un punto de vista, tal como un vuelo de aire en comparacin con un modelo de espacio de aire. Esta descripcin de la vista se documenta en un idioma parcialmente especializada, como "piloto-speak" frente "controladorspeak". Las herramientas son usadas para ayudar a las partes interesadas, y que interactan entre s en cuanto a la lengua derivada del punto de vista ("piloto-speak" versus " "controladorspeak"). Cuando los actores usan herramientas comunes, como el contacto de radio entre piloto y controlador, un idioma comn es esencial.
Pgina381de670

TOGOF9.1
35.4.2 Vistas y puntos de vista en la arquitectura empresarial
Ahora vamos a mapear este ejemplo para la arquitectura empresarial. Consideremos dos partes interesadas en un nuevo sistema informtico pequeo: los usuarios y los desarrolladores. Los usuarios del sistema tienen un punto de vista que refleja sus inquietudes al interactuar con el sistema, y los desarrolladores del sistema de tener un punto de vista diferente. Visto que se desarrollan para tratar cualquiera de los dos puntos de vista son poco probable para describir exhaustivamente todo el sistema, porque cada perspectiva reduce cmo cada uno ve el sistema. El punto de vista del usuario se compone de todas las formas en que el usuario interacta con el sistema, no ver ningn detalle, como aplicaciones o sistemas de gestin de bases de datos (DBMS). El punto de vista del desarrollador es uno de productividad y herramientas, y no incluye cosas tales como los datos reales en vivo y las conexiones con los consumidores. Sin embargo, hay cosas que se comparten, tales como descripciones de los procesos que estn habilitados por el sistema y / o protocolos de comunicacin establecido para que los usuarios comuniquen directamente los problemas del desarrollo. En este ejemplo, un punto de vista es la descripcin de cmo el usuario ve el sistema, y el otro punto de vista es cmo el desarrollador ve el sistema. Los usuarios describen el sistema desde su perspectiva, utilizando un modelo de disponibilidad, tiempo de respuesta, y el acceso a la informacin. Todos los usuarios del sistema de utilizar este modelo, y el modelo tiene un lenguaje especfico. Desarrolladores describir el sistema de manera diferente que los usuarios, usando un modelo de software conectado al hardware distribuido sobre una red, etc Sin embargo, hay muchos tipos de desarrolladores (base de datos, seguridad, etc) del sistema, y no tienen un comn idioma derivada del modelo.
35.4.3 necesidad de un lenguaje comn y herramientas interoperables para Arquitectura Descripcin

Existen herramientas para los usuarios y desarrolladores. Herramientas tales como la ayuda en lnea estn all especficamente para los usuarios, y tratan de utilizar el idioma del usuario. Existen muchas herramientas diferentes para diferentes tipos de desarrolladores, pero adolecen de la falta de un lenguaje comn que se requiere para que el sistema en conjunto. Es difcil, si no imposible, en el estado actual del mercado de herramientas para tener una herramienta de interoperar con otra herramienta. Las cuestiones relativas a la evaluacin de las herramientas para el trabajo de la arquitectura se discuten en detalle en la Parte V , 42. Herramientas para el desarrollo de la arquitectura .
35.5 Conclusiones
Esta seccin se trata de hacer frente a puntos de vista en forma estructurada, pero esto de ninguna manera es un tratado completo de puntos de vista.
Pgina382de670

TOGOF9.1
. En general, TOGAF abarca los conceptos y definiciones que se presentan en la norma ISO / IEC 42010:2007, especficamente los conceptos que ayudan a guiar el desarrollo de una visin y hacer que la visin accionable Estos conceptos se pueden resumir en: Seleccin de una de las partes interesadas clave Entender sus preocupaciones y generalizando / documentar esas preocupaciones Entender cmo modelar y hacer frente a esas preocupaciones
35.6 Architectural Artifacts por ADM Fase

La Figura 35-3 muestra los artefactos que estn asociados con el metamodelo contenido de ncleo y cada una de las extensiones de contenido.
Figura353:artefactosasociadosconelmetamodeloyExtensionesCore
Las clases especficas de artefacto son los siguientes: Catlogos son listas de bloques de construccin. Matrices muestran las relaciones entre los componentes bsicos de los tipos especficos. Diagramas actuales bloques de construccin, adems de sus relaciones e interconexiones de un modo grfico que soporta la comunicacin efectiva de los interesados.
Los artefactos recomendadas para la produccin en cada fase de ADM son los siguientes.
Pgina383de670

TOGOF9.1
35.6.1 Fase Preliminar
A continuacin se describen los catlogos, matrices y diagramas que se pueden crear dentro de la Etapa Preliminar, como se indica en la Parte II , 6.5 Salidas .
Principios Catlogo
El catlogo Principios capta principios de los principios de negocio y la arquitectura que describen lo que una solucin o arquitectura "buena" debe ser similar. Principios se utilizan para evaluar y acordar un resultado para los puntos de decisin arquitectura. Principios tambin se utilizan como una herramienta para ayudar en la gestin de arquitectura de las iniciativas de cambio. El catlogo Principios contiene las siguientes entidades metamodelo: Principio
35.6.2 Fase A: Architecture Vision

A continuacin se describen los catlogos, matrices y diagramas que se pueden crear dentro de la Fase A (Architecture Vision) que se enumeran en 7.5 Salidas .
Stakeholder Mapa Matrix
El propsito de la matriz de los interesados mapa es identificar los grupos de inters para la contratacin arquitectura, su influencia sobre el compromiso, y sus preguntas clave, temas o preocupaciones que deben ser abordados en el marco de la arquitectura. Entender las partes interesadas y sus necesidades permite a un arquitecto para enfocar los esfuerzos en las reas que satisfagan las necesidades de los interesados (vase la Parte III , 24. Gestin de los grupos de inters ). Debido a la naturaleza potencialmente confidencial de la informacin de mapeo de los interesados y el hecho de que la fase Architecture Vision est destinado a ser llevado a cabo utilizando tcnicas de modelado informales, no hay entidades metamodelo especficos se utilizan para generar un mapa de las partes interesadas.
Diagrama de la Cadena de Valor
Un diagrama de la cadena de valor ofrece una vista de orientacin de alto nivel de una empresa y cmo interacta con el mundo exterior. En contraste con el diagrama de descomposicin funcional ms formal desarrollado en la Fase B (Business Architecture), el diagrama de la cadena de valor se centra en el impacto de presentacin. El propsito de este diagrama es rpidamente a bordo y alinear las partes interesadas de una iniciativa particular el cambio, de modo que todos los participantes entiendan el contexto funcional y organizativa de alto nivel de la participacin de la arquitectura.
Pgina384de670

TOGOF9.1
Solucin Concepto Diagrama
Un diagrama Solution Concept ofrece una orientacin de alto nivel de la solucin que se prev el fin de cumplir los objetivos de la participacin de la arquitectura. En contraste con los esquemas ms formales y detalladas de arquitectura desarrollado en las siguientes fases, el concepto de solucin representa un "dibujo a lpiz" de la solucin esperada al inicio del contrato. Este diagrama puede incorporar objetivos clave, requisitos y restricciones para la participacin y tambin poner de relieve las reas de trabajo para ser investigado con ms detalle con el modelado de la arquitectura formal. Su propsito es rpidamente a bordo y alinear las partes interesadas de una iniciativa particular el cambio, de modo que todos los participantes entiendan lo que el compromiso de la arquitectura est tratando de lograr y cmo se espera que un enfoque de solucin particular ser satisfacer las necesidades de la empresa.
35.6.3 Fase B: Arquitectura de Negocios

A continuacin se describen los catlogos, matrices y diagramas que se pueden crear dentro de la Fase B (Business Architecture) como se indica en 8.5 Salidas .
Catlogo Organizacin / Actor
El propsito del catlogo Organizacin / Actor es capturar una lista definitiva de todos los participantes que interactan con l, incluidos los usuarios y los propietarios de los sistemas de TI. El catlogo Organizacin / Actor se puede hacer referencia al elaborar los requisitos con el fin de comprobar la integridad. Por ejemplo, los requisitos para una aplicacin que da servicio a los clientes se pueden probar por la totalidad mediante la verificacin de exactamente qu tipos de clientes necesitan ser apoyados y si existen requisitos o restricciones particulares para tipos de usuario. El / catalog Actor Organizacin contiene las siguientes entidades metamodelo: Unidad de Organizacin Actor Ubicacin (puede incluirse en este catlogo, si un catlogo independiente de la ubicacin no se mantiene)
Conductor / Meta / Objetivo Catlogo
El propsito del Conductor / Meta / Objetivo catlogo es ofrecer una referencia de toda la Organizacin de cmo una organizacin responde a sus pilotos en la prctica a travs de metas, objetivos, y (opcionalmente) las medidas. La publicacin de una ruptura definitiva de los conductores, las metas y objetivos permite que las iniciativas de cambio dentro de la empresa para identificar las sinergias en toda la organizacin
Pgina385de670

TOGOF9.1
(por ejemplo, mltiples organizaciones que intentan lograr objetivos similares), que a su vez permiten a las partes interesadas para identificar e iniciativas de cambio vinculadas a alinear o consolidados. El Conductor / Meta / Objetivo catlogo contiene las siguientes entidades metamodelo: Unidad de Organizacin Conductor Meta Objetivo Medida (pueden estar opcionalmente incluido)
Catlogo de funciones
El propsito del catlogo de papel es el de proporcionar una lista de todos los niveles de autorizacin o zonas dentro de una empresa. Con frecuencia, la seguridad de aplicaciones o el comportamiento se define en contra de los conceptos entendidos a nivel local de la autorizacin que crean consecuencias complejas e inesperadas cuando se combina en el escritorio del usuario. Si se definen los roles, entendidos, y alineados en todas las organizaciones y aplicaciones, lo que permite una experiencia de usuario ms fluida y aplicaciones en general, ms seguras, ya que los administradores no tengan que recurrir a soluciones alternativas con el fin de permitir a los usuarios para llevar a cabo su trabajo. Adems de apoyar la definicin de seguridad para la empresa, el catlogo de funciones tambin forma un insumo clave para la identificacin de los impactos de la organizacin de gestin del cambio, la definicin de las funciones de trabajo, y la ejecucin de la capacitacin del usuario final. Como cada rol implica el acceso a una serie de funciones de la empresa, si alguna de estas funciones de la empresa se ven afectados, a continuacin, cambiar ser necesario el manejo, es posible que las responsabilidades organizativas que redefinirse, y puede ser necesaria la reconversin. El catlogo contiene las siguientes clases, entidades metamodelo: Papel
Business Service / Funcin catlogo
El propsito de el catlogo de servicios de negocios / funcin es la de proporcionar una descomposicin funcional en una forma que se puede filtrar, inform sobre, y pregunt, como un suplemento a los diagramas de descomposicin funcional grficas. El catlogo de servicios de negocios / La funcin puede utilizarse para identificar las capacidades de una organizacin y para comprender el nivel de gobierno que se aplica a las funciones de una organizacin. Esta descomposicin funcional se puede utilizar para identificar nuevas capacidades
Pgina386de670

TOGOF9.1
requeridas para apoyar el cambio de negocios o se puede usar para determinar el alcance de las iniciativas de cambio, aplicaciones o componentes de la tecnologa. El catlogo de servicios de negocios / Funcin contiene las siguientes entidades metamodelo: Unidad de Organizacin Funcin comercial Servicios de Negocio Informacin de servicio del sistema (opcionalmente puede incluirse aqu)
Ubicacin catlogo
El catlogo Ubicacin proporciona un listado de todos los lugares en los que la empresa lleva a cabo operaciones de negocios o casas de activos arquitectnicamente relevantes, tales como los centros de datos o equipos de computacin de usuario final. El mantenimiento de una lista definitiva de los lugares permite iniciativas de cambio para definir rpidamente un alcance ubicacin y para la prueba de integridad en la evaluacin de los paisajes actuales o soluciones destinatarios propuestos. Por ejemplo, un proyecto para actualizar los sistemas operativos de escritorio deber identificar todas las ubicaciones donde se utilizan los sistemas operativos de escritorio. Del mismo modo, cuando se estn implementando nuevos sistemas, un diagrama de las ubicaciones es esencial con el fin de desarrollar estrategias de implementacin adecuadas que comprenden tanto al usuario como ubicacin de la aplicacin e identificar los problemas relacionados con la ubicacin, como la internacionalizacin, localizacin, los impactos sobre los impactos de zona horaria de disponibilidad, distancia en latencia, los impactos de la red de ancho de banda, y el acceso. El catlogo contiene Ubicacin las siguientes entidades metamodelo: Ubicacin
Proceso / Evento / Control / Catlogo de Productos
El proceso / evento / Control / Catlogo de productos proporciona una jerarqua de procesos, eventos que desencadenan los procesos, los productos procedentes de los procesos y controles que se aplican a la ejecucin de los procesos. Este catlogo ofrece un complemento a cualquier diagrama de flujo de proceso que se crean y permite a una empresa que va a filtrar, informe y consulta a travs de las organizaciones y procesos para identificar el alcance, en comn, o impacto. Por ejemplo, el proceso / evento / Control / Catlogo de productos permite a una empresa para ver las relaciones de los procesos a los sub-procesos con el fin de identificar la cadena de impactos resultantes de cambiar un proceso de alto nivel. El proceso / evento / Control / Catlogo de productos incluye las siguientes entidades metamodelo:
Pgina387de670

TOGOF9.1
Proceso Evento Control Producto
Contrato / Medida Catlogo
El catlogo Contract / Medida proporciona un listado de todos los contratos de servicio acordados y (opcionalmente) las medidas adjuntas a esos contratos. Forma la lista maestra de los niveles de servicio acordados para toda la empresa. El Contrato / catalog Medida contiene las siguientes entidades metamodelo: Servicios de Negocio Informacin de servicio del sistema (opcional) Contrato Medida
Matriz de Interaccin de Negocios
El propsito de esta matriz es representar las interacciones de la relacin entre las organizaciones y funciones de negocio en toda la empresa. Comprender la interaccin de negocios de una empresa es importante ya que ayuda a resaltar la cadena de valor y las dependencias en todas las organizaciones. La matriz de interaccin de negocios muestra las siguientes entidades metamodelo y relaciones: Organizacin Funcin comercial Servicios de Negocio Business Service comunica con relaciones de servicios empresariales Servicios de Negocio depende de las relaciones de servicio de negocios
Matrix Actor / Rol
El propsito de esta matriz es mostrar que los actores realizan que los roles, el apoyo a la definicin de los requisitos de seguridad y de cualificaciones.
Pgina388de670

TOGOF9.1
Comprender las relaciones actor-a roles es una herramienta de apoyo clave en la definicin de las necesidades de capacitacin, la configuracin de seguridad del usuario y la gestin del cambio organizacional. La matriz Actor / Rol muestra las siguientes entidades metamodelo y relaciones: Actor Papel Actor realiza relaciones de rol
Negocios Huella Diagrama
Un diagrama de negocios Huella describe los vnculos entre los objetivos de negocio, unidades organizativas, funciones de oficina y servicios, y los mapas de estas funciones a los componentes tcnicos que entregan la capacidad requerida. Un diagrama de negocios Huella proporciona una trazabilidad clara entre un componente tcnico y el objetivo comercial que satisface, a la vez que demuestra la propiedad de los servicios identificados. Un diagrama de negocios Huella demuestra solamente los hechos clave que relacionan funciones de la unidad de organizacin de los servicios de entrega y se utiliza como una plataforma de comunicacin para los de categora superior (CxO) las partes interesadas.
Business Service / Diagrama de Informacin
El diagrama de Servicios de Negocio / Informacin muestra la informacin necesaria para apoyar uno o ms servicios de oficina. El diagrama de Business Service / Information muestra los datos que se consume en o producido por un servicio de negocio y tambin puede mostrar la fuente de informacin. El diagrama de Business Service / Information muestra una representacin inicial de la informacin incorporada dentro de la arquitectura y por lo tanto constituye una base para elaboracin y perfeccionamiento dentro de la fase C (Arquitectura de Datos).
Diagrama de Descomposicin Funcional
El propsito del diagrama de descomposicin funcional es mostrar en una sola pgina de las capacidades de una organizacin que son relevantes para la consideracin deuna arquitectura . Mediante el examen de las capacidades de una organizacin desde una perspectiva funcional, es posible desarrollar rpidamente modelos de lo que hace la organizacin sin ser arrastrado a prolongar el debate sobre cmo la organizacin hace. Una vez que un diagrama bsico de descomposicin funcional se ha desarrollado, se hace posible a la capa de calor-maps en la parte superior de este diagrama para mostrar el alcance y las decisiones. Por ejemplo, la capacidad para ser implementadas en diferentes fases de un programa de cambio.
Pgina389de670

TOGOF9.1
Diagrama del ciclo de vida del producto
El propsito del diagrama del ciclo de vida del producto es ayudar en la comprensin de los ciclos de vida de las entidades clave dentro de la empresa. Entender los ciclos de vida de productos es cada vez ms importante con respecto a las preocupaciones ambientales, la legislacin y la reglamentacin cuando los productos deben ser rastreados desde su fabricacin hasta su eliminacin. Del mismo modo, las organizaciones que crean productos que involucran informacin personal o sensible deben tener un conocimiento detallado de la vida til del producto durante el desarrollo de la arquitectura de negocios con el fin de garantizar el rigor en el diseo de los controles, procesos y procedimientos. Ejemplos de esto incluyen tarjetas de crdito, tarjetas de dbito, tarjetas de la tienda / de fidelidad, tarjetas inteligentes, credenciales de identidad de usuario (documentos de identidad, pasaportes, etc.)
Meta / Objetivo Diagrama / Servicio
El propsito de un diagrama de Meta / Objetivo / Servicio es definir las formas en que un servicio contribuye a la consecucin de una visin o estrategia de negocio. Los servicios se asocian con los controladores, metas, objetivos y medidas que apoyan, lo que permite a la empresa a entender que los servicios contribuyen a aspectos similares de rendimiento empresarial. El diagrama de Meta / Objetivo / servicio tambin proporciona entrada cualitativa sobre lo que constituye un alto rendimiento para un servicio en particular.
Diagrama de negocios de casos de uso
Un diagrama de negocios de caso de uso muestra las relaciones entre consumidores y proveedores de servicios de oficina. Servicios a empresas son consumidos por los actores u otros servicios de negocios y el diagrama de negocios de caso de uso proporciona riqueza agregada al describir la capacidad del negocio mediante la ilustracin de cmo y cundo se utiliza esa capacidad. El propsito del diagrama de casos de uso de negocios es ayudar a describir y validar la interaccin entre los actores y sus roles en los procesos y funciones. Como la arquitectura avanza, el caso de uso puede evolucionar desde el nivel de negocio para incluir datos, aplicaciones, y detalles de tecnologa. Negocio casos de uso de arquitectura tambin se pueden volver a utilizar en los sistemas de trabajo de diseo.
Organizacin Descomposicin Diagrama
Un diagrama de Organizacin Descomposicin describe los vnculos entre actores, roles, y la ubicacin dentro de un rbol de organizacin. Un mapa de la organizacin debe proporcionar una cadena de mando de los propietarios y encargados de tomar decisiones en la organizacin. Aunque no es la intencin de la Organizacin diagrama de descomposicin vincular meta de la organizacin, debera ser posible vincular de forma intuitiva las metas a las partes interesadas en el diagrama de la Organizacin de descomposicin.
Pgina390de670

TOGOF9.1
Diagrama de Flujo de Proceso
El propsito del diagrama de flujo de proceso es representar todos los modelos y las asignaciones relacionadas con la entidad metamodelo proceso. Los diagramas de flujo de procesos muestran el flujo secuencial de control entre las actividades y pueden utilizar las tcnicas de natacin carriles para representar la propiedad y la realizacin de los pasos del proceso. Por ejemplo, la aplicacin que soporta una fase del proceso se puede mostrar como un bao carriles. Adems de mostrar una secuencia de la actividad, flujos de proceso tambin pueden ser utilizados al detalle los controles que se aplican a un proceso, los eventos que desencadenan o resultan de la finalizacin de un proceso, y tambin los productos que se generan a partir de la ejecucin del proceso. Los diagramas de flujo de proceso son tiles en la elaboracin de la arquitectura con especialistas en la materia, ya que permiten al especialista para describir "cmo el trabajo est hecho" para una funcin en particular. A travs de este proceso, cada paso del proceso puede llegar a ser una funcin de grano ms fino y puede, a su vez ser elaborado como un proceso.
Diagrama de eventos
El propsito del diagrama de eventos es para representar la relacin entre los eventos y proceso. Ciertos eventos - como la llegada de cierta informacin (por ejemplo, el cliente enva pedido de cliente) o de un determinado punto en el tiempo (por ejemplo, al final del trimestre fiscal) necesitan causa el trabajo y ciertas acciones que deben emprenderse en el negocio. stos se refieren a menudo como "eventos de negocios" o simplemente "eventos" y se consideran como factores desencadenantes de un proceso. Es importante tener en cuenta que el evento tiene que desencadenar un proceso y generar una respuesta de negocios o resultado.
35.6.4 Fase C: Arquitectura de Datos

A continuacin se describen los catlogos, matrices y diagramas que se pueden crear dentro de la fase C (Arquitectura de datos) que se enumeran en 10.5 Salidas .
Catlogo de Entity Data / componente de datos
El propsito del catlogo de Entity Data / componente de datos es identificar y mantener una lista de todo el uso de los datos en toda la empresa, incluyendo las entidades de datos y tambin los componentes de datos donde se almacenan las entidades de datos. Un catlogo de Entity Data / componente de datos acordado apoya la definicin y aplicacin de polticas de gestin de la informacin y gobierno de datos y tambin fomenta el intercambio de datos eficaz y reutilizacin. El catlogo Entity Data / componente de datos contiene las siguientes entidades metamodelo: Entity Data Componente lgica de datos Componente Fsico de Datos
Pgina391de670

TOGOF9.1
Entity Data / Matrix Funcin comercial
El propsito de la matriz de funciones de Entity Data / Negocios es ilustrar las relaciones entre las entidades de datos y funciones de negocios dentro de la empresa.Funciones de negocio se apoyan en los servicios empresariales con lmites definidos de forma explcita y contarn con el apoyo y se dieron cuenta de los procesos de negocio. El mapeo de la relacin de funciones de Entity DataBusiness permite lo siguiente a tener lugar: Asignar la propiedad de entidades de datos a las organizaciones Comprender los datos y las necesidades de intercambio de informacin de los servicios de negocio Apoyar el anlisis de las deficiencias y determinar si las entidades de datos se han perdido y es necesario crear Definir solicitud de origen, solicitud de registro, y la aplicacin de referencia para entidades de datos Habilitar el desarrollo de los programas de gobierno de datos en toda la empresa (establecer administrador de datos, el desarrollo de estndares de datos pertinentes a la funcin de negocios, etc)
La matriz de datos de entidad / Funcin negocios muestra las siguientes entidades y relaciones: Entity Data Funcin comercial Relacin Entity Data para ser propietario de unidad organizativa
Aplicacin / Data Matrix
El propsito de la matriz de aplicacin / datos es para representar la relacin entre las aplicaciones (es decir, componentes de la aplicacin) y las entidades de datos que se tiene acceso y actualizados por ellos. Las solicitudes sern crear, leer, actualizar y eliminar entidades especficas de datos que se asocian con ellos. Por ejemplo, una aplicacin de CRM ser crear, leer, actualizar y eliminar informacin de la entidad cliente. Las entidades de datos en un entorno de paquetes / servicios empaquetados se pueden clasificar como datos maestros, datos de referencia, datos de transacciones, datos de contenido y datos histricos. Las aplicaciones que operan en las entidades de datos incluyen aplicaciones transaccionales, aplicaciones de gestin de la informacin y las aplicaciones de almacenamiento empresarial. El mapeo de la relacin componente de aplicacin-Entity Data es un paso importante, ya que permite lo siguiente a tener lugar: Asigne acceso de datos para aplicaciones especficas en la organizacin
Pgina392de670

TOGOF9.1
Entender el grado de duplicacin de datos en diferentes aplicaciones, y la escala del ciclo de vida de los datos Entender donde los mismos datos se actualiza por diferentes aplicaciones Apoyar el anlisis de las deficiencias y determinar si alguna de las aplicaciones estn desaparecidos y como consecuencia es necesario crear
La matriz de aplicaciones / datos es una tabla de dos dimensiones con Logical componente de aplicacin en un eje y Entity Data en el otro eje.
Diagrama conceptual de datos
El propsito fundamental del esquema conceptual de datos es representar las relaciones entre las entidades de datos crticos dentro de la empresa. Este esquema se ha desarrollado para atender las preocupaciones de los interesados del negocio. Las tcnicas utilizadas son: Modelos de relacin Entidad Diagramas de clases UML simplificado
Diagrama de lgica de datos
El propsito fundamental del esquema lgico de datos es mostrar vistas lgicas de las relaciones entre las entidades de datos crticos dentro de la empresa. Este esquema ha sido desarrollado para atender las preocupaciones de: Los desarrolladores de aplicaciones Los diseadores de bases de datos
Diagrama de Divulgacin de Datos
El propsito del diagrama de Divulgacin de Datos es mostrar la relacin entre la entidad de datos, servicio de negocios, y componentes de la aplicacin. El diagrama muestra cmo las entidades lgicas se han de realizar fsicamente por componentes de la aplicacin. Esto permite dimensionamiento eficaz para llevar a cabo y la huella de TI para ser refinado. Por otra parte, mediante la asignacin de valor para el negocio a los datos, una indicacin de la criticidad del negocio de componentes de la aplicacin se puede ganar. Adems, el diagrama puede mostrar la replicacin de datos y la propiedad de las aplicaciones de la referencia principal para los datos. En este caso, puede mostrar dos copias y la relacin amo-copia entre ellos. Este diagrama puede incluir servicios; es decir, los servicios encapsulan datos y residen en una aplicacin o servicios que se encuentran en una aplicacin y acceder a datos encapsulados dentro de la aplicacin.
Diagrama de seguridad de datos
Pgina393de670

TOGOF9.1
Los datos se consideran como un activo para la empresa y la seguridad de datos, simplemente significa asegurar que los datos de la empresa no est comprometida y que el acceso a la misma se controla adecuadamente. El propsito del diagrama de seguridad de datos es describir qu actor (persona, organizacin o sistema) pueden acceder a que los datos empresariales. Esta relacin se puede mostrar en forma de matriz entre dos objetos o puede mostrarse como una asignacin. El diagrama tambin se puede utilizar para demostrar el cumplimiento de las leyes de privacidad de datos y dems normativa aplicable (HIPAA, SOX, etc). Este diagrama tambin debe considerar las implicaciones de confianza donde los socios de una empresa o de terceros pueden tener acceso a los sistemas de la empresa, como una situacin subcontratada donde la informacin puede ser administrado por otras personas e incluso puede ser alojado en un pas diferente.
Diagrama de migracin de datos
La migracin de datos es fundamental en la aplicacin de un paquete o una solucin basada en los servicios empaquetados. Esto es particularmente cierto cuando una aplicacin heredada existente se reemplaza por un paquete o una empresa se va a migrar a una mayor huella de paquetes / servicios empaquetados. Paquetes tienden a tener su propio modelo de datos y durante la migracin de datos pueden necesitar los datos de aplicaciones heredadas a ser transformado antes de cargarlos en el paquete. Actividades de migracin de datos por lo general implicar los siguientes pasos: Extraer los datos de las aplicaciones de cdigo (sistemas de referencia) Perfil de datos de origen Realizar las operaciones de transformacin de datos, incluidos los procesos de calidad de datos: o o o Estandarizar, normalizar, los datos-de duplicado de origen (limpieza de datos) Partido, fusionar y consolidar datos de diferentes fuentes (s) Asignaciones de fuente a destino
Cargue en aplicaciones de destino (sistemas de destino)
El propsito del diagrama de migracin de datos es para mostrar el flujo de datos desde la fuente a las aplicaciones de destino. El diagrama proporcionar una representacin visual de la propagacin de fuentes / objetivos y servir como herramienta de auditora de datos y el establecimiento de la trazabilidad. Este diagrama puede ser elaborado o mejorado como se detalla en caso necesario. Por ejemplo, el diagrama puede contener slo una disposicin general de la migracin de paisaje o podra entrar en el nivel de elementos de metadatos aplicacin individual de detalle.
Pgina394de670

TOGOF9.1
Diagrama del ciclo de vida de datos
El diagrama de datos del ciclo de vida es una parte esencial de la gestin de los datos de negocio a lo largo de su ciclo de vida, desde su concepcin hasta su eliminacin dentro de las limitaciones del proceso de negocio. Los datos se considera como una entidad en s mismo, desvinculado de los procesos de negocio y de la actividad. Cada cambio en el estado est representado en el diagrama que puede incluir el evento o reglas que desencadenan que el cambio en el estado. La separacin de los datos de proceso permite a los requisitos de datos comunes que se identifiquen, que permite el intercambio de recursos para alcanzar con mayor eficacia.
35.6.5 Fase C: Arquitectura de aplicaciones

A continuacin se describen los catlogos, matrices y diagramas que se pueden crear dentro de la fase C (Application Architecture) como se indica en 11.5 Salidas .
Catlogo cartera de aplicaciones
La finalidad de este catlogo es identificar y mantener una lista de todas las aplicaciones de la empresa. Esta lista ayuda a definir el alcance horizontal de las iniciativas de cambio que puedan afectar a determinados tipos de aplicaciones. Un portafolio de aplicaciones permite acordado un conjunto estndar de aplicaciones que se definan y gobernados. El catlogo del portafolio de aplicaciones proporciona una base sobre la cual basar las matrices y diagramas restantes. Normalmente es el punto de inicio de la fase de Arquitectura de la aplicacin. El catlogo de la Cartera de Aplicaciones contiene las siguientes entidades metamodelo: Servicio de Sistema de Informacin Lgico componente de aplicacin Fsica componente de aplicacin
Catlogo de interfaz
El propsito de el catlogo de interfaz es el alcance y documentar las interfaces entre las aplicaciones que permitan a las dependencias globales entre aplicaciones a ser de mbito tan pronto como sea posible. Las solicitudes sern crear, leer, actualizar y eliminar datos en otras aplicaciones; esto se lograr por algn tipo de interfaz, ya sea a travs de un archivo por lotes que se carga peridicamente, una conexin directa con la base de datos de otra aplicacin, o por medio de algn tipo de API o servicio web. El mapeo de la relacin entidad de la aplicacin del Componente-aplicacin es un paso importante, ya que permite lo siguiente a tener lugar:
Pgina395de670

TOGOF9.1
Entender el grado de interaccin entre las aplicaciones, identificando aquellos que son esenciales en trminos de sus dependencias en otras aplicaciones Entender el nmero y tipos de interfaces entre aplicaciones Entender el grado de duplicacin de interfaces entre aplicaciones Identificar las posibilidades de simplificacin de las interfaces cuando se considera la cartera de aplicaciones de destino Apoyar el anlisis de las deficiencias y determinar si alguna de las aplicaciones estn desaparecidos y como consecuencia es necesario crear
El catlogo de interfaz contiene las siguientes entidades metamodelo: Lgico componente de aplicacin Fsica componente de aplicacin Aplicacin comunica con relacin aplicacin
Aplicacin / Matrix Organizacin
El propsito de esta matriz es representar la relacin entre las aplicaciones y unidades de la organizacin dentro de la empresa. Funciones de negocio son realizadas por unidades organizativas. Algunas de las funciones y servicios prestados por las unidades organizativas sern apoyados por las aplicaciones. El mapeo de la relacin Aplicacin Unidad Componente-Organizacin es un paso importante, ya que permite lo siguiente a tener lugar: Asignar el uso de aplicaciones a las unidades de la organizacin que realizan funciones empresariales Comprender los requisitos de soporte de aplicaciones de los servicios de negocios y procesos llevados a cabo por una unidad de organizacin Apoyar el anlisis de las deficiencias y determinar si alguna de las aplicaciones estn desaparecidos y como consecuencia es necesario crear Definir el conjunto de aplicaciones que utiliza una unidad de organizacin en particular
La matriz de Aplicacin / Organizacin es una tabla de dos dimensiones con el componente lgico de aplicacin / fsica en un eje y unidad de organizacin en el otro eje. La relacin entre estas dos entidades es un compuesto de un nmero de relaciones metamodelo que necesitan validar: Unidades de Organizacin de poseer Servicios Actores que pertenecen a unidades de organizacin utilizan Servicios
Pgina396de670

TOGOF9.1
Los servicios se realizan por componentes de aplicacin lgicas / fsicas
Matrix Papel / Aplicacin
El propsito de la matriz de Papel / Aplicacin es describir la relacin entre las aplicaciones y los roles de negocio que los utilizan en la empresa. La gente en una organizacin interactan con las aplicaciones. Durante esta interaccin, estas personas asumen un papel especfico para realizar una tarea; por ejemplo, el comprador del producto. El mapeo de la relacin de componentes-funcin de aplicacin es un paso importante, ya que permite que el siguiente tenga lugar: Asignar el uso de aplicaciones a las funciones especficas en la organizacin Entender los requisitos de seguridad de la aplicacin de los servicios y procesos de apoyo a la funcin de negocio, y se les trata de acuerdo con la poltica actual Apoyar el anlisis de las deficiencias y determinar si alguna de las aplicaciones estn desaparecidos y como consecuencia es necesario crear Definir el conjunto de aplicaciones que utiliza una funcin de negocio en particular; esencial en cualquier movimiento hacia la computacin basada en roles
La matriz de roles / aplicaciones es una tabla de dos dimensiones con Logical componente de aplicacin en un eje y Papel en el otro eje. La relacin entre estas dos entidades es un compuesto de un nmero de relaciones metamodelo que necesitan validar: Papel accede Funcin Funcin es limitado por servicio Los servicios se realizan por componentes de aplicacin lgicas / fsicas
Matrix Aplicacin / Funcin
El propsito de la matriz de Uso / funcin es representar la relacin entre las aplicaciones y funciones de negocios dentro de la empresa. Funciones de negocio son realizadas por unidades organizativas. Algunas de las funciones y los servicios financieros sern mantenidos por las aplicaciones. El mapeo de la relacin de componentes-funcin de aplicacin es un paso importante, ya que permite lo siguiente a tener lugar: Asignar el uso de aplicaciones a las funciones de negocio que son compatibles con ellos Comprender los requisitos de soporte de aplicaciones de los servicios de negocios y procesos llevados a cabo
Pgina397de670

TOGOF9.1
Apoyar el anlisis de las deficiencias y determinar si alguna de las aplicaciones estn desaparecidos y como consecuencia es necesario crear Definir el conjunto de aplicaciones utilizado por una empresa particular la funcin
La matriz de aplicacin / funcin es una tabla de dos dimensiones con lgica componente de aplicacin en un eje y Funcin en el otro eje. La relacin entre estas dos entidades es un compuesto de un nmero de relaciones metamodelo que necesitan validar: Funcin es limitado por servicio Los servicios se realizan por componentes de aplicacin lgicas / fsicas
Aplicacin matriz de interaccin
El propsito de la matriz de interaccin de aplicaciones es para representar relaciones de comunicacin entre aplicaciones. El mapeo de las interacciones de las aplicaciones muestra en la matriz de formar el equivalente de la Catlogo de interfaz o un diagrama de comunicaciones de la aplicacin. La matriz de la interaccin de aplicaciones es una tabla de dos dimensiones con servicios de aplicaciones, Logical componente de aplicacin, y Fsica componente de aplicacin en las filas y las columnas de la tabla. Las relaciones representadas por esta matriz incluyen: Application Service consume Application Service Lgico componente de aplicacin se comunica con Logical componente de aplicacin Fsica componente de aplicacin se comunica con Fsica componente de aplicacin
Aplicacin Diagrama Comunicacin
El propsito del diagrama de comunicaciones de la aplicacin es para representar todos los modelos y las asignaciones relacionadas con la comunicacin entre las aplicaciones en la entidad metamodelo. Muestra los componentes de aplicaciones e interfaces entre los componentes. Las interfaces pueden estar asociados con las entidades de datos en su caso. Las aplicaciones pueden estar asociados con los servicios de negocio en su caso. La comunicacin debe ser lgica y slo debe mostrar la tecnologa intermedia donde es arquitectnicamente relevante.
Solicitud y usuario Ubicacin Diagrama
El Esquema de aplicacin y usuario Ubicacin muestra la distribucin geogrfica de las solicitudes. Se puede utilizar para mostrar donde las aplicaciones se utilizan por el usuario final; la
Pgina398de670

TOGOF9.1
distribucin de donde se ejecuta y / o entrega en los escenarios de cliente ligero de la aplicacin host; la distribucin de donde se desarrollan aplicaciones, probados y puestos en libertad; etctera El anlisis puede revelar oportunidades para la racionalizacin, as como la duplicacin y / o lagunas. El propsito de este diagrama es representar claramente las ubicaciones de la empresa de la que los usuarios de negocios por lo general interactan con las aplicaciones, sino tambin la ubicacin de alojamiento de la infraestructura de aplicaciones. El diagrama permite: Identificacin del nmero de instancias de paquetes necesarios para soportar suficientemente la poblacin de usuarios que pueden estar dispersas geogrficamente Estimacin del nmero y el tipo de licencias de usuario para el paquete u otro software Estimacin del nivel de apoyo necesario para los usuarios y la ubicacin de centro de apoyo Seleccin de las herramientas de administracin del sistema, la estructura y el sistema de gestin necesarios para apoyar las empresas los usuarios / clientes / socios tanto a nivel local como a distancia La planificacin adecuada para los componentes tecnolgicos de la empresa, es decir, el ancho de banda tamao del servidor y de la red, etc Consideraciones sobre el rendimiento, mientras que la implementacin de soluciones de arquitectura de aplicaciones y tecnologa
Normalmente, los usuarios interactan con las aplicaciones en una variedad de maneras; por ejemplo: Para apoyar las operaciones de los negocios del da a da Para participar en la ejecucin de un proceso de negocio Para tener acceso a la informacin (bsqueda, lectura) Para desarrollar la aplicacin Administrar y mantener la aplicacin
Diagrama de Casos de Uso
Un Esquema de aplicacin de casos de uso muestra las relaciones entre consumidores y proveedores de servicios de aplicacin. Los servicios de aplicacin son consumidos por los actores u otros servicios de la aplicacin y el diagrama de casos de uso de aplicaciones proporciona riqueza agregada en la descripcin de funciones de la aplicacin mediante la ilustracin de cmo y cundo se utiliza esa funcionalidad.
Pgina399de670

TOGOF9.1
El propsito del diagrama de aplicacin de casos de uso es ayudar a describir y validar la interaccin entre los actores y sus roles con las aplicaciones. Como la arquitectura avanza, el caso de uso puede evolucionar a partir de informacin funcional para incluir detalles realizacin tcnica. Aplicacin casos de uso tambin pueden ser reutilizadas en los sistemas ms detallado trabajo de diseo.
Empresa Manejabilidad Diagrama
El diagrama muestra cmo la empresa de administracin de una o ms aplicaciones interactan con aplicaciones y tecnologa de componentes que soportan la gestin operativa de una solucin. Este diagrama es realmente un filtro en el diagrama de comunicaciones de la aplicacin, en concreto para el software de clase de gestin empresarial. El anlisis puede revelar duplicaciones y lagunas y oportunidades en la operacin de gestin de servicios de TI de una organizacin.
Realizacin de proceso / aplicacin Diagrama
El propsito del diagrama Realizacin Proceso / aplicacin es de representar claramente la secuencia de eventos cuando mltiples aplicaciones estn implicados en la ejecucin de un proceso de negocio. Realza el diagrama de comunicaciones de la aplicacin aadindole las restricciones de secuenciacin, y los puntos de la mano-off entre lotes y procesamiento en tiempo real. Sera identificar secuencias complejas que podran simplificarse, e identificar posibles puntos de racionalizacin en la arquitectura con el fin de proporcionar informacin ms oportuna a los usuarios de negocios. Tambin puede identificar las mejoras en la eficiencia de procesos que pueden reducir el trfico de la interaccin entre aplicaciones.
Software Diagrama Ingeniera
El diagrama de la Ingeniera del Software rompe aplicaciones en paquetes, los mdulos, los servicios y las operaciones desde una perspectiva de desarrollo. Permite a un anlisis ms detallado del impacto en la planificacin de las etapas de la migracin, y el anlisis de las oportunidades y soluciones. Es ideal para los equipos de desarrollo de aplicaciones y equipos de gestin de aplicaciones en la gestin de los entornos de desarrollo complejos.
Diagrama de aplicacin de Migracin
El diagrama de Migracin de aplicaciones identifica la migracin de aplicaciones de lnea de base a los componentes de la aplicacin. Permite a una estimacin ms precisa de los costos de migracin al mostrar con precisin qu se deben asignar entre las etapas de migracin de aplicaciones e interfaces.
Pgina400de670

TOGOF9.1
Sera identificar aplicaciones temporales, reas de estacionamiento, y la infraestructura necesaria para apoyar las migraciones (por ejemplo, entornos de ejecucin paralelas, etc.)
Diagrama de distribucin de software
El diagrama de distribucin de software, se muestra cmo el software de aplicacin se estructura y se distribuye a travs de la finca. Es til en la actualizacin de los sistemas o de los proyectos de consolidacin de aplicaciones. Este diagrama muestra cmo las aplicaciones fsicas se distribuyen a travs de la tecnologa fsica y de la ubicacin de esa tecnologa. Esto permite una visin clara de cmo se encuentra alojado el software, sino que tambin permite que gestiona el personal de operaciones pueda comprender como que el software de aplicacin se mantiene una vez instalado.
35.6.6 Fase D: Architecture Tecnologa

La siguiente seccin describe los catlogos, matrices y diagramas que se pueden crear dentro de la Fase D (Architecture Technology) que se enumeran en 12.5 Salidas .
Catlogo de Estndares de Tecnologa
El catlogo de Estndares de Tecnologas documenta las normas acordadas para la tecnologa en toda la empresa que cubren las tecnologas y las versiones, los ciclos de vida de la tecnologa, y los ciclos de actualizacin de la tecnologa. Dependiendo de la organizacin, esto tambin puede incluir la ubicacin o dominio especfico de informacin comercial estndares. Este catlogo ofrece una visin general de las tecnologas estndares de la empresa que son o pueden ser desplegados, y tambin ayuda a identificar las discrepancias en toda la empresa. Si los estndares de tecnologa estn actualmente en vigor, se aplican estos para el catlogo Cartera Tecnolgica para obtener una visin de base del cumplimiento de los estndares tecnolgicos. El catlogo Cartera Tecnolgica contiene las siguientes entidades metamodelo: Plataforma de Servicios Lgico Componente Tecnologa Componente Tecnologa Fsica
Pgina401de670

TOGOF9.1
Catlogo Cartera Tecnolgica
La finalidad de este catlogo es identificar y mantener una lista de toda la tecnologa en uso en toda la empresa, incluyendo hardware, software de infraestructura y software de aplicacin. Una cartera de tecnologa acordado apoya la gestin del ciclo de vida de productos de tecnologa y versiones, y tambin es la base para la definicin de estndares de tecnologa. El catlogo Cartera Tecnolgica proporciona una base sobre la cual basar las matrices y diagramas restantes. Normalmente es el punto de inicio de la fase de Tecnologa de la Arquitectura. Registros de tecnologa y bases tambin proporcionan aportacin a este catlogo de una lnea de base y se dirigen a la perspectiva. Tecnologas en el catlogo deben clasificarse en contra de la tecnologa Modelo de Referencia TOGAF (TRM) - vase la parte VI , 43. Fundacin Arquitectura: Modelo de referencia tcnica - la extensin del modelo segn sea necesario para ajustarse a la clasificacin de los productos de la tecnologa en uso. El catlogo Cartera Tecnolgica contiene las siguientes entidades metamodelo: Plataforma de Servicios Lgico Componente Tecnologa Componente Tecnologa Fsica
Aplicacin / Matrix Tecnologa
La matriz de Aplicacin / Tecnologa documenta el mapeo de aplicaciones para la plataforma tecnolgica. Esta matriz debe estar alineada con y complementar uno o varios diagramas de descomposicin de la plataforma. La Aplicacin / matriz Tecnologa muestra: Componentes lgicos de aplicacin / Fsica Servicios, Componentes Tecnolgicos lgicos y Componentes Tecnologa Fsicas Tecnologa del componente fsico se da cuenta de las relaciones de componente de aplicacin de Fsica
Entornos y diagrama de las ubicaciones
El diagrama de ambientes y zonas representa qu lugares albergan las aplicaciones, lo que identifica las tecnologas y / o aplicaciones que se utilizan en las ubicaciones y, finalmente, identifica los lugares desde los que los usuarios de negocios por lo general interactan con las aplicaciones.
Pgina402de670

TOGOF9.1
Este diagrama tambin debe mostrar la existencia y ubicacin de los diferentes entornos de implementacin, incluyendo entornos no productivos, como el desarrollo y la produccin de pre.
Plataforma Descomposicin Diagrama
El diagrama de la Plataforma de descomposicin representa la plataforma tecnolgica que soporta las operaciones de la Arquitectura de Sistemas de Informacin. El esquema cubre todos los aspectos de la plataforma de infraestructura y proporciona una visin general de la plataforma tecnolgica de la empresa. El diagrama se puede ampliar para mapear la plataforma de tecnologa para componentes de aplicacin apropiadas dentro de un rea funcional o proceso especfico. Este diagrama puede mostrar detalles de las especificaciones, como las versiones de producto, nmero de CPU, etc, o simplemente podra ser un "ojo-chart" informal que proporciona una visin general del entorno tcnico. El diagrama debe mostrar claramente las aplicaciones empresariales y la plataforma de tecnologa para cada rea de aplicacin ms se puede descomponer de la siguiente manera: Hardware: o o Componentes tecnolgicos lgicos (con atributos) Componentes tecnolgicos fsica (con atributos)
Software: o o Componentes tecnolgicos lgicos (con atributos) Componentes tecnolgicos fsica (con atributos)
Dependiendo del alcance de la obra de arquitectura empresarial, la tecnologa de la informacin adicional entre plataformas (por ejemplo, comunicaciones, telecomunicaciones y la informacin de video) se puede abordar.
Diagrama de Procesamiento
El diagrama de procesamiento se centra en unidades de despliegue de cdigo / configuracin y cmo stas se implementan en la plataforma tecnolgica. Una unidad de implementacin representa la agrupacin de las funciones de negocios, servicio, o componentes de la aplicacin. El diagrama de procesamiento se dirige a la siguiente: Que deben ser agrupados conjunto de componentes de la aplicacin para formar una unidad de despliegue Como una unidad de despliegue conecta / interacta con otro (LAN, WAN, y los protocolos aplicables) Como formas de configuracin de la aplicacin y uso generan requerimientos de carga o de capacidad para los distintos componentes de la tecnologa
La organizacin y agrupacin de unidades de implementacin depende de las preocupaciones de separacin de la presentacin, lgica de negocio y almacenamiento de datos capas y los requisitos
Pgina403de670

TOGOF9.1
de nivel de servicio de los componentes. Por ejemplo, unidad de despliegue capa de presentacin se agrupa en base a la siguiente: Los componentes de aplicacin que proporcionan funciones de interfaz de usuario o de acceso de usuarios Los componentes de aplicacin que se diferencian por ubicacin y funciones de usuario
Hay varias consideraciones para determinar cmo se agrupan los componentes de aplicaciones. Cada unidad de despliegue se compone de sub-unidades, tales como: Instalacin : Parte que contiene el cdigo ejecutable o configuracin de paquetes (en el caso de los paquetes). Ejecucin : el componente de la aplicacin con su estado asociado en tiempo de ejecucin. Persistencia : Los datos que representa el estado persistente de la componente de la aplicacin.
Por ltimo, estas unidades de implementacin se implementan en los componentes tecnolgicos y dedicar o compartidos (estacin de trabajo, servidor web, servidor de aplicaciones o servidor de base de datos, etc.) Es importante tener en cuenta que el procesamiento de la tecnologa puede influir y repercutir en la definicin de servicios y granularidad.
Red Informtica / Hardware Diagrama
A partir de la transformacin de los sistemas cliente-servidor de mainframes y ms tarde con la llegada del e-Business y J2EE, las grandes empresas movido principalmente en un entorno distribuido de computacin en red altamente red basada en servidores de seguridad y zonas desmilitarizadas. En la actualidad, la mayora de las aplicaciones tienen un front-end web y, mirando a la arquitectura de implementacin de estas aplicaciones, es muy comn encontrar tres capas distintas en el panorama de la red; a saber, una capa de presentacin de la tela, una lgica de negocio o capa de aplicacin, y una capa de almacenamiento de datos back-end. Es una prctica comn para las aplicaciones que se desplegarn y alojados en un entorno de infraestructura compartida y comn. Por lo que es muy crtico para documentar la correspondencia entre las aplicaciones lgicas y los componentes de la tecnologa (por ejemplo, servidores) que apoya la aplicacin tanto en los entornos de desarrollo y produccin. El propsito de este diagrama es para mostrar la vista lgica "como desplegado" de componentes de aplicaciones lgicas en un entorno informtico de red distribuida. El diagrama es til para las siguientes razones: Habilitar la comprensin de que la aplicacin se implementa en donde en el entorno informtico de red distribuida El establecimiento de la autorizacin, la seguridad y el acceso a estos componentes de la tecnologa Entender la Arquitectura Tecnologa que soporta las aplicaciones durante la resolucin de problemas y solucin de problemas
Pgina404de670

TOGOF9.1
Aislar los problemas de rendimiento encontradas por las aplicaciones, determine si es relacionado con el cdigo de la aplicacin o relacionada con la plataforma de la tecnologa, y realizar la actualizacin necesaria para los componentes especficos de la tecnologa fsica Identificar las reas de optimizacin a medida que las nuevas tecnologas estn disponibles que eventualmente reducir costos Habilitar application / tecnologa de auditacin y acreditar el cumplimiento de las normas de tecnologa de la empresa Servir como una herramienta importante para introducir cambios en la arquitectura de la tecnologa, de tal modo apoyando la gestin del cambio efectiva Establecer la trazabilidad y el cambio de direccin de punto final de la aplicacin mientras se mueve la aplicacin ya sea de un entorno compartido de un entorno dedicado o viceversa
El alcance del diagrama puede ser definido apropiadamente para cubrir una aplicacin especfica, la funcin de negocios, o toda la empresa. Si es elegido para ser desarrollado en el mbito de la empresa, entonces el panorama de la informtica de la red puede ser representado de una manera agnstica aplicacin tambin.
Comunicaciones Diagrama Ingeniera
El diagrama de Ingeniera de Comunicaciones se describen los medios de comunicacin - el mtodo de envo y recepcin de informacin - entre estos activos en la Arquitectura de Tecnologa; siempre que la seleccin de paquetes de soluciones en las arquitecturas anteriores imponer requisitos especficos sobre las comunicaciones entre las aplicaciones. El diagrama de Ingeniera de Comunicaciones tendr conexiones lgicas entre el cliente y componentes de servidor y de identificar los lmites de la red y la infraestructura de red necesaria para implementar fsicamente esas conexiones. No describe el formato de la informacin o el contenido, pero se ocupar de cuestiones de protocolo y de capacidad.
35.6.7 Fase E: Oportunidades y Soluciones

La siguiente seccin describe los catlogos, matrices y diagramas que se pueden crear dentro de la Fase E (Oportunidades y Soluciones) que se enumeran en 13.5 Salidas .
Proyecto Diagrama de Contexto
Un diagrama de contexto del proyecto se muestra el alcance de un paquete de trabajo para ser implementado como parte de un plan ms amplio de transformacin. El diagrama de contexto del proyecto vincula un paquete de trabajo de las organizaciones, funciones, servicios, procesos, aplicaciones, datos y tecnologa que se agrega, se quita o afectado por el proyecto. El diagrama de contexto del proyecto es tambin una valiosa herramienta para la gestin de la cartera de proyectos y la movilizacin de proyectos.
Diagrama de Beneficios
Pgina405de670

TOGOF9.1
El diagrama muestra Beneficios oportunidades identificadas en la definicin de la arquitectura, que se clasifica en funcin de su tamao relativo, el beneficio y la complejidad. Este diagrama puede ser utilizado por los interesados para hacer la seleccin, priorizacin y secuenciacin de las decisiones sobre las oportunidades identificadas.
Gestin 35.6.8 Requisitos

La siguiente seccin describe los catlogos, matrices y diagramas que se pueden crear dentro de la fase de gestin de requisitos que se enumeran en 17.5 Salidas .
Requisitos del catlogo
El catlogo Requisitos capta las cosas que la empresa tiene que hacer para cumplir con sus objetivos. Requisitos generados a partir de la arquitectura compromisos se aplican normalmente a travs de las iniciativas de cambio identificados y con mbito en la Fase E (Oportunidades y Soluciones). Los requisitos tambin pueden ser utilizados como una herramienta de control de calidad para asegurarse de que una arquitectura particular, es apto para el propsito (es decir, la arquitectura puede cumplir todos los requisitos identificados). El catlogo contiene los requisitos de las siguientes entidades metamodelo: Requisito Asuncin Restriccin Brecha
35.7 Vistas Arquitectura recomendados para ser desarrollados

Parte III , 24. Gestin de los grupos de inters se presenta un resumen de los principales grupos de inters que se encuentran normalmente en el desarrollo de la arquitectura empresarial. Los probables preocupaciones de cada grupo de inters tambin son identificados junto con los artefactos pertinentes (catlogos, matrices y diagramas). Los puntos de vista de arquitectura, y puntos de vista correspondientes, que se pueden crear para apoyar cada uno de estos grupos de inters se dividen en las siguientes categoras: Vistas Arquitectura Profesiones, que abordan las preocupaciones de los usuarios del sistema, y describen los flujos de informacin empresarial entre las personas y los procesos de negocio Puntos de vista de arquitectura de datos, que responden a las preocupaciones de los diseadores de bases de datos y administradores de bases de datos e ingenieros de sistemas responsables de desarrollo e integracin de los distintos componentes de bases de datos del sistema Vistas arquitectura de la aplicacin, que abordan las preocupaciones de los sistemas y software ingenieros responsables del desarrollo y la integracin de los diversos componentes de software de aplicacin del sistema de
Pgina406de670

TOGOF9.1
Vistas Arquitectura Tecnologa, que abordan las preocupaciones de los compradores (el personal de adquisiciones responsables de la adquisicin de la Commercial Off-The-Shelf (COTS) de software y hardware que se incluirn en el sistema), el personal de operaciones, administradores de sistemas y administradores de sistemas
En las siguientes subsecciones TOGAF presenta algunas vistas recomendadas, algunos o todos de los cuales pueden ser apropiadas en un desarrollo de la arquitectura en particular. Esto no pretende ser un conjunto exhaustivo de puntos de vista, sino simplemente como un punto de partida. Los descritos podrn complementarse con visitas adicionales segn sea necesario. Este material debe ser considerado como guas para el desarrollo y el tratamiento de una vista, no como una definicin completa de un punto de vista. Los artefactos identificados en 35.6 Architectural Artifacts por ADM fase se pueden utilizar para hacer frente a las preocupaciones especficas de los grupos de inters, y en algunos casos los artefactos se pueden utilizar con la vista del mismo nombre; por ejemplo, el diagrama de Ingeniera de Software, Ingeniera de Comunicaciones diagrama, y el diagrama de la Empresa de administracin. Cada subseccin se describen los grupos de inters relacionados con la vista, sus preocupaciones y las entidades modeladas y el lenguaje utilizado para describir la vista (el punto de vista). El mirador ofrece conceptos de arquitectura de los diferentes puntos de vista, incluidos los componentes, interfaces y asignacin de los servicios esenciales para la vista. Los idiomas punto de vista, los mtodos analticos, y de modelado mtodos asociados con vistas se aplican tpicamente con el uso de herramientas apropiadas.
35.7.1 Desarrollo de una arquitectura empresarial Visualizar

El punto de vista de la Arquitectura de Negocios se ocupa de atender las preocupaciones de los usuarios.
35.7.1.1 Las partes interesadas y Preocupaciones
Este punto de vista debe ser desarrollado para los usuarios. Se centra en los aspectos funcionales del sistema desde la perspectiva de los usuarios del sistema. Responder a las expectativas de los usuarios incluye la consideracin de los siguientes: Personas Los aspectos de recursos humanos del sistema. Examina los actores humanos involucrados en el sistema. Proceso Se ocupa de los procesos de usuario que intervienen en el sistema. Funcin Se ocupa de las funciones requeridas para soportar los procesos. Informacin de contacto Se ocupa de la informacin necesaria para fluir en apoyo de los procesos.
Pgina407de670

TOGOF9.1
Usabilidad Considera los aspectos de usabilidad del sistema y de su entorno. Rendimiento Considera los aspectos de rendimiento del sistema y de su entorno.
35.7.1.2 Desarrollo de la Vista
Escenarios de negocios (vase la Parte III , 26. Escenarios empresariales y objetivos de la empresa ) son una tcnica importante que puede utilizarse antes y como un insumo clave para el desarrollo de la vista de arquitectura de negocio, para ayudar a identificar y entender las necesidades del negocio, y por lo tanto para obtener los requerimientos del negocio y las limitaciones que el desarrollo de la arquitectura tiene que abordar. Escenarios de negocios son una manera muy til para describir lo que debe suceder cuando se planifican y se producen acontecimientos imprevistos. Es altamente recomendable que los escenarios de negocio pueden crear para el cambio planificado, y para el cambio no planificado. La siguiente seccin describe algunas de las cuestiones clave que el arquitecto podra tener en cuenta al construir escenarios de negocio.
35.7.1.3 Cuestiones clave
La vista Business Architecture considera los aspectos funcionales del sistema; es decir, lo que el nuevo sistema se pretende hacer. Esto puede ser construido a partir de un anlisis del entorno existente y de los requisitos y limitaciones que afectan al nuevo sistema. Los nuevos requisitos y limitaciones aparecern a partir de un nmero de fuentes, incluyendo posiblemente: Existentes especificaciones internas y las listas de productos aprobados Metas y objetivos de negocio Actividades de reingeniera de procesos de negocio Los cambios en la tecnologa
Lo que debera salir de la vista de arquitectura de negocio es una comprensin clara de los requisitos funcionales de la nueva arquitectura, con frases como: "Se necesitan mejoras en el manejo de consultas de los clientes a travs del uso ms amplio de integracin computadora / telefona". La vista Business Architecture considera los aspectos de usabilidad del sistema y de su entorno. . Tambin debe tener en cuenta los impactos sobre el usuario, tales como los niveles de cualificacin requeridos, la necesidad de formacin especializada, y la migracin de la prctica actual Al considerar la usabilidad del arquitecto debera tener en cuenta: El, y cmo intuitiva facilidad de uso de la interfaz de usuario es
Pgina408de670

TOGOF9.1
Sea o no un acceso transparente a los datos y aplicaciones, independientemente de la ubicacin La facilidad de gestin del entorno de usuario por el usuario Interoperabilidad de aplicaciones a travs de medios tales como arrastrar y soltar Servicios de ayuda en lnea La claridad de la documentacin Seguridad y contrasea aspectos, tales como evitar la necesidad de mltiples cuadros de dilogo de inicio de sesin y contrasea El acceso a las aplicaciones de productividad, como el correo o una hoja de clculo
Tenga en cuenta que, aunque la seguridad y la gestin se cree por aqu, es desde el punto de vista de la facilidad de uso y funcionalidad. Los aspectos tcnicos de la seguridad y la gestin son considerados en la vista de seguridad de la empresa (ver 35.7.2 Desarrollar un Vista Enterprise Security ) y la visin empresarial de administracin (ver 35.7.7 Desarrollo de una empresa de administracin Ver ).
35.7.2 Desarrollo de un Vista Enterprise Security

La vista Enterprise Security se ocupa de los aspectos de seguridad del sistema.
Este punto de vista se debe desarrollar para los ingenieros de seguridad del sistema. Se centra en cmo se implementa el sistema desde el punto de vista de la seguridad, y cmo afecta a la seguridad de las propiedades del sistema. Se examina el sistema para establecer qu informacin es almacenada y procesada, lo valioso que es, lo que las amenazas existen, y cmo se pueden abordar. Las principales preocupaciones de este punto de vista son la comprensin de cmo asegurarse de que el sistema est disponible slo a aquellos que tienen permiso, y cmo proteger el sistema contra cambios no autorizados.
Los temas de la arquitectura general de un "sistema de seguridad" son componentes que estn asegurados, o componentes que proporcionan servicios de seguridad.Adems Listas de control de acceso (ACL) y definiciones de esquema de seguridad se utilizan para modelar e implementar la seguridad.
35.7.2.3 Conceptos Bsicos
En esta seccin se presentan los conceptos bsicos necesarios para la comprensin de la seguridad del sistema de informacin.
Pgina409de670

TOGOF9.1
La esencia de la seguridad es el uso controlado de la informacin. El propsito de esta seccin es proporcionar una breve descripcin de cmo se lleva a cabo la proteccin de seguridad de los componentes de un sistema de informacin. Mecanismos doctrinales o de procedimiento, tales como los procedimientos y polticas de seguridad fsicas y de personal, no se discuten aqu en profundidad. La Figura 35-4 muestra una vista abstracta de una Arquitectura de Sistemas de la Informacin, que hace hincapi en el hecho de que un sistema de informacin desde la perspectiva de la seguridad es ya sea parte de un entorno local de abonado (LSE) o una Red de Comunicaciones (CN). Un LSE puede ser fijo o mvil. Las empresas grandes, por definicin, estn bajo el control de la organizacin utilizando. En una aplicacin de computacin distribuida de sistemas abiertos, casi con toda seguridad se requerirn LSE seguras y no seguras para interoperar.
Figura354:AbstractoSeguridadArquitecturaVista
Dominios de Informacin
El concepto de un dominio de informacin proporciona la base para la discusin de los requisitos de proteccin de la seguridad. Un dominio de la informacin se define como un conjunto de usuarios, sus objetos de informacin, y una poltica de seguridad. Una poltica de seguridad de la informacin de dominio es la declaracin de los criterios de adhesin en el mbito de la informacin y la proteccin necesaria de los objetos de informacin. Rompiendo la informacin de una organizacin hasta en dominios es el primer paso en la reduccin de la tarea de la elaboracin de polticas de seguridad a un tamao manejable. El negocio de la mayora de las organizaciones requiere que sus miembros operan en ms de un dominio de informacin. La diversidad de las actividades comerciales y la variacin en la percepcin de las amenazas a la seguridad de la informacin dar lugar a la existencia de diferentes dominios de informacin dentro de una poltica de seguridad de la organizacin. Una actividad especfica puede utilizar varios dominios de informacin, cada uno con su propia informacin distinta la poltica de seguridad de dominio. Dominios de informacin no estn necesariamente limitadas por los sistemas de informacin o incluso redes de sistemas. Los mecanismos de seguridad implementados en los componentes del sistema de informacin pueden ser evaluados por su capacidad para cumplir con las polticas de seguridad de dominio de informacin.
Pgina410de670

TOGOF9.1
Aislamiento Estricto
Dominios de informacin puede ser vista como estrictamente aislados unos de otros. Objetos de informacin deben ser transferidos entre dos dominios de informacin slo de acuerdo con las reglas establecidas, condiciones y procedimientos expresados en la poltica de seguridad de cada dominio de la informacin.
Proteccin Absoluta
El concepto de "proteccin absoluta" se utiliza para lograr el mismo nivel de proteccin en todos los sistemas de informacin de apoyo a la informacin de dominio particular. Se llama la atencin sobre los problemas creados por la interconexin de las empresas grandes que proporcionan diferentes puntos fuertes de proteccin de seguridad. Esta interconexin es probablemente porque los sistemas abiertos pueden consistir en un nmero indeterminado de empresas grandes heterogneos. Anlisis de los requisitos mnimos de seguridad se asegurar de que el concepto de proteccin absoluta se conseguir para cada dominio de informacin a travs de las empresas grandes.
35.7.2.4 Generic Security Architecture Vista
La Figura 35-5 muestra una vista de la arquitectura genrica que puede ser utilizado para discutir la asignacin de los servicios de seguridad y la implementacin de mecanismos de seguridad. Este punto de vista se identifican los componentes de la arquitectura dentro de una LSE. Las empresas grandes estn conectados por la CNS.Las empresas grandes son los sistemas finales, sistemas de retransmisin y Sistemas Locales de Comunicaciones (LCS), que se describen a continuacin.
Figura355:GenericSecurityArchitectureVista
Relay System (RS) : El componente de la LSE, cuya funcionalidad se limita a la transferencia de informacin y es slo indirectamente accesible por los usuarios (por ejemplo, router, switch, multiplexor, Agente de transferencia de mensajes (MTA)). Se puede tener una funcionalidad similar a un sistema final, sino un usuario final no utilizarlo directamente. Tenga en cuenta que las funciones del sistema de rel se pueden proporcionar en un sistema final.
Pgina411de670

TOGOF9.1
Sistema de Comunicacin Local (LCS) : Una red que proporciona capacidades de comunicacin entre las empresas grandes o dentro de un LSE con todos los componentes bajo el control de un LSE. Red de Comunicaciones (CN) : Una red que proporciona inter-LSE capacidades de comunicacin, pero no es controlado por las empresas grandes (por ejemplo, los transportistas comerciales).
El sistema de cierre y el sistema de rel son vistos como que requiere el mismo tipo de proteccin de seguridad. Por esta razn, una discusin de la proteccin de seguridad en un sistema de extremo generalmente tambin se aplica a un sistema de rel. Las protecciones de seguridad en un sistema final podra ocurrir en el hardware y el software.
35.7.2.5 Asignacin de Servicios de Seguridad
La proteccin de seguridad de un sistema de informacin es proporcionada por los mecanismos implementados en el hardware y el software del sistema y por el uso de los mecanismos doctrinales. Los mecanismos implementados en el hardware y el software del sistema se concentran en el sistema final o sistema de rel. Este enfoque para la proteccin de seguridad se basa en el sistema abierto, el enfoque de computacin distribuida para sistemas de informacin. Esto implica el uso de portadores comunes comerciales y sistemas de comunicacin de uso comn privadas como el proveedor de CN entre las empresas grandes. Por lo tanto, para la operacin de sistemas de extremo en un entorno distribuido, un mayor grado de proteccin de seguridad puede asegurarse de la aplicacin de mecanismos en el sistema final o sistema de rel. Sin embargo, las redes de comunicacin deben satisfacer el elemento de disponibilidad de la seguridad con el fin de proporcionar una proteccin de seguridad adecuada para el sistema de informacin. Esto significa que los CN debe proporcionar un nivel acordado de la capacidad de respuesta, la continuidad del servicio, y la resistencia a las amenazas accidentales e intencionales a la disponibilidad de servicios de comunicaciones. La aplicacin de la proteccin de la seguridad necesaria en el sistema final se produce en tres reas de servicio del sistema de TOGAF. Ellos estn operando los servicios del sistema, servicios de red y servicios de administracin de sistemas. La mayor parte de la implementacin de la proteccin de seguridad se espera que ocurra en el software. Se espera que el hardware para proteger la integridad del software de sistema de extremo. Mecanismos de seguridad de hardware incluyen la proteccin contra la manipulacin, emanaciones no deseadas, y la criptografa.
Servicios del sistema operativo
Un "contexto de seguridad" se define como un proceso controlado el espacio objeto de una poltica de seguridad de la informacin de dominio. Por tanto, el contexto de seguridad es anlogo a una nocin de sistema operativo comn de espacio de proceso de usuario. Se requiere aislamiento de contextos de seguridad. Se requieren los contextos de seguridad para todas las aplicaciones (aplicaciones por ejemplo, los usuarios finales y la gestin de la seguridad). La atencin se centra en el aislamiento estricto de los dominios de informacin, gestin de los recursos del sistema final, y el uso compartido controlado y la transferencia de informacin entre los dominios de informacin. Cuando sea posible, las funciones crticas de seguridad deben ser aislados en relativamente pequeos mdulos que se relacionan de maneras bien definidas .
Pgina412de670

TOGOF9.1
El sistema operativo aislar mltiples contextos de seguridad entre s mediante funciones de proteccin de hardware (por ejemplo, registro de estado del procesador, registros de asignacin de memoria) para crear espacios de direcciones separados para cada uno de ellos. Software no fiable utilizar recursos del sistema final slo invocando funciones crticas de seguridad a travs del ncleo de la separacin. La mayor parte de las funciones crticas de seguridad son las funciones de bajo nivel de los sistemas operativos tradicionales.
Servicios de red
Dos clases bsicas de comunicaciones se prevn para los que distribuyen contextos de seguridad pueden necesitar ser establecida. Estos son interactivos y protagonizaron (almacenamiento y retransmisin) de comunicaciones. El concepto de una "asociacin de seguridad" constituye un contexto interactivo seguridad distribuida. Una asociacin de seguridad se define como todos los mecanismos de comunicacin y de seguridad y funciones que amplan las protecciones exigidas por una poltica de seguridad de la informacin de dominio dentro de un sistema de extremo a la informacin en la transferencia entre mltiples sistemas finales. La asociacin de seguridad es una extensin o ampliacin de una asociacin de capa de aplicacin de OSI. Una asociacin de capa de aplicacin se compone de funciones y protocolos de capa de aplicacin apropiadas, adems de todas las funciones y protocolos de comunicaciones subyacentes en otras capas del modelo OSI. Mltiples protocolos de seguridad pueden ser incluidos en un solo asociacin de seguridad para proporcionar una combinacin de servicios de seguridad. Para las comunicaciones de entrega por etapas (por ejemplo, correo electrnico), se har uso de una tcnica de encapsulacin (denominado "proceso de envoltura") para transmitir los atributos de seguridad necesaria con los datos que se transfieren como parte de los servicios de red. Los atributos de seguridad envueltos pretenden permitir que el sistema extremo receptor para establecer el contexto de seguridad necesarias para el procesamiento de los datos transferidos. Si el proceso de envoltura no puede proporcionar toda la proteccin de la seguridad es necesario, contextos de seguridad de interaccin entre sistemas finales tendrn que ser utilizados para garantizar la transferencia segura en escena de la informacin.
Sistema de Servicios de Gestin de la Seguridad
Gestin de la seguridad es un caso particular de las funciones de gestin de sistemas de informacin que se analiza en los captulos anteriores. Servicios de gestin de la seguridad del sistema de informacin se refieren a la instalacin, mantenimiento y observancia de dominio de la informacin y las reglas de poltica de seguridad de sistemas de informacin en el sistema de informacin destinado a proporcionar estos servicios de seguridad. En particular, la funcin de gestin de la seguridad controla la informacin que necesitan los servicios del sistema operativo dentro de la arquitectura de seguridad del sistema final. Adems de estos servicios bsicos, gestin de seguridad requiere el manejo de eventos, la auditora y la recuperacin. La normalizacin de las funciones de gestin de seguridad, estructuras de datos y protocolos permitir la interoperabilidad de los procesos de aplicacin de gestin de seguridad (smaps) a travs de muchas plataformas de apoyo a la gestin de seguridad distribuida.
35.7.3 Desarrollo de un Software Engineering Ver

La vista de la Ingeniera de Software tiene que ver con el desarrollo de nuevos sistemas de software.
Pgina413de670

TOGOF9.1
La construccin de un sistema de software intensivo es a la vez caro y consume mucho tiempo. Debido a esto, es necesario establecer directrices para ayudar a minimizar el esfuerzo requerido y los riesgos involucrados. Este es el propsito de la vista de la Ingeniera del Software, que debe ser desarrollado para los ingenieros de software que van a desarrollar el sistema. Las principales preocupaciones de estos grupos de inters son: Enfoque de Desarrollo La modularidad del software y de re-uso Portabilidad Migracin e interoperabilidad
Enfoque de Desarrollo
Hay muchos modelos de ciclo de vida definido para el desarrollo de software (cascada, prototipos, etc.) Una consideracin para el arquitecto es la mejor manera de alimentar las decisiones arquitectnicas en el modelo de ciclo de vida que va a ser utilizado para el desarrollo del sistema.
Software Modularidad y Reutilizacin
Como una pieza de software crece en tamao, por lo que la complejidad y las interdependencias entre diferentes partes del aumento de cdigo. Confiabilidad caer drsticamente a menos que esta complejidad puede ser controlada. La modularidad es un concepto por el cual una pieza de software se agrupa en un nmero de subunidades distintas y lgicamente cohesivos, la presentacin de los servicios para el mundo exterior a travs de una interfaz bien definida. En trminos generales, los componentes de un mdulo se compartir el acceso a los datos comunes, y la interfaz proporcionar el acceso controlado a estos datos. El uso de la modularidad, se hace posible construir una aplicacin de software de forma incremental en una base fiable de cdigo antes de la prueba. Un beneficio adicional de un sistema modular bien definida es que los mdulos definidos dentro de ella pueden ser reutilizadas en el mismo o en otros proyectos, cortar drsticamente el tiempo de desarrollo mediante la reduccin tanto en el desarrollo y prueba de esfuerzo. En los ltimos aos, el desarrollo de los lenguajes de programacin orientados a objetos se ha incrementado en gran medida el apoyo lenguaje de programacin para el desarrollo del mdulo y la reutilizacin del cdigo. Estos lenguajes permiten al desarrollador definir "clases" (una unidad de modularidad) de objetos que se comportan de una manera controlada y bien definido. Tcnicas tales como la herencia - que permite a las partes de una interfaz existente a un objeto que cambiar - aumentar el potencial de reutilizacin al permitir que las clases predefinidas para ser adaptados o ampliados cuando los servicios que ofrecen no llegan a cumplir con el requisito del desarrollador. Si la modularidad y la reutilizacin del software es probable que sean los objetivos principales de los nuevos desarrollos de software, se debe prestar atencin a si las partes que componen un
Pgina414de670

TOGOF9.1
proyecto de arquitectura puede facilitar o prohibir el nivel deseado de la modularidad en las reas apropiadas.
Portabilidad
Software portabilidad - la capacidad de tomar un pedazo de software escrito en un entorno y hacer que se ejecute en otro - es importante en muchos proyectos, especialmente el desarrollo de productos. Se requiere que todos los aspectos de software y hardware de una Arquitectura Tecnolgica elegido (no slo la aplicacin de nuevo desarrollo) estarn disponibles en la nueva plataforma. Ser, por lo tanto, ser necesario para asegurar que las partes componentes de cualquier arquitectura elegida estn disponibles a travs de todas las plataformas de destino apropiadas.
Migracin e interoperabilidad
La interoperabilidad es siempre necesaria entre las partes componentes de una nueva arquitectura. Tambin podr, sin embargo, precisa entre una nueva arquitectura y las piezas de un sistema heredado existente; Por ejemplo, durante la sustitucin escalonada de un sistema antiguo. La interoperabilidad entre las nuevas y viejas arquitecturas puede, por lo tanto, ser un factor en la eleccin de la arquitectura.
Data-intensiva contra los sistemas de software de informacin-intensivos Lograr la interoperabilidad Niveles de software Usos de un nivel de acceso a datos Distribucin
Data-Intensive frente a los sistemas de software de informacin-intensivos
Este punto de vista considera dos categoras generales de sistemas de software. En primer lugar, estn los sistemas que requieren slo una interfaz de usuario a una base de datos, que requieren poco o nada de la lgica de negocio integrada en el software. Estos sistemas pueden ser llamados "uso intensivo de datos." En segundo lugar, estn los sistemas que requieren los usuarios manipular la informacin que pueda ser distribuido a travs de mltiples bases de datos, y para ello la manipulacin de acuerdo con un predefinido lgica de negocio. Estos sistemas se pueden llamar "informacin-intensiva" Sistemas de uso intensivo de datos se pueden construir con relativa facilidad mediante el uso de herramientas 4GL. En estos sistemas, la lgica de negocio est en la mente de los usuarios; es decir, el usuario entiende las reglas para la manipulacin de los datos y utiliza esas reglas mientras que hace su trabajo. Sistemas de informacin intensiva son diferentes. La informacin se define como "datos significativos"; es decir, los datos en un contexto que incluye la lgica de negocio.La informacin es diferente de datos. Los datos son las fichas que estn almacenados en bases de datos u otros almacenes de datos. La informacin es varias fichas de datos combinados para transmitir un
Pgina415de670

TOGOF9.1
mensaje. Por ejemplo, "3" son los datos, pero "3 widgets" es la informacin. Normalmente, la informacin refleja un modelo. Sistemas de informacin intensiva tambin tienden a requerir informacin de otros sistemas y, si este camino de la transmisin de informacin est automatizado, por lo general se requiere un poco de mediacin para convertir el formato de la informacin que llega a un formato que puede ser utilizado a nivel local. Debido a esto, los sistemas de informacin intensiva tienden a ser ms complejos que otros, y requieren el mximo esfuerzo para construir, integrar y mantener. Este punto de vista se ocupa principalmente de los sistemas de informacin intensiva. Adems de los sistemas que pueden manejar la informacin, a pesar de la construccin, los sistemas tambin deben ser lo ms flexible posible. Esto tiene una serie de beneficios. Se permite que el sistema para ser utilizado en diferentes entornos; por ejemplo, el mismo sistema debera pueda utilizarse con diferentes fuentes de datos, incluso si el nuevo almacn de datos es una configuracin diferente. Del mismo modo, podra tener sentido utilizar la misma funcionalidad pero con los usuarios que necesitan una interfaz de usuario diferente. As los sistemas de informacin deben ser construidos de manera que puedan ser reconfigurados con diferentes almacenes de datos o diferentes interfaces de usuario. Si un sistema est construido para permitir esto, permite a la empresa a las partes volver a utilizar (o componentes) de un sistema en otro.
El logro de la interoperabilidad
La palabra "interoperar" implica que un sistema de procesamiento realiza una operacin en nombre o bajo requerimiento de otro sistema de procesamiento. En la prctica, la peticin es una oracin completa que contiene un verbo (en funcionamiento) y uno o ms sustantivos (identidades de los recursos, donde los recursos pueden ser la informacin, datos, dispositivos fsicos, etc.) Interoperabilidad proviene de funcionalidad compartida. Interoperabilidad slo puede lograrse cuando se pasa informacin, no cuando se pasa de datos. La mayora de los sistemas de informacin de hoy en da reciben informacin tanto de sus propios almacenes de datos y otros sistemas de informacin. En algunos casos, la red de la conectividad entre los sistemas de informacin es bastante extensa. La Fuerza Area de EE.UU., por ejemplo, tiene un concepto conocido como "La interoperabilidad A5". Esto significa que los datos requeridos se encuentra disponible en cualquier momento y en cualquier lugar, por cualquier persona , que est autorizada, de cualquier manera. Esto requiere que muchos sistemas de informacin estn vinculados arquitectnicamente y proporcionan informacin a la otra. Tiene que haber algn tipo de conectividad fsica entre los sistemas. Esto podra ser una red de rea local (LAN), una red de rea amplia (WAN), o, en algunos casos, podra ser simplemente el paso de medios de almacenamiento de datos entre sistemas. Suponiendo una red conecta los sistemas, debe haber un acuerdo sobre los protocolos utilizados. Esto permite la transferencia de bits. Cuando los bits se ensamblan en el sistema de recepcin, que deben ser colocados en el contexto de que el sistema de recepcin debe. En otras palabras, tanto los sistemas de origen y de destino deben estar de acuerdo en un modelo de informacin. El sistema de origen utiliza este modelo para convertir su informacin en datos que se pasan, y el sistema de destino utiliza este mismo modelo para transformar los datos obtenidos en informacin que puede utilizar. Esto por lo general requiere de un acuerdo entre los arquitectos y diseadores de los dos sistemas. En el pasado, este acuerdo fue a menudo documentado en la forma de un Documento de Control de Interfaz (ICD). La CIE define la sintaxis y la semntica exacta de que el sistema de envo utilizar para que el sistema receptor sabr qu hacer cuando lleguen los datos. El mayor
Pgina416de670

TOGOF9.1
problema con los DCI es que tienden a ser soluciones nicas entre dos sistemas. Si un sistema dado debe compartir informacin con notros sistemas, existe la necesidad potencial de N 2 DAI. Esta integracin extremadamente apretado prohbe la flexibilidad y la capacidad de un sistema para adaptarse a un entorno cambiante. El mantenimiento de todos estos DAI es tambin un desafo. Las nuevas tecnologas, como el Extensible Markup Language (XML), tiene la promesa de hacer que los datos de "auto describe". uso de las nuevas tecnologas como XML, una vez que estn fiable y bien documentada, que podra eliminar la necesidad de un DAI. Adems, hay sera Comercial productos (COTS) disponibles para analizar y manipular los datos XML Off-The-Shelf, eliminando la necesidad de desarrollar estos productos en el local. Tambin debe aliviar el dolor de mantener todas las interfaces. Otro enfoque es la construccin de "mediadores" entre los sistemas. Los mediadores usaran metadatos que se enva con los datos para comprender la sintaxis y la semntica de los datos y convertirlos en un formato utilizable por el sistema receptor. Sin embargo, los mediadores no se requiere que se le enve metadatos bien formado, aadiendo a la complejidad de la interfaz.
Niveles de Software
Por lo general, las arquitecturas de software son un bien de dos niveles o de tres niveles. 2 Cada nivel se presenta tpicamente al menos una capacidad.
De dos niveles
En un dos -tier arquitectura, la interfaz de usuario y la lgica de negocio estn estrechamente acopladas mientras los datos se mantiene independiente. Esto le da la ventaja de permitir que los datos residen en un servidor de datos dedicado. Tambin permite que los datos se mantienen de forma independiente. El estrecho acoplamiento de la interfaz de usuario y la lgica de negocio a asegurar que van a trabajar bien juntos, para este problema en este mbito. Sin embargo, el estrecho acoplamiento de la interfaz de usuario y la lgica de negocio aumenta drsticamente los riesgos de mantenibilidad, mientras que la reduccin de la flexibilidad y oportunidades para su reutilizacin.
Three-Tier
Un enfoque de tres niveles, aade un nivel que separa la lgica de negocio de la interfaz de usuario. En principio, esto permite que la lgica de negocio para ser utilizado con diferentes interfaces de usuario, as como con diferentes almacenes de datos. Con respecto a la utilizacin de diferentes interfaces de usuario, los usuarios podran querer la misma interfaz de usuario, pero usando diferentes servidores de presentacin COTS; por ejemplo, Java Virtual Machine (JVM). Del mismo modo, si la lgica de negocio se va a utilizar con distintos almacenes de datos, a continuacin, cada almacn de datos debe utilizar el mismo modelo de datos 3 (estandarizacin de los datos), o un nivel de mediacin debe ser aadido por encima del almacn de datos (encapsulacin de datos).
Cinco Tier
Pgina417de670

TOGOF9.1
Para lograr la mxima flexibilidad, el software debera utilizar un esquema de cinco niveles para el software que ampla el paradigma de tres niveles (ver Figura 35-6 ). Este rgimen est destinado a proporcionar una fuerte separacin de las tres principales reas funcionales de la arquitectura. Puesto que hay de cliente y servidor aspectos tanto de la interfaz de usuario y el almacn de datos, el esquema a continuacin, tiene cinco niveles. 4 El nivel de presentacin es tpicamente basados en COTS. La interfaz de presentacin puede ser un servidor de X, Win32, etc No debe haber un nivel separado para el cliente de interfaz de usuario. Este cliente establece el look-and-feel de la interfaz; el servidor (capa de presentacin) en realidad lleva a cabo las tareas mediante la manipulacin de la pantalla. El cliente de interfaz de usuario oculta el servidor de presentacin de la lgica empresarial de la aplicacin. La lgica empresarial de la aplicacin (por ejemplo, un motor de programacin) debe ser un nivel separado. Este nivel se denomina "lgica de la aplicacin" y funciona como un servidor para el cliente de interfaz de usuario. Se conecta a la interfaz de usuario tpicamente a travs de devoluciones de llamada. La capa de lgica de aplicacin tambin funciona como un cliente para el nivel de acceso a datos. Si hay un usuario necesita utilizar una aplicacin con mltiples bases de datos con diferentes esquemas, entonces se necesita un nivel diferente para el acceso a datos.Este cliente podra acceder a los almacenes de datos utilizando la interfaz apropiada COTS 5 y luego convertir los datos en bruto en un tipo de datos abstracto que representa las partes del modelo de informacin. La interfaz de esta red sera entonces objeto proporcionar una interfaz de acceso a datos generalizada (DAI), que ocultar los detalles de almacenamiento de los datos de cualquier aplicacin que utilice esos datos. Cada nivel en este esquema puede tener cero o ms componentes. La organizacin de los componentes dentro de un nivel es flexible y puede reflejar un nmero de diferentes arquitecturas basadas en necesidad. Por ejemplo, puede haber muchos componentes diferentes en el nivel de aplicacin de la lgica (programacin, contabilidad, control de inventario, etc) y la relacin entre ellos puede consistir en una arquitectura tiene sentido, pero ninguno de ellos debe ser un cliente para el servidor de presentacin. Esta separacin limpia de interfaz de usuario, la lgica de negocio, y la informacin dar lugar a la mxima flexibilidad y el software en componentes que se presta a las prcticas de desarrollo lnea de productos. Por ejemplo, es concebible que la misma funcionalidad debe ser construido de una vez y sin embargo ser utilizable por diferentes servidores de presentacin (por ejemplo, en los ordenadores o cajas de sistema UNIX), que se muestran con un aspecto diferente y se siente en funcin de las necesidades del usuario, y se puede usar con mltiples bases de datos heredadas . Por otra parte, esta flexibilidad no debe requerir reescrituras masivas para el software cada vez que se necesita un cambio.
Pgina418de670

TOGOF9.1
Figura356:LaOrganizacindecinconiveles
Algunos usos de un nivel de acceso a datos
El nivel de acceso a datos proporciona una vista estandarizada de ciertas clases de datos, y como tal funciona como un servidor para uno o ms niveles lgica de la aplicacin. Si se aplica correctamente, no habra necesidad de que el cdigo de aplicacin "saber" acerca de los detalles de implementacin de los datos. El cdigo de la aplicacin slo tendra que saber acerca de una interfaz que presenta un nivel de abstraccin superior a los datos. Esta interfaz se denomina interfaz de acceso a datos (DAI). Por ejemplo, en caso de necesitar un motor de programacin para saber qu eventos estn programados entre dos fechas, dicha consulta no debera requerir el conocimiento de tablas y combinaciones en una base de datos relacional. Por otra parte, el DAI podra proporcionar tcnicas de acceso estandarizados para los datos. Por ejemplo, el DAI podra proporcionar una publicacin y suscripcin (P & S) de interfaz mediante el cual los sistemas que requieren el acceso a almacenes de datos podra registrar un inters en ciertos tipos de datos, tal vez, en determinadas condiciones, y el DAI podra proporcionar los datos requeridos cuando se producen esas condiciones .
Una posible instanciacin de un DAI
Uno de los medios para crear una instancia de un componente de acceso de datos es con tres capas, como se muestra en la Figura 35-7 . Este no es el nico medio para construir un DAI, pero se presenta como una posibilidad.
Pgina419de670

TOGOF9.1
Figura357:DataAccessInterface(DAI)
Mientras que la capa de acceso a datos directo contiene los detalles de implementacin de uno o varios almacenes de datos, la Red de objetos y la capa de Distribucin de la Informacin no requieren de tal conocimiento. En cambio, las dos capas superiores reflejan la necesidad de estandarizar la interfaz de un dominio determinado. La capa de acceso a datos directo extiende la brecha entre el nivel de acceso a datos y el nivel de almacn de datos, y por lo tanto tiene conocimiento de los detalles de implementacin de los datos. SQL declaraciones, ya sea incrustadas oa travs de una norma como la DRDA u ODBC, se encuentran aqu. La capa de red del objeto es la creacin de instancias de software del modelo de informacin. Como tal, es un medio eficaz para mostrar las relaciones que se dan entre piezas de datos. La traduccin de los datos de los accesos a los objetos de la red sera la funcin de la capa de acceso a datos directo. Dentro de la capa de Distribucin de la Informacin se encuentra la interfaz con el "mundo exterior". Esta interfaz normalmente utiliza un bus de datos para distribuir los datos (vase ms adelante). 6 Tambin podra contener diversos servicios relacionados con la informacin; Por ejemplo, un registro de P & S y servicio de publicacin o una interfaz a un servidor de seguridad para el control de acceso a datos. 7 la capa de informacin de distribucin pueden tambin ser usados para distribuir aplicaciones o applets requeridos para procesar informacin distribuida. Los objetos en la red objeto sealaran las aplicaciones o applets, lo que permite un fcil acceso al cdigo de procesamiento requerido.
IAA Habilitar Flexibilidad
El DAI permite una arquitectura muy flexible. Capacidades primas mltiples pueden acceder a los mismos o diferentes almacenes de datos, todo a travs de la misma DAI.Cada DAI podra implementarse de muchas maneras, de acuerdo a las necesidades especficas de las capacidades de primas que lo usan. Figura 35-8 ilustra una serie de posibilidades, incluyendo mltiples IAA diferentes en diferentes mbitos con el acceso a la misma base de datos, un nico DAI acceder a mltiples bases de datos, y varias instancias de la misma DAI acceden a la misma base de datos.
Pgina420de670

TOGOF9.1
No siempre est claro que se necesita un DAI, y que parece requerir un trabajo adicional durante todas las fases de desarrollo. Sin embargo, si una base de datos cada vez ser rediseado, o si una aplicacin se va a volver a utilizar y no hay ningn control sobre cmo se implementa la nueva informacin, el uso de un DAI ahorra tiempo en el largo plazo.
Figura358:usosmltiplesdeunainterfazdeaccesoadatos(IAA)
Distribucin
El modelo de referencia ISO para el procesamiento distribuido abierto (RM-ODP) ofrece un metaestndar que se pretende permitir normas ms especficas que surjan.Define el modelo de referencia de RM-ODP un conjunto de transparencias de distribucin que sean aplicables a la vista TOGAF Software Engineering. Acceso Transparencia mscaras diferencias en la representacin de datos y los mecanismos de invocacin para permitir el interfuncionamiento entre objetos. Esta transparencia resuelve muchos de los problemas de interfuncionamiento entre sistemas heterogneos, y por lo general se proporciona de forma predeterminada. Transparencia El incumplimiento mscaras de un objeto del fracaso y la posible recuperacin de otros objetos (o s) para permitir la tolerancia a fallos. Cuando se proporciona esta transparencia, el diseador puede trabajar en un mundo idealizado en el que no se produce la clase correspondiente de fracasos. Ubicacin Transparencia enmascara el uso de la informacin sobre la ubicacin en el espacio cuando la identificacin y unin a las interfaces. Esta transparencia proporciona una vista lgica de nombrar, independientemente de la ubicacin fsica real. Transparencia Migracin mscaras de un objeto de la capacidad de un sistema para cambiar la ubicacin de ese objeto. La migracin se utiliza a menudo para alcanzar el equilibrio de carga y reducir la latencia. Transparencia Reubicacin mscaras reubicacin de una interfaz de otras interfaces asociadas a la misma. Reubicacin permite la operacin del sistema para continuar incluso cuando la migracin o el reemplazo de algunos objetos crea inconsistencias temporales en la vista visto por sus usuarios.
Pgina421de670

TOGOF9.1
Transparencia de replicacin enmascara el uso de un grupo de objetos mutuamente compatibles conductualmente para sustentar una interfaz. replicacin se utiliza a menudo para mejorar el rendimiento y la disponibilidad. Transparencia Transaccin mscaras de coordinacin de las actividades entre una configuracin de los objetos para lograr consistencia.
Bus Infraestructura
El bus de la infraestructura representa el middleware que establece la relacin de cliente / servidor. Este software comercial es como un plano posterior en la que las capacidades se pueden conectar. Un sistema debe cumplir con una aplicacin comercial de un estndar middleware. Esto es para asegurar que las capacidades utilizando diferentes implementaciones comerciales de la norma pueden interoperar. Si se utiliza ms de una norma comercial (por ejemplo, COM y CORBA), entonces el sistema debe permitir la interoperabilidad entre las implementaciones de estos estndares a travs del uso de software de puente comercial. 8 Cuando sea posible, las interfaces deben ser especificados en la adecuada descripcin de la interfaz Idioma (IDL). Tomado de esta forma, todas las interfaces en el esquema de cinco niveles representa una oportunidad para su distribucin. Los clientes pueden interactuar con los servidores a travs del bus de la infraestructura. En esta interaccin, el transporte real de la red (TCP / IP, HTTP, etc), la plataforma / proveedor del servidor y del sistema operativo del servidor son todos transparentes.
Pgina422de670

TOGOF9.1 Figura359:nocionalModelodeDistribucin
35.7.3.3 Conclusin
La vista de la Ingeniera de Software proporciona orientacin sobre la forma de estructurar el software de una manera muy flexible. Siguiendo estas pautas, el software resultante ser por componentes. Esto permite la reutilizacin de los componentes en diferentes entornos. Por otra parte, mediante el uso de un bus de infraestructura y las interfaces limpias, el software resultante ser independiente de la ubicacin, lo que permite su distribucin a travs de una red.
35.7.4 Desarrollo de un sistema de ingeniera Ver

El punto de vista de Ingeniera de Sistemas se ocupa de reunir software y componentes de hardware en un sistema de trabajo.
Este punto de vista se debe desarrollar para el personal de ingeniera de sistemas del sistema, y debe centrarse en cmo se implementa el sistema desde el punto de vista de hardware / software y redes. Los ingenieros de sistemas estn normalmente preocupados por la ubicacin, modificabilidad, reusabilidad y la disponibilidad de todos los componentes del sistema. El punto de vista de Ingeniera de Sistemas presenta un nmero de diferentes formas en que los componentes de software y hardware se puede montar en un sistema de trabajo. En gran medida, la eleccin del modelo determina las propiedades del sistema final. Se ve en la tecnologa que ya existe en la organizacin, y lo que est disponible en la actualidad o en un futuro prximo. Esto revela reas en las que las nuevas tecnologas pueden contribuir a la funcin o la eficiencia de la nueva arquitectura, y cmo los diferentes tipos de procesamiento de la plataforma puede soportar diferentes partes del sistema en general. Las principales preocupaciones de este punto de vista son la comprensin de los requisitos del sistema. En general, estos grupos de inters tienen que ver con garantizar que los componentes adecuados se desarrollan y despliegan dentro del sistema de una manera ptima. El desarrollo de este punto de vista ayuda en la seleccin de las mejores configuraciones para el sistema.
Este punto de vista de la arquitectura se centra en los modelos de computacin que son apropiados para un entorno de computacin distribuida. Para apoyar la migracin de sistemas heredados, esta seccin tambin presenta modelos que son apropiados para un entorno centralizado. Las definiciones de muchos de los modelos de computacin (por ejemplo, basado en host, maestro / esclavo, y de tres niveles) histricamente precedieron a la definicin del modelo de cliente / servidor, que trata de ser un modelo de propsito general. En la mayora de los casos, los modelos no se han redefinido en la literatura informtica en trminos de contrastes con el modelo cliente / servidor. Por lo tanto, algunas de las distinciones de caractersticas no siempre estn limpios. En general, sin embargo, los modelos se distinguen por la asignacin de funciones para una aplicacin de sistema de informacin a los distintos componentes (por ejemplo, terminales,
Pgina423de670

TOGOF9.1
plataformas de computacin). Estas funciones que componen una aplicacin de sistema de informacin son la presentacin, la funcin de la aplicacin y gestin de datos.
Modelo cliente / servidor
Figura3510:BsicoModeloCliente/Servidor
Procesamiento cliente / servidor es un tipo especial de computacin distribuida denominado "proceso cooperativo", porque los clientes y servidores cooperan en el procesamiento de una aplicacin total de (presentacin, procesamiento funcional, datos de gestin). En el modelo, los clientes son procesos que solicitan servicios y servidores son procesos que proporcionan servicios. Los clientes y los servidores pueden estar ubicados en el mismo procesador, diferentes nodos multi-procesador, o en procesadores separados en ubicaciones remotas. El cliente normalmente inicia las comunicaciones con el servidor. El servidor normalmente no inicia una peticin de un cliente. Un servidor puede soportar muchos clientes y puede actuar como un cliente a otro servidor. Figura 35-10 muestra un modelo cliente / servidor de base, que hace hincapi en las relaciones de solicitud-respuesta. Figura 35-11 muestra el mismo tipo elaborado siguiendo el TOGAF TRM, mostrando cmo las diversas entidades e interfaces se pueden utilizar para soportar un modelo de cliente / servidor, si el servidor es local o remoto para el cliente. En estas representaciones, las relaciones de solicitud-respuesta se definiran en el API.
Pgina424de670

TOGOF9.1
Figura3511:ReferenciaModeloRepresentacindemodelodecliente/servidor
Los clientes tienden a generalizarse y pueden ejecutarse en uno de los muchos nodos. Los servidores suelen estar especializados y se ejecutan en un par de nodos. Los clientes suelen implementarse como una llamada a una rutina. Los servidores se implementan normalmente como un proceso continuo a la espera de las solicitudes de servicio (de los clientes). Muchas implementaciones de cliente / servidor implican comunicaciones remotas a travs de una red. Sin embargo, nada en el modelo cliente / servidor dicta comunicaciones remotas, y la ubicacin fsica de los clientes es normalmente transparente para el servidor. La comunicacin entre un cliente y un servidor puede implicar una comunicacin local entre dos procesos independientes en la misma mquina. Un programa de aplicacin se puede considerar que constar de tres partes: El manejo de datos Funcin de aplicacin Presentacin
En general, cada uno de ellos puede ser asignado a un cliente o aplicacin de servidor, haciendo un uso adecuado de los servicios de la plataforma. Esta asignacin define una configuracin especfica de cliente / servidor.
Master / Slave y Modelos Jerrquicos
En este modelo, los ordenadores esclavos estn conectados a un ordenador central. En cuanto a la distribucin, el modelo maestro / esclavo es un paso adelante respecto al modelo basado en host. La distribucin se proporciona en una sola direccin - del maestro a los esclavos. Los ordenadores esclavos realizan la tramitacin del expediente slo cuando es dirigido por el equipo maestro. Adems, los procesadores esclavos pueden realizar el procesamiento local limitado, tales como la edicin, procesamiento de tecla de funcin y la validacin del campo. Una configuracin
Pgina425de670

TOGOF9.1
tpica podra ser una unidad central como el maestro con los PC como los esclavos que actan como terminales inteligentes, como se ilustra en la figura 35-12 . El modelo jerrquico es una extensin del modelo maestro / esclavo con ms capacidades de distribucin. En este enfoque, la capa superior es generalmente un mainframe de gran alcance, que acta como un servidor para el segundo nivel. La segunda capa consiste en servidores y clientes de la LAN a la primera capa, as como servidores de la tercera capa. La tercera capa consiste en PCs y estaciones de trabajo. Este modelo ha sido descrita como la adicin de un verdadero procesamiento distribuido en el modelo maestro / esclavo. Figura 35-12 muestra un ejemplo modelo jerrquico en la tercera configuracin, y por debajo, la figura 35-13 muestra el modelo jerrquico representado en trminos de las entidades e interfaces de la TRM.
Figura3512:HostBased,Master/SlaveyModelosJerrquicos
Pgina426de670

TOGOF9.1
Figura3513:Modelojerrquicoutilizandoelmodelodereferencia
Modelo Peer-to-Peer
En el modelo peer-to-peer existen procesos de coordinacin. Todos los equipos son servidores que puedan recibir las solicitudes de servicios y responder a ellos; y todos los equipos son clientes, ya que pueden enviar solicitudes de servicios a otras computadoras. En las implementaciones actuales, a menudo hay funciones redundantes en las plataformas participantes. Se han hecho intentos para implementar el modelo de los sistemas de bases de datos heterogneas (o federados) distribuidos. Este modelo podra ser considerado como un caso especial del modelo de cliente / servidor, en el que todas las plataformas son servidores y clientes. Figura 35-14 (A) muestra un ejemplo de configuracin del par-a-par en el que todas las plataformas tienen funciones completas.
Pgina427de670

TOGOF9.1
Figura3514:PeertoPeerydistribuidosModelosdeGestindeobjetos
Distribuido Modelo de Gestin de Objetos
En este modelo, el procedimiento remoto llamadas Se utiliza normalmente para la comunicacin en el cliente / servidor y otros modelos de procesamiento distribuido son reemplazados por los mensajes enviados a los objetos. Los servicios prestados por los sistemas en una red son tratados como objetos. . Un solicitante no necesita conocer los detalles de cmo se configura el objeto El enfoque requiere: Un mecanismo para enviar mensajes
Pgina428de670

TOGOF9.1
Un mecanismo para coordinar la entrega de los mensajes Las aplicaciones y servicios que soportan una interfaz de mensajera
Este enfoque no contrasta con el cliente / servidor o modelos de peer-to-peer, pero especifica una interfaz consistente para la comunicacin entre plataformas de co-operacin. Es considerado por algunos como un enfoque de implementacin de cliente / servidor y modelos peer-to-peer. Figura 35-14 presenta dos ejemplos de modelos de objetos distribuidos. Ejemplo B muestra cmo se alterara una configuracin cliente / servidor para dar cabida al modelo de gestin de objetos distribuidos. Ejemplo C muestra cmo se vera alterada un modelo peer-to-peer para llevar a cabo la gestin de objetos distribuidos. El Object Management Group (OMG), un consorcio de participantes de la industria que trabajan hacia los estndares de objeto, se ha desarrollado una arquitectura - Common Object Request Broker Architecture (CORBA) - que especifica el protocolo de una aplicacin de cliente debe utilizar para comunicarse con un intermediario de solicitud de objetos ( ORB), que presta servicios. El ORB especifica cmo los objetos de manera transparente pueden hacer peticiones y recibir respuestas. Adems, Object Linking de Microsoft e incrustacin de objetos (OLE) estndar para Windows es un ejemplo de una aplicacin de gestin de objetos distribuidos, por lo que cualquier aplicacin compatible con OLE puede trabajar con datos de cualquier otra aplicacin compatible con OLE.
35.7.5 Desarrollo de un Comunicaciones Ingeniera View

La vista de la Ingeniera de Comunicaciones se ocupa de las comunicaciones de estructuracin y elementos de red para simplificar la planificacin y diseo de la red.
Este punto de vista debe ser desarrollado para las comunicaciones del personal de ingeniera del sistema, y debe centrarse en cmo se implementa el sistema desde la perspectiva del ingeniero de comunicaciones. Ingenieros de comunicaciones son tpicamente preocupado por la ubicacin, modificabilidad, reusabilidad y la disponibilidad de servicios de comunicaciones y redes. Las principales preocupaciones de este punto de vista son la comprensin de los requisitos de comunicaciones de red y. En general, estos grupos de inters tienen que ver con garantizar que las correspondientes comunicaciones y los servicios de redes se desarrollan y despliegan dentro del sistema de una manera ptima. El desarrollo de este punto de vista ayuda en la seleccin de la mejor modelo de comunicaciones para el sistema.
Las redes de comunicaciones se construyen de dispositivos finales (por ejemplo, impresoras), nodos de procesamiento, los nodos de comunicacin (elementos de conmutacin), y los medios de comunicacin de enlace que los conectan. La red de comunicaciones proporciona los medios por los cuales se intercambia informacin. Las formas de informacin incluyen datos, imgenes, voz y video. Dado que los sistemas de informacin automatizados aceptan y procesan la informacin usando los formatos de datos digitales en lugar de los formatos analgicos, los conceptos de
Pgina429de670

TOGOF9.1
comunicacin TOGAF y orientacin se centrar en las redes digitales y los servicios digitales.Servicios multimedia integrados estn incluidos. La vista de la Ingeniera de Comunicaciones se describe la arquitectura de comunicaciones con respecto a la geografa, se analiza el modelo de referencia de interconexin de sistemas abiertos (OSI), y describe un marco general destinado a permitir el anlisis de sistemas eficaces y planificacin.
Infraestructura de comunicaciones
La infraestructura de comunicaciones puede contener hasta tres niveles de transporte - local, regional / metropolitano, y global - como se muestra en la Figura 35-15 . Los nombres de los componentes de transporte se basan en su respectivo mbito geogrfico, pero tambin existe una relacin jerrquica entre ellos. Los componentes de transporte corresponden a una estructura de gestin de la red en la que la gestin y el control de los recursos de red se distribuyen a travs de los diferentes niveles. Los componentes locales se refieren a los activos que se encuentran relativamente cerca geogrficamente. Este componente contiene equipos de comunicaciones fijas y pequeas unidades de equipos de comunicaciones mviles. LAN, a la que se conectar la mayora de los dispositivos finales, estn incluidos en este componente. Las interfaces estndar facilitar la portabilidad, flexibilidad e interoperabilidad de las redes LAN y dispositivos finales. Redes de rea metropolitana (MAN) Regional y estn geogrficamente dispersos en una gran superficie. Una red regional o metropolitano podra conectar componentes locales en varias bases fijas o conectarse puestos remotos separados. En la mayora de los casos, las redes regionales y metropolitanas se utilizan para conectar redes locales. Sin embargo, las bases de datos compartidas, plataformas regionales de procesamiento y centros de gestin de red pueden conectarse directamente oa travs de una red LAN. Las interfaces estndar sern proporcionados para conectar redes locales y dispositivos finales. Redes de rea Global o amplia (WAN) se encuentran en todo el mundo, proporcionando conectividad a las redes regionales y metropolitanas en el entorno fijo y desplegado.Adems, unidades mviles, bases de datos compartidas, y centros de procesamiento central se pueden conectar directamente a la red mundial, como se requiera. Las interfaces estndar sern proporcionados para conectar las redes regionales y metropolitanas y los dispositivos finales.
Pgina430de670

TOGOF9.1
Figura3515:Infraestructuradecomunicaciones
Comunicaciones Modelos
La infraestructura geogrficamente dividido descrito anteriormente es la base de un marco global de comunicaciones. Estas divisiones geogrficas permiten la aplicacin por separado de las diferentes responsabilidades de gestin, las actividades de planificacin, las funciones operacionales y tecnologas de apoyo que deben aplicarse en cada rea. Componentes y servicios de hardware y software instalados en el marco forman el modelo completo. Los siguientes puntos se describe el modelo de referencia OSI y una agrupacin de las capas OSI que facilita la discusin de los problemas de interoperabilidad.
El modelo de referencia OSI
La interconexin de sistemas abiertos (OSI) Modelo de referencia, representada en la figura 3516 , es el modelo utilizado para las comunicaciones de datos en TOGAF.Cada una de las siete capas del modelo representa uno o ms servicios o protocolos (un conjunto de normas que regulan las comunicaciones entre sistemas), que definen la operacin funcional de las comunicaciones entre los usuarios y los elementos de red. Cada capa (con la excepcin de la capa superior)
Pgina431de670

TOGOF9.1
proporciona servicios para la capa por encima de ella. Este modelo tiene por objeto establecer el funcionamiento de sistemas abiertos e implica la implementacin basada en estndares. Se esfuerza para permitir diferentes sistemas para llevar a cabo la interoperabilidad completa y la calidad de funcionamiento en toda la red. Las siete capas del modelo OSI estn estructurados para facilitar el desarrollo independiente dentro de cada capa y para proporcionar cambios independientes de otras capas. Protocolos estndares internacionales estables en conformidad con las definiciones de capas OSI modelo de referencia han sido publicadas por diversos organismos de normalizacin. Esto no quiere decir que los nicos protocolos que se ajustan en TOGAF son protocolos OSI. Otras normas de protocolo, como SNA o TCP / IP se pueden describir utilizando el modelo de capas OSI de siete como referencia. Soporte y reas de negocio de aplicaciones, tal como se define en TOGAF, estn por encima de la pila de protocolos modelo de referencia OSI y el uso de sus servicios a travs de la capa de aplicaciones.
Marco de comunicaciones
Un sistema de comunicaciones basado en el modelo de referencia OSI incluye los servicios en todas las capas pertinentes, el apoyo y el software de aplicacin de rea de negocio que se encuentra por encima de la capa de aplicacin del modelo de referencia OSI y el equipo fsico que lleva los datos. Estos elementos se pueden agrupar en niveles arquitectnicos que representan las principales capacidades funcionales, tales como la conmutacin y el enrutamiento, la transferencia de datos y el rendimiento de las aplicaciones.
Figura3516:modelodereferenciaOSI Pgina432de670

TOGOF9.1
Estos niveles arquitectnicos son: El nivel de transmisin (por debajo de la capa fsica del modelo de referencia OSI) proporciona todas las capacidades fsicas y electrnicas, las cuales establecen una ruta de transmisin entre los elementos funcionales del sistema (cables, circuitos arrendados, interconexiones, etc.) La red de conmutacin de nivel (capas OSI 1 a 3), establece la conectividad a travs de los elementos de la red para soportar el encaminamiento y control del trfico (interruptores, controladores, software de red, etc.) El nivel de intercambio de datos (capas OSI 4 a 7) lleva a cabo la transferencia de la informacin despus de que la red se ha establecido (de extremo a extremo, la transferencia de usuario a usuario) que incluye elementos ms capaces de procesamiento (hosts, estaciones de trabajo, servidores, etc ). En el TRM, servicios de la capa de aplicacin OSI se consideran parte de la entidad plataforma de aplicaciones, ya que ofrecen interfaces estandarizadas a la entidad de programacin de aplicaciones. El nivel del Programa de Aplicaciones (por encima de la OSI) incluye el apoyo y aplicaciones en reas de negocios (programas de aplicacin no de gestin).
El marco de las comunicaciones se define para consistir en los tres componentes geogrficos de la infraestructura de comunicaciones (local, regional y global) y los cuatro niveles de la arquitectura (Programa de Aplicaciones de transmisin, conmutacin de red, intercambio de datos, y), y se representa en la figura 35 - 17 . Los servicios de comunicaciones se llevan a cabo en uno o ms de estos niveles de la arquitectura dentro de los componentes geogrficos. Figura 35-17 muestra computacin elementos (que operan a nivel de programa de aplicaciones) con el apoyo a elementos de intercambio de datos, vinculados entre s a travs de diversos elementos de conmutacin (que funcionan a la Nivel de conmutacin de red), cada uno situado dentro de su respectivo componente geogrfico. Figura 35-17 tambin identifica la relacin de TOGAF a la arquitectura de comunicacin.
Pgina433de670

TOGOF9.1
Figura3517:Marcodecomunicaciones
Asignacin de Servicios a Componentes
La infraestructura de comunicaciones consta de los componentes de transporte local, regional y global. Los servicios destinados a estos componentes son idnticos a los servicios del programa de aplicacin, el intercambio de datos, conmutacin de red, o los niveles de arquitectura de transmisin que se aplican a un componente. Intercambio de datos y servicios de nivel de conmutacin de red son idnticos a los servicios de las correspondientes capas de modelo de referencia OSI. Normalmente, slo conmutacin de redes y servicios de transmisin se asignan a los componentes regionales y globales, que consisten en nodos de comunicacin y medios de transmisin. Todos los servicios se pueden realizar en el componente local, que incluye los dispositivos finales, nodos de procesamiento, nodos de comunicaciones, y los medios de comunicacin de enlace. Transporte, transformacin, transporte y aplicaciones son todas realizadas en este componente.
35.7.6 Desarrollo de un Vista de flujo de datos

El punto de vista de flujo de datos se refiere a almacenamiento, recuperacin, procesamiento, archivo y seguridad de los datos.
Pgina434de670

TOGOF9.1
Este punto de vista se debe desarrollar para los ingenieros de bases de datos del sistema. Las principales preocupaciones de este punto de vista son la comprensin de cmo proporcionar datos a las personas adecuadas y las aplicaciones con las interfaces adecuadas en el momento adecuado. Esta visin se refiere a la arquitectura del almacenamiento, recuperacin, procesamiento, archivo y seguridad de los datos. Se ve en el flujo de datos a medida que se almacena y se procesa, y en qu se requerir componentes para apoyar y gestionar tanto el almacenamiento y el procesamiento. En general, estos grupos de inters tienen que ver con garantizar el acceso ubicuo a la informacin de alta calidad.
Los temas de la arquitectura general de un "sistema de base de datos" son componentes de base de datos o componentes que proporcionan servicios de bases de datos. El modelado de una "base de datos" se suele hacer con los diagramas de entidad-relacin y definiciones de esquema, incluyendo las definiciones de tipo de documento.
. Servicios de gestin de datos pueden ser proporcionados por una amplia gama de implementaciones Algunos ejemplos son: Las mega-centros que proporcionan las bases de datos corporativas orientacin funcional de apoyo a las necesidades de datos locales y remotas DBMS distribuido que apoyan el uso interactivo de las bases de datos con particiones y parcialmente replicados Los sistemas de archivos proporcionados por los sistemas operativos, los cuales pueden ser utilizados por las aplicaciones de procesamiento tanto interactivos y por lotes
Servicios de gestin de datos incluyen el almacenamiento, la recuperacin, la manipulacin, la copia de seguridad, reinicio / recuperacin, seguridad y funciones asociadas para texto, datos numricos y de datos complejos, tales como documentos, grficos, imgenes, audio y video. El sistema operativo proporciona servicios de gestin de archivos, pero que se consideran aqu porque existen muchas bases de datos de legado como uno o ms archivos, sin los servicios de un DBMS. Los componentes principales que ofrecen servicios de gestin de datos que se describen en esta seccin son: Sistemas de gestin de bases de datos (ver Sistemas de gestin de bases de datos ) Diccionario de Datos / Sistemas de directorios (ver diccionario de datos / Directory Systems ) Administracin de datos (en la administracin de datos )
Pgina435de670

TOGOF9.1
Seguridad de los datos (ver Seguridad de Datos )
Estos son los aspectos crticos de la gestin de datos por las siguientes razones. El DBMS es el componente ms crtico de cualquier capacidad de gestin de datos, y un sistema / directorio de diccionario de datos es necesario en colaboracin con el DBMS como una herramienta para ayudar a la administracin de la base de datos.Seguridad de los datos es una parte necesaria de toda poltica global para la seguridad en el procesamiento de informacin.
Sistemas de Gestin de Base de Datos
Un sistema de gestin de bases de datos (DBMS) prev la gestin sistemtica de los datos. . Este componente de gestin de datos proporciona servicios y capacidades para la definicin de los datos, la estructuracin de los datos, acceder a los datos, as como la seguridad y la recuperacin de los datos Un DBMS realiza las siguientes funciones: Estructuras de datos de una manera coherente Proporciona acceso a los datos Minimiza la duplicacin Permite reorganizacin; es decir, cambios en el contenido de los datos, estructura, y el tamao Soporta las interfaces de programacin Proporciona seguridad y control
Un DBMS debe proporcionar: Persistencia; los datos siguen existiendo despus de la ejecucin de la aplicacin se ha completado Gestin de almacenamiento secundario Concurrencia Recuperacin Definicin de Datos / Data Manipulation Language (DDL / DML), que puede ser una interfaz grfica
Base de datos Modelos
El modelo de datos lgica que subyace a la base de datos que caracteriza a un DBMS. Los modelos de datos lgicos comunes son las siguientes: Modelo Relacional : Un sistema de gestin de base de datos relacional de datos (RDBMS) estructuras en tablas que tienen ciertas propiedades: o Cada fila de la tabla es distinta de cada dos filas.
Pgina436de670

TOGOF9.1
o Cada fila contiene slo datos atmicos; es decir, no hay datos de repeticin o estructuras tales como matrices. Cada columna de la tabla relacional define campos o atributos de datos con nombre.
Una coleccin de tablas relacionadas en el modelo relacional constituye una base de datos. La teora matemtica de las relaciones subyace en el modelo relacional - tanto a la organizacin de los datos y los lenguajes que manipulan los datos. Edgar Codd, a continuacin, en IBM, ha desarrollado el modelo relacional en 1973. Ha sido popular, en trminos de uso comercial, desde principios de 1980. Modelo Jerrquico : El modelo de datos jerrquico organiza los datos en una estructura de rbol. Hay una jerarqua de segmentos de padres y de datos de nios.Esta estructura implica que un registro puede haber repeticin de la informacin, en general, en los segmentos de datos secundarios. Por ejemplo, una organizacin puede almacenar informacin sobre un empleado, como nombre, nmero de empleado, departamento, salario. La organizacin tambin puede almacenar informacin acerca de los nios de un empleado, como nombre y fecha de nacimiento. Los datos de los empleados y los nios forman una jerarqua, donde los datos de empleado representa el segmento de los padres y de los datos de los nios representa el segmento infantil. Si un empleado tiene tres hijos, entonces no habra tres segmentos secundarios asociados con un segmento de los empleados. En una base de datos jerrquica de la relacin padre-hijo es uno-amuchos. Esto restringe un segmento nio a tener slo un segmento de matriz. DBMS jerrquicos fueron populares desde finales de 1960, con la introduccin del Sistema de Gestin de la Informacin de IBM (IMS) DBMS, a travs de la dcada de 1970. Modelo de la Red : La popularidad del modelo de datos de la red coincide con la popularidad del modelo de datos jerrquico. Algunos datos se modelan de forma ms natural con ms de un padre por nio. As, el modelo de red permite el modelado de muchos-a-muchos en los datos. En 1971, la Conferencia sobre Sistemas de Datos Idiomas (CODASYL) define formalmente el modelo de red. La construccin bsica de modelado de datos en el modelo de red es la construccin de conjunto.Un conjunto consiste en un tipo de propietario registro, un nombre de conjunto, y un tipo de registro miembro. Un tipo de registro miembro puede tener ese papel en ms de un conjunto, de ah el concepto multipadre es compatible. Un tipo de registro propietario tambin puede ser miembro o propietario en otro conjunto. El modelo de red CODASYL se basa en la teora matemtica de conjuntos. Orientada a objetos Modelo : Un sistema de gestin de base de datos orientada a objetos (SGBDOO) debe ser a la vez un DBMS y un sistema orientado a objetos. Como DBMS debe proporcionar las capacidades identificadas anteriormente. OODBMS normalmente puede modelar datos tabulares, datos complejos, datos jerrquicos, y las redes de datos. Las siguientes son caractersticas importantes de un sistema orientado a objetos: o Los objetos complejos: por ejemplo, los objetos pueden estar compuestos de otros objetos. Objeto de identidad: cada objeto tiene un identificador nico externo a los datos. Encapsulacin: un objeto consta de datos y los programas (o mtodos) que manipularlo.
o o
Pgina437de670

TOGOF9.1
o o o Tipos o clases: una clase es una coleccin de objetos similares. Herencia: subclases heredan los atributos y los mtodos de las clases de datos. Reemplazar con el enlace en tiempo: el mtodo particular de una subclase puede reemplazar el mtodo de una clase en tiempo de ejecucin. Extensibilidad: por ejemplo, un usuario puede definir nuevos objetos. Completitud computacional: un lenguaje de propsito general (tal como Ada, C o C + +) es computacionalmente completa. El lenguaje SQL de propsito especial no lo es. La mayora de OODBMS incorporan un lenguaje de programacin de propsito general.
o o
Archivos planos : Un sistema de archivos planos est estrechamente asociada con un mtodo de acceso de almacenamiento. Un ejemplo es el mtodo de acceso secuencial indizado de IBM (ISAM). Los modelos analizados anteriormente en esta seccin son modelos de datos lgicos; archivos planos requieren que el usuario trabajar con la disposicin fsica de los datos en un dispositivo de almacenamiento. Por ejemplo, el usuario debe conocer la ubicacin exacta de un elemento de datos en un registro. Adems, los archivos planos no proporcionan todos los servicios de un DBMS, tales como la designacin de los datos, la eliminacin de la redundancia y control de concurrencia. Adems, no hay independencia de los datos y el programa de aplicacin. El programa de aplicacin debe conocer la disposicin fsica de los datos.
SGBD Distribuidos
Un DBMS distribuido gestiona una base de datos que se extiende sobre ms de una plataforma. La base de datos puede basarse en cualquiera de los modelos de datos mencionados anteriormente (excepto el archivo plano). La base de datos puede ser replicado, particiones, o una combinacin de ambos. Una base de datos replicada es una en la que existen copias completas o parciales de la base de datos en las diferentes plataformas. Una base de datos particionada es una en la que parte de la base de datos es en una plataforma y partes son en otras plataformas. La particin de una base de datos puede ser vertical u horizontal. Una particin vertical pone algunos campos y los datos asociados en una sola plataforma y algunos campos y los datos asociados en otra plataforma. Por ejemplo, considere una base de datos con los siguientes campos: identificacin de empleado, nombre del empleado, departamento, nmero de dependientes, proyecto asignado, tasa de salario, impuesto tasa. Una particin vertical podra colocar la identificacin del empleado, nmero de dependientes, la tasa de salario y tasa de impuestos en una plataforma y el nombre del empleado, departamento y proyecto asignado en otra plataforma. Una particin horizontal puede mantener todos los campos en todas las plataformas, pero la distribucin de los registros. Por ejemplo, una base de datos con 100.000 registros podra poner los primeros 50.000 registros en una plataforma y los segundos 50.000 registros en una segunda plataforma. Si la base de datos distribuida se replica o se reparti, un nico DBMS gestiona la base de datos. Hay un nico esquema (descripcin de los datos en una base de datos en trminos de un modelo de datos; por ejemplo, relacional) para una base de datos distribuida. La distribucin de la base de datos es generalmente transparente para el usuario. El trmino "DBMS distribuido" implica homogeneidad.
Distribuidos Heterogneos DBMS
Pgina438de670

TOGOF9.1
Un sistema distribuido de bases de datos heterogneas es un conjunto de bases de datos independientes, cada uno con sus propios DBMS, presenta a los usuarios como una nica base de datos y sistema. "Federados" se utiliza como sinnimo de "distribuido heterogneo". La heterogeneidad se refiere a las diferencias en los modelos de datos (por ejemplo, de la red y relacionales), los DBMS de diferentes proveedores, plataformas de hardware diferentes, u otras diferencias. Los tipos ms simples de los sistemas de bases de datos federadas son comnmente llamadas "puertas de acceso". En una puerta de entrada, un proveedor (por ejemplo, Oracle) proporciona acceso unidireccional a travs de sus DBMS a otra base de datos gestionada por DBMS de un proveedor diferente (por ejemplo, DB2 de IBM). Los dos DBMS no necesitan compartir el mismo modelo de datos. Por ejemplo, muchos proveedores de RDBMS son portales a los DBMS jerrquicos y de red. Hay sistemas de bases de datos federadas, tanto en el mercado y en la investigacin que proporcionan un acceso ms general a los diversos DBMS. Estos sistemas suelen proporcionar un componente de integracin de esquemas para integrar los esquemas de las diversas bases de datos y presentarlos a los usuarios como una nica base de datos, un componente de gestin de consultas para distribuir las consultas a los diferentes DBMS en la federacin, y un componente de gestin de transacciones, para distribuir y gestionar los cambios en las distintas bases de datos de la federacin.
Diccionario de Datos / Sistemas de directorios
El segundo componente de la prestacin de servicios de gestin de datos, el Diccionario / Sistema de Directorio de Datos (DD / DS), se compone de los servicios pblicos y los sistemas necesarios para el catlogo, documentar, gestionar, y el uso de metadatos (datos sobre los datos). Un ejemplo de los metadatos es la siguiente definicin: una larga cadena alfanumrica de seis caracteres, en el que el primer carcter es una letra del alfabeto y cada uno de los restantes cinco caracteres es un nmero entero entre 0 y 9; el nombre de la cadena es "la identificacin del empleado " . Las utilidades DD / DS hacen uso de archivos especiales que contienen el esquema de base de datos. (Un esquema, el uso de metadatos, define el contenido y la estructura de una base de datos.) Este esquema est representado por un conjunto de tablas para incluir en la compilacin de definicin de datos (DDL) Idioma. El DD / DS normalmente se proporciona como parte de un DBMS pero a veces est disponible a partir de fuentes alternativas. En la gestin de datos distribuidos, informacin de distribucin tambin se puede mantener en el sistema de directorio de red. En este caso, la interfaz entre los DD / DS y el sistema de directorio de red sera a travs de la API del componente de servicios de red en la plataforma. En los entornos actuales, diccionarios de datos se suelen integrar con el DBMS y sistemas de directorio se limitan por lo general a una sola plataforma. Directorios de red se usan para expandir el reino DD / DS. La relacin entre los DD / DS y el directorio de red es una combinacin compleja de fuentes fsicos y lgicos de datos.
Administracin de Datos
La administracin de datos aborda adecuadamente la arquitectura de datos, que est fuera del alcance de TOGAF. Se discuten brevemente aqu debido a las reas de superposicin. Se ocupa de todos los recursos de datos de una empresa, y como tal hay solapamientos con la gestin de datos, que se ocupa de los datos en bases de datos. Dos reas especficas de superposicin son los depositarios y administracin de base de datos, que se describen brevemente a continuacin.
Repositorio
Pgina439de670

TOGOF9.1
Un repositorio es un sistema que gestiona todos los datos de la empresa, que incluye datos y modelos de procesos y otra informacin de la empresa. Por lo tanto, los datos en un repositorio es mucho ms extensa que la de una DD / DS, que por lo general slo define los datos que forman una base de datos.
Administracin de bases de datos
La administracin de datos y administracin de base de datos son procesos complementarios. La administracin de datos es responsable de los datos, estructura de datos, y la integracin de datos y procesos. Administracin de base de datos, por otro lado, incluye el diseo fsico, desarrollo, implementacin, seguridad y mantenimiento de las bases de datos fsicos. Administracin de base de datos es responsable de la gestin y aplicacin de las polticas de la empresa relacionadas con bases de datos individuales.
Seguridad de los datos
El tercer componente de la prestacin de servicios de gestin de datos es la seguridad de los datos. Esto incluye los procedimientos y las medidas tecnolgicas aplicadas para prevenir el acceso no autorizado, modificacin, uso y difusin de los datos almacenados o procesados por un sistema informtico. La seguridad de datos incluye tambin la integridad de datos (es decir, preservar la exactitud y validez de los datos), y proteger el sistema de daos fsicos (incluidas las medidas preventivas y los procedimientos de recuperacin). Control de autorizacin permite slo los usuarios autorizados tengan acceso a la base de datos en el nivel adecuado. Directrices y procedimientos se pueden establecer para la rendicin de cuentas, los niveles de control, y el tipo de control. Autorizacin para el control de los sistemas de bases de datos difiere de la de los sistemas de archivos tradicionales, ya que, en un sistema de base de datos, no es raro para que diferentes usuarios tienen diferentes derechos a los mismos datos. Este requisito abarca la capacidad de especificar subconjuntos de datos y para distinguir entre grupos de usuarios. Adems, el control descentralizado de las autorizaciones es de particular importancia para los sistemas distribuidos. La proteccin de datos es necesario para evitar que los usuarios no autorizados de comprender el contenido de la base de datos. El cifrado de datos, como uno de los mtodos primarios para la proteccin de datos, es til tanto para la informacin almacenada en el disco y de la informacin intercambiada en una red.
35.7.7 Desarrollo de una empresa de administracin Ver

La visin empresarial de administracin se ocupa de las operaciones, la administracin y gestin del sistema.
Este punto de vista debe ser desarrollado para las operaciones, la administracin y el personal de gestin del sistema. Las principales preocupaciones de estos grupos de inters son la comprensin de cmo el sistema se gestiona como un todo, y cmo se controlan todos los componentes del sistema. La preocupacin principal es la gestin de cambio en el sistema y predecir el mantenimiento preventivo necesario.
Pgina440de670

TOGOF9.1
En general, estos grupos de inters tienen que ver con garantizar que la disponibilidad del sistema no sufre cuando se produzcan cambios. Administrar el sistema incluye Administracin de componentes como: Componentes de seguridad Los activos de datos Activos de software Los activos de hardware Redes activos
Escenarios de negocios son una manera muy til para describir lo que debe suceder cuando se planifican y se producen acontecimientos imprevistos. Es altamente recomendable que los escenarios de negocio pueden crear para el cambio planificado, y para el cambio no planificado. A continuacin se describen algunas de las cuestiones clave que el arquitecto podra considerar en la construccin de escenarios de negocio.
La visin empresarial de administracin acta como un control y equilibrio sobre las dificultades y el da a da los gastos de funcionamiento de los sistemas construidos en la nueva arquitectura. A menudo, la gestin del sistema no se considera hasta que se hayan tomado todas las decisiones de compra y de desarrollo importantes, y tener una visin de gestin independiente en una etapa temprana en el desarrollo de la arquitectura es una forma de evitar este escollo. Es una buena prctica para desarrollar la visin empresarial de administracin con un examen atento de la opinin de Ingeniera de Sistemas , ya que, en general, la gestin es difcil de adaptar en un diseo existente. Los elementos clave de la visin empresarial de administracin son: Las polticas, los procedimientos y directrices que impulsan sus necesidades de gestin (por ejemplo, una poltica para restringir la descarga de software desde Internet) Cmo su disponibilidad del sistema de medidas de la tienda Los servicios de gestin y los servicios pblicos necesarios La magnitud que pueda, calidad y ubicacin del personal de gestin y apoyo La capacidad de los usuarios para asumir las tareas de administracin del sistema, tales como el mantenimiento de contraseas La capacidad de administracin de los componentes existentes y previstas en cada una de las categoras de componentes
Pgina441de670

TOGOF9.1
Si la administracin debe ser centralizada o distribuida Si la seguridad es responsabilidad de los administradores de sistemas o un grupo separado, teniendo en cuenta todos los requisitos legales
Componentes tcnicos principales categoras que son objeto de la operacin vista empresarial de administracin con el cambio, ya sean mejoras previstas, o interrupciones no planificadas. La siguiente tabla muestra las preocupaciones especficas de cada categora de componente.
Categora de Consideraciones sobre el cambio componentes planeadas Componentes de Cmo se propaga un cambio de seguridad seguridad en todo el sistema? Quin es responsable de hacer los cambios; usuarios finales, o guardias de seguridad? Activos de Datos Cmo se aaden nuevos elementos de datos? Modificacin imprevista Consideraciones Qu debe suceder cuando se viola la seguridad? Qu debe ocurrir si un componente de seguridad falla?
Cules son los procedimientos de respaldo y son todas las capacidades del sistema de copia de seguridad all en el Cmo se importan los datos / exportados tiempo? o carga / sin carga? Cmo se gestiona la copia de seguridad mientras se ejecuta de forma continua? Cmo se propaga el cambio de datos en un entorno distribuido? Qu es lo que quieres que ocurra cuando Cmo es una nueva aplicacin introducida en los sistemas? falla una aplicacin? Qu procedimientos existen para controlar la calidad del software? Cmo se propagan los cambios de aplicaciones en un entorno distribuido? Cmo es la introduccin de software no deseado restringido dada la Internet? Cmo evala el impacto del nuevo Qu es lo que quieres que ocurra cuando hardware en el sistema, especialmente la se producen interrupciones de hardware? red de carga? Cmo evala el impacto de los nuevos componentes de red? Cmo optimizar los componentes de red? Qu es lo que quieres que ocurra cuando falla un recurso de la aplicacin?
Activos de Software
Activos de Hardware Networking Activo
35.7.8 Desarrollo de un Adquirente Ver

La vista adquiriente tiene que ver con la adquisicin de Commercial Off-The-Shelf (COTS) de software y hardware.
Pgina442de670

TOGOF9.1
Este punto de vista debe ser desarrollado para el personal que participa en la adquisicin de cualquiera de los componentes de la arquitectura de tema. Las principales preocupaciones de estos grupos de inters son la comprensin de lo que la construccin de bloques de la arquitectura se pueden comprar, y qu restricciones (o reglas) existen que son relevantes para la compra. La adquirente comprar con mltiples proveedores en busca de la mejor solucin de coste, si bien respetando las restricciones (o reglas) aplicadas por la arquitectura, como las normas. La principal preocupacin es hacer que las decisiones de compra que se ajustan a la arquitectura, y por lo tanto reducir el riesgo de los costos adicionales que surjan a partir de componentes que no cumplen.
La vista adquirente normalmente se representa como una arquitectura de soluciones de Bloques de Construccin (SBB), complementados con vistas a las normas que deben ser respetados por los bloques de construccin individuales.
El adquirente normalmente se ejecuta un proceso similar a la de abajo. Dentro de las descripciones de pasos que podemos ver las preocupaciones y problemas que enfrenta la entidad adquirente.
Etapas del Paso Descripcin y Salida Proceso de Contratacin Planificacin Crea el plan para la compra de algn componente. Para los sistemas de TI, las siguientes consideraciones son pertinentes a la construccin de bloques. Adquisicin Este paso requiere el acceso a la Arquitectura Bloques de Construccin (Abs) y SBB.

Exploracin Concept
El proxeneta necesita saber qu ABBS aplicar restricciones (estndares) para su uso en la evaluacin y para la creacin de RFP / RFI. El proxeneta necesita saber qu SBB candidatos se adhieran a estos estndares. El procurador tambin necesita saber qu proveedores ofrecen SBB aceptados, y en el que han sido desplegados. El procurador tiene que saber cul es el presupuesto de este componente fue dada en relacin con el coste total del sistema.
En este paso, el procurador mira a la viabilidad del concepto. Bloques de construccin dan el planificador de un sentido de los riesgos existentes; si existen muchos ABBS o SBB que coinciden con el concepto, el riesgo es menor.
Pgina443de670

TOGOF9.1
Este paso requiere el acceso a ABBS y SBB. El planificador necesita saber qu ABBS aplicar restricciones (estndares), y necesita saber qu SBB candidatos se adhieran a estos estndares. Demostracin En este paso, el proxeneta trabaja con el desarrollo de un prototipo de una Concepto aplicacin. El procurador recomienda los dispositivos SBB reutilizables basados en y Validacin estndares en forma, y la experiencia pasada con los proveedores. Este paso requiere el acceso a SBB reutilizables. En este paso, el proxeneta trabaja con el desarrollo para gestionar la relacin con los proveedores que suministran los dispositivos SBB. Bloques de construccin que han demostrado ser aptos para esta finalidad y son marcados como aprobados. Este paso requiere una actualizacin de la situacin de "aprobado la contratacin" de un SBB. En este paso, el proxeneta trabaja con el desarrollo para gestionar la relacin con los proveedores que suministran los dispositivos SBB. Bloques de construccin que se ponen en produccin consiguen debidamente marcado. Este paso requiere una actualizacin de la situacin a "la produccin" de SBB, con el identificador del sistema de donde se est desarrollando el bloque de construccin. En este paso, el proxeneta trabaja con el desarrollo para gestionar la relacin con los proveedores que suministran los dispositivos SBB. Bloques de construccin que estn totalmente desplegados obtener debidamente marcado. Este paso requiere una actualizacin del estado a "desplegado" de SBB, con el identificador del sistema de que se ha desplegado el bloque de construccin.
Desarrollo
Produccin
Despliegue
Pgina444de670

TOGOF9.1
36. Arquitectura Entregables

En este captulo se ofrece una descripcin de los entregables que se hace referencia en el Mtodo de Desarrollo de Arquitectura (ADM).
36.1 Introduccin
Este captulo define los entregables que se suele consumidos y producidos en todo el ciclo de TOGAF ADM. Como prestaciones suelen ser los productos de trabajo contractuales o formales de un proyecto de arquitectura, es probable que estas prestaciones se vern limitados o alterados por cualquier proyecto global o la gestin de procesos de la empresa (como CMMI, PRINCE2, PMBOK, o MSP). Por tanto, este captulo est destinado a proporcionar una lnea de base tpica de la arquitectura entregables con el fin de definir mejor las actividades que se requieren en el ADM y actuar como un punto de partida para la adaptacin dentro de una organizacin especfica. El marco de contenido TOGAF (ver la Parte IV , 33. Introduccin ) identifica los entregables que se producen como salidas de la ejecucin del ciclo ADM y potencialmente consumidos como insumos en otros puntos de la ADM. Otros entregables pueden producirse en otros lugares y consumidos por el ADM. Entregables producidos por la ejecucin de la ADM se muestran en la tabla a continuacin.
Entregable Arquitectura Bloques de Construccin (Ver 36.2.1 Arquitectura Building Blocks ) Arquitectura Contrato (Ver 36.2.2 Arquitectura de licitacin ) Arquitectura Definicin de documento (Ver 36.2.3 Arquitectura de definicin de documento ) Principios Arquitectura (Ver 36.2.4 Principios de Arquitectura ) Arquitectura Repositorio (Ver 36.2.5 Arquitectura Repositorio ) Arquitectura Requisitos Especificacin (ver 36.2.6 Arquitectura Especificacin de Requisitos ) Arquitectura Roadmap (Ver 36.2.7 Arquitectura Roadmap ) Architecture Vision (Ver 36.2.8 Architecture Vision ) Principios de Actuacin, objetivos de negocio, y los impulsores del negocio (Ver 36.2.9 Principios de Actuacin, objetivos de negocio, y los impulsores del negocio ) Evaluacin de Capacidad La produccin de ... F, H B, C, D, E, F De entrada a ... A, B, C, D, E C, D, E, F, G, H
Preliminar, A, B, C, D Preliminar
B, C, D, E, F, Gestin de Requisitos B, C, D, E, F A, E Preliminar, A, B
Preliminar, A, B, C, D, E, F, G, H Preliminar, A, B, C, D, E, F, G, H, Gestin de Requisitos C, D, Gestin de Requisitos B, C, D, E, F B, C, D, E, F, G, H, Gestin de Requisitos A, B
A, E
B, C, D, E, F
Pgina445de670

TOGOF9.1
(Ver 36.2.10 Evaluacin de Capacidad ) Solicitud de cambio (Ver 36.2.11 Solicitud de cambio ) Plan de Comunicacin (Ver 36.2.12 Plan de Comunicaciones ) Evaluacin de cumplimiento (Ver Evaluacin del Cumplimiento 36.2.13 ) Implementacin y Plan de Migracin (Ver 36.2.14 Implementacin y Plan de Migracin ) Gobierno Modelo de Implementacin (Ver 36.2.15 Implementacin Modelo de Gobierno ) Modelo de Organizacin de Empresa Arquitectura (ver 36.2.16 Modelo de Organizacin de Empresa de Arquitectura ) Solicitud de Arquitectura Trabajo (Ver 36.2.17 Solicitud de Arquitectura de Trabajo ) Evaluacin de Impacto Requisitos (Ver 36.2.18 Requisitos de Evaluacin de Impacto ) Solucin Building Blocks (Ver Solucin 36.2.19 Building Blocks ) Declaracin de Arquitectura de Trabajo (Ver 36.2.20 Declaracin de Arquitectura de Trabajo ) Marco de Arquitectura Adaptado (Ver 36.2.21 Tailored Architecture Framework ) F, G, H La T E, F B, C, D, E, F H F
G, H
Preliminar
Preliminar, A, B, C, D, E, F, G, H, Gestin de Requisitos A, G
Preliminar, F, H
Gestin de Requisitos
Gestin de Requisitos
T A, B, C, D, E, F, G, H
A, B, C, D, E, F, G B, C, D, E, F, G, H, Gestin de Requisitos Preliminar, A, B, C, D, E, F, G, H, Gestin de Requisitos
Preliminar, A
36.2 Descripciones Entregables

Las siguientes secciones ofrecen ejemplos de las descripciones de los entregables que se hace referencia en el ADM. Tenga en cuenta que no todo el contenido descrito aqu tiene que estar contenido en una entrega especial. Ms bien, se recomienda el uso de referencias externas cuando sea posible; por ejemplo, los planes estratgicos de una empresa no deben ser copiados a una Solicitud de Arquitectura Trabajo, sino ms bien el ttulo de los planes estratgicos deben ser referenciados. Adems, no se sugiere que estas descripciones se deben seguir a la letra. Sin embargo, cada elemento debe ser considerado cuidadosamente; haciendo caso omiso de cualquier elemento de entrada o de salida puede causar problemas aguas abajo.
36.2.1 Arquitectura Bloques de Construccin

Documentacin de Arquitectura y modelos de arquitectura de repositorio de la empresa; vase la Parte IV , 37. Building Blocks .
Pgina446de670

TOGOF9.1
36.2.2 Arquitectura Contrato
Propsito
Arquitectura contratos son los acuerdos conjuntos entre los socios de desarrollo y los patrocinadores de los entregables, la calidad y la aptitud para el propsito de una arquitectura . La implementacin exitosa de estos acuerdos ser entregado a travs de la gobernanza arquitectura eficaz (vase la Parte VII , 50. Arquitectura de Gobierno). Mediante la implementacin de un enfoque regido a la gestin de los contratos, lo siguiente ser garantizada: Un sistema de monitoreo continuo para comprobar la integridad, los cambios, la toma de decisiones, y la auditora de todas las actividades relacionadas con la Arquitectura dentro de la organizacin La adhesin a los principios, las normas y los requisitos de las arquitecturas existentes o en desarrollo Identificacin de los riesgos en todos los aspectos del desarrollo y la implementacin de la arquitectura (s) que cubre el desarrollo interno contra las normas aceptadas, polticas, tecnologas y productos, as como los aspectos operativos de las arquitecturas de tal manera que la organizacin pueda continuar sus actividades dentro de un entorno resistente Un conjunto de procesos y prcticas que garanticen la rendicin de cuentas, la responsabilidad y la disciplina en relacin con el desarrollo y el uso de todos los artefactos arquitectnicos Una comprensin formal de la organizacin de gobierno responsable del contrato, su nivel de autoridad, y el mbito de la arquitectura bajo el gobierno de este rgano
Contenido
Contenido tpico de un diseo y desarrollo de contratos de Arquitectura son: Introduccin y antecedentes La naturaleza del acuerdo Alcance de la arquitectura Arquitectura y estratgicos principios y los requisitos Los requisitos de conformidad Proceso y las funciones de desarrollo y gestin de la Arquitectura Medidas Arquitectura Target Fases definidas de entregables Plan de trabajo conjunto priorizado Ventana de tiempo (s)
Pgina447de670

TOGOF9.1
Arquitectura de entrega y de negocios mtricas
Los contenidos tpicos de la arquitectura de licitacin de un negocio de los usuarios son: Introduccin y antecedentes La naturaleza del acuerdo Alcance Requisitos estratgicos Los requisitos de conformidad Arquitectura adoptantes Ventana de tiempo Arquitectura mtricas de negocio Arquitectura de servicios (que incluye el contrato de nivel de servicio (SLA))
Para ms detalles sobre el uso de la arquitectura de Contratos, consulte la Parte VII , 49. Arquitectura de Contratos .
36.2.3 Arquitectura de definicin de documento

Propsito
La definicin de documento La arquitectura es el contenedor de entrega de los artefactos arquitectnicos bsicos creados durante el proyecto y para obtener informacin importante relacionada. La definicin de documento Arquitectura abarca todos los mbitos de arquitectura (negocio, datos, aplicaciones y tecnologa) y tambin examina todos los estados relevantes de la arquitectura (lnea de base, transicin y meta). Una arquitectura de transicin muestra la empresa en un estado de gran importancia arquitectnica entre la lnea de base y Target Arquitecturas. Arquitecturas de transicin se utilizan para describir las arquitecturas objetivo transitorias necesarias para la realizacin efectiva de la arquitectura destino. La definicin de documento La arquitectura es un complemento de la arquitectura de Especificacin de Requisitos, con un objetivo complementario: La definicin de documento Arquitectura proporciona una visin cualitativa de la solucin y tiene por objeto comunicar la intencin de los arquitectos. La especificacin de arquitectura Requisitos ofrece una visin cuantitativa de la solucin, indicando los criterios cuantificables que deben cumplirse durante la implementacin de la arquitectura.
Contenido
Pgina448de670

TOGOF9.1
Los contenidos tpicos de una definicin de arquitectura de documento son: Alcance Metas, objetivos y limitaciones Principios Arquitectura Arquitectura de lnea de base Modelos de arquitectura (por cada estado para modelar): o o o o Modelos Arquitectura Profesiones Modelos de arquitectura de datos Modelos de arquitectura de la aplicacin Modelos de arquitectura tecnolgica
Fundamento y justificacin de enfoque arquitectnico Mapeo de Arquitectura Repositorio: o o o o Mapeo de Arquitectura del Paisaje Mapeo para referenciar los modelos Mapeo de las normas Evaluacin Reutilizacin
Anlisis de las deficiencias La evaluacin del impacto Arquitectura de transicin: o o o o o Definicin de estados de transicin Arquitectura de negocios para cada estado de transicin Arquitectura de datos para cada estado de transicin Arquitectura de aplicaciones de cada estado de transicin Arquitectura Tecnolgica para cada estado de transicin
36.2.4 Principios Arquitectura

Propsito
Los principios son normas generales y directrices, destinadas a ser duradera y rara vez modificada, que informan y apoyan la forma en que una organizacin se marca sobre el cumplimiento de su misin.
Pgina449de670

TOGOF9.1
A su vez, los principios pueden ser slo un elemento de un conjunto estructurado de ideas que en conjunto definen y guas de la organizacin, a partir de los valores a travs de acciones y resultados.
Contenido
Ver Parte III , 23. Principios de Arquitectura de directrices y un conjunto detallado de principios de arquitectura genricos, entre ellos: Principios empresariales (vase 23.6.1 Principios de Negocios ) Principios de datos (vase 23.6.2 Datos Principios ) Principios de aplicacin (ver 23.6.3 Principios de Aplicacin ) Principios Tecnologa (ver 23.6.4 Principios Tecnolgicos )

Propsito
La arquitectura de repositorio acta como una zona de espera para todos los proyectos relacionados con la arquitectura dentro de la empresa. El repositorio permite que los proyectos para la gestin de sus entregables, localizar reutilizables activos, y publicar los resultados a las partes interesadas y otras partes interesadas.
Contenido
Vase la Parte V , 41. Arquitectura Repositorio para obtener una descripcin detallada del contenido de un repositorio de Arquitectura.
36.2.6 Arquitectura Especificacin de Requisitos

Propsito
La especificacin de arquitectura Requisitos proporciona un conjunto de enunciados cuantitativos que describen lo que un proyecto de implementacin debe hacer para cumplir con la arquitectura. Una arquitectura de Especificacin de Requisitos tpicamente formar un componente importante de un contrato de ejecucin o contratar ms detallada Arquitectura Definicin. Como se mencion anteriormente, la arquitectura de Especificacin de Requisitos es un complemento de la definicin de documento de Arquitectura, con un objetivo complementario: La definicin de documento Arquitectura proporciona una visin cualitativa de la solucin y tiene por objeto comunicar la intencin del arquitecto. La especificacin de arquitectura Requisitos ofrece una visin cuantitativa de la solucin, indicando los criterios cuantificables que deben cumplirse durante la implementacin de la arquitectura.
Contenido
Pgina450de670

TOGOF9.1
Los contenidos tpicos de una arquitectura de Especificacin de Requisitos son: Medidas de xito Requisitos de arquitectura Contratos de servicios de negocios Contratos de servicios de aplicaciones Directrices de implementacin Las especificaciones de implementacin Las normas de aplicacin Requisitos de interoperabilidad Requisitos de gestin de servicios de TI Restricciones Supuestos
36.2.7 Arquitectura Roadmap

Propsito
La Arquitectura Roadmap enumera los paquetes de trabajo individuales que realizarn la arquitectura destino y las coloca en una lnea de tiempo para mostrar la progresin de la Arquitectura de referencia para la arquitectura destino. La Hoja de Ruta de la arquitectura destaca el valor del negocio paquetes de trabajo individuales en cada etapa.Arquitecturas de transicin necesarias para realizar eficazmente la Arquitectura objetivo se identifican como pasos intermedios. La Hoja de Ruta de la arquitectura se desarrolla gradualmente a lo largo de las fases E y F, e informada por los componentes de la hoja de ruta fcilmente identificables de la Fase B, C y D dentro de la ADM.
Contenido
Los contenidos tpicos de una hoja de ruta de la Arquitectura son: Cartera Paquete de trabajo: o o o o o Descripcin Paquete de trabajo (nombre, descripcin, objetivos, entregables) Requisitos funcionales Dependencias Relacin con la oportunidad Relacin a la Arquitectura de definicin de documento y Arquitectura Especificacin de Requisitos
Pgina451de670

TOGOF9.1
o El valor del negocio Evaluacin Factor de Aplicacin y de la matriz de deduccin, incluyendo: o o o o o o Riesgos Cuestiones Supuestos Dependencias Acciones Entradas
Brechas consolidados, soluciones, y la matriz de dependencias, entre ellas: o o o o Arquitectura dominio Brecha Posibles soluciones Dependencias
Cualquier Arquitecturas de transicin Recomendaciones para la implementacin: o o o Criterios de valoracin de la eficacia de los proyectos Riesgos y problemas Bloques de Solucin de construccin (SBB)
36.2.8 Architecture Vision

Propsito
El Architecture Vision se crea desde el principio en el ciclo de ADM. Proporciona un resumen de los cambios a la empresa que se derivarn de la implementacin exitosa de la arquitectura destino. El propsito de la Architecture Vision es proporcionar actores clave con un resultado acordado formalmente. Pronto acuerdo sobre el resultado permite a los arquitectos para centrarse en los detalles necesarios para validar la factibilidad. Proporcionar una Architecture Vision tambin es compatible con la comunicacin de las partes interesadas, proporcionando una versin resumida de la arquitectura Definicin completa.
Contenido
Los contenidos tpicos de una Visin Arquitectura son: Descripcin del problema:
Pgina452de670

TOGOF9.1
o o Las partes interesadas y sus preocupaciones Lista de temas / situaciones que deben abordarse
Objetivo de la Declaracin de Arquitectura de Trabajo Resumen considera necesaria para la solicitud de Arquitectura Trabajo y la versin 0.1 de negocios, aplicaciones, datos y tecnologa Arquitecturas cre; tpicamente incluyendo: o o Diagrama de la cadena de valor Diagrama conceptual de soluciones
Requisitos asignados Referencia al proyecto de arquitectura Definicin de documento
36.2.9 Principios de Actuacin, objetivos de negocio, y los impulsores del negocio

Propsito
Principios de Actuacin, los objetivos de negocio, y los impulsores del negocio proporcionan un contexto para el trabajo de la arquitectura, mediante la descripcin de las necesidades y formas de trabajo empleado por la empresa. No obstante, muchos factores que estn fuera de la consideracin de la arquitectura la disciplina pueden tener implicaciones importantes para la forma en que la arquitectura se desarrolla.
Contenido
El contenido y la estructura del contexto de negocios para la arquitectura puede variar considerablemente de una organizacin a otra.
36.2.10 Evaluacin de Capacidad

Propsito
Antes de embarcarse en una arquitectura detallada definicin, es valioso para comprender la lnea de base y el nivel de capacidad objetivo de la empresa. Esta evaluacin de la capacidad puede ser examinado en varios niveles: Cul es el nivel de capacidad de la empresa en su conjunto? De dnde viene la empresa desean aumentar u optimizar la capacidad? Cules son las reas de enfoque de arquitectura que apoyarn el desarrollo deseado de la empresa? Cul es la capacidad o nivel de madurez de la funcin de TI dentro de la empresa? Cules son las posibles consecuencias de la realizacin del proyecto de arquitectura en trminos de gobernanza o el diseo, la gestin operativa, habilidades y estructura de la organizacin? Qu es un estilo apropiado, nivel de formalidad, y la cantidad de detalle para el proyecto de arquitectura para encajar con la cultura y la capacidad de la organizacin de TI?
Pgina453de670

TOGOF9.1
Cul es la capacidad y la madurez de la funcin de la arquitectura dentro de la empresa? Qu activos de arquitectura se encuentran actualmente en la existencia?Se mantienen y precisa? Qu normas y modelos de referencia deben ser considerados? Es probable que haya oportunidades para crear reutilizables activos durante el proyecto de arquitectura? Cuando existan vacos de capacidad, en qu medida es el negocio listo para transformar con el fin de alcanzar la capacidad de objetivo? Cules son los riesgos para la transformacin, las barreras culturales y otras consideraciones que deben abordarse ms all de la brecha de capacidades bsicas?
Contenido
Los contenidos tpicos de una Evaluacin de Capacidad son: Evaluacin de la capacidad del negocio, incluyendo: o o o o o o Capacidades del negocio Evaluacin del estado basal del nivel de rendimiento de cada capacidad Futuro aspiracin estado para el nivel de rendimiento de cada capacidad Evaluacin del estado de lnea de base de cmo se realiza cada capacidad Futuro aspiracin estado para saber cmo debe ser realizado cada capacidad Evaluacin de los posibles impactos a la organizacin de la empresa resultante de la implementacin exitosa de la arquitectura destino
Evaluacin de capacidades de TI, incluyendo: o o o o Lnea de base y objetivo de nivel de madurez del proceso de cambio Nivel de partida y de destino de madurez de los procesos operativos Evaluacin de la capacidad de lnea de base y la capacidad Evaluacin de los impactos probables a la organizacin de TI como resultado de la implementacin exitosa de la arquitectura destino
Evaluacin de la madurez de la Arquitectura, que incluye: o o o Procesos de gobernanza Arquitectura, organizacin, funciones y responsabilidades Evaluacin de habilidades Arquitectura Amplitud, profundidad y calidad de la definicin del paisaje con el Repositorio de Arquitectura Amplitud, profundidad y calidad de definicin las normas con el Repositorio Arquitectura Amplitud, profundidad y calidad de la determinacin del modelo de referencia con el Repositorio de Arquitectura
Pgina454de670

TOGOF9.1
o Evaluacin de re-uso potencial Preparacin para la transformacin del negocio de Evaluacin, que incluye: o o o o Factores de Preparacin Visin para cada factor de preparacin Las calificaciones de preparacin actuales y de destino Riesgos de Preparacin
36.2.11 Solicitud de Cambio

Propsito
Durante la implementacin de una arquitectura , a medida que ms datos se dan a conocer, es posible que la definicin y los requisitos de arquitectura original no son adecuadas o no son suficientes para completar la implementacin de una solucin. En estas circunstancias, es necesario que los proyectos de implementacin de cualquiera desvan del enfoque arquitectnico sugerido o solicitar ampliaciones de mbito. Adems, los factores externos - como los factores del mercado, cambios en estrategia de negocios y nuevas oportunidades de la tecnologa - pueden abrir oportunidades para ampliar y refinar la arquitectura. En estas circunstancias, una solicitud de cambio puede ser presentada con el fin de poner en marcha un nuevo ciclo de trabajo de la arquitectura.
Contenido
Los contenidos tpicos de una solicitud de cambio son: Descripcin del cambio propuesto Justificacin del cambio propuesto La evaluacin del impacto del cambio propuesto, incluyendo: o o o o o o Referencia a los requisitos especficos Prioridad de los interesados de los requisitos a la fecha Fases para ser revisitados Fase de llevar sobre los requisitos de priorizacin Los resultados de las investigaciones de fase y prioridades revisadas Recomendaciones sobre la gestin de requisitos
Nmero de referencia del Repositorio
36.2.12 Plan de Comunicacin

Propsito
Pgina455de670

TOGOF9.1
Las arquitecturas empresariales contienen grandes volmenes de informacin compleja e interdependiente. La comunicacin efectiva de informacin dirigida a las partes interesadas adecuadas en el momento adecuado es un factor crtico de xito para la arquitectura empresarial. Desarrollo de un Plan de Comunicacin para la arquitectura permite esta comunicacin se lleve a cabo dentro de un proceso planificado y gestionado.
Contenido
Contenido tpico de un plan de comunicaciones son: Identificacin de las partes interesadas y la agrupacin por las necesidades de comunicacin Identificacin de las necesidades de comunicacin, los mensajes clave en relacin con el Architecture Vision, los riesgos de la comunicacin, y factores crticos de xito (CSF) Identificacin de los mecanismos que se utilizan para comunicarse con las partes interesadas y permitir el acceso a la arquitectura de la informacin, tales como reuniones, boletines, repositorios, etc Identificacin de un calendario de comunicaciones, mostrando qu comunicaciones se produzcan con cul grupo de participantes en qu momento y en qu lugar
36.2.13 Evaluacin de cumplimiento

Propsito
Una vez que una arquitectura se ha definido, es necesario para gobernar que la arquitectura a travs de la aplicacin para asegurarse de que el original Architecture Vision se realiza de manera adecuada y que ningn aprendizajes de implementacin se introducen de nuevo en el proceso de la arquitectura. Revisiones de cumplimiento del perodo de los proyectos de aplicacin proporcionan un mecanismo para revisar el progreso del proyecto y asegurarse de que el diseo y la implementacin se avanzan en lnea con los objetivos estratgicos y arquitectnicos.
Contenido
Los contenidos tpicos de una Evaluacin de Cumplimiento son: Informacin general sobre el progreso y el estado del proyecto Descripcin general de la arquitectura del proyecto / diseo Completadas las listas de verificacin de arquitectura: o o o o o Hardware y sistema operativo lista Los servicios de software y middleware lista Aplicaciones listas de comprobacin Listas de control de gestin de la informacin Listas de control de seguridad
Pgina456de670

TOGOF9.1
o o o Listas de control de gestin del sistema Listas de control de ingeniera de sistemas Mtodos y herramientas de listas de verificacin
36.2.14 Implementacin y Plan de Migracin

Propsito
La aplicacin y el Plan de Migracin ofrece un calendario de los proyectos que realizarn la arquitectura destino. La aplicacin y el Plan de Migracin incluye proyectos ejecutables agrupados en carteras y programas gestionados. La Implementacin y Estrategia de migracin de identificar el enfoque para el cambio es un elemento clave de la aplicacin y el Plan de Migracin.
Contenido
Contenido tpico de una aplicacin y el Plan de Migracin son: Implementacin y Estrategia de migracin: o o Direccin estratgica aplicacin Enfoque de secuenciacin de Implementacin
Proyectos y Distribucin de la cartera de ejecucin: o o o o o Asignacin de los paquetes de trabajo para proyectar y de cartera Capacidades entregados por proyectos Hitos y calendario Estructura de desglose del trabajo Puede incluir el impacto sobre la cartera existente, programa y proyectos
Puede contener: Cartas del proyecto: o o o o o Paquetes de trabajo incluidos El valor del negocio Riesgo, problemas, hiptesis, dependencias Las necesidades de recursos y los costes Beneficios de la migracin, determinados (incluyendo la asignacin a los requerimientos del negocio) Estimacin de los gastos de las opciones de migracin
Pgina457de670

TOGOF9.1
36.2.15 Implementacin Modelo de Gobierno
Propsito
Una vez que una arquitectura se ha definido, es necesario planificar cmo la arquitectura de transicin que implementa la arquitectura se regir mediante la aplicacin.Dentro de las organizaciones que han establecido las funciones de la arquitectura, no es probable que sea un marco de gobernanza que ya existen, pero los procesos especficos, las organizaciones, los roles, las responsabilidades y las medidas puede ser necesario definir sobre una base de proyecto por proyecto. El Gobierno asegura Modelo de Aplicacin de que un proyecto de transicin a la aplicacin tambin pasa de manera ordenada en la gobernanza arquitectura apropiada.
Contenido
Contenido tpico de un Modelo de Gobierno de Ejecucin se encuentran: Los procesos de gobernanza Estructura de la organizacin de Gobierno Funciones y responsabilidades de Gobierno Los puestos de control de gobierno y los criterios de xito / fracaso
36.2.16 Modelo Organizacional para Arquitectura Empresarial

Propsito
Para que un marco de arquitectura para ser utilizado con xito, debe ser apoyado por la correcta organizacin, las funciones y las responsabilidades dentro de la empresa.De particular importancia es la definicin de los lmites entre los distintos profesionales de arquitectura empresarial y de las relaciones de gobernanza que se extienden a travs de estas fronteras.
Contenido
Contenido tpico de un modelo organizativo para la arquitectura de la empresa son los siguientes: mbito de las organizaciones afectadas La evaluacin gestacional, lagunas, y el enfoque de resolucin Roles y responsabilidades de equipo de arquitectura (s) Las restricciones sobre el trabajo de arquitectura Necesidades presupuestarias Gobernabilidad y estrategia de apoyo
Pgina458de670

TOGOF9.1
36.2.17 Solicitud de Arquitectura Trabajo
Propsito
Este es un documento que se enva desde la organizacin patrocinadora de la organizacin Arquitectura para desencadenar el inicio de un ciclo de desarrollo de la arquitectura. Las solicitudes de Arquitectura trabajo se pueden crear como una salida de la fase preliminar, a raz de las solicitudes de cambio aprobadas arquitectura, o los trminos de referencia para el trabajo de arquitectura procedentes de planificacin de la migracin. En general, toda la informacin contenida en este documento debe estar a un nivel alto.
Contenido
Las solicitudes de Arquitectura trabajo suelen incluir: Patrocinadores Organizacin Declaracin de la misin de la Organizacin Los objetivos de negocio (y cambios) Los planes estratgicos de la empresa Plazos Los cambios en el entorno empresarial Limitaciones de organizacin La informacin presupuestaria, las limitaciones financieras Las restricciones externas, restricciones comerciales Descripcin del sistema de negocio actual Descripcin del sistema actual arquitectura / TI Descripcin de desarrollar organizacin Descripcin de los recursos disponibles para el desarrollo de la organizacin

Evaluacin de Impacto 36.2.18 Requisitos
Propsito
A lo largo de la ADM, la nueva informacin se recoge en relacin con una arquitectura . Como se recoge esta informacin, nuevos hechos pueden salir a la luz que invalida los aspectos actuales de la arquitectura. A Requisitos de evaluacin de impacto evala los requisitos de arquitectura actuales y las especificaciones para identificar los cambios que se deben hacer y las implicaciones de esos cambios.
Pgina459de670

TOGOF9.1
Contenido
Los contenidos tpicos de una Evaluacin de Impacto Los requisitos son: Referencia a los requisitos especficos Prioridad de los interesados de los requisitos a la fecha Fases para ser revisitados Fase de llevar sobre los requisitos de priorizacin Los resultados de las investigaciones de fase y prioridades revisadas Recomendaciones sobre la gestin de requisitos Nmero de referencia del Repositorio
Solucin 36.2.19 Building Blocks

-Implementacin especfica bloques de construccin de la empresa Arquitectura repositorio; vase la Parte IV , 37. Building Blocks .
36.2.20 Declaracin de Arquitectura de Trabajo

Propsito
La Declaracin de Arquitectura Trabajo define el alcance y el enfoque que se utilizar para completar un ciclo de desarrollo de la arquitectura. La Declaracin de Arquitectura El trabajo es por lo general el documento contra el cual se medir la ejecucin exitosa del proyecto de arquitectura y puede constituir la base de un acuerdo contractual entre el proveedor y el consumidor de servicios de arquitectura.
Contenido
Los contenidos tpicos de una Declaracin de Arquitectura Trabajo son: Ttulo Arquitectura solicitud de proyecto y antecedentes Arquitectura Descripcin y alcance del proyecto Descripcin general de Arquitectura Visin Cambio especfico de los procedimientos de alcance Las funciones, las responsabilidades y los entregables Criterios y procedimientos de aceptacin Plan de la configuracin y programacin del proyecto
Pgina460de670

TOGOF9.1
Aprobaciones
36.2.21 Tailored Architecture Framework

Propsito
TOGAF proporciona un marco estndar de la industria para la arquitectura que se puede utilizar en una amplia variedad de organizaciones. Sin embargo, antes de TOGAF se puede utilizar con eficacia dentro de un proyecto de arquitectura, sastrera a dos niveles es necesario. En primer lugar, es necesario adaptar el modelo TOGAF para la integracin en la empresa. Esta adaptacin incluye la integracin con los marcos de los proyectos y de gestin de procesos, la personalizacin de la terminologa, el desarrollo de estilos de presentacin, seleccin, configuracin y despliegue de herramientas de arquitectura, etc La formalidad y el detalle de las estructuras adoptadas tambin deben alinearse con otros factores contextuales para la empresa, tales como la cultura, las partes interesadas, los modelos comerciales para la arquitectura de la empresa, y el nivel actual de la arquitectura de Capacidad. Una vez que el marco se ha adaptado a la empresa, ms la adaptacin es necesaria con el fin de adaptar el marco del proyecto de arquitectura especfica. Adaptacin a este nivel seleccionar entregables y artefactos adecuados para satisfacer las necesidades del proyecto y las partes interesadas. Vase la Parte II , 6.4.5 Tailor TOGAF y, en su caso, Otros arquitectura marco seleccionado (s) para otras consideraciones al seleccionar y adaptar el marco de la arquitectura.
Contenido
Contenido tpico de un Marco de Arquitectura Tailored son: Mtodo de arquitectura adaptada Adaptado contenido de la arquitectura (entregables y artefactos) Herramientas de configurar e implementar Interfaces con modelos de gobierno y otros marcos: o o o o o Planificacin Ejecutiva Arquitectura Empresarial Portafolio, Programa, Gestin de Proyectos Desarrollo de Sistemas / Ingeniera Operaciones (Servicios)
Pgina461de670

TOGOF9.1
37. Bloques de Construccin

En este captulo se explica el concepto de bloques de construccin.

Esta seccin tiene por objeto explicar e ilustrar el concepto de bloques de construccin en la arquitectura. Despus de esta visin general, hay dos partes principales: Introduccin a los Bloques de construccin (vase 37.2 Introduccin a los Bloques de Construccin ), discute los conceptos generales de bloques de construccin, y explica las diferencias entre Arquitectura Bloques de Construccin (Abs) y solucin Building Blocks (SBB). Bloques de Construccin y la ADM ( 37.3 Bloques de Construccin y el ADM ), resume las etapas en las que el diseo y la especificacin de bloque de construccin se produce dentro de la Arquitectura Mtodo de Desarrollo de TOGAF (ADM).
37.2 Introduccin a los Bloques de Construccin

Esta seccin es una introduccin al concepto de bloques de construccin.

En esta seccin se describen las caractersticas de los bloques de construccin. La utilizacin de bloques de construccin en el ADM se describe por separado en 37.3 Bloques de Construccin y el ADM .
37.2.2 Caractersticas genricas

Bloques de construccin tienen caractersticas genricas de la siguiente manera: Un bloque de construccin es un paquete de funcionalidad definida para satisfacer las necesidades del negocio en toda la organizacin. Un bloque de construccin tiene un tipo que corresponde al contenido metamodelo TOGAF (como actor, servicio de negocios, la aplicacin, o entidad de datos) Un bloque de construccin tiene un lmite definido y es generalmente reconocido como "una cosa" por los expertos de dominio. Un bloque de construccin puede interoperar con otros, bloques de construccin, interdependientes. Un buen bloque de construccin tiene las siguientes caractersticas:
Pgina462de670

TOGOF9.1
o Se considera la implementacin y el uso, y evoluciona para explotar la tecnologa y las normas. Se puede ensamblar a partir de otros bloques de construccin. Puede ser un subconjunto de otros bloques de construccin. Lo ideal es un bloque de construccin es reutilizable y reemplazable, y bien especificado.
o o o
Frontera y la especificacin de un bloque de construccin deben ser dbilmente acoplados a su aplicacin; es decir, debe ser posible realizar un bloque de construccin de varias maneras diferentes sin impactar en el lmite o la especificacin del bloque de construccin. La forma en que los medios y capacidades se montan en bloques de construccin pueden variar ampliamente entre las arquitecturas individuales. Cada organizacin debe decidir por s mismo lo que la disposicin de bloques de construccin que funciona mejor para l. Una buena eleccin de bloques de construccin puede conducir a mejoras en la integracin de sistemas de legado, la interoperabilidad y la flexibilidad en la creacin de nuevos sistemas y aplicaciones. Los sistemas estn construidos a partir de colecciones de bloques de construccin, por lo que la mayora de los bloques de construccin que interoperar con otros bloques de construccin. Dondequiera que eso es cierto, es importante que las interfaces con un bloque de construccin se publican y razonablemente estable. Bloques de construccin se pueden definir en varios niveles de detalle, dependiendo de la etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una etapa temprana, un bloque de construccin puede consistir simplemente en un nombre o una breve descripcin. Ms tarde, un bloque de construccin se puede descomponer en varios bloques de edificios de apoyo y puede ir acompaada de una especificacin completa. El nivel de detalle al que se debe especificar un bloque de construccin depende de los objetivos de la arquitectura y, en algunos casos, menos detalle puede ser de mayor valor (por ejemplo, en la presentacin de las capacidades de una empresa, una nica clara y concisa la imagen tiene ms valor que una densa especificacin de 100 pginas). El OMG ha desarrollado un estndar para la Especificacin de activos reutilizables (RAS) , 1 que proporciona un buen ejemplo de cmo los bloques de construccin pueden ser descritas formalmente y gestionados.
37.2.3 Arquitectura Bloques de Construccin

Arquitectura Bloques de Construccin (Abs) se refieren a la Arquitectura Continuum (vase la Parte V , 39.4.1 Arquitectura Continuum ), y se definen o seleccionados como resultado de la aplicacin de la ADM.
37.2.3.1 Caractersticas
Abs:
Pgina463de670

TOGOF9.1
Captura de requisitos de arquitectura; requisitos, por ejemplo, de negocio, datos, aplicaciones y tecnologa Dirigir y orientar el desarrollo de SBB
37.2.3.2 Especificacin Contenido
Especificaciones de ABB son los siguientes, como mnimo: Funcionalidad y atributos fundamentales: semntico, sin ambigedades, incluyendo la capacidad de seguridad y capacidad de gestin Interfaces: conjunto elegido, suministrado La interoperabilidad y la relacin con otros bloques de construccin Bloques de construccin dependientes con la funcionalidad requerida y las interfaces de usuario con nombre Mapa de negocios / entidades organizativas y polticas
37.2.4 Solucin Building Blocks

Solucin Building Blocks (SBB) se relacionan con el Continuum Solutions (vase la Parte V , 39.4.2 Soluciones Continuum ), y puede ser o bien adquieren o se desarrollan.
37.2.4.1 Caractersticas
SBB: Definir cules son los productos y componentes sern implementar la funcionalidad Definir la ejecucin Cumplir los requisitos de negocio Son producto o proveedores conscientes
37.2.4.2 Especificacin Contenido
Especificaciones SBB incluyen los siguientes, como mnimo: Funcionalidad y atributos especficos Interfaces; el conjunto implementado SBB necesarios que se utilizan con la funcionalidad y los nombres de las interfaces utilizadas requerido Mapeo de la SBB con la topologa de TI y las polticas operacionales
Pgina464de670

TOGOF9.1
Especificaciones de atributos compartidos a travs del medio ambiente (que no debe confundirse con la funcionalidad), tales como seguridad, manejabilidad, localizabilidad, escalabilidad Rendimiento, capacidad de configuracin Conductores Diseo y limitaciones, incluyendo la arquitectura fsica Las relaciones entre los SBB y ABBS
37.3 Bloques de Construccin y el ADM

37.3.1 Principios bsicos
Esta seccin se centra en el uso de los bloques de construccin de la ADM. Consideraciones generales y caractersticas de los bloques de construccin se describen en 37.2 Introduccin a los Bloques de Construccin .
37.3.1.1 pilares en Arquitectura
Una arquitectura es un conjunto de bloques de construccin representados en un modelo arquitectnico, y una especificacin de cmo esos bloques de construccin estn conectados a cumplir con los requisitos generales de la empresa. Los diversos bloques de construccin en una arquitectura especifican el alcance y el enfoque que se utilizar para hacer frente a un problema de negocio especfico. Hay algunos principios generales que sustentan el uso de bloques de construccin en el diseo de arquitecturas especficas: Una arquitectura slo debe contener elementos bsicos que son relevantes para el problema de negocio que la arquitectura est tratando de resolver. Bloques de construccin pueden tener relaciones complejas entre s. A una cuadra del edificio puede soportar mltiples bloques de construccin o puede apoyar parcialmente un solo bloque de construccin (por ejemplo, el servicio de negocio de "la tramitacin de reclamaciones" sera apoyada por muchas entidades de datos y, posiblemente, varios componentes de la aplicacin). Bloques de construccin deben ajustarse a las normas pertinentes de su tipo, los principios de la empresa, as como las normas de la empresa.
37.3.1.2 Mdulo de Diseo
El proceso de identificacin de bloques de construccin incluye el estudio de las colecciones de las capacidades o activos que interactan entre s y luego dibujarlos juntos o hacindolos diferente: Considere tres clases de bloques de construccin: o Bloques de construccin reutilizables, como los elementos heredados
Pgina465de670

TOGOF9.1
o Bloques de construccin a ser objeto de desarrollo, tales como las nuevas aplicaciones Bloques de construccin a ser objeto de adquisicin; es decir, Commercial OffThe-Shelf (COTS) aplicaciones
Utilice el nivel deseado de integracin para unir o combinar funciones en bloques de construccin. Por ejemplo, los elementos heredados podran ser tratados como grandes bloques de construccin para evitar que stas se descompongan.
En las primeras etapas y durante visitas de la empresa de ms alto nivel, los bloques de construccin son a menudo mantenidos en una definicin amplia integracin. Es durante estos ejercicios en que las definiciones de servicios a menudo puede ser mejor vieron. Como se abordan consideraciones de implementacin, vistas ms detalladas de bloques de construccin a menudo pueden utilizarse para hacer frente a las decisiones de implementacin, se centran en las decisiones estratgicas crticas, o la ayuda en la evaluacin del valor y el impacto futuro de lo comn y reutilizacin.
37.3.2 Mdulo Especificacin de procesos en el ADM

El proceso de definicin de bloque de construccin se lleva a cabo gradualmente a medida que la ADM es seguido, sobre todo en las fases A, B, C y D. Se trata de un proceso iterativo porque como definicin procede, informacin detallada sobre la funcionalidad requerida, las limitaciones impuestas a la arquitectura , y la disponibilidad de los productos puede afectar a la eleccin y el contenido de bloques de construccin. Las partes clave de la ADM en el que los bloques de construccin estn diseados y especificados se resumen a continuacin. La obra ms importante en estos pasos consiste en identificar los ABBS necesarios para cumplir con las metas y objetivos de negocio. El conjunto seleccionado de ABBS se refina en un proceso iterativo para llegar a un conjunto de SBB, que puede ser comprado o bien off-the-shelf o la costumbre desarrollada. La especificacin de la construccin de bloques utilizando el ADM es un proceso evolutivo e iterativo. Las fases y etapas del ADM en el que se desarrollaron y se especifican los bloques de construccin principales se resumen a continuacin, y se ilustran en la Figura 37-1 .
Pgina466de670

TOGOF9.1
Figura371:FasesADM/PasosclaveenlaquelosbloquesdeconstruccinestnEvolved/ especificado
Pgina467de670

TOGOF9.1
Parte V
Continuum Empresarial y Herramientas
Pgina468de670

TOGOF9.1
38. Introduccin
Este captulo proporciona una introduccin y una visin general de los contenidos de la Parte V: Empresa Continuum y Herramientas .
38.1 Introduccin
Por lo general es imposible crear una nica arquitectura unificada que rene todos los requisitos de todas las partes interesadas de todos los tiempos. Por lo tanto, la empresa arquitecto tendr que lidiar no slo con una nica arquitectura de la empresa, pero con muchas arquitecturas empresariales relacionados. Cada arquitectura tendr un propsito diferente y arquitecturas se relacionan entre s. Efectivamente delimita el mbito de aplicacin de una arquitectura , por tanto, es un factor crtico de xito en permitir que los arquitectos para romper un espacio de problemas complejos en componentes manejables que se pueden abordar de forma individual. The Enterprise Continuum ofrece una vista del Repositorio de Arquitectura que muestra la evolucin de estas arquitecturas relacionadas de genrico a lo especfico, de lo abstracto a concreto y de lgica fsica. Esta parte de TOGAF Enterprise Continuum discute; incluyendo el Continuum Arquitectura y el Continuum Solutions. En l se describe cmo las arquitecturas se pueden particionar y organizados dentro de un repositorio. Tambin se describen las herramientas para el desarrollo de la arquitectura.
38.2 Estructura de la Parte V

Parte V: Empresa Continuum y Herramientas se estructura de la siguiente manera: Introduccin (este captulo) The Enterprise Continuum (ver 39.EmpresaContinuum ) describe una vista del Repositorio de Arquitectura que proporciona mtodos para clasificar la arquitectura y los artefactos de la solucin, que muestra cmo los diferentes tipos de artefactos evolucionan, y cmo pueden ser aprovechados y reutilizados. Arquitectura Particionamiento (ver 40.Arquitecturadeparticionamiento ) describe las diversas caractersticas que se pueden aplicar para clasificar y luego arquitecturas de particin. La Arquitectura Repositorio (ver 41.ArquitecturaRepositorio ) muestra cmo las clasificaciones abstractas de la arquitectura se pueden aplicar a una estructura de repositorio para que las arquitecturas pueden ser organizadas y de fcil acceso.
Pgina469de670

TOGOF9.1
Herramientas para el desarrollo de la arquitectura (vase 42.Herramientasparaeldesarrollo delaarquitectura ) proporciona directrices sobre la seleccin de un conjunto de herramientas para crear y administrar los artefactos arquitectnicos.
Pgina470de670

TOGOF9.1
39. Continuum Empresarial

The Enterprise Continuum ofrece mtodos para clasificar la arquitectura y los artefactos de la solucin, tanto internos como externos en el Repositorio de Arquitectura, a medida que evolucionan a partir de genricos Arquitecturas Fundacin a las arquitecturas Organizacin Especficos. The Enterprise Continuum permite al arquitecto para articular la perspectiva amplia de qu, por qu, y cmo la arquitectura de la empresa ha sido diseado con los factores y los conductores considerados. The Enterprise Continuum es una ayuda importante para la comunicacin y el entendimiento, tanto dentro de las empresas individuales, y entre las empresas de los clientes y organizaciones de vendedores. Sin una comprensin de "qu lugar del continuum que eres", gente discutiendo la arquitectura a menudo pueden hablar con propsitos cruzados, ya que hacen referencia a diferentes puntos en el continuo, al mismo tiempo, sin darse cuenta. Cualquier arquitectura es un contexto especfico; Por ejemplo, hay arquitecturas que son especficos a los clientes individuales, industrias, subsistemas, productos y servicios. Arquitectos, tanto en el lado de la compra y el lado de la oferta, deben tener a su disposicin un lenguaje coherente para comunicar eficazmente las diferencias entre las arquitecturas. Tal lenguaje permitir eficiencia de la ingeniera y el aprovechamiento eficaz de Commercial Off-The-Shelf (COTS) la funcionalidad del producto. The Enterprise Continuum establece que un lenguaje coherente. The Enterprise Continuum permite a la organizacin de los artefactos de arquitectura reutilizables y activos de soluciones para maximizar las oportunidades de inversin de arquitectura empresarial.
39.2 de Enterprise Continuum y Arquitectura Re-Uso

La manera ms simple de pensar de la Empresa Continuum es como una vista del repositorio de todos los activos de la arquitectura. Puede contener descripciones de arquitectura, maquetas, bloques de construccin, modelos, puntos de vista, y otros artefactos - que existen tanto dentro de la empresa y en la industria de TI en general, que la empresa considere haya disponible para el desarrollo de arquitecturas para la empresa. Los ejemplos de artefactos de arquitectura y soluciones internas son los entregables del trabajo previo de la arquitectura, que estn disponibles para su reutilizacin.Los ejemplos de la arquitectura y la solucin artefactos externos son la gran variedad de modelos de
Pgina471de670

TOGOF9.1
referencia de la industria y los patrones de arquitectura que existen, y estn continuamente surgiendo, incluyendo aquellas que son muy genrico (como el modelo de referencia tcnica TOGAF (TRM)); las especficas de ciertos aspectos de la tecnologa (por ejemplo, una arquitectura de servicios web, o una arquitectura de gestin genricos); las especficas de ciertos tipos de tratamiento de la informacin, tales como el comercio electrnico, gestin de la cadena de suministro, etc; y las especficas de ciertas industrias verticales, como los modelos generados por consorcios verticales como TMF (en el sector de las Telecomunicaciones), ARTE (Retail), Energistics (petrotcnicos), etc La arquitectura de la empresa determina que la arquitectura y los artefactos de la solucin de una organizacin incluye en su arquitectura de repositorio. La reutilizacin es una consideracin importante en esta decisin.
39.3 Los constituyentes de la Empresa Continuum

Una visin general del contexto y de los constituyentes de la Empresa Continuum se muestra en la Figura 39-1 .
Figura391:EmpresaContinuum
Pgina472de670

TOGOF9.1
The Enterprise Continuum est dividida en tres continua distinta de la siguiente manera:
La empresa Continuum (ver 39.4EmpresaContinuumendetalle ) es el continuum ms externa y clasifica los activos relacionados con el contexto de la estructura general de la empresa. Las clases de Enterprise Continuum de activos pueden influir en las arquitecturas, pero no se utilizan directamente durante el desarrollo de la arquitectura ADM. The Enterprise Continuum clasifica los activos contextuales utilizados para desarrollar arquitecturas, como las polticas, normas, iniciativas estratgicas, estructuras organizativas y capacidades de nivel empresarial. The Enterprise Continuum tambin puede clasificar las soluciones (a diferencia de las descripciones o especificaciones de soluciones). Por ltimo, la empresa Continuum contiene dos especialidades, a saber, la Arquitectura y Soluciones Continua. La Arquitectura Continuum (ver 39.4.1ArquitecturaContinuum ) ofrece una manera consistente para definir y entender las reglas genricas, las representaciones y las relaciones en una arquitectura, incluyendo las relaciones de trazabilidad y de derivacin (por ejemplo, para demostrar que una Arquitectura Organizacin Especfico se basa en una industria o norma genrica). La Arquitectura Continuum representa una estructuracin de Arquitectura Bloques de Construccin (Abs) que son activos arquitectura reutilizables. ABBS evolucionan a travs de su ciclo de vida de desarrollo de entidades abstractas y genricas que expresan plenamente activos Organizacin de una arquitectura especfica. Los activos Arquitectura Continuum se utilizarn para orientar y seleccionar los elementos de la serie continua de soluciones (vase ms adelante). La Arquitectura Continuum muestra las relaciones entre los marcos fundamentales (como TOGAF), arquitecturas de sistemas comunes (como el III-RM), arquitecturas industriales y arquitecturas empresariales. La Arquitectura Continuum es una herramienta til para descubrir en comn y eliminar la redundancia innecesaria. El Continuum Soluciones (ver 39.4.2SolucionesContinuum ) proporciona una forma consistente para describir y comprender la aplicacin de los activos definidos en la Arquitectura Continuum. El Continuum Soluciones define lo que est disponible en el entorno de la organizacin como reutilizables Solution Building Blocks (SBB). Las soluciones son el resultado de acuerdos entre los clientes y los socios de negocios que implementan las reglas y relaciones definidas en el espacio de la arquitectura. El Continuum Soluciones aborda los aspectos comunes y las diferencias entre los productos, sistemas y servicios de los sistemas implementados.
The Enterprise Continuum clasifica los activos de arquitectura que son aplicables en todo el mbito de la arquitectura de la empresa. Estos activos, que pueden ser referidos como bloques de construccin, pueden representar una variedad de elementos que en conjunto definen y limitan la arquitectura empresarial. Ellos pueden tomar la forma de los objetivos de negocio y objetivos, iniciativas estratgicas, capacidades, polticas, normas y principios. The Enterprise Continuum tambin contiene el Continuum Arquitectura y el Continuum Solutions. Cada uno de estos Continua se describe en mayor detalle en las siguientes secciones.
Pgina473de670

TOGOF9.1
39.4 Continuum Empresarial en detalle

The Enterprise Continuum pretende representar la clasificacin de todos los activos que estn disponibles para una empresa. Clasifica los activos que existen dentro de la empresa junto con otros activos en el medio ambiente en general que son relevantes para la empresa, como los productos, la investigacin, los factores del mercado, factores comerciales, estrategias de negocios, y la legislacin. TOGAF pretende ser un marco para la realizacin de arquitectura de la empresa, y como resultado muchos de los activos que se encuentran dentro de la Empresa Continuum estn ms all de la consideracin especfica del marco TOGAF. Sin embargo, las arquitecturas estn conformadas fundamentalmente por las preocupaciones fuera de la prctica de la arquitectura y por lo tanto de suma importancia es que toda la arquitectura debe reflejar con precisin el contexto externo. Los factores contextuales especficas a ser identificados e incorporados en una arquitectura variarn desde la arquitectura a la arquitectura. Sin embargo, los factores contextuales tpicos para el desarrollo de la arquitectura es probable que incluyan:
Factores que influyen externos, como el cambio de reglamentacin, los avances tecnolgicos, y la actividad de la competencia Estrategia y el contexto de negocios, incluyendo fusiones, adquisiciones y otros requisitos de transformacin empresarial Operaciones de negocios actuales, lo que refleja las arquitecturas y soluciones implementadas
Al observar el contexto de la arquitectura, se puede observar que existe actividad de desarrollo de la arquitectura dentro de un ciclo de vida de la empresa ms amplia de cambio continuo. ABBS se definen en relacin a un conjunto de factores contextuales y luego se dio cuenta a travs de SBB. SBB se despliegan en forma de soluciones en vivo y se convierten en una parte del modelo de operacin de lnea de base de la empresa. El modelo de explotacin de la empresa y la informacin emprica sobre el desempeo de la empresa conforma el contexto y los requisitos para el cambio futuro. Por ltimo, estos nuevos requisitos para el cambio crean una retroalimentacin de lazo para influir en la creacin de nuevas arquitecturas de destino.
39.4.1 Arquitectura Continuum
La Arquitectura Continuum ilustra cmo se desarrollan y evolucionan las arquitecturas a travs de un continuo que va desde la Fundacin arquitecturas, como la proporcionada por TOGAF, a travs de los Sistemas Comunes de Arquitecturas y Industria Arquitecturas y las propias arquitecturas especficos de la organizacin de una empresa.
Pgina474de670

TOGOF9.1
Las flechas en el Continuum Arquitectura representan la relacin que existe entre las diferentes arquitecturas de la Arquitectura Continuum. La direccin hacia la izquierda se centra en satisfacer las necesidades de la empresa y los requerimientos del negocio, mientras que la direccin hacia la derecha se centra en el aprovechamiento de los componentes arquitectnicos y bloques de construccin.
Figura392:ArquitecturaContinuum
Las necesidades de la empresa y los requerimientos del negocio se abordan en detalle creciente de izquierda a derecha. El arquitecto tendr una apariencia tpica de encontrar elementos arquitectnicos reutilizables hacia la izquierda del continuo. Cuando no se encuentran elementos, los requisitos para los elementos que faltan se pasan a la izquierda de la continuo para su incorporacin. Esas arquitecturas de aplicacin dentro de sus propias organizaciones pueden utilizar los mismos modelos continuos especializados para su negocio. Los cuatro tipos de arquitectura particulares ilustradas en la Figura 39-2 estn destinados a indicar la gama de diferentes tipos de arquitectura que se puedan desarrollar en diferentes puntos en el continuo; que no son fijos etapas en un proceso. Muchos tipos diferentes de la arquitectura pueden ocurrir en los puntos entre las ilustradas en la Figura 39-2 . Aunque la serie continua transformacin evolutiva ilustrado no representa un proceso formal, representa una progresin, que se produce en varios niveles:
Lgico para fsica Horizontal (IT centrada) a vertical (centrado en las empresas) Generalizacin de la especializacin Taxonoma para completar y especificacin especfica de la arquitectura
En cada punto del continuo, una arquitectura est diseada en funcin de los conceptos de diseo y los mdulos disponibles y pertinentes a ese punto.
Pgina475de670

TOGOF9.1
Las cuatro arquitecturas ilustrados en la Figura 39-2 representan principales clasificaciones de las arquitecturas posibles, y sern relevantes y familiar para muchos arquitectos. Ellos se analizan en detalle a continuacin.
Fundacin Arquitectura
Una Fundacin de Arquitectura consta de componentes genricos, interrelaciones, principios y directrices que proporcionan una base sobre la que las arquitecturas ms especficas se pueden construir. El TOGAF ADM es un proceso que apoye la especializacin de dichas arquitecturas de la Fundacin con el fin de crear modelos especficos de la organizacin. El TOGAF TRM describe una arquitectura fundamental sobre el que pueden basarse otras arquitecturas, ms especficos. Ver 43. Fundacin Arquitectura: Tcnico Modelo de Referencia para ms detalles.
Sistemas Comunes Arquitecturas
Sistemas Comunes Arquitecturas guiar la seleccin e integracin de los servicios especficos de la Architecture Foundation para crear una arquitectura til para la construccin de soluciones comunes (es decir, altamente reutilizables) en una amplia serie de mbitos pertinentes. Ejemplos de sistemas comunes Arquitecturas incluyen: un ttulo de arquitectura, una arquitectura de gestin, una arquitectura de red, una arquitectura operaciones, etc Cada uno es incompleto en trminos de funcionalidad general del sistema, pero es completa en trminos de un dominio determinado problema (seguridad, capacidad de gestin, la creacin de redes, operaciones, etc), por lo que las soluciones que implementan la arquitectura constituyen bloques de construccin reutilizables para la creacin de estados de funcionamiento funcionalmente completos de la empresa. Otras caractersticas de los sistemas comunes Arquitecturas incluyen:
Refleja los requisitos especficos de un dominio del problema genrico Define componentes bsicos especficos de un dominio del problema genrico Define los estndares de negocios, datos, aplicaciones, o de tecnologa para la implementacin de estos bloques de construccin Proporciona elementos bsicos para los gastos fciles reutilizacin y bajos
El TOGAF Integrado de Informacin de Referencia Infraestructura Modelo (III-RM) vase la parte VI , 44. Integrado de Informacin Infraestructura Modelo de referencia- es un modelo de referencia que apoya la descripcin de los sistemas de Common Architecture en el dominio
Pgina476de670

TOGOF9.1
de aplicacin que se centra en los requisitos, bloques de construccin, y las normas relativas a la visin del flujo de informacin sin fronteras.
Arquitecturas de la Industria
Arquitecturas Industria guan la integracin de los componentes de los sistemas comunes con componentes especficos de la industria, y orientar la creacin de soluciones de la industria para los problemas de los clientes especficos dentro de una industria en particular. Un ejemplo tpico de un componente especfico de la industria es un modelo de datos que representa las funciones y los procesos de negocio especficos de un sector vertical en particular, como la arquitectura de la industria al por menor "Activo tienda", o un Sector Arquitectura que incorpora el modelo de datos Energistics (consulte www.energistics.org ). Otras caractersticas de la Industria Arquitecturas incluyen:
Refleja los requisitos y las normas especficas de un sector vertical Define componentes bsicos especficos de un dominio del problema genrico Contiene datos lgicos especficos de la industria y modelos de procesos Contiene aplicaciones especficas de la industria y modelos de procesos, as como las reglas de negocio especficos de la industria Proporciona directrices para las pruebas de las colecciones de los sistemas Alienta a los niveles de interoperabilidad en toda la industria Arquitecturas-organizacin especfica
Arquitecturas especficos de la organizacin describen y guan la implementacin final de componentes de la solucin para una empresa en particular o red de empresas conectadas extendido. Puede haber una variedad de arquitecturas de Organizacin-especficas que se necesitan para cubrir eficazmente las necesidades de la organizacin mediante la definicin de las arquitecturas de los crecientes niveles de detalle. Alternativamente, esto podra dar lugar a varias arquitecturas ms detallados-organizacin especfica para entidades especficas dentro de la empresa global. Desglosando Arquitecturas-organizacin especfica en piezas constituyentes se aborda en el 40. Arquitectura de particionamiento . La Arquitectura Organizacin-especfico gua la personalizacin final de la solucin, y tiene las siguientes caractersticas:
Pgina477de670

TOGOF9.1
Proporciona un medio para comunicar y gestionar las operaciones de negocio a travs de las cuatro reas de arquitectura Refleja los requisitos especficos para una empresa en particular Define bloques de construccin especficos para una empresa en particular Contiene modelos de negocio especficos de la organizacin, datos, aplicaciones y tecnologas Proporciona un medio para fomentar la implementacin de soluciones adecuadas para satisfacer las necesidades empresariales Proporciona los criterios para medir y seleccionar los productos adecuados, soluciones, y servicios Proporciona un camino evolutivo para apoyar el crecimiento y las nuevas necesidades de la empresa
39.4.2 Soluciones Continuum
El Continuum Soluciones representa la especificacin detallada y la construccin de las arquitecturas en los niveles correspondientes de la Arquitectura Continuum. En cada nivel, el Continuum Solutions es una poblacin de la arquitectura con bloques de construccin de referencia - bien los productos comprados o componentes integrados - que representan una solucin a las necesidades de negocio de la empresa expresaron en ese nivel. Un repositorio poblada basado en el Continuo Soluciones puede considerarse como un inventario de soluciones o re-uso de la biblioteca, que se puede aadir un valor significativo a la tarea de gestionar e implementar mejoras a la empresa. El Continuum Soluciones se ilustra en la Figura 39-3 .

Figura393:SolucionesdeContinuidad
"Mover a la derecha" en el Continuo Soluciones se centra en proporcionar soluciones de valor (es decir, las soluciones de cimentacin proporcionan valor en la creacin de soluciones de sistemas comunes; soluciones de sistemas comunes se utilizan para crear soluciones de la industria, y las soluciones industriales que se utilizan para crear soluciones
Pgina478de670

TOGOF9.1
especficas de la organizacin ). "Mover a la izquierda" en el Continuo Soluciones se centra en hacer frente a las necesidades empresariales. Estos dos puntos de vista son importantes para una empresa tratando de centrarse en sus necesidades y aumentar al mximo el uso de los recursos disponibles a travs del apalancamiento. Los apartados siguientes describen cada uno de los tipos de soluciones dentro del Continuum Solutions.
Soluciones Fundacin
Soluciones Fundacin son conceptos muy genricos, herramientas, productos, servicios y componentes de la solucin, que son los proveedores fundamentales de capacidades. Los servicios incluyen servicios profesionales - tales como la capacitacin y servicios de consultora - que garantizan el valor mximo de inversin de las soluciones en el menor tiempo posible; y servicios de apoyo - como el Help Desk - que garantizan el mximo valor posible de las soluciones (servicios que aseguran las actualizaciones oportunas y mejoras de los productos y sistemas). Soluciones Ejemplo Fundacin incluiran los lenguajes de programacin, sistemas operativos, estructuras de datos fundamentales (como EDIFACT), enfoques genricos organizacin estructuracin, estructuras fundamentales para la organizacin de las operaciones de TI (como ITIL), etc
Sistemas Comunes Soluciones
Una solucin comn de sistemas es una implementacin de un sistema de arquitectura comn compuesto por un conjunto de productos y servicios, que pueden ser certificados o con la marca. Representa el mximo comn denominador para una o ms soluciones en los segmentos de la industria que la solucin de los Sistemas Comunes apoya. Sistemas Comunes Soluciones representan colecciones de requisitos y capacidades comunes, en lugar de los especficos de un cliente o industria en particular.Sistemas Comunes soluciones proporcionan a las organizaciones con entornos operativos especficos para las necesidades operativas y de informacin, como la alta disponibilidad de los sistemas de almacenamiento de datos escalable de procesamiento de transacciones y. Ejemplos de sistemas comunes de soluciones incluyen: un producto de sistema de gestin de la empresa o un producto de sistema de seguridad. Proveedores de sistemas informticos son los proveedores tpicos de centradas en la tecnologa de sistemas comunes Solutions. "Software como servicio" proveedores son proveedores habituales de las soluciones de aplicaciones comunes. Proveedores de
Pgina479de670

TOGOF9.1
outsourcing de procesos de negocios son tpicas del negocio proporciona capacidad centrada en sistemas comunes Solutions.
Soluciones para la Industria
Una solucin de la Industria es una implementacin de una Arquitectura de la Industria, que ofrece paquetes reutilizables de componentes y servicios comunes especficos para una industria. Componentes fundamentales son proporcionados por sistemas comunes Soluciones y / o Fundacin Solutions, y se complementan con los componentes especficos de la industria. Los ejemplos incluyen: un esquema de base de datos fsica o un dispositivo de punto de servicio especfico de la industria. Soluciones para la industria son especficas de la industria, las compras agregadas que estn listos para ser adaptado a las necesidades de una organizacin individual. En algunos casos, una solucin de la industria puede incluir no slo una implementacin de la arquitectura de la Industria, pero tambin otros elementos de la solucin, como los productos especficos, servicios y soluciones de sistemas que sean apropiadas a esa industria.
Solutions-organizacin especfica
Una solucin-organizacin especfica es una implementacin de la arquitectura de la Organizacin especfica que proporciona las funciones de la empresa necesarios.Dado que las soluciones estn diseadas para operaciones especficas de negocio, que contienen la mayor cantidad de contenido nico con el fin de dar cabida a las personas y los procesos de las organizaciones especficas que varan. Soluciones Building Organizacin especficas sobre Soluciones para la industria, sistemas comunes Soluciones y Fundacin Solutions es el principal propsito de conectar el Continuum Arquitectura al Continuum Solutions, como guiado por los arquitectos dentro de una empresa. Una solucin-organizacin especfica se estructura con el fin de apoyar los acuerdos especficos Nivel de Servicio (SLA) para asegurar el apoyo de los sistemas operativos en los niveles de servicio deseados. Por ejemplo, una aplicacin de terceros proveedor de alojamiento puede ofrecer diferentes niveles de apoyo a los sistemas operativos. Estos acuerdos definen los trminos y condiciones de ese apoyo. Otros factores clave que deben ser definidos dentro de una solucin de Organizacin Especficos son los parmetros operativos clave y mtricas de calidad que pueden utilizarse para controlar y gestionar el medio ambiente.
Pgina480de670

TOGOF9.1
The Enterprise Continuum puede proporcionar un enlace clave entre la arquitectura, el desarrollo, y el personal de operaciones por lo que les permite comunicarse y llegar a un acuerdo sobre los requisitos de apoyo operacionales previstos. El personal de operaciones a su vez puede acceder al Enterprise Continuum para obtener informacin con respecto a los conceptos de operacin y requisitos de compatibilidad de servicios del sistema implementado.
39.5 La Empresa Continuum y el ADM

El TOGAF ADM describe el proceso de desarrollo de una arquitectura especfica de la empresa y una solucin (s) especfica de la empresa que se ajustan a la arquitectura mediante la adopcin y la adaptacin (en su caso) arquitecturas y soluciones (de izquierda a derecha en la clasificacin continua) genricos. De manera similar, las arquitecturas y soluciones especficas que han demostrado ser efectivos y crebles sern generalizados para su reutilizacin (de derecha a izquierda en la clasificacin continua). En los lugares pertinentes en todo el TOGAF ADM, hay punteros a los activos de arquitectura tiles al nivel pertinente de generalidad en la clasificacin continuum. En algunos casos - por ejemplo, en el desarrollo de una arquitectura Tecnologa - esto puede ser la Fundacin Arquitectura TOGAF TRM (ver ms abajo). 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. S TOGAF ofrece dos modelos de referencia para la consideracin para su uso en el desarrollo de la arquitectura de una organizacin:
1. La Fundacin Arquitectura TOGAF , que comprende una TRM de los servicios y
funciones genricas que proporciona una base firme sobre la cual las arquitecturas ms especficos y componentes arquitectnicos se pueden construir.
2. La Integrado de Informacin de Referencia Infraestructura Modelo (III-RM), que se

basa en la Fundacin Arquitectura TOGAF, y est especficamente diseado para ayudar a la realizacin de arquitecturas que permiten y apoyan la visin de Flujo de informacin sin fronteras.
Sin embargo, en el desarrollo de las arquitecturas de los distintos dominios dentro de una arquitectura global de la empresa, el arquitecto tendr que considerar el uso y re-uso de una amplia variedad de diferentes activos de la arquitectura, y la Empresa Continuum ofrece un enfoque para clasificar y comunicar estos diferentes activos .
39.6 La Empresa Continuum y su organizacin

Las secciones anteriores han descrito la empresa Continuum, la Arquitectura Continuum, y el Continuum Solutions. Las siguientes secciones describen las relaciones entre cada uno de los tres continuos y cmo deben aplicarse estas relaciones dentro de su organizacin.
Pgina481de670

TOGOF9.1 39.6.1 Relaciones
Cada uno de los tres continuos contiene informacin acerca de la evolucin de las arquitecturas durante su ciclo de vida:
The Enterprise Continuum ofrece un contexto general de las arquitecturas y soluciones y clasifica los activos que se aplican en todo el mbito de la empresa. La Arquitectura Continuum proporciona un mecanismo de clasificacin de los activos que definen colectivamente la arquitectura en diferentes niveles de evolucin de genrico a lo especfico. El Continuum Soluciones ofrece la clasificacin de los activos para describir las soluciones especficas para la organizacin que pueden ser implementadas para lograr el propsito de la arquitectura.
Las relaciones entre el Continuum Arquitectura y Soluciones Continuum se muestran en la Figura 39-4 .
Figura394:LasrelacionesentrelaarquitecturaySolucionesContinua
La relacin entre la arquitectura y el Continuum Continuum Solutions es una de orientacin, direccin y apoyo. Por ejemplo, la Fundacin Arquitecturas guan la creacin o seleccin de la Fundacin Solutions. Soluciones Fundacin de Apoyo a la Architecture Foundation, ayudando a comprender la arquitectura definida en la Arquitectura Continuum. La Architecture Foundation tambin gua el desarrollo de la Fundacin Solutions, proporcionando arquitectnicos de direccin, los requisitos y los principios que guan la seleccin y realizacin de soluciones apropiadas. Una relacin similar existe entre los otros elementos de la empresa Continuum.
Pgina482de670

TOGOF9.1
The Enterprise Continuum presenta mecanismos para ayudar a mejorar la productividad a travs del apalancamiento. La Arquitectura Continuum ofrece una manera consistente para entender las diferentes arquitecturas y sus componentes. El Continuum Soluciones ofrece una manera consistente para entender los diferentes productos, sistemas, servicios y soluciones que se requieren. The Enterprise Continuum no se debe interpretar como la representacin de las relaciones estrictamente encadenados. Arquitecturas especficos de la organizacin pueden tener componentes de una arquitectura comn de sistemas y soluciones de Organizacinespecficas podran contener soluciones Fundacin. Las relaciones que se muestran en la figura 39-1 son una ilustracin que muestra las oportunidades para el aprovechamiento de los componentes de la arquitectura y de la solucin.
39.6.2 Su Empresa
TOGAF proporciona un mtodo para que usted pueda "arquitecto" de los sistemas de su empresa. Su organizacin arquitectura tendr que hacer frente a cada tipo de arquitectura se ha descrito anteriormente. Por ejemplo, se recomienda que usted tiene su propio Architecture Foundation que rige todos sus sistemas. Usted tambin debe tener sus propias arquitecturas de sistemas comunes que rigen los principales sistemas compartidos - como el sistema de red o sistema de gestin. Usted puede tener sus propias arquitecturas especficas de la industria que rigen la forma en que sus sistemas deben comportarse dentro de su industria. Por ltimo, cualquier departamento u organizacin dentro de su negocio puede necesitar su propia Arquitectura-Organizacin Especfica individuo para gobernar los sistemas dentro de ese departamento. Su organizacin arquitectura o bien adoptar o adaptar las arquitecturas existentes, o desarrollar sus propias arquitecturas desde cero. En cualquier caso, TOGAF es una herramienta para ayudar. Proporciona un mtodo para ayudarle a generar / mantener cualquier tipo de arquitectura dentro de la Arquitectura Continuum tiempo de aprovechar los activos de arquitectura ya definidos, interno o externo a la organizacin. El TOGAF ADM que a los activos de arquitectura reutilizar ayuda, por lo que su organizacin arquitectura ms eficiente y eficaz.
Pgina483de670

TOGOF9.1
40. Arquitectura de particionamiento

Las particiones se utilizan para simplificar el desarrollo y la gestin de la arquitectura empresarial. Las particiones se encuentran en la base de la arquitectura de la gobernanza y son distintos de los niveles y los conceptos organizadores del Continuum Arquitectura (ver 39. Empresa Continuum ). Arquitecturas estn divididas debido a que:
Arquitecturas de unidad organizativa en conflicto entre s. Los diferentes equipos tienen que trabajar en los diferentes elementos de la arquitectura al mismo tiempo y particiones permiten a grupos especficos de los arquitectos poseen y desarrollan los elementos especficos de la arquitectura. Arquitectura reutilizacin efectiva requiere segmentos modulares de arquitectura que pueden adoptarse e incorporarse en las arquitecturas y soluciones ms amplias.
No es prctico para presentar un modelo de particin definitiva de la arquitectura. Cada empresa tiene que adoptar un modelo de particin que refleja su propio modelo de funcionamiento. Este captulo trata de los criterios de clasificacin que se aplican en general a las arquitecturas y cmo estos se pueden aprovechar para dividir la empresa en un conjunto de arquitecturas con complejidad manejable y una gobernanza eficaz.
40.2 Clasificacin Aplicar para crear arquitecturas con particiones

Por las razones expuestas en la seccin anterior, es valioso para dividir y organizar la empresa Continuum en un conjunto de soluciones y arquitecturas relacionadas con:
Complejidad manejable para cada arquitectura o solucin individual Agrupaciones definidas Jerarquas definidas y estructuras de navegacin Procesos adecuados, roles y responsabilidades adjuntas a cada agrupacin
Pgina484de670

TOGOF9.1
La siguiente tabla muestra cmo los criterios de clasificacin adecuados pueden ser utilizados para apoyar el particionamiento de soluciones:
Caracterstica Uso de Apoyo a la Solucin de particionamiento Asunto (Manga) Las soluciones se organizan naturalmente en grupos para apoyar la gestin operativa y control. Ejemplos de particiones de soluciones de acuerdo a la materia incluiran aplicaciones, departamentos, divisiones, productos, servicios, centros de servicio, sitios, etc Descomposicin de soluciones por tema suele ser la tcnica fundamental para la estructuracin de las dos soluciones y las arquitecturas que las representan. Los ciclos de vida de la solucin se suelen organizar en torno a una lnea de tiempo, lo que permite que el impacto del desarrollo de la solucin, implantacin, operacin y retiro para ser manejado contra otra actividad econmica que ocurre en perodos de tiempo similares. La madurez y la volatilidad de una solucin tpicamente afectar la velocidad de ejecucin necesaria para el ciclo de vida de la solucin. Adems, la volatilidad y la madurez darn forma a las prioridades de inversin. Soluciones existentes en entornos altamente voltiles pueden ser ms adecuados para, tcnicas de desarrollo gil rpidos. La siguiente tabla muestra cmo cada criterio de clasificacin se pueden utilizar para apoyar el particionamiento de arquitecturas:
Tiempo
Vencimiento / Volatilidad
Caracterstica Uso de fomentar una arquitectura de particionamiento Profundidad El nivel de detalle dentro de una arquitectura tiene una fuerte correlacin con los grupos de inters que estn interesados en la arquitectura. Arquitecturas Tpicamente menos detallados sern de inters para las partes interesadas ejecutivos. Como arquitecturas aumentan en detalle, su relevancia para la implementacin y el personal de operaciones tambin se incrementar.
Pgina485de670

TOGOF9.1
En trminos prcticos, la arquitectura disciplina se utiliza para soportar un nmero de diferentes tipos de arquitectura que se utilizan para diferentes objetivos. Los criterios de clasificacin antes mencionados, pueden ser utilizados en diferentes formas de apoyar el logro de cada objetivo. Las siguientes caractersticas no se utilizan para dividir una Arquitectura del Paisaje:
Arquitecturas utilizadas para describir la arquitectura del paisaje en general, no son abstractos. Volatilidad Solucin general evita las arquitecturas de ser definido, que estn lejos en el futuro. La volatilidad tambin reduce la precisin de los edificios histricos en el tiempo, ya que los cambios en la organizacin y se adapta a las nuevas circunstancias.
El uso de los criterios anteriores, las arquitecturas se pueden agrupar en las particiones.
40.2.1 Las actividades dentro de la Etapa Preliminar
El objetivo clave de la Etapa Preliminar es establecer la capacidad Arquitectura para la empresa. En la prctica esta actividad requerir el establecimiento de un nmero de particiones de arquitectura, proporcionando lmites definidos, gobierno y propiedad. En trminos generales, cada equipo que lleva a cabo la actividad de la arquitectura dentro de la empresa ser propietaria de una o ms particiones de arquitectura y ejecutar el ADM de definir, gobernar, y hacer realidad sus arquitecturas. Si se espera que ms de un equipo para trabajar en una sola arquitectura, esto puede llegar a ser problemtico, ya que las responsabilidades precisas de cada equipo son difciles de establecer. Por esta razn, es preferible aplicar la particin a la arquitectura hasta cada arquitectura tiene un equipo propietaria. Por ltimo, vale la pena considerar la distincin entre las capacidades permanentes de la empresa y los equipos temporales movilizados para apoyar una iniciativa de cambio en particular. Aunque las competencias de los equipos permanentes dentro de la empresa se puede definir con precisin, es ms difcil de prever y especificar las responsabilidades de (posiblemente desconocidos) equipos de arquitectura de carcter temporal. En los casos de estos equipos temporales, cada equipo debe venir bajo el gobierno de un equipo de arquitectura en pie y debe haber un proceso dentro del ciclo de ADM de estos equipos para establecer particin arquitectura apropiada. Pasos en la Etapa Preliminar para apoyar la arquitectura de particin son los siguientes:
Determinar la estructura de la organizacin para la arquitectura dentro de la empresa : Los diversos equipos permanentes que va a crear la arquitectura deben ser identificados. Para cada uno de estos equipos, los lmites apropiados deben ser establecidos, incluyendo:
Pgina486de670

TOGOF9.1
o Los rganos de gobierno que son aplicables al equipo o de miembros del equipo o Equipo de las lneas de responsabilidad Determinar las responsabilidades de cada equipo de arquitectura de pie : Para cada equipo de arquitectura, las responsabilidades deben ser identificados.Este paso se aplica la lgica de reparticin en la arquitectura de la empresa con el fin de identificar en primer lugar, el alcance de cada equipo y en segundo lugar a la particin de la arquitectura bajo el mandato de un solo equipo. Una vez completado, este paso debera haber particionado todo el mbito de la empresa y debera haber asignado la responsabilidad para cada arquitectura particionada a un solo equipo. El particionamiento debe crear una definicin de cada arquitectura que incluya: o reas temticas estn cubiertos o Nivel de detalle que el equipo trabajar en o Los perodos de tiempo que deben cubrirse o Grupos de Inters Determinar las relaciones entre arquitecturas : Una vez que se ha creado un conjunto de arquitecturas con particiones, las relaciones entre las arquitecturas deben desarrollarse. Este paso permite que las relaciones de gobernanza para formalizarse y tambin muestra donde los artefactos de una arquitectura se espera que sean reutilizados en otras arquitecturas. reas de consideracin incluyen: o Dnde se superponen diferentes arquitecturas / cola de milano / drill-down? o Cules son los requisitos de cumplimiento entre las arquitecturas?
Una vez que la fase preliminar se completa, los equipos a cargo de la arquitectura debe entenderse. Cada equipo debe tener un alcance definido y las relaciones entre los equipos y la arquitectura debe ser entendido. Asignacin de equipos a alcance arquitectura se muestra en la Figura 40-1 .
Pgina487de670

TOGOF9.1
Figura401:AsignacindeequiposaArquitecturaAlcance
40.3 Integracin
La creacin de arquitecturas con particiones corre el riesgo de producir una coleccin fragmentada y desarticulada de las arquitecturas que no pueden integrarse para formar un panorama general (ver Parte II , 5.6 Arquitectura de Integracin ). 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. Arquitecturas federados normalmente se utilizan en los gobiernos y los conglomerados, donde las unidades organizativas separadas necesitan arquitecturas diferentes. Dicho marco especifica los principios de interoperabilidad, la 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 . Con el fin de mitigar este riesgo, las normas para la integracin de contenidos deben ser definidos y la gobernanza arquitectura deben abordar la integracin de contenidos como condicin para el cumplimiento de la arquitectura. Marcos de contenido, tales como el marco TOGAF contenido (consulte la Parte IV: Marco de Arquitectura de contenido ) se puede utilizar para especificar bloques de construccin estndar y artefactos que son objeto de las normas de integracin de contenidos. Por ejemplo, un catlogo estndar de los procesos de negocio puede ser acordado por una empresa. Arquitecturas posteriores a continuacin pueden facilitar la integracin mediante
Pgina488de670

TOGOF9.1
el uso de la misma lista de procesos y referencias cruzadas a otros aspectos de la arquitectura de los procesos estndar. La integracin puede ser dirigido desde un nmero de dimensiones:
Integracin a travs de los dominios de arquitectura proporciona una vista en corte de dominio del estado de un segmento de la empresa para un punto en el tiempo. Integracin a travs del mbito organizativo de la empresa proporciona una vista en corte del segmento de la empresa. El Architecture Vision proporciona un resumen integral de la arquitectura Definiciones, que proporcionan un resumen integrado de Transicin Arquitecturas. La Figura 40-2 muestra cmo el contenido arquitectnico se puede agregar utilizando una variedad de tcnicas.
Figura402:ArquitecturadeAgregacindeContenidos
Pgina489de670

TOGOF9.1
41. Arquitectura Repositorio

El funcionamiento de una Arquitectura Capability madura dentro de una gran empresa crea un enorme volumen de la produccin arquitectnica. La gestin eficaz y el apalancamiento de estos productos de trabajo de arquitectura requieren una taxonoma formal para los diferentes tipos de activos de arquitectura junto a los procesos y herramientas dedicadas para el almacenamiento de contenido arquitectnico. Esta seccin de TOGAF proporciona un marco estructural para un repositorio de Arquitectura que permite a una empresa para distinguir entre diferentes tipos de activos arquitectnicas que existen en diferentes niveles de abstraccin en la organizacin. Este repositorio de arquitectura es una parte de la ms amplia Enterprise Repository, que proporciona la capacidad de vincular elementos arquitectnicos a los componentes del diseo detallado, distribucin y servicio de administracin de repositorios. A un alto nivel, se espera que seis clases de informacin arquitectnica que se celebrar dentro de un repositorio de Arquitectura:
La Arquitectura Metamodel describe la aplicacin organizativo adaptado de un marco de arquitectura, incluyendo un mtodo para el desarrollo de la arquitectura y un metamodelo para el contenido de la arquitectura. La Capacidad de Arquitectura define los parmetros, estructuras y procesos que ayuden a la gobernabilidad de la arquitectura de repositorio. La arquitectura del paisaje presenta una representacin arquitectnica de los activos en uso, o previsto, por la empresa en determinados puntos en el tiempo. La Base de informacin de Normas captura las normas que deben cumplir las nuevas arquitecturas, que pueden incluir normas de la industria, los productos y servicios seleccionados de proveedores o servicios compartidos ya desplegados dentro de la organizacin. La Biblioteca de Referencia proporciona directrices, plantillas, patrones y otras formas de material de referencia que se puede aprovechar el fin de acelerar la creacin de nuevas arquitecturas para la empresa. El Gobierno Log proporciona un registro de la actividad de gobierno en toda la empresa.
Las relaciones entre estas reas del Repositorio de Arquitectura se muestran en la Figura 411.
Pgina490de670

TOGOF9.1
Figura411:Visingeneraldelaarquitecturaderepositorio
Esta seccin de TOGAF describe la estructura y el contenido de las reas de depsito que tienen la salida de los proyectos, es decir, la arquitectura del paisaje, la Biblioteca, la Base de informacin de normas y el registro de la gobernanza. Esta seccin, adems, los requisitos que deben considerarse al seleccionar las herramientas para la gestin de un repositorio de Arquitectura.

La Arquitectura del Paisaje tiene vistas arquitectnicas del estado de la empresa en determinados puntos en el tiempo. Debido a la gran cantidad y las diversas necesidades de los interesados a lo largo de toda la empresa, la arquitectura del paisaje se divide en tres niveles de granularidad:
1. Arquitecturas Estratgicas (ver ParteI , 3,70ArquitecturaEstratgica ) muestran una vista
de resumen a largo plazo de toda la empresa. Arquitecturas estratgicos proporcionan un
Pgina491de670

TOGOF9.1
marco de organizacin de la actividad operativa y el cambio y permiten una configuracin de direccin a nivel ejecutivo.
2. Arquitecturas del segmento (vase laParteI , Arquitectura3.62Segmento ) proporcionar

modelos operativos ms detallados para las reas dentro de una empresa.Arquitecturas del segmento se pueden utilizar a nivel de programa o de una cartera de organizar y operativamente alinear actividad de cambio ms detallada.
3. Arquitecturas de capacidad (vase laParteI , Arquitectura3,27Capability ) muestran de

una forma ms detallada cmo la empresa puede soportar una unidad particular de la capacidad. Arquitecturas de capacidad se utilizan para proporcionar una visin general de la capacidad de corriente, capacidad de objetivo, y los incrementos de capacidad y permitir paquete de obras y proyectos a ser agrupados dentro de las carteras y los programas gestionados.
41.3 Referencia de la Biblioteca

La Biblioteca proporciona un depsito para contener los materiales de referencia que se deben utilizar para desarrollar arquitecturas. Materiales de referencia de que se pueden obtener a partir de una variedad de fuentes, incluyendo:
Los organismos de normalizacin De productos y servicios proveedores Comunidades o foros de la industria Las plantillas estndar Mejores prcticas empresariales
La Biblioteca debe contener:

Arquitecturas de Referencia Modelos de Referencia Biblioteca Mirador Plantillas Nota: Los trminos arquitectura de referencia y modelo de referencia no se utilizan con cuidado en la mayora de la literatura. Arquitectura de referencia y modelo de referencia tienen la misma relacin que la arquitectura y el modelo. Cualquiera puede existir como un estado genrico o especfico de la organizacin. Tpicamente,un genrico arquitectura de referencia proporciona el equipo de arquitectura con un esbozo de su arquitectura de referencia especfica de la organizacin que se personaliza para una organizacin especfica. Por ejemplo, un genrico arquitectura de referencia puede identificar que existe
Pgina492de670

TOGOF9.1
una necesidad de modelos de datos.Una organizacin que selecciona el SID del TMF como un modelo de datos de referencia es la creacin de una arquitectura de referencia especficos de cada organizacin.
Con el fin de separar las diferentes clases de materiales de referencia de arquitectura, la Biblioteca puede utilizar el Continuum La arquitectura como un mtodo para la clasificacin.
Figura412:ArquitecturaContinuum
La Arquitectura Continuum, como se muestra en la Figura 41-2 , se puede ver como un esquema de clasificacin Reference Library. Como tal, ilustra cmo las arquitecturas de referencia se pueden organizar a travs de una gama - desde la Fundacin Arquitecturas y Arquitecturas especficos de la industria, para una Arquitectura Organizacin Especfico. Las necesidades de la empresa y los requerimientos del negocio se abordan en la disminucin de la abstraccin de izquierda a derecha. El arquitecto tendr tpicamente encontrar ms elementos arquitectnicos reutilizables hacia la izquierda de la gama. Cuando no se encuentran elementos, los requisitos para los elementos que faltan se pasan a la izquierda de la gama para su incorporacin. A travs de este ejercicio, es importante tener en cuenta los conceptos de niveles y particiones. En diferentes niveles de granularidad puede existir materiales de referencia apropiados para el nivel, y las particiones dentro de la arquitectura del paisaje se puede esperar para utilizar el material de referencia diferente (ver 40. Arquitectura de particionamiento y la Parte III , 20. Aplicando la ADM a travs de la Arquitectura del Paisaje ).
41.4 Normas de Informacin de Base

La Base de informacin de Normas proporciona un rea de depsito para contener un conjunto de especificaciones, a la que deben ajustarse las arquitecturas.Establecimiento de
Pgina493de670

TOGOF9.1
una base de informacin de Normas proporciona una base inequvoca para la gobernanza de la arquitectura debido a que:
Las normas son de fcil acceso a los proyectos y, por tanto, las obligaciones del proyecto pueden ser comprendidas y previstas para Las normas se establecen en forma clara e inequvoca, de modo que el cumplimiento se puede evaluar objetivamente
41.4.2 Tipos de Norma
Normas normalmente se dividen en tres clases:

Obligaciones legales y reglamentarias : Estas normas son obligatorias por ley y, por tanto, una empresa debe cumplir o enfrentar graves consecuencias. Estndares de la industria : Estas normas son establecidas por organismos de la industria, tales como The Open Group, y luego son seleccionados por la empresa para su aprobacin. Estndares de la industria ofrecen un potencial para la interoperacin y compartir a travs de las empresas, sino que tambin quedan fuera del control de la empresa y, por tanto, se debe supervisar de manera activa. Normas de organizacin : Estas normas se establecen dentro de la organizacin y se basan en la aspiracin de la empresa (por ejemplo, la seleccin de las aplicaciones estndar de apoyo a la cartera de consolidacin). Normas de organizacin requieren procesos para permitir exenciones y normas evolucin.
Normas 41.4.3 Ciclo de Vida
Normas generalmente no existen para todos los tiempos. . Las nuevas normas se identifican y gestionan a travs de un proceso de ciclo de vida general, las normas pasan a travs de las siguientes etapas:
Norma : Norma potencial ha sido identificado por la organizacin, pero que an no ha sido evaluada para su aprobacin. Norma Provisional (tambin conocido como un estndar de prueba ): Un estndar provisional ha sido identificado como un posible estndar para la organizacin, pero no se ha probado a un nivel en el que su valor se entiende completamente. Los proyectos que deseen adoptar las Normas provisionales podrn hacerlo, pero bajo condiciones experimentales especficas, por lo que la viabilidad de la norma puede ser examinado con ms detalle. Estndar (tambin conocido como un estndar activo ): Una Norma define una solucin de la corriente principal que se debe utilizar generalmente como el enfoque de eleccin. Supresin gradual estndar (tambin conocido como un estndar de Deprecated ): Un estndar Phasing-Out se acerca al fin de su ciclo de vida til. Los proyectos que se reutilizando componentes existentes en general, puede seguir haciendo uso de la supresin gradual de las Normas. Despliegue de nuevas instancias de la Norma Phasing-Out son generalmente desalentada.
Pgina494de670

TOGOF9.1
Estndar Retirado (tambin conocido como un estndar obsoleto ): Un estndar Retirado ya no es aceptada como vlida en el paisaje. En la mayora de los casos, se deben tomar medidas correctivas para eliminar la Norma Retirado del paisaje. Cambio de la actividad en un estndar Jubilado slo debe ser aceptado como parte de un plan general de desmantelamiento.
Todas las normas deben ser revisadas peridicamente para asegurar que se sientan en el lado derecho del escenario del ciclo de vida de normas. Como parte de la gestin del ciclo de vida de las normas, el impacto de cambiar el estado del ciclo de vida debe ser dirigida a comprender el impacto paisajstico de un cambio de las normas y el plan de accin adecuado para abordarlo.
41.4.4 Normas de Clasificacin dentro de la Base de Informacin de Normas
Normas dentro de la Base de informacin de normas se clasifican de acuerdo a los bloques de construccin dentro del contenido metamodelo TOGAF. Cada entidad metamodelo puede potencialmente tener estndares asociados (por ejemplo, servicios de negocios, Componente Tecnologa). Las normas pueden relacionarse con bloques de construccin (por ejemplo, una lista de componentes de tecnologa estndar) "aprobado" o puede especificar el uso adecuado de un bloque de construccin (por ejemplo, los escenarios donde la infraestructura de mensajera es el caso, las normas de comunicacin de aplicacin se definen). En el nivel superior, las normas se clasifican de acuerdo con los mbitos de arquitectura TOGAF, incluyendo las siguientes reas:
Normas Comerciales : o Norma comparti las funciones de negocio o definiciones de roles y actores estndar o normas de gobierno para la actividad empresarial y de Seguridad Estndares de Datos : o la codificacin y valores de datos estndar o estructuras y formatos de datos estndar o Normas de origen y la propiedad de los datos o restricciones a la reproduccin y el acceso Aplicaciones Estndares : o aplicaciones estndar / compartidos que apoyan las funciones de negocio especficas
Pgina495de670

TOGOF9.1
o Normas para la comunicacin de solicitud y la interoperacin o Normas de acceso, presentacin y estilo Estndares de Tecnologa ; o Los productos de hardware estndar o Los productos de software estndar o Normas para el desarrollo de software
41.5 Gobierno Entrar

El Gobierno de registro proporciona un rea repositorio para almacenar la informacin compartida en relacin con la gobernanza en curso de los proyectos. El mantenimiento de un repositorio compartido de informacin de gobierno es importante, debido a que:
Las decisiones tomadas durante los proyectos (por ejemplo, desviaciones estndares o la justificacin de un enfoque arquitectnico particular) son importantes para retener y acceder en forma permanente. Por ejemplo, si un sistema se va a sustituir, que tiene la vista de las decisiones arquitectnicas clave que dieron forma a la implementacin inicial es muy valiosa, ya que pondr de relieve las limitaciones que de otra manera puedan estar tapados. Muchos actores estn interesados en los resultados de gestin del proyecto (por ejemplo, otros proyectos, los clientes del proyecto, el Consejo de Arquitectura, etc.)
41.5.2 Contenido de la sesin de Gobierno
El Registro de la gobernanza debe contener los siguientes elementos:

Decisin Log :. Un registro de todas las decisiones de gran importancia arquitectnica que se han hecho en la organizacin Esto suele incluir: o selecciones de producto o Justificacin de las principales caractersticas arquitectnicas de proyectos o desviaciones de Normas o Normas cambios de ciclo de vida o Solicitud de cambio de las evaluaciones y aprobaciones o evaluaciones de Re-uso Evaluaciones de cumplimiento : En el puesto de control hitos clave en el progreso de un proyecto, una revisin formal de la arquitectura se llevarn a cabo. . Esta revisin se mida
Pgina496de670

TOGOF9.1
la conformidad del proyecto con los estndares de arquitectura definidos para cada proyecto, este registro debe incluir: o Visin general del proyecto o visin Progreso (lnea de tiempo, estado, problemas, riesgos, dependencias, etc) o listas de control completadas arquitectura o Los estndares de evaluacin del cumplimiento o Acciones recomendadas Evaluaciones de capacidad : En funcin de sus objetivos, algunos proyectos se llevar a cabo evaluaciones de los negocios, o Arquitectura de capacidad. . Estas evaluaciones deben llevarse a cabo peridicamente y realiza un seguimiento para asegurar que se est logrando progreso adecuado Este registro debe incluir: o Los modelos de referencia para la ejecucin de evaluaciones de capacidad Plantillas y o evaluaciones de la capacidad de Empresas o evaluaciones de la capacidad de TI, de madurez y de impacto o evaluaciones de madurez Arquitectura Calendario : El calendario debera mostrar un calendario de proyectos en vuelo y las sesiones formales de revisin, que se celebrar en contra de estos proyectos. Cartera de Proyectos : La cartera de proyectos debe contener informacin resumida acerca de todos los proyectos en vuelo que se incluyen en la gobernanza de arquitectura, incluyendo: o El nombre y la descripcin del proyecto o mbito arquitectnico del proyecto o Los roles y las responsabilidades asociadas con el proyecto arquitectnico Medicin del desempeo : En base a un estatuto de la funcin de la arquitectura, por lo general se define una serie de criterios de rendimiento. El registro de medicin del desempeo debe capturar las mtricas relacionadas para que el rendimiento puede ser medido y evaluado de forma continua a la gobernanza y cualquier otra medida de rendimiento en relacin con la carta de la arquitectura del proyecto.
41.6 El Enterprise Repository

Mientras que el Repositorio de Arquitectura contiene informacin relativa a la arquitectura de la empresa y los artefactos asociados hay un nmero considerable de repositorios empresariales que apoyan la arquitectura. Esto incluye los requisitos requisitos de acopio de repositorio y el Depsito Soluciones de almacenamiento Soluciones Building Blocks (SBB). Ver Figura 41-1 .
Pgina497de670

TOGOF9.1
Los resultados de negocio para los requisitos se reflejarn en el Repositorio de soluciones a travs del tiempo. Cuando esto ocurre se cumplen y se archivan para fines de auditora con los requisitos.
41.6.1 Requisitos Repositorio
El Repositorio de Requisitos es utilizado por la fase de gestin de requisitos del Mtodo de Desarrollo de Arquitectura (ADM) para registrar y gestionar toda la informacin pertinente a las necesidades de la arquitectura. Los requisitos frente a los muchos tipos de requisitos de arquitectura; es decir, los requisitos, estratgicos y de capacidad de segmento que son los motores principales de la arquitectura de la empresa. Los requisitos pueden ser recogidos en todas las etapas del ciclo de vida del desarrollo de la arquitectura y deben ser aprobados a travs de las diferentes fases y procesos de gobernanza.
41.6.2 Soluciones Repositorio
El Repositorio Soluciones mantiene los bloques de construccin de la solucin (SBB).
41.7 Repositorios externos

41.7.1 Modelos de referencia externos
Hay muchos modelos de referencia de la industria disponibles que pueden ayudar a comprender el papel de los y el desarrollo de las arquitecturas de referencia. Los ejemplos incluyen MDA de OMG, FEA de Gobierno de los EE.UU., TMF de la industria de las telecomunicaciones, los modelos de referencia de SOA de OASIS y The Open Group.
Normas externos 41.7.2
Estos se refieren a la industria, mejores prcticas o estndares definidos formales utilizados por organizaciones lderes. Los ejemplos incluyen ISO, IEEE, y las normas gubernamentales.
Aprobaciones 41.7.3 Arquitectura de la Junta
Las decisiones tomadas por el Consejo de Arquitectura que afectan a la arquitectura de la empresa a menudo se registran en las actas de las reuniones. Estas actas se celebran a menudo en los archivos de documentacin que estn excluidos de la Arquitectura Repositorio por motivos legales o reglamentarios.
Pgina498de670

TOGOF9.1
42. Herramientas para el Desarrollo de la Arquitectura

Como un marco de arquitectura empresarial, TOGAF proporciona una base para el desarrollo de arquitecturas de una manera uniforme y consistente. Su objetivo en este sentido es asegurar que las diversas descripciones de arquitectura desarrollados dentro de una empresa, tal vez por diferentes arquitectos o equipos de arquitectura, soportan la comparacin y la integracin de arquitecturas de dentro y fuera de los dominios de la arquitectura (de negocios, datos, aplicaciones, tecnologa), y en relacin a diferentes mbitos de la zona de negocios dentro de la empresa. Para apoyar este objetivo, TOGAF define numerosos productos en forma de arquitecturas, representados como modelos de arquitectura, vistas de la arquitectura de los modelos, y otros artefactos. Con el tiempo, estos artefactos se convierten en un recurso que debe ser gestionado y controlado, en particular con vistas a su reutilizacin. Este concepto se refiere el TOGAF como la "Empresa Continuum". Modelos de arquitectura y las vistas son discutidos en detalle por separado en la Parte IV , 35. Architectural Artifacts . Esta seccin trata sobre las consideraciones en la eleccin de las herramientas automatizadas para generar este tipo de modelos de arquitectura y vistas, y para su mantenimiento en el tiempo.
42.2 Problemas de la Herramienta de Normalizacin

En el estado actual del mercado de herramientas, muchas empresas de desarrollo de arquitecturas empresariales luchan con el tema de la estandarizacin de herramientas, ya sea que busquen un solo "una talla para todos" herramienta o un conjunto multiherramienta para el modelado de arquitecturas y la generacin de los diferentes puntos de vista de arquitectura requerida. Hay ventajas aparentes asociadas con la seleccin de una sola herramienta. Organizaciones siguientes tal poltica puede aspirar a obtener beneficios tales como reduccin de la formacin, las licencias compartidas, descuentos por cantidad, el mantenimiento y el intercambio de datos ms fcil. Sin embargo, tambin hay razones para negarse a identificar a una sola herramienta mandato, incluyendo razones de principio (que respaldan una nica herramienta de la arquitectura no alentara la innovacin comercial competitiva o el desarrollo de la capacidad de la herramienta avanzada); y el hecho de que una sola herramienta no tendra en cuenta una variedad de desarrollo de la arquitectura "niveles de madurez" y necesidades especficas a travs de una empresa.
Pgina499de670

TOGOF9.1
Equipos de arquitectura empresarial de xito son a menudo los que armonicen sus herramientas de arquitectura con su nivel de arquitectura madurez, equipo / capacidades organizacionales y los objetivos o el enfoque. Si diferentes organizaciones dentro de una empresa se encuentran en diferentes niveles de madurez de la arquitectura y tener diferentes objetivos o enfoque (por ejemplo, la empresa frente a la Empresa frente Architecture Technology), se hace muy difcil para una herramienta para satisfacer las necesidades de todas las organizaciones.
Pgina500de670

TOGOF9.1
PARTE VI Modelos TOGAF Referencia
Pgina501de670

TOGOF9.1
. 43 Architecture Foundation: Referencia tcnica Modelo

En este captulo se describe el modelo de referencia tcnica (TRM), incluida la taxonoma bsica, la representacin grfica y la detallada taxonoma plataforma. La taxonoma detallada plataforma se describe en 43.5 Taxonoma Plataforma detallada .
43.1 Conceptos
En esta seccin se describe el papel de la TRM, los componentes de la TRM, y el uso de otros TRM.
43.1.1 Funcin de la TRM en la Architecture Foundation
La Fundacin Arquitectura TOGAF es una arquitectura de servicios genricos y las funciones que proporciona una base sobre la que las arquitecturas ms especficos y componentes arquitectnicos se pueden construir. Esta Architecture Foundation se encarna en el modelo de referencia tcnica (TRM), que proporciona un modelo y taxonoma de los servicios de la plataforma genricos. El TRM es universalmente aplicable y, por lo tanto, se puede utilizar para construir cualquier arquitectura de sistema.
43.1.2 TRM Componentes
Cualquier TRM tiene dos componentes principales:

1. Una taxonoma , que define la terminologa, y proporciona una descripcin coherente de los componentes y la estructura conceptual de un sistema de informacin 2. Un asociado grfico TRM , que proporciona una representacin visual de la taxonoma, como una ayuda para la comprensin
El objetivo de la TOGAF TRM es proporcionar un ampliamente aceptado taxonoma ncleo, y una representacin visual apropiada de que la taxonoma. El grfico TRM se ilustra en 43,3 TRM en detalle , y la taxonoma se explica en un 43,4 Application Platform Taxonoma .
43.1.3 Otros TRM
Una de las grandes dificultades en el desarrollo de un marco de arquitectura es en la eleccin de una TRM que funcione para todos.
Pgina502de670

TOGOF9.1
El TOGAF TRM fue derivado originalmente de la Arquitectura del marco de Tcnico de Gestin de la Informacin (TAFIM) TRM (que a su vez se deriva del modelo de IEEE 1003.0). Esta TRM es "plataforma-centric": se centra en los servicios y la estructura de la plataforma subyacente necesario para apoyar el uso y la reutilizacin de aplicaciones (es decir, la portabilidad de la aplicacin). En particular, se centra en las interfaces entre la plataforma y que las aplicaciones soportadas, y entre la plataforma y el medio ambiente externo. La corriente TOGAF TRM es una versin modificada de la TAFIM TRM, que tiene como objetivo hacer hincapi en el aspecto de la interoperabilidad, as como el de la portabilidad. El objetivo de la TRM es permitir definicin estructurado de la plataforma de aplicaciones estandarizada y sus interfaces asociadas. El resto de entidades, que son necesarios en cualquier arquitectura especfica, slo se abordan en la TRM en la medida en que influyen en la plataforma de aplicaciones. El objetivo que subyace en este enfoque es asegurar que los bloques de construccin de alto nivel que constituyen soluciones de negocio tienen una completa plataforma slida sobre la que ejecutar. Otros modelos arquitectnicos - taxonomas y / o grficos - no slo son posibles, pero puede ser preferible para algunas empresas. Por ejemplo, un modelo de este tipo especfico de la empresa podra ser derivado por extensin o adaptacin del TOGAF TRM. Alternativamente, una taxonoma diferente puede ser realizada en el legado de la obra arquitectnica anterior por una empresa, y la empresa puede preferir a perpetuar el uso de esta taxonoma. Del mismo modo, una empresa puede preferir para representar la taxonoma TOGAF (o su propia taxonoma) utilizando una forma diferente de grfico, que capta mejor los conceptos heredados y resulta ms fcil para los propsitos de comunicacin interna. Adems de su uso como un modelo de referencia para el desarrollo de la arquitectura de la tecnologa, la TRM se puede utilizar como una taxonoma para desarrollar una Base de Informacin de Normas (SIB) dentro de una organizacin especfica. El ncleo de TOGAF es su ADM: el TRM es una herramienta utilizada en la aplicacin de la ADM en el desarrollo de arquitecturas especficas. Coherencia prevista entre TRM y SIB se mantienen, el TOGAF ADM es vlida cualquiera que sea la eleccin de la taxonoma especfica, TRM grfico, o SIB conjunto de herramientas.
43.2 Desglose de Alto Nivel

En esta seccin se describen los principales elementos de la TRM.
El detalle ms gruesa de la TRM se muestra en la Figura 43-1 , que muestra tres entidades principales (software de aplicacin, la plataforma de aplicaciones y la infraestructura de
Pgina503de670

TOGOF9.1
comunicaciones) conectados por dos interfaces (Plataforma de Aplicaciones de Interfaz y Comunicaciones Interfaz de Infraestructura).

Figura431:ReferenciatcnicaModelodeAltoNiveldeVista
El diagrama no dice nada acerca de las relaciones detalladas entre las entidades; slo que ellos existen. Cada uno de los elementos de este diagrama se discute en detalle en el 43,3 TRM en detalle .
43.2.2 Portabilidad e Interoperabilidad
La TRM de alto nivel busca destacar dos importantes objetivos arquitectnicos comunes:
1. Portabilidad de aplicaciones , a travs de la plataforma de interfaz de aplicacin - la
identificacin del conjunto de servicios que van a ser puestos a disposicin en una forma estndar de aplicaciones a travs de la plataforma
2. Interoperabilidad , a travs de la interfaz de comunicaciones Infraestructura - la

identificacin del conjunto de servicios de infraestructura de comunicaciones que han de ser aprovechados de una manera estndar por la plataforma
Pgina504de670

TOGOF9.1
Ambos objetivos son esenciales para permitir la integracin dentro de la empresa y la interoperabilidad de confianza a escala mundial entre las empresas. En particular, el modelo de alto nivel busca reflejar el papel cada vez ms importante de Internet como base para la interoperabilidad inter e intra-empresa. La dimensin horizontal de la modelo en la Figura 43-1 representa la diversidad, y la forma del modelo se pretende hacer hincapi en la importancia de la diversidad mnima en la interfaz entre la plataforma de aplicaciones y la infraestructura de comunicaciones. Esto a su vez significa centrarse en el conjunto bsico de servicios que pueden ser garantizados con el apoyo de todas las redes basadas en IP, como la base sobre la que construir entornos informticos empresariales interoperables de hoy.
43.3 TRM en detalle

En esta seccin se describe la TRM en detalle, incluyendo las categoras de servicios de plataforma y entorno externo sub-entidades.
43.3.1 Introduccin
Figura 43-2 se expande en la Figura 43-1 para presentar las categoras de servicios de la plataforma de aplicaciones y las dos categoras de software de aplicacin.
Pgina505de670

TOGOF9.1
Figura432:Modelodereferenciatcnicadetallada(MostrandoCategorasdeservicio) Figura 43-2 es slo una representacin de las entidades de TRM: ni implica ni inhibe las
interrelaciones entre ellos. Arquitecturas de TI derivados de TOGAF pueden variar considerablemente en funcin de los requisitos del sistema de informacin. En la prctica, muchas arquitecturas no incluirn todos los servicios aqu descritos, y muchos van a incluir servicios adicionales para apoyar el software de aplicacin que es especfico de la organizacin o de su industria vertical. En la construccin de una arquitectura , los usuarios de TOGAF deben evaluar sus propias necesidades y seleccionar los servicios, interfaces y estndares que satisfagan sus propias necesidades de negocio.
43.3.2 Entidades TRM e Interfaces
Las secciones siguientes describen en detalle cada elemento de la TRM se ilustra en la Figura 43-2 . Ambos se incluyen en el siguiente orden:
Las tres entidades:
Pgina506de670

TOGOF9.1
o software de aplicacin (ver 43.3.3AplicacindeSoftware ) o plataforma de aplicaciones (ver 43.3.4ApplicationPlatform ) o infraestructura de comunicaciones (ver 43.3.5InfraestructuradeComunicaciones ) Las dos interfaces: o Aplicacin Interface Platform (ver 43.3.6AplicacinInterfacePlatform ) o Interfaz de infraestructura de comunicaciones (ver 43.3.7InterfazdeComunicaciones Infraestructura )
43.3.3 Aplicacin de Software
La TRM detallada reconoce dos categoras de Software de aplicacin:

1. Aplicaciones empresariales , que implementan negocio procesos para una empresa en
particular o sector vertical. La estructura interna de las aplicaciones de negocio se relaciona estrechamente con la configuracin de software de aplicacin especfico seleccionado por una organizacin.
2. Aplicaciones de Infraestructura , que proporcionan funcionalidad empresarial de uso general, con base en los servicios de infraestructura.
Durante el desarrollo de la arquitectura de la tecnologa, aplicaciones de negocios y aplicaciones de infraestructura son importantes fuentes de requisitos para los servicios de arquitectura de la tecnologa, y la seleccin de las normas para la plataforma de aplicaciones se vern influenciados fuertemente por la configuracin del software de aplicacin para ser admitido.
43.3.3.1 Aplicaciones empresariales
Las aplicaciones empresariales son las aplicaciones que son especficas de una empresa en particular o industria vertical. . Dichas aplicaciones suelen modelar elementos de dominio de una empresa de actividad o proceso de negocios Ejemplos de las aplicaciones de negocio pueden incluir:
Servicios de gestin de archivo de historias clnicas utilizadas en la industria mdica Servicios de gestin de inventario utilizados en la industria al por menor Servicios de modelado de datos geolgicos utilizados en la industria del petrleo
Con el tiempo, las aplicaciones de negocio en particular puede convertirse en aplicaciones de infraestructura, si llegan a ser lo suficientemente ubicuos, interoperables y de propsito general que es potencialmente til para una amplia gama de usuarios de TI de la empresa.
43.3.3.2 Aplicaciones Infraestructura
Pgina507de670

TOGOF9.1
Aplicaciones de infraestructura son las aplicaciones que tienen todas, o casi todas, de las siguientes caractersticas:
La amplia disponibilidad como Commercial Off-The-Shelf (COTS) de software significa que es poco rentable para considerar la implementacin personalizada. La interaccin del usuario es una parte importante de la funcin de la aplicacin. Las implementaciones se basan en los servicios de infraestructura. Las implementaciones pueden incluir extensiones significativas ms all de la necesaria para utilizar los servicios de infraestructura subyacentes. La interoperabilidad es un requisito fuerte.
Ejemplos de las aplicaciones en esta categora incluyen:

Servicios de pago y transferencia electrnica de fondos Servicios de cliente de correo electrnico Publicar y suscribirse Los agentes inteligentes Servicios de calendario y programacin Servicios Groupware Los servicios de flujo de trabajo Hojas de clculo El software de presentacin Edicin de documentos y presentacin Aplicaciones de gestin, sistema de uso general rendimiento y gestin de redes funciones para el administrador del sistema Herramientas de ingeniera de software, proporcionando funciones de desarrollo de software para el personal de desarrollo de sistemas
Aplicaciones de infraestructura tienen fuertes dependencias de servicios de nivel inferior en la arquitectura. Por ejemplo, una aplicacin de flujo de trabajo puede utilizar los servicios de la plataforma, como la mensajera o el procesamiento de transacciones para implementar el flujo de trabajo entre tareas. Del mismo modo, una aplicacin de trabajo en grupo es probable que hacer un uso extensivo de los datos y servicios de comunicacin para la estructura de los documentos, as como la mecnica de almacenar y acceder a ellos. Aplicaciones de infraestructura, por definicin, son aplicaciones que se consideran suficientemente ubicuos, interoperables y de uso general dentro de la empresa puedan
Pgina508de670

TOGOF9.1
considerarse de hecho como parte de la infraestructura de TI. Al igual que las aplicaciones de negocio pueden con el tiempo llegan a ser consideradas como aplicaciones de infraestructura, por lo que las aplicaciones de infraestructura suelen ser candidatos para ser incluidos como servicios de infraestructura en las futuras versiones de un TI arquitectura.
43.3.4 Plataforma de Aplicaciones
43.3.4.1 Plataforma Concept
El trmino "plataforma" se utiliza de muchas maneras diferentes en la industria de TI hoy en da. Debido a los diferentes usos, el trmino a menudo calificado; por ejemplo, "la plataforma de aplicaciones", "normalizado" y "plataformas propietarias", "cliente" y "plataformas de servidor", "plataforma informtica distribuida", "plataforma de portabilidad". Comn a todos estos usos es la idea de que alguien necesita un conjunto de servicios prestados por un determinado tipo de plataforma, y pondr en marcha una funcin de "alto nivel" que hace uso de esos servicios. El TOGAF TRM se centra en la plataforma de aplicaciones, y la "funcin de nivel superior" es el conjunto de software de aplicacin, que se ejecuta en la parte superior de la plataforma de aplicaciones, que se necesita para hacer frente a los requerimientos del negocio de la empresa. Es importante reconocer que la plataforma de aplicaciones en el TOGAF TRM es un genrico, entidad, conceptual. Desde el punto de vista de la TOGAF TRM, la Plataforma de Aplicaciones contiene todos los servicios posibles. En una arquitectura especfica de destino, la plataforma de aplicaciones contendr slo aquellos servicios necesarios para apoyar las funciones requeridas. Por otra parte, la plataforma de aplicaciones para una arquitectura especfica Target normalmente no ser una entidad nica, sino ms bien una combinacin de diferentes entidades para diferentes funciones ms necesarias, como cliente de escritorio, servidor de archivos, servidor de impresin, servidor de aplicaciones, servidor de Internet, bases de datos servidor, etc, cada uno de los cuales estar integrado por un conjunto especfico, definido de servicios necesarios para apoyar la funcin especfica de que se trate. Tambin es importante reconocer que muchos de los sistemas de TI del mundo real que sean comprados y utilizados en la actualidad para implementar una arquitectura de tecnologa estn totalmente equipadas con numerosos servicios avanzados, que a menudo se dan por sentados por el comprador. Por ejemplo, un sistema de ordenador de sobremesa tpico de hoy viene con el software que implementa los servicios de la mayora, si no todas las categoras de servicios de la TOGAF TRM. Dado que el comprador de un sistema de este tipo a menudo no se considera nada "ms pequeo" que el paquete total de servicios que viene con el sistema, ese paquete de servicio puede llegar a ser muy fcilmente la "plataforma". En efecto, en ausencia de una Arquitectura Tecnolgica para guiar el proceso
Pgina509de670

TOGOF9.1
de adquisicin, esto es, invariablemente, lo que sucede. Como este proceso se repite en toda la empresa, los diferentes sistemas adquiridos para funciones similares (como el cliente de escritorio, servidor de impresin, etc) pueden contener marcadamente diferentes paquetes de servicios. Paquetes de servicios estn representados en una Arquitectura Tecnolgica en forma de "bloques de construccin". Una de las tareas clave del arquitecto de TI para pasar de la plataforma de aplicaciones conceptual de la TRM para una Arquitectura Tecnolgica especfica de la empresa es mirar ms all del conjunto de plataformas del mundo real que ya existen en la empresa. El arquitecto de TI debe analizar los servicios realmente necesarios a fin de implementar una infraestructura de TI que cumpla con los requerimientos del negocio de la empresa en la forma ptima, y para definir el conjunto de ptimas soluciones de Bloques de Construccin (SBB) - en el mundo real "plataformas" para poner en prctica esa arquitectura.
43.3.4.2 La extensin de la TRM
El TOGAF TRM identifica un conjunto genrico de servicios de la plataforma, y proporciona una taxonoma en la que estos servicios de la plataforma se dividen en categoras de funcionalidad similar. Una organizacin en particular puede que tenga que aumentar este conjunto con servicios adicionales o categoras de servicios que se consideran ser genricos en su propio segmento de mercado vertical. El conjunto de servicios identificados y definidos para la plataforma de aplicaciones va a cambiar con el tiempo. Se necesitarn nuevos servicios como aparece la nueva tecnologa y a medida que cambian las necesidades de aplicacin.
43.3.4.3 Interfaces entre Servicios
Adems de apoyar el software de aplicacin a travs de la plataforma de aplicaciones de interfaz (API), los servicios de la plataforma de aplicaciones pueden apoyarse unos a otros, ya sea mediante interfaces especificadas abiertamente lo que puede o no ser la misma que la API, o por interfaces no expuestas privadas. Un objetivo clave del desarrollo de la arquitectura es para mdulos de servicios sean capaces de sustitucin por otros mdulos que proporcionan la misma funcionalidad del servicio a travs de la misma API de servicio. El uso de las interfaces privadas, sin impresionar entre mdulos de servicio puede comprometer la capacidad de sustituir. Interfaces privadas representan un riesgo que debe ser resaltado para facilitar la futura transicin.
43.3.4.4 Desarrollos futuros
La TRM se ocupa de la futura evolucin de la plataforma de aplicaciones de dos formas. En primer lugar, como las interfaces con los servicios que se estandaricen, funcionalidad que formaba parte anteriormente de la entidad de software de aplicacin migra a formar parte
Pgina510de670

TOGOF9.1
de la plataforma de aplicaciones. En segundo lugar, la TRM se puede ampliar con nuevas categoras de servicios que aparece una nueva tecnologa. Ejemplos de reas funcionales que pueden incluirse en las categoras de servicio de la plataforma de aplicaciones en el futuro incluyen:
Funciones de hoja de clculo, incluyendo la capacidad de crear, manipular y presentar la informacin en tablas o grficos; esta capacidad debe incluir la capacidad de habla como de cuarta generacin que permiten el uso de la lgica de programacin dentro de las hojas de clculo Funciones de apoyo a las decisiones, incluidas las herramientas que apoyan la planificacin, administracin y gestin de proyectos Funciones de clculo, incluyendo la capacidad de realizar clculos aritmticos rutinarias y complejas Funciones de calendario, incluyendo la capacidad para gestionar proyectos y horarios coordinados a travs de un calendario automatizado
Una taxonoma detallada de la plataforma de aplicaciones se da en el 43,4 Application Platform - Taxonoma .

43.3.5 Comunicaciones Infraestructura
La infraestructura de comunicaciones proporciona los servicios bsicos para la interconexin de sistemas y proporcionar los mecanismos bsicos para la transferencia de datos opaco. Contiene los elementos de hardware y software que forman los enlaces de comunicaciones en red y fsicos utilizados por el sistema, y por supuesto todos los otros sistemas conectados a la red. Tiene que ver con el complejo mundo de las redes y la infraestructura de comunicaciones fsico, incluyendo interruptores, proveedores de servicios y los medios de transmisin fsica. Un conductor primario en Arquitectura Tecnologa de toda la empresa en los ltimos aos ha sido la creciente conciencia de la utilidad y el costo-efectividad de Internet como la base de una infraestructura de comunicaciones para la integracin de la empresa. Esto est causando un rpido aumento en el uso de Internet y un aumento constante en la gama de aplicaciones que unen a la red para el servicio descentralizado. Esto se considera an ms en 43.3.7 Interfaz de Comunicaciones Infraestructura .
43.3.6 Aplicacin Interface Platform
La plataforma de interfaz de aplicaciones (API) especifica una interfaz completa entre el software de aplicacin y la plataforma de aplicaciones subyacente a travs del cual se proporcionan los servicios. Una definicin rigurosa de los resultados de la interfaz en portabilidad de la aplicacin, a condicin de que tanto la plataforma y la aplicacin se
Pgina511de670

TOGOF9.1
ajustan a la misma. Para que esto funcione, la definicin de la API debe incluir la sintaxis y la semntica de no slo la interfaz de programacin, sino tambin todo el protocolo necesario y definiciones de estructuras de datos. Portabilidad depende de la simetra de la conformidad de las aplicaciones y de la plataforma a la API con arquitectura. Es decir, la plataforma debe ser compatible con la API de lo especificado, y la aplicacin debe utilizar no ms de la API especificada. El API especifica una interfaz completa entre una aplicacin y uno o ms servicios que ofrece la plataforma de aplicaciones subyacente. Una aplicacin puede utilizar varios APIs, y puede incluso utilizar diferentes APIs para implementaciones diferentes de un mismo servicio.
Interface 43.3.7 Comunicaciones Infraestructura
La interfaz de la infraestructura de comunicaciones es la interfaz entre la plataforma de aplicaciones y la infraestructura de comunicaciones.

Figura 43-1 busca reflejar el papel cada vez ms importante de Internet como base para la interoperabilidad inter e intra-empresa. La dimensin horizontal de la modelo en la Figura 431 representa la diversidad, y la forma de la modelo est destinado especficamente para enfatizar la diversidad mnima en la interfaz entre la plataforma de aplicaciones y la infraestructura de comunicaciones.
En particular, el modelo hace hincapi en la importancia de centrarse en el conjunto bsico de servicios que pueden ser garantizados con el apoyo de todas las redes basadas en IP, como la base sobre la que construir entornos informticos empresariales interoperables de hoy.
43.3.8 Cualidades
Adems del conjunto de componentes que forman el TRM, hay un conjunto de atributos o cualidades que son aplicables a todos los componentes. Por ejemplo, para el servicio de gestin para ser eficaz, capacidad de gestin debe ser una cualidad omnipresente de todos los servicios de la plataforma, aplicaciones y servicios de infraestructura de comunicaciones.
Figura 43-2 capta este concepto representa los componentes de TRM se sientan en un plano
posterior de cualidades. Otro ejemplo de una calidad de servicio es la seguridad. La aplicacin adecuada de todo el sistema de seguridad requiere no slo un conjunto de servicios de seguridad, que corresponden a la categora de los servicios de seguridad se muestra en la plataforma, sino tambin el apoyo (es decir, la "conciencia de seguridad") de software en otras partes de la
Pgina512de670

TOGOF9.1
TRM. Por lo tanto, una aplicacin podra utilizar un servicio de seguridad para marcar un archivo como de slo lectura, pero es la aplicacin correcta de la calidad de la seguridad en los servicios del sistema operativo que impide que las operaciones de escritura en el archivo. Servicios de seguridad y del sistema operativo deben cooperar para hacer el archivo seguro. Cualidades se especifican en detalle durante el desarrollo de una arquitectura de destino. Algunas cualidades son ms fciles que otros para describir en trminos de estndares. Por ejemplo, el apoyo de un conjunto de locales se puede definir como parte de la especificacin de la calidad a escala internacional. Otras cualidades mejor pueden especificarse en trminos de medidas en lugar de los estndares. Un ejemplo sera el rendimiento, para el que las API o protocolos estndar son de uso limitado.
43.4 Plataforma de Aplicaciones - Taxonoma

En esta seccin se describe la taxonoma plataforma de aplicaciones, incluidos los principios fundamentales y un resumen de los servicios y calidades. Una taxonoma detallada de servicios de la plataforma y cualidades se puede encontrar en 43,5 Taxonoma Plataforma detallada .
43.4.1 Principios bsicos
El TOGAF TRM tiene dos componentes principales:

1. Una taxonoma , que define la terminologa, y proporciona una descripcin coherente de los componentes y la estructura conceptual de un sistema de informacin 2. Un asociado grfico TRM , que proporciona una representacin visual de la taxonoma, como una ayuda para la comprensin
En esta seccin se describe en detalle la taxonoma del TOGAF TRM. El objetivo es proporcionar una taxonoma central que proporciona una definicin til, coherente y estructurado de la entidad Plataforma de aplicaciones y es ampliamente aceptable. No se hacen afirmaciones que la clasificacin elegida es la nica posible, o que representa la mejor opcin. De hecho, es importante hacer hincapi en que el uso de TOGAF, y, en particular, el TOGAF ADM, es de ninguna manera depende del uso de la taxonoma TOGAF TRM. Otros taxonomas son perfectamente posibles, y pueden ser preferibles para algunas organizaciones. Por ejemplo, una taxonoma diferente puede ser realizada en el legado de la obra arquitectnica anterior por una organizacin, y la organizacin puede preferir a perpetuar el uso de esta taxonoma. Alternativamente, una organizacin puede decidir que se puede
Pgina513de670

TOGOF9.1
derivar una taxonoma especfica de la organizacin ms adecuada mediante la extensin o adaptacin de la taxonoma TOGAF TRM. De la misma manera, una organizacin puede preferir para representar la taxonoma TOGAF (o su propia taxonoma) utilizando una forma diferente de grfico TRM, que capta mejor los conceptos heredados y resulta ms fcil para los propsitos de comunicacin interna.
43.4.2 Aplicacin de Servicios Plataforma Categoras
Las principales categoras de servicios definidos para la plataforma de aplicaciones se enumeran a continuacin. Tenga en cuenta que "los servicios de objetos" no aparece como una categora de la taxonoma TRM. Esto se debe a que todos los servicios de objetos individuales se incorporan en las principales categoras de servicios pertinentes. Sin embargo, las diversas descripciones tambin se recogen en un nico apartado (vase 43.4.2.1 orientada a objetos Prestacin de Servicios ) con el fin de proporcionar un nico punto de referencia que muestra cmo los servicios de objetos relacionados con las principales categoras de servicios.
Servicios de Intercambio de Datos (ver 43.5.1Serviciosdedatosdeintercambio ): o Documentar los servicios de tipos de datos y conversin genricos o servicios de intercambio de datos grficos o servicios de intercambio de datos especializadas o servicios de intercambio electrnico de datos o Los servicios de fax o funciones de la interfaz grfica Raw o funciones de procesamiento de texto o funciones de procesamiento de documentos o Las funciones de publicacin o funciones de procesamiento de vdeo o funciones de procesamiento de audio o funciones de procesamiento multimedia o funciones de sincronizacin de medios o funciones de presentacin y distribucin de informacin
Pgina514de670

TOGOF9.1
o funciones de hipertexto Servicios de gestin de datos (vase 43.5.2Serviciosdegestindedatos ): o diccionario de datos / servicios de repositorio o Sistema de Gestin de Base de Datos de los servicios (DBMS) o servicios de Sistema de Gestin de Base de datos orientada a objetos (SGBDOO) o Los servicios de gestin de archivos o funciones de procesamiento de consultas o funciones de generacin de pantalla o Informe funciones de generacin de o Redes funciones de acceso / concurrentes o las funciones de almacenamiento Grficos y Servicios de imgenes (vase 43.5.3Grficosyserviciosdeimgenes ): o Los servicios de gestin grfica de objetos o servicios de Dibujo o funciones de imagen Servicios Internacionales de la operacin (ver 43.5.4InternacionalesServiciosdeOperacin ): o Los conjuntos de caracteres y servicios de representacin de datos o Los servicios de convenciones Cultural o Los servicios de apoyo en el idioma local Ubicacin y servicios de directorio (vase 43.5.5Ubicacinyserviciosdedirectorio ): o Los servicios de directorio o Los servicios de nombres para usos especiales o los servicios de ubicacin de servicio o Los servicios de inscripcin o Los servicios de filtrado o Servicios de contabilidad Servicios de red (vase 43.5.6Serviciosdered ): o Los servicios de comunicaciones de datos
Pgina515de670

TOGOF9.1
o los servicios de correo electrnico o servicios de datos distribuidos o servicios de archivos distribuidos o servicios de nombres distribuidos o servicios de tiempo Distribuido o servicios de procesos a distancia (acceso) o Los servicios de cola de impresin remota y la distribucin de salidas o funciones de telefona mejoradas o funciones de la pantalla compartida o funciones de conferencia de vdeo o funciones de difusin o funciones de la lista de correo Servicios del sistema operativo (vase 43.5.7Serviciosdelsistemaoperativo ): o Los servicios de operaciones del kernel o servicios de intrprete de comandos y de servicios pblicos o Los servicios de procesamiento por lotes o Los servicios de archivos y sincronizacin de directorios Servicios de Ingeniera de Software (ver 43.5.8SoftwareEngineeringServices ): o Los servicios de lenguaje de programacin o Cdigo objeto vincular los servicios o servicios de ingeniera de software asistida por ordenador (CASE) medio ambiente y herramientas o servicios de la interfaz grfica de usuario (GUI) de construccin o Los servicios de lenguaje de secuencias de comandos o servicios de Idioma vinculante o Los servicios de entorno de tiempo de ejecucin o servicios de interfaz de aplicacin binaria
Pgina516de670

TOGOF9.1
Servicios de procesamiento de transaccin (ver 43.5.9ServiciosdeProcesamientode Transacciones ): o Los servicios de administrador de transacciones Servicios de la interfaz de usuario (ver 43.5.10usuarioServiciosInterface ): o servicios Cliente grfico / servidor o mostrar los objetos de servicios o Los servicios de administracin de Ventana o servicios de apoyo de dilogo o Servicios de impresin o servicios de formacin y de ayuda en lnea basados en ordenador o Los servicios basados en caracteres Servicios de seguridad (ver ServiciosdeSeguridad43.5.11 ): o servicios de autenticacin de Identificacin y o servicios de control de entrada del sistema o Los servicios de Auditora o Los servicios de control de acceso o Los servicios de no repudio o Los servicios de gestin de seguridad o servicios de recuperacin de confianza o Los servicios de cifrado o servicios de comunicaciones de confianza Sistema y Servicios de Gestin de Red (ver 43.5.12SistemaylosServiciosdeGestinde Red ): o Los servicios de gestin de usuario o Configuracin de la gestin de servicios (CM) o Los servicios de gestin de rendimiento o Disponibilidad y gestin de fallos servicios o Los servicios de gestin de la contabilidad
Pgina517de670

TOGOF9.1
o Los servicios de gestin de seguridad o Imprimir Servicios de gestin o Los servicios de gestin de red o Copia de seguridad y los servicios de restauracin o Los servicios de gestin de disco en lnea o Los servicios de gestin de Licencia o Los servicios de gestin de la capacidad o Los servicios de instalacin de software o Dificultad para venta de entradas de servicios 43.4.2.1 orientada a objetos Prestacin de Servicios
Una descripcin detallada de cada una de estas categoras de servicios se da en 43.5.13 orientada a objetos Prestacin de Servicios .
Object Request Broker (ORB) Servicios: o Los servicios de repositorio de Implementacin o Servicios de instalacin y activacin o servicios de repositorio de interfaz o Los servicios de replicacin Comunes Servicios de objeto: o cambiar los servicios de gestin o Los servicios de Colecciones o Los servicios de control de concurrencia o Los servicios de intercambio de datos o servicios de gestin de eventos o Los servicios de Externalizacin o Servicios de cesin o Los servicios de ciclo de vida o servicios de nombres
Pgina518de670

TOGOF9.1
o Los servicios de objetos persistentes o Propiedades de los servicios o Los servicios de consulta o Los servicios de relaciones o Servicios de seguridad o servicios de puesta en marcha o Los servicios de Tiempo o Los servicios de comercio o Servicios de transaccin,
43.4.3 Cualidades aplicacin de servicio de la plataforma

43.4.3.1 Principios
Adems de las categoras de servicios de plataforma delineados por categora funcional, calidades de servicio afectan Arquitecturas de Sistemas de Informacin. A la calidad de servicio se describe un comportamiento, como la capacidad de adaptacin o de gestin. Calidades de servicio tienen un efecto penetrante en el funcionamiento de la mayora o la totalidad de las categoras de servicios funcionales. En general la exigencia de un determinado nivel de calidad de servicio en particular requiere una o ms categoras de servicios funcionales a cooperar en la consecucin del objetivo. Por lo general, esto significa que los bloques de construccin de software que implementan los servicios funcionales contienen software que contribuye a la implementacin de la calidad. Por la calidad que se proporciona adecuadamente, todos los servicios funcionales pertinentes deben haber sido diseados para apoyarlo. Cualidades de servicios tambin tienen que sujetarse en software en la entidad de software de aplicacin y el ambiente externo, as como la plataforma de aplicaciones. En algunos casos, una calidad de servicio afecta a cada una de las categoras de servicios en una manera similar, mientras que en otros casos, la calidad del servicio tiene una influencia nica en una categora de servicio particular. Por ejemplo, la operacin internacional depende de la mayor parte de las categoras de servicios de la misma manera, tanto a los servicios ya la necesidad de su cooperacin para la localizacin de los mensajes, las fuentes y otras caractersticas de un local, pero puede tener un efecto ms profundo en la servicios de ingeniera de software, que quiz requiera de instalaciones para la produccin de software internacionalizado.
Pgina519de670

TOGOF9.1
Durante el proceso de desarrollo de la arquitectura, el arquitecto debe ser consciente de la existencia de las cualidades y el grado de su influencia en la eleccin de los bloques de construccin de software utilizado en la implementacin de la arquitectura. La mejor manera de asegurarse de que las cualidades no se olvidan es crear una matriz de calidad, que describe las relaciones entre cada servicio funcional y las cualidades que influyen en ella.
43.4.3.2 Taxonoma de calidades de servicio
Las calidades de servicio actualmente identificados en la taxonoma TRM son:

Disponibilidad (el grado en que algo est disponible para su uso), incluyendo: o Capacidad de administracin , la capacidad de reunir informacin sobre el estado de algo y para controlarlo o de servicio , la capacidad de identificar los problemas y tomar medidas correctivas, tales como reparar o actualizar un componente en un sistema que ejecuta o de rendimiento , la capacidad de un componente para ejercer sus funciones en el momento oportuno o fiabilidad , o la resistencia al fracaso o valorizacin , o la capacidad de restaurar un sistema a un estado de trabajo despus de una interrupcin O el estado de localizacin , la capacidad de un sistema para encontrar cuando sea necesario Aseguramiento , incluyendo: o de seguridad , o la proteccin de la informacin contra accesos no autorizados o integridad o la seguridad de que los datos no se ha daado o credibilidad , o el nivel de confianza en la integridad del sistema y sus datos Usabilidad , o la facilidad de operacin de los usuarios, incluyendo: o la operacin internacional , incluyendo habilidades multilinges y multiculturales Adaptabilidad , incluyendo: o la interoperabilidad , ya sea dentro o fuera de la organizacin (por ejemplo, la interoperabilidad de las funciones de calendario o programacin puede ser clave para la utilidad de un sistema) O escalabilidad , la capacidad de un componente para aumentar o reducir su rendimiento o capacidad adecuada a las exigencias del entorno en el que opera o Portabilidad , de datos, de personas, aplicaciones y componentes
Pgina520de670

TOGOF9.1
o extensibilidad , o la capacidad de aceptar la nueva funcionalidad o La capacidad de ofrecer acceso a los servicios en los nuevos paradigmas, tales como la orientacin a objetos
43.5 Taxonoma Plataforma detallada

En esta seccin se ofrece una taxonoma detallada de los servicios de la plataforma y cualidades.
43.5.1 Servicios de datos de intercambio
Servicios de intercambio de datos proporcionan apoyo especializado para el intercambio de informacin entre las aplicaciones y el entorno externo. Estos servicios estn diseados para manejar el intercambio de datos entre aplicaciones en la misma plataforma y aplicaciones en diferentes plataformas (heterogneas). Existe un conjunto anlogo de los servicios de intercambio de datos orientada a objetos, que se puede encontrar en Servicios de Intercambio de Datos y Servicios de Externalizacin de 43.5.13 orientada a objetos Prestacin de Servicios .
Documento Generic Data Typing y Conversin servicios estn respaldados por las especificaciones para la codificacin de los datos (por ejemplo, texto, imagen, carcter numrico, especial) y tanto las estructuras lgicas y visuales de los documentos electrnicos, incluidos los documentos compuestos. Grficos de datos de intercambio de servicios se apoyan en las descripciones independientes del dispositivo de elementos de imagen para grficos basados en vectores y descripciones de grficos basados en raster. Especializada Data Interchange servicios estn respaldados por las especificaciones que describen los datos utilizados por mercados verticales especficos.Mercados cuando stas existan incluyen las industrias del petrleo Mdico, Biblioteca, Dental, Assurance, y. Electronic Data Interchange servicios se utilizan para crear un entorno electrnico (sin papel) para llevar a cabo el comercio y lograr ganancias significativas en la calidad, capacidad de respuesta, y el ahorro que ofrece este entorno. Ejemplos de las aplicaciones que utilizan servicios de comercio electrnico incluyen: bsqueda y seleccin de proveedores; adjudicacin del contrato; datos de los productos; envo, reenvo y recepcin; costumbres; informacin de pago; control de inventarios; mantenimiento; los datos relacionados con los impuestos; y los datos relacionados con los seguros. Fax servicios se utilizan para crear, analizar, transmitir y / o recibir imgenes de fax.
Las siguientes reas funcionales estn soportados principalmente por el software de aplicacin, pero estn avanzando hacia la migracin a la plataforma de aplicaciones:
Grficos Raw Interfaz formatos de archivos de datos grficos de apoyo a funciones tales como TIFF, JPEG, GIF, y CGM.
Pgina521de670

TOGOF9.1
Tratamiento de Textos funciones, incluyendo la capacidad de crear, editar, combinar, y dar formato al texto. Procesamiento de Documentos funciones, incluyendo la capacidad de crear, editar, combinar, y formatear documentos. Estas funciones permiten a la composicin de los documentos que incorporan grficos, imgenes, e incluso anotacin de voz, junto con el texto estilizado. Se incluyen de formato y edicin avanzadas funciones como guas de estilo, correccin ortogrfica, el uso de mltiples columnas, tabla de la generacin de contenido, encabezados y pies de pgina, herramientas Esquema, y el apoyo para la digitalizacin de imgenes en formatos de mapas de bits. Otras capacidades incluyen la compresin y descompresin de imgenes o documentos enteros. Publicacin funciones, incluyendo la incorporacin de imgenes de calidad fotogrfica y grficos en color y caractersticas de formato y estilo avanzadas, tales como el ajuste de texto alrededor de objetos grficos o fotos y kerning (es decir, cambiar el espaciado entre caracteres de texto). Estas funciones tambin interactuar con sofisticados equipos de impresin y produccin. Otras capacidades incluyen la representacin de color y la compresin y descompresin de imgenes o documentos enteros. Video Processing funciones, incluyendo la capacidad de capturar, componer, editar, comprimir y descomprimir la informacin de vdeo utilizando formatos como MPEG. An as tambin se proporcionan grficos y funciones de generacin de ttulo. Procesamiento de audio funciones, incluyendo la capacidad de capturar, componer, editar, comprimir y descomprimir datos de audio. Procesamiento Multimedia funciones, incluyendo la capacidad de almacenar, recuperar, modificar, ordenar, buscar e imprimir todos o cualquier combinacin de los medios de comunicacin mencionados. Esto incluye el apoyo a los medios de comunicacin microfilm, tecnologa de almacenamiento ptico que permite el almacenamiento de los documentos escaneados o produce computadora que utilizan tcnicas digitales de almacenamiento, una funcin de barrido, y la compresin y descompresin de datos. Sincronizacin de medios funciones permiten la sincronizacin de los flujos de datos, tales como audio y video para presentaciones. Presentacin de la Informacin y de distribucin funciones se utilizan para gestionar la distribucin y presentacin de informacin de lotes y aplicaciones interactivas. Estas funciones se utilizan para proteger las aplicaciones en reas de negocio de cmo se utiliza la informacin. Permiten a las aplicaciones en reas de negocio para crear piscinas genricas de informacin sin la incorporacin de controles que determinan el uso de esa informacin. Funciones de distribucin de la informacin y de presentacin incluyen la seleccin de las funciones de formato apropiadas requeridas para llevar a cabo la distribucin y presentacin de la informacin a una variedad de aplicaciones en reas de negocio y los usuarios. Funciones de presentacin y distribucin de la informacin tambin incluye la capacidad de almacenar, archivar, priorizar, restringir, y volver a crear informacin. Hipertexto funciones apoyan la generacin, distribucin, localizacin, bsqueda y visualizacin de texto e imgenes, ya sea local o global. Estas funciones incluyen la bsqueda y la navegacin, los enlaces de hipertexto, y la presentacin de informacin multimedia.
Pgina522de670

TOGOF9.1 Servicios de gestin de datos 43.5.2
. Central a la mayora de los sistemas es la gestin de datos que se puede definir de forma independiente de los procesos que crean o utilizan, mantenerse indefinidamente, y se comparte entre muchos procesos de los servicios de gestin de datos incluyen:
Diccionario de Datos / Repositorio servicios permiten a los administradores de datos y los ingenieros de la informacin para acceder y modificar los datos acerca de los datos (es decir, metadatos). Estos datos pueden incluir formatos interna y externa, la integridad y reglas de seguridad, y la ubicacin dentro de un sistema distribuido. Diccionario de datos y servicios de repositorio tambin permiten a los usuarios finales y las aplicaciones para definir y obtener datos que est disponible en la base de datos. La administracin de datos define la normalizacin y registro de los tipos de elementos de datos individuales para cumplir con los requisitos para el intercambio de datos y la interoperabilidad entre los sistemas de informacin en toda la empresa. Funciones de administracin de datos incluyen los procedimientos, pautas y mtodos para la planificacin efectiva de datos, anlisis, normas, modelos, gestin de configuracin, almacenamiento, recuperacin, proteccin, la validacin y la documentacin. Los diccionarios de datos a veces son atados a un nico sistema de gestin de bases de datos (DBMS), pero los diccionarios de datos heterogneas apoyarn el acceso a diferentes DBMS. Repositorios pueden contener una amplia variedad de informacin, incluyendo bases de informacin de administracin (MIB), o informacin relacionados con las causas. Sistemas orientados a objetos pueden proporcionar repositorios de objetos e interfaces, descritas en los servicios de repositorio de implementacin y servicios de repositorio de interfaz en 43.5.13orientadaaobjetos PrestacindeServicios . Sistema de Gestin de Base de Datos (DBMS) servicios proporcionan acceso controlado a los datos estructurados. Para gestionar los datos, el DBMS proporciona control de concurrencia y facilidades para combinar datos de diferentes esquemas. Los diferentes tipos de DBMS soportan diferentes modelos de datos, entre ellos, la red, los modelos orientados a objetos, y de archivos planos relacionales, jerrquicas. Algunos DBMS estn diseados para funciones especiales tales como el almacenamiento de objetos grandes o datos multimedia. Servicios de DBMS son accesibles a travs de una interfaz de lenguaje de programacin, una interfaz de lenguaje de manipulacin de datos interactivos (como SQL), o un interfaz de lenguaje interactivo / cuarta generacin. Look-up y recuperacin de datos para los objetos se describen por separado en los servicios de consulta en 43.5.13orientadaaobjetosPrestacindeServicios . Para una mayor eficiencia, los DBMS a menudo ofrecen servicios especficos para crear, rellenar, mover, copia de seguridad, restaurar, recuperar, y bases de datos de archivos, aunque algunos de estos servicios podran ser proporcionados por las capacidades de administracin de archivos generales descritos en 43.5.7Serviciosdelsistemaoperativo o una especfica servicio de copia de seguridad. Algunos distribucin apoyo DBMS de la base de datos, incluyendo las instalaciones para la actualizacin de registros de forma remota, replicacin de datos, localizar y almacenar datos en cach, y la administracin remota. Sistema de gestin de base de datos orientada a objetos de servicios (SGBDOO) proporcionan almacenamiento para objetos e interfaces a esos objetos.Estos servicios pueden apoyar el Repositorio de Ejecucin, Interface Repository, y los servicios de objetos persistentes en 43.5.13orientadaaobjetosPrestacindeServicios . Administracin de archivos proporcionan servicios de gestin de datos a travs de mtodos de acceso a archivos incluidos secuencial indizado (ISAM) y hash de acceso
Pgina523de670

TOGOF9.1
aleatorio. Servicios de archivos planos y directorios se describen en 43.5.7serviciosdel sistemaoperativo .
Procesamiento de consultas funciones que proporcionan para la seleccin interactiva, la extraccin y el formato de la informacin almacenada en los archivos y bases de datos. Funciones de procesamiento de consultas se invocan a travs de lenguajes orientados a los usuarios y herramientas (a menudo referida como lenguajes de cuarta generacin), que simplifican la definicin de criterios y la bsqueda de ayuda en la creacin de presentacin eficaz de la informacin recuperada (incluyendo el uso de grficos). Generacin Screen funciones que proporcionan la capacidad de definir y generar pantallas que apoyan la recuperacin, presentacin y actualizacin de datos. Informe Generacin funciones que proporcionan la capacidad de definir y generar informes impresos compuestos por los datos extrados de una base de datos. Redes / acceso simultneo funciones que gestionan el acceso de usuarios simultneos al sistema de gestin de bases de datos (DBMS) funciones. Almacenaje funciones que proporcionan la capacidad de almacenar grandes cantidades de datos - generalmente capturados de otros sistemas de bases de datos - y para realizar el procesamiento analtico en lnea sobre el mismo en apoyo de ad hoc consultas.
43.5.3 Grficos y Servicios de Imgenes
. Servicios Grficos proporcionan funciones necesarias para crear, almacenar, recuperar y manipular imgenes Estos servicios incluyen:
Gestin de objetos grficos de servicios, incluyendo la definicin de los objetos grficos multidimensionales en una forma que es independiente de los dispositivos de salida, y la gestin de las estructuras jerrquicas que contienen datos de los grficos. Formatos grficos de datos incluyen dos y dibujos geomtricos tridimensionales, as como imgenes. Dibujo servicios de apoyo a la creacin y manipulacin de imgenes con software como GKS, PEX, PHIGS o OpenGL.
Imaging funciones que prevn la exploracin, creacin, edicin, compresin y descompresin de imgenes de acuerdo con los estndares de formato de imagen reconocidos; por ejemplo, PIKS / IPI, OpenXIL o XIE.
43.5.4 Internacionales Servicios de Operacin
Como prctica, los desarrolladores de sistemas de informacin tienen sistemas para satisfacer las necesidades de un segmento de mercado geogrfico o lingstico especfico,
Pgina524de670

TOGOF9.1
que puede ser una nacin o de un mercado cultural particular diseado y desarrollado en general. Para hacer que el sistema de informacin viable, o comercial, a un segmento diferente del mercado, por lo general se requiere un proceso de reingeniera completa. Los usuarios u organizaciones que necesitan para operar en un entorno multi-nacional o multicultural tpicamente hicieron lo mismo con varios sistemas de procesamiento de informacin en general, incompatibles. Operacin Internacional proporciona un conjunto de servicios e interfaces que permiten a un usuario definir, seleccionar y cambiar entre diferentes entornos de aplicaciones culturalmente relacionados con el apoyo de la aplicacin particular. En general, estos servicios deben proporcionarse de tal manera que las cuestiones de internacionalizacin son transparentes a la lgica de la aplicacin.
Conjuntos de caracteres y representacin de datos servicios incluyen la capacidad de introducir, almacenar, manipular, recuperar, comunicar y presentar datos de forma independiente del esquema de codificacin utilizado. Esto incluye la capacidad de mantener y acceder a un repositorio central de juego de caracteres de todos los conjuntos de caracteres codificados que se usan a lo largo de la plataforma. Los conjuntos de caracteres se identifican de forma nica para que el usuario o la aplicacin final puede seleccionar el conjunto de caracteres codificados para ser utilizado. Esta representacin independiente del sistema soporta la transferencia (o compartir) de los valores y la sintaxis, pero no la semntica, de registros de datos entre sistemas de comunicacin. Las especificaciones son independientes de los registros y campos representaciones internas de los sistemas de comunicacin. Tambin se incluye la capacidad de reconocer el conjunto de caracteres codificados de entidades de datos y, posteriormente, a la entrada, comunicar y presentar esos datos. Convenio Cultural servicios proporcionan la capacidad de almacenar y acceder a las reglas y convenciones para las entidades culturales que se mantienen en un repositorio convencin cultural llamado un "locale". Locales deben estar disponibles para todas las aplicaciones. Locales suelen incluir la fecha y la moneda formatos, las secuencias de clasificacin y formatos de nmero. Formatos estandarizados de localizacin y APIs permiten a las entidades de software que utilizan la informacin de localizacin desarrollado por otros. Asistencia de idiomas locales los servicios proporcionan la capacidad de soportar ms de un idioma al mismo tiempo en un sistema. Mensajes, mens, formularios y documentacin en lnea se pueden visualizar en el idioma seleccionado por el usuario. Las aportaciones de los teclados que se han modificado a nivel local para apoyar a los conjuntos de caracteres locales puede ser interpretada correctamente.
El buen funcionamiento de los servicios de operacin internacionales depende de todas las entidades de software que participan tienen la capacidad de:
Utilice locales Cambie entre locales segn sea necesario Mantener varias configuraciones regionales activas
Pgina525de670

TOGOF9.1
Acceso a las fuentes adecuadas
Esto requiere que las entidades de software que se escriben en un estilo particular y en ser diseado desde el principio con la internacionalizacin en mente.
43.5.5 Ubicacin y Servicios de Directorio
Ubicacin y directorio de servicios proporcionan apoyo especializado para la localizacin de los recursos necesarios y la mediacin entre los consumidores de servicios y los proveedores de servicios. La World Wide Web, basada en Internet, ha creado la necesidad de localizar los recursos de informacin, que actualmente est satisfecho principalmente mediante el uso de motores de bsqueda. Los avances en la Internet global, y en los sistemas distribuidos heterogneos, demandan una mediacin activa a travs de servicios de corredura que incluyen el registro automtico y dinmico, acceso al directorio, la comunicacin de directorios, filtracin, y servicios de contabilidad para el acceso a los recursos.
Directorio de servicios proporcionan los servicios para que los clientes establecen que los recursos son, y, por extensin, la forma en que se puede llegar. "Los clientes" pueden ser los seres humanos o los programas de ordenador, y "recursos" pueden ser una gran variedad de cosas, tales como nombres, direcciones de correo electrnico, los certificados de seguridad, impresoras, pginas web, etc Nomenclatura de Propsitos Especiales servicios proporcionan servicios que hagan referencia los nombres (cadenas ordenadas de caracteres imprimibles) a los objetos dentro de un contexto determinado (namespaces). Los objetos son normalmente organizados jerrquicamente dentro de los espacios de nombres. Ejemplos son: o Sistemas de archivos o las bases de datos de seguridad o colas de proceso Servicio de Localizacin de servicios proporcionan acceso a "Pginas Amarillas" servicios en respuesta a las preguntas sobre la base de las limitaciones. Registro de servicios proporcionan servicios para registrar la identidad, la descripcin de los servicios de un recurso est proporcionando y descripciones de los medios para acceder a ellos. Filtrado de servicios proporcionan servicios para seleccionar informacin til de datos utilizando criterios definidos. Contabilidad servicios proporcionan servicios como cuenta abierta, actualizacin de cuenta, saldo de la cuenta, cuenta detalle, cierre contable, descuentos, recuento proyecto cuenta / uso, la cuenta del acuerdo de pago basado en el trfico de mensajes, y / o el tiempo de conexin y / o utilizacin de los recursos, y / o especficos de agente (por ejemplo, basado en el valor).
Pgina526de670

TOGOF9.1 Servicios de red 43.5.6
Los servicios de red se proporcionan para soportar aplicaciones distribuidas que requieren acceso a datos y aplicaciones de la interoperabilidad en entornos de red heterogneos u homogneos. Un servicio de red consiste tanto una interfaz y un protocolo subyacente.
Comunicaciones de datos , que incluyen las interfaces y protocolos para la transmisin de datos fiable, transparente de extremo a extremo a travs de redes de comunicaciones. Servicios de comunicaciones de datos incluyen tanto las funciones de alto nivel (tales como transferencia de archivos, acceso remoto, ejecucin de procesos a distancia, o los servicios de integracin de PC) y funciones de bajo nivel (como un API de sockets) que da acceso directo a los protocolos de comunicacin. El correo electrnico servicios incluyen la capacidad de enviar, recibir, reenviar, almacenar, visualizar, recuperar, priorizar, autenticar y gestionar los mensajes.Esto incluye la capacidad para anexar archivos y documentos a los mensajes. Los mensajes pueden incluir cualquier combinacin de datos, texto, audio, grficos e imgenes, y deben ser capaces de ser formateado en formatos de intercambio de datos estndar. Este servicio incluye el uso de directorios y listas de distribucin de informacin de enrutamiento, la capacidad de asignar prioridades, el uso de los formularios electrnicos con formato previo, y la capacidad de seguir el estado de los mensajes. Servicios asociados incluyen una lista resumida de los mensajes entrantes, un registro de los mensajes recibidos y leer, la posibilidad de presentar o mensajes de impresin, y la capacidad de responder o reenviar mensajes. Datos Distribuidos servicios proporcionan acceso a, y la modificacin de los datos / metadatos en las bases de datos locales o remotos. En un entorno distribuido, los datos no disponibles en la base de datos local es descabellada desde un servidor de datos a distancia, a peticin del cliente local. Distribuidos de archivos servicios proporcionan para el acceso remoto a archivos transparente. Las aplicaciones tienen un acceso equivalente a los datos independientemente de la ubicacin fsica de los datos. Servicios auxiliares para esta funcin pueden incluir direcciones, datos transparentes en cach, replicacin de datos, bloqueo de archivos y el registro de archivos. Nombre Distribuidos servicios proporcionan un medio para la identificacin nica de los recursos dentro de un sistema de computacin distribuida. Estos servicios estn disponibles para aplicaciones dentro de la red y proporciona informacin que puede incluir el nombre de los recursos, atributos asociados, la ubicacin fsica y la funcionalidad de los recursos. Tenga en cuenta que todos los recursos del sistema deben ser identificables, en todos los sistemas de informacin, por el nombre distribuida. Esto permite que la ubicacin fsica de cambiar, no slo para acomodar el movimiento, sino tambin equilibrio de carga, la utilizacin del sistema, la ampliacin (aadiendo procesadores y moviendo los recursos para acomodar el aumento de recursos), procesamiento distribuido, y todos los aspectos de los sistemas abiertos. Servicios de nombres distribuidas incluyen los servicios de directorio, como los servicios X.500 y de navegacin de la red. Servicios de nombres distribuidas incluyen maneras de localizar objetos de datos tanto por nombre como por su funcin. 43.5.13orientadaaobjetosPrestacindeServicios describe los servicios equivalentes al amparo de los servicios de nomenclatura y Servicios comerciales, respectivamente.
Pgina527de670

TOGOF9.1
Tiempo Distribuidos proveen servicios de tiempo sincronizado coordinacin tan necesaria entre procesos distribuidos en diferentes zonas horarias. Un servicio equivalente se describe en Servicios de Tiempo en 43.5.13orientadaaobjetosPrestacindeServicios . Proceso Remoto (acceso) los servicios proporcionan los medios para aplicaciones dispersas para comunicarse a travs de una red informtica. Estos servicios facilitan las comunicaciones de programa a programa, independientemente de su naturaleza distribuida o una operacin en plataformas heterogneas. Servicios de procesos a distancia, incluyendo la llamada a procedimiento remoto (RPC) y los mecanismos de mensajera asncrona sustentan aplicaciones cliente / servidor. Cola de impresin remota y Distribucin de salida servicios proporcionan los medios para la impresin de produccin de forma remota. Los servicios incluyen la gestin de la impresin remota incluyendo impresora y seleccin de medios, el uso de las formas, la seguridad y la gestin de colas de impresin.
Telefona mejoradas funciones, incluyendo el establecimiento de llamada, llaman la coordinacin, desvo de llamadas, llamada en espera, directorios programadas, las teleconferencias, distribucin automtica de llamadas (til para los ocupados categoras de servicio al cliente), y la grabacin de llamadas detalle. Pantalla compartida funciones que proporcionan las teleconferencias de audio con ventanas de estaciones de trabajo comunes entre dos o ms usuarios. Esto incluye la capacidad para actualizar ventanas cada vez que alguien muestra nuevo material o cambia una batera existente. Cada usuario dispone de la capacidad para anotar de forma grfica o modificar la ventana de conferencia compartida. Video-conferencia funciones que proporcionan la transmisin de video de dos vas entre los diferentes sitios. Estas funciones incluyen establecimiento de llamada, llame a la coordinacin, la pantalla de movimiento completo de eventos y participantes de una manera bidireccional, el apoyo a la gestin de la direccin de las cmaras, que van desde la posicin fija, al remitente dirigido, dirigido al receptor, al sonido automatizado recogida. Broadcast funciones que proporcionan un solo sentido funciones de audio o las comunicaciones de audio / vdeo entre una ubicacin y envo de mltiples emplazamientos de recepcin o entre mltiples enviar y recibir ubicaciones. Listas de Correo de funciones que permiten a los grupos a participar en las conferencias. Estas conferencias pueden o no ocurrir en tiempo real. Los conferenciantes o invitados pueden caer dentro o fuera de las conferencias o subconferencias a voluntad. Se proporciona la capacidad de rastrear los intercambios.Las funciones incluyen el intercambio de documentos, gestin de conferencias, instalaciones de grabacin, y la bsqueda y la capacidad de recuperacin.
43.5.7 servicios del sistema operativo
Servicios del sistema operativo son los responsables de la gestin de los recursos de la plataforma, incluyendo el procesador, la memoria, los archivos, y la entrada y salida. . Por
Pgina528de670

TOGOF9.1
lo general protegen las aplicaciones de los detalles de implementacin de la mquina de los servicios del sistema operativo se incluyen:
Operaciones del ncleo proporcionan servicios de bajo nivel necesarias para: o Creacin y gestin de los procesos y subprocesos de ejecucin o Ejecutar programas o Definir y comunicar eventos asncronos o Definir y operaciones del reloj del sistema proceso o Implementar las funciones de seguridad o Gestin de archivos y directorios o Entrada de control / procesamiento de salida hacia y desde los dispositivos perifricos
Algunos servicios del ncleo tienen anlogos descritos en 43.5.13 orientada a objetos Prestacin de Servicios , como los servicios de control de concurrencia.
Intrprete de comandos y utilitarios servicios incluyen mecanismos de servicios a nivel de operador, tales como: o contenidos Comparando, impresin y archivos que muestran o Edicin de archivos o patrones de bsqueda o expresiones Evaluacin o Los mensajes de registro o mover archivos entre directorios o Ordenacin de datos o Ejecucin de scripts de comandos o cola de impresin local o Los procesos de ejecucin de seal de programacin o Acceso a la informacin del entorno El procesamiento por lotes los servicios de apoyo a la capacidad de la cola de trabajo (puestos de trabajo) y gestionar la secuencia de procesamiento basado en comandos de control de trabajo y listas de datos. Estos servicios tambin incluyen el apoyo a la gestin de la salida de procesamiento por lotes, lo que con frecuencia incluye archivos actualizados o bases de datos y productos de informacin tales como informes impresos o
Pgina529de670

TOGOF9.1
documentos electrnicos. El procesamiento por lotes se realiza de forma asncrona desde el usuario que solicita el trabajo. De archivos y sincronizacin de directorios servicios permiten copias locales y remotas de los archivos y directorios que se hagan idnticos. Los servicios de sincronizacin normalmente se utilizan para actualizar los archivos despus de perodos de trabajo sin conexin en un sistema porttil.
43.5.8 Software Engineering Services
El aspecto funcional de una aplicacin se materializa en los lenguajes de programacin utilizados para codificarlo. Adems, los desarrolladores de sistemas profesionales requieren herramientas adecuadas para el desarrollo y mantenimiento de aplicaciones. Estas capacidades son proporcionados por los servicios de ingeniera de software, las cuales incluyen:
Lenguaje de programacin de servicios proporcionan la sintaxis bsica y definicin semntica para su uso por un desarrollador de software para describir la funcin del software de aplicacin deseada. Shell y servicios lingsticos ejecutivo de guin permiten el uso de los comandos del sistema operativo o de los servicios pblicos en lugar de un lenguaje de programacin. Shells y scripts ejecutivos suelen ser interpretados en lugar de compilarse, pero los compiladores de apoyo algunos sistemas operativos para los scripts de ejecutivos. Por el contrario, algunos compiladores producen cdigo para ser interpretado en tiempo de ejecucin.Otras herramientas de este grupo incluyen formateadores de cdigo fuente y los compiladores del compilador. Cdigo Object Linking servicios proporcionan la capacidad de los programas para acceder a la aplicacin y el sistema operativo de la plataforma subyacente a travs de las API que se han definido de forma independiente del lenguaje de programacin. Es utilizado por los programadores para acceder a estos servicios utilizando mtodos compatibles con el sistema operativo y el idioma especfico usado. La unin se dependiendo del sistema operativo, pero independiente del lenguaje. Computer-Aided Software Engineering (CASE) Medio ambiente y Herramientas servicios incluyen sistemas y programas que ayudan en el desarrollo automatizado y mantenimiento de software. Estos incluyen, pero no estn limitados a, herramientas para la especificacin de requisitos y anlisis, para el trabajo de diseo y anlisis, para crear, editar, probar, y el cdigo de programa de depuracin, para documentar, para la creacin de prototipos, y para la comunicacin de grupo. Las interfaces entre estas herramientas incluyen servicios para almacenar y recuperar informacin acerca de los sistemas y el intercambio de esta informacin entre los diversos componentes del sistema de entorno de desarrollo. Un complemento de estas capacidades es la capacidad de gestionar y controlar la configuracin de los componentes de software, los datos de prueba, y las bibliotecas para registrar los cambios en el cdigo fuente o para acceder a los repositorios CASE. Otras herramientas de idioma incluyen generadores de cdigo y traductores, herramientas de inteligencia artificial, y herramientas como el comando del sistema UNIX make , que utiliza el conocimiento de las interdependencias entre los mdulos de recompilar y enlazar los slo aquellas partes de un programa que han cambiado. Interfaz grfica de usuario (GUI) de construccin servicios de ayuda en el desarrollo de la Interfaz Hombre-Computadora (HCI) elementos de las aplicaciones.Las herramientas
Pgina530de670

TOGOF9.1
incluyen servicios para la generacin y la captura de los diseos de pantalla, y para definir la apariencia, la funcin, el comportamiento, y la posicin de los objetos grficos. Scripting Language servicios proporcionan los lenguajes interpretados que permiten al usuario llevar a cabo alguna funcin complicada de un modo simple. Las reas de aplicacin servidos por lenguajes de scripting de propsito especial incluyen clculo, desarrollo de la interfaz grfica de usuario, y el desarrollo de prototipos de aplicaciones. Binding Language servicios proporcionan asignaciones de las interfaces proporcionadas por los lenguajes de programacin en los servicios prestados por la plataforma de aplicaciones. En muchos casos, el mapeo es sencillo ya que la plataforma suministra servicios anlogos a los esperados por la aplicacin. En otros casos, el servicio de enlace lenguaje debe utilizar una combinacin de los servicios de la plataforma de aplicaciones para proporcionar una cartografa totalmente funcional. Medio ambiente en tiempo de ejecucin de servicios proporcionan soporte para el software de aplicacin en tiempo de ejecucin. Este soporte incluye la localizacin y la conexin de bibliotecas de enlace dinmico, o incluso de emulacin de un entorno operativo diferente a la que realmente existe. Interfaz de aplicacin binaria servicios proporcionan servicios que hacen que la plataforma de aplicaciones de cumplir con los estndares de interfaz binaria de aplicacin definidos.
Servicios de Procesamiento de Transacciones 43.5.9
Servicios de procesamiento de transacciones (TP) proporcionan soporte para el procesamiento en lnea de informacin en unidades discretas llamadas "transacciones", con la garanta del estado de la informacin al final de la transaccin. Normalmente, esto implica secuencias predeterminadas de entrada de datos, la validacin, la pantalla y la actualizacin o la investigacin en contra de un archivo o base de datos. Tambin incluye los servicios para priorizar y rastrear transacciones.Servicios de TP pueden incluir el apoyo a la distribucin de las transacciones a una combinacin de los procesadores locales y remotos. Una transaccin es una unidad completa de trabajo. Se puede comprender muchas tareas de clculo, que puede incluir interfaz de usuario, de recuperacin de datos, y comunicaciones. Una tpica transaccin modifica los recursos compartidos. Las transacciones tambin deben ser capaces de ser revertido (es decir, sin hacer) si es necesario, en cualquier etapa. Cuando una transaccin se ha completado sin fallos, se ha comprometido. Finalizacin de una transaccin significa cualquiera de compromiso o retrotraccin. Normalmente, un servicio de TP contendr un gestor de transacciones, que une la entrada de datos y de software de visualizacin con el procesamiento, la base de datos, y otros recursos para formar el servicio completo.
Pgina531de670

TOGOF9.1
La suma de todo el trabajo realizado en cualquier parte del sistema en el transcurso de una sola transaccin se llama una "transaccin global." Las transacciones no se limitan a una sola plataforma de aplicaciones.
Gestor de transacciones . servicios, que permiten a una aplicacin demarcar transacciones, y dirigir su realizacin los servicios del gestor de transacciones incluyen: o Inicio de una transaccin o Coordinacin de recursos recuperables que intervienen en una transaccin o Confirmacin o retrotraccin de transacciones o Control de los tiempos de espera en las transacciones o Encadenamiento de transacciones, conjuntamente, o situacin de la operacin de Monitoreo
Algunos servicios de gestor de transacciones tienen equivalentes descritos en 43.5.13 orientada a objetos Prestacin de Servicios , bajo Servicios de transaccin.
43.5.10 Servicios al Usuario de la interfaz
Servicios de interfaz de usuario definen cmo los usuarios pueden interactuar con una aplicacin. Dependiendo de las capacidades requeridas por los usuarios y las aplicaciones, estas interfaces pueden incluir los siguientes:
Grficos de cliente / servidor de servicios que definen las relaciones entre cliente y servidor los procesos operativos de interfaz grfica de usuario muestra, por lo general dentro de una red. En este caso, el programa que controla cada unidad de visualizacin es un proceso de servidor, mientras que los programas de usuario independientes son procesos clientes que solicitan servicios de visualizacin del servidor. Display Objetos servicios que definen las caractersticas de los elementos de visualizacin, tales como color, forma, tamao, movimiento, contexto grfico, las preferencias del usuario, la gestin de la fuente, y las interacciones entre los elementos de la pantalla. Gestin Ventana servicios que definan cmo deben ventanas creadas, mover, almacenar, recuperar, eliminar, y relacionados entre s. Soporte de dilogo servicios se traducen los datos introducidos para la exhibicin a la que en realidad se muestra en la pantalla (por ejemplo, los movimientos del cursor, la entrada de datos del teclado, y los dispositivos de entrada de datos externos). Impresin de salida de soporte de servicios de texto y / o los datos grficos, incluyendo cualquier filtracin o la conversin del formato necesario. Servicios de impresin pueden incluir la capacidad de imprimir todo o parte de un documento, imprimir y compaginar ms de una copia, para seleccionar el tamao y la orientacin de la produccin, para elegir la
Pgina532de670

TOGOF9.1
resolucin de impresin, los colores, y el comportamiento grfico, y para especificar las fuentes y otros caractersticas. Entrenamiento y Ayuda Online Computer-Based servicios proporcionan un entorno de formacin integrada en estaciones de trabajo de usuario. La formacin est disponible en una base como-necesaria para cualquier aplicacin disponible en el entorno. Los mensajes electrnicos se proporcionan en el golpe de una tecla desde cualquier lugar dentro de la aplicacin. Esto incluye la formacin tutorial sobre la aplicacin en el uso y la disponibilidad de conexin, capacitacin interactiva en el sitio. Carcter-Basado servicios, que tienen que ver con el apoyo a los terminales no grficas. Servicios basados en caracteres incluyen soporte para terminal de control de tipo independiente de atributos de visualizacin, movimientos del cursor, teclas programables, seales acsticas, y otras funciones.
Los servicios asociados a un sistema de ventanas incluyen la presentacin visual de la informacin en una pantalla que contiene una o ms ventanas o paneles, el apoyo a sealar a un objeto en la pantalla mediante un dispositivo sealador como un ratn o pantalla tctil, y la manipulacin de un conjunto de objetos en la pantalla a travs del dispositivo de sealizacin oa travs de la entrada de teclado. Otras interfaces de usuario que se incluyen son los controles industriales y dispositivos de realidad virtual.
43.5.11 Servicios de Seguridad
Los servicios de seguridad son necesarias para proteger la informacin sensible en el sistema de informacin. El nivel adecuado de proteccin se determina en base al valor de la informacin a los usuarios finales de la zona de negocios y de la percepcin de las amenazas a la misma. Para ser eficaz, la seguridad debe hacerse fuerte, nunca debe darse por sentado, y debe ser diseado en una arquitectura y no agregada despus. Si un sistema es independiente o distribuido, la seguridad debe ser aplicado a todo el sistema. No hay que olvidar que la exigencia de la seguridad se extiende no slo a travs de la gama de entidades de un sistema, sino tambin a travs del tiempo. En el establecimiento de una fianza . arquitectura, el mejor enfoque es considerar qu se est defendiendo, qu valor tiene, y cules son las amenazas a que son las principales amenazas que deben contrarrestarse son:
La prdida de la confidencialidad de los datos Falta de disponibilidad de datos o servicios La prdida de integridad de los datos El uso no autorizado de los recursos
Contadores a estas amenazas son proporcionados por los siguientes servicios:

Pgina533de670

TOGOF9.1
Identificacin y autenticacin de los servicios ofrecen: o Identificacin, rendicin de cuentas y auditora de los usuarios y sus acciones o Los datos de autenticacin y de cuentas o Proteccin de datos de autenticacin o informacin del estado de usuario de Active o Los mecanismos de autenticacin Contrasea Control de Sistema de Entrada servicios ofrecen: o advertencia a los usuarios no autorizados de que el sistema es consciente de la seguridad o Autenticacin de usuarios o de la Informacin, aparece en la entrada, a unos exitosos y no exitosos intentos de conexin anteriores o bloqueo iniciado por el usuario de una sesin de prevenir an ms el acceso hasta que el usuario se ha autenticado re- Auditora servicios ofrecen un control autorizado y la proteccin de la pista de auditora, el registro de informacin de eventos relevantes para la seguridad detalladas, y control de seguimiento de auditora, la gestin y la inspeccin. Control de acceso proporcionan servicios: o los atributos de control de acceso para los sujetos (tales como procesos) y objetos (como archivos) o La aplicacin de normas para la asignacin y modificacin de atributos de control de acceso o Ejecucin de los controles de acceso o de control de la creacin y eliminacin de objeto, incluso asegurando que la reutilizacin de objetos no permite sujetos para obtener accidentalmente el acceso a la informacin preexistente en el objeto
Servicios de control de acceso tambin aparecen bajo los servicios de seguridad en 43.5.13 orientada a objetos Prestacin de Servicios .
No repudio servicios proporcionan la prueba de que un usuario realiza una accin, o enviar o recibir informacin, en un momento determinado. Servicios de no repudio tambin aparecen bajo los servicios de seguridad en 43.5.13orientadaaobjetosPrestacinde Servicios . Gestin de Seguridad de servicios proporcionan seguro sistema de configuracin e inicializacin, el control de los parmetros de la poltica de seguridad, la gestin de los
Pgina534de670

TOGOF9.1
datos de registro del usuario, y los recursos del sistema y las restricciones en el uso de las funciones administrativas. Recuperacin de confianza los servicios proporcionan instalaciones de recuperacin como la restauracin de las copias de seguridad de forma que no comprometan la proteccin de seguridad. Cifrado servicios proporcionan formas de codificacin de datos de tal manera que slo puede ser ledo por alguien que posee una tecla apropiada, o alguna otra pieza de informacin secreta. Adems de proporcionar confidencialidad de los datos para la comunicacin de confianza, los servicios de cifrado se utilizan para sustentar muchos otros servicios, como la identificacin y autenticacin, control de entrada del sistema, y los servicios de control de acceso. Comunicacin Trusted servicios ofrecen: o Una forma segura para la comunicacin partidos para autenticarse entre s, sin el riesgo de un espa, posteriormente, hacindose pasar por una de las partes o Una forma segura de generar y verificar los valores de comprobacin de integridad de los datos o cifrado y descifrado de la confidencialidad y otros fines de Datos o una manera de producir un hash irreversible de los datos para el apoyo de las funciones de firma digital y el no repudio o Generacin, derivacin, distribucin, almacenamiento, recuperacin y eliminacin de claves criptogrficas
Los servicios de seguridad requieren otras entidades de software para cooperar en:
Control de acceso para los recursos gestionados por la entidad Contabilidad y auditora de los eventos relevantes para la seguridad La importacin y exportacin de datos Potencialmente todos los otros servicios de seguridad, segn el enfoque de implementacin particular
Los servicios de seguridad son una categora en la que una amplia vista es particularmente importante, ya que una cadena es tan fuerte como su eslabn ms dbil.Esta es una categora de servicios cuando el ambiente externo tiene implicaciones crticas en la plataforma de aplicaciones. Por ejemplo, la presencia de un servidor de seguridad puede proporcionar un nico punto de acceso a una red del mundo exterior, por lo que es posible concentrar el control de acceso en un lugar y relajar los requisitos de detrs del firewall.
Pgina535de670

TOGOF9.1 43.5.12 Sistema y los Servicios de Gestin de Red
Los sistemas de informacin estn compuestos por una gran variedad de diversos recursos que se debe manejar de manera efectiva a la consecucin de los objetivos de un entorno de sistema abierto. Mientras que los recursos individuales (por ejemplo, impresoras, software, usuarios, procesadores) pueden ser muy diferentes, la abstraccin de estos recursos como objetos administrados permite el tratamiento de una manera uniforme. Los conceptos bsicos de la gestin - incluyendo la operacin, administracin y mantenimiento - pueden entonces aplicar a todo el conjunto de componentes del sistema de informacin junto con sus servicios de ayudante. Sistema y funcionalidad de gestin de red se pueden dividir en varias maneras diferentes; Una forma es hacer una divisin de acuerdo a los elementos de gestin que genricamente se aplican a todos los recursos funcionales. Esta divisin reduce como sigue:
Gestin de usuarios de servicios ofrecen la posibilidad de mantener las preferencias y privilegios de un usuario. Gestin de la Configuracin (CM) los servicios de direccin de cuatro funciones bsicas: o Identificacin y especificacin de todos los recursos del componente o de control, o la capacidad de congelar los elementos de configuracin, el cambio slo a travs de procesos acordados o la contabilidad de estado de cada elemento de configuracin o Verificacin a travs de una serie de revisiones para asegurar la conformidad entre el elemento de configuracin actual y la informacin registrada sobre l
Estos servicios incluyen: Procesador CM, CM Red, Sistema Distribuido de CM, CM Topologa y Aplicacin CM. Procesador CM toma un enfoque de plataforma centrada. Servicios de CM Red y Sistema Distribuido de CM permiten a los sistemas remotos a ser gestionados y controlados incluyendo el intercambio de estado de la red. Topologa de CM se utiliza para controlar la topologa de las entidades fsicas o lgicas que se distribuyen. CM aplicacin se centra en las aplicaciones. Gestin de la configuracin aparece tambin como servicios de gestin del cambio en 43.5.13 orientada a objetos Prestacin de Servicios .
Gestin del rendimiento de servicios monitorean aspectos de rendimiento de hardware, la plataforma y el software de aplicacin, y los componentes de red y proporcionar maneras de ajustar el sistema para cumplir con los objetivos de rendimiento. Disponibilidad y gestin de fallos servicios permiten un sistema para reaccionar ante la prdida o el funcionamiento incorrecto de los componentes del sistema, incluyendo hardware, software de plataforma y software de aplicacin. Gestin Contable servicios proporcionan la capacidad de gastos de los servicios para la carga y el reembolso.
Pgina536de670

TOGOF9.1
Gestin de Seguridad de los servicios de control de los servicios de seguridad de acuerdo con las polticas de seguridad aplicables. Administracin de impresin servicios ofrecen la posibilidad de gestionar los servicios de cola de impresin, tanto locales como remotos. Administracin de red de servicios comprenden elementos de todos los servicios descritos anteriormente, pero a menudo se tratan como un servicio separado. Copia de seguridad y restauracin de servicios proporcionan una instalacin de almacenamiento multi-nivel para garantizar la seguridad continua de datos en caso de fallo de un componente o subsistema. Online Administracin de discos servicios gestionar la utilizacin del almacenamiento en disco frente a los valores de umbral e invocan una accin correctiva. Administracin de licencias de servicios de apoyo a la aplicacin efectiva de los acuerdos de licencia de software. Servicios de cesin de objetos se describen en la seccin de Licencias de servicios en 43.5.13orientadaaobjetosPrestacindeServicios . Gestin de Capacidad servicios abordan tres funciones bsicas: o en curso de anlisis de gestin de la capacidad y el desempeo histrico y la capacidad o gestin de carga de trabajo para identificar y comprender las aplicaciones que utilizan el sistema o Planificacin de la capacidad para planificar los recursos de hardware necesarios para el futuro Instalacin de software de distribucin de servicios de apoyo, la instalacin, retirada, traslado, la activacin y actualizacin automtica de software o paquetes de datos desde medios transportables o a travs de redes. Servicios similares para los objetos se describen en los servicios de instalacin y activacin en 43.5.13orientadaaobjetos PrestacindeServicios .
Trouble Ticketing servicios de apoyo a la generacin, procesamiento y seguimiento de los informes de problemas. Problemas de venta de entradas es un trmino de origen en el mundo de las telecomunicaciones, en referencia a la capacidad de pasar informes de faltas tanto dentro como entre los proveedores de servicios de telecomunicaciones. En este entorno, las fallas se encuentran a menudo por un cliente de un proveedor, mientras que la causa del problema se encuentra en el dominio administrativo de otro proveedor. Venta de entradas El problema es que un servicio comn que puede ser til para una gama creciente de aplicaciones si el trabajo se hace necesario hacer que descienda de las telecomunicaciones en las zonas ms amplias de aplicaciones distribuidas, tales como el correo electrnico.
Pgina537de670

TOGOF9.1
Esta ruptura de los servicios del sistema y gestin de la red es paralela a la ruptura de las nuevas de gestin de red OSI, lo cual representa un marco global coherente que se aplica por igual a las redes integrales y los nodos individuales de las redes. Una consideracin importante de las normas de apoyo a los servicios de esta categora es que no deben hacer cumplir las polticas de gestin especficas, sino ms bien permitir que una amplia variedad de diferentes polticas de gestin a implementar, seleccionados de acuerdo con las necesidades particulares de las instalaciones del usuario final. Servicios de gestin del sistema y de red necesitan la cooperacin de otras entidades de software en:
Proporcionar informacin sobre el estado Eventos notificantes En respuesta a las instrucciones de manejo
43.5.13 orientada a objetos Prestacin de Servicios
En esta seccin se muestra cmo se prestan los servicios de una manera orientada a objetos. "Servicios de objeto" no aparece como una categora en el modelo de referencia tcnica (TRM), ya que todos los servicios de objetos individuales se incorporan en su caso, en las categoras de servicios dados. Un objeto es una entidad identificable, encapsulado que proporciona uno o ms servicios que pueden ser solicitadas por un cliente. Los clientes solicitan un servicio invocando el mtodo apropiado asociado con el objeto, y el objeto lleva a cabo el servicio en nombre del cliente. Los objetos proporcionan un paradigma de programacin que puede conducir a importantes beneficios, entre ellos:
El aumento de la modularidad Una reduccin en los errores Facilidad de depuracin
Servicios de gestin de objetos proporcionan formas de crear, localizar y nombrar a los objetos, y que les permite comunicarse en un entorno distribuido. El conjunto completo de servicios de objetos identificados hasta ahora se enumeran a continuacin en aras de la exhaustividad. . Cuando un servicio objeto en particular es parte de una categora de servicio de aplicacin ms general, se le da un puntero a la otra categora de servicio objeto servicios incluyen:
Object Request Broker (ORB) . servicios, que permiten a los objetos para hacer y recibir las solicitudes y respuestas en un entorno distribuido de forma transparente los servicios ORB incluyen:
Pgina538de670

TOGOF9.1
o Implementacin del repositorio servicios apoyan la ubicacin y la gestin de implementaciones de objetos. Los servicios se asemejan a las que proporciona el diccionario de datos / servicios de repositorio en 43.5.2Serviciosdeadministracinde datos . o Instalacin y activacin de servicios proporcionan formas de distribuir, instalar, activar y mover los objetos. Esto corresponde a los Servicios de instalacin de software en 43.5.12SistemayServiciosdegestindered . o Interface Repository servicios apoyan el almacenamiento y gestin de la informacin acerca de las interfaces a los objetos. Los servicios se asemejan a las que proporciona el diccionario de datos / servicios de repositorio en 43.5.2Servicios deadministracindedatos . o replicacin de replicacin de servicios de soporte de objetos en sistemas distribuidos, incluyendo la gestin de la coherencia entre las copias. Objeto comn de servicios, que proporcionan funciones bsicas para el uso y aplicacin de objetos. . Estos son los servicios necesarios para construir cualquier aplicacin distribuida por objeto servicios comunes incluyen: o Gestin del Cambio servicios proporcionan para identificacin de la versin y la configuracin de interfaces de objetos, implementaciones y casos. Esto corresponde a los servicios de administracin de configuracin que se describen en 43.5.12SistemayServiciosdegestindered . o Colecciones servicios proporcionan operaciones sobre colecciones de objetos, como listas, rboles, pilas, o colas. Los servicios incluyen el establecimiento, la adicin de objetos, o sacarlos de las colecciones, poniendo a prueba la pertenencia establecido, formando uniones e intersecciones de conjuntos, y as sucesivamente. o el control de concurrencia servicios permiten a varios clientes para coordinar su acceso a los recursos compartidos. Sincronizacin como ste se proporciona normalmente con los servicios prestados en Kernel 43.5.7serviciosdelsistema operativo . o Data Interchange servicios apoyan el intercambio de informacin visible estado entre los objetos. Dependiendo del tipo de objeto implicado, esto corresponde a una o ms de los servicios prestados en 43.5.1DataInterchangeServices . o Gestin de eventos servicios proporcionan capacidades bsicas para la gestin de eventos, incluyendo eventos asncronos, evento "fan-in", la notificacin de "fanout", y entrega de eventos confiable. o Externalizacin de servicios definen los protocolos y convenciones para la externalizacin y la internalizacin de los objetos. Medios de grabacin el estado del objeto en una corriente de datos de externalizacin, y medios de internalizacin recrear un estado del objeto a partir de un flujo de datos. Este es un ejemplo de la Presentacin de la Informacin y las funciones de distribucin en 43.5.1Serviciosde datosdeintercambio .
Pgina539de670

TOGOF9.1
o licencias de polticas de apoyo a los servicios para la concesin de licencias de objetos y medicin y tarificacin por el uso de objetos. Esto corresponde a los servicios de gestin de licencias en 43.5.12SistemayServiciosdegestindered . o Ciclo de Vida de los servicios definen las convenciones para crear, eliminar, copiar y mover objetos. La creacin de objetos se define en trminos de los objetos de la fbrica, que son objetos que crean otros objetos. o Asignacin de nombres a los servicios proporcionan la capacidad de unirse a un nombre a un objeto, y para localizar un objeto por su nombre. Esto es anlogo al servicio Nombre Distribuida descrito en 43.5.6Serviciosdered . o de objetos persistentes servicios proporcionan interfaces comunes para retener y gestionar el estado persistente de los objetos. Objetos menudo se almacenan en un SGBDOO, describen como uno de los servicios de gestindedatos43.5.2 . o Propiedades de los servicios de apoyo a la creacin, supresin, misiones, y la proteccin de las propiedades dinmicas asociadas con los objetos. o Consulta de los servicios de soporte de indexacin y las operaciones de consulta de las colecciones de objetos que devuelven un subconjunto de la coleccin. Esto es similar a la base de datos de consulta, una parte de las funciones de DBMS en ServiciosdeGestindeDatos43.5.2 . o Relacin servicios permiten relaciones entre los objetos (tales como la propiedad o de contencin) que se representan explcitamente como objetos. o de seguridad de control de acceso de servicios de apoyo en los objetos y no repudio de las operaciones sobre los objetos. El control de acceso se define como un servicio de seguridad (ver 43.5.11ServiciosdeSeguridad ). No repudio, que es tambin un servicio de seguridad, proporciona la prueba de que una accin se llev a cabo por un usuario particular en un momento particular. o de puesta en marcha de servicios de apoyo automtico de inicio y terminacin de los servicios objeto de ORB puesta en marcha o terminacin. o Tiempo de sincronizacin de servicios de apoyo de los relojes en un sistema distribuido. Esto es lo mismo que el servicio de hora Distribuido en 43.5.6Servicios dered . o de comercio de servicios permiten a los clientes a localizar los objetos por los servicios de los objetos proporcionan, en lugar de por su nombre. Esto es similar a la de servicio de nombres distribuido en 43.5.6Serviciosdered . o transacciones de servicios proporcionan facilidades para agrupar operaciones en unidades atmicas, llamado "transacciones", con la certeza de que una transaccin se llevar a cabo en su totalidad o en absoluto. Esto corresponde a algunos de los servicios del gestor de transacciones de ServiciosdeProcesamiento deTransacciones43.5.9 .
Pgina540de670

TOGOF9.1
Pgina541de670

TOGOF9.1
44. Integrado de Informacin de Referencia Infraestructura Modelo

En este captulo se describe la informacin integrada de referencia Infraestructura Modelo (III-RM), en trminos de sus conceptos, una visin general, y la taxonoma.
44.1 Conceptos bsicos

Esta seccin trata de los conceptos bsicos de la III-RM, incluyendo antecedentes, componentes y conductores.
44.1.1 Antecedentes
Con la aparicin de las tecnologas basadas en Internet en los ltimos aos, para muchas organizaciones el principal foco de atencin, y el circuito de retorno de la inversin en la arquitectura esfuerzo, se ha desplazado desde el espacio de la plataforma de aplicaciones para el espacio de software de aplicacin. (De hecho, este ha sido uno de los factores que impulsan la migracin de s TOGAF de un marco y un mtodo para la Tecnologa de la Arquitectura a uno para la arquitectura global de la empresa.) El Modelo de Referencia Tcnica TOGAF (TRM) se describe en el 43. Fundacin Arquitectura: Modelo de referencia tcnica se centra en el espacio de la plataforma de aplicaciones. En esta seccin se describe un modelo de referencia que se centra en el software de aplicacin espacial, y "Sistemas Comunes de Arquitectura" en trminos de Enterprise Continuum. Este es el Integrado de Informacin de Referencia Infraestructura Modelo (IIIRM). El III-RM es un subconjunto de la TOGAF TRM en trminos de su alcance general, sino que tambin se expande ciertas partes de la TRM - en particular, las aplicaciones de negocio y aplicaciones de infraestructura partes - con el fin de proporcionar ayuda para hacer frente a una de las claves desafos que enfrenta el arquitecto empresarial de hoy: la necesidad de disear una infraestructura de informacin integrada para permitir sin fronteras flujo de informacin. Estos conceptos se explican en detalle a continuacin. Esta seccin introductoria examina el concepto de flujo de informacin sin fronteras; por qu es necesaria una infraestructura de informacin integrada que le permita;y cmo el IIIRM puede ayudar al arquitecto en el diseo de una infraestructura de informacin integrada para su empresa.
Pgina542de670

TOGOF9.1 44.1.2 componentes del modelo
Al igual que el TOGAF TRM, el III-RM tiene dos componentes principales:

1. Una taxonoma , que define la terminologa, y proporciona una descripcin coherente de
los componentes y la estructura conceptual de una infraestructura de informacin integrada
2. Un asociado grfico III-RM , que proporciona una representacin visual de la taxonoma, y la interrelacin de los componentes, como una ayuda para la comprensin
El modelo supone la existencia subyacente de una plataforma de computacin y la red, como se describe en la TRM; estos no se representan en el modelo.
44.1.3 Relacin con otras partes de TOGAF
La relacin de la III-RM a la TRM se explica ms arriba. Aunque el III-RM se pretende ser una herramienta til en la ejecucin de la Arquitectura Mtodo de Desarrollo de TOGAF (ADM), es importante destacar que la ADM es de ninguna manera depende del uso de la RM-III (ms de lo que es depende del uso de la TRM). Existen otras taxonomas y modelos de referencia en este espacio que se puede utilizar en conjuncin con el ADM, y de hecho pueden ser preferibles para algunas organizaciones.
Drivers 44.1.4 clave de negocio y tcnicos
44.1.4.1 problema de espacio: la necesidad de flujo de informacin sin fronteras
El problema de espacio sin fronteras de flujo de informacin es uno que es compartido por muchos de los miembros de los clientes de The Open Group, y por muchas otras organizaciones similares en todo el mundo. Es esencialmente el problema de la obtencin de informacin a las personas adecuadas en el momento adecuado de una manera segura y fiable, con el fin de apoyar las operaciones que son fundamentales para la empresa extendida. En General Electric, Jack Welch invent el trmino "la Organizacin sin fronteras", no quiere decir que no hay lmites, pero que deben hacerse permeable. La creacin de estructuras organizativas que permitieron a cada departamento para operar con la mxima eficiencia fue durante mucho tiempo aceptado como el mejor enfoque para la gestin de una gran empresa. Entre otros beneficios, este enfoque fomenta el desarrollo de conocimientos especializados en el personal, que se podran aplicar esas habilidades a aspectos especficos de una actividad general (como un proceso de fabricacin), con el fin de cumplir las tareas implicadas mejor, ms rpido y ms barato.
Pgina543de670

TOGOF9.1
A medida que cada actividad global progres a travs de la organizacin, que pasa de un departamento a otro (por ejemplo, desde el diseo hasta la produccin a las ventas), cada departamento tomara insumos del departamento anterior en el proceso, podr aplicar sus propios procesos de negocio para la actividad, y enviar su salida al siguiente departamento en lnea. En el mundo actual donde la velocidad, la flexibilidad y la capacidad de respuesta a los cambios del mercado marcan la diferencia entre el xito y el fracaso, este mtodo de trabajo ya no es apropiado. Las organizaciones han estado tratando durante algn tiempo para superar las limitaciones impuestas por las estructuras tradicionales de organizacin. Se han emprendido y abandonado porque eran demasiado ambiciosos, mientras que otros cuestan mucho ms en tiempo y dinero de lo previsto originalmente Muchos esfuerzos de reingeniera de procesos de negocio. Sin embargo, las organizaciones de hoy en da reconocen que no necesitan abandonar la organizacin funcional o departamental en conjunto. Pueden permitir que las personas adecuadas se renan en equipos multifuncionales de modo que todas las habilidades, conocimientos y experiencia pueden ser ejercidas sobre cualquier problema especfico o una oportunidad de negocio. Pero esto a su vez plantea sus propios desafos. CIOs estn bajo una enorme presin para facilitar el acceso a la informacin a cada equipo multifuncional segn sea necesario-, y sin embargo, las fuentes de estos datos pueden ser numerosas y los volmenes enormes. Peor an, los sistemas informticos, que se han construido en un perodo de 20 o 30 aos a un costo de miles de millones de dlares, y no estn a punto de ser expulsado o al por mayor reemplazado, fueron construidos para cada departamento funcional. As que a pesar de que puede ser posible que la gente a trabajar juntos de manera efectiva (no es un logro menor en s mismo), los sistemas informticos que utilizan estn diseados para soportar el pensamiento de estilo antiguo. Los sistemas de TI en lugar de hoy no permiten que la informacin fluya en apoyo de la organizacin sin fronteras. Cuando lo hacen, entonces tendremos sin fronteras Flujo de Informacin.
44.1.4.2 Solucin Espacio: La necesidad de una infraestructura de informacin integrada
El Open Group Interoperable Enterprise Business Escenario 1 publicado originalmente en 2001, cristaliza esta necesidad sin fronteras Flujo de informacin y describe la forma en que esta necesidad impulsa el despliegue de su infraestructura de la informacin de los clientes de TI. En este escenario, planteamiento del problema del cliente dice que yo (como la empresa cliente) podra ganar eficiencias operativas significativas y mejorar los diferentes procesos de negocio de la empresa - tanto los procesos internos, y los que abarca las principales
Pgina544de670

TOGOF9.1
interacciones con los proveedores, clientes y socios - si tan slo pudiera dar mi personal con:
Informacin integrada para que diferentes y potencialmente conflictivas piezas de informacin que no se distribuyen a travs de diferentes sistemas Acceso integrado a esa informacin a fin de que el personal pueda acceder a toda la informacin que necesitan y tienen derecho a, a travs de una cmoda interfaz
La infraestructura que permite a esta visin se denomina la "infraestructura de informacin integrada". A modo de ejemplo, un enfoque actual de la infraestructura de informacin integrada es proporcionar "portales empresariales" que permiten un acceso integrado a la informacin de diferentes sistemas de aplicaciones, a travs de una cmoda interfaz web-enabled, (uno de los segmentos de color en los extremos de toda la empresa el cilindro en la Figura 44-1 ).
Figura441:Unaaproximacinalflujodeinformacinsinfronteras(EnterprisePortals)
Uno de los principales retos para el arquitecto en la empresa de hoy es trabajar, y luego comunicar a la alta direccin, como las tecnologas lejanos como los servicios web,
Pgina545de670

TOGOF9.1
servicios de integracin de aplicaciones, etc, se van hacia el logro de una infraestructura de informacin integrada, y darse cuenta de la visin sin fronteras Flujo de Informacin, en la empresa de que se trate. Anlisis de seguimiento del Grupo Abierto del Escenario Interoperable Enterprise Business ha dado lugar al desarrollo de un modelo integrado de infraestructura de la informacin (el III-RM), que representa a los principales componentes necesarios para abordar el problema de espacio sin fronteras Flujo de Informacin, y puede ayudar al arquitecto en esta tarea. As, el III-RM ofrece ideas relacionadas con las necesidades del cliente para sin fronteras flujo de informacin en entornos empresariales. El modelo tambin apunta a las reglas y normas para ayudar a aprovechar las soluciones y productos dentro de la cadena de valor. Las siguientes subsecciones discuten el modelo en detalle.
44.1.5 Situacin de la IIIRM
El III-RM se documenta en su forma actual, y de ninguna manera considerados un artculo acabado. Sin embargo, se trata de un modelo que ha sido desarrollado y aprobado por los miembros de The Open Group en su conjunto, en respuesta a la Interoperable Enterprise Business Scenario, que a su vez se desarroll en respuesta a la urgente necesidad expresada por los miembros de los clientes de The Open Grupo de ayuda en este campo. El escenario de negocios y el modelo de referencia por lo tanto representan un problema y un enfoque de solucin que la pertenencia al grupo abierto en su conjunto apoya plenamente. Se espera que la publicacin de la modelo como parte de TOGAF fomentar su adopcin y el uso generalizado, y proporcionar un canal de comunicacin mediante el cual la experiencia con el uso del modelo puede ser realimentada, puntos de mejora asimilado, y el modelo refinado y reeditado como sea necesario .
44.2 de Alto Nivel View

Esta seccin proporciona una vista de alto nivel de la III-RM, incluyendo derivacin del modelo, grfico de alto nivel, y los componentes.
44.2.1 Obtencin de la IIIRM de la TRM
El III-RM es un modelo de las principales categoras de componentes para el desarrollo, gestin y operacin de una infraestructura de informacin integrada. Se trata de un modelo de un conjunto de aplicaciones que se sienta encima de una plataforma de aplicaciones. Este modelo es un subconjunto de la TOGAF TRM, y utiliza una orientacin ligeramente diferente.
Pgina546de670

TOGOF9.1
Considere la Figura 44-2 , donde se presentan dos vistas de la TOGAF TRM. El lado izquierdo es la visin familiar de la TOGAF TRM; es una vista lateral, donde nos fijamos en el modelo como si estuviera buscando en una casa del lado, revelando el contenido de los "pisos". La vista de arriba hacia abajo en la parte derecha representa lo que se podra ver si la mirara a una casa del "techo" abajo.
Figura442:TOGAFTRMOrientacinVistas
El subconjunto de la TRM que comprende el III-RM se representa en la figura 44-3 , en el que las partes de la TRM no es relevante para la III-RM estn "en gris".
La figura 44-3 ilustra que la atencin se centra en el software de aplicacin, la plataforma de aplicaciones y cualidades subconjunto del TOGAF TRM.
Pgina547de670

TOGOF9.1
Figura443:EnfoquedelaIIIRM
44.2.2 de Alto Nivel IIIRM Grfico
El propio III-RM resultante se representa en la Figura 44-4 . Es fundamentalmente un modelo de referencia de arquitectura de aplicaciones - un modelo de componentes de aplicaciones y servicios de aplicacin de software esencial para una infraestructura de informacin integrada. (Hay ms aplicaciones de negocios y aplicaciones de infraestructura que stas en el medio ambiente, por supuesto, pero estos son los subconjuntos relevantes para el problema de espacio sin fronteras Flujo de Informacin.)
Pgina548de670

TOGOF9.1
Figura444:IIIRMdeAltoNivel
Como se explic anteriormente, el modelo supone la existencia subyacente de un clculo y la plataforma de red, y no representa a ellos explcitamente. Aunque la computacin y de la plataforma de red no se muestran, puede haber requisitos en los que se deben cumplir, adems de los requisitos de los componentes de la III-RM, con el fin de abordar plenamente el problema de espacio sin fronteras Flujo de Informacin.
44.2.3 Componentes de Alto Nivel IIIRM
El III-RM tiene los siguientes componentes principales:

Aplicaciones empresariales , designados por las cajas amarillas en el modelo de alto nivel (que corresponden al cuadro "Aplicaciones empresariales" en el grfico TRM). Hay tres tipos de Aplicaciones de Negocio en el modelo: o Aplicaciones de intermediacin , que gestionan las solicitudes de cualquier nmero de clientes ya travs de cualquier nmero de aplicaciones de los proveedores de informacin
Pgina549de670

TOGOF9.1
o aplicaciones de proveedores de informacin , que proporcionan respuestas a las peticiones de los clientes y el acceso rudimentario a los datos gestionados por un servidor particular o Aplicaciones de Informacin al Consumidor , que entregan contenido al usuario del sistema, y proporcionan servicios para solicitar el acceso a la informacin en el sistema en nombre del usuario Aplicaciones Infraestructura , denotados por las cajas de color naranja en el modelo de alto nivel (que corresponden al cuadro "Aplicaciones de Infraestructura" en el grfico TRM). Hay dos tipos de Aplicacin Infraestructura en el modelo: o Herramientas de desarrollo , que proporcionan todo el modelado es necesario, el diseo, la construccin y las capacidades para desarrollar e implementar aplicaciones que requieren acceso a la infraestructura de informacin integrada, de manera compatible con las normas de medio ambiente o Servicios de Gestin , que proporcionan todos los servicios pblicos necesarios para comprender, operar, ajustar y administrar el sistema en tiempo de ejecucin con el fin de satisfacer las demandas de un negocio en constante cambio, de una manera consistente con las normas de medio ambiente Una plataforma de aplicaciones , que proporciona servicios de apoyo a todas las aplicaciones mencionadas - en reas tales como la ubicacin, el directorio, el flujo de trabajo, gestin de datos, intercambio de datos, etc - y por lo tanto proporciona la capacidad de encontrar, manipular y mover la informacin dentro del entorno. Este conjunto de servicios constituye un subconjunto del conjunto total de los servicios de la plataforma de aplicaciones de TRM, y se representa por la capa base de color verde oscuro en el modelo de alto nivel (que corresponde a la plataforma de aplicaciones en el grfico TRM). Las interfaces utilizadas entre los componentes. Las interfaces incluyen formatos y protocolos, interfaces de programacin de aplicaciones, switches, los valores de datos, etc Interfaces entre los componentes a nivel de aplicacin son de color rojo. Interfaces entre los componentes de nivel de aplicacin y sus servicios de apoyo en la plataforma de aplicaciones son de color blanco (que corresponde a la caja de API en el grfico TRM). El Cualidades backplane, denotado por la capa base de color marrn en el modelo de alto nivel (que corresponde a la placa posterior Cualidades en el grfico TRM). El software de aplicacin y la plataforma de aplicaciones deben cumplir con las polticas y los requisitos descritos por el backplane cualidades.
44.3 Taxonoma detallada

En esta seccin se ofrece una taxonoma detallada de la III-RM, incluyendo grfica detallada, las categoras de servicios de plataforma, y el medio ambiente sub-entidades externas.
Pgina550de670

TOGOF9.1 44.3.1 detallada IIIRM Grfico
El detallado III-RM se muestra en la Figura 44-5 .

Figura445:IIIRMDetallado
Las restantes subsecciones se expanden en el detalle taxonoma / componente se muestra en la Figura 44-5 .
44.3.2 Aplicaciones de Negocio
Hay tres tipos de aplicaciones de negocio en el modelo:

Aplicaciones proveedor de informacin , que proporcionan respuestas a las solicitudes de los clientes y el acceso rudimentario a los datos gestionados por un servidor particular Aplicaciones de intermediacin , que gestionan las solicitudes de cualquier nmero de clientes hacia y a travs de cualquier nmero de proveedores de servicios Informacin de los usos del consumidor , que entregan contenido al usuario del sistema, y prestan servicios a la solicitud de acceso a la informacin en el sistema en nombre del usuario
El conjunto global de proveedor de informacin, de informacin al consumidor, y aplicaciones de corretaje crea colectivamente un entorno que proporciona un amplio
Pgina551de670

TOGOF9.1
conjunto de servicios de usuario final para acceder de forma transparente los sistemas heterogneos, bases de datos y sistemas de archivos.
44.3.2.1 Informacin Aplicaciones Proveedores
En la medida en que la informacin de hoy puede ser considerado como "rehenes", como se muestra en la Figura 44-6 , Aplicaciones proveedor de informacin son las aplicaciones que "liberar" a los datos de sus silos.
Figura446:LiberatedatosSilosparasatisfacerlasnecesidadesdeinformacindelosequiposdelaempresa defuncionescruzadas
Aplicaciones proveedor de informacin a lograr esto proporcionando una interfaz abierta para una interfaz de silo potencialmente propietario, como se ilustra en la Figura 44-7 , donde los puertos en la izquierda de la informacin de aplicaciones de proveedores estn interfaces abiertas y las interfaces entre las aplicaciones de los proveedores de informacin y datos de silo son interfaces propietarias.
Pgina552de670

TOGOF9.1
Figura447:InformacinAplicacionesProveedoresLiberatededatos,proporcionandointerfacesabiertasa losdatosSilos
44.3.2.2 Aplicaciones Corretaje
Aplicaciones de corretaje sirven peticiones individuales que requieren acceso a mltiples fuentes de informacin. Una aplicacin de Bolsa analiza dicha solicitud, distribuye la solicitud a mltiples fuentes de informacin, recoge las respuestas, y enva una nica respuesta al cliente solicitante. Aplicaciones de corretaje acceder a la informacin del proveedor de aplicaciones que utilizan las interfaces abiertas proporcionadas por las aplicaciones de los proveedores de la informacin (como se describe ms arriba); que integran la informacin de mltiples aplicaciones de los proveedores de informacin y transmiten la informacin integrada para aplicaciones de informacin al consumidor mediante interfaces abiertas. Aplicaciones de corretaje tambin permiten el acceso a la informacin dentro de la empresa por los socios estratgicos.
Pgina553de670

TOGOF9.1
Figura448:AplicacionesdecorretajeintegrarlainformacindelaInformacinAplicacionesProveedores
44.3.2.3 Informacin usos del consumidor
Informacin de los usos del consumidor facilitan informacin a los usuarios en la forma en que la necesitan, cuando lo necesitan, y de una manera segura a terminar.Esto incluye el suministro de la informacin en el texto, video, audio, Ingls, Alemn, etc Informacin de los usos del consumidor se comunican con las aplicaciones de corretaje o Aplicaciones proveedor de informacin que utilizan las interfaces abiertas que las aplicaciones Corretaje e Informacin de Proveedores proporcionan. La seguridad se proporciona a travs de los servidores de seguridad y / o servicios de seguridad.
La figura 44-9 muestra las aplicaciones de consumidor de informacin con los servicios de
seguridad que aparecen como el patrn de ladrillo.
Pgina554de670

TOGOF9.1
Figura449:Informacinusosdelconsumidorsecomunicanmedianteinterfacesabiertas
44.3.3 Aplicaciones Infraestructura
Hay dos tipos de Aplicacin Infraestructura en el modelo:

Herramientas de desarrollo , que proporcionan todo el modelado es necesario, el diseo, la construccin y las capacidades para desarrollar e implementar aplicaciones que requieren acceso a la infraestructura de informacin integrada, de manera compatible con las normas de medio ambiente Utilidades de gestin , que proporcionan todos los servicios pblicos necesarios para comprender, operar, ajustar y administrar el sistema en tiempo de ejecucin con el fin de satisfacer las demandas de un negocio en constante cambio, de manera compatible con las normas de medio ambiente 44.3.3.1 Herramientas de desarrollo
El componente Herramientas de Desarrollo del modelo comprende aplicaciones que toman la forma de herramientas para el modelado, diseo y construccin de la infraestructura de informacin integrada. En concreto, incluye herramientas para los negocios, procesos y modelado de datos, as como las herramientas para la construccin de aplicaciones tradicionales que transforman el modelo de negocio en el software que automatiza los procesos de negocio que giran en torno a la informacin.
Pgina555de670

TOGOF9.1
Tenga en cuenta que cada conjunto de herramientas estar conectada lgicamente a travs de un directorio, lo que permite una herramienta a ser impulsado por los datos de otra. Las secciones siguientes describen los requisitos para componentes de herramientas de desarrollo. El conjunto de herramientas tambin incluye un repositorio.
Herramientas de Modelado de Negocios
Esta categora cubre las herramientas para el modelado de reglas de negocio y reglas de procesos de negocio. Modelado de actividades se describe y documenta el negocio de una amplia base de conocimientos. Establece un consenso entre la direccin general de los requisitos de direccin de negocio, organizacin, procesos, informacin y el entorno actual de los negocios. Tal vez lo ms importante es que esta comprensin se documenta en un formato comn, orientada a los negocios que se utilizarn para la mejora posterior.
Herramientas de Modelado Diseo
Esta categora cubre las herramientas para disear, definir y documentar los elementos de TI ms relevantes de la empresa sobre la base de las reglas de negocio y los procesos de negocio. Ejemplos de elementos a ser diseados incluyen: conexiones entre las personas, las organizaciones, los flujos de trabajo y ordenadores; datos y modelos de objetos; traduccin de datos fsica y las reglas de traduccin; y limitaciones.
Implementacin y herramientas de construccin
Instrumentos de aplicacin permiten el desarrollo oportuno de los reutilizables procesos, aplicaciones y servicios de aplicacin. Estas herramientas incluyen navegadores inteligentes, los compiladores de lenguaje de manipulacin de datos y optimizadores, compiladores de aplicaciones distribuidas y depuradores, cliente y servidor de desarrollo de herramientas heterogneas, las herramientas de definicin de polticas y herramientas de generacin de scripts del flujo de trabajo.
Herramientas de Modelado de Datos Herramientas de implementacin
Herramientas de implementacin son necesarios para mover el software implementado en el entorno de desarrollo en el entorno operativo.
Bibliotecas
Pgina556de670

TOGOF9.1
Este componente incluye las bibliotecas reutilizables de software que utilizan las normas del entorno operacional.
44.3.3.2 Gestin de Servicios Pblicos
Esta categora cubre las aplicaciones que toman la forma de utilidades para las operaciones, la administracin y gestin de redes, y de la gestin de los datos en funcin de los requisitos de disponibilidad y costo. Dichas utilidades pueden ejecutarse en una o en un entorno desatendido asistido.
Operaciones, Administracin y Gestin (OA & M) Utilidades
El componente de OA & M cubre servicios de gestin y administracin de sistemas tradicionales que gestionan las reglas de negocio y los objetos de informacin.Algunos ejemplos son: utilidades para la instalacin, derechos de autor y la gestin de licencias; y administracin miscelnea, la configuracin y las funciones de registro. Adems, existen utilidades para el control de la facturacin del servicio, el servicio de activacin y administracin de cuentas.
Calidad de servicio Administrador de Utilidades
Estos incluyen utilidades de monitorizacin y gestin de la salud.

Copia Gestin De Servicios
Utilidades de administracin de copia son los que gestionan el movimiento de datos desde cualquier sistema operativo dado a los puntos de distribucin necesarias en la empresa, con el fin de garantizar el mximo aprovechamiento de los datos de los sistemas operativos. Tambin se incluyen herramientas que detectan y bandera datos de mala calidad.
Administracin de almacenamiento Utilidades
Estos son los servicios pblicos que permita la gestin de almacenamiento de datos de menor costo. Utilidades de administracin de almacenamiento compatibles con la gran variedad de mecanismos de almacenamiento y estn conectados a un archivo, objeto, y los sistemas de bases de datos.
Pgina557de670

TOGOF9.1 44.3.4 Plataforma de Aplicaciones
Todos los diferentes tipos de aplicaciones descritas anteriormente se construyen en la parte superior de los servicios prestados por la plataforma de aplicaciones. El componente de la plataforma de aplicaciones de la III-RM comprende un subconjunto de todos los servicios que se definen en el TOGAF TRM, el subconjunto que se refiere a la infraestructura de informacin integrada. Especficamente, comprende todos los servicios en la plataforma de aplicaciones de TRM que permiten a las aplicaciones se centran en la comprensin y tratamiento de la informacin requerida, en lugar de comprender la forma, formato y / o ubicacin de la informacin. Los servicios del componente Application Platform se pueden utilizar para dar soporte a aplicaciones convencionales, as como Intermediacin, informacin para el consumidor, y las aplicaciones de proveedor de informacin. Cuando se utiliza como parte de una arquitectura global de aplicacin de esta forma, este enfoque permite la mxima influencia de un nico entorno operativo que est diseado para asegurar la transferencia efectiva y coherente de los datos entre los procesos, y para apoyar el desarrollo rpido y eficiente, la implementacin y la gestin de de aplicaciones. El componente de la plataforma de aplicaciones comprende las siguientes categoras de servicio.
44.3.4.1 Software Engineering Services Idiomas Bibliotecas Registros 44.3.4.2 Servicios de Seguridad Autenticacin, autorizacin y control de acceso Single Sign-On Firma digital Firewall Encryption La deteccin de intrusiones Gestin de la identidad
Pgina558de670

TOGOF9.1
Gestin de claves 44.3.4.3 Ubicacin y Servicios de Directorio
Ubicacin y directorio de servicios proporcionan facilidades de acceso para el nombre, ubicacin, descripcin y datos de relaciones que describe la infraestructura de informacin integrada. Los servicios de directorio compatibles con el despliegue y la disponibilidad de toda la empresa de un directorio de la infraestructura de informacin integrada. Los datos en el directorio se ponen a disposicin de todos los dems componentes en el modelo de arquitectura.
La figura 44-10 muestra la yuxtaposicin de ubicacin y servicios de directorio para los otros
componentes.
Figura4410:Yuxtaposicindeubicacinyserviciosdedirectorioparaotroscomponentes
Los servicios especficos incluyen:

Directorio Registro Publicacin / suscripcin Descubrimiento Nombrando
Pgina559de670

TOGOF9.1
Hacer referencia / eliminacin de referencias 44.3.4.4 Interaccin Humano Servicios
Servicios de interaccin humana proporcionan los medios para constantemente presentan datos al usuario final en el formato adecuado. Comprenden servicios que contribuyan a la formulacin de solicitudes de datos del cliente y permiten la visualizacin y presentacin de los datos consultados. Los servicios especficos incluyen:
Presentacin Transformacin Navegador Meta ndices Portal y personalizacin 44.3.4.5 Servicios de Data Interchange

Formato de Informacin Formularios Electrnicos Mensajera instantnea Aplicacin de mensajera Comunicacin de aplicacin a aplicacin Integracin de aplicaciones empresariales Servicios de administracin de datos 44.3.4.6

Informacin y datos de acceso Mapeo de Transformacin Distribucin de consultas Agregacin Bsqueda
Pgina560de670

TOGOF9.1
Expediente
Servicios de acceso a la informacin proporcionan la capacidad de una aplicacin para acceder a una visin integrada de los datos, independientemente de si existen los datos en un sistema de computadora central o en un sistema distribuido. Los servicios de acceso a la informacin aseguran que la integridad de datos se mantiene entre mltiples bases de datos, y tambin proporcionan la limpieza de datos en lnea (en el que los datos se comprueba con normas de datos para cada acceso). Servicios de acceso a datos proporcionan interfaces abiertas para los datos heredados, proporcionar nuevas aplicaciones de servicios de acceso a la base de datos estndar para grandes cantidades de datos existentes, y proporcionar servicios de acceso estndar a los nuevos tipos de datos.
44.3.4.7 Otros servicios del sistema operativo

Intermediacin Evento Workflow
Estos servicios adicionales permiten el flujo de informacin, como se representa en la figura 44-11 .
Pgina561de670

TOGOF9.1
Figura4411:WorkflowServicesHabilitarFlujodeInformacin
Flujo de trabajo denota el concepto de automatizacin de procesos, facilitando las interacciones del usuario y la ejecucin de aplicaciones de acuerdo con un mapa de procesos. Los servicios de flujo de trabajo permiten la integracin de aplicaciones empresariales, lo que resulta en aplicaciones de valor extendida. Los servicios de flujo de trabajo tambin se ocupan de las necesidades de la gestin de un entorno en el que los sistemas heredados son frecuentes. Los servicios de flujo de trabajo tambin proporcionan un medio para encapsular las aplicaciones existentes, apoyando as las necesidades del cliente para el apalancamiento de los activos existentes.
44.3.5 Cualidades
El componente de las cualidades del modelo se apoya en la calidad de los servicios de servicio, incluyendo los diversos servicios que se requieren para mantener la calidad del sistema como se especifica en los Acuerdos de Nivel de Servicio (SLA). En esto se incluyen los servicios a crear las condiciones para, y reaccionar a las peticiones de la Calidad de Service Manager.
Pgina562de670

TOGOF9.1
PARTE VII Marco de Arquitectura de Capacidad

Pgina563de670

TOGOF9.1
45. Introduccin
Este captulo proporciona una introduccin y una visin general de los contenidos de la parte VII: Arquitectura del marco de Capacidad .

Con el fin de operar con xito una funcin de la arquitectura dentro de una empresa, es necesario poner en marcha las estructuras apropiadas de organizacin, procesos, funciones, responsabilidades y habilidades para realizar la Capacidad de Arquitectura.
Parte VII: Architecture Framework Capacidad proporciona un conjunto de materiales de referencia
para la forma de establecer una funcin de este tipo de arquitectura. Los lectores deben tener en cuenta que aunque esta parte contiene una serie de directrices para apoyar actividades clave, en su forma actual, el Marco de Capacidad Arquitectura no pretende ser una plantilla completa para el funcionamiento de una capacidad de arquitectura empresarial. Una estructura general para el marco de capacidades de Arquitectura se muestra en la Figura
45-1 .
Pgina564de670

TOGOF9.1
Figura451:ArquitecturaMaduroCapability
45.2 Estructura de la Parte VII

Parte VII: Arquitectura del marco de Capacidad est estructurado de la siguiente manera: Introduccin (este captulo) Establecer una capacidad de Arquitectura (ver 46.establecerunacapacidaddeArquitectura ) Architecture Board (ver 47.ArchitectureBoard ) Arquitectura de cumplimiento (vase 48.ArquitecturadeCumplimiento ) Contratos de Arquitectura (ver 49.ArquitecturaContratos ) Arquitectura de control (vase 50.ArquitecturadeGobierno ) Modelos de Madurez Arquitectura (ver 51.ArquitecturadeMadurezModelos ) Arquitectura Skills Framework (vase 52.ArquitecturaSkillsFramework )
Pgina565de670

TOGOF9.1
Pgina566de670

TOGOF9.1
46. Establecer una capacidad de Arquitectura

Este captulo proporciona directrices sobre cmo utilizar el ADM para establecer una capacidad de Arquitectura.

Como con cualquier capacidad de negocio, la creacin de una capacidad de arquitectura empresarial puede ser apoyado por el Mtodo de Desarrollo de Arquitectura TOGAF (ADM). El uso exitoso de la ADM proporcionar una prctica de valor aadido, y la arquitectura sostenible centrada en el cliente que permite a la empresa, ayuda a maximizar el valor de las inversiones, e identifica proactivamente las oportunidades de obtener beneficios de negocio y gestionar el riesgo. El establecimiento de un estudio de arquitectura sostenible dentro de una organizacin se puede lograr mediante la adhesin a la misma aproximacin que se utiliza para establecer las dems capacidades - tales como la capacidad de gestin de procesos de negocio - dentro de una organizacin. El ADM es un mtodo ideal para ser utilizado al arquitecto y gobernar la aplicacin de tal capacidad. La aplicacin de la ADM con el Architecture Vision especfica para establecer un estudio de arquitectura en la organizacin iba a lograr este objetivo. Esto no debe ser visto como una fase de un proyecto de arquitectura, o de un proyecto de una sola vez, sino ms bien como una prctica continua que ofrece el contexto, el ambiente y los recursos para gobernar y permitir la entrega de arquitectura para la organizacin. Como un proyecto de arquitectura se ejecuta dentro de este entorno que podra solicitar un cambio en la prctica de la arquitectura que dara lugar a un nuevo ciclo de la ADM de ampliar la prctica de la arquitectura. La implementacin de cualquier capacidad dentro de una organizacin requerira el diseo de las cuatro arquitecturas de dominio: de negocios, datos, aplicaciones, y Tecnologa. Por lo tanto, se establece la prctica de la arquitectura dentro de una organizacin requerira el diseo de:
La arquitectura de negocio de la prctica de la arquitectura que pondr de relieve la gobernabilidad arquitectura, los procesos de arquitectura, arquitectura estructura organizativa, las necesidades de informacin de arquitectura, productos de arquitectura, etc La Arquitectura de Datos que defina la estructura de la empresa Continuum y Arquitectura Repositorio de la organizacin
Pgina567de670

TOGOF9.1
La arquitectura de aplicaciones especificando la funcionalidad y / o servicios de aplicaciones se requiere para que el estudio de arquitectura La Tecnologa de la Arquitectura que describe las necesidades de infraestructura de la prctica de la arquitectura y el despliegue en apoyo de las aplicaciones de arquitectura y Empresa Continuum
Los pasos en el establecimiento de un estudio de arquitectura se explican a continuacin, contra el contexto de las fases de ADM. Por tanto, el lector debe referirse a la fase de ADM relevante en la Parte II: Arquitectura Mtodo de Desarrollo (ADM) , para comprender el alcance completo de cada paso. En esta seccin, los aspectos fundamentales se destacarn para cada fase de ADM que se debe considerar y son especficas para el establecimiento de un estudio de arquitectura. La intencin, por lo tanto no es repetir la descripcin de cada fase de ADM, pero para guiar al lector a aplicar cada fase de ADM en el contexto del establecimiento de una prctica de la arquitectura.
46.2 Fase A: Architecture Vision

El propsito de esta fase en el contexto del establecimiento de un estudio de arquitectura es definir o revisar la visin, las partes interesadas, y los principios de la prctica de la arquitectura. El objetivo en esta fase sera en la prctica de la arquitectura en su conjunto y no en un proyecto de arquitectura en particular. Lo siguiente debe ser considerado en trminos de comprensin de los pasos en el contexto del establecimiento de una prctica de la arquitectura:
Establecer el Proyecto : Este paso debe centrarse en la definicin de los grupos de inters en la prctica de la arquitectura. Las partes interesadas incluiran las funciones y unidades de la organizacin que participan en la prctica de la arquitectura, as como aquellos que se beneficiarn de las prestaciones generadas por la prctica de la arquitectura, por tanto, que se puede definir como los clientes de la prctica de la arquitectura. Identificar a los Interesados y preocupaciones, los requisitos de negocio y Architecture Vision : Este paso genera las primeras definiciones, muy de alto nivel de los entornos de referencia y objetivos, desde una perspectiva de los sistemas de informacin de negocios y tecnologa para la prctica de la arquitectura. Identificar objetivos de negocio y los impulsores del negocio : Esto sera ms relevante para la prctica de la arquitectura, que a un proyecto de arquitectura en particular. La comprensin de los objetivos de negocio y los conductores es esencial para alinear la prctica de la arquitectura para el negocio. Definir el Alcance : Definir el alcance de la prctica de la arquitectura sera un plan de proyecto de alto nivel de lo que debe ser abordado en trminos de arquitectura para el prximo perodo. Definir restricciones : El enfoque en este paso debe estar en las limitaciones de toda la empresa que impactaran en todos los proyectos de arquitectura.
Pgina568de670

TOGOF9.1
Revise Arquitectura Principios, incluidos los Principios de Actuacin : La intencin en este paso debe ser definir los principios que regiran y orientar la gestin de la prctica de la arquitectura. Cuando los principios de arquitectura generalmente rigen las prestaciones de arquitectura, los principios de la prctica de arquitectura abordaran la organizacin prctica de la arquitectura, el contenido, las herramientas, y el proceso. Desarrollar el Enunciado del Trabajo de Arquitectura y Aprobacin Secure : Este paso debe generar la prctica la visin y el mbito de la arquitectura.
Otro paso que se puede considerar en esta fase es llevar a cabo una evaluacin de la madurez de la arquitectura. Consulte 51. Modelos de Madurez de Arquitectura para la orientacin sobre este tema.
46.3 Fase B: Arquitectura de Negocios

Las reas clave de enfoque durante esta fase de establecimiento o el perfeccionamiento de la Arquitectura Empresarial de la prctica de la arquitectura son:
Una Arquitectura Ontologa definir los trminos y las definiciones que se utilizarn en la organizacin con el fin de establecer una comprensin comn de estos trminos arquitectnicos. El proceso de arquitectura donde el ADM formara la base del proceso y la necesidad de ser personalizado para satisfacer las necesidades de la organizacin y prctica de la arquitectura de la visin. Consulte 5.3AdaptacindelaADM para la orientacin en el desarrollo de este proceso. Los procesos de gobernanza arquitectura requeridas deben ser incluidos en el proceso general de la arquitectura. Los puntos de vista de arquitectura y vistas que muestra todos los puntos de vista y opiniones que deben ser abordados por el estudio de arquitectura. Las prcticas de los actores identificados arquitectura guiaran el desarrollo de esta definicin. Uno de los puntos de vista que deben incluirse es el punto de vista de la arquitectura de gobernanza; consulte laParteIV , 35.ArchitecturalArtifacts para orientarlos respecto a esta salida. La arquitectura marco descriptivo de las distintas entregas de arquitectura que se generarn por la prctica de la arquitectura, las interrelaciones y dependencias entre los entregables de arquitectura, as como las normas y directrices que rigen el diseo de estos productos entregables. Los puntos de vista y las opiniones de arquitectura definidos deben utilizarse para orientar la definicin del marco de la arquitectura. ParteII:Arquitectura MtododeDesarrollo(ADM) y 36.ArquitecturaEntregables son referencias tiles que ayudarn a describir el marco de la arquitectura. La Planilla de Responsabilidades Arquitectura definicin de las funciones en la prctica de la arquitectura y la asignacin de la responsabilidad de las funciones a las prestaciones y los procesos de arquitectura. Esta matriz incluira las estructuras necesarias arquitectura de gobernanza y roles. ParteII:ArquitecturaMtododeDesarrollo(ADM) , as como 47.ArchitectureBoard , 50.ArquitecturadeGobierno , y 52.ArquitecturaSkills Framework proporcionar orientacin sobre esta salida.
Pgina569de670

TOGOF9.1
La arquitectura de rendimiento Mtrica identificacin y descripcin de los indicadores que se utilizarn para monitorear el desempeo de la prctica de la arquitectura en contra de su declarada prctica la visin y los objetivos de la arquitectura. El Marco de Gobierno de Arquitectura , que es un punto de vista especfico del proceso de arquitectura definida y Arquitectura Planilla de Responsabilidades.
46.4 Fase C: Arquitectura de Datos

La Arquitectura de Datos de la prctica de la arquitectura especificara y gobernar la estructura de la empresa Continuum de la organizacin y arquitectura de repositorio. La Arquitectura de Datos debe definirse con base en el marco de la arquitectura. La Arquitectura de Datos se refiere a veces como el metamodelo de la prctica de la arquitectura.
46.5 Fase C: Arquitectura de aplicaciones

La Arquitectura de la aplicacin de la prctica de la arquitectura define la funcionalidad necesaria para generar, mantener, publicar, distribuir, y gobernar los entregables arquitectura como se define en el marco de la arquitectura. Un enfoque clave debe estar en los conjuntos de herramientas de modelizacin necesarias para modelar, pero no debera ser el nico foco. Consulte 42. Herramientas para el desarrollo de la arquitectura para la orientacin en la seleccin de un conjunto de herramientas. La publicacin de los entregables de arquitectura para hacer frente a puntos de vista especficos en el marco de la arquitectura a veces requieren una funcionalidad especializada o personalizada y no debe ser descuidado.
46.6 Fase D: Architecture Tecnologa

La Tecnologa de la Arquitectura de la prctica de la arquitectura debera definir la infraestructura de tecnologa de apoyo a la prctica de la arquitectura.
46.7 Fase E: Oportunidades y Soluciones

Un factor crtico a considerar durante esta fase de la planificacin de la creacin de la prctica de la arquitectura es el cambio organizacional que se requiere y cmo se va a lograr.
46.8 Fase F: planeamiento de migracin

El enfoque no debe ser slo en los componentes de los sistemas de informacin de arquitectura en esta fase, sino que incluyen la arquitectura de negocio. La adopcin del proceso de la arquitectura y el marco tendr un impacto importante en el establecimiento general de la prctica de la arquitectura en la organizacin.
Pgina570de670

TOGOF9.1
46.9 Fase G: Gobernanza Aplicacin

La implementacin de la Arquitectura Empresarial de la prctica de la arquitectura debe ser el foco de esta fase. Cambiar las prcticas dentro de la organizacin a adoptar un enfoque ms estructurado y disciplinado ser un reto y debe ser abordado por las tcnicas de cambio de organizacin adecuadas.
46.10 Fase H: Gestin Arquitectura Cambio

Los cambios en la arquitectura de la prctica de la arquitectura deben ser gestionados por esta fase. Estos cambios generalmente se activan durante la ejecucin de proyectos de arquitectura. Un cambio tpico sera el requisito para una nueva arquitectura entregable. Esto tendra un impacto en todos los mbitos de la arquitectura de la prctica de la arquitectura.
Gestin 46.11 Requisitos

La comprensin y la gestin de los requisitos para la prctica de la arquitectura es crucial. Los requisitos deben estar claramente articuladas y se alinean con la visin prctica de la arquitectura.
Pgina571de670

TOGOF9.1
47. Architecture Board

Contenidodelcaptulo 47.1Rol|47.2Responsabilidades|47.3ConfiguracindelaJuntadeArquitectura|47.4 FuncionamientodelConsejodeArquitectura
Este captulo proporciona directrices para el establecimiento y funcionamiento de un Consejo de Arquitectura Empresarial.
47.1 Papel
Un elemento clave para una estrategia exitosa de gobernabilidad arquitectura (ver 50. Arquitectura de Gobierno ) es una Junta de Arquitectura de toda la organizacin para supervisar la implementacin de la estrategia. Este rgano debe ser representativa de todos los actores clave en la arquitectura, y comprender normalmente un grupo de ejecutivos responsables de la revisin y el mantenimiento de la arquitectura general. Arquitectura Boards pueden tener, o alcance la lnea de negocio global, regional. Sobre todo en las grandes empresas, Arquitectura Juntas estn compuestas normalmente por representantes de la organizacin en un mnimo de dos niveles:
Local (expertos en el dominio, la responsabilidad de lnea) Mundial (la responsabilidad de toda la organizacin)
En tales casos, cada tabla se establecer con identificable y articulado:

Responsabilidades y capacidades de toma de decisiones Lmites de mandato y autoridad
47.2 Responsabilidades
La Junta de Arquitectura se hace tpicamente responsable y rendir cuentas, para lograr algunos o todos de los siguientes objetivos:
Proporcionar la base para todas las decisiones con respecto a las arquitecturas Coherencia entre los sub-arquitecturas El establecimiento de objetivos para la reutilizacin de los componentes La flexibilidad de la arquitectura de la empresa:
Pgina572de670

TOGOF9.1
o para satisfacer las cambiantes necesidades del negocio o Para aprovechar las nuevas tecnologas Ejecucin de Arquitectura de Cumplimiento Mejorar el nivel de madurez de la arquitectura la disciplina dentro de la organizacin Asegurarse de que se adopte la disciplina de desarrollo basado en la arquitectura El apoyo a una capacidad de escalada visible para las decisiones fuera de los lmites
Otras responsabilidades de una perspectiva operacional deben incluir:

Todos los aspectos de seguimiento y control del Contrato Arquitectura Reunin sobre una base regular Asegurar la gestin y la aplicacin efectiva y coherente de las arquitecturas Resolucin de ambigedades, problemas o conflictos que han sido escalados Prestar asesoramiento, orientacin e informacin Asegurar el cumplimiento de las arquitecturas, y la concesin de las dispensas que estn en consonancia con la estrategia y objetivos de la tecnologa Teniendo en cuenta la poltica (calendario, Acuerdos de Nivel de Servicio (SLAs), etc) cambia cuando se solicitan y otorgan dispensas similares; por ejemplo, la nueva forma de requisitos de servicio Garantizar que toda la informacin pertinente para la aplicacin del Contrato de Arquitectura se publica bajo condiciones controladas y transmitirse a las partes autorizadas La validacin de los niveles de servicio reportados, ahorro de costes, etc
Desde la perspectiva de la gobernabilidad, la Junta de Arquitectura tambin es responsable de:

La produccin de materiales y actividades de gobernanza utilizable Proporcionar un mecanismo para la aceptacin formal y la aprobacin de la arquitectura a travs del consenso y la publicacin autorizada Proporcionar un mecanismo de control fundamental para asegurar la aplicacin efectiva de la arquitectura Establecer y mantener el enlace entre la aplicacin de la arquitectura, la estrategia de arquitectura y los objetivos plasmados en la arquitectura de la empresa, as como los objetivos estratgicos del negocio La identificacin de divergencia con respecto a las actividades de la arquitectura y de planificacin para la reestructuracin a travs de dispensaciones o actualizaciones de la poltica
Pgina573de670

TOGOF9.1
47.3 Configuracin Up Architecture Board

47.3.1 Los disparadores
Uno o ms de los siguientes sucesos desencadena normalmente el establecimiento de un Consejo de Arquitectura:

Nuevo CIO Fusin o adquisicin Examen de un traslado a las nuevas formas de la informtica Reconocimiento de que es mal alineado al negocio El deseo de lograr una ventaja competitiva a travs de la tecnologa Creacin de un programa de arquitectura de la empresa El cambio de negocios importante o un rpido crecimiento Requisitos para las soluciones complejas, multi-funcionales
En muchas empresas, el patrocinador ejecutivo del esfuerzo inicial de la arquitectura es el CIO (u otro alto ejecutivo). Sin embargo, para obtener un amplio apoyo de las empresas, un organismo que patrocina tiene ms influencia. Este organismo patrocinador se llama aqu un Consejo de Arquitectura, pero el ttulo no es importante.Sea cual sea el nombre, es el grupo de nivel ejecutivo responsable de la revisin y mantenimiento de la arquitectura estratgica y todos sus sub-arquitecturas. La Junta de Arquitectura es el patrocinador de la arquitectura dentro de la empresa, sino que el propio Consejo de Arquitectura necesita un patrocinador ejecutivo del ms alto nivel de la corporacin. Este compromiso debe abarcar el proceso de planificacin y continuar en la fase de mantenimiento del proyecto de arquitectura. En muchas empresas que fracasan en un esfuerzo planificacin de la arquitectura, hay una notable falta de participacin ejecutiva y aliento para el proyecto. Una fuente pasa por alto con frecuencia de los miembros de la Junta de Arquitectura es la Junta Directiva de la empresa. Estas personas siempre tienen diversos conocimientos sobre la empresa y su competencia. Debido a que tienen un impacto significativo en la visin y los objetivos de negocio, pueden tener xito en la validacin de la armonizacin de las estrategias de TI con los objetivos empresariales.
47.3.2 Tamao de la Junta
El tamao recomendado para una Junta de Arquitectura es de cuatro o cinco aos (y no ms de diez) miembros permanentes.
Pgina574de670

TOGOF9.1
Con el fin de mantener el Consejo de Arquitectura de un tamao razonable, al tiempo que garantiza la representacin de toda la empresa en la que con el tiempo, miembros de la Junta de Arquitectura se puede girar, dando privilegios y responsabilidades de toma de decisiones a diversos altos directivos. Esto puede ser necesario en cualquier caso, debido a que algunos miembros de la Junta de Arquitectura de la bsqueda de que las limitaciones de tiempo a prevenir la participacin activa a largo plazo. Sin embargo, una cierta continuidad debe existir en el Consejo de Arquitectura, para evitar que la arquitectura corporativa de la variacin de un conjunto de ideas a otro. Una tcnica para asegurar la rotacin con continuidad es tener trminos establecidos para los miembros, y para tener los trminos expiran en diferentes momentos. En el proceso de arquitectura en curso tras el esfuerzo inicial de la arquitectura, la Junta de Arquitectura se puede volver a alquilar. El patrocinador ejecutivo revisar normalmente la labor de la Junta de Arquitectura y evaluar su eficacia; si es necesario, el proceso de revisin de Arquitectura de Cumplimiento est actualizado o modificado.
Estructura Junta 47.3.3
El Marco de Gobierno TOGAF Arquitectura (ver 50.2 Arquitectura Governance Framework ) proporciona un marco de organizacin genrica que posiciona a la Junta de Arquitectura en el marco de las estructuras de gobierno ms amplios de la empresa. Esta estructura identifica los principales grupos y las responsabilidades de organizacin, as como la relacin entre cada grupo. Se trata de una estructura de las mejores prcticas, y puede estar sujeto a cambio dependiendo de la forma de la organizacin y las estructuras existentes. Hay que prestar atencin al tamao de la organizacin, su forma, y cmo las funciones de TI se implementan. Esto proporcionar la base para disear la estructura Architecture Board en el contexto del entorno general de gobierno. En particular, se debe considerar que el concepto de propiedad global y la implementacin local, y la integracin de nuevos conceptos y tecnologas de todas las reas de aplicacin correspondientes arquitecturas. La estructura de la Junta de Arquitectura debe reflejar la forma de la organizacin. La estructura de gobierno de la arquitectura requerida y puede ir ms all de las estructuras genricas descritas en el Marco de Gobierno TOGAF Arquitectura (ver 50.2 Arquitectura del marco de la gobernanza ). La organizacin puede necesitar para definir una combinacin del proceso de gobernanza de la TI en su lugar y las estructuras y capacidades organizacionales existentes, que suelen incluir los siguientes tipos de cuerpo:
Junta de gobierno Global Junta de Gobierno Local Autoridades de Diseo Grupos de trabajo
Pgina575de670

TOGOF9.1
47.4 El funcionamiento del Consejo de Arquitectura

En esta seccin se describe el funcionamiento de la Junta de Arquitectura de todo desde la perspectiva de gobierno.
47.4.1 general
Reuniones de Arquitectura de la Junta deben llevarse a cabo dentro de las agendas claramente identificados con los objetivos explcitos, la cobertura de contenidos y acciones definidas. En general, las reuniones de la junta estarn alineados con las mejores prcticas, tal como se da en el marco COBIT (ver 50.1.4.1 Un Controles de TI Marco - COBIT ). Estas reuniones brindarn direccin clave:
Apoyo a la produccin de materiales y actividades de gobernanza de calidad Proporcionar un mecanismo para la aceptacin formal a travs del consenso y la publicacin autorizada Proporcionar un mecanismo de control fundamental de velar por la aplicacin efectiva de las arquitecturas Establecer y mantener el enlace entre la aplicacin de las arquitecturas y la estrategia y objetivos de la organizacin se indica (de negocios y de TI) La identificacin de la divergencia de las actividades contractuales y de planificacin para realinear con el contrato a travs de dispensaciones o actualizaciones de la poltica
47.4.2 Preparacin
Cada participante recibir una agenda y la documentacin de apoyo - por ejemplo, las solicitudes de exencin, los informes de gestin del rendimiento, etc - y se espera que est familiarizado con el contenido de cada uno. Cuando las acciones se han asignado a un individuo, es responsabilidad de la persona que informe sobre los avances en contra de estos. Cada participante debe confirmar su disponibilidad y la asistencia a la reunin de Junta de Arquitectura.
47.4.3 del orden del da
En esta seccin se describe el contenido de un programa de la reunin Architecture Board. Cada tema del programa se describe en trminos de slo su contenido.
Acta de la reunin anterior
Pgina576de670

TOGOF9.1
Minutos contienen los detalles de la anterior reunin Architecture Board segn el protocolo estndar de la organizacin.
Las solicitudes para el Cambio
Los artculos de este captulo estn normalmente cambian las solicitudes de modificacin de las arquitecturas, principios, etc, pero tambin pueden incluir el control de las empresas respecto a la arquitectura de Contratos; por ejemplo, asegurarse de que el trfico de voz a nmeros de tarificacin adicional, como informes del tiempo, se prohibi el trfico de datos a ciertos sitios web se controla. Cualquier solicitud de cambio se realiza dentro de los niveles y parmetros definidos por el Contrato Arquitectura autoridad acordados.
Dispensaciones
Una dispensacin se utiliza como el mecanismo para solicitar un cambio en las arquitecturas existentes, contratos, principios, etc fuera de los parmetros normales de operacin; por ejemplo, excluye la prestacin del servicio a una filial, solicitud de los niveles de servicio inusuales por motivos de negocio especficas, implementar la tecnologa o los productos no estndar para apoyar las iniciativas empresariales especficas. Las dispensaciones se conceden por un periodo de tiempo determinado y un conjunto de servicios identificados y los criterios operativos que deben ser ejecutadas durante la vida til de la dispensacin. Las dispensaciones no se otorgan por tiempo indefinido, pero se utilizan como un mecanismo para asegurar que los niveles de servicio y los niveles operacionales, etc se cumplen mientras que proporciona una flexibilidad de nivel en su aplicacin y el tiempo. La naturaleza de duracin determinada de dispensaciones asegura que son un disparador para la actividad de Cumplimiento Arquitectura.
Evaluaciones de cumplimiento
El cumplimiento se evala a los SLA, Acuerdos de Nivel Operacional (OLA), los objetivos de costes, y refresca arquitectura requeridas. Estas evaluaciones sern revisadas y aceptadas o rechazadas en funcin de los criterios definidos en el Marco de Gobierno de Arquitectura. El informe de evaluacin Arquitectura Cumplimiento incluir detalles como se describe.
Resolucin de Disputas
Las controversias que no han sido resueltos a travs de la arquitectura de cumplimiento y los procesos de dispensacin se identifican aqu para ms accin y se documentan a travs de las evaluaciones de cumplimiento Arquitectura y documentacin dispensacin.
Arquitectura Estrategia y Direccin de Documentacin
Pgina577de670

TOGOF9.1
Este describe las estrategias de la arquitectura, la direccin y las prioridades y slo ser formulada por el Consejo de Arquitectura global. Se debe tomar la forma de documentacin de arquitectura estndar.
Acciones de Asignacin
Se trata de un informe sobre las acciones asignadas en anteriores reuniones de la Junta de Arquitectura. Un rastreador de accin se utiliza para documentar y mantener el estado de todas las acciones asignadas durante las reuniones de la Junta de Arquitectura y debe consistir de por lo menos la siguiente informacin:
Referencia Prioridad Descripcin Accin Propietario Accin Informacin de la accin Fecha planteado Fecha de vencimiento Estado Tipo Fecha de Resolucin Gestin de la Documentacin del Contrato
Se trata de una aceptacin formal de las actualizaciones y cambios a la documentacin de la arquitectura para su publicacin en adelante.
Otros asuntos (AOB)
Descripcin de las cuestiones que no estn directamente cubiertos por alguno de los anteriores. Estos no pueden ser descritos en el orden del da, sino que deben ser planteadas al comienzo de la reunin. Toda la documentacin necesaria se debe manejar de acuerdo toda la documentacin de la gobernanza de la arquitectura.
Calendario de reuniones
Toda reunin Fechas de detalle debe ser detallada y publicada.
Pgina578de670

TOGOF9.1
4. Arquitectura Cumplimiento
Contenidodelcaptulo 48.1Introduccin|48.2Terminologa:ElsignificadodelaArquitecturaCumplimiento|48.3 ArquitecturaCumplimientoOpiniones|ProcesodeRevisindeCumplimiento48.4 Arquitectura|Arquitectura48.5RevisindeCumplimientoListasdecomprobacin|Directrices 48.6ArquitecturadeRevisindeCumplimiento
Este captulo proporciona directrices para asegurar el cumplimiento del proyecto a la arquitectura.
48.1 Introduccin
Garantizar el cumplimiento de los proyectos individuales con la arquitectura de la empresa es un aspecto esencial de la gobernabilidad arquitectura (vase 50.Arquitectura de Gobierno ). Con este fin, la funcin de gobierno de TI dentro de una empresa normalmente se definen dos procesos complementarios:
La Arquitectura funcin se requiere para preparar una serie de arquitecturas de Proyecto; es decir, puntos de vista especficos del proyecto de la arquitectura empresarial que ilustran cmo los impactos de arquitectura empresarial en los principales proyectos de la organizacin. (ver Fases ADM de A a F) El IT Governance funcin ser definir un proceso de revisin formal de Arquitectura de Cumplimiento (vase 48.3ComentariosArquitecturadecumplimiento ) para revisar el cumplimiento de los proyectos a la arquitectura de la empresa.
Adems de la definicin de procesos formales, el gobierno arquitectura (ver 50. Arquitectura de Gobierno ) funcin tambin puede estipular que la funcin de la arquitectura debe extenderse ms all de la funcin de la definicin de la arquitectura y la seleccin de las normas, y participar tambin en el proceso de seleccin de la tecnologa, e incluso en el comercial relaciones involucradas en la provisin de servicios y productos de las compras externas. Esto puede ayudar a minimizar la posibilidad de una mala interpretacin de la arquitectura de la empresa y maximizar el valor de la negociacin comercial centralizada.
48.2 Terminologa: El significado de la Arquitectura de Cumplimiento

Una relacin clave entre la arquitectura y la implementacin se encuentra en las definiciones de los trminos "conformes", "conforme", etc Si bien el uso de la terminologa puede diferir entre las organizaciones, los conceptos de niveles de conformidad se ilustran en la Figura 48-1 puede ser muy til en la formulacin de una estrategia de cumplimiento de TI.
Pgina579de670

TOGOF9.1
Figura481:NivelesdeArquitecturaConformidad
La frase "de conformidad con" en la figura 48-1 significa:

Apoya la estrategia declarada y direcciones futuras Se adhiere a los estndares establecidos (incluida la sintaxis y las reglas semnticas especificadas) Proporciona la funcionalidad declarado Se adhiere a los principios enunciados; por ejemplo: o donde sea abierto posible y adecuado o reutilizacin de bloques de construccin de los componentes siempre que sea posible y apropiado
Pgina580de670

TOGOF9.1
48.3 Comentarios Arquitectura Cumplimiento

Una revisin de Cumplimiento La arquitectura es un examen de la conformidad de un proyecto especfico en funcin de criterios establecidos de arquitectura, el espritu y los objetivos de negocio. Un proceso formal para esos exmenes normalmente se forma el ncleo de una estrategia de cumplimiento de arquitectura empresarial.
48.3.1 Propsito
Los objetivos de la revisin de Cumplimiento Arquitectura incluyen algunos o todos de los siguientes:
En primer lugar, detectar errores en la arquitectura temprana del proyecto, y por lo tanto reducir el costo y el riesgo de los cambios requeridos ms adelante en el ciclo de vida. Esto a su vez significa que el tiempo total del proyecto se acorta, y que la empresa obtiene el beneficio lnea de fondo del desarrollo de la arquitectura ms rpido. Velar por la aplicacin de las mejores prcticas para el trabajo de la arquitectura. Proporcionar una visin general del cumplimiento de una arquitectura de estndares de la empresa por mandato. Identificar dnde las propias normas pueden exigir modificaciones. Identificar los servicios que estn actualmente especfica de la aplicacin, pero podran ser incluidos como parte de la infraestructura de la empresa. Estrategias de Documentos para la colaboracin, el intercambio de recursos y otras sinergias a travs de mltiples equipos de arquitectura. Tome ventaja de los avances tecnolgicos. Comunicar a la gestin de la situacin de la disponibilidad tcnica del proyecto. Identificar criterios clave para las actividades de adquisicin (por ejemplo, para su inclusin en los documentos comerciales el producto RFI / RFP Off-The-Shelf (COTS)). Identificar y comunicar deficiencias arquitectnicas significativas de productos y proveedores de servicios.
Adems de los objetivos generales relacionados con la garanta de calidad se ha sealado, existen motivaciones adicionales, orientacin poltica ms para la realizacin de Arquitectura Las revisiones de cumplimiento, que pueden ser relevantes en casos particulares:
La revisin de cumplimiento La arquitectura puede ser una buena manera de decidir entre alternativas de arquitectura, ya que los tomadores de decisiones que suelen participar en la revisin pueden guiar las decisiones en trminos de lo que es mejor para el negocio, en lugar de lo que es tcnicamente ms agradable o elegante.
Pgina581de670

TOGOF9.1
La salida de la revisin de Cumplimiento La arquitectura es una de las pocas entregas cuantificables para el CIO para ayudar en la toma de decisiones. Arquitectura opiniones pueden servir como una manera para que la organizacin Arquitectura para colaborar con los proyectos de desarrollo que de otro modo podran avanzar sin la participacin de la funcin de la arquitectura. Arquitectura opiniones pueden demostrar un apoyo rpido y positivo a la comunidad de negocios de la empresa: o La arquitectura de la empresa y Arquitectura Cumplimiento ayuda a asegurar la alineacin de los proyectos de TI con los objetivos empresariales. o arquitectos a veces puede ser considerado como profundamente en infraestructura tcnica y alejada de la actividad principal. o Desde una revisin de cumplimiento Arquitectura tiende a mirar sobre todo a las zonas de riesgo crticos de un sistema, a menudo se destacan los principales riesgos para los propietarios de los sistemas.
Si bien se requiere el cumplimiento de la arquitectura para el desarrollo y ejecucin, el incumplimiento tambin proporciona un mecanismo para poner de relieve:
reas que deben abordarse para el reajuste Temas para estudiar para su integracin en las arquitecturas, ya que estn al descubierto por los procesos de cumplimiento
Este ltimo punto identifica el cambio continuo y la adaptabilidad de las arquitecturas de los requisitos que se puedan conducir por indisciplina, pero tambin permite que los cambios se registran por los cambios rpidos en movimiento en el entorno operacional. Tpicamente dispensas (vase 50.1.4 IT Governance ) se utilizarn para poner de relieve estos cambios y poner en marcha un proceso para registrar, monitorear y evaluar la idoneidad de los cambios necesarios.
48.3.2 El tiempo
El momento de las actividades de cumplimiento debe ser considerado en relacin con el desarrollo de las propias arquitecturas. Las revisiones de cumplimiento se llevan a cabo en los hitos o puntos de control de proyectos apropiados en el ciclo de vida del proyecto. puestos de control especficos debe incluirse la siguiente manera:
El desarrollo de la propia arquitectura (cumplimiento ADM) La implementacin de la arquitectura (s) (arquitectura cumplimiento)
Arquitectura tiempos de proyectos para las evaluaciones deben incluir:

Pgina582de670

TOGOF9.1
Inicio del proyecto Diseo inicial Los principales cambios en el diseo Ad hoc
La revisin de cumplimiento Arquitectura normalmente est dirigida a un punto en el tiempo cuando los requerimientos del negocio y la arquitectura de la empresa son razonablemente firme, y la arquitectura del proyecto est tomando forma, mucho antes de su finalizacin. El objetivo es llevar a cabo la revisin lo antes posible, en una etapa en que todava hay tiempo para corregir los errores o deficiencias importantes, con la condicin obvia que no necesita haber sido algn desarrollo importante de la arquitectura del proyecto con el fin de que exista ser algo a revisar. Las entradas a la revisin de Cumplimiento Arquitectura pueden venir de otras partes del ciclo de vida del proyecto de norma, el cual puede tener un impacto en el tiempo.
48.3.3 Gobernabilidad y Escenarios de personal
En cuanto a la gobernanza y la realizacin del examen de cumplimiento de Arquitectura, y el personal involucrado, hay varios escenarios posibles:
Para proyectos de menor escala, el proceso de revisin podra simplemente tomar la forma de una serie de preguntas que los arquitectos del proyecto o de los lderes del proyecto representan a s mismos, utilizando las listas de verificacin que aparecen a continuacin, tal vez el cotejo de las respuestas en alguna forma de informe del proyecto a la gerencia. La necesidad de llevar a cabo un proceso de este tipo se incluye normalmente en las polticas generales de gobierno de TI en toda la empresa. Cuando el proyecto que se examina no ha implicado una prctica o arquitecto a tiempo completo hasta la fecha (por ejemplo, en un proyecto de nivel de aplicacin), el propsito de la revisin es tpicamente para hacer valer la experiencia arquitectnica de una funcin de la arquitectura empresarial. En tal caso, la funcin de la arquitectura empresarial iba a organizar, dirigir y llevar a cabo la revisin, con la participacin de expertos en los sectores de negocios. En tal escenario, la revisin no es un sustituto de la participacin de los arquitectos en un proyecto, pero puede ser un complemento o una gua para su participacin. Es probable que sea necesaria una base de datos para manejar el volumen de datos que se produciran en el anlisis de un gran sistema o conjunto de sistemas. En la mayora de los casos, sobre todo en proyectos de mayor envergadura, la funcin de la arquitectura se han estado profundamente involucrado en, y tal vez conduzca, el proyecto de desarrollo que se examina. (Este es el escenario tpico TOGAF.) En tales casos, la revisin ser coordinado por el arquitecto de la empresa principal, que reunir un equipo de expertos en negocios y dominio tcnico para la revisin, y compilar las respuestas a las preguntas formuladas durante la la revisin en alguna forma de informe. Las preguntas suelen plantearse durante el examen por los expertos en negocios
Pgina583de670

TOGOF9.1
y dominio tcnico. Por otra parte, la revisin podra ser dirigido por un representante de una Junta de Arquitectura o algn organismo similar en las responsabilidades de toda la empresa.
En todos los casos, el proceso de revisin de Cumplimiento Arquitectura necesita el respaldo de la alta direccin, y normalmente se encarg como parte de las polticas de gobierno corporativo de arquitectura (ver 50. Arquitectura de Gobierno ). Normalmente, la empresa CIO o empresa Architecture Board (ver 47. Arquitectura Board ) dar un mandato opiniones arquitectura para todos los proyectos, con posteriores revisiones anuales.
48.4 Proceso de Arquitectura de Revisin de Cumplimiento

El proceso de revisin de Arquitectura cumplimiento se ilustra en la Figura 48-2 .
Figura482:ProcesoArquitecturaRevisindeCumplimiento
48.4.2 Roles
Los papeles principales en el proceso se tabulan a continuacin.
No. Papel Responsabilidades 1 Architecture Para asegurarse de que las Board arquitecturas de TI son consistentes y apoyar las necesidades generales de la
Notas Patrocinador y supervisar las actividades de arquitectura.
Pgina584de670

TOGOF9.1
2 Lder del Proyecto (o Junta del Proyecto) 3 Architecture Review Coordinador 4
empresa. Responsable de todo el proyecto.
5 6
Para administrar todo el proceso Ms probabilidades de de desarrollo de la arquitectura y ser orientado a los la revisin. negocios de orientacin tecnolgica. Enterprise Para asegurarse de que la Un especialista en Architect arquitectura es tcnicamente arquitectura de TI. Lead coherente y a prueba de futuro. Arquitecto Uno de los asistentes tcnicos de la Enterprise Architect plomo. Cliente Para asegurar que los Gestiona la parte de la requerimientos del negocio estn organizacin que va a claramente expresados y depender del xito de la comprendidos. TI se describe en la arquitectura. Negocios Para asegurar que los procesos Sabe cmo funciona el dominio para satisfacer los requerimientos dominio del Expert del negocio se justifican y negocio; Tambin puede ser el cliente. comprendido. Los Para garantizar que los arquitectos Los miembros de la directores de tienen una comprensin organizacin del cliente proyecto suficientemente detallada de los que tienen entrada a los procesos del departamento de requerimientos del atencin al cliente. Pueden negocio que la proporcionar entrada al dominio arquitectura es abordar. de expertos de negocios o para los arquitectos.
48.4.3 Pasos
Los principales pasos en el proceso se tabulan a continuacin.
No. Accin 1 Solicitud arquitectura revisin
Notas Conforme a lo dispuesto por las polticas y procedimientos de gobierno de TI.
Quin Cualquier persona, sea o orientada a los negocios, con un inters o responsabilidad en el rea de los negocios
Pgina585de670

TOGOF9.1
2 Identificar parte responsable de la organizacin y los directores de los proyectos correspondientes. 3 Identificar Enterprise Architect plomo y otros arquitectos. 4 Determinar el alcance de Identificar qu otras la revisin unidades de negocio / departamentos estn involucrados. Comprender que el sistema se ajuste en el marco de la arquitectura corporativa. 5 Listas de verificacin a Para hacer frente a los medida. requerimientos del negocio. 6 Horario Arquitectura reunin de revisin
afectados. Architecture Review Coordinador
Architecture Review Coordinador Architecture Review Coordinador
Enterprise Architect Lead Architecture Review Coordinador con la colaboracin de Enterprise Architect plomo. Lead Enterprise Architect y / o Arquitecto, lder del proyecto, y los Clientes
7 Directores de proyectos Para obtener Entrevista informacin bsica y tcnica:

Para proyecto interno: en persona Para COTS: en persona o por medio de RFP
Utilice las listas de comprobacin. 8 Analizar las listas de Repase con los verificacin terminados estndares corporativos. Identificar y resolver
Enterprise Architect Lead
Pgina586de670

TOGOF9.1
9 Preparar Arquitectura informe de revisin de cumplimiento 10 Hallazgos de la revisin Para Clientes Presente Para Architecture Board 11 Acepte revisin y firmar 12 Enviar el informe de evaluacin / Resumen de Architecture Review Coordinador
problemas. Determinar recomendaciones. Puede incluir personal Enterprise Architect de apoyo. Lead Enterprise Architect Lead Architecture Board y el Cliente Enterprise Architect Lead
48.5 Arquitectura de Revisin de Cumplimiento listas de verificacin

Las siguientes listas de control de revisin proporcionan una amplia gama de preguntas tpicas que se pueden utilizar en la realizacin de Arquitectura Las revisiones de cumplimiento, en relacin con diversos aspectos de la arquitectura. La organizacin de las preguntas que incluye las disciplinas bsicas de la ingeniera de sistemas, gestin de la informacin, seguridad y administracin de sistemas. Las listas de control se basan en material proporcionado por un miembro de The Open Group, y son especficos para esa organizacin. Otras organizaciones pueden utilizar las siguientes listas de verificacin con otras preguntas a la medida de sus necesidades particulares. Las listas de comprobacin proporcionadas contienen demasiadas preguntas para cualquier crtica individual: Tienen el objetivo de adaptarse de forma selectiva con el proyecto de que se trate (vase 48.6 Arquitectura para la Revisin de Cumplimiento ). Las listas de verificacin efectivamente utilizadas tpicamente se desarrollan / seleccionados por expertos en la materia. Estn destinados a ser actualizado anualmente por los grupos de inters en esas reas. Algunas de las listas de verificacin incluyen una breve descripcin del principio arquitectnico que provoca la pregunta, as como una breve descripcin de lo que debe buscar en la respuesta. Estas extensiones de la lista de control tienen por objeto permitir que los inteligentes re-fraseo de las preguntas, y para dar al usuario de la lista de verificacin una idea de por qu se hizo la pregunta. De vez en cuando las preguntas se pueden escribir, como en RFP, o en el trabajo con un arquitecto superior del proyecto. Ms tpicamente se expresan oralmente, como parte de una entrevista o sesin de trabajo con el proyecto.
Pgina587de670

TOGOF9.1
Las listas de control que aqu se han diseado para su uso en proyectos de arquitectura individuales, no para el dominio de la arquitectura de negocios o de la arquitectura a travs de mltiples proyectos. (Haciendo una revisin de la arquitectura para una esfera ms amplia de la actividad, a travs de procesos de negocio y proyectos de sistemas mltiples, que implicara un proceso similar, pero las categoras lista de verificacin y sus contenidos seran diferentes.)
48.5.1 Sistema Operativo Hardware y lista de control 1. Cul es el enfoque del ciclo de vida del proyecto? 2. En qu fase est el proyecto en su ciclo de vida? 3. Qu cuestiones clave han sido identificados ni analizados que el proyecto cree que va a
conducir evaluaciones de hardware y sistemas operativos para redes, servidores y dispositivos de usuario final?
4. Qu capacidades del sistema implicar gran volumen y / o transferencias de datos de alta frecuencia? 5. De qu manera el impacto del diseo del sistema o implican dispositivos de usuario final? 6. Cul es la cantidad y la distribucin (regional y mundial) de uso, almacenamiento de datos y el procesamiento? 7. Qu aplicaciones tienen afinidad con su proyecto por las similitudes en los datos,
servicios de aplicaciones, etc? Hasta qu punto est de datos affinitized con su proyecto?
8. Qu opciones de hardware y sistemas operativos se han realizado antes del diseo funcional de los elementos clave del sistema? 9. Si se toman las decisiones de hardware y sistema operativo fuera del control del proyecto:
o o Lo que la conciencia tiene el proyecto de la justificacin de esas decisiones? Cmo puede influir en el proyecto aquellas decisiones que el diseo del sistema se concreta?
10. Si se han elegido algunos no estndares:

o Cules son los requisitos de negocio y tcnicas esenciales para no utilizar las normas corporativas? Es compatible con un modelo de negocio? Haga que los supuestos en el caso de negocios sido objeto de escrutinio?
o o
11. Cul es su proceso de evaluacin de los costes del ciclo de vida completo de hardware y sistemas operativos? 12. Cmo ha sido la gestin financiera de las empresas ha dedicado a la evaluacin de los costes del ciclo de vida? 13. Ha realizado un anlisis financiero de la empresa? Pgina588de670

TOGOF9.1 14. Ha hecho compromisos con ningn proveedor? 15. Cree usted que sus necesidades pueden ser satisfechas por un solo proveedor? 48.5.2 Servicios de Software y Middleware Checklist 1. Describir cmo se definen las condiciones de error, criados, y se propagan entre los componentes de la aplicacin. 2. Describe el patrn general de cmo se definen y se disponen en varios mdulos de aplicacin mtodos. 3. Describe el patrn general de cmo se definen y organizan en varios mdulos de
aplicacin los parmetros del mtodo. Son [en], [in / out], [out] parmetros especificados siempre en el mismo orden? Los valores booleanos devueltos por mdulos tienen un resultado consistente?
4. Describa el enfoque que se utiliza para minimizar el nmero de viajes de ida y vuelta entre
cliente y servidor de llamadas, sobre todo para las llamadas fuera de proceso, y cuando las estructuras de datos complejas estn involucrados.
5. Describir las principales estructuras de datos que se pasan entre los principales componentes del sistema. 6. Describir los principales protocolos de comunicacin que se utilizan entre los principales componentes del sistema. 7. Describir las tcnicas de clculo de referencias que se utilizan entre diversos componentes
del sistema. Describa cualquier arreglo de clculo de referencias especializadas que se utilizan.
8. Describir en qu medida el sistema est diseado con componentes con estado y sin estado. 9. Describa cmo y cundo se guarda el estado de ambos componentes con estado y sin estado. 10. Describir el grado en que se crean los objetos, utilizado, y destruido frente reutilizados a travs de la agrupacin de objetos. 11. Describir la medida en que el sistema se basa en el roscado o de la seccin de codificacin crtico. 12. Describa el enfoque y la documentacin interna que se utiliza internamente en el sistema
para documentar los mtodos, los mtodos de argumentos, y la funcionalidad del mtodo.
13. Describir el proceso de revisin de cdigo que se utiliz para construir el sistema. 14. Describa la prueba de la unidad que se ha utilizado para probar los componentes del sistema. 15. Describir la pre-y post-condicin de prueba que se incluye en varios mdulos del sistema. 16. Describa la prueba de la afirmacin que se incluye con el sistema. Pgina589de670

TOGOF9.1 17. Los componentes son compatibles con todos los tipos de interfaces que necesitan para
apoyar o son ciertas suposiciones hechas sobre qu tipos de componentes llamar a otros componentes, ya sea en trminos de enlaces de lenguaje u otras formas de clculo de referencias?
18. Describir la medida en que necesitan grandes problemas-endian o little-endian formato de datos que se manejan a travs de diferentes plataformas. 19. Describa si los nmeros o cadenas deben ser manejados de manera diferente a travs de diferentes plataformas. 20. Describa si el software tiene que comprobar de punto flotante de errores de redondeo. 21. Describir cmo las funciones de fecha y hora a gestionar fechas a fin de evitar un manejo inadecuado del tiempo y el clculo de la fecha o la pantalla. 22. Describir qu herramientas o procesos se han utilizado para probar el sistema en busca de fugas de memoria, la accesibilidad o la robustez general. 23. Describir las capas del software de servicios de sistemas. Describir el nmero general de
los vnculos entre los principales componentes del sistema. El sistema est compuesto por una gran cantidad de interfaces de punto a punto o son los mayores backbones de mensajera utilizado en su lugar?
24. Describir en qu medida los componentes del sistema estn bien imprecisa o fuertemente acoplados. 25. Qu requisitos necesita el sistema a partir de la infraestructura en materia de bibliotecas
compartidas, soporte para protocolos de comunicacin, equilibrio de carga, procesamiento de transacciones, la supervisin del sistema, los servicios de nombres u otros servicios de infraestructura?
26. Describir cmo los componentes del sistema y del sistema estn diseados para refactorizacin. 27. Describir cmo los componentes del sistema o del sistema dependen de la infraestructura de mensajera comn frente a una estructura nica de comunicacin punto a punto. 48.5.3 Aplicaciones Listas de verificacin
48.5.3.1 Infraestructura (Empresa Productividad) Aplicaciones
1. Existe la necesidad de capacidades que no se ofrecen a travs de productos de aplicacin infraestructura estndar de la empresa? Por ejemplo:
o Colaboracin Uso compartido de aplicaciones La videoconferencia Calendarios Email
Pgina590de670

TOGOF9.1
o o Gestin de flujo de trabajo Tramitacin de las solicitudes de publicacin / palabra o o HTML SGML y XML Formato de documento porttil Elaboracin de documentos (formato propietario) Edicin
Aplicaciones de hoja de clculo Aplicaciones de presentacin Presentaciones de negocios Imagen Animacin Vdeo Sonido CBT Navegadores web
Aplicaciones de gestin de datos Interfaz de base de datos La gestin de documentos La gestin de datos del producto Los almacenes de datos / mart
Aplicaciones de gestin de Programa Gestin de proyectos Visibilidad Programa
2. Describir los requisitos de negocio para capacidades de aplicaciones de infraestructura de la empresa, que no son satisfechas por los productos estndar.
48.5.3.2 Aplicaciones empresariales
1. Son algunas de las capacidades requeridas proporcionado por los productos estndar que apoyan una o ms aplicaciones de lnea de negocio? Por ejemplo: Pgina591de670

TOGOF9.1
o Aplicaciones de adquisicin de negocios o Ventas y marketing
Aplicaciones de ingeniera Diseo asistido por ordenador Ingeniera asistida por ordenador El anlisis matemtico y estadstica
Aplicaciones de gestin de proveedores Gestin de la cadena de suministro Customer Relationship Management
Aplicaciones de fabricacin Planificacin de Recursos Empresariales (ERP) Manufacturing Execution Systems La calidad de fabricacin Ingeniera de procesos de fabricacin Mquina y el control adaptativo
Aplicaciones de soporte al cliente Apoyo logstico de avin Ingeniera de mantenimiento
o o o o
Aplicaciones Finanzas Gente aplicaciones Instalaciones aplicaciones Aplicaciones de sistemas de informacin Ingeniera de sistemas Ingeniera de software Herramientas de desarrollo Web Entornos de desarrollo integrados Categoras de ciclo de vida Categoras funcionales Categoras de productos especializados
Pgina592de670

TOGOF9.1
o o o Fabricacin asistido por ordenador habilitacin de e-Business Ingeniera de procesos de negocios El control de calidad estadstico
2. Describir los requisitos del proceso de capacidades de aplicaciones de negocio que no son satisfechas por los productos estndar.
Integracin 48.5.3.3 Aplicacin Enfoque
1. Qu puntos de integracin (de procesos de negocio / actividad, aplicaciones, datos, entorno de computacin) son el objetivo de esta arquitectura? 2. Qu tcnicas de integracin de aplicaciones se aplicar (objetos de negocio comunes
[ORB], las definiciones de datos estndar [STEP, XML, etc], presentacin de la interfaz de usuario comn / desktop)?
Informacin 48.5.4 Gestin de listas de verificacin

48.5.4.1 Valores de datos
1. Cules son los procesos que estandarizan la gestin y uso de los datos? 2. Qu procesos de negocio apoya la entrada y la validacin de los datos? Uso de los datos ? 3. Qu acciones de negocio corresponden a la creacin y modificacin de los datos? 4. Qu acciones de negocio corresponden a la supresin de los datos y se lo considera parte de un registro de negocios? 5. Cules son los requisitos de calidad de los datos requeridos por el usuario de negocios? 6. Qu procesos existen para apoyar la integridad referencial de los datos y / o normalizacin?
48.5.4.2 Definicin de Datos
1. Cules son el modelo de datos, definiciones de datos, la estructura, y las opciones de alojamiento de aplicaciones compradas (COTS)? 2. Cules son las normas para la definicin y el mantenimiento de los requisitos de datos y diseos para todos los componentes del sistema de informacin? 3. Lo repositorio compartible se utiliza para capturar el contenido del modelo y la informacin de apoyo para los datos? 4. Cul es la definicin del modelo de datos fsicos (derivados de modelos de datos lgicos) que se utiliza para disear la base de datos? Pgina593de670

TOGOF9.1 5. Qu herramientas de desarrollo y software de gestin de datos han sido seleccionados? 6. Lo que los propietarios de los datos se han identificado como responsable de las
definiciones comunes de datos, eliminando la redundancia no planificada, con informacin constantemente confiable, oportuna y precisa, y la proteccin de datos por el mal uso y la destruccin? 48.5.4.3 Seguridad / Proteccin
1. Cules son la entidad de datos y atributos reglas de acceso que protegen los datos de alteraciones no intencionales y no autorizados, divulgacin y distribucin? 2. Cules son los mecanismos de proteccin de datos para proteger los datos contra el acceso externo no autorizado? 3. Cules son los mecanismos de proteccin de datos para controlar el acceso a los datos de fuentes externas que tienen residencia temporal interna dentro de la empresa?
48.5.4.4 Hosting, Tipos de datos, y recursos compartidos
1. Qu es la disciplina de la gestin de datos nica de autoridad-como una fuente lgica con

reglas definidas para la actualizacin de datos fsicas que residen en diferentes plataformas?
2. Qu es la disciplina de la gestin de datos replicados, que se deriva de los datos de autoridad nica-operacionales? 3. Qu servidor de nivel de datos se ha identificado para el almacenamiento de los datos operativos de alto o crtico medianas? 4. Qu servidor de nivel de datos se ha identificado para el almacenamiento de tipo C datos operativos? 5. Qu servidor de nivel de datos se ha identificado para el almacenamiento de datos de apoyo a las decisiones contenidas en un almacn de datos? 6. Qu Database Management Systems (DBMS) han puesto en marcha?
48.5.4.5 Servicios Comunes
1. Cules son los servicios normalizados distribuidos de gestin de datos (por ejemplo,
validacin, controles de coherencia, las modificaciones de datos, cifrado y gestin de transacciones) y de dnde residen? 48.5.4.6 Mtodo de acceso
1. Cules son los requisitos de acceso a los datos de archivo estndar, el mensaje y la gestin de datos? 2. Cules son los requisitos de acceso para los datos de apoyo a las decisiones? Pgina594de670

TOGOF9.1 3. Cules son el almacenamiento de datos y las ubicaciones de lgica de aplicacin? 4. Qu lenguaje de consulta se est utilizando? 48.5.5 Lista de Verificacin de Seguridad 1. Conciencia de Seguridad : Se ha asegurado que las polticas y directrices a las que
usted est diseando seguridad corporativa son las ltimas versiones? Ha ledo usted de ellos? Es usted consciente de todos los procesos de cumplimiento de seguridad informtica y la aceptacin del riesgo pertinentes? (Entrevistador debe enumerar todas las polticas y directrices pertinentes.)
2. Identificacin / Autenticacin : Diagrama de flujo del proceso de cmo se identifica a un

usuario para la aplicacin y cmo la aplicacin autentica que el usuario es quien dice ser. Proporcionar documentacin de apoyo para el diagrama que explica el flujo de la interfaz de usuario para el servidor (s) aplicacin / base de datos y de vuelta al usuario. Est conforme con las polticas corporativas sobre cuentas, contraseas, etc?
3. Autorizacin : Proporcionar un flujo de procesos de principio a fin que muestra cmo un

usuario solicita el acceso a la aplicacin, indicando que los controles de seguridad asociados y separacin de funciones. Esto debe incluir la forma en que la solicitud sea aprobada por el titular de los datos apropiados, cmo se coloca el usuario en el perfil de la clasificacin de nivel de acceso adecuado, cmo se crea el ID de usuario, la contrasea y el acceso y proporcionar al usuario. Tambin incluye la forma en que se informa al usuario de sus responsabilidades asociadas con el uso de la aplicacin, dada una copia del contrato de acceso, cmo cambiar la contrasea, a quin llamar para pedir ayuda, etc
4. Controles de acceso : Documento de cmo se agregan los IDs de usuario, contraseas y

acceso perfiles, cambiar, quitar, y documentados. La documentacin debe incluir quin es responsable de estos procesos.
5. Sensitive Information Protection : Proporcionar documentacin que identifica los datos

sensibles que requieren proteccin adicional. Identificar los propietarios de los datos responsables de estos datos y el proceso que se utiliza para proteger el almacenamiento, transmisin, impresin y distribucin de estos datos. Incluya cmo se protege el campo / archivo de contraseas. Cmo se pueden prevenir los usuarios vean la informacin confidencial de otra persona? Existen acuerdos con terceros (socios, proveedores, contratistas, etc) sobre la salvaguardia de la informacin? Si es as, cules son las obligaciones?
6. Pistas de auditora y registros de auditora : Identificar y cuentas de grupo de

documentos requeridos por los usuarios o el soporte de aplicaciones, incluyendo las cuentas de grupos de sistema operativo. Identificar y documentar las cuentas individuales y / o roles que tienen privilegios de superusuario tipo, lo que estos privilegios son, quin tiene acceso a estas cuentas, cmo se controla el acceso a estas cuentas, el seguimiento, y se registra y cmo se maneja el cambio de contrasea y distribucin, incluyendo cuentas del sistema operativo. Tambin identificar los registros de auditora, que pueden leer los registros de auditora, que se modifican los registros de auditora, que pueden eliminar los registros de auditora, y cmo los registros de auditora queda protegido y almacenado. Es el ID de usuario oscurecido en las pistas de auditora?
7. Consideraciones de acceso externo : La aplicacin puede utilizar slo internamente? Si no es as, est conforme con los requisitos de acceso externos de las empresas? Pgina595de670

TOGOF9.1 Lista de control de gestin del sistema 48.5.6 1. Cul es la frecuencia de los cambios de software que debe ser distribuido? 2. Qu herramientas se utilizan para la distribucin de software? 3. Son varias las versiones de software y / o datos permitidos en la produccin? 4. Cul es la frecuencia de copia de seguridad de los datos de usuario y se espera el tiempo de restauracin? 5. Cmo estn las cuentas de usuario creadas y administradas? 6. Cul es la estrategia de gestin de licencias de sistema? 7. Se requieren herramientas de administracin del sistema general Qu? 8. Se requieren herramientas de administracin de aplicaciones especficas Qu? 9. Se requieren herramientas de administracin del servicio Lo especficos? 10. Cmo estn de servicio las llamadas recibidas y enviadas? 11. Describa cmo se desinstala el sistema. 12. Describa el proceso o las herramientas disponibles para comprobar que el sistema est correctamente instalado. 13. Describir las herramientas o instrumentos que estn disponibles que monitorean la salud y el rendimiento del sistema. 14. Describir las herramientas o proceso en lugar de que se pueden usar para determinar dnde se ha instalado el sistema. 15. Describa qu tipo de registros de auditora se encuentran en el lugar para capturar la historia del sistema, sobre todo despus de un accidente. 16. Describir las capacidades del sistema para enviar sus propios mensajes de error para el personal de servicio. Sistema 48.5.7 Ingeniera / Arquitectura general listas de verificacin
48.5.7.1 general
1. Qu otras aplicaciones y / o sistemas requieren la integracin con el tuyo? 2. Describir el nivel de integracin y estrategia con cada uno. 3. Cmo geogrficamente distribuida es la base de usuarios? 4. Cul es la importancia estratgica de este sistema a otras comunidades de usuarios dentro y fuera de la empresa?
Pgina596de670

TOGOF9.1 5. Qu recursos de computacin son necesarios para ofrecer un servicio de sistema para
los usuarios dentro de la empresa? Fuera de la empresa y el uso de los activos informticos de la empresa? Fuera de la empresa y el uso de sus propios activos?
6. Cmo pueden los usuarios fuera del entorno de entrega nativa acceder a sus aplicaciones y datos? 7. Cul es la esperanza de vida de esta solicitud? 8. Describir el diseo que se adapta a los cambios en la base de usuarios, datos almacenados y la tecnologa del sistema de entrega. 9. Cul es el tamao de la base de usuarios y su nivel de rendimiento esperado? 10. Qu rendimiento y tcnicas de las pruebas de tensin se utilizan? 11. Cul es la organizacin general de los componentes de software y de datos? 12. Qu es el servicio y la configuracin del sistema en general? 13. Cmo son el software y los datos configurados y asignan a la configuracin del servicio y el sistema? 14. Qu se necesita tecnologa propietaria (hardware y software) para este sistema? 15. Describa cmo todos y cada versin del software puede ser reproducido y re-desplegarse en el tiempo. 16. Describir la actual base de usuarios y cmo se espera que la base de cambiar en los prximos tres a cinco aos. 17. Describir la distribucin geogrfica actual de la base de usuarios y cmo se espera que la base de cambiar en los prximos tres a cinco aos. 18. Describir la forma en que muchos usuarios actuales o futuros deben utilizar la aplicacin con carcter mvil o que necesitan para trabajar fuera de lnea. 19. Describir lo que la aplicacin general lo hace, los componentes principales de la aplicacin, as como los principales flujos de datos. 20. Describir la instrumentacin incluido en la aplicacin que permite la salud y el rendimiento de la aplicacin a monitorizar. 21. Describir la justificacin de negocio para el sistema. 22. Describir las razones para escoger el lenguaje de desarrollo del sistema frente a otras
opciones en trminos de costo inicial de desarrollo en comparacin con los costes de mantenimiento a largo plazo.
23. Describir el proceso de anlisis de sistemas que se utiliz para llegar a la fase de la arquitectura del sistema y la seleccin de productos de la arquitectura del sistema. 24. Quin adems del cliente original puede tener un uso para o beneficiarse del uso de este sistema? Pgina597de670

TOGOF9.1 25. Qu porcentaje de los usuarios utilizan el sistema en modo de exploracin frente a modo de actualizacin? 26. Cul es la duracin tpica de las solicitudes que son transaccional? 27. Es necesario la entrega de datos garantizada o actualizacin, o El sistema tolera el fracaso? 28. Cules son los requisitos de tiempo de hasta del sistema? 29. Describa en donde la arquitectura del sistema se adhiere o no se adhiere a los estndares. 30. Describir el enfoque de la planificacin y el anlisis de proyectos utilizado en el proyecto.
48.5.7.2 Procesadores / Servidor / Clientes
1. Describir la arquitectura de aplicaciones cliente / servidor. 2. Anotar lo pictrico para ilustrar donde se ejecuta la funcionalidad de la aplicacin.
48.5.7.3 Client
1. Son funciones distintas de presentacin realizadas en el dispositivo de usuario? 2. Describir la instalacin de datos y ayuda proceso que se prestan. 3. Describa la tcnica de navegacin con pantalla a pantalla. 4. Describa cmo el usuario navega entre esta y otras aplicaciones. 5. Cmo es esto y otras aplicaciones en marcha del dispositivo de usuario? 6. Existen datos entre aplicaciones y capacidades de uso compartido proceso? Si es as, describir lo que est siendo compartido y por qu tcnica / tecnologa. 7. Describir los volmenes de datos que se transfieren al cliente. 8. Cules son los requisitos adicionales para el almacenamiento de datos local para apoyar la aplicacin? 9. Cules son los requisitos adicionales de software de almacenamiento / memoria local para apoyar la aplicacin? 10. Existen conflictos de hardware / software conocidos o limitaciones de capacidad
provocadas por otros requisitos de aplicacin o situaciones que puedan afectar a los usuarios de aplicaciones?
11. Describir cmo el look-and-feel de la capa de presentacin se compara con el look-and-feel de las otras aplicaciones existentes. 12. Describir en qu medida el cliente necesita para apoyar la comunicacin asincrnica y / o sincrnica. Pgina598de670

TOGOF9.1 13. Describir cmo se separa la capa de presentacin del sistema de otras capas de clculo o de transferencia de datos del sistema.
48.5.7.4 Application Server
1. Can / hacer la capa de presentacin y niveles de aplicacin se ejecutan en procesadores separados? 2. Can / hacer la capa de aplicacin y la capa de acceso a datos se ejecutan en procesadores separados? 3. Puede esta aplicacin puede colocar en un servidor independiente de aplicacin de todas las dems aplicaciones? En caso negativo, explique las dependencias. 4. Se pueden agregar fcilmente servidores de aplicaciones paralelas adicionales? Si es as, cul es el mecanismo de equilibrio de carga? 5. Se ha medido la demanda de recursos generados por la aplicacin y lo que es el
valor? Si es as, la capacidad del servidor planeado sido confirmada en los niveles de aplicacin y agregados? 48.5.7.5 Data Server
1. Hay otras aplicaciones que deben compartir el servidor de datos? Si es as, identificarlos y describir los datos y los requisitos de acceso a datos. 2. Se ha medido la demanda de recursos generados por la aplicacin y lo que es el
valor? Si es as, la capacidad del servidor planeado sido confirmada en los niveles de aplicacin y agregados? 48.5.7.6 COTS (en su caso)
1. Es el proveedor sustancial y estable? 2. La empresa recibir el cdigo fuente sobre la desaparicin del proveedor? 3. Este software configurado para el uso de la empresa? 4. Hay datos o procesos que impidan el uso de este software peculiares de A & D?
o Es este software disponible en la actualidad?
5. Se ha utilizado / demostrado para los requisitos de volumen / disponibilidad / nivel de los servicios similares a los de la empresa?
o Describir la historia pasada financiera y la cuota de mercado del proveedor.
Ingeniera del sistema 48.5.8 / Mtodos y Herramientas Lista de verificacin 1. Existen indicadores para la actual forma de hacer negocios? 2. El dueo del sistema ha creado criterios de evaluacin que se utilizarn para orientar el proyecto? Describa cmo se utilizarn los criterios de evaluacin. Pgina599de670

TOGOF9.1 3. Se ha hecho una investigacin de las arquitecturas existentes para aprovechar el trabajo
ya existente? Describir el mtodo utilizado para descubrir y entender. Se integrarn las arquitecturas? Si es as, explique el mtodo que se utilizar.
4. Describir los mtodos que se utilizarn en el proyecto:

o o o o o o o o o o o o Para la definicin de las estrategias de negocio Para definir las reas en necesidad de mejorar Para definir la lnea de base y de destino los procesos de negocio Para la definicin de los procesos de transicin Para la gestin del proyecto Para la comunicacin del equipo Para la gestin del conocimiento, gestin de cambios y gestin de la configuracin Para el desarrollo de software Para hacer referencia a las normas y declaraciones de la direccin Para asegurar la calidad de los entregables Para las revisiones de diseo y de la aceptacin entregable Para capturar las mtricas
5. Los mtodos documentados y distribuidos a cada miembro del equipo? 6. En qu medida son los miembros del equipo estn familiarizados con estos mtodos? 7. Qu procesos existen para garantizar el cumplimiento de los mtodos? 8. Describir la infraestructura que est en su lugar para apoyar el uso de los mtodos a travs de la finalizacin del proyecto y libera previstos.
o o o o Cmo se ofrece la consulta y resolucin de problemas? Cmo se coordin la capacitacin? Cmo son los cambios y las mejoras incorporadas y en cascada? Cmo son las lecciones aprendidas capturados y comunicados?
9. Qu herramientas se estn utilizando en el proyecto? (Especificar versiones y

plataformas). En qu medida son los miembros del equipo estn familiarizados con estas herramientas?
10. Describir la infraestructura que est en su lugar para apoyar el uso de las herramientas a travs de la finalizacin del proyecto y libera anticipadas?
o Cmo se ofrece la consulta y resolucin de problemas?
Pgina600de670

TOGOF9.1
o o o Cmo se coordin la capacitacin? Cmo son los cambios y las mejoras incorporadas y en cascada? Cmo son las lecciones aprendidas capturados y comunicados?
11. Describa cmo el proyecto promover la reutilizacin de sus entregables y contenido entregable. 12. Los diseos de la arquitectura "en vivo" despus de que el proyecto se ha
implementado? Describa el mtodo que se utilizar para incorporar los cambios de nuevo en los diseos de la arquitectura.
13. Se definieron los procesos actuales? 14. Se temas documentados, valorados, y se asocian a los procesos actuales? Si no, cmo sabes que est reparando algo que est roto? 15. Estaban / actividades de mejora de procesos existentes o previstas identificados y
asociados a los procesos actuales? Si no, cmo se sabe que esta actividad no est en conflicto con o redundante a otras Declaraciones de trabajo?
16. Tiene mtricas actuales? Tiene previsto la mtrica? Si no, cmo sabes que est mejorando algo? 17. Qu procesos va a poner en marcha para recoger, evaluar, y las mtricas de informes? 18. Qu impactos tendr el nuevo diseo de tener en los procesos existentes de negocios,
las organizaciones y los sistemas de informacin? Se han documentado y compartido con los propietarios?
48.6 Arquitectura de Cumplimiento para la Revisin

48.6.1 Adaptacin de las listas de verificacin Centrarse en:
o zonas de alto riesgo o esperados (y emergente) diferenciadores Para cada pregunta en la lista de verificacin, de entender: o La pregunta en s misma o El principio detrs de l o Lo que debe buscar en las respuestas Pregunte expertos en el tema para sus puntos de vista Fijar las preguntas la lista de verificacin para su uso Tenga en cuenta la necesidad de informacin a la Junta de Arquitectura
Pgina601de670

TOGOF9.1 48.6.2 Realizacin de Arquitectura revisiones de cumplimiento
Comprender claramente los objetivos de quienes solicitan la revisin; y mantenerse en el camino y entregar lo que se le pide. Por ejemplo, por lo general quieren saber lo que est bien o mal con el sistema que se est con arquitectura; no lo que est bien o mal en la metodologa de desarrollo utilizada, su propia estructura de gestin, etc Es fcil de conseguir fuera de la pista y discutir temas que son interesantes y tal vez valga la pena, pero no lo que se solicit. Si usted puede arrojar luz y conocimiento sobre los enfoques tcnicos, pero la discusin no es necesaria para la revisin, como voluntario para proporcionar despus de la revisin. Si se hace evidente durante el debate que hay otras cuestiones que deben abordarse, que estn fuera del alcance de la revisin solicitada, tocar el tema con el presidente de la reunin despus. Un plan para resolver los problemas puede ser desarrollado de acuerdo con su grado de gravedad. Stay "cientfica". En lugar de: "Nos gusta ver grandes bases de datos hospedadas en ABC en lugar de XYZ . ", dicen cosas como: "El tiempo de inactividad asociado con XYZ entornos de bases de datos es mucho mayor que en el ABC . entornos de bases de datos tanto no recomendamos hospedaje tipo M y Nsistemas de un XYZ medio ambiente. " Haga preguntas "abiertas"; es decir, preguntas que no suponen una respuesta en particular. A menudo hay "agendas ocultas" o cuestiones controvertidas entre quienes solicitan una revisin, que probablemente no sabr por adelantado. Un enfoque despersonaliza a los debates puede ayudar a cerrar las brechas de opinin en lugar de agravarlos. Trate a los que estn siendo entrevistados con respeto. Puede que no hayan incorporado el sistema "como debe ser", pero probablemente lo hizo lo mejor que pudo, dadas las circunstancias que se colocan pulg Ayuda el ejercicio se convierta en una experiencia de aprendizaje para usted y los presentadores. Las revisiones deben incluir actividades de evaluacin detalladas contra las arquitecturas y deben asegurarse de que los resultados se almacenan en la empresa Continuum.
Pgina602de670

TOGOF9.1
49. Contratos de Arquitectura

Este captulo proporciona directrices para la definicin y el uso de Arquitectura Contratos.
49.1 Papel
Arquitectura contratos son los acuerdos conjuntos entre los socios de desarrollo y los patrocinadores de los entregables, la calidad y la aptitud para el propsito deuna arquitectura . La implementacin exitosa de estos acuerdos ser entregado a travs de la gobernanza arquitectura eficaz (vase 50. Arquitectura de Gobierno ).Mediante la implementacin de un enfoque regido a la gestin de los contratos, lo siguiente ser garantizada:
Un sistema de monitoreo continuo para comprobar la integridad, los cambios, la toma de decisiones, y la auditora de todas las actividades relacionadas con la Arquitectura dentro de la organizacin La adhesin a los principios, las normas y los requisitos de las arquitecturas existentes o en desarrollo Identificacin de los riesgos en todos los aspectos del desarrollo y la implementacin de la arquitectura (s) que cubre el desarrollo interno contra las normas aceptadas, polticas, tecnologas y productos, as como los aspectos operativos de las arquitecturas de tal manera que la organizacin pueda continuar sus actividades dentro de un entorno resistente Un conjunto de procesos y prcticas que garanticen la rendicin de cuentas, la responsabilidad y la disciplina en relacin con el desarrollo y el uso de todos los artefactos arquitectnicos Una comprensin formal de la organizacin de gobierno responsable del contrato, su nivel de autoridad, y el mbito de la arquitectura bajo el gobierno de este rgano
El Contrato Arquitectura tradicional es un acuerdo entre el patrocinador y la funcin de la arquitectura o IS departamento. Sin embargo, cada vez ms servicios estn siendo proporcionados por los integradores de sistemas, proveedores de aplicaciones y los proveedores de servicios, coordinados a travs de la funcin de la arquitectura o IS departamento. Por tanto, existe una necesidad de un Contrato de Arquitectura de establecer acuerdos conjuntos entre todas las partes involucradas en el desarrollo de la arquitectura y el parto. Arquitectura contratos pueden ocurrir en diferentes etapas del Mtodo de Desarrollo de Arquitectura (ADM); por ejemplo:
Pgina603de670

TOGOF9.1
La Declaracin de Arquitectura de Trabajo creado en la Fase A de laparteII:Arquitectura MtododeDesarrollo(ADM) es efectivamente un contrato de Arquitectura entre la organizacin de la arquitectura y el patrocinador de la arquitectura de la empresa (o la funcin de gobierno de TI). El desarrollo de uno o ms dominios de la arquitectura (de negocios, datos, aplicaciones, tecnologa), y en algunos casos, la supervisin de la arquitectura general de la empresa, puede contratar a los integradores de sistemas, proveedores de aplicaciones, y / o proveedores de servicios. Cada uno de estos acuerdos normalmente se regir por un contrato de Arquitectura que define las prestaciones, la calidad y la aptitud para el propsito de la arquitectura desarrollada, y los procesos por los que los socios en el desarrollo de la arquitectura van a trabajar juntos. Al inicio de la fase G (Gobernanza de Implementacin), entre la funcin de la arquitectura y la funcin de responsable de la aplicacin de la arquitectura de la empresa se define en las fases anteriores de ADM. Normalmente, este ser o bien la funcin de desarrollo de sistemas en la empresa, o de un importante contratista a quien se contrata la obra. o Qu se est "implementada" en la Fase G del ADM es la arquitectura general de la empresa. En general, abarca la infraestructura de tecnologa (de la Fase D), y tambin aquellas aplicaciones empresariales y capacidades de gestin de datos que se han definido en la arquitectura de aplicaciones y arquitectura de datos (a partir de la fase C), ya sea porque son de toda la empresa en el mbito de aplicacin, o porque son estratgicos en trminos de negocio, y por lo tanto de importancia y visibilidad en toda la empresa. Sin embargo, normalmente no incluyen aplicaciones de negocio no estratgicas, que las unidades de negocio sern posteriormente desplegar en la parte superior de la infraestructura de la tecnologa que se implementa como parte de la arquitectura de la empresa. o En las implementaciones de gran escala, bien puede ser uno de licitacin Arquitectura por el equipo de implementacin de un programa de proyectos de implementacin. Cuando la arquitectura de la empresa ha puesto en prctica (al final de la fase G), un Contrato de Arquitectura normalmente se elaborar entre la funcin architecting ( o la funcin de gobierno de TI, que subsume la funcin architecting) y los usuarios de negocios que posteriormente se construye y la implementacin de sistemas de aplicaciones en el entorno con arquitectura.
Es importante tener en cuenta en todos los casos en que el objetivo final no es slo una empresa de arquitectura, sino una arquitectura empresarial dinmico; es decir, aquella que permite la evolucin flexibles en respuesta a los cambios en los conductores de tecnologa y negocios, sin restricciones innecesarias. El Contrato de Arquitectura es crucial para permitir una dinmica arquitectura de la empresa y es clave para que rige la aplicacin. Los contenidos tpicos de estas tres clases de Arquitectura Contrato se explican a continuacin.
49.2 Contenido
Pgina604de670

TOGOF9.1 49.2.1 Declaracin de Arquitectura de Trabajo
La Declaracin de Arquitectura Trabajo se crea como un entregable de la fase A, y es efectivamente un contrato de Arquitectura entre la organizacin de la arquitectura y el patrocinador de la arquitectura de la empresa (o la funcin de gobierno de TI, en nombre de la empresa). Los contenidos tpicos de una Declaracin de Trabajo de Arquitectura son los definidos en la Parte IV , 36.2.20 Declaracin de Arquitectura de Trabajo .
49.2.2 Contrato entre Arquitectura y Socios de Desarrollo
Esta es una declaracin de intencin firmada en el diseo y el desarrollo de la arquitectura de la empresa, o de una parte significativa de la misma, de las organizaciones asociadas, incluyendo integradores de sistemas, proveedores de aplicaciones y proveedores de servicios. Cada vez ms el desarrollo de uno o ms dominios de la arquitectura (de negocios, datos, aplicaciones, tecnologa) puede ser subcontratada, con la funcin de la arquitectura de la empresa que proporciona la supervisin de la arquitectura general de la empresa, y la coordinacin y el control del esfuerzo general. En algunos casos, incluso esta funcin de supervisin puede ser contratado, aunque la mayora de las empresas prefieren mantener que la responsabilidad principal en la casa. Cualesquiera que sean los detalles de los acuerdos de contratacin externa, los propios arreglos normalmente se rigen por un contrato de Arquitectura que define las prestaciones, la calidad y la aptitud para el propsito de la arquitectura desarrollada, y los procesos por los que los socios en el desarrollo de la arquitectura trabajarn juntos. Contenido tpico de un diseo y desarrollo de contratos de Arquitectura son:
Introduccin y antecedentes La naturaleza del acuerdo Alcance de la arquitectura Arquitectura y estratgicos principios y los requisitos Los requisitos de conformidad Proceso y las funciones de desarrollo y gestin de la Arquitectura Medidas arquitectura objetivo Fases definidas de entregables Plan de trabajo conjunto priorizado
Pgina605de670

TOGOF9.1
Ventana de tiempo (s) Arquitectura de entrega y de negocios mtricas
La plantilla para este contrato normalmente se define como parte de la Fase Preliminar de la ADM, si no es que ya existe, y el contrato especfico se definir en la fase adecuada de la ADM, en funcin de la obra en particular que se est subcontratado.
49.2.3 Funcin Contrato entre la arquitectura y los Usuarios de Negocio
Esta es una declaracin firmada de la intencin de cumplir con la arquitectura de la empresa, expedida por los usuarios de negocio de la empresa. Cuando la arquitectura de la empresa ha puesto en prctica (al final de la Fase F), un Contrato de Arquitectura normalmente se elaborar entre la funcin architecting ( o la funcin de gobierno de TI, que subsume la funcin architecting) y los usuarios de negocios que posteriormente se construye y la implementacin de sistemas de aplicaciones en el entorno con arquitectura. Los contenidos tpicos de la arquitectura de licitacin de un negocio de los usuarios son:
Introduccin y antecedentes La naturaleza del acuerdo Alcance Requisitos estratgicos Entregables Arquitectura que cumplan con los requisitos de negocio Los requisitos de conformidad Arquitectura adoptantes Ventana de tiempo Arquitectura mtricas de negocio Arquitectura de servicios (que incluye el contrato de nivel de servicio (SLA))
Este contrato tambin se utiliza para administrar los cambios en la arquitectura de la empresa en la Fase H.
49.3 Relacin con la arquitectura de la gobernanza

El documento de la Arquitectura Contrato produce en Fase G de las figuras ADM lugar destacado en el mbito de la gobernanza arquitectura, como se explica en la Parte VII , 50. Arquitectura de Gobierno .
Pgina606de670

TOGOF9.1
En el contexto de la gobernanza arquitectura, el Contrato de Arquitectura se utiliza a menudo como un medio para impulsar el cambio de la arquitectura. Con el fin de garantizar que el Contrato Arquitectura es eficaz y eficiente, puede ser necesario introducir en la fase G, los siguientes aspectos de la normativa de gobierno:
Procesos simples Autoridad centrado en las personas Comunicacin fuerte Las respuestas oportunas y un proceso de escalada efectiva Apoyo a las estructuras organizativas El seguimiento del estado de implementacin de la arquitectura
Pgina607de670

TOGOF9.1
50. Arquitectura de Gobierno

Este captulo proporciona un marco y directrices para la gobernanza de la arquitectura.
50.1 Introduccin
En esta seccin se describe la naturaleza de la gobernanza, y los niveles de gobernanza.
50.1.1 Niveles de Gobierno dentro de la empresa
Gobernabilidad Arquitectura es la prctica y la orientacin en la que las arquitecturas empresariales y otras arquitecturas son gestionados y controlados a nivel de toda la empresa. Gobernabilidad Arquitectura tpicamente no funciona de manera aislada, sino dentro de una jerarqua de las estructuras de gobierno, que, sobre todo en la empresa ms grande, pueden incluir todos los siguientes dominios distintos con sus propias disciplinas y procesos:
El gobierno corporativo Gobernabilidad Tecnologa Gobierno de TI Gobernabilidad Arquitectura
Cada uno de estos dominios de gobierno puede existir en diversos niveles geogrficos mundial, regional y local - dentro de la empresa en general. El gobierno corporativo es, pues, un tema muy amplio, ms all del alcance de un marco de arquitectura de la empresa, tales como TOGAF. Este y otros apartados se centran en la gobernanza de arquitectura; pero ellos lo describen en el contexto de la gobernabilidad en toda la empresa, debido a la jerarqua de las estructuras de gobierno en el que por lo general opera, como se explic anteriormente. En particular, esta seccin y las siguientes tienen por objeto:
Proporcionar una visin general de la naturaleza de la gobernanza como una disciplina por derecho propio Describir el contexto de la gobernanza en la que el gobierno arquitectura tpicamente funciona dentro de la empresa
Pgina608de670

TOGOF9.1
Describir un marco de gobernanza de Arquitectura que se pueden adaptar y aplicar en la prctica, tanto para la arquitectura de la empresa y de otras formas de la arquitectura de TI
50.1.2 Naturaleza de la Gobernabilidad

50.1.2.1 Gobernabilidad: una perspectiva genrica
La gobernanza es esencial en asegurar que el negocio se lleva a cabo correctamente. Es menos sobre el control manifiesto y el cumplimiento estricto de las normas, y ms acerca de la orientacin y eficaz y la utilizacin equitativa de los recursos para asegurar la sostenibilidad de los objetivos estratgicos de la organizacin. A continuacin se describen los principios bsicos de la gestin empresarial, identificados por la Organizacin para la Cooperacin y el Desarrollo Econmicos (OCDE):
Se centra en los derechos, las funciones y el tratamiento equitativo de los accionistas Comunicacin y transparencia y las responsabilidades de la junta Asegura: o Sonido orientacin estratgica de la organizacin o La vigilancia eficaz de la gestin de la junta o la rendicin de cuentas Junta para la empresa y para los accionistas Las responsabilidades de la Junta: o revisin y direccin de la estrategia corporativa o Configuracin y supervisin del cumplimiento de los objetivos de desempeo de la gerencia
Apoyando esto, la OCDE considera una visin tradicional de la gobernanza como: "... el sistema por el cual las corporaciones de negocios son dirigidas y controladas La estructura de gobierno corporativo especifica la distribucin de derechos y responsabilidades entre los diferentes participantes en la empresa - tales como el tablero. , gerentes, accionistas y otras partes interesadas - y detalla las normas y procedimientos para la toma de decisiones en asuntos corporativos Al hacer esto, sino que tambin proporciona la estructura a travs del cual se los objetivos de la empresa. establecen, y los medios para alcanzar dichos objetivos y la supervisin del rendimiento "[OCDE (1999)].
50.1.2.2 Caractersticas de Gobernabilidad
Las siguientes caractersticas han sido adaptados de Gobierno Corporativo (Naidoo, 2002) y se coloca aqu para poner de relieve el valor y la necesidad de una gobernanza como un enfoque que se adoptar dentro de las organizaciones y sus relaciones con todas las partes involucradas:
Pgina609de670

TOGOF9.1
Disciplina Todas las partes interesadas tendrn un compromiso de cumplir con los procedimientos, los procesos y las estructuras de autoridad establecidos por la organizacin. Transparencia Todas las acciones implementadas y su apoyo a las decisiones estarn disponibles para su inspeccin por las partes de la organizacin y los proveedores autorizados. Independencia Todos los procesos, toma de decisiones y los mecanismos utilizados se establecern con el fin de minimizar o evitar potenciales conflictos de inters. Responsabilidad Grupos identificables dentro de la organizacin - por ejemplo, las juntas de gobierno que toman las acciones o tomar decisiones - estn autorizados y responsables de sus actos. Responsabilidad Se requiere que cada parte contratada para actuar con responsabilidad para la organizacin y sus grupos de inters. Justicia Todas las decisiones tomadas, los procesos utilizados y su aplicacin no se les permitir crear una ventaja injusta a ningn partido en particular.
Gobernanza 50.1.3 Tecnologa
Controla la gobernanza Tecnologa cmo una organizacin utiliza la tecnologa en la investigacin, desarrollo y produccin de sus productos y servicios. A pesar de que puede incluir las actividades de gobierno de TI, a menudo tiene un alcance ms amplio. Gobierno La tecnologa es una capacidad clave, requisitos y recursos para la mayora de las organizaciones debido a la omnipresencia de la tecnologa en todo el espectro de la organizacin. Estudios recientes han demostrado que muchas organizaciones tienen un saldo a favor de los intangibles ms que tangibles que requieren gestin. Dado que la mayora de estos intangibles son activos informativos y digitales, es evidente que las empresas son cada vez ms dependientes de la TI, y la gobernabilidad de TI - El gobierno de TI - por lo tanto, se est convirtiendo en una parte an ms importante de la gestin de la tecnologa. Estas tendencias tambin destacan las dependencias de las empresas no slo en la informacin en s, sino tambin los procesos, sistemas y estructuras que crean, ofrecen y consumen. A medida que el cambio hacia el aumento de valor a travs de intangibles
Pgina610de670

TOGOF9.1
aumenta en muchos sectores de la industria, por lo que la gestin del riesgo debe ser considerado como la clave para la comprensin y la moderacin de los nuevos desafos, amenazas y oportunidades. No slo son organizaciones que dependen cada vez ms de la informacin para sus operaciones y la rentabilidad, sino tambin su reputacin, la marca, y en ltima instancia, sus valores tambin dependen de la misma informacin y la tecnologa de apoyo.
50.1.4 Gobierno de TI
Gobierno de TI proporciona el marco y la estructura que une los recursos de TI y la informacin a los objetivos y estrategias de la empresa. Por otra parte, el gobierno de TI institucionaliza las mejores prcticas para la planificacin, adquisicin, implementacin y monitoreo de desempeo de TI, para asegurarse de que los activos de TI de la empresa apoyan sus objetivos de negocio. En los ltimos aos, el gobierno de TI se ha convertido en parte integral de la gobernanza efectiva de la empresa moderna. Las empresas son cada vez ms dependientes de TI para apoyar las funciones crticas del negocio y los procesos; y para ganar con xito la ventaja competitiva, las empresas necesitan para gestionar eficazmente la tecnologa compleja que es un fenmeno generalizado en toda la organizacin, con el fin de responder de manera rpida y segura a las necesidades empresariales. Adems, los entornos normativos de todo el mundo estn exigiendo cada vez ms estricto control de la empresa sobre la informacin, impulsada por el aumento de los informes de los desastres del sistema de informacin y el fraude electrnico. La gestin de los riesgos relacionados con las TI es ahora ampliamente aceptada como una parte clave de la gobernanza empresarial. De ello se desprende que una estrategia de gobierno de TI, y una organizacin adecuada para la implementacin de la estrategia, deben ser establecidas con el apoyo de la alta direccin, aclarando que es dueo de los recursos de TI de la empresa, y, en particular, que tiene la responsabilidad ltima de su integracin en toda la empresa .
50.1.4.1 Un Controles de TI Marco - COBIT
Al igual que con el gobierno corporativo, gobierno de TI es un tema muy amplio, ms all del alcance de un marco de arquitectura de la empresa, tales como TOGAF. Una buena fuente de informacin detallada sobre el gobierno de TI es el marco COBIT (Objetivos de Control para la Informacin y Tecnologas Relacionadas). Este es un estndar abierto para el control de TI, desarrollado y promovido por el Instituto de Gobierno de TI, y publicado por la Information Systems Audit y Control Foundation (ISACF). Controles de COBIT pueden proporcionar una ayuda til a la ejecucin de una estrategia de cumplimiento. Un mapeo integral entre TOGAF y COBIT est disponible que gua al practicante en la
Pgina611de670

TOGOF9.1
aplicacin de la gobernanza arquitectura alineado con el gobierno de TI: Mapeo de TOGAF 8.1Con . COBIT 4.0, por el IT Governance Institute (ITGI) 1
50.1.5 Arquitectura de Gobierno: Visin general
50.1.5.1 arquitectura de gobernanza Caractersticas
Gobernabilidad Arquitectura es la prctica y la orientacin en la que las arquitecturas empresariales y otras arquitecturas son gestionados y controlados a nivel de toda la empresa. Incluye lo siguiente:
La implementacin de un sistema de controles sobre la creacin y el seguimiento de todos los componentes y actividades de arquitectura, para garantizar la efectiva introduccin, implantacin y evolucin de arquitecturas dentro de la organizacin La implementacin de un sistema para garantizar el cumplimiento de las normas internas y externas y las obligaciones reglamentarias El establecimiento de procesos de apoyo a la gestin eficaz de los procesos anteriores dentro de los parmetros acordados El desarrollo de prcticas que garanticen la rendicin de cuentas a una comunidad claramente identificadas las partes interesadas, tanto dentro como fuera de la organizacin 50.1.5.2 Arquitectura gobernanza como una responsabilidad del nivel de direccin
Como se mencion anteriormente, el gobierno de TI se ha convertido recientemente en una responsabilidad bordo como parte de la gobernanza empresarial en general. El gobierno de las arquitecturas de una organizacin es un factor clave en la vinculacin de TI / negocio eficaz, y por lo tanto es cada vez ms una tecla de responsabilidad a nivel de placa en su propio derecho. Esta seccin tiene como objetivo proporcionar el impulso para la apertura de TI y la gestin de arquitectura para que las responsabilidades empresariales asociados con las actividades de la arquitectura y los artefactos pueden ser dilucidados y gestionados.
50.1.5.3 TOGAF y Arquitectura de Gobierno
Fase G del TOGAF ADM (vase parte II , 15 Fase G:. Gobernanza Aplicacin ) est dedicado a la gobernanza de ejecucin, que se ocupa de la realizacin de la arquitectura a travs de los proyectos de cambio. Gobernabilidad implementacin es slo un aspecto de la gobernanza arquitectura, que abarca la gestin y el control de todos los aspectos del desarrollo y la evolucin de las arquitecturas empresariales y otras arquitecturas dentro de la empresa. Gobernabilidad Arquitectura necesita ser apoyado por un marco de gobernanza Arquitectura (descrito en 50.2 Arquitectura Governance Framework ), que ayuda a identificar los procesos efectivos para que las responsabilidades empresariales asociados a la
Pgina612de670

TOGOF9.1
gobernabilidad arquitectura pueden ser dilucidados, comunicadas, y gestionadas con eficacia.
50.2 Arquitectura del marco de la gobernanza

En esta seccin se describe un marco conceptual y organizativo para la gobernanza de la arquitectura. Como se ha explicado anteriormente, la fase G del TOGAF ADM (ver Parte II , 15. Fase G: Gobernanza Aplicacin ) est dedicado a la gobernanza de ejecucin, que se ocupa de la realizacin de la arquitectura a travs de los proyectos de cambio. Gobernabilidad implementacin es slo un aspecto de la gobernanza arquitectura, que abarca la gestin y el control de todos los aspectos del desarrollo y la evolucin de las arquitecturas empresariales y otras arquitecturas dentro de la empresa. Gobernabilidad Arquitectura necesita ser apoyado por un marco de gobernanza Arquitectura, se describe a continuacin. El marco del gobierno de describir es un marco genrico que se puede adaptar al entorno de gobernanza existente de una empresa. Se tiene la intencin de ayudar en la identificacin de procesos eficaces y de organizacin de estructuras, de modo que las responsabilidades empresariales asociados a la gobernabilidad arquitectura pueden ser dilucidados, comunicadas, y gestionadas con eficacia.
50.2.1 Arquitectura del marco de gobernanza Estructura conceptual
50.2.1.1 Conceptos clave
Conceptualmente, la gobernabilidad arquitectura es un enfoque, una serie de procesos, una orientacin cultural, y un conjunto de responsabilidades de propiedad que garanticen la integridad y la eficacia de las arquitecturas de la organizacin. Los conceptos clave se ilustran en la Figura 50-1 .
Pgina613de670

TOGOF9.1
Figura501:ArquitecturaGovernanceFrameworkEstructuraconceptual
La divisin del proceso, el contenido y el contexto son clave para el apoyo de la iniciativa de gobierno arquitectura, por lo que permite la introduccin de nuevo material de gobierno (legal, reglamentaria, basada en estndares, o legislativo) sin afectar indebidamente los procesos. Este enfoque de contenido agnstico asegura que el marco es flexible. Los procesos suelen ser independiente del contenido y poner en prctica un enfoque de mejores prcticas probadas de la gobernanza activa. El Marco de Gobierno La arquitectura es parte integral de la empresa Continuum, y gestiona todo el contenido relevante, tanto para la propia arquitectura y para los procesos de gobernanza de la arquitectura.
50.2.1.2 Procesos Clave arquitectura de la gobernanza
Se requieren procesos de gobierno para identificar, gestionar, auditar y difundir toda la informacin relacionada con la gestin de la arquitectura, los contratos y la ejecucin. Estos procesos de gestin servir para asegurarse de que todos los artefactos de la arquitectura y de los contratos, los principios y los acuerdos de nivel operativo son monitoreados en forma permanente con capacidad de auditora clara de todas las decisiones tomadas.
Pgina614de670

TOGOF9.1
Gestin de Polticas y Take-On
Todas las modificaciones de arquitectura, los contratos y la informacin de apoyo deben estar bajo el gobierno a travs de un proceso formal para registrar, validar, ratificar, administrar y publicar contenido nuevo o actualizado. Estos mecanismos servirn para garantizar la integracin ordenada con contenido de gobierno existente de tal manera que todas las partes relevantes, documentos, contratos y la informacin de apoyo son administrados y auditados.
Conformidad
Las evaluaciones del cumplimiento contra los Acuerdos de Nivel de Servicio (SLAs), Acuerdos de Nivel Operacional (OLA), las normas y los requisitos reglamentarios se llevarn a cabo de manera continua para garantizar la estabilidad, la conformidad y supervisin del rendimiento. Estas evaluaciones sern revisadas y aceptadas o rechazadas en funcin de los criterios definidos en el marco de gobernanza.
Dispensa
Una evaluacin de la conformidad puede rechazarse cuando la materia (diseo, funcionamiento, nivel de servicio o la tecnologa) no son compatibles. En este caso, el tema puede:
1. Ser ajustado o reajustado a fin de satisfacer los requisitos de cumplimiento 2. Solicite una dispensacin
En caso de rechazo de una Evaluacin de Cumplimiento, una ruta alternativa para el cumplimiento de la conformidad provisional se proporciona a travs de las dispensaciones. stos se conceden por un periodo de tiempo determinado y un conjunto de servicios identificados y criterios operacionales que deben ser ejecutadas durante la vida til de la dispensacin. Las dispensaciones no se otorgan por tiempo indefinido, pero se utilizan como un mecanismo para asegurar que los niveles de servicio y los niveles operativos se cumplen mientras que proporciona un nivel de flexibilidad en su aplicacin y el tiempo. La naturaleza de duracin determinada de dispensaciones asegura que son un disparador importante en el ciclo de cumplimiento.
Control y seguimiento
Se requiere una gestin de rendimiento para asegurar que tanto los elementos operativos y de servicios se gestionan en contra de un conjunto acordado de criterios.Esto incluir la vigilancia contra los acuerdos de servicio y de nivel operativo, los comentarios para el ajuste y presentacin de informes. Informacin de gestin interna se considerar en Gestin Ambiental .
Pgina615de670

TOGOF9.1
Control para Empresas
Control para Empresas se relaciona con los procesos alegadas para garantizar el cumplimiento de las polticas comerciales de la organizacin.
Gestin Ambiental
Esto identifica todos los servicios necesarios para asegurar que el medio ambiente basada en un repositorio que sustenta el marco de gobierno es eficaz y eficiente.Esto incluye la gestin fsica y lgica repositorio, acceso, comunicacin, formacin y acreditacin de todos los usuarios. Todos los artefactos arquitectura, contratos de servicio, contratos, e informacin de apoyo deben estar bajo el gobierno a travs de un proceso formal para registrar, validar, ratificar, administrar y publicar contenido nuevo o actualizado. Estos mecanismos servirn para garantizar la integracin ordenada con contenido de gobierno existente de tal manera que todas las partes relevantes, documentos, contratos y la informacin de apoyo son administrados y auditados. El ambiente de gobernabilidad tendr una serie de procesos administrativos definidos con el fin de efectuar un servicio gestionado y entorno del proceso. Estos procesos incluyen la gestin de usuarios, SLA internos (definidos con el fin de controlar sus propios procesos), y la informacin de gestin de informes.
50.2.2 Arquitectura del marco de gobernanza Estructura Organizacional
50.2.2.1 Informacin general
Gobernabilidad Arquitectura es la prctica y la orientacin en la que las arquitecturas empresariales y otras arquitecturas son gestionados y controlados. Con el fin de garantizar que este control es eficaz dentro de la organizacin, es necesario contar con las estructuras organizativas correctas establecidas para apoyar todas las actividades de gobierno. Una estructura de gobierno arquitectura para la aplicacin efectiva del enfoque descrito en esta seccin incluir tpicamente los siguientes niveles, que pueden en la prctica implican una combinacin de procesos de TI existentes de gobierno, las estructuras organizativas y capacidades. Ellos suelen incluir lo siguiente:
Junta de gobierno Global Junta de Gobierno Local Autoridades de Diseo Grupos de trabajo
Pgina616de670

TOGOF9.1
La organizacin arquitectura se ilustra en la Figura 50-2 se destacan los principales elementos estructurales necesarios para una iniciativa de gobierno arquitectura. Si bien cada empresa tendr diferentes necesidades, se espera que los fundamentos del diseo de la organizacin se muestra en la Figura 50-2 se aplicarn y aplicables en una amplia variedad de tipos de organizacin.
Figura502:ArquitecturaGovernanceFrameworkEstructuraOrganizacional 50.2.2.2 reas Clave Figura 50-2 identifica tres reas clave de la gestin de la arquitectura: Desarrollar,
implementar y desplegar. Cada uno de ellos es la responsabilidad de uno o varios grupos dentro de la organizacin, mientras que la empresa Continuum se muestra para apoyar todas las actividades y los artefactos asociados a la gobernanza de las arquitecturas en todo su ciclo de vida. Los Desarrollar responsabilidades, procesos y estructuras suelen estar vinculadas a la TOGAF ADM y su uso, mientras que las responsabilidades Implementar, procesos y estructuras generalmente estn vinculados a la fase G (vase la Parte II , 15 Fase G:. Gobernanza Aplicacin ).
Pgina617de670

TOGOF9.1
Como se mencion anteriormente, el Marco de Gobierno La arquitectura es parte integral de la empresa Continuum, y gestiona todo el contenido relevante, tanto a los propios como a los procesos de gobernanza configuraciones configuracin.
50.2.2.3 Beneficios operacionales
Como se ilustra en la Figura 50-2 , la gobernanza de las arquitecturas de la organizacin no slo proporciona el control directo y la orientacin de su desarrollo y aplicacin, pero tambin se extiende a las operaciones de las arquitecturas implementadas. Se han encontrado los siguientes beneficios que se derivan a travs de la continua gobierno de arquitecturas:
Enlaces procesos de TI, los recursos y la informacin a las estrategias y objetivos de la organizacin Se integra e institucionaliza las mejores prcticas de Alinea con los marcos de la industria tales como COBIT (planificacin y organizacin, adquisicin e implementacin, entrega y apoyo, y el seguimiento del desempeo de TI) Permite a la organizacin a sacar el mximo provecho de sus activos de informacin, de infraestructura y de hardware y software Protege los activos digitales subyacentes de la organizacin Soporta requisitos de prcticas de regulacin y mejores como la auditabilidad, la seguridad, la responsabilidad y la rendicin de cuentas Promueve la gestin del riesgo visible
Estos beneficios se posicionan Governance Framework TOGAF Arquitectura como un enfoque, una serie de procesos, una orientacin cultural, y un conjunto de propiedad de responsabilidades, que juntos asegurar la integridad y la eficacia de las arquitecturas de la organizacin.
50.3 Arquitectura de Gobierno en la Prctica

Esta seccin proporciona directrices prcticas para la aplicacin eficaz de gobernanza de la arquitectura.
Factores claves de xito 50.3.1 Arquitectura de Gobierno
Es importante tener en cuenta lo siguiente para asegurar un enfoque exitoso para el gobierno arquitectura, y para la gestin eficaz del Contrato de Arquitectura:
Pgina618de670

TOGOF9.1
Mejores prcticas para la presentacin, la adopcin, la reutilizacin, la notificacin y el retiro de las polticas de arquitectura, procedimientos, funciones, competencias, estructuras organizativas, y servicios de apoyo Responsabilidades y estructuras de apoyo a los procesos de gobernanza de arquitectura y requisitos de informacin de la Organizacin Integracin de las herramientas y procesos para facilitar la asimilacin de los procesos, tanto de procedimiento y culturalmente Criterios para el control de los procesos de gobierno arquitectura, dispensas, evaluaciones de cumplimiento, SLAs y OLAs Requisitos internos y externos para la eficacia, eficiencia, confidencialidad, integridad, disponibilidad, cumplimiento y confiabilidad de toda la informacin relacionada con la arquitectura de gobernanza-, los servicios y los procesos
50.3.2 Elementos de una Estrategia de Gobernabilidad Efectiva Arquitectura

50.3.2.1 Arquitectura Gobernabilidad y Poltica Corporativa
Una arquitectura empresarial impuesta sin el apoyo poltico adecuado est condenada al fracaso. Para tener xito, la arquitectura de la empresa debe reflejar las necesidades de la organizacin. Los arquitectos de la empresa, si no estn implicados en el desarrollo de la estrategia de negocio, por lo menos deben tener una comprensin fundamental de la misma y de los problemas de negocio imperantes que enfrenta la organizacin. Incluso puede ser necesario para que puedan participar en el proceso de implementacin del sistema y de poseer en ltima instancia, las decisiones de inversin y seleccin de productos derivados de la aplicacin de la Tecnologa de la Arquitectura. Hay tres elementos importantes de la estrategia de gobierno de la arquitectura que se refieren en particular a la aceptacin y el xito de la arquitectura dentro de la empresa. Mientras relevantes y aplicables en su propio derecho, aparte de su papel en el gobierno, y por lo tanto, describe por separado, sino que tambin de una parte integral del cualquier estrategia de gobierno arquitectura eficaz.
Una Junta de Arquitectura de toda la Organizacin (vase 47.ArchitectureBoard ) se debe establecer con el respaldo de la alta direccin para supervisar la aplicacin de la estrategia de gobierno de TI. Un completo conjunto de principios de la arquitectura (vase 23.Principiosde Arquitectura debe establecerse), para orientar, informar y apoyar la forma en que una organizacin se marca sobre el cumplimiento de su misin a travs de la utilizacin de las TI. Una Cumplimiento Arquitectura (ver .48ArquitecturaCumplimiento ) estrategia debe ser adoptada - medidas especficas (algo ms que una declaracin de poltica) para garantizar el cumplimiento de la arquitectura, incluyendo las evaluaciones de impacto de proyectos, un proceso de revisin de Cumplimiento Arquitectura formal, y, posiblemente, incluso mediante la integracin del equipo de arquitectura de la contratacin del producto.
Pgina619de670

TOGOF9.1
Pgina620de670

TOGOF9.1
51. Arquitectura de Madurez Modelos

Este captulo proporciona tcnicas para evaluar y cuantificar la madurez de una organizacin en la arquitectura de la empresa.

Organizaciones que pueden gestionar el cambio con eficacia son generalmente ms xito que las que no pueden. Muchas organizaciones saben que necesitan para mejorar sus procesos con el fin de gestionar con xito el cambio, pero no saben cmo. Tales organizaciones tpicamente gastan muy poco en la mejora de procesos, porque no estn seguros de cmo proceder mejor; o gastar mucho, en una serie de esfuerzos paralelos y desenfocadas, con poco o ningn resultado. Modelos de Madurez de Capacidad (CMM) abordan este problema al proporcionar un mtodo eficaz y probado para una organizacin para ganar poco a poco el control y la mejora de sus procesos de cambio. Estos modelos proporcionan los siguientes beneficios:
Describen las prcticas que cualquier organizacin debe llevar a cabo con el fin de mejorar sus procesos. Proporcionan un criterio para medir peridicamente la mejora. Constituyen un marco probado en el que la gestin de los esfuerzos de mejora. Organizan las diversas prcticas en niveles, cada nivel que representa una mayor capacidad para controlar y gestionar el entorno de desarrollo.
Una evaluacin de las prcticas de la organizacin contra el modelo - llamado una "evaluacin" - determina el nivel en el que se encuentra la organizacin en la actualidad. Indica la capacidad de la organizacin para ejecutar en la zona de que se trate, y las prcticas en las que la organizacin necesita para centrarse con el fin de ver la mejora ms grande y el ms alto retorno de la inversin. Los beneficios de MMCs para efectivamente esfuerzo directo estn bien documentados.
51.2 Antecedentes
El Instituto de Ingeniera de Software (SEI) - www.sei.cmu.edu operado por la Universidad Carnegie Mellon - desarroll el CMM originales (Capability Maturity Model) para el Software (SWCMM) a principios de 1990, que sigue siendo ampliamente utilizado hoy. Esta CMM proporciona un marco para desarrollar modelos de madurez en una amplia gama de disciplinas.
Pgina621de670

TOGOF9.1
El creciente inters en la aplicacin de estas tcnicas a otros campos ha dado lugar a una serie de herramientas de la plantilla que evalan:
El estado de los procesos de arquitectura La arquitectura Buy-in de la organizacin tanto a
Los principales temas abordados en estos modelos incluyen:

Implementacin de procesos y de auditora Las mediciones de calidad Gente competencias Gestin de las inversiones
Implican el uso de una multiplicidad de modelos, y se centran en particular en la medicin de los beneficios del negocio y retorno de la inversin. Un tema estrechamente relacionado es el Skills Framework Architecture (ver 52. Arquitectura Skills Framework ), que se puede utilizar para planificar las habilidades objetivo y capacidades requeridas por una organizacin para desarrollar y utilizar la arquitectura empresarial con xito, y para determinar las necesidades de capacitacin y desarrollo de individuos.
51.3 Marco de EE.UU. Departamento de Comercio ACMM

Como un ejemplo de la tendencia hacia un mayor inters en la aplicacin de tcnicas de CMM para la arquitectura empresarial, ahora se espera que todas las agencias federales de Estados Unidos para proporcionar modelos de madurez y clasificaciones como parte de sus requisitos de gestin de inversiones y de auditora de TI. En particular, el Departamento de Comercio de EE.UU. (DoC) ha desarrollado una arquitectura empresarial Capability Maturity Model (ACMM ) 1 para ayudar en la realizacin de evaluaciones internas. ACMM versin 1.2 se public en diciembre de 2007. El ACMM proporciona un marco que representa los componentes clave de un proceso de arquitectura de la empresa productiva. El objetivo es mejorar las probabilidades generales para el xito de la arquitectura empresarial mediante la identificacin de las reas dbiles y proporcionar un camino evolutivo definido a mejorar el proceso global de la arquitectura. El ACMM se compone de tres secciones:
1. El modelo de madurez de la arquitectura empresarial Pgina622de670

TOGOF9.1 2. Caractersticas de arquitectura empresarial de los procesos de las unidades operativas en los diferentes niveles de madurez 3. El CMM scorecard arquitectura empresarial
Las dos primeras secciones se explica la arquitectura de los niveles de madurez de la capacidad y la arquitectura elemento personal empresa correspondiente y las caractersticas de cada nivel de madurez para ser utilizados como medidas en el proceso de evaluacin. En la tercera seccin se utiliza para obtener el nivel de madurez de capacidades Arquitectura que debe ser reportada a la Informacin Oficial Jefe Departamento de Comercio (CIO).
51.3.2 Elementos del ACMM
La Declaracin ACMM consta de seis niveles de madurez y nueve elementos de la arquitectura. Los seis niveles son:
0 Ninguno 1 Inicial 2 En desarrollo 3 Definido 4 Gestionado 5 Medido
Los nueve elementos de la arquitectura de la empresa son los siguientes:

1. Proceso de Arquitectura 2. El desarrollo de la Arquitectura 3. Vinculacin de negocios 4. Implicacin personal directivo superior Pgina623de670

TOGOF9.1 5. Participacin unidad de funcionamiento 6. Comunicacin Arquitectura 7. Seguridad de TI 8. Gobernabilidad Arquitectura 9. Inversin en TI y la estrategia de adquisicin
Dos mtodos complementarios se utilizan en el ACMM para calcular una calificacin de madurez. El primer mtodo se obtiene una media de nivel de madurez de arquitectura empresarial ponderado. El segundo mtodo muestra el porcentaje alcanzado en cada nivel de madurez para los nueve elementos de la arquitectura.
51.3.3 Ejemplo: Arquitectura Empresarial niveles de madurez de procesos
El siguiente ejemplo muestra las caractersticas detalladas de los niveles de madurez de arquitectura empresarial que se aplican a cada uno de los nueve elementos. Por ejemplo, el Nivel 3: Definido, el punto nmero 8 (gobernanza explcito documentado de la mayora de las inversiones en TI), muestra el estado del Nivel de Madurez 3 por elemento 8 (Arquitectura de Gobierno).
Nivel 0: Ninguno
Ningn programa de arquitectura de la empresa. No arquitectura empresarial que hablar.

Nivel 1: Inicial
Informal proceso de arquitectura de la empresa en marcha.

1. Los procesos son ad hoc y localizada. Algunos procesos de arquitectura empresarial se
definen. No hay proceso de la arquitectura unificada a travs de tecnologas o procesos de negocio. El xito depende de los esfuerzos individuales.
2. Procesos de arquitectura de la empresa, la documentacin y las normas son establecidas por una variedad de especiales medios y son localizados o informal. 3. Minimal, vinculacin o implcita de las estrategias de negocio o controladores de negocio. 4. Conocimiento limitado equipo de gestin o la participacin en el proceso de la arquitectura. 5. Limited funcionamiento de la unidad de aceptacin del proceso de arquitectura de la empresa. 6. La ltima versin de la documentacin de la arquitectura empresarial de la unidad de
mando est en la web. Existe poca comunicacin sobre el proceso de arquitectura de la empresa y las mejoras posibles procesos.
Pgina624de670

TOGOF9.1 7. Consideraciones de seguridad de TI son ad hoc y localizada. 8. No gobernabilidad explcita de las normas arquitectnicas. 9. Poca o ninguna participacin de personal de planificacin y adquisiciones estratgicas en
el proceso de arquitectura de la empresa. Poca o ninguna adherencia a los estndares existentes. Nivel 2: En desarrollo
Proceso de arquitectura de la empresa se encuentra en desarrollo.

1. Proceso bsico de arquitectura empresarial se documenta sobre la base de la OMB
Circular A-130 y el Departamento de Comercio de Arquitectura Empresarial de Orientacin. El proceso de la arquitectura se ha desarrollado funciones y responsabilidades claras.
2. La visin de TI, los principios, los vnculos comerciales, de lnea de base y Arquitectura
objetivo se identifican. Existen normas Arquitectura, pero no necesariamente vinculados a Target Arquitectura. Modelo Referencia tcnica (TRM) y el marco de las Normas perfil establecido.
3. Vinculacin explcita con las estrategias de negocio. 4. Conciencia de Gestin de la arquitectura esfuerzo. 5. Asignacin de responsabilidades y se est trabajando. 6. El Departamento de Comercio y de la unidad de funcionamiento las pginas web de
arquitectura empresarial se actualizan peridicamente y se utilizan para documentar la arquitectura entregables.
7. Arquitectura de seguridad de TI ha definido roles y responsabilidades claras. 8. Gobernanza de unos estndares arquitectnicos y algunos adherencia al existente Perfil Normas. 9. Poco o ningn gobierno formal de la inversin en TI y la estrategia de adquisicin. Equipo de operacin demuestra la adhesin a alguna existente Perfil Normas.
Nivel 3: Definido
Arquitectura empresarial Definido incluyendo procedimientos escritos detallados y TRM.

1. La arquitectura est bien definida y comunicada al personal de TI y la gestin empresarial
con el equipo de operacin responsabilidades de TI. El proceso se sigui en gran medida.
2. Se han completado el anlisis de brechas y el Plan de Migracin. TRM desarrollado plenamente y Normas perfil. IT objetivos y mtodos se identifican. 3. Arquitectura empresarial est integrada con la planificacin del capital y el control de las inversiones. Pgina625de670

TOGOF9.1 4. Equipo Directivo al tanto y apoya el proceso de arquitectura de toda la
empresa. Administracin apoya activamente las normas arquitectnicas.
5. La mayora de los elementos de la unidad de operacin muestran aceptacin o estn participando activamente en el proceso de arquitectura de la empresa. 6. Arquitectura documentos actualizados regularmente en la empresa doc Pgina web arquitectura. 7. Arquitectura de seguridad de TI Normas perfil est totalmente desarrollado y se integra con la arquitectura empresarial. 8. Gobernabilidad explcita documentada de la mayora de las inversiones en TI. 9. Existe una estrategia de adquisicin de TI e incluye medidas de cumplimiento de la
arquitectura de TI de la empresa. Beneficios econmicos son considerados en la identificacin de proyectos. Nivel 4: Gestionado
Gestionado y el proceso de arquitectura de la empresa medido.

1. Proceso de arquitectura de la empresa forma parte de la cultura. Las mtricas de calidad asociados con el proceso de la arquitectura son capturados. 2. Documentacin de la arquitectura Enterprise se actualiza en un ciclo regular para reflejar la
arquitectura de la empresa actualizada. Arquitecturas de negocios, datos, aplicaciones y tecnologa definida por el apropiado de jure y de facto normas.
3. La planificacin de capital y control de las inversiones se ajustan en base a los comentarios

recibidos y las lecciones aprendidas de la arquitectura empresarial actualizado. peridica nuevo examen de los impulsores del negocio.
4. Equipo de alta gerencia que participan directamente en el proceso de revisin de la arquitectura. 5. La unidad operativa entera acepta y participa activamente en el proceso de arquitectura de la empresa. 6. Arquitectura documentos se actualizan regularmente, y frecuentemente crtica para los ltimos desarrollos de arquitectura / standards. 7. Mtricas de desempeo asociados a la arquitectura de seguridad de TI son capturados. 8. Gobernabilidad explcita de todas las inversiones de TI. Los procesos formales para la gestin de las varianzas retroalimentan arquitectura empresarial. 9. Todas las adquisiciones y compras de TI planificadas son guiados y regidos por la arquitectura de la empresa.
Nivel 5: Optimizacin
Pgina626de670

TOGOF9.1
Mejora continua del proceso de arquitectura de la empresa.

1. Concertada los esfuerzos para optimizar y mejorar continuamente el proceso arquitectura. 2. Un proceso de las normas y renuncias se utiliza para mejorar el proceso de desarrollo de la arquitectura. 3. Mtricas de procesos Arquitectura se utilizan para optimizar e impulsar los vnculos
comerciales. Negocios involucrado en las mejoras continuas de los procesos de la arquitectura empresarial.
4. Participacin alta direccin en la optimizacin de mejoras en los procesos de desarrollo de la arquitectura y la gobernabilidad. 5. Comentarios sobre el proceso de la arquitectura de todos los elementos de la unidad de servicio se utiliza para impulsar mejoras en los procesos de la arquitectura. 6. Arquitectura documentos son utilizados por todos los que toma las decisiones en la organizacin para cada decisin de negocios relacionados con las TI. 7. La retroalimentacin de TI arquitectura de seguridad mtricas se utilizan para impulsar mejoras en los procesos de la arquitectura. 8. Gobernabilidad explcita de todas las inversiones de TI. Un proceso de las normas y renuncias se utiliza para hacer las mejoras de gobierno en procesos. 9. Sin inversin en TI no planificado o de la actividad de adquisicin.
51.4 Modelos de Madurez de Capacidad de Integracin (CMMI)

51.4.1 Introduccin
Los modelos de capacidad que el SEI est actualmente involucrado en el desarrollo, expansin, o el mantenimiento son las siguientes:
CMMI (Capability Maturity Model Integration) IPD-CMM (Desarrollo de Productos Integrada Capability Maturity Model) P-CMM (People Capability Maturity Model) SA-CMM (Software Acquisition Capability Maturity Model) SE-CMM (Ingeniera de Sistemas Capability Maturity Model) SW-CMM (Capability Maturity Model de Software)
Como se explica en este captulo, en los ltimos aos la industria ha experimentado un crecimiento significativo en el rea de modelos de madurez. La multiplicidad de modelos disponibles ha llevado a sus propios problemas, en cuanto a la forma de integrar todos los
Pgina627de670

TOGOF9.1
diferentes modelos para producir una mtrica con significado para la madurez del proceso global. En respuesta a esta necesidad, el SEI ha desarrollado un marco llamado Capability Maturity Model Integration (CMMI), para proporcionar un medio de gestionar la complejidad. Segn el SEI, el uso de los modelos CMMI mejora en las mejores prcticas de los modelos anteriores en muchos aspectos importantes, en particular las organizaciones que permitan a:
Vincular de forma ms explcita las actividades de gestin y de ingeniera a los objetivos de negocio Ampliar el alcance y la visibilidad de las actividades del ciclo de vida del producto y de ingeniera para asegurar que el producto o servicio cumple con las expectativas del cliente Incorporar las lecciones aprendidas de otras reas de las mejores prcticas (por ejemplo, medicin, gestin de riesgos y la gestin de proveedores) Implementar prcticas de alta madurez ms robustas Direccin funciones organizativas adicionales crticos para sus productos y servicios Ms cumplir plenamente con las normas pertinentes de la ISO
CMMI se est adoptando en todo el mundo.

51.4.2 Mtodo SCAMPI
El CMMI Mtodo de evaluacin estndar para la Mejora de Procesos (SCAMPI) es el mtodo de evaluacin asociada con CMMI. El mtodo de evaluacin SCAMPI se utiliza para identificar las fortalezas, debilidades, y valoraciones en relacin con los modelos de referencia CMMI. Incorpora las mejores prcticas encontradas con xito en la comunidad de evaluacin, y se basa en las caractersticas de varios mtodos de evaluacin legado. Es aplicable a una amplia gama de modos de uso de evaluacin, incluyendo tanto la mejora de procesos internos y externos determinaciones de capacidad. El documento de definicin del mtodo SCAMPI 2 se describen los requisitos, las actividades y las prcticas relacionadas con cada uno de los procesos que componen el mtodo SCAMPI.
51.5 Conclusiones
En esta seccin se ha tratado de introducir en TOGAF el tema de los mtodos y tcnicas basadas en CMM para su uso en relacin con la arquitectura empresarial. Los beneficios de usar MMCs estn bien documentados. Las futuras versiones de TOGAF pueden incluir un modelo de madurez para medir la adopcin de s TOGAF.
Pgina628de670

TOGOF9.1
52. Arquitectura Skills Framework

En este captulo se proporciona un conjunto de funciones, la habilidad y la experiencia de las normas para el trabajo de arquitectura de empresa del personal de la empresa.
52.1 Introduccin
. Habilidades marcos proporcionan una vista de los niveles de competencia requeridos para funciones especficas Definen:
Los roles dentro de un rea de trabajo Las habilidades que requiere cada funcin La profundidad de los conocimientos necesarios para cumplir la funcin con xito
Son relativamente comunes para la definicin de las competencias necesarias para una empresa de consultora y / o cesin de gestin de proyectos, para entregar un proyecto especfico o paquete de trabajo. Tambin son muy utilizados por las agencias de contratacin y de bsqueda para que coincida con los candidatos y los roles. Su valor se deriva de su capacidad para proporcionar un medio para identificar rpidamente partidos de habilidad y lagunas. Aplicado con xito, pueden asegurar que los candidatos son aptos para los puestos de trabajo que tengan asignadas. Su valor en el contexto de la arquitectura de la empresa se debe a la inmadurez de la disciplina de arquitectura empresarial, y los problemas que surgen de esto.
52.2 Necesidad de un Marco de Arquitectura Empresarial Habilidades

52.2.1 Definitoria Rigor
"Arquitectura Empresarial" y "EA" son ampliamente utilizados pero hoy mal definidos los trminos de la industria. Se utilizan para denotar una variedad de prcticas y habilidades aplicadas en una amplia variedad de dominios de arquitectura. Hay una necesidad de una mejor clasificacin para permitir una comprensin ms implcita de qu tipo de arquitectura / arquitecto que se est describiendo. Esta falta de uniformidad conduce a dificultades para las organizaciones que buscan contratar o asignar / promocin de personal para cubrir puestos en el campo de la arquitectura. Debido a los diferentes usos de los trminos, a menudo la incomprensin y la
Pgina629de670

TOGOF9.1
falta de comunicacin entre los que buscan reclutar a favor, y los que tratan de llenar, los diferentes roles del arquitecto.
52.2.2 Bases de la Prctica de la Arquitectura Interior
A pesar de la falta de una terminologa uniforme, habilidades de arquitectura estn en el incremento de la demanda, ya que la disciplina de la arquitectura ganancias cada vez ms atencin en la industria. Muchas empresas han establecido, o estn considerando la creacin, una prctica de la arquitectura empresarial, como medio de fomentar el desarrollo de las habilidades y experiencia necesarias entre el personal de la casa para llevar a cabo las diferentes tareas requeridas por la arquitectura de la empresa. Una prctica de la arquitectura empresarial es un programa formal de desarrollo y certificacin, mediante el cual una entidad reconoce formalmente la competencia de sus arquitectos en ejercicio, como se demuestra por su trabajo. Ese programa es esencial para asegurar la alineacin de las capacidades del personal y la experiencia con las tareas de arquitectura que la empresa desee realizar. Tambin se requiere que las definiciones de funciones y de competencias en el que un programa de este tipo tiene que basarse, por tanto el reclutamiento y las organizaciones que suministran, en los casos en que el personal externo ha sido contratada para realizar el trabajo de arquitectura (por ejemplo, como parte de un compromiso de consultora). Una prctica de arquitectura de la empresa es difcil y costoso establecer. Normalmente se construye en torno a un proceso de revisin por pares, y consiste en el tiempo y el talento del liderazgo tcnico estratgico de una empresa. Normalmente se trata de establecimiento de un comit de revisin de pares, y la documentacin del proceso, y de los requisitos para la certificacin interna. El tiempo tambin se exigi a los aspirantes a prepararse para la revisin por pares, mediante la creacin de un portafolio de su trabajo para demostrar sus habilidades, experiencias y contribuciones a la profesin. El TOGAF Arquitectura Skills Framework intenta abordar esta necesidad proporcionando definiciones de las habilidades de la arquitectura y los niveles de competencia necesarios de personal, internos o externos, que vaya a realizar las diversas funciones Architecting definidos en el Marco TOGAF. Debido a la complejidad, el tiempo y costo, muchas empresas no cuentan con un programa interno de certificacin de arquitecto de la empresa, prefiriendo en lugar de simplemente entrevistar y contratar a personal de la arquitectura en un ad hoc base. Existen riesgos graves asociados con este enfoque:
La comunicacin entre las organizaciones de reclutamiento, consultoras y agencias de empleo es muy difcil.
Pgina630de670

TOGOF9.1
El tiempo es perdido entrevistar al personal que puedan haber aplicado de buena fe, pero an carecen de los conocimientos y / o experiencia requeridas por el empleador. El personal que son capaces de llenar papeles arquitectura puede ser pasado por alto, o no puede identificarse con las vacantes publicadas y por lo tanto ni siquiera aplicar. Hay mayor riesgo de personal inadecuados ser empleado o contratado, a travs de la culpa de nadie, ya pesar de todos los involucrados que actan de buena fe.Esto a su vez puede: o Aumentar los gastos de personal, a travs de la necesidad de volver a contratar o reasignar personal o afectar negativamente el tiempo, costo y calidad de los sistemas de TI operacionales y los proyectos que les ofrecen
52,3 Goles / Justificacin

52.3.1 Certificacin de Enterprise Architects
El propsito principal de un establecimiento de un programa interno de certificacin de arquitecto de la empresa de la empresa es doble:
1. Reconocer formalmente a la habilidad de sus arquitectos en ejercicio, como parte de la tarea de establecer y mantener una organizacin architecting profesional 2. Para asegurar la alineacin de las capacidades del personal necesario y la experiencia con
las tareas de arquitectura que la empresa desea realizar, si stos se van a realizar internamente a la empresa o en el exterior; por ejemplo, como parte de un compromiso de consultora
52.3.2 Beneficios especficos
Los beneficios especficos previstos por el uso del TOGAF Arquitectura Skills Framework incluyen:
Reduccin del tiempo, el costo y el riesgo en la formacin, la contratacin y la gestin de profesionales de la arquitectura, tanto internos como externos: o la comunicacin entre las organizaciones de reclutamiento Simplifica, consultoras y agencias de empleo o Evita perder tiempo entrevistando a personal que puedan haber aplicado de buena fe, pero an carecen de los conocimientos y / o experiencia requeridas por el empleador
Pgina631de670

TOGOF9.1
o personal evita que son capaces de llenar papeles Arquitectura ser pasado por alto, o no se identifican con las vacantes publicadas y por lo tanto ni siquiera aplicando Tiempo y costo para establecer una prctica de la arquitectura interna reducida: o Muchas empresas no tienen una prctica de la arquitectura interna debido a la complejidad de instalar uno, prefiriendo en lugar de simplemente entrevistar y contratar a personal de la arquitectura en un ad hoc base. o Al proporcionar definiciones de las habilidades de la arquitectura y los niveles de competencia requeridos del personal que vaya a realizar las diversas funciones definidas dentro de la arquitectura de TOGAF, el Skills Framework Architecture reduce enormemente el tiempo, el costo y el riesgo de la creacin de una prctica por primera vez, y evita "llantas de re-inventar". o Las empresas que ya tienen una prctica de la arquitectura interna son capaces de establecer normas para toda la empresa, pero an as experimentar dificultades como se indica ms arriba en la contratacin de personal o consultores atractivas, de fuentes externas, debido a la falta de uniformidad entre las distintas empresas. Al alinear su marco de competencias existente con las definiciones aceptadas en la industria proporcionados por The Open Group, una empresa puede simplificar en gran medida estos problemas. Reduccin del tiempo y el costo de implementar un estudio de arquitectura ayuda a reducir el tiempo, costo y riesgo de desarrollo global de la solucin: o Las empresas que no tienen una prctica de la arquitectura interna corren el riesgo de personal inadecuados est empleada o contratada, a travs de la culpa de nadie, ya pesar de todos los involucrados que actan de buena fe. El tiempo y costo resultantes penas superan con creces el tiempo y el costo de tener un estudio de arquitectura interior: Los gastos de personal se incrementan, a travs de la necesidad ocasional de volver a contratar o reasignar personal. An ms importante es el impacto adverso sobre el tiempo, costo y calidad de los sistemas de TI operacionales y los proyectos para lanzarlas, como resultado de malas asignaciones del personal.
52.4 Arquitectura Empresarial de rol y Habilidad Categoras

En esta seccin se describe el papel de un arquitecto de la empresa, las habilidades fundamentales que se requieren, y algunas disciplinas posibles en que un arquitecto de la empresa puede especializarse.
Pgina632de670

TOGOF9.1
TOGAF ofrece una empresa de arquitectura, y por lo tanto requiere de los negocios y los profesionales capacitados de TI para desarrollar la arquitectura de la empresa. El TOGAF Arquitectura Skills Framework proporciona una vista de los niveles de competencia para las funciones especficas dentro del equipo de arquitectura de la empresa. El marco define:
Los roles dentro de un rea de trabajo de arquitectura empresarial Las habilidades requeridas por esos roles La profundidad de los conocimientos necesarios para cumplir cada funcin con xito
El valor est en que proporciona un medio rpido para la identificacin de las habilidades y las lagunas. Aplicado con xito, el marco puede ser utilizado como una medida para:
El desarrollo del personal Asegurar que la persona correcta hace el trabajo adecuado
52.4.2 Roles TOGAF
Un equipo tpico de la arquitectura de emprender el desarrollo de una empresa de arquitectura como se describe en TOGAF comprendera las siguientes funciones:
Los miembros de la Junta de Arquitectura Arquitectura Patrocinador Arquitectura del Administrador Arquitectos para: o Enterprise Architecture (que para el propsito de las tablas que se muestran a continuacin se puede considerar como un superconjunto de negocios, datos, aplicaciones, y Arquitectura de Tecnologa) o Arquitectura de Negocios o Arquitectura de Datos o Arquitectura de aplicaciones o Tecnologa de la Arquitectura Programa y / o Jefes de Proyecto Diseador de TI Y muchos otros ...
Pgina633de670

TOGOF9.1
Las siguientes tablas muestran, para cada uno de estos roles, las habilidades requeridas y el nivel deseable de competencia en cada habilidad. De todas las funciones enumeradas anteriormente, el que necesita un anlisis particularmente detallado y definicin es, por supuesto, el papel central del arquitecto de la empresa. Como se explic anteriormente, "Arquitectura Empresarial" y "EA" son trminos que son muy utilizados pero muy mal definidos en la industria hoy en da, lo que denota una gran variedad de prcticas y habilidades aplicadas en una amplia variedad de dominios de la arquitectura. A menudo hay confusin entre el papel de un arquitecto y la de un diseador o constructor. Muchas de las habilidades requeridas por un arquitecto de la empresa tambin son requeridos por el diseador, que ofrece las soluciones. Aunque sus habilidades son complementarias, las de la diseadora son principalmente la tecnologa enfocada y traducen la arquitectura en componentes entregables. El inciso final por debajo, por tanto, explora en detalle las caractersticas genricas del papel de arquitecto de la empresa, as como los requisitos de habilidades clave, cualquiera que sea el dominio particular arquitectura (Arquitectura Empresarial, Arquitectura de Negocios, Arquitectura de datos, arquitectura de aplicaciones, Arquitectura de Tecnologa, etc.)
52.4.3 Categoras de Habilidades
El conjunto de habilidades del equipo TOGAF deber incluir las siguientes categoras principales de capacidades:
Competencias Genricas : - que comprende tpicamente de liderazgo, trabajo en equipo, habilidades interpersonales, etc Habilidades de Negocios y Mtodos : - que tpicamente comprenden casos de negocio, procesos de negocio, planificacin estratgica, etc Arquitectura Empresarial Habilidades : - que tpicamente comprende modelado, diseo de bloques de construccin, aplicaciones y diseo de papel, integracin de sistemas, etc Programa o Proyecto de Habilidades Directivas : - que tpicamente comprende la gestin del cambio empresarial, mtodos y herramientas de gestin de proyectos, etc IT Generales Conocimiento Habilidades : - que tpicamente comprende aplicaciones de corretaje, gestin de activos, planificacin de la migracin, SLAs, etc Tcnicas Habilidades de TI : - que tpicamente comprende la ingeniera de software, seguridad, intercambio de datos, gestin de datos, etc Entorno legal : - que tpicamente comprende las leyes de proteccin de datos, derecho contractual, derecho de contratacin, fraude, etc
Las tablas siguientes ilustran cada una de estas categoras de habilidades.

Pgina634de670

TOGOF9.1
Las siguientes tablas muestran, para cada una de estas habilidades, los papeles en los que sean pertinentes y del nivel deseable de competencia en cada habilidad.
52.4.4 Niveles de Competencia
El TOGAF Arquitectura Skills Framework identifica cuatro niveles de conocimiento o habilidad en cualquier rea:
52.5
Arquitectura Empresarial de rol y Habilidad Definiciones
52.5.1 Competencias Genricas
52.5.2NegocioHabilidadesyMtodos
Pgina635de670

TOGOF9.1 52.5.3 Arquitectura Empresarial Habilidades
52.5.4 Programa o Habilidades de Gestin de Proyectos
Pgina636de670

TOGOF9.1 52.5.5 TI Habilidades Conocimientos generales
52.5.6 Tcnicas Habilidades de TI
52.5.7 Entorno Legal
Pgina637de670

TOGOF9.1
52.6 Rol genrico y Habilidades de la EA

De todas las funciones enumeradas anteriormente, el que necesita un anlisis particularmente detallado y definicin es, por supuesto, el papel central del arquitecto de la empresa. Como se explic anteriormente, "Arquitectura Empresarial" y "EA" son trminos que son muy utilizados pero muy mal definidos en la industria hoy en da, lo que denota una gran variedad de prcticas y habilidades aplicadas en una amplia variedad de dominios de la arquitectura. Por tanto, esta seccin explora en detalle las caractersticas genricas del papel de arquitecto de la empresa, y algunos de los requisitos de habilidades clave, cualquiera que sea el dominio particular arquitectura (Arquitectura Empresarial, Arquitectura de Negocios, Arquitectura de datos, arquitectura de aplicaciones, Arquitectura de Tecnologa, etc.)
52.6.1 Rol Genrico
Arquitectos empresariales son visionarios, entrenadores, jefes de equipo, de empresa a tcnico enlaces, informticos y expertos de la industria. La siguiente es una descripcin de trabajo efectiva para un arquitecto de la empresa:
"El arquitecto tiene la responsabilidad de asegurar la integridad (aptitud para el propsito) de la arquitectura, en trminos de abordar adecuadamente todos los intereses pertinentes de las partes interesadas, y la integridad de la arquitectura, en cuanto a la conexin de todos los diferentes puntos de vista para entre ellos, la conciliacin de forma satisfactoria las preocupaciones conflictivas de los diferentes grupos de inters, y que muestra las compensaciones hechas en hacerlo (como entre la seguridad y el rendimiento, por ejemplo).
La eleccin de qu puntos de vista particulares de arquitectura para desarrollar es una de las decisiones clave que la empresa arquitecto tiene que hacer. La eleccin tiene que ser limitada por consideraciones de orden prctico, y por el principio de la aptitud para el propsito (es decir, la arquitectura debe ser desarrollado slo hasta el punto en el que es apto para el propsito, y no reiter el infinito como un ejercicio acadmico). " El papel de la empresa arquitecto es ms parecido al de un planificador de la ciudad que la de un arquitecto del edificio, y el producto de la empresa arquitecto se caracteriza mejor como una comunidad planificada (en oposicin a una expansin urbana sin restricciones), y no como un edificio bien diseado o un conjunto de edificios. Un arquitecto de la empresa no crea la visin tcnica de la empresa, pero tiene relaciones profesionales con los ejecutivos de la empresa para reunir y articular la visin tcnica, y
Pgina638de670

TOGOF9.1
para elaborar el plan estratgico para darse cuenta. Este plan siempre est relacionada con los planes de negocio de la empresa, y las decisiones de diseo son trazables al plan de negocios. El plan estratgico de la empresa arquitecto est ligada al proceso de gobernanza arquitectura (ver 50. Arquitectura de Gobierno ) para la empresa, por lo que las decisiones de diseo no sean eludidas por conveniencia tctica. El arquitecto de la empresa produce documentacin de las decisiones de diseo para los equipos de desarrollo de aplicaciones o equipos de aplicacin de productos para su ejecucin. Un arquitecto est involucrado en todo el proceso; empezando con el trabajo con el cliente para entender las necesidades reales, en oposicin a sus deseos, y a continuacin, durante todo el proceso de traducir esas necesidades en capacidades verificadas para satisfacer las necesidades. Adems, el arquitecto puede presentar diferentes modelos para el cliente que se comunican cmo pueden cumplirse esas necesidades, y por lo tanto es un participante esencial en el proceso de venta consultiva. Sin embargo, el arquitecto no es el constructor, y deber permanecer en un nivel de abstraccin necesario para garantizar que no se interpongan en el camino de la aplicacin prctica. El siguiente extracto de El Arte de Sistemas Architecting ilustra esta idea:
"Es la responsabilidad del arquitecto de conocer y concentrarse en los pocos detalles e interfaces crticos que realmente importan, y no sobrecargarse con el resto."
El enfoque del arquitecto es en la comprensin de lo que se necesita para satisfacer al cliente, donde el valor cualitativo se utiliza ms de las medidas cuantitativas. El arquitecto utiliza ms habilidades inductivas que las habilidades deductivas de la constructora. Las ofertas de arquitecto ms con las directrices, en lugar de las normas que los constructores utilizan como una necesidad. Tambin debe quedar claro que el papel de un arquitecto puede ser realizado por un ingeniero. Un objetivo de este documento es describir el papel - lo que debe hacerse, sin importar el que la ejecuta. Por lo tanto, el papel del arquitecto se puede resumir como a:
Conocer e interpretar los requisitos : investigar para obtener informacin, escuchar a la informacin, influir en las personas, facilitar la creacin de consenso, sintetizar y traducir las ideas en acciones concretas requisitos, articular esas ideas a los dems. Identificar el uso o propsito, las limitaciones, riesgos, etc El arquitecto participa en el descubrimiento y la documentacin de los escenarios de negocio de los clientes que estn impulsando la
Pgina639de670

TOGOF9.1
solucin. El arquitecto es el responsable de los requisitos de la comprensin y el entendimiento de que los requisitos encarna en la especificacin de la arquitectura. Crear un modelo de utilidad : tomar los requisitos y desarrollar modelos bien formulados de los componentes de la solucin, aumentando los modelos segn sea necesario para adaptarse a todas las circunstancias. Mostrar mltiples puntos de vista a travs de los modelos para comunicar las ideas de manera efectiva. El arquitecto es responsable de la integridad de la arquitectura global y el mantenimiento de la visin de la oferta desde una perspectiva arquitectnica. El arquitecto tambin garantiza oportunidades de apalancamiento se identifican, utilizando bloques de construccin, y es un enlace entre los grupos funcionales (sobre todo de desarrollo y comercializacin) para garantizar que las oportunidades de apalancamiento se realicen. El arquitecto proporciona y mantiene estos modelos como un marco para entender el dominio (s) del trabajo de desarrollo, guiando a lo que debe hacerse dentro de la organizacin o fuera de la organizacin. El arquitecto debe representar la opinin de la organizacin de la arquitectura mediante la comprensin de todos los componentes necesarios del negocio. Validar, refinar y expandir el modelo : verificar las hiptesis, traer expertos en la materia, etc con el fin de mejorar el modelo y definir con mayor precisin, aadiendo nuevas ideas necesarias para que el resultado sea ms flexible y ms estrechamente ligado a la corriente y requisitos previstos. El arquitecto, adems, debe evaluar el valor de los desarrollos de soluciones de mejora que emanan del trabajo de campo y de incorporarlos en los modelos de arquitectura, segn corresponda. Gestione la arquitectura : un seguimiento continuo de los modelos y actualizarlos si es necesario para mostrar los cambios, adiciones y alteraciones.Representar a la arquitectura y problemas durante el desarrollo y toma los puntos del programa. El arquitecto es un "agente de cambio", lo que supone que la necesidad de la puesta en prctica de la arquitectura. A travs de este ciclo de desarrollo, el arquitecto promueve continuamente la puesta en comn de los clientes, la arquitectura y la informacin tcnica entre las organizaciones.
52.6.2 Caracterizacin en trminos de la Empresa Continuum
Bajo ciertas circunstancias, la complejidad de una solucin puede requerir arquitectos adicionales para apoyar el esfuerzo de la arquitectura. Las diferentes categoras de arquitectos se describen a continuacin, pero como son arquitectos, todos ellos realizan las tareas descritas anteriormente. Cualquier combinacin de empresas, soluciones empresariales y soluciones de arquitectos puede ser utilizada, como un equipo. En estos casos, cada miembro puede tener un enfoque especfico, si las funciones y responsabilidades que no son especficas, dentro de las fases del proceso de desarrollo. En los casos en que sea necesario un equipo de arquitectos, un arquitecto de la empresa principal debe ser asignado para gestionar y dirigir a los miembros del equipo.
El Enterprise Architect tiene la responsabilidad para el diseo arquitectnico y la documentacin en un paisaje y tcnico nivel del modelo de referencia. El Enterprise Architect a menudo conduce a un grupo de los Arquitectos del segmento y / o arquitectos de soluciones relacionadas con un programa determinado. El enfoque de la EA est en funciones de negocios a nivel de empresa necesarios.
Pgina640de670

TOGOF9.1
El Arquitecto segmento tiene la responsabilidad para el diseo arquitectnico y la documentacin de los problemas o las organizaciones empresariales especficas. Un Arquitecto Segmento re-utiliza la salida de todos los otros arquitectos, unindose a las soluciones tcnicas detalladas en el paisaje arquitectnico general. El enfoque del Arquitecto segmento est en las soluciones de negocio a nivel de empresa en un determinado dominio, tales como finanzas, recursos humanos, ventas, etc El arquitecto de la solucin tiene la responsabilidad para el diseo arquitectnico y la documentacin en un sistema o subsistema, como la gestin o la seguridad. Un arquitecto de la solucin puede blindar el Enterprise Architect / Segmento de los detalles innecesarios de los sistemas, productos y / o tecnologas.El enfoque del arquitecto de soluciones en las soluciones de tecnologa de sistema; Por ejemplo, un componente de una solucin tal como el almacenamiento de datos de la empresa.
52.6.3 Caractersticas clave de un Enterprise Architect

52.6.3.1 habilidades y experiencia en la produccin de diseos
Un arquitecto de la empresa deben ser competentes en las tcnicas que intervienen en la produccin de diseos de sistemas complejos, incluidos los requisitos de descubrimiento y el anlisis, la formulacin de solucin contexto, la identificacin de alternativas de solucin y su evaluacin, seleccin de tecnologa, y la configuracin de diseo.
52.6.3.2 Amplia Manga Tcnica, con la profundidad tcnica en uno o unos pocos Disciplinas
Un arquitecto de la empresa debe poseer una extensa amplitud tcnica a travs de la experiencia en la industria de TI. Esta amplitud debe ser en reas de desarrollo y despliegue de aplicaciones, y en las reas de creacin y mantenimiento de la infraestructura para apoyar el entorno de aplicaciones complejas. Entornos de TI actuales son heterogneos por naturaleza, y el arquitecto de la empresa con experiencia tendrn habilidades a travs de mltiples plataformas, incluyendo los sistemas distribuidos y entornos de mainframe tradicionales. Arquitectos empresariales tendrn, como resultado de su carrera, las habilidades en al menos una disciplina que se considera que est en el nivel de un experto en la materia.
52.6.3.3 Mtodo Enfoque determinado de Ejecucin
Los arquitectos de la empresa se acercan a su trabajo a travs del uso constante de los mtodos de diseo reconocidas, como la Arquitectura Mtodo de Desarrollo TOGAF (ADM). Los arquitectos de la empresa deben tener conocimiento de trabajo de ms de un mtodo de diseo y ser confortables partes Implementacin de mtodos apropiados para la situacin en la que estn trabajando trabajando. Esto debe considerarse en el cuerpo de trabajo de diseo de la empresa arquitecto ha producido a travs de uso exitoso repetida de ms de un mtodo de diseo. La habilidad en el uso la metodologa est en saber qu partes de los mtodos a utilizar en una situacin dada, y qu mtodos no utilizar.
52.6.3.4 Completa Experiencia del Alcance del Proyecto
Pgina641de670

TOGOF9.1
Mientras los arquitectos empresariales son responsables del diseo y de la mano-off del proyecto a los ejecutores, es vital que tengan experiencia en todos los aspectos de un proyecto, desde el diseo hasta el desarrollo, prueba, implementacin y produccin. Este mbito de aplicacin de la experiencia servir para mantener los arquitectos empresariales basadas en la nocin de la aptitud para el propsito y el carcter prctico de la implementacin del sistema. El impacto de la experiencia completa del alcance del proyecto debe liderar el arquitecto empresarial para tomar mejores decisiones de diseo, e informar mejor a los intercambios realizados en esas decisiones.
52.6.3.5 Liderazgo
Comunicacin y trabajo en equipo son clave para el papel exitoso de la empresa arquitecto. La mezcla de buena habilidad tcnica y la capacidad de conducir son cruciales para el trabajo. El arquitecto de la empresa debe ser visto como un lder en la empresa mediante la organizacin de TI, los clientes que sirven, y la gestin.
52.6.3.6 Habilidades Personales y Profesionales
El arquitecto de la empresa debe tener las comunicaciones slidas y habilidades de relacin. Una de las principales tareas de la empresa arquitecto es comunicar informacin tcnica compleja para todos los interesados del proyecto, incluidos los que no tienen una formacin tcnica. Tambin se requiere que la negociacin fuerte y habilidades de resolucin de problemas. El arquitecto de la empresa debe trabajar con el equipo de gestin del proyecto para tomar decisiones de manera oportuna para mantener los proyectos en marcha.
52.6.3.7 habilidades y experiencia en una o ms industrias
La habilidad de la Industria y la experiencia harn que la tarea de reunir los requisitos y decidir las prioridades ms fcil y efectivo para la EA. Los arquitectos de la empresa deben entender los procesos de negocio de la empresa en la que trabajan, y cmo esos procesos trabajan con otras empresas de pares en la industria.Tambin debe ser capaz de detectar las principales tendencias y procesos viciados correctas, dando a la organizacin de TI la capacidad de dirigir la empresa, no slo responder a las solicitudes. La misin de la empresa es arquitecto liderazgo tcnico estratgico.
52.7 Conclusiones
El TOGAF Arquitectura Skills Framework proporciona una evaluacin de las habilidades necesarias para ofrecer una exitosa arquitectura empresarial.
Pgina642de670

TOGOF9.1
Se espera que la prestacin de este Skills Framework Architecture le ayudar a reducir el tiempo, costo y riesgo involucrado en la formacin, la contratacin y la gestin de profesionales de la arquitectura de TI, y al mismo tiempo permitir y animar a ms organizaciones para instituir una estructura de funcionamiento interno de TI , es de esperar en base a (o por lo menos apalancamiento) la funcin y las definiciones de habilidad siempre.
Pgina643de670

TOGOF9.1
Apndices
Pgina644de670

TOGOF9.1
A. Glosario de Definiciones complementarias

Este apndice contiene definiciones adicionales para complementar las definiciones contenidas en el 3. Definiciones .
A.1 de control de acceso (AC)

Un servicio de seguridad que garantiza que slo los usuarios con los derechos correctos puede acceder a determinados dispositivos, aplicaciones o datos.
A.2 Ada
Un lenguaje de programacin de alto nivel desarrollado por el Departamento de Defensa de EE.UU. ( DoD ) y ampliamente utilizado en los pases del Departamento de Defensa y de la OTAN. Se utiliza para el procesamiento en tiempo real, es de naturaleza modular, e incluye caractersticas orientadas a objetos.
Componente de aplicacin A.3

Una encapsulacin de funcionalidad de la aplicacin alineado con estructura de ejecucin. Por ejemplo, una aplicacin de procesamiento de solicitud de compra. Ver tambin A.50 Lgico componente de aplicacin y A.63 Fsica componente de aplicacin .
Software de Aplicacin A.4

Entidades de software que tienen un fin comercial especfico.
A.5 Disponibilidad
En el contexto de los sistemas de TI, la probabilidad de que las capacidades funcionales del sistema estn listos para su uso por un usuario en cualquier momento, en donde se considera todos los tiempos, incluyendo operaciones, reparacin, administracin y tiempo de logstica. La disponibilidad se define adems por categora sistema tanto para las operaciones de rutina y prioritarios.
Procesamiento por lotes A.6
Pgina645de670

TOGOF9.1
Procesamiento de los datos o la realizacin de trabajos acumulados con antelacin, de tal manera que cada acumulacin as formado se procesa o se lleva a cabo en la misma computadora funcione.
A.7 Business System

Hardware, software, declaraciones de polticas, procesos, actividades, normas, y las personas que en conjunto implementan una funcin de negocios.
Catlogo A.8
Una lista estructurada de los productos arquitectnicos de un tipo similar, que se utiliza como referencia. Por ejemplo, a las normas de tecnologa catlogo o un portafolio de aplicaciones.
A.9 Cliente
Un componente de la aplicacin que solicita los servicios de un servidor.
A.10 COBIT
Es el acrnimo de Objetivos de Control para la Informacin y Tecnologas Relacionadas, creado por la Asociacin de Sistemas de Informacin de Auditora y Control (ISACA) y el IT Governance Institute (ITGI), que proporciona un conjunto de mejores prcticas recomendadas para la gestin / administracin de los sistemas de informacin y tecnologa .
A.11 Red de Comunicaciones

Un conjunto de productos, conceptos y servicios que permiten la conexin de los sistemas informticos con el fin de transmitir datos y otras formas (por ejemplo, voz y video) entre los sistemas.
A.12 Comunicaciones Nodo

Un nodo que es ya sea interna a la red de comunicaciones (por ejemplo, enrutadores, puentes, o repetidores) o situado entre el dispositivo final y la red de comunicaciones para operar como una puerta de enlace.
Sistema A.13 Comunicaciones

Un conjunto de activos (medios de transmisin, los nodos de conmutacin, interfaces y dispositivos de control) que establecer vnculos entre usuarios y dispositivos.
Pgina646de670

TOGOF9.1
A.14 de aplicaciones compuestas

Un componente de aplicacin que se crea mediante la composicin de otras aplicaciones atmicas o compuestos.
A.15 Configuration Management

Una disciplina aplicando direccin tcnica y administrativa y la vigilancia de:
Identificar y documentar las caractersticas funcionales y fsicas de un elemento de configuracin Los cambios de control a esas caractersticas Registrar y comunicar los cambios en el procesamiento y el estado de aplicacin
Adems, la gestin de la configuracin de la arquitectura de la prctica de la empresa (de propiedad intelectual) los activos y lneas de base y el control de cambio a lo largo de esos activos.
A.16 Servicio de conectividad

Un rea de servicio de la entidad ambiente externo del modelo de referencia tcnica (TRM) que proporciona conectividad de extremo a extremo para las comunicaciones a travs de tres niveles de transporte (global, regional y local). Proporciona servicios generales y especficos de la aplicacin a finales de plataforma dispositivos.
Contrato A.17
Un acuerdo entre un consumidor de servicios y un proveedor de servicios que establece los parmetros funcionales y no funcionales para la interaccin.
Control A.18
Un paso de toma de decisiones con el acompaamiento de la lgica de decisin utilizado para determinar el enfoque de ejecucin de un proceso o para asegurar que un proceso cumple con los criterios de gobierno. Por ejemplo, un control de cierre de sesin en el proceso de tramitacin de solicitud de compra que comprueba si el valor total de la solicitud est dentro de los lmites de sesin fuera de la solicitante, o si necesita una escalada a la autoridad superior.
A.19 CxO
El oficial en jefe dentro de una funcin particular de la empresa; por ejemplo, el Director Ejecutivo, Director Financiero, Director de Informacin, Director de Tecnologa.
Pgina647de670

TOGOF9.1
Diccionario de datos A.20

Un tipo especializado de base de datos que contiene metadatos; un repositorio de informacin que describe las caractersticas de los datos que se utilizan para disear, monitorear, documentar, proteger y controlar los datos en los sistemas de informacin y bases de datos; un sistema de aplicacin de apoyo a la definicin y gestin de metadatos de la base de datos.
Elemento de datos A.21

Una unidad bsica de informacin que tiene un significado y que puede tener subcategoras (elementos de datos) de las unidades y valores distintos.
A.22 Entity Data

Una encapsulacin de datos que es reconocido por un experto de dominio de negocios como una cosa. entidades de datos lgicos se puede atar a las aplicaciones, repositorios y servicios y puede ser estructurada de acuerdo a consideraciones de implementacin.
A.23 de datos de servicio de intercambio

Un servicio de la entidad de plataforma del modelo de referencia tcnica (TRM) que proporciona apoyo especializado para el intercambio de datos entre aplicaciones en el mismo o en diferentes plataformas.
A.24 Servicio de Gestin de Datos

Un servicio de la entidad de plataforma del modelo de referencia tcnica (TRM) que brinda apoyo a la gestin, el almacenamiento, el acceso y la manipulacin de los datos en una base de datos.
Base de datos A.25

Una coleccin estructurada u organizada de entidades de datos, la cual se puede acceder por un ordenador.
A.26 Sistema de Gestin de Base de Datos

Un programa de aplicacin de ordenador que tenga acceso o manipula la base de datos.
Servicio de directorio A.27
Pgina648de670

TOGOF9.1
Un componente de tecnologa que ofrece servicios de localizacin que se encuentran la ubicacin de un servicio, o la ubicacin de los datos, o la traduccin de un nombre comn en una direccin especfica de la red. Es anlogo a los libros de telfono y se puede implementar en esquemas centralizados o distribuidos.
Base de datos distribuida A.28

1. Una base de datos que no se almacena en una ubicacin central, pero se dispersa a travs de una red de ordenadores interconectados. 2. Una base de datos bajo el control total de un sistema de gestin de base de datos central
(DBMS), pero cuyos dispositivos de almacenamiento no estn adscritos a un mismo procesador.
3. Una base de datos que se encuentra fsicamente en dos o ms lugares distintos.
A.29 Conductor
Una condicin externa o interna que motiva a la organizacin a definir sus metas. Un ejemplo de un controlador externo es un cambio en la normativa que regula el cumplimiento o que, por ejemplo, requieren cambios en la forma en que una organizacin opera; es decir, la Ley Sarbanes-Oxley en los EE.UU..
A.30 para el usuario final

Persona que, en ltima instancia utiliza la aplicacin informtica o salida.
Planificacin de recursos empresariales A.31 (PIR)

Una suite completa de aplicaciones integradas que soportan las principales funciones de apoyo empresarial de una organizacin; por ejemplo, Financiera (AP / AR / GL), recursos humanos, nmina, inventario, procesamiento de pedidos y facturacin, Compras, Logstica, Produccin, etc
A.32 Evento
Un cambio de estado de la organizacin que desencadena eventos de procesamiento puede provenir de dentro o fuera de la organizacin y puede ser resuelto dentro o fuera de la organizacin.
A.33 Interfaz Ambiente Externo (EEI)

La interfaz que soporta la transferencia de informacin entre la plataforma de aplicacin y el ambiente externo.
Pgina649de670

TOGOF9.1
A.34 FORTRAN
Es el acrnimo de traductor frmula, que es un lenguaje de programacin de alto nivel utilizado ampliamente en aplicaciones cientficas y de ingeniera.
A.35 Descomposicin Funcional

Una jerarqua de las funciones de una empresa u organizacin.
A.36 Meta
Una declaracin de alto nivel de la intencin o la direccin de una organizacin. Normalmente se utiliza para medir el xito de una organizacin.
Directriz A.37
Un documento de arquitectura que ofrece orientacin sobre el mejor modo de llevar a cabo actividades de diseo o de implementacin.
A.38 Hardware
La infraestructura fsica necesaria para ejecutar el software; por ejemplo, servidores, estaciones de trabajo, equipos de red, etc
A.39 Interfaz Hombre-Computadora (HCI)

Hardware y software que permite el intercambio de informacin entre el usuario y el ordenador.
A.40 Informacin del dominio

Agrupacin de la informacin (o entidades de datos) mediante una serie de criterios tales como la clasificacin de seguridad, propiedad, ubicacin, etc En el contexto de la seguridad, los dominios de informacin se definen como un conjunto de usuarios, sus objetos de informacin, y una poltica de seguridad.
Sistema de Informacin A.41 (IS)

La porcin de la computadora (o IT) basado en un sistema de negocio.
Servicio de Sistema de Informacin A.42
Pgina650de670

TOGOF9.1
Los elementos automticos de un servicio empresarial. Hay un servicio de sistema de informacin pueden ofrecer o apoyar la totalidad o parte de uno o varios servicios de oficina.
Interaccin A.43
Una relacin entre los bloques de construccin de arquitectura (es decir, servicios o componentes) que encarna la comunicacin o utilizacin.
A.44 Modelo de Interaccin

Una vista arquitectnico, catlogo, o una matriz que muestra un tipo particular de interaccin. Por ejemplo, un diagrama que muestra la integracin de aplicaciones.
A.45 Interface
Interconexin e interrelaciones entre, por ejemplo, personas, sistemas, dispositivos, aplicaciones o el usuario y una aplicacin o dispositivo.
A.46 ITIL
Es el acrnimo de Information Technology Infrastructure Library, que proporciona un conjunto de mejores prcticas recomendadas para la gestin / administracin de los sistemas de informacin y tecnologa.
A.47 indicador clave de rendimiento (KPI)

Una forma de cuantificar el desempeo del negocio o proyecto.
A.48 Ciclo de Vida

El perodo de tiempo que comienza cuando un sistema est concebido y termina cuando el sistema ya no est disponible para su uso.
A.49 Ubicacin
Un lugar donde la actividad empresarial se lleva a cabo y se puede descomponer jerrquicamente.
Componente de aplicacin A.50 Lgico
Pgina651de670

TOGOF9.1
Una encapsulacin de funcionalidad de la aplicacin que es independiente de una implementacin particular. Por ejemplo, la clasificacin de todas las aplicaciones de procesamiento de solicitud de compra implementados en una empresa.
Componente de datos A.51 Lgico

Una zona de frontera que encapsula las entidades de datos relacionados para formar una ubicacin lgica que se celebrar. Por ejemplo, la informacin de aprovisionamiento externo.
A.52 Lgico Componente Tecnologa

Una encapsulacin de la infraestructura de tecnologa que es independiente de un producto en particular. Una clase de producto de tecnologa. Por ejemplo, el software de gestin de la cadena de suministro, como parte de un sistema de planificacin de recursos empresariales (ERP) suite o una solicitud de compra Commercial Off-The-Shelf (COTS) servicios de empresa de procesamiento.
A.53 Administracin de Programas Exitosos (MSP)

Una metodologa de mejores prcticas para la gestin del programa, desarrollado por la Oficina del Reino Unido de Comercio Gubernamental (OGC).
Matrix A.54
Un formato para mostrar la relacin entre dos (o ms) elementos arquitectnicos en un formato de cuadrcula.
A.55 Medida
Un indicador o factor que se puede controlar, por lo general en forma permanente, para determinar el xito o el alineamiento con los objetivos y metas.
A.56 Metaview
A MetaView acta como un patrn o plantilla de la vista, desde el que desarrollar puntos de vista individuales. A MetaView establece los propsitos y audiencias para una vista, las formas en que se documenta la vista (por ejemplo, para el modelado visual), y las formas en las que se utiliza (por ejemplo, para el anlisis). Ver tambin 3.76 Punto de vista en 3. Definiciones .
A.57 Servicio Multimedia

Pgina652de670

TOGOF9.1
Un servicio del modelo de referencia tcnica (TRM) que proporciona la capacidad para manipular y administrar los productos de informacin que consta de texto, grficos, imgenes, vdeo y audio.
A.58 Especificaciones Abiertas

Especificaciones pblicas que son mantenidos por un proceso de consenso abierto y pblico para dar cabida a las nuevas tecnologas a travs del tiempo y que son consistentes con las normas internacionales.
A.59 Sistema Abierto

Un sistema que implementa las especificaciones abiertas suficientes para interfaces, servicios y formatos de apoyo que permitan la aplicacin de software diseada correctamente:
Para ser portado con cambios mnimos a travs de una amplia gama de sistemas Para interoperar con otras aplicaciones en sistemas locales y remotos Para interactuar con los usuarios en un estilo que facilita la portabilidad de usuario
Gobernanza Operacional A.60

Gobernabilidad Operacional analiza el desempeo operacional de los sistemas frente a los niveles contratados rendimiento, la definicin de los niveles de rendimiento operativo y la implementacin de sistemas que garanticen el funcionamiento eficaz de los sistemas. Ver tambin 3.39 Gobernanza en 3. Definiciones .
A.61 Servicio del Sistema Operativo

Un servicio bsico de la entidad plataforma de aplicacin del Modelo de Referencia Tcnica (TRM) que se necesita para operar y administrar la plataforma de aplicaciones y proporcionar una interfaz entre el software de aplicacin y la plataforma (por ejemplo, gestin de archivos, entrada / salida, colas de impresin ).
Servicios A.62 Packaged

Servicios que se adquieren en el mercado de un Comercial Off-The-Shelf (COTS) de los proveedores, en lugar de ser construido a travs del cdigo de construccin.
A.63 Fsica componente de aplicacin

Pgina653de670

TOGOF9.1
Una aplicacin, mdulo de aplicacin, servicios de aplicaciones, u otro componente de despliegue de la funcionalidad. Por ejemplo, una instancia de una Commercial Off-TheShelf (COTS) Planificacin de recursos empresariales (ERP) de alimentacin configurado y desplegado la aplicacin de gestin de la cadena.
A.64 Componente Fsico de Datos

Una zona de frontera que encapsula las entidades de datos relacionados para formar un lugar fsico que se celebrar. Por ejemplo, un objeto de negocio de la orden de compra, que comprende encabezado de la orden de compra y nodos de objetos de negocios artculo.
A.65 Tecnologa Componente Fsico

Un producto de infraestructura de tecnologa o la tecnologa instancia de producto infraestructura. Por ejemplo, un determinado modelo de una solucin comercial Off-TheShelf (COTS), o de una marca especfica y la versin del servidor.
A.66 Portabilidad
1. La facilidad con la que un sistema, componente, datos, o el usuario pueden ser transferidos de un hardware o entorno de software a otro. 2. Una mtrica de calidad que se puede utilizar para medir el esfuerzo relativo para
transportar el software para su uso en otro entorno o para convertir de software para su uso en otro entorno operativo, la configuracin de hardware, o entorno de sistema de software.
A.67 Portafolio
El conjunto completo de las actividades de cambio o sistemas que existen dentro de la organizacin o parte de la organizacin. Por ejemplo, la cartera de aplicaciones y la cartera de proyectos.
A.68 PRINCE2
Es el acrnimo de proyectos en ambientes controlados, que es un mtodo de gestin de proyectos estndar.
Proceso A.69
Un proceso representa una secuencia de actividades que en conjunto logran un resultado determinado, puede descomponerse en sub-procesos, y puede mostrar el funcionamiento de una funcin o servicio (en el siguiente nivel de detalle). Los procesos tambin pueden ser utilizados para conectar o componer organizaciones, funciones, servicios y procesos.
Pgina654de670

TOGOF9.1
A.70 Producto
La salida generada por el negocio. El producto de negocios de la ejecucin de un proceso.
A.71 Perfil
Un conjunto de una o ms normas bsicas y, en su caso, la identificacin de las anteriores clases, subconjuntos, opciones y parmetros de esas normas bsicas, necesarias para el cumplimiento de una funcin determinada.
A.72 Profiling
La identificacin de las normas y caractersticas de un sistema en particular.
Programa A.73
Un conjunto coordinado de proyectos de cambio que ofrecen el beneficio empresarial a la organizacin.
A.74 Proyecto
Un proyecto de cambio nico, que ofrece el beneficio empresarial a la organizacin.
Gestin de Riesgos A.75

La gestin de los riesgos y problemas que pueden amenazar el xito de la estructura de funcionamiento de la empresa y su capacidad de cumplir es la visin, metas y objetivos, y, sobre todo, de su prestacin de servicios.
Nota: La gestin de riesgos se describe en laParteIII , 31.GestindeRiesgos .
A.76 Escalabilidad
La capacidad de usar el mismo software de aplicacin en muchas clases diferentes de plataformas de hardware / software de PC para-super computadoras (extiende el concepto de portabilidad). La capacidad de crecer para dar cabida a mayores cargas de trabajo.
A.77 Seguridad
Servicios que protegen los datos, garantizando su confidencialidad, disponibilidad e integridad.
Pgina655de670

TOGOF9.1
A.78 Servidor
Un componente de aplicacin que responde a las peticiones de un cliente.
Servicio A.79
Una representacin lgica de una actividad de negocio repetible que tiene un resultado especfico. Un servicio es autnomo, puede estar compuesto por otros servicios, y es un "recuadro negro" a sus consumidores. Algunos ejemplos son "verificacin de crdito del cliente", "proporcionar datos meteorolgicos", y "consolidar los informes de perforacin".
A.80 Servicio Calidad

Una configuracin preestablecida de atributos no funcionales que pueden ser asignadas a un servicio o contrato de servicio.
A.81 INTELIGENTE
Es el acrnimo de especficos, medibles, alcanzables, realistas y de duracin determinada, que es un enfoque para asegurar que las metas y objetivos se establecen de manera que se puede lograr y medir.
Gestin de Proveedores A.82

La gestin de los proveedores de productos y servicios para la prctica de la arquitectura de la empresa de comn acuerdo con las actividades de adquisicin de empresas ms grandes.
Sistema A.83
Una coleccin de componentes organizados para cumplir una funcin especfica o un conjunto de funciones (fuente: ISO / IEC 42010:2007).
Sistema A.84 y el Servicio de Gestin de Red

Un servicio de la entidad de plataforma de aplicacin del Modelo de Referencia Tcnica (TRM), que proporciona la administracin del sistema de informacin global cruzada categora. Estos servicios incluyen la gestin de la informacin, los procesadores, redes, configuraciones, contabilidad y rendimiento.
A.85 Sistema Stakeholder

Un individuo, equipo u organizacin (o clases de los mismos) con intereses en, o preocupaciones con respecto a un sistema (fuente: ISO / IEC 42010:2007).
Pgina656de670

TOGOF9.1
A.86 Tecnologa Componente

Una encapsulacin de infraestructura tecnolgica que representa una clase de producto de la tecnologa o producto de tecnologa especfica.
A.87 Perodo de tiempo

El plazo durante el cual el impacto potencial se va a medir.
A.88 Transaccin
La interaccin entre un usuario y un ordenador en el que el usuario introduce una orden para recibir un resultado especfico de la computadora.
Transaccin Secuencia A.89

Orden de las operaciones necesarias para lograr los resultados deseados.
A.90 Use-Case
Una vista de la organizacin, aplicacin o funcionalidad del producto que ilustra las capacidades en contexto con el usuario de esa capacidad.
A.91 usuario
1. Cualquier persona, organizacin o unidad funcional que utiliza los servicios de un sistema de procesamiento de informacin. 2. En un lenguaje de esquema conceptual, cualquier persona o cualquier cosa que puede emitir o recibir rdenes y mensajes hacia o desde el sistema de informacin.
A.92 Servicio Interfaz de usuario

Un servicio de la entidad de plataforma de aplicacin del Modelo de Referencia Tcnica (TRM) que soporta la interaccin directa hombre-mquina mediante el control del medio ambiente en el que los usuarios interactan con las aplicaciones.
Pgina657de670

TOGOF9.1
B. Abreviaturas
ABB Arquitectura Bloque de construccin Corriente alterna Control de Acceso ACL Lista de Control de Acceso ACMM Arquitectura Capability Maturity Model ACSE Elemento de servicio de control de asociacin ADM Arquitectura Mtodo de Desarrollo ANSI American National Standards Institute API Interface Application Platform ARTES Asociacin de Estndares de Tecnologa Retail BMM Motivacin Modelo de Negocio BPM Gestin de Procesos de Negocio BPMN Business Process Modeling Notation
Pgina658de670

TOGOF9.1
BTEP El Programa Canadiense Enablement Transformacin Empresas Gobierno CAB Comit de Cambios CCITT Comit Consultivo sobre Telgrafos y Telfonos, ahora conocido como la Unin Internacional de Telecomunicaciones (UIT) CI Elementos de Configuracin CIPR Proceso Central de Informacin CM Gestin de la Configuracin CMIP Protocolo de Informacin de Gestin Comn CMIS Gestin de la Informacin del Servicio Comn CMM Modelos de Madurez de Capacidad CMMI Capability Maturity Model Integration CN Red de Comunicaciones COBIT Objetivos de Control para la Informacin y Tecnologas Relacionadas CODASYL Conferencia sobre Sistemas de Datos de Idiomas CORBA
Pgina659de670

TOGOF9.1
Common Object Request Broker Architecture COTS Aplicaciones Comercial Off-The-Shelf CRM Customer Relationship Management CRUD Crear / Leer / Actualizar / Eliminar CSF Factor Clave de xito DAI Data Access Interface DBA Database Administrator DBMS Sistema de Gestin de Base de Datos DCE Distributed Computing Environment DDL Data Definition Language DISA Departamento de Defensa de la Agencia de Sistemas de Informacin de EE.UU. DMF Utilidad de gestin de datos DML Manipulacin de datos Idioma DMTF Distributed Management Task Force
Pgina660de670

TOGOF9.1
DNS Sistema de nombres de dominio DdC Departamento de Comercio de EE.UU. DoD Departamento de Defensa de EE.UU. DoDAF Departamento de Defensa de Arquitectura de Marco DRDA Distributed Relational Database Architecture EA Arquitectura Empresarial EAI Integracin de Aplicaciones Empresariales EDI Intercambio Electrnico de Datos EEI Interfaz Ambiente Externo ERP Planificacin de Recursos Empresariales ES Fin del sistema ESB Enterprise Service Bus ETL Extraer, Transformar, Cargar FEAF
Pgina661de670

TOGOF9.1
Federal Enterprise Architecture Framework FICO Fair Isaac Corporation FORTRAN Traductor FORmula FTE Equivalente a Tiempo Completo GOTS Gobierno aplicaciones Off-The-Shelf GUI Interfaz grfica de usuario HIPAA Ley de Responsabilidad de Seguro de Salud de Portabilidad y ICAM Fabricacin Asistida por Ordenador Integrado ICD Documento de Control de Interfaz ICOM Entradas, salidas, controles y mecanismos / Recursos IDEF Ayudado Integrated Computer Manufacturing (ICAM) Definicin IDL Interfaz de lenguaje de descripcin IEC Comisin Electrotcnica Internacional IEEE Instituto de Ingenieros Elctricos y Electrnicos
Pgina662de670

TOGOF9.1
III Infraestructura de Informacin Integrado III-RM Integrado de Informacin Infraestructura Modelo de Referencia IMS Sistema de Gestin de la Informacin ISA Information Systems Architecture ISACA Sistemas de Informacin Asociacin de Auditora y Control de ISACF Sistemas de Informacin de Auditora y Control Foundation ISAM Indexado Mtodo de acceso secuencial ISO Organizacin Internacional de Normalizacin Informtica Tecnologa de la Informacin ITGI IT Governance Institute ITIL Information Technology Infrastructure Library ITPMF IT Management Facility Portafolio UIT Unin Internacional de Telecomunicaciones JMS
Pgina663de670

TOGOF9.1
Java Message Service JVM Java Virtual Machine KPI Indicador clave de rendimiento LAN Red de rea Local LCS Sistema de Comunicacin Local LIPR Proceso de Informacin Local LSE Red local de abonado MAN Red de rea metropolitana MDA Model Driven Architecture MIB Bases de Informacin de Gestin MIS Sistemas de Informacin Gerencial MLS Multi-Nivel de Seguridad MTA Agente de transferencia de mensajes NASCIO Oficiales de la Asociacin Nacional de Estado Jefe de Informacin
Pgina664de670

TOGOF9.1
NIST Instituto Nacional de Estndares y Tecnologa OAG Abra Aplicaciones Group OAGIS Abra Aplicaciones Grupo de Integracin de Especificaciones ODBC Open Database Connectivity OCDE Organizacin para la Cooperacin y el Desarrollo OGC Oficina de Comercio Gubernamental del Reino Unido OLA Acuerdo de Nivel Operacional OMB Oficina de Administracin y Presupuesto OMG Object Management Group OODBMS Sistema de gestin de base de datos orientada a objetos ORB Object Request Broker OS Sistema Operativo OSE Abrir entorno del sistema OSI
Pgina665de670

TOGOF9.1
Interconexin de sistemas abiertos OSOA Arquitectura orientada a servicios P-CMM Gente Capability Maturity Model PDA Asistente Digital Personal PDF Formato de Documento Porttil PEX Extensin PHIGS al sistema X Window PHIGS Sistema Grfico Interactivo jerrquica del programador PMI Iniciativa de Gestin de Proyectos PMBOK Proyecto Organismo de Gestin del Conocimiento PRINCE Proyectos en ambientes controlados QoS Calidad de servicio RACI Responsable, Responsable, Consultado, Informado RAS Servicios de acceso remoto RDA Acceso base de datos remota
Pgina666de670

TOGOF9.1
RDBMS Relational Database Management System REA Recursos-Event-Agent RFC Solicitud para el Cambio RFI Solicitud de Informacin RFP Solicitud de Propuesta RFQ Solicitud de Cotizacin RM Modelo de Referencia RM-ODP Modelo de referencia ISO para el Procesamiento distribuido abierto RPC Llamada a procedimiento remoto RS Relay System SA-CMM Software de Adquisicin de Capability Maturity Model SBB Solucin Mdulo SCAMPI Estndar CMMI mtodo de valoracin para la Mejora de Procesos SDO
Pgina667de670

TOGOF9.1
Service Data Objects SEI Instituto de Ingeniera de Software SGML Standard Generalized Markup Language SIB Normas de Informacin de Base SCA Service Component Architecture SCAMPI CMMI mtodo de valoracin para la Mejora de Procesos SLA Acuerdo de Nivel de Servicio SMAP Proceso de solicitud de Gestin de la Seguridad INTELIGENTE Especficos, medibles, alcanzables, realistas y de duracin determinada SMTP Simple Mail Transfer Protocol SNA Arquitectura de red de Sistema SNMP Simple Network Management Protocol SOA Arquitectura Orientada a Servicios SPEM Processing Software Engineering Metamodel
Pgina668de670

TOGOF9.1
SQL Structured Query Language PASO Estndar para el intercambio de datos y el modelo del producto SWG Grupo de Trabajo Especial SysML Sistemas Modeling Language TADG Tesoro Arquitectura Orientacin Desarrollo TAFIM Marco de Arquitectura Tcnica para la Gestin de la Informacin TCP / IP / Protocolo de Internet Transmission Control Protocol TISAF Sistema de Informacin de Hacienda Architecture Framework TRM Referencia tcnica del Modelo TFA Transparente de acceso a archivos TLSP Protocolo de seguridad de nivel de transporte TMF TeleManagement Forum TP Procesamiento de transacciones UML
Pgina669de670

TOGOF9.1
Unified Modeling Language UN / CEFACT Centro de las Naciones Unidas para la Facilitacin del Comercio y las Transacciones Electrnicas UN / EDIFACT Naciones Unidas / Intercambio Electrnico de Datos para la Administracin, Comercio y Transporte WAN Red de rea Amplia WSDL Web Services Description Language XML Extensible Markup Language XSD Definicin de esquemas XML
Pgina670de670

Togaf 91ES

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Togaf 91ES

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Togaf 91ES

Cargado por

Copyright:

Formatos disponibles

The Open Group Architecture Framework

The Open Group Architecture Framework

1.1 Estructura del documento TOGAF

The Open Group Architecture Framework

Figura 1-1: Estructura del documento TOGAF

The Open Group Architecture Framework

1.2 Resumen Ejecutivo

The Open Group Architecture Framework

The Open Group Architecture Framework

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

The Open Group Architecture Framework

The Open Group Architecture Framework

2.2 Qu es la arquitectura en el contexto de TOGAF?

2.3 Qu tipo de arquitectura TOGAF El trato con?

The Open Group Architecture Framework

2.4 Arquitectura Mtodo de Desarrollo

The Open Group Architecture Framework

2.5 Entregables, Artefactos y bloques de construccin

The Open Group Architecture Framework

The Open Group Architecture Framework

Continuum 2.6 Empresa

2.7 Arquitectura Repositorio

The Open Group Architecture Framework

The Open Group Architecture Framework

2.8 Establecer y mantener una capacidad de Arquitectura Empresarial

2.9 Establecimiento de la Capacidad de Arquitectura como una

The Open Group Architecture Framework

The Open Group Architecture Framework

2.10 El uso de TOGAF con otros marcos

The Open Group Architecture Framework

3.4 Arquitectura de la aplicacin

3.5 Application Platform

The Open Group Architecture Framework

3.6 Plataforma de Aplicaciones (API)

3.7 Estilo arquitectnico

3.9 Arquitectura Bloque de construccin (ABB)

3.10 Arquitectura Continuum

3.11 Arquitectura Mtodo de Desarrollo (ADM)

The Open Group Architecture Framework

3.12 Arquitectura de dominio

3.13 Marco de Arquitectura

3.14 Arquitectura de Gobierno

3.15 Arquitectura del Paisaje

3.16 Principios Arquitectura

3,17 Architecture Vision

The Open Group Architecture Framework

3.19 Lnea de Base

3.20 Flujo de Informacin sin fronteras

The Open Group Architecture Framework

3.22 Arquitectura de Negocios

3.23 Funcin de Empresas

3.24 Gobierno de Empresas

3.25 Servicios de Negocio

3.27 Capacidad de Arquitectura

The Open Group Architecture Framework

Incremento de 3,28 Capacidad

3.29 Comunicaciones y Gestin de las partes interesadas

3.30 Las preocupaciones

3.32 Arquitectura de Datos