Togaf 91es 373f4f

The Open Group Architecture Framework TOGOF 9.1

FASE I Introducción

Página 1 de 670


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

¿Qué es una empresa?



¿Por qué necesito una empresa de arquitectura?



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

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

Página 2 de 670


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

Página 3 de 670

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

Se espera que las organizaciones que son nuevas para TOGAF y desean adoptar progresivamente conceptos TOGAF para centrarse en determinadas partes de la especificación para su aprobación inicial, con otras áreas presentadas para su consideración posterior.



Las organizaciones que ya han implementado marcos de arquitectura pueden optar por combinar estos marcos con los aspectos de la especificación TOGAF.

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

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

Página 4 de 670

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

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



Una operación de negocio más eficiente: o

Menores costos de operación de negocios

o

Organización más ágil

o

Capacidades empresariales compartidos a través de la organización

o

Costos de gestión del cambio Inferior

o

Fuerza de trabajo más flexible

o

Mejora de la productividad de las empresas

Una operación de TI más eficiente: o

Bajo desarrollo de software, soporte y mantenimiento de los costos

o

El aumento de la portabilidad de las aplicaciones

o

Interoperabilidad mejorada y más fácil sistema y red de gestión

o

Mejora de la capacidad para abordar cuestiones críticas a nivel de empresa como la seguridad

Página 5 de 670

The Open Group Architecture Framework TOGOF 9.1   o 



Más fácil actualización y el intercambio de los componentes del sistema

Mejor retorno de la inversión existente, menor riesgo para la inversión futura: o

Reducción de la complejidad en el negocio y TI

o

Máximo rendimiento de la inversión en la infraestructura de TI de negocios existentes y

o

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

o

Reducción del riesgo general en las nuevas inversiones y su coste de propiedad

Más rápido, más sencillo y más barato de adquisiciones: o

Las decisiones de compra son más simples, ya que la información que rige la contratación está fácilmente disponible en un plan coherente

o

El proceso de contratación es más rápido - maximizar la velocidad de adquisición y flexibilidad sin sacrificar la coherencia arquitectónica

o

La capacidad de suministro de los sistemas abiertos heterogéneos de múltiples proveedores

o

La capacidad de asegurar las capacidades más económicos

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

Por lo general, la preparación para las necesidades de transformación de negocios o de cambios en la infraestructura radicales inicia una revisión o desarrollo de arquitectura empresarial. A menudo las personas clave a identificar áreas de cambio necesarios para que los nuevos objetivos de negocio que debe cumplir. Estas personas se conocen comúnmente como las "partes interesadas" en el cambio. El papel del arquitecto es hacer frente a sus preocupaciones a través de: 

La identificación y el perfeccionamiento de los requisitos que los interesados tienen



Desarrollo de vistas de la arquitectura que muestran cómo las preocupaciones y necesidades van a ser tratados



Mostrando las compensaciones que se van a realizar en la conciliación de los intereses potencialmente conflictivos de las distintas partes interesadas

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

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

Página 6 de 670

The Open Group Architecture Framework TOGOF 9.1   ¿Por qué necesito TOGAF como marco para la arquitectura de la empresa?

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

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

Página 7 de 670


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

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

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

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

2.3 ¿Qué tipo de arquitectura TOGAF ¿El trato con? Hay cuatro campos de arquitectura que son comúnmente aceptadas como subconjuntos de un conjunto de arquitectura empresarial, todo lo cual TOGAF está diseñado para soportar: 

La arquitectura de negocio define la estrategia empresarial, el gobierno, la organización y los procesos clave del negocio.



La Arquitectura de Datos describe la estructura de los activos de datos lógicos y físicos de una organización y los recursos de gestión de datos.

Página 8 de 670

The Open Group Architecture Framework TOGOF 9.1   

La Arquitectura de la aplicación proporciona un modelo para las aplicaciones individuales que se desplegarán, sus interacciones y su relación con los procesos de negocio de la organización.



La Tecnología de la Arquitectura describe las capacidades de software y hardware lógicos que se requieren para apoyar el despliegue de servicios de negocio, datos y aplicaciones. Esto incluye la infraestructura de TI, middleware, redes, comunicaciones, procesamiento, normas, etc

2.4 Arquitectura Método de Desarrollo La Arquitectura Método de Desarrollo de TOGAF () proporciona un probado y proceso repetible para el desarrollo de arquitecturas. La incluye el establecimiento de un marco de arquitectura, desarrollo de contenidos arquitectura, la transición, y que rige la realización de arquitecturas. Todas estas actividades se llevan a cabo dentro de un ciclo iterativo de definición de la arquitectura y la realización continua que permite a las organizaciones a transformar sus empresas de una manera controlada en respuesta a los objetivos de negocio y oportunidades. Fases dentro de la son los siguientes: 

La fase preliminar describe las actividades de preparación e iniciación necesarios para crear una capacidad de Arquitectura incluyendo personalización de TOGAF y definición de Arquitectura Principios.



Fase A: Arquitectura Visión describe la fase inicial de un ciclo de desarrollo de la arquitectura. Incluye información sobre cómo definir el alcance de la iniciativa de desarrollo de la arquitectura, la identificación de las partes interesadas, la creación de la arquitectura de la Visión, y obtener la aprobación para proceder con el desarrollo de la arquitectura.



Fase B: Arquitectura de Negocios describe el desarrollo de una arquitectura de negocios para apoyar el acuerdo Architecture Vision.



Fase C: Sistemas de Información Arquitecturas describe el desarrollo de Sistemas de Información Arquitecturas para apoyar el acuerdo Architecture Vision.



Fase D: Architecture Tecnología describe el desarrollo de la arquitectura de la tecnología para apoyar el acuerdo Architecture Vision.



Fase E: Oportunidades y Soluciones lleva a cabo la planificación de la implementación inicial y la identificación de los vehículos de reparto para la arquitectura se define en las fases anteriores.



Fase C: planeamiento de migración aborda cómo pasar de la línea de base a las arquitecturas objetivo al finalizar una implementación detallada y Plan de Migración.



Fase G: Gobernanza Aplicación proporciona una supervisión de arquitectura de la aplicación.



Fase H: Arquitectura de Gestión del Cambio , establece los procedimientos para la gestión del cambio a la nueva arquitectura.

Página 9 de 670


Gestión de Requisitos examina el proceso de gestión de requisitos de arquitectura en todo el .

2.5 Entregables, Artefactos y bloques de construcción Arquitectos ejecutores del producirán una serie de resultados, como resultado de sus esfuerzos, como los flujos de procesos, requisitos arquitectónicos, planes de proyectos, evaluaciones de cumplimiento de proyectos, etc El marco de contenido TOGAF Arquitectura (ver la Parte IV , 33. Introducción ) proporciona una modelo estructural para el contenido de arquitectura que permite a los principales productos de trabajo para definir consistentemente, estructurados y presentados. La Arquitectura del marco de contenido usa las siguientes tres categorías para describir el tipo de producto de trabajo de arquitectura dentro del contexto de uso: 

Un entregable es un producto de trabajo que se especifica y, a su vez revisado formalmente, de acuerdo, y firmado por las partes interesadas contractualmente.Entregables representan la salida de los proyectos y los resultados que se tenga en forma de documentación serán típicamente archivadas en la finalización de un proyecto, o la transición hacia un repositorio arquitectura como un modelo de referencia, estándar o instantánea de la arquitectura del paisaje en un punto en el tiempo.



Un artefacto es un producto del trabajo arquitectónico que describe un aspecto de la arquitectura. Los artefactos se clasifican generalmente como catálogos (listas de cosas), matrices (que muestran las relaciones entre las cosas), y diagramas (imágenes de las cosas). Los ejemplos incluyen un catálogo de necesidades, matriz de interacción de negocios, y un diagrama de casos de uso. Un entregable arquitectónica puede contener muchos objetos y artefactos formarán el contenido de la Arquitectura Repository.



Un bloque de construcción representa un (potencialmente reutilizable), componente de negocio, TI, o la capacidad de la arquitectura que se puede combinar con otros bloques de construcción para ofrecer arquitecturas y soluciones. Bloques de construcción se pueden definir en varios niveles de detalle, dependiendo de la etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una etapa temprana, un bloque de construcción puede consistir simplemente en un nombre o una breve descripción. Más tarde, un bloque de construcción se puede descomponer en varios bloques de edificios de apoyo y puede ir acompañada de una especificación completa. Bloques de construcción pueden relacionarse con "arquitecturas" o "soluciones". o

Arquitectura Bloques de Construcción (Abs) suelen describir la capacidad requerida y dar forma a la especificación de soluciones de Bloques de Construcción (SBB). Por ejemplo, una capacidad de servicio al cliente puede ser necesaria dentro de una empresa, con el apoyo de muchos SBB, como los procesos, datos y software de aplicación.

o

Solución Building Blocks (SBB) representan los componentes que se utilizarán para implementar la capacidad requerida. Por ejemplo, una red es un bloque de construcción que se puede describir a través de artefactos complementarios y luego objeto de un uso para darse cuenta de las soluciones para la empresa.

Página 10 de 670

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

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

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


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

Figura 2‐3: Empresa Continuum



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

Página 12 de 670

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

Figura 2‐4: TOGAF Arquitectura Estructura del repositorio

   Los componentes principales dentro de un repositorio de Arquitectura son los siguientes: 

La Arquitectura Metamodel describe la aplicación organizativo adaptado de un marco de arquitectura, incluyendo un metamodelo para el contenido de la arquitectura.



La Capacidad de Arquitectura define los parámetros, estructuras y procesos que ayuden a la gobernabilidad de la arquitectura de repositorio.



La arquitectura del paisaje es la representación arquitectónica de activos desplegados dentro de la empresa de explotación en un punto determinado en el tiempo.El paisaje es probable que exista en múltiples niveles de abstracción para adaptarse a diferentes objetivos de la arquitectura.

Página 13 de 670


La Base de información de Normas (SIB) captura las normas que deben cumplir las nuevas arquitecturas, que pueden incluir normas de la industria, los productos y servicios seleccionados de proveedores o servicios compartidos ya desplegados dentro de la organización.



La Biblioteca de Referencia proporciona directrices, plantillas, patrones y otras formas de material de referencia que se puede aprovechar el fin de acelerar la creación de nuevas arquitecturas para la empresa.



El Gobierno Log proporciona un registro de la actividad de gobierno en toda la empresa.

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

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

2.9 Establecimiento de la Capacidad de Arquitectura como una

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

Página 14 de 670

The Open Group Architecture Framework TOGOF 9.1   arquitectura empresarial debe funcionar como cualquier otra unidad operativa dentro de un negocio; es decir, se debe tratar como un negocio. Con este fin, y por encima de los procesos básicos definidos en el , una práctica de la arquitectura empresarial debe establecer capacidades en las siguientes áreas: 

Gestión Financiera



Gestión del rendimiento (véase 3.52 Performance Management )



Gestión de Servicios



Gestión de Riesgos (véase Gestión de Riesgos A.75 )



Gestión de Recursos



Comunicaciones y Gestión de los interesados (véase 3.29 Comunicaciones y Gestión de los grupos de interés )



Gestión de la Calidad



Gestión de Proveedores (véase Gestión de Proveedores A.82 )



Gestión de la Configuración (ver Gestión de la Configuración A.15 )



Gestión Ambiental

Central a la idea de operar una arquitectura en curso es la ejecución del bien definido y un gobierno eficaz, por lo que toda la actividad de gran importancia arquitectónica es controlado y alineado en un marco único. Como el gobierno se ha convertido en un requisito cada vez más visible de la gestión organizacional, la inclusión de la gobernabilidad dentro de TOGAF alinea el marco de las mejores prácticas de negocio actual y también asegura un nivel de visibilidad, orientación y control que apoyará todos los requisitos y obligaciones de las partes interesadas de la arquitectura. Los beneficios de la gobernabilidad arquitectura incluyen: 

El aumento de la transparencia de la rendición de cuentas, y la delegación informó de la autoridad



La gestión del riesgo controlado



Protección de la base de activos existente a través de la maximización de la reutilización de los componentes arquitectónicos existentes



Mecanismos de control proactivo, monitoreo y gestión



Proceso, concepto, y el componente de reutilización a través de todas las unidades de negocio de la organización



La creación de valor a través del monitoreo, medición, evaluación y retroalimentación

Página 15 de 670


Mayor visibilidad apoyo a los procesos internos y los requisitos de las partes externas; en particular, el aumento de la visibilidad de la toma de decisiones en los niveles inferiores es supervisado a un nivel adecuado dentro de la empresa de las decisiones que pueden tener importantes consecuencias estratégicas para la organización



Gran valor para el accionista; en particular, la arquitectura empresarial representa cada vez más la propiedad intelectual del núcleo de la empresa - los estudios han demostrado una correlación entre el aumento de valor para los accionistas y las empresas bien gobernadas



Se integra con los procesos y las metodologías existentes y complementa la funcionalidad mediante la adición de capacidades de control

Mayores detalles sobre el establecimiento de una capacidad de arquitectura empresarial se da en la parte VII , 45. Introducción .

2.10 El uso de TOGAF con otros marcos Dos de los elementos clave de cualquier marco de arquitectura de la empresa son: 

Una definición de los entregables que la actividad architecting debería producir



Una descripción del método por el cual esto se debe hacer

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

Página 16 de 670


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

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

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

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

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

3.5 Application Platform Página 17 de 670

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

3.6 Plataforma de Aplicaciones (API) La interfaz o conjunto de funciones, entre el software de aplicación y / o de la plataforma de aplicaciones.

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

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

3.9 Arquitectura Bloque de construcción (ABB) Un componente del modelo de arquitectura que describe un solo aspecto del modelo general. Ver también 3.21 Módulo .

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

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

Página 18 de 670


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

3.13 Marco de Arquitectura Una estructura conceptual utilizado para desarrollar, implementar y mantener una arquitectura .

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

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

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

3,17 Architecture Vision Una descripción sucinta de la Arquitectura objetivo que describe su valor para el negocio y los cambios en la empresa, que será el resultado de su implementación exitosa. Sirve

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

Página 19 de 670

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

3.18 Artefacto Un producto del trabajo arquitectónico que describe un aspecto de la arquitectura. Ver también 3.21 Módulo .

3.19 Línea de Base Una especificación que ha sido revisado formalmente y acordado, que a partir de entonces, sirve como la base para un mayor desarrollo o el cambio y que sólo se puede cambiar a través de los procedimientos de control de cambios formales o de un tipo de procedimiento como la gestión de la configuración.

3.20 Flujo de Información sin fronteras 1. Una marca registrada de The Open Group. 2. Una representación abreviada de " a la información integrada para apoyar mejoras en los procesos de negocio", que representan un estado deseado de la infraestructura de una empresa específica a las necesidades de negocio de la organización. Una infraestructura que ofrece sin fronteras Flujo de Información cuenta con componentes estándares abiertos que ofrecen servicios en la empresa extendida que de un cliente: 

Combine múltiples fuentes de información



Segura entregar la información cuando y donde sea necesario, en el contexto adecuado para las personas o sistemas que utilicen dicha información.

Nota: La necesidad de flujo de información sin fronteras se describe en la Parte VI , 44. Integrado de Información de Referencia Infraestructura Modelo .

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

Página 20 de 670

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

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

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

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

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

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

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

Página 21 de 670


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

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

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

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

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

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

Página 22 de 670

The Open Group Architecture Framework TOGOF 9.1   archiva en la finalización de un proyecto, o de transición a un repositorio de arquitectura como un modelo de referencia, estándar o instantánea de la arquitectura del paisaje en un punto en el tiempo.

3.34 Empresa El nivel más alto (por lo general) de la descripción de una organización y por lo general cubre todas las misiones y funciones. Una empresa a menudo abarcar varias organizaciones.

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

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

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

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

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

Página 23 de 670


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

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

3. Un término comúnmente asignada a un departamento dentro de una organización encargada de aprovisionamiento de algunos o todos los dominios descritos en (2) anteriormente.

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

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

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

Página 24 de 670


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

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

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

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

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

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

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

Página 25 de 670


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

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

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

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

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

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

Página 26 de 670


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

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

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

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

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

3.63 Servicio de Orientación Una manera de pensar en términos de servicios y el desarrollo basado en el servicio y los resultados de los servicios.

Arquitectura Orientada a Servicios 3.64 (SOA) . Un estilo arquitectónico que apoya la orientación al servicio Tiene las siguientes características distintivas:

Página 27 de 670


Se basa en el diseño de los servicios - que reflejan las actividades empresariales del mundo real - que comprenden la empresa (o entre empresas) los procesos de negocio.



Representación del Servicio utiliza descripciones empresariales para proporcionar el contexto (es decir, los procesos de negocio, meta, regla, política, interfaz de servicio, y el componente de servicio) e implementa servicios utilizando la orquestación de servicios.



Coloca los requisitos únicos de la infraestructura -, se recomienda que las implementaciones utilizan estándares abiertos para darse cuenta de la interoperabilidad y la transparencia de ubicación.



Las implementaciones son favorables al medio específico - se ven limitados o habilitadas por el contexto y deben ser descritas dentro de ese contexto.



Se requiere un gobierno fuerte de la representación de servicios y la ejecución.



Se requiere de una "prueba de fuego", lo que determina un "buen servicio".

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

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

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

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

3.69 Normas de Información de Base (SIB) Una base de datos de normas que se pueden utilizar para definir los servicios particulares y otros componentes de una arquitectura de organización específica.

Página 28 de 670


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

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

3.72 Taxonomía de Arquitectura Vistas El conjunto organizado de todas las opiniones pertinentes para una arquitectura.

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

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

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

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

3.77 Paquete de Trabajo Página 29 de 670

The Open Group Architecture Framework TOGOF 9.1   Un conjunto de acciones identificadas para alcanzar uno o más objetivos para el negocio. Un paquete de trabajo puede ser una parte de un proyecto, un proyecto completo, o un programa.

Página 30 de 670


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

4.1 ¿Qué hay de nuevo en TOGAF 9? En esta sección se ofrece un panorama general de las principales características nuevas en TOGAF 9. Estructura Modular

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

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

Página 31 de 670

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

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

Dentro de las organizaciones más grandes, la práctica de la arquitectura de la empresa requiere de una serie de personas y equipos que trabajan juntos en muchas arquitecturas . Aunque cada arquitectura abordará un problema específico, en un ideal arquitecturas situación se puede considerar como un grupo con el fin de desarrollar una visión integrada global de cómo la empresa está cambiando. Esta versión de TOGAF cuenta con un amplio conjunto de conceptos y directrices para apoyar el establecimiento de una jerarquía integrada de las arquitecturas están siendo desarrollados por los equipos que operan dentro de un modelo de gobernanza arquitectónico general. En particular, se presentan los siguientes conceptos: 

Particionamiento : Con el fin de desarrollar arquitecturas que tienen niveles manejables de coste y la complejidad, es necesario particionar la empresa en las arquitecturas específicas. TOGAF discute el concepto de la separación y ofrece una variedad de técnicas y consideraciones de cómo particionar las diversas arquitecturas dentro de una empresa.



Arquitectura Repositorio : TOGAF proporciona un modelo de información lógica para un repositorio Arquitectura, que puede ser utilizado como un almacén integrado para todas las salidas creados por la ejecución de la .



Marco Capacidad : Esta versión de TOGAF ofrece una definición más estructurado a la organización, competencias, funciones y responsabilidades que se requieren para operar una capacidad efectiva de arquitectura empresarial. Los nuevos materiales TOGAF también proporcionan orientación sobre un proceso que se puede seguir para identificar y establecer una capacidad Arquitectura apropiado.

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

La nueva parte III: Directrices y Técnicas reúne un conjunto de materiales que muestran con más detalle cómo el se puede aplicar a las situaciones específicas de apoyo. Las nuevas pautas discuten: 

Los diversos usos de iteración que son posibles dentro de la y cuando cada técnica se deben aplicar



Los vínculos entre el TOGAF y Arquitectura Orientada a Servicios (SOA)



Las consideraciones específicas que se requieren para hacer frente a la arquitectura de seguridad dentro de la

Página 32 de 670


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

Detalle adicional

Esta versión de la especificación TOGAF incluye información más detallada apoyo a la ejecución de la . áreas particulares de mejora son: 

La fase preliminar, que cuenta con una guía extendida en el establecimiento de un marco de arquitectura de la empresa y la planificación para el desarrollo de la arquitectura. La Fase Preliminar extendido también ofrece consejos para la definición de un modelo de gobernanza para la realización arquitectura beneficio y también analiza la vinculación entre TOGAF y otros marcos de gestión.



Las Oportunidades y fase Soluciones y planeamiento de migración de fase, que cuentan con un método más detallado y sólido para la definición y planificación de transformación de la empresa, con base en los principios de la planificación basada en la capacidad.

4.1.1 Los cambios aplicados en esta edición Esta edición de TOGAF 9 incluye un conjunto de actualizaciones de mantenimiento en base a los comentarios recibidos en la publicación de 2009. . Un documento detallado por separado de los cambios está disponible como TOGAF 9 Rectificación Técnica N º 1 (Documento U112) se incluye a continuación una lista resumida de los cambios: 

Se han eliminado las definiciones de los términos en que el uso por TOGAF no es distintivo de la definición de diccionario común.



El uso de los términos "aplicación" contra "el sistema" se han revisado y hecho consistente.



Las descripciones de la Fase E y F se han modificado para que coincida con el nivel de detalle en otras fases.



Los usos de la terminología para la transición Arquitectura / Roap Estrategia / Implementación han aclarado y hecho consistente.



Los conceptos de niveles / iteraciones / particiones han aclarado y hecho consistente. Esto incluye una reorganización de material en la parte III , 19. La aplicación de la iteración de la y 20. La aplicación de la a través de la arquitectura del paisaje , y la Parte V , 40. Arquitectura de particionamiento .



Los "Objetivos" secciones de las fases se han revisado a fin de centrarse en los objetivos reales en lugar de las técnicas o una lista de pasos.



Los artefactos posibles (puntos de vista) para cada fase se muestran ahora en la descripción de esa fase, no sólo en la Parte IV , 35. Architectural Artifacts .



Los términos "artefacto" en comparación con "punto de vista" se han aclarado y hecho consistente. Esto incluye una reestructuración de la Parte IV , 35.Architectural Artifacts .



El capítulo SOA ( Parte III , 22. Uso de TOGAF para definir y Gobierno SOAs ) ha sido actualizado para describir la última salida de grupo de trabajo de SOA.

Página 33 de 670


Texto introductorio adicional sobre los estilos arquitectónicos se ha añadido en la Parte III , 18. Introducción .



Pequeños cambios se han hecho para el capítulo de la arquitectura de seguridad ( Parte III , 21. Arquitectura de Seguridad y el ) para mantener la coherencia con el .



Se han realizado correcciones a metamodelo diagramas.



Las correcciones se han aplicado a los aspectos del metamodelo.



En el ejemplo de bloques de construcción se ha eliminado.



La categorización de modelo de documento se ha eliminado.



Duplicar texto en varios lugares ha sido reemplazado con una referencia adecuada:



o

Análisis de brechas en las fases B, C y D ahora referencia a la Parte III , 27. Análisis Gap .

o

Gestión de Requisitos en varias fases ahora hace referencia la parte II , 17.2.2 Requisitos para el Desarrollo en la fase de gestión de requisitos.

Algunos de los artefactos han sido renombrados para reflejar mejor su uso: o

Matriz System / Data se convierte en matriz de aplicaciones / datos

o

Diagrama de clases ha sido reemplazado con el diagrama conceptual de datos y el diagrama de lógica de datos

o

Matriz del sistema / Organización convierte matriz Aplicación / Organización

o

Matriz de Papel / System convierte matriz Papel / Aplicación

o

Matriz de Sistema / Función convierte en matriz de Aplicación / Función

o

Diagrama Realización de proceso / sistema convierte diagrama Realización de proceso / aplicación

o

Diagrama del sistema de casos de uso se convierte en el diagrama de casos de uso de aplicaciones

o

Matriz del sistema / tecnología se convierte en matriz de Aplicación / Tecnología



La descripción de la arquitectura de principios ahora los divide en dos únicos tipos Enterprise y Arquitectura -, mientras que antes de que llamaran a los Principios de TI por separado. IT Principios ahora son vistos como sólo una parte de los Principios Empresariales.



El Stakeholder Mapa incorporado en el capítulo de gestión de los interesados ( Parte III , 24. Gestión de los grupos de interés ) que ahora se hace referencia explícita a modo de ejemplo, la tabla se ha puesto de relieve para referirse a las preocupaciones de las partes interesadas, y la lista de objetos para cada grupo de interés actualizada.

Página 34 de 670


El capítulo Escenarios empresariales ( Parte III , 26. Escenarios empresariales y objetivos de la empresa ) se ha renombrado a escenarios empresariales y objetivos de la empresa para reflejar mejor el contenido del capítulo.



La relación de la Enterprise Repository al Repositorio Arquitectura se aclara en la Parte V , 41. Arquitectura Repositorio .



Los criterios de evaluación y directrices se han eliminado de la Parte V , 42. Herramientas para el desarrollo de la arquitectura .



El capítulo sobre la Arquitectura de Madurez Modelos ( Parte VII , 51. Arquitectura de Madurez Modelos ) ha sido revisada su redacción para mantener la coherencia y la claridad.

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

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

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

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

Página 35 de 670


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

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

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

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

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

Página 36 de 670

The Open Group Architecture Framework TOGOF 9.1   La siguiente tabla ilustra donde ahora se puede localizar TOGAF 8.1.1 Contenido base de recursos.

TOGAF 8.1.1 Recursos Architecture Board Arquitectura Cumplimiento Arquitectura contratos Arquitectura de Gobierno Modelos de Madurez Arquitectura Arquitectura Patrones Principios Arquitectura Arquitectura Skills Framework Desarrollo Arquitectura Vistas Bloques de Construcción Vistas Dominio de procesos de negocio Escenarios empresariales Estudios de caso Glosario Otras Arquitecturas y Marcos Herramientas para el Desarrollo de la Arquitectura y el Marco Zachman

Ubicación actual Trasladado a la Parte VII: Arquitectura del marco de Capacidad Trasladado a la Parte VII: Arquitectura del marco de Capacidad Trasladado a la Parte VII: Arquitectura del marco de Capacidad Trasladado a la Parte VII: Arquitectura del marco de Capacidad Trasladado a la Parte VII: Arquitectura del marco de Capacidad Trasladado a la Parte III: Directrices y Técnicas de Trasladado a la Parte III: Directrices y Técnicas de Trasladado a la Parte VII: Arquitectura del marco de Capacidad Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de contenido Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de contenido Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de contenido Trasladado a la Parte III: Directrices y Técnicas de Eliminado. Estudios de caso estarán disponibles en el sitio web Open Group. Trasladado a la Parte I: Introducción Eliminado. Este material estará disponible en el sitio web de Open Group como un Libro Blanco. Trasladado a la Parte V: Empresa Continuum y Herramientas Eliminado. Este material estará disponible en el sitio web de Open Group como un Libro Blanco.

4.4 Mapeo de TOGAF 9 Estructura de TOGAF 8.1.1 La siguiente tabla muestra los puntos de TOGAF 9 capítulos se asignan a los de TOGAF 8.1.1: TOGAF 9 Capítulo Parte I: Introducción 1 Introducción 2 Conceptos Básicos 3 Definiciones 4 Notas de la versión Parte II: Arquitectura Método de Desarrollo 5 Introducción 6 Fase Preliminar 7 Fase A: Architecture Vision 8 Fase B: Arquitectura de Negocios

Derivación de TOGAF 8.1.1 Material revisado; basado en el capítulo 1 Nuevo capítulo El material derivado de Capítulo 36, vuelto a trabajar en las definiciones formales y abreviaturas secciones Nuevo capítulo Material revisado; basado en el Capítulo 3 Material revisado; basado en el Capítulo 4 Material revisado; basado en el Capítulo 5 Material revisado; basado en el Capítulo 6

Página 37 de 670

The Open Group Architecture Framework TOGOF 9.1   9 Fase C: Arquitecturas de Sistemas de Información 10 Fase C: Arquitectura de Datos 11 Fase C: Arquitectura de aplicaciones 12 Fase D: Architecture Tecnología 13 Fase E: Oportunidades y Soluciones 14 Fase C: planeamiento de migración 15 Fase G: Gobernanza Aplicación 16 Fase H: Gestión Arquitectura Cambio 17 Arquitectura Gestión de Requisitos Parte III: Directrices y Técnicas de 18 Introducción 19 La aplicación de la a través de la Arquitectura del Paisaje 20 La aplicación de la en los diferentes niveles de la empresa 21 Arquitectura de Seguridad y el

Material revisado; basado en el Capítulo 7 Material revisado; basado en el Capítulo 8 Material revisado; basado en el Capítulo 9 Material revisado; basado en el capítulo 10 Material revisado; basado en el capítulo 11 Material revisado; basado en el Capítulo 12 Material revisado; basado en el capítulo 13 Material revisado; basado en el capítulo 14 Ningún cambio material; mapas del capítulo 15 Nuevo capítulo Nuevo capítulo Nuevo capítulo

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

Página 38 de 670

The Open Group Architecture Framework TOGOF 9.1   47 Architecture Board 48 Arquitectura Cumplimiento 49 Arquitectura contratos 50 Arquitectura de Gobierno 51 Modelos de Madurez Arquitectura 52 Arquitectura Skills Framework La Glosario de Definiciones complementarias B Abreviaturas

Con cambios mínimos; mapas del capítulo 23 Con cambios mínimos; mapas para el Capítulo 24 Con cambios mínimos; mapas para el Capítulo 25 Con cambios mínimos, se asigna al Capítulo 26 Con cambios mínimos; mapas del capítulo 27 Algunos cambios cosméticos; mapas del capítulo 30 Derivado del Capítulo 36 Derivado del Capítulo 36

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

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

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

Página 39 de 670


4.6 ¿Por qué unirse The Open Group? Las organizaciones que deseen reducir el tiempo, costo y riesgo de la implementación de soluciones de múltiples proveedores que se integran dentro de y entre las empresas necesitan The Open Group como su socio clave. The Open Group reúne a los compradores y proveedores de sistemas de información en todo el mundo, y les permite trabajar juntos, tanto para garantizar que las soluciones de TI a cumplir las necesidades de los clientes, y para hacer más fácil la integración de TI en toda la empresa. TOGAF es un factor clave en esta tarea. Sí, sí TOGAF está disponible gratuitamente. Pero, ¿cuánto va a gastar en el desarrollo o la actualización de su arquitectura empresarial utilizando TOGAF? ¿Y cuánto va a gastar en adquisiciones en base a que la arquitectura? El precio de la membresía de The Open Group es insignificante en comparación con estas cantidades. Además de los beneficios generales de la pertenencia, como miembro de The Open Group usted será elegible para participar en el Foro de Arquitectura Open Group, que es el programa de desarrollo en el que se desarrolló TOGAF, y en el que los s TOGAF reunirse para intercambiar información y la retroalimentación. Los de la ganancia Architecture Forum: 

inmediato a los frutos del actual programa de trabajo TOGAF (no disponible para el público hasta la publicación de la próxima edición del documento TOGAF) - de hecho, la última información sobre TOGAF



El intercambio de experiencias con otras organizaciones de clientes y proveedores que participan en la arquitectura empresarial en general, y la creación de redes con los arquitectos que utilizan TOGAF en proyectos de desarrollo de arquitectura importantes de todo el mundo



La revisión por pares de la caja material de estudio arquitectura específica

Página 40 de 670


PARTE II Método Arquitectura Desarrollo

Página 41 de 670


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

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

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

Página 42 de 670

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

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

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

Página 43 de 670


5.2 Arquitectura del Ciclo de Desarrollo 5.2.1 Puntos clave Los siguientes son los puntos clave de la : 

El es iterativo, sobre todo el proceso, entre las fases, y dentro de las fases (véase la Parte III , 19. La aplicación de iteración para el ). Para cada iteración de la , una nueva decisión debe tomarse en cuanto a: o

La amplitud de la cobertura de la empresa a definir

o

El nivel de detalle que se define

o

La extensión del período de tiempo destinado a, incluyendo el número y extensión de cualquier periodos de tiempo intermedios

o

Los activos de arquitectura para ser movilizados, entre ellos: 

Activos creados en versiones anteriores del ciclo de en la empresa



Activos disponibles en la industria en otras partes (otros marcos, modelos de sistemas, modelos industriales verticales, etc)



Estas decisiones deberían basarse en una evaluación práctica de los recursos y la disponibilidad de la competencia, y el valor que de manera realista se puede esperar que obtuviera la empresa del ámbito elegido de la obra de arquitectura.



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

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

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

Página 44 de 670

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

Figura 5‐1: Arquitectura Ciclo de Desarrollo Las fases del ciclo de se dividen además en pasos; por ejemplo, los pasos dentro de las fases de desarrollo de la arquitectura (B, C, D ) son los siguientes: 

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



Desarrollar Arquitectura de referencia Descripción



Desarrollar Arquitectura Target Descripción



Realizar análisis de las deficiencias



Definir los componentes de la hoja de ruta candidatos

Página 45 de 670


Resolver los impactos en la Arquitectura del Paisaje



Llevar a cabo una revisión formal de las partes interesadas



Finalizar la Arquitectura



Crear Arquitectura Definición de documento

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

Fase A: Architecture Vision

Entregable Arquitectura Visión

Contenido Negocios Arquitectura Datos Arquitectura Aplicación Arquitectura Tecnología de Arquitectura

B: Arquitectura de Negocios C: Sistemas de Información Arquitectura

D: Architecture

Arquitectura Definición Documento Arquitectura Definición Documento

Arquitectura

Negocios Arquitectura

Versión Descripción 0.1 Versión 0.1 indica que un esquema de alto nivel de la arquitectura está en su lugar. 0.1 Versión 0.1 indica que un esquema de alto nivel de la arquitectura está en su lugar. 0.1 Versión 0.1 indica que un esquema de alto nivel de la arquitectura está en su lugar. 0.1 Versión 0.1 indica que un esquema de alto nivel de la arquitectura está en su lugar. 1.0 Versión 1.0 indica una revisión formal, la arquitectura detallada.

Datos Arquitectura

1.0

Versión 1.0 indica una revisión formal, la arquitectura detallada.

Aplicación Arquitectura Tecnología de

1.0

Versión 1.0 indica una revisión formal, la arquitectura detallada. Versión 1.0 indica una revisión formal, la

1.0

Página 46 de 670

The Open Group Architecture Framework TOGOF 9.1   Tecnología

Definición Documento

Arquitectura

arquitectura detallada.

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

5.3 Adaptación de la El es un método genérico para el desarrollo de la arquitectura, que está diseñado para hacer frente a la mayor parte del sistema y los requisitos de organización. Sin embargo, a menudo será necesario modificar o ampliar el para adaptarse a necesidades específicas. Una de las tareas antes de aplicar la es revisar sus componentes para la aplicabilidad y, a continuación, adaptarlos según convenga a las circunstancias de la empresa individual. Esta actividad también puede producir un "específica de la empresa". Una de las razones para querer adaptar el , lo que es importante destacar, es que el orden de las fases de la es hasta cierto punto depende de la madurez de la disciplina de arquitectura dentro de la empresa. Por ejemplo, si el caso de negocio para hacer arquitectura en absoluto no es bien reconocido, a continuación, crear una visión de la Arquitectura es casi siempre esencial; y una detallada arquitectura de negocio a menudo tiene que venir a continuación, con el fin de apuntalar la Architecture Vision, detalle el caso de negocios para el trabajo restante arquitectura, y asegurar la participación activa de los principales interesados en que el trabajo. En otros casos puede ser preferido un orden ligeramente diferente; por ejemplo, un inventario detallado del entorno de línea de base se puede hacer antes de emprender la Arquitectura Empresarial. El orden de las fases puede definirse también por los principios de la arquitectura y los principios de negocio de una empresa. Por ejemplo, los principios empresariales pueden dictar que se preparará a la empresa a ajustar sus procesos de negocio para satisfacer las necesidades de una solución empaquetada, para que pueda implementarse rápidamente para permitir una respuesta rápida a los cambios del mercado. En tal caso, la arquitectura de negocio (o al menos la realización de la misma), así pueden seguir a la finalización de la Arquitectura de Sistemas de Información o de la Tecnología de la Arquitectura. Otra razón para querer adaptar el 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 y su genérico en relación con el Marco conocido Zachman, u otro entorno de arquitectura empresarial que tiene un conjunto definido de prestaciones específicas para un sector vertical, en particular: Gobierno, Defensa, e-Business , Telecomunicaciones, etc El se ha diseñado específicamente con este potencial de integración en la mente. Otras posibles razones para querer adaptar el incluyen: 

El es uno de los muchos procesos empresariales que conforman el modelo de gobierno corporativo. Es complementario a, y de apoyo a otros procesos de gestión de los programas estándar, tales como los de autorización, gestión de riesgos, la planificación empresarial y la presupuestación, la planificación del desarrollo, desarrollo de sistemas, y las adquisiciones.



El se encargó para su uso por un contratista principal o el plomo en una situación de la contratación externa, y debe adaptarse para alcanzar un compromiso adecuado entre las prácticas existentes del contratista y los requisitos de la empresa contratante.

Página 47 de 670


La empresa es una empresa pequeña y mediana, y desea utilizar un método "cut-down" más en sintonía con el nivel reducido de recursos y la complejidad del sistema típico de dicho entorno.



La empresa es muy grande y complejo, que comprende muchas "empresas" independientes, aunque interrelacionados dentro de un marco general de colaboración de negocios, y el método de la arquitectura debe adaptarse a reconocer esto. Diferentes enfoques para la planificación y la integración se pueden utilizar en tales casos, incluyendo las siguientes (posiblemente en combinación):



o

La planificación de arriba hacia abajo y el desarrollo - el diseño del conjunto de meta-empresarial interconectado como una sola entidad (un ejercicio que normalmente se extiende a los límites del sentido práctico)

o

Desarrollo de una arquitectura o "genérico" de "referencia", típico de las empresas dentro de la organización, pero que no representan ninguna empresa específica, que a su vez se espera que las empresas individuales de adaptación con el fin de producir una "instancia" arquitectura adaptada a la empresa de que se trate .

o

Replicación - el desarrollo de una arquitectura específica para una empresa, implementar como una prueba de concepto, y luego tomar que como una "arquitectura de referencia "para ser clonado en otras empresas.

En un entorno de varios proveedores o de producción, una arquitectura genérica para una familia de productos se refiere a menudo como una "Línea de Arquitectura ",y el proceso análogo al descrito anteriormente se denomina "(basado en la arquitectura) Línea de productos de ingeniería". El se dirige principalmente a los arquitectos en las empresas usuarias de TI, sino una organización de proveedores cuyos productos se basan IT-bien podría desear para adaptarlo como un método genérico para un desarrollo Línea de Producto Arquitectura.

5.4 Arquitectura de Gobierno El , ya sea adaptada por la organización o se utiliza como documentado aquí, es un proceso clave para ser gestionados de la misma manera que otros artefactos arquitectura clasifican mediante la Empresa Continuum y se mantienen en la arquitectura de repositorio. La Junta de Arquitectura debe estar convencido de que el método se está aplicando correctamente en todas las fases de una arquitectura de desarrollo iteración. El cumplimiento de la es fundamental para la gobernanza de la arquitectura, para asegurar que todas las consideraciones se hacen y se producen todos los entregables requeridos. La gestión de todos los artefactos arquitectónicos, la gobernanza y los procesos relacionados debe apoyarse en un entorno controlado. Normalmente, esto se basa en uno o más repositorios de soporte de objeto con versiones y control de procesos y el estado. Las principales áreas de información que gestiona un repositorio de gobierno deben contener los siguientes tipos de información: 

Datos de referencia (garantía de los propios repositorios de la organización / empresa Continuum, incluyendo los datos externos, por ejemplo, COBIT, ITIL): Se utiliza para la orientación y la instrucción durante la ejecución del proyecto. Esto incluye los detalles de la

Página 48 de 670

The Open Group Architecture Framework TOGOF 9.1   información antes mencionados. Los datos de referencia incluye una descripción de los propios procedimientos de gobierno. 

Estado de proceso : Toda la información sobre el estado de todos los procesos de gobernanza será istrado; ejemplos de ello son las solicitudes pendientes de cumplimiento, solicitudes de dispensa, y evaluaciones de cumplimiento investigaciones.



Auditoría de la información : Esto grabará todas las acciones del proceso de gobernanza completados y se utilizará para apoyar: o

Las decisiones clave y el personal responsable para cualquier proyecto de arquitectura que ha sido sancionado por el proceso de gobernanza

o

Una referencia para la futura evolución del proceso arquitectónico y el apoyo, orientación y prioridad

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

5.5 La determinación del alcance de la Arquitectura Hay muchas razones para restringir (o restringir) el alcance de la actividad arquitectónica a realizar, la mayoría de los cuales se relacionan con los límites en: 

La autoridad para la organización del equipo de producción de la arquitectura



Los objetivos y las preocupaciones de los interesados que deben abordarse dentro de la arquitectura



La disponibilidad de las personas, las finanzas y otros recursos

El ámbito elegido para la actividad de la arquitectura, lo ideal sería permitir que el trabajo de todos los arquitectos dentro de la empresa que se rige y se integra de manera eficaz. Esto requiere de un conjunto de particiones alineadas "arquitectura" que aseguran los arquitectos no están trabajando en actividades duplicadas o contradictorias.También se requiere la definición de reutilización y de cumplimiento relaciones entre las particiones de arquitectura. La división de la empresa y su actividad relacionada con la arquitectura-se analiza con más detalle en el 40. Arquitectura de particionamiento . Cuatro dimensiones se suelen utilizar para definir y limitar el alcance de una arquitectura : 

Amplitud : ¿Cuál es la magnitud de la empresa, y qué parte de esa medida será esta arquitectura de acuerdo con el esfuerzo? o

Muchas empresas son muy grandes, que comprende de manera efectiva una federación de unidades organizativas que válidamente podría considerarse empresas en su propio derecho.

o

La empresa moderna se extiende cada vez más allá de sus límites tradicionales, para abrazar una combinación borrosa de la empresa comercial tradicional combinado con proveedores, clientes y socios.

Página 49 de 670


Profundidad : ¿En qué nivel de detalle debe ir el esfuerzo architecting? ¿Cuánto arquitectura es "suficiente"? ¿Cuál es la adecuada delimitación entre el esfuerzo de la arquitectura y otras actividades relacionadas (diseño de sistemas, ingeniería de sistemas, sistemas de desarrollo)?



Período de tiempo : ¿Cuál es el período de tiempo que debe ser articulada para la Architecture Vision, y ¿tiene sentido (en términos de practicidad y recursos) para el mismo período que se tratarán en la descripción detallada arquitectura? Si no es así, ¿cuántos Arquitecturas Transición se han de determinar, y cuáles son sus periodos de tiempo?



Arquitectura Dominios : Una descripción completa de arquitectura empresarial debe contener los cuatro dominios de la arquitectura (de negocios, datos, aplicaciones, tecnología), pero la realidad de los recursos y las limitaciones de tiempo a menudo significan que no hay tiempo suficiente, la financiación o los recursos para construir una de arriba hacia abajo , todo incluido descripción de la arquitectura que abarca las cuatro áreas de arquitectura, aunque el alcance de la empresa es elegida para ser menor que el alcance total de la empresa en general.

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

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

Página 50 de 670

The Open Group Architecture Framework TOGOF 9.1   La viabilidad de una única arquitectura de toda la empresa para cada función de negocio o propósito puede ser rechazada por ser demasiado complejo y difícil de manejar.En estas circunstancias, se sugiere que un número de diferentes arquitecturas empresariales existen en una empresa. Estas arquitecturas empresariales se centran en los plazos determinados, segmentos de negocios o eventos, y los requisitos específicos de la organización. En tal caso, tenemos que crear la arquitectura de la empresa global como una "federación" de estas arquitecturas empresariales. Una manera eficaz de gestionar y explotar estas arquitecturas empresariales es adoptar un modelo de publicación y suscripción que permite a la arquitectura para ser puesto bajo un marco de gobernanza. En este modelo, los desarrolladores de arquitectura y arquitectura consumidores en los proyectos (los lados de la oferta y la demanda de trabajo de la arquitectura) se inscriben para un marco de beneficio mutuo de gobierno que garantice que: 

Material arquitectónico es de buena calidad, hasta a la fecha, aptas para esta finalidad, y publicado (examinó y aprobó que se hagan públicos).



El uso de material de la arquitectura puede ser monitoreada, y el cumplimiento de las normas, modelos y principios se puede exhibir, a través de: o

Un proceso de evaluación de la conformidad que describe lo que el está suscribiendo, y evalúa su nivel de cumplimiento

o

Un proceso de dispensación que pueden conceder dispensas de adhesión a las normas de arquitectura y directrices en casos específicos (por lo general con un fuerte imperativo de negocio)

Publicación y suscripción técnicas se están desarrollando como parte de generales de gobierno de TI y específicamente para el ámbito de Defensa.

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

Página 51 de 670

The Open Group Architecture Framework TOGOF 9.1   se puede lograr. Valor de los interesados es un elemento clave: un alcance demasiado amplio puede disuadir a algunas partes interesadas (sin retorno de la inversión).

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

1. En primer lugar, el desarrollo de arquitectura objetivo Descripciones para el sistema en su conjunto (a gran escala), lo que demuestra una respuesta a los objetivos y las preocupaciones de los interesados durante un período de tiempo relativamente distantes (por ejemplo, un período de seis años).

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

Página 52 de 670

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

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

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

Página 53 de 670


Figura 5‐2: Integración de la Arquitectura Artefactos Como las organizaciones a abordar temas comunes (como la Arquitectura Orientada a Servicios (SOA), y la infraestructura de información integrada), y modelos de datos universales y estructuras de datos estándar surgir, se facilitará la integración hacia el extremo superior del espectro. Sin embargo, siempre habrá la necesidad de una gobernanza normas efectiva para reducir la necesidad de manual de coordinación y resolución de conflictos.

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

Página 54 de 670


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

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


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

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

Revisar el contexto de la organización para la realización de la arquitectura empresarial

o

Identificar y el alcance de los elementos de las organizaciones empresariales afectadas por la Capacidad de Arquitectura

o

Identificar los marcos establecidos, métodos y procesos que se cruzan con la capacidad de Arquitectura

o

Establecer destino Capability Maturity

2. Establecer la Capacidad de Arquitectura: o

Definir y establecer el modelo de organización de la Arquitectura Empresarial

o

Definir y establecer el proceso detallado y recursos para la gobernanza de la arquitectura

o

Seleccionar y aplicar herramientas que apoyan la capacidad Arquitectura

o

Definir los principios de la arquitectura

6.2 Enfoque Esta Fase Preliminar trata de definir "dónde, qué, por qué, quién, y cómo lo hacemos arquitectura" en la empresa de que se trate. Los principales aspectos son los siguientes: 

Definición de la empresa



La identificación de factores clave y elementos en el contexto de la organización



Definición de los requisitos para la obra de arquitectura



Definición de los principios de la arquitectura que informen de cualquier obra de arquitectura



Definir el marco para ser utilizado



Definición de las relaciones entre los marcos de gestión



La evaluación de la madurez de arquitectura empresarial

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

Página 56 de 670

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

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

6.2.2 Contexto Organizacional Con el fin de tomar decisiones efectivas e informadas sobre el marco para la arquitectura para ser utilizado dentro de una empresa particular, es necesario entender el contexto que rodea el marco de la arquitectura. Las áreas específicas a tener en cuenta serían: 

Los modelos comerciales para la arquitectura de la empresa y los planes presupuestarios para la actividad de la arquitectura empresarial. Cuando no existan tales planes, la Etapa Preliminar se debe utilizar para desarrollar un plan de presupuesto.



Los grupos de interés para la arquitectura de la empresa; sus problemas y preocupaciones clave.



Las intenciones y la cultura de la organización, como se refleja en las directivas empresariales bordo, los imperativos de negocio, estrategias de negocios, principios de negocio, objetivos de negocio, y los impulsores del negocio.



. Los procesos actuales que apoyan la ejecución de los cambios y el funcionamiento de la empresa, incluyendo la estructura del proceso y también el nivel de rigor y formalidad aplicada dentro de la organización Áreas de enfoque deben incluir:

Página 57 de 670

The Open Group Architecture Framework TOGOF 9.1   o

Los métodos actuales para la descripción de la arquitectura

o

Marcos y métodos de gestión de proyectos actuales

o

Marcos y métodos de gestión de los sistemas actuales

o

Procesos y métodos de gestión de la cartera de proyectos actuales

o

Procesos y métodos de gestión de la cartera de aplicaciones actuales

o

Procesos y métodos de gestión de la cartera de tecnología actuales

o

Procesos y métodos de gestión de carteras de información actuales

o

Sistemas de diseño y desarrollo de esquemas y métodos actuales



El paisaje Arquitectura de referencia, incluyendo el estado de la empresa y también cómo el paisaje se representa actualmente en forma de documentación.



Las habilidades y capacidades de la empresa y las organizaciones específicas que se adopta el marco.

Revisión del contexto de la organización debería establecer requisitos valiosos sobre cómo adaptar el marco de arquitectura en términos de: 

Nivel de formalidad y el rigor que se aplicará



El nivel de sofisticación y los gastos necesarios



Puntos de o con otras organizaciones, procesos, roles y responsabilidades



Enfoque de la cobertura de contenidos

6.2.3 Requisitos para la Arquitectura de Trabajo Los imperativos de negocio detrás de la obra de arquitectura empresarial en coche de los requisitos y parámetros de rendimiento de la obra de arquitectura. Deben ser lo suficientemente clara para que esta fase puede alcance los resultados del negocio y las necesidades de recursos y definir las necesidades de información de negocios de la empresa de esquema y estrategias asociadas de la obra de arquitectura empresarial por hacer. Por ejemplo, estos pueden incluir: 

Los requerimientos del negocio



Aspiraciones culturales



Los intentos de la Organización



El propósito estratégico



Necesidades financieras de previsión

Los elementos significativos de estos deben ser articulados de manera que el patrocinador puede identificar todos los tomadores de decisiones y actores clave involucrados en la definición y el establecimiento de una capacidad de Arquitectura.

Página 58 de 670

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

6.2.5 Marcos de gestión La Arquitectura Método de Desarrollo de TOGAF () es un método genérico, destinado a ser utilizado por las empresas en una amplia variedad de tipos de industrias y geografías. También está diseñado para su uso con una amplia variedad de otros marcos de arquitectura de la empresa, si es necesario (aunque se puede utilizar perfectamente en su propio derecho, sin adaptación). TOGAF tiene que coexistir con y mejorar las capacidades operativas de otros marcos de gestión que están presentes dentro de cualquier organización, ya sea formal o informalmente. Además de estos marcos, la mayoría de las organizaciones tienen un método para el desarrollo de soluciones, la mayoría de los cuales tienen un componente de TI. La importancia de los sistemas es que reúne a los diversos dominios (también conocidas como Personas, Procesos y Materiales / Tecnología) para ofrecer una capacidad de negocio. Los principales marcos sugeridas para coordinarse con TOGAF son: 

Gestión de Capacidad de Empresas (Dirección de Operaciones y Planificación) que determina lo que se requieren capacidades laborales para entregar valor de negocio que incluye la definición de rendimiento de la inversión y de las medidas de control / rendimiento requeridos.



Métodos de gestión de cartera / del proyecto que determinan cómo una empresa gestiona sus iniciativas de cambio.



Métodos de gestión de operaciones que describen cómo una empresa gestiona sus operaciones del día a día, incluyendo IT.

Página 59 de 670


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

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

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

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

Página 60 de 670

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

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

Página 61 de 670

The Open Group Architecture Framework TOGOF 9.1   proyectos. Arquitecturas de proyectos y detallada fuera del contexto de diseño suelen estar basadas en metodologías de diseño de sistemas. Gestión de operaciones recibe los entregables y luego integra y los sostiene dentro de la infraestructura corporativa. A menudo, los servicios de gestión de servicios de TI se basan en ISO 20000 o BS15000 (ITIL).

6.2.7 Planificación de la Arquitectura Empresarial / Cambio de negocios Evaluación de madurez Modelos de Madurez de Capacidad (detallados en la Parte VII , 51. Arquitectura de Madurez Modelos ) son formas útiles de evaluación de la capacidad de una empresa para ejercer diferentes capacidades. Modelos de Madurez de Capacidad suelen identificar factores seleccionados que se requieren para ejercer una capacidad. La capacidad de una organización para ejecutar factores específicos proporciona una medida de la madurez y puede ser usado para recomendar una serie de pasos secuenciales para mejorar una capacidad. Es una evaluación que proporciona a los ejecutivos una visión de mejorar pragmáticamente una capacidad. Un buen modelo de madurez de la arquitectura empresarial cubre las características necesarias para desarrollar y consumir arquitectura empresarial. Las organizaciones pueden determinar sus propios factores y obtener los modelos de madurez adecuadas, pero se recomienda tomar un modelo existente y personalizarlo según sea necesario. Existen varios modelos de buenas, incluyendo NASCIO, y el Departamento de Comercio de Arquitectura Capability Maturity Model EE.UU.. El uso de Modelos de Madurez de Capacidad se detalla en la Parte VII , 51. Arquitectura de Madurez Modelos . Otros ejemplos incluyen el Modelo de Madurez de EE.UU. Federal Enterprise Architecture. A pesar de que los modelos son originarios de gobierno, son igualmente aplicables a la industria.

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

6.3.1 Materiales de Referencia Externa a la Empresa  TOGAF 

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

6.3.2 Entradas para no Arquitectónicos  Estrategias de la Junta y los planes de negocios a bordo, estrategia de negocio, estrategia de TI, los principios de negocio, objetivos de negocio, y los conductores de negocios, cuando se pre-existente 

Marcos importantes que operan en el negocio; por ejemplo, la cartera / de gestión de proyectos

Página 62 de 670


Gobernanza y marcos legales, incluyendo la estrategia de gobierno arquitectura, cuando pre-existente



Capacidad de Arquitectura



Los acuerdos de asociación y de contrato

6.3.3 Entradas de arquitectura . Modelos pre-existentes para el funcionamiento de una capacidad de arquitectura empresarial puede ser utilizado como una base para la Etapa Preliminar Entradas incluiría: 



Modelo de organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de Arquitectura ), incluyendo: o

Ámbito de las organizaciones afectadas

o

La evaluación gestacional, lagunas, y el enfoque de resolución

o

Roles y responsabilidades de equipo de arquitectura (s)

o

Necesidades presupuestarias

o

Gobernabilidad y estrategia de apoyo

Marco de arquitectura existente, en su caso, incluyendo: o

Método de Arquitectura

o

Contenido de Arquitectura

o

Herramientas de configurar e implementar

o

Principios Arquitectura

o

Arquitectura Repositorio

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

Página 63 de 670


6.4.1 Alcance de las organizaciones empresariales impactado



6.4.2 Marcos Confirmar Gobernabilidad y Apoyo



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



6.4.4 Identificar y establecer Arquitectura Principios



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



6.4.6 Implementar herramientas de arquitectura

6.4.1 Alcance de las organizaciones empresariales impactado  Identificar empresa de la base (unidades) - aquellos que son los más afectados y lograr mayor valor de la obra 

Identificar empresariales blandos (unidades) - los que se ven el cambio a su capacidad y trabajar con unidades básicas, pero son de otra forma no directamente afectados



Identificar empresa extendida (unidades) - las unidades fuera de la empresa de ámbito que se verán afectados en su propia arquitectura de la empresa



Identificar las comunidades implicadas (empresas) - las partes interesadas que se verán afectados y que están en los grupos de las comunidades



Identificar gobierno involucrados, incluidos los marcos jurídicos y geografías (empresas)

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

6.4.3 Definir y establecer la arquitectura empresarial Equipo y Organización  Determinar la capacidad de la empresa y el negocio existente

Página 64 de 670


Llevar a cabo una evaluación de la madurez de la empresa de arquitectura / cambios en el negocio, si se requiere



Identificar las lagunas en las áreas de trabajo existentes



Asignar roles y responsabilidades para la gestión de la empresa Arquitectura capacidad y la gobernanza



Definir las solicitudes de cambio a los programas y proyectos de negocio existentes: o

Informar existente arquitectura empresarial y la arquitectura de TI de trabajo de las necesidades de las partes interesadas

o

Solicitud de evaluación de impacto en sus planes y el trabajo

o

Identificar áreas de interés común

o

Identifique las diferencias críticas y conflictos de interés

o

Producir las solicitudes de cambio a las actividades de las partes interesadas



Determine las restricciones sobre el trabajo de arquitectura empresarial



Revise y estoy de acuerdo con los patrocinadores y junta



Evaluar las necesidades presupuestarias

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

6.4.5 Tailor TOGAF y, en su caso, Otros arquitectura marco seleccionado (s) En este paso, determinar lo que la adaptación de TOGAF se requiere. Considerar la necesidad de: 

Terminología Sastrería : Arquitectura practicantes deben usar terminología que se entiende en general en toda la empresa. Adaptación debería producir una terminología acordado fijar para la descripción de contenido arquitectónico.



Adaptación del proceso : El TOGAF proporciona un proceso genérico para la realización de la arquitectura. La adaptación del proceso ofrece la oportunidad de eliminar las tareas que ya se llevan a cabo en otras partes de la organización, añadir tareas específicas de la organización (por ejemplo, los puestos de control específicas) y alinear los procesos de a los marcos de procesos externos y puntos de o. puntos de o clave para ser dirigida incluiría: o

Enlaces a los procesos de gestión de carteras de proyectos (y de servicios)

o

Enlaces a ciclo vital del proyecto

o

Enlaces a los procesos de traspaso de las operaciones

Página 65 de 670




o

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

o

Enlaces a los procesos de contratación

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

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

6.5 Salidas Las salidas de la Fase Preliminar pueden incluir, pero no se limitan a: 





o


o


o

Las restricciones sobre el trabajo de arquitectura

o


o


Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture Framework ), que incluye: o

Método de arquitectura adaptada

o

Adaptado contenido de la arquitectura (entregables y artefactos)

o

Arquitectura Principios (ver la Parte IV , 36.2.4 Principios de Arquitectura )

Página 66 de 670





Arquitectura repositorio inicial (ver la Parte IV , 36.2.5 Arquitectura del repositorio ), poblada de contenidos marco



Reformulación de, o referencia a los principios de negocio, objetivos de negocio, y los conductores de negocios (véase la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los impulsores del negocio )



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



Arquitectura Governance Framework (véase ( Parte VII , Governance Framework 50.2 Arquitectura )

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

Catálogos: o

Catálogo de Principios

Página 67 de 670


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

Figura 7‐1: Fase A: Architecture Vision

7.1 Objetivos Los objetivos de la Fase A son: 

Desarrollar una visión aspiracional de alto nivel de las capacidades y el valor del negocio para ser entregados como resultado de la arquitectura de la empresa propuesta



Obtener la aprobación de una Declaración de Arquitectura Trabajo que define un programa de trabajos para desarrollar e implementar la arquitectura se indica en el Architecture Vision

7.2 Enfoque Página 68 de 670

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

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

Página 69 de 670

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

7.2.3 Escenarios empresariales El tiene su propio método (un "método-dentro-de-método") para la identificación y articulación de los requerimientos de negocio implicados en nueva capacidad de negocio para hacer frente a los conductores clave del negocio, y los requisitos de arquitectura implícitas. Este proceso se conoce como "escenarios de negocio", y se describe en la Parte III , 26. Escenarios empresariales y objetivos de la empresa . La técnica puede ser usada de forma iterativa, a diferentes niveles de detalle en la descomposición jerárquica de la Arquitectura Empresarial.

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

7.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio )

Página 70 de 670

The Open Group Architecture Framework TOGOF 9.1   7.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 

Principios de Actuación, los objetivos de negocio, y los conductores de negocios (véase la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los impulsores del negocio )

7.3.3 Entradas de arquitectura  Modelo de organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de Arquitectura ), incluyendo:





o


o


o


o


o

Requisitos de reutilización

o


o

Las solicitudes de cambio

o




o


o

Principios Arquitectura (ver la Parte IV , 36.2.4 Principios Arquitectura ), incluidos los principios de negocios, al pre-existente

o


Poblado Arquitectura repositorio (véase la Parte IV , 36.2.5 Arquitectura Repositorio ) - la documentación existente de arquitectura (descripción marco, descripciones arquitectónicas, las descripciones de línea de base, Abs, etc)

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

Página 71 de 670

The Open Group Architecture Framework TOGOF 9.1   Los pasos en la Fase A son como sigue: 

7.4.1 Establecer el Proyecto de Arquitectura



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



7.4.3 Confirmar y Empresariales elaborada Objetivos, controladores de Negocios y restricciones



7.4.4 Evaluar las capacidades empresariales



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



7.4.6 Definir el alcance



7.4.7 Confirmar y Arquitectura elaborar principios, incluidos los Principios de Actuación



7.4.8 Desarrollar Architecture Vision



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



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



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

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

7.4.2 Identificar los grupos de interés, las preocupaciones y los Requerimientos del Negocio Identificar las partes interesadas clave y sus preocupaciones / objetivos, y definir los requisitos empresariales clave que se abordarán en el compromiso de la arquitectura.Participación de los interesados en esta etapa se pretende lograr tres objetivos: 

Para identificar los componentes y los requisitos para ser probados como Architecture Vision visión candidatos se desarrolla



Para identificar los límites de alcance candidatos para el compromiso de limitar el alcance de la investigación arquitectónica requerida

Página 72 de 670


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

El principal producto resultante de esta etapa es un mapa de las partes interesadas para el compromiso, que muestra que las partes interesadas participen con el compromiso, su nivel de participación y sus principales preocupaciones (ver Parte III , 24.3 Pasos en el proceso de gestión de los grupos de interés y 24,4 Plantilla Stakeholder Mapa ). El mapa de las partes interesadas se utiliza para apoyar las diversas salidas de la fase Architecture Vision, e identificar: 

Las preocupaciones y puntos de vista que son relevantes para este proyecto; esto se refleja en la arquitectura de la visión (ver la Parte IV , 36.2.8 Architecture Vision )



Los actores que están involucrados con el proyecto y, en consecuencia constituyen el punto de partida para un plan de comunicaciones (ver la Parte IV , 36.2.12 Plan de Comunicaciones )



Las funciones y responsabilidades clave en el proyecto, que debe ser incluido en el Estado de Arquitectura de trabajo (ver la Parte VII , 36.2.20 Declaración de Arquitectura de Trabajo )

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

7.4.3 Confirmar y Empresariales elaborada Objetivos, controladores de Negocios y restricciones Identificar los objetivos de negocio y los conductores estratégicos de la organización. Si estos ya han sido definidos en otros lugares dentro de la empresa, garantizar que las definiciones existentes son actuales, y aclarar cualquier área de ambigüedad. De lo contrario, volver a los autores de la Declaración de Arquitectura de trabajo y trabajar con ellos para definir estos elementos esenciales y asegurar su aprobación por parte de la gestión empresarial. Definir las restricciones que deben ser tratados, incluidas las limitaciones de toda la empresa y las limitaciones específicas de cada proyecto (tiempo, calendario, recursos, etc.) Las restricciones en toda la empresa pueden ser informados por la empresa y Arquitectura principios desarrollados en la Fase Preliminar y aclararlas en el marco de la Fase A.

7.4.4 Evaluar las capacidades empresariales Es valioso para entender un conjunto de capacidades dentro de la empresa. Una parte se refiere a la capacidad de la empresa para desarrollar y consumir la arquitectura. La segunda parte se refiere a la línea de base y el nivel de capacidad objetivo de la empresa.

Página 73 de 670

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

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

7.4.6 Definir el alcance Definir lo que está dentro y lo que está fuera del alcance de los esfuerzos de Arquitectura de referencia y arquitectura objetivo, entendiendo que la línea de base y el objetivo no necesitan ser descritos en el mismo nivel de detalle. En muchos casos, la línea de base se describe en un nivel de abstracción más alto, por lo que hay más tiempo disponible para especificar el destino con suficiente detalle. Los desafíos de este son discutidos en 5.5 Alcance de la Arquitectura . En particular, definir: 

La amplitud de la cobertura de la empresa



El nivel de detalle requerido



Las características de la partición de la arquitectura (véase la Parte V , 40. Arquitectura de particionamiento para más detalles)



Los dominios específicos de arquitectura para ser cubiertos (negocio, datos, aplicaciones, tecnología)

Página 74 de 670


La extensión del período de tiempo destinado a, más el número y el alcance de cualquier período de tiempo intermedio



Los activos de arquitectura para ser apalancadas, o considerados para su uso, de la empresa Continuum de la organización: o

Activos creados en versiones anteriores del ciclo de en la empresa

o

Activos disponibles en la industria en otras partes (otros marcos, modelos de sistemas, modelos industriales verticales, etc)

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

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

7.4.9 Definir el objetivo Arquitectura propuestas de valor y los indicadores clave de rendimiento  Desarrollar el caso de negocio para las arquitecturas y los cambios necesarios 

Producir la propuesta de valor para cada uno de los grupos de interesados



Evaluar y definir los requisitos de contratación



Revisar y acordar las propuestas de valor con los patrocinadores y las partes interesadas

Página 75 de 670


Definir las métricas y las medidas que se construirán en la arquitectura de la empresa para satisfacer las necesidades empresariales de rendimiento



Evaluar el riesgo de negocios (véase la Parte III , 31. Gestión de Riesgos )

Los resultados de esta actividad se deben incorporar en el Estado de Arquitectura de Trabajo para que el rendimiento sea seguido en consecuencia.

7.4.10 Identificar los riesgos de transformación empresarial y Mitigación Actividades Identificar los riesgos asociados con la Architecture Vision y evaluar el nivel de riesgo inicial (por ejemplo, catastrófica, crítico, marginal o insignificante) y la frecuencia potencial asociado a él. Asignar una estrategia de mitigación para cada riesgo. Un marco de gestión de riesgos se describe en la Parte III , 31. Gestión de Riesgos . Hay dos niveles de riesgo que deben ser considerados, a saber: 

Nivel Inicial del Riesgo : categorización del riesgo antes de determinar e implementar acciones de mitigación.



Nivel Residual de Riesgo : categorización del riesgo después de la implementación de medidas de mitigación (si los hay).

Actividades de mitigación de riesgos deben ser considerados para su inclusión en el Estado de Arquitectura Obra.

7.4.11 Desarrollar el Enunciado de Arquitectura de Trabajo; Aprobación Secure . Evaluar los productos de trabajo que se requieren para producir (y cuándo) contra el conjunto de requisitos de rendimiento de negocio Esto implicará asegurar que: 

Las mediciones de rendimiento se construyen en los productos de trabajo.



Productos de trabajo relacionados con el rendimiento específicos están disponibles.

Luego, las actividades serán las siguientes: 

Identificar nuevos productos de trabajo que tendrá que ser cambiado



Proporcionar dirección en la que tendrá que ser cambiado productos de trabajo existentes, incluyendo bloques de construcción, y garantizar que todas las actividades y dependencias de éstos se coordinan



Identificar el impacto del cambio en otros productos de trabajo y la dependencia de sus actividades



Con base en el propósito, enfoque, alcance y limitaciones, determinan que se deben desarrollar los dominios de arquitectura, hasta qué nivel de detalle, y que vistas de arquitectura deben construirse

Página 76 de 670


Evaluar las necesidades de recursos y disponibilidad para llevar a cabo la obra en el plazo requerido; esto incluirá la adhesión a los métodos de planificación de la organización y los productos de trabajo para producir los planes para la realización de un ciclo de la



Estimar los recursos necesarios, desarrollar un plan de trabajo y un calendario para el desarrollo propuesto, y documentar todos estos en la Declaración de Arquitectura Trabajo



Definir las métricas de rendimiento que deben cumplir durante este ciclo de la por el equipo de arquitectura de la empresa



Desarrollar el Plan y programa específico de arquitectura empresarial Comunicaciones dónde, cómo, y cuando los arquitectos de la empresa se comunicará con las partes interesadas, incluidos los grupos y las comunidades de afinidad, sobre el avance de los desarrollos de arquitectura empresarial



Revisar y acordar los planes con los patrocinadores, y garantizar la aprobación formal de la Declaración de Arquitectura Obra bajo los procedimientos de gobierno que resulten



Obtener el cierre de sesión de patrocinador para proceder

7.5 Salidas Las salidas de la Fase A pueden incluir, pero no se limitan a: 

Declaración aprobada de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de Arquitectura de Trabajo ), incluyendo, en particular: o

Arquitectura Descripción y alcance del proyecto

o

Descripción general de Arquitectura Visión

o

Plan de la configuración y programación del proyecto



Declaraciones refinadas de los principios de negocio, objetivos de negocio, y los conductores de negocios (véase la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los impulsores del negocio )



Principios Arquitectura (ver la Parte IV , 23. Arquitectura Principios )



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



Tailored Architecture Framework (véase la Parte IV , 36.2.21 Tailored Architecture Framework ) (para la contratación), incluyendo:



o


o


o


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

Descripción del problema

Página 77 de 670




o

Objetivo de la Declaración de Arquitectura de Trabajo

o

Vistas de resumen

o

Escenario empresarial (opcional)

o

Requisitos clave refinados de interesados de alto nivel

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

Línea de base de Empresas Arquitectura, Versión 0.1

o

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

o

Arquitectura de datos de línea de base, versión 0.1

o

Línea de base de arquitectura de aplicaciones, versión 0.1

o

Objetivo Negocio Arquitectura, Versión 0.1

o

Tecnología Target Arquitectura, Versión 0.1

o

Arquitectura de datos de destino, Versión 0.1

o

Objetivo de Arquitectura de aplicaciones, Versión 0.1



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



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

Nota: Escenarios de negocios múltiples pueden ser usados para generar una única arquitectura Visión. Las salidas pueden incluir algunos o todos de los siguientes: 

Matrices: o



Matriz de los grupos de interés Mapa

Diagramas: o

Diagrama de la cadena de valor

o

Diagrama conceptual de soluciones

Página 78 de 670


8 Fase B:. Arquitectura de Negocios En este capítulo se describe el desarrollo de una arquitectura de negocios para apoyar una Architecture Vision acordado.

Figura 8‐1: Fase B: Arquitectura de Negocios

8.1 Objetivos Los objetivos de la Fase B son: 

Desarrollar la arquitectura destino de negocios que describe cómo la empresa necesita para operar para lograr los objetivos de negocio y responder a los conductores estratégicos establecidos en el Architecture Vision, de una manera que se dirige la solicitud de Arquitectura Trabajo y preocupaciones de los interesados



Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de las brechas entre la línea de base y objetivo de negocio Arquitecturas

Página 79 de 670


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

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

Página 80 de 670

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

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

8.2.3 Modelado de Negocios Los modelos de negocios deben ser extensiones lógicas de los escenarios de negocio de la Architecture Vision, por lo que la arquitectura puede ser mapeado a partir de los requerimientos de negocio de alto nivel hasta los más detallados. Una variedad de herramientas y técnicas de modelado se puede emplear, si se considera apropiado (teniendo en cuenta la precaución por encima de no entrar en detalles innecesarios). Por ejemplo: 

Modelos de actividad (también llamados Modelos de Procesos de Negocio ) describen las funciones relacionadas con las actividades de la empresa de negocios, los datos y / o información intercambiada entre las actividades (intercambios internos), y los datos y / o información intercambiada con otras actividades que están fuera del alcance de el modelo (intercambios externos). Modelos de actividad son de naturaleza jerárquica. Capturan las

Página 81 de 670

The Open Group Architecture Framework TOGOF 9.1   actividades llevadas a cabo en un proceso de negocio, y los del ICOM (insumos, controles, productos y mecanismos / recursos utilizados) de esas actividades. Modelos de actividad se pueden anotar con declaraciones explícitas de las reglas de negocio que representan las relaciones entre los ICOM. Por ejemplo, una regla de negocio puede especificar quién puede hacer qué en determinadas condiciones, la combinación de entradas y controles necesarios, y los productos resultantes. Una de las técnicas para la creación de modelos de actividad es la IDEF (Integrated Computer Aided Manufacturing (ICAM) Definición) técnica de modelado. El Object Management Group (OMG) ha desarrollado el Business Process Modeling Notation (BPMN), un estándar para el modelado de procesos de negocio que incluye un lenguaje con el que especifique los procesos de negocio, sus tareas / pasos, y los documentos aportados. 

Modelos de casos de uso para describir cualquiera de los procesos de negocio o funciones de los sistemas, según el enfoque del esfuerzo de modelado. Un modelo de casos de uso se describen los procesos de negocio de una empresa en términos de casos de uso y actores correspondientes a los procesos de negocio y los participantes de la organización (personas, organizaciones, etc.) El modelo de casos de uso se describe en los diagramas de casos de uso y especificaciones de casos de uso.



Modelos de clase son similares a los modelos de datos lógicos. Un modelo de clase describe la información estática y de relaciones entre la información. Un modelo de clase también se describen los comportamientos informativos. Como muchos de los otros modelos, también se puede utilizar para modelar diversos niveles de granularidad. Dependiendo de la intención de la modelo, un modelo de clases puede representar entidades de dominio empresarial o sistemas de clases de implementación. Un modelo de dominio de negocio representa la información clave del negocio (clases de dominio), sus características (atributos), sus comportamientos (métodos u operaciones) y las relaciones (a menudo referida como la multiplicidad, que describe el número de clases por lo general participan en la relación), y cardinalidad ( describe la participación requerida u opcional en la relación). Especificaciones información más elaborada y detalle que no se puede representar en el diagrama de clases.

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

Página 82 de 670

The Open Group Architecture Framework TOGOF 9.1   Ciertos sectores de la industria tienen las técnicas de modelado específicos para el sector de que se trate. Por ejemplo, el sector de Defensa utiliza los siguientes modelos.Estos modelos deben ser utilizados con cuidado, especialmente si la ubicación y realización de los procesos de negocio se verán alterados en el visionario Arquitectura Empresarial. 

El Diagrama de conectividad de nodo se describen los lugares de negocios (nodos), los "needlines" entre ellos, y las características de la información intercambiada. Conectividad de nodo se puede describir en tres niveles: conceptuales, lógicos y físicos. Cada needline indica la necesidad de algún tipo de transferencia de información entre los dos nodos conectados. Un nodo puede representar un papel (por ejemplo, un CIO), una unidad organizativa, un lugar de negocios o instalación, y así sucesivamente. Una flecha que indica la dirección del flujo de información se anota para describir las características de los datos o información - por ejemplo, su nivel de contenido, los medios de comunicación, la seguridad o la clasificación, la puntualidad, y los requisitos de interoperabilidad del sistema de información.



El Intercambio de Información Matrix documenta los requisitos de intercambio de información para una empresa de arquitectura. Requisitos de intercambio de información expresan las relaciones a través de tres entidades básicas (actividades, nodos de negocios y sus elementos, y el flujo de información), y se centran en las características del intercambio de información, como el rendimiento y la seguridad. Identifican que intercambia la información con quién, por qué es necesaria la información, y de qué manera.

Aunque originalmente desarrollado para su uso en el sector de la Defensa, estos modelos están encontrando cada vez mayor uso en otros sectores del gobierno, y también pueden ser considerados para su uso en entornos no-gubernamentales.

8.2.4 Arquitectura Repositorio Como parte de la fase B, el equipo de arquitectura tendrá que considerar lo que están disponibles en el repositorio de recursos Arquitectura Arquitectura Profesiones pertinentes (véase la Parte V , 41. Arquitectura Repositorio ), en particular: 

Modelos de negocio genéricos relacionados con el sector de la industria de la organización. Estos son "Arquitecturas Industria", en términos de la Empresa Continuum. Se llevan a cabo en la Biblioteca de la arquitectura de repositorio (véase la Parte V , 41,3 Reference Library ). Por ejemplo: o

El Grupo de Gestión de objetos (OMG) - www.omg.org - tiene una serie de grupos de trabajo de dominio de los modelos de negocio en desarrollo verticales relevante para dominios verticales específicos como la salud, Transporte, Finanzas, etc

o

El TeleManagement Forum (TMF) - www.tmforum.org - ha desarrollado modelos de negocio detallados relevante para la industria de las Telecomunicaciones.

o

Departamentos y agencias gubernamentales de los diferentes países tienen modelos y marcos de referencia obligatorios para el uso, la intención de promover la integración entre departamentos y la interoperabilidad. Un ejemplo es el modelo de negocio de referencia Federal Enterprise Architecture, que es un marco de la función de guiado para la descripción de las operaciones comerciales de la independiente del Gobierno Federal de los organismos que los realizan.

Página 83 de 670


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//mccarth4 ) de la Universidad Estatal de Michigan, principalmente para el modelado de sistemas de contabilidad. Ha demostrado ser tan útil para una mejor comprensión de los procesos de negocio que se ha convertido en uno de los principales marcos de modelos, tanto para las empresas tradicionales y los sistemas de comercio electrónico.

o

El Marco de STEP (estándar para el intercambio de datos del modelo del producto) se ocupa de diseño de producto y el interfuncionamiento cadena de suministro. STEP es un estándar ISO (ISO 10303). La aplicación de la norma STEP ha sido liderado por algunos grandes fabricantes aeroespaciales, y también se ha tenido en otras industrias que tienen una necesidad de complejos datos gráficos y de proceso, tales como la industria de la construcción.

o

RosettaNet - www.rosettanet.org - es un consorcio creado por las empresas líderes en el ordenador, componentes electrónicos, semiconductores y las cadenas de suministro de fabricación. Su misión es desarrollar un conjunto completo de los procesos de negocio electrónico estándar para estas cadenas de suministro, y promover y apoyar su adopción y uso.



Bloques de construcción específicas de la empresa (componentes de procesos, reglas de negocio, descripciones de puestos, etc.)



Normas aplicables.

8.3 Entradas Esta sección define las entradas a la Fase B.

8.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 8.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 

Principios de Actuación, los objetivos de negocio, y los conductores de negocios (véase la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los impulsores del negocio )







8.3.3 Entradas de arquitectura  Modelo de organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de Arquitectura ), incluyendo: o


Página 84 de 670




o


o


o


o


o




o


o




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



Principios Arquitectura (ver la Parte IV , 36.2.4 Principios Arquitectura ), incluidos los principios de negocios, al pre-existente



Continuum Empresarial (véase la Parte V , 39. Empresa Continuum )



Arquitectura repositorio (véase la Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo:





o

Bloques de construcción reutilizables

o

Modelos de referencia disponibles al público

o

Modelos de referencia específicos de la organización

o

Normas de la Organización

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

Descripción del problema

o


o

Vistas de resumen

o

Escenario empresarial (opcional)

o

Requisitos clave refinados de interesados de alto nivel

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

Línea de base de Empresas Arquitectura, Versión 0.1

o

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

Página 85 de 670



o


o

Objetivo Negocio Arquitectura, Versión 0.1

o

Tecnología Target Arquitectura, Versión 0.1

o


o


8.4 Pasos El nivel de detalle abordado en la Fase B dependerá del alcance y los objetivos del esfuerzo global de la arquitectura. Los nuevos procesos de negocio que se están introduciendo en el marco de este esfuerzo tendrá que ser definido en detalle durante la Fase B. procesos de negocio existentes y que se incorporen y apoyados en el entorno de destino pueden ya han definido adecuadamente en el trabajo arquitectónico anterior; pero, si no, ellos también tendrán que ser definidos en la Fase B. El orden de los pasos en la Fase B (véase más adelante), así como el momento en que se inician formalmente y completaron deben adaptarse a la situación en cuestión, de acuerdo con el gobierno arquitectura establecida. En particular, determinar si en esta situación, es oportuno proceder a línea de base o Arquitectura objetivo el desarrollo en primer lugar, como se describe en la Parte III , 19. Aplicando la iteración de la . Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante el paso Finalizar la Arquitectura de Negocios (ver 8.4.8 Finalizar la Arquitectura de Negocios ). La documentación generada a partir de estas medidas debe ser publicada oficialmente en la Arquitectura paso Crear definición de documento (ver 8.4.9 Crear Arquitectura Definición de documento ). Los pasos en la fase B son los siguientes: 

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



8.4.2 Desarrollar basal Arquitectura Descripción



8.4.3 Desarrollar Target Arquitectura Descripción



8.4.4 Realizar análisis de brechas



8.4.5 Definir candidatos Componentes Hoja de Ruta



8.4.6 Impactos Resolver Across the Landscape Architecture



8.4.7 Revisión de Conducta de las partes interesadas Formal



8.4.8 Finalizar la Arquitectura de Negocios

Página 86 de 670


8.4.9 Crear Arquitectura Definición de documento

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

Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de vista específico necesario, utilizando la herramienta o método seleccionado. Asegúrese de que todas las preocupaciones de los interesados están cubiertos. Si no es así, crear nuevos modelos para abordar las preocupaciones no están cubiertos, o aumentar los modelos existentes (véase 8.2.3 Modelado de Negocios ). Escenarios de negocios son una técnica muy útil para descubrir y documentar los requerimientos del negocio, y se pueden utilizar de forma iterativa, a diferentes niveles de detalle en la descomposición jerárquica de la Arquitectura Empresarial. Escenarios de negocio se describen en la Parte III , 26. Escenarios empresariales y objetivos de negocio . Se mencionan los modelos de actividad, los modelos de casos de uso, y los modelos de la clase anterior como técnicas que permitan la definición de la arquitectura de negocio de una organización. En muchos casos, los tres enfoques pueden ser utilizados en secuencia para descomponer progresivamente un negocio. 

Análisis Estructurado : Identifica las funciones clave de negocio en el ámbito de la arquitectura, y los mapas de aquellas funciones en las unidades de la organización dentro de la empresa.



Use caso Análisis : El detalle de las funciones de nivel empresarial a través de actores y organizaciones permite que los actores de una función para ser identificados y permite una interrupción en los servicios de apoyo / entrega de esa capacidad funcional.



Modelado de Procesos : El detalle de una función o servicio de negocio a través de la modelización de procesos permite que los elementos del proceso de ser identificados, y permite la identificación de los servicios a las empresas de menor nivel o funciones.

El nivel y el rigor de la descomposición necesaria varía de una empresa a otra, así como dentro de una empresa, y el arquitecto deben tener en cuenta los objetivos de la empresa, los objetivos, el

Página 87 de 670

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

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

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

Catálogo de Organización / Actor



Conductor / Meta / Objetivo catálogo



Catálogo de funciones

Página 88 de 670


Catálogo de servicios de negocios / Función



Ubicación catálogo



Proceso / Evento / Control / Catálogo de productos



Catálogo Contract / Medida

La estructura de catálogos se basa en los atributos de las entidades metamodelo, según se define en la Parte IV , 34. Metamodel contenido . 8.4.1.4 Identificar Matrices requeridos

Matrices muestran las relaciones básicas entre las entidades del modelo relacionado. Las matrices son la materia prima para el desarrollo de puntos de vista y también actúan como un recurso clave para la evaluación del impacto, realizado como parte del análisis de brecha. Las siguientes matrices deben ser considerados para el desarrollo dentro de una arquitectura de negocios: 

Matriz de interacción de negocios (mostrando la dependencia y la comunicación entre las organizaciones y actores)



Matriz Actor / papel (mostrando los roles asumidos por cada actor)

La estructura de las matrices se basa en los atributos de las entidades metamodelo, según se define en la Parte IV , 34. Metamodel contenido . 8.4.1.5 Identificar los diagramas requeridos

Diagramas presentan la información Arquitectura de Negocios de un conjunto de diferentes perspectivas (puntos de vista) de acuerdo a los requisitos de las partes interesadas. Los siguientes diagramas deben ser considerados para el desarrollo dentro de una arquitectura de negocios: 

Diagrama de Huella de negocios



Diagrama de Business Service / Information



Diagrama de descomposición funcional



Meta / Objetivo diagrama / Servicio



Diagrama de casos de uso



Organización diagrama de descomposición



Diagrama de Flujo del Proceso



Eventos diagrama

Página 89 de 670

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

Una vez que los catálogos de Arquitectura de Negocios, matrices y diagramas han sido desarrollados, modelado de arquitectura se completa mediante la formalización de los requerimientos de negocio centrada en la implementación de la arquitectura destino. Estos requisitos pueden: 

Se relacionan con el ámbito empresarial



Proporcionar los requisitos de entrada en las arquitecturas de datos, aplicaciones y Tecnología



Proporcionar orientaciones detalladas que se refleja en el diseño e implementación para asegurar que la solución satisface los requisitos de arquitectura originales

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

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

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

Página 90 de 670

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

8.4.4 Realizar análisis de brechas Verifique los modelos de arquitectura para la coherencia y la precisión interna: 

Realizar análisis de trade-off para resolver conflictos (si los hay) entre los diferentes puntos de vista



Validar que los modelos son compatibles con los principios, objetivos y limitaciones



Nota cambios en el punto de vista representado en los modelos seleccionados desde el repositorio de Arquitectura, y el documento



Modelos de arquitectura de prueba para la integridad frente a los requisitos

Identificar las brechas entre la línea base y de destino, utilizando la técnica de análisis de carencias como se describe en la Parte III , 27. Análisis Gap .

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

8.4.6 Impactos Resolver Across la Arquitectura del Paisaje Una vez que la arquitectura de negocio se ha finalizado, hay que entender cualquier impacto o implicaciones más amplias. En esta etapa, otros artefactos de arquitectura en la arquitectura del paisaje deben ser examinados para identificar: 

¿Crea esta arquitectura de negocio un impacto en las arquitecturas preexistentes?



¿Se han hecho los cambios recientes que impactan en la Arquitectura de Negocios?



¿Hay oportunidades para aprovechar el trabajo de esta arquitectura de negocio en otras áreas de la organización?

Página 91 de 670


¿Impacta esta arquitectura de negocio otros proyectos (incluidos los previstos, así como los actualmente en curso)?



¿Será este negocio Arquitectura verse afectado por otros proyectos (incluidos los previstos, así como los actualmente en curso)?

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

8.4.8 Finalizar la Arquitectura de Negocios  Seleccione estándares para cada uno de los bloques de construcción, reutilizando la mayor cantidad posible de los modelos de referencia seleccionados del repositorio Arquitectura 

Documentar completamente cada bloque de construcción



Realizar última comprobación cruzada de la arquitectura global contra objetivos de negocio; documento de justificación de la construcción de las decisiones del bloque en el documento de la arquitectura



Documento Final informe requisitos de trazabilidad



Documento de asignación definitiva de la arquitectura dentro del Repositorio de Arquitectura; de los bloques de construcción seleccionados, identificar las que podrían ser re-utilizado (las prácticas de trabajo, roles y relaciones de negocio, descripciones de puestos, etc), y publican a través del Repositorio de Arquitectura



Finalice todos los productos de trabajo, tales como los resultados de análisis de carencias

8.4.9 Crear Arquitectura Definición de documento  Justificación del documento para la construcción de bloquear decisiones en la definición de documento Arquitectura 

Preparar las secciones de negocios de la definición de documento de Arquitectura, que comprende una parte o todos los siguientes: o

La huella de la empresa (una descripción de alto nivel de la gente y los lugares que participan en las funciones clave del negocio)

o

Una descripción detallada de las funciones de negocio y sus necesidades de información

o

La huella de la gestión (mostrando ámbito de control y rendición de cuentas)

o

Normas, reglas y directrices que muestran prácticas de trabajo, legislación, medidas financieras, etc

o

Una matriz de habilidades y un conjunto de descripciones de puestos

Página 92 de 670

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

8.5 Salidas Los resultados de la Fase B pueden incluir, pero no se limitan a: 



Las versiones refinadas y actualizadas de los entregables de la fase Arquitectura Visión, en su caso, entre ellos: o

Declaración de Arquitectura de trabajo (véase la Parte IV , 36.2.20 Declaración de Arquitectura de Trabajo ), actualizado en caso necesario

o

Validado principios de negocio, objetivos de negocio, y los conductores de negocios (véase la Parte IV , 36.2.9 Principios de Actuación, objetivos de negocio, y los impulsores del negocio ), actualizadas si es necesario

o

Principios Arquitectura (ver la Parte IV , 36.2.4 Principios de Arquitectura )

Proyecto de Arquitectura de definición de documento (ver la Parte IV , 36.2.3 Arquitectura de definición de documento ), incluyendo: o

Línea de base de Empresas Arquitectura, Version 1.0 (detallado), si procede

o

Objetivo Negocio Arquitectura, Version 1.0 (detallado), incluyendo:

o



Estructura de la organización - la identificación de lugares de negocios y relacionándolos con las unidades organizativas



Los objetivos de negocio y objetivos - para la empresa y cada unidad organizativa



Funciones de negocio - un detallado paso, recursivo implica sucesiva descomposición de las principales áreas funcionales en subfunciones



Servicios de negocio - los servicios que la empresa y cada unidad de la empresa proporciona a sus clientes, tanto internos como externos



Los procesos de negocio, incluidas las medidas y resultados



Las funciones de negocio, incluyendo el desarrollo y la modificación de las necesidades de competencias



Modelo de datos de negocios



La correlación de la organización y funciones - se relacionan las funciones de negocio a las unidades organizativas en la forma de un informe de matriz

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

Página 93 de 670




Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo dichos requisitos y efectos Arquitectura Profesiones como: o

Los resultados del análisis de Gap

o

Requisitos técnicos - Identificar, categorizar y priorizar las implicaciones para el trabajo en los ámbitos de arquitectura restantes; por ejemplo, por una matriz de dependencia / prioridad (por ejemplo, guiando el comercio entre la velocidad de procesamiento de transacciones y de seguridad); una lista de los modelos específicos que se esperan a producirse (por ejemplo, expresado como primitivas del Marco Zachman)

o

Requisitos de negocio actualizados

Componentes de la arquitectura de negocios de una Arquitectura Roap (ver la Parte IV , 36.2.7 Arquitectura Roap )






Catálogos: o

Catálogo de Organización / Actor

o

Conductor / Meta / Objetivo catálogo

o


o

Catálogo de servicios de negocios / Función

o


o

Proceso / Evento / Control / Catálogo de productos

o

Catálogo Contract / Medida

Matrices: o

Matriz de interacción de negocios

o

Matriz Actor / Rol

Diagramas: o

Diagrama de Huella de negocios

o

Diagrama de Business Service / Information

o

Diagrama de descomposición funcional

o

Diagrama del ciclo de vida del producto

o


o

Diagrama de casos de uso

Página 94 de 670


Organización diagrama de descomposición

o

Diagrama de Flujo del Proceso

o

Diagrama de eventos

Página 95 de 670


9 Fase C:. Arquitecturas de Sistemas de Información En este capítulo se describen las arquitecturas de los sistemas de información para un proyecto de arquitectura, incluyendo el desarrollo de datos y aplicación de arquitecturas.

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

9.1 Objetivos Los objetivos de la Fase C son: 

Desarrollar los sistemas de información del objetivo (datos y aplicaciones) Arquitectura, describiendo cómo los Sistemas de Información Arquitectura de la empresa permitirá a la Arquitectura de Negocios y el Architecture Vision, de una manera que se dirige la solicitud de Arquitectura Trabajo y preocupaciones de los interesados



Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de las brechas entre las arquitecturas de referencia y sistemas de información del objetivo (Application Data y)


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

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






9.3.3 Entradas de arquitectura  Modelo de organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de Arquitectura ), incluyendo:



o


o


o


o


o


o




o


o


Página 97 de 670


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



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



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



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










o


o


o




o

Objetivo Negocio Arquitectura, Version 1.0 (detallado)

o


o


o


o


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

Los resultados del análisis de Gap (de Arquitectura Empresarial)

o

Requisitos técnicos pertinentes que se aplicarán 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 Información - Arquitectura de Datos



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

9.5 Salidas Página 98 de 670

The Open Group Architecture Framework TOGOF 9.1   Los principales resultados de la Fase C son: 

Las versiones refinadas y actualizadas de los entregables de la fase Arquitectura Visión, en su caso, entre ellos: o










o


o


o

Objetivo de Arquitectura de aplicaciones, versión 1.0

o

Puntos de vista de arquitectura de datos correspondientes a los puntos de vista seleccionados abordar las principales preocupaciones de las partes interesadas

o

Vistas Arquitectura Aplicación correspondientes a los puntos de vista seleccionados abordar las preocupaciones de interés clave

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo dichos requisitos de Sistemas de Información Arquitectura como: o


o

Requisitos técnicos pertinentes que se aplicarán a esta evolución del ciclo de desarrollo de la arquitectura

o

Las restricciones en la Arquitectura de Tecnología a punto de ser diseñados

o

Requisitos de negocio actualizados, en su caso

Componentes de los sistemas de información de una Arquitectura Roap (ver la Parte IV , 36.2.7 Arquitectura Roap )



Página 99 de 670


. 10 Fase C: Arquitecturas de Sistemas de Información - Arquitectura de Datos En este capítulo se describe la parte Arquitectura de datos de la Fase C.

10.1 Objetivos Los objetivos de la parte Arquitectura de datos de la Fase C son: 

Desarrollar la arquitectura de datos de destino que permite a la Arquitectura de Negocios y el Architecture Vision, al dirigirse a la Solicitud de Arquitectura Trabajo y preocupaciones de los interesados



Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de las brechas entre la línea de base y datos de destino Arquitecturas

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

Cuando una empresa ha optado por realizar la transformación arquitectónica gran escala, es importante para comprender y abordar los problemas de gestión de datos. Un enfoque estructurado y global de la gestión de datos permite el uso eficaz de los datos para sacar provecho de sus ventajas competitivas. Las consideraciones incluyen: 

Una definición clara de lo que los componentes de aplicación en el paisaje servirán como el sistema de registro o de referencia para los datos maestros de la empresa



¿Habrá un estándar en toda la empresa que todos los componentes de la aplicación, incluyendo los paquetes de software, tienen que adoptar (en los paquetes principales pueden ser preceptivo sobre los modelos de datos y no puede ser flexible)?



Entender claramente cómo las entidades de datos son utilizados por las funciones de negocio, procesos y servicios



Entender claramente cómo y cuando las entidades de datos de empresas se crean, almacenan, transportan, e informó



¿Cuál es el nivel y la complejidad de las transformaciones de datos requeridas para apoyar las necesidades de intercambio de información entre las aplicaciones?



¿Cuál será el requisito para el software en el apoyo a la integración de datos con los clientes de la empresa y los proveedores (por ejemplo, el uso de herramientas de ETL

Página 100 de 670

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

Cuando se sustituye una aplicación existente, habrá una necesidad crítica para migrar datos (master, transaccionales y de referencia) para la nueva aplicación. La Arquitectura de Datos debe determinar las necesidades de migración de datos y también proporcionar indicadores sobre el nivel de la transformación, la escarda, y la limpieza que se requiere para presentar los datos en un formato que cumpla con las exigencias y limitaciones de la aplicación de destino. El objetivo es que la aplicación de destino tiene datos de calidad cuando está poblado. Otra consideración clave es asegurarse de que una definición común de datos en toda la empresa se estableció para apoyar la transformación. 10.2.1.3 Data Governance

Consideraciones de gobernabilidad de datos asegurarse de que la empresa tiene las dimensiones necesarias en el lugar para permitir la transformación, de la siguiente manera: 

Estructura : Esta dimensión se refiere a si la empresa tiene la estructura organizativa necesaria y los organismos de normalización para gestionar aspectos de entidad de datos de la transformación.



Sistema de Gestión : Aquí las empresas deben tener el sistema de gestión necesarias y los programas relacionados con los datos para gestionar los aspectos de la gobernanza de las entidades de datos a lo largo de su ciclo de vida.



Gente : Esta dimensión aborda cuáles son las habilidades y roles de la empresa relacionadas con los datos requiere para la transformación. Si la empresa carece de este tipo de recursos y competencias, la empresa debe considerar o bien la adquisición de esas habilidades críticas o capacitación de los recursos internos existentes para satisfacer las necesidades a través de un programa de aprendizaje bien definidos.

10.2.2 Arquitectura Repositorio Como parte de esta fase, el equipo de arquitectura tendrá que considerar qué recursos están disponibles arquitectura de datos pertinentes en la arquitectura de repositorio de la organización (véase la Parte V , 41. Arquitectura Repositorio ), en particular, los modelos de datos genéricos relacionados con la industria de la organización "vertical" sector. Por ejemplo: 

ARTES ha definido un modelo de datos para la industria al por menor.



Energistics ha definido un modelo de datos para la industria petrotécnicos.

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


Página 101 de 670






10.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de Arquitectura ), incluyendo:



o


o


o


o


o


o




o


o




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












o

Bloques de construcción reutilizables (en particular, las definiciones de los datos actuales)

o


o


o


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

Página 102 de 670






o


o


o

Arquitectura de datos de línea de base, Versión 0.1, si está disponible

o

Arquitectura de datos de destino, Versión 0.1, si está disponible

o

Línea de base de arquitectura de aplicaciones, versión 1.0 (detallada) o Versión 0.1 (Vision)

o

Objetivo de Arquitectura de aplicaciones, versión 1.0 (detallada) o Versión 0.1 (Vision)

o

Línea de Base Tecnológica de Arquitectura, Version 0.1 (Vision)

o

Tecnología Target Arquitectura, Version 0.1 (Vision)


Los resultados del análisis de Gap (de Arquitectura Empresarial)

o

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


Página 103 de 670


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



10.4.3 Desarrollar Arquitectura de Datos de Blanco Descripción



10.4.4 Realizar el Análisis Gap









Conducta 10.4.7 Stakeholder Formal Comentario



10.4.8 Finalizar la Arquitectura de Datos




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

Diagrama entidad-relación



Los diagramas de clases

10.4.1.1 Determinar Proceso general Modeling

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

Página 104 de 670

The Open Group Architecture Framework TOGOF 9.1   Asegúrese de que todas las preocupaciones de los interesados están cubiertos. Si no es así, crear nuevos modelos para abordar las preocupaciones no están cubiertos, o aumentar los modelos existentes (véase más arriba). El proceso recomendado para el desarrollo de una Arquitectura de datos es la siguiente: 

Recoger los modelos relacionados con los datos de Business Architecture existente y materiales de la arquitectura de aplicaciones



Racionalizar los requisitos de datos y se alinean con ningún catálogo de datos empresariales existentes y modelos; esto permite el desarrollo de una relación de inventario de datos y de la entidad



Actualizar y desarrollar matrices a través de la arquitectura, relacionando los datos de servicio de negocio, función empresarial, los derechos de , y la aplicación



Elaborar vistas Arquitectura de datos mediante el examen de cómo se crean los datos, distribuida, emigrado, asegurado, y se archivan

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

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

Catálogo de Entity Data / componente de datos


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

Página 105 de 670

The Open Group Architecture Framework TOGOF 9.1   Las matrices son la materia prima para la elaboración de diagramas y también actúan como un recurso clave para la evaluación del impacto. En esta etapa, una entidad a la matriz de aplicaciones podría ser producido para validar este mapeo. ¿Cómo se crea de datos, mantienen, transforman y pasan a otras aplicaciones, o utilizados por otras aplicaciones, ahora comenzará a ser entendido. Lagunas evidentes, tales como las entidades que nunca parecen ser creado por una aplicación o de datos creada pero nunca utilizado, deben observarse para el análisis de brecha más tarde. El inventario de datos racionalizada se puede utilizar para actualizar y refinar los diagramas de arquitectura de cómo los datos se refiere a otros aspectos de la arquitectura. Una vez realizados estos cambios, puede ser adecuado para caer en un corto iteración de Arquitectura de aplicaciones para resolver los cambios identificados. Las siguientes matrices deben ser considerados para el desarrollo dentro de una Arquitectura de Datos: 

Entity Data / Función comercial (que muestran qué datos apoyan que funciona y qué función negocio posee qué datos)



Servicios de Negocio / Información (desarrollada durante la fase de Arquitectura Empresarial)



Aplicación / datos (desarrollado a través de las fases de la arquitectura de aplicaciones y arquitectura de datos)

La estructura de las matrices se basa en los atributos de las entidades metamodelo, según se define en la Parte IV , 34. Metamodel contenido . 10.4.1.4 Identificar Diagramas requeridos

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

Página 106 de 670

The Open Group Architecture Framework TOGOF 9.1   Los siguientes diagramas deben ser considerados para el desarrollo dentro de una Arquitectura de Datos: 

Diagrama conceptual de datos



Diagrama de lógica de datos



Diagrama de Divulgación de Datos



Diagrama del ciclo de vida de datos



Diagrama de seguridad de datos



Diagrama de migración de datos

10.4.1.5 Identificar los tipos de Requisito para ser Collected

Una vez que los catálogos de arquitectura de datos, matrices y diagramas han sido desarrollados, modelado de arquitectura se completa mediante la formalización de los requisitos de datos enfocada para la implementación de la arquitectura destino. Estos requisitos pueden: 

Se relacionan con el dominio de datos



Proporcionar los requisitos de entrada en la aplicación y Tecnología Arquitecturas




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

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

Página 107 de 670

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

10.4.4 Realizar el Análisis Gap Verifique los modelos de arquitectura para la coherencia y la precisión interna: 












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

10.4.6 Impactos Resolver Across la Arquitectura del Paisaje Una vez que la Arquitectura de Datos ha finalizado, es necesario entender los impactos o repercusiones más amplias. En esta etapa, otros artefactos de arquitectura en la arquitectura del paisaje deben ser examinados para identificar: 

¿Crea esto Arquitectura de Datos un impacto en las arquitecturas preexistentes?



¿Se han hecho los cambios recientes que impactan la Arquitectura de Datos?

Página 108 de 670


¿Hay oportunidades para aprovechar el trabajo de esta arquitectura de datos en otras áreas de la organización?



¿Impacta esta arquitectura de datos de otros proyectos (incluyendo los previstos, así como los actualmente en curso)?



¿Esto Arquitectura de Datos verse afectado por otros proyectos (incluidos los previstos, así como los actualmente en curso)?

Conducta 10.4.7 Stakeholder Formal Comentario Compruebe la motivación original para el proyecto de la arquitectura y la Declaración de Arquitectura de Trabajo contra la arquitectura de datos propuesto. Llevar a cabo un análisis de impacto para identificar las áreas donde las arquitecturas empresariales y de aplicaciones (por ejemplo, prácticas de negocios) puede que tenga que cambiar para atender a los cambios en la arquitectura de datos (por ejemplo, cambios en las formas o procedimientos, aplicaciones o sistemas de base de datos). Si el impacto es significativo, esto puede justificar las Arquitecturas Empresariales y de aplicación está revisando. Identifique las áreas en las que la arquitectura de la aplicación (si se generan en este punto) puede tener que cambiar para atender a los cambios en la arquitectura de datos (o para identificar las limitaciones en la arquitectura de la aplicación a punto de ser diseñados). Si el impacto es significativo, puede ser apropiado para caer en una breve versión de la arquitectura de aplicaciones en este punto. Identificar las posibles limitaciones de la arquitectura de la tecnología a punto de ser diseñados, el perfeccionamiento de la Arquitectura de Datos propuesta sólo si es necesario.

10.4.8 Finalizar la Arquitectura de Datos  Seleccione estándares para cada uno de los bloques de construcción, reutilizando la mayor cantidad posible de los modelos de referencia seleccionados del repositorio Arquitectura 




Realizar última comprobación cruzada de la arquitectura general de los requerimientos del negocio; documento de justificación de la construcción de las decisiones del bloque en el documento de la arquitectura






Documento de asignación definitiva de la arquitectura dentro del Repositorio de Arquitectura; de los bloques de construcción seleccionados, identificar las que podrían ser reutilizados, y publicar a través del Repositorio de Arquitectura



Finalice todos los productos de trabajo, tales como análisis de las deficiencias

Página 109 de 670

The Open Group Architecture Framework TOGOF 9.1   10.4.9 Crear Arquitectura Definición de documento Justificación del documento para la construcción de bloquear decisiones en la definición de documento Architecture. Preparar arquitectura de datos de secciones de la definición de documento Arquitectura, que comprende algunos o todos de: 




Modelo de datos lógicos



Modelo de proceso de gestión de datos



Entity Data / matriz de funciones de negocios



Requisitos de interoperabilidad de datos (por ejemplo, el esquema XML, las políticas de seguridad)



En su caso, utilizar los informes y / o gráficos generados por las herramientas para demostrar puntos de vista clave de la arquitectura de modelado; direccionar el documento para su examen por los interesados, e incorporar la retroalimentación

10.5 Salidas Los resultados de la Fase C (Arquitectura de datos) pueden incluir, pero no se limitan a: 



Las versiones refinadas y actualizadas de los entregables de la fase Arquitectura Visión, en su caso: o


o

Principios datos validados (véase la Parte III , 23.6.2 Datos Principios ), o nuevos principios de datos (si se generan aquí)


Arquitectura de datos de línea de base, la versión 1.0, en su caso

o


o






Modelo de datos lógicos



Modelos de procesos de gestión de datos





Página 110 de 670




Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo dichos requisitos arquitectura de datos como: o


o

Requisitos de interoperabilidad de datos

o


o


o


o

Requisitos de las aplicaciones actualizadas, en su caso

Componentes de la arquitectura de datos de una Arquitectura Roap (ver la Parte IV , 36.2.7 Arquitectura Roap )


Catálogos: o





Catálogo de Entity Data / componente de datos

Matrices: o


o

Aplicación / matriz de datos

Diagramas: o

Diagrama conceptual de datos

o


o


o


o


o


Página 111 de 670


. 11 Fase C: Arquitecturas de Sistemas de Información - Arquitectura de la aplicación Contenido del capítulo 11.1 Objetivos  |  11.2 Enfoque  |  11.3 entradas  |  11.4 Pasos  |  11.5 Salidas

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

11.1 Objetivos Los objetivos de la parte Arquitectura de la aplicación de la Fase C son: 

Desarrollar la Arquitectura de aplicación de destino que permite a la Arquitectura de Negocios y el Architecture Vision, al dirigirse a la Solicitud de Arquitectura Trabajo y preocupaciones de los interesados



Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de las brechas entre la línea de base y objetivo de aplicación de arquitecturas

11.2 Enfoque 11.2.1 Arquitectura Repositorio Como parte de esta fase, el equipo de arquitectura tendrá que considerar qué recursos están disponibles arquitectura de aplicaciones relevantes en la arquitectura de repositorio (véase la Parte V , 41. Arquitectura del repositorio ). En particular: 



Modelos de negocio genéricos relacionados con la industria del sector "vertical" de la organización; por ejemplo: o

El TeleManagement Forum (TMF) - www.tmforum.org - ha desarrollado modelos detallados aplicaciones relevantes para la industria de las Telecomunicaciones.

o

El Grupo de Gestión de objetos (OMG) - www.omg.org - tiene una serie de grupos de trabajo de dominio de los modelos de software en desarrollo verticales relevante para dominios verticales específicos como la salud, Transporte, Finanzas, etc

Modelos de aplicación pertinentes a las funciones de negocio de alto nivel comunes, tales como el comercio electrónico, gestión de la cadena de suministro, etc

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

Página 112 de 670

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

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









o


o


o


o


o


o




o


o




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









Arquitectura repositorio (véase la Parte IV , 36.2.5 Arquitectura del repositorio ), incluyendo: o


Página 113 de 670








o


o


o




o


o

Arquitectura de línea de base de datos, versión 1.0 (detallados), o la Versión 0.1 (Vision)

o

Arquitectura Meta Data, versión 1.0 (detallados), o la Versión 0.1 (Vision)

o

Línea de base de arquitectura de aplicaciones, Versión 0.1, si está disponible adecuado y si

o

Objetivo de Arquitectura de aplicaciones, Versión 0.1, si está disponible

o

Línea de Base Tecnológica de Arquitectura, Version 0.1 (Vision)

o

Tecnología Target Arquitectura, Version 0.1 (Vision)


Los resultados del análisis de Gap (de Arquitectura de Negocios y Arquitectura de datos, si está disponible)

o

Requisitos técnicos pertinentes que se aplicarán a esta fase

Los componentes empresariales y arquitectura de datos de una hoja de ruta de la Arquitectura, en su caso (véase la Parte IV , 36.2.7 Arquitectura Roap )

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

Página 114 de 670

The Open Group Architecture Framework TOGOF 9.1   Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante el paso Finalizar la Arquitectura de la aplicación (ver 11.4.8 finalizar la Arquitectura de la aplicación ). La documentación generada a partir de estas medidas debe ser publicada oficialmente en la Arquitectura paso Crear definición de documento (ver 11.4.9 Crear Arquitectura Definición de documento ). Los pasos en la Fase C (Arquitectura de aplicaciones) son las siguientes: 




11.4.2 Desarrollar Línea Base Application Architecture Descripción



11.4.3 Desarrollar Target Application Architecture Descripción















11.4.8 Finalizar la arquitectura de aplicaciones




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

Página 115 de 670

The Open Group Architecture Framework TOGOF 9.1   11.4.1.1 Determinar Proceso general Modeling

Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de vista específico necesario, utilizando la herramienta o método seleccionado. Asegúrese de que todas las preocupaciones de los interesados están cubiertos. Si no es así, crear nuevos modelos para abordar las preocupaciones no están cubiertos, o aumentar los modelos existentes (véase más arriba). El proceso recomendado para el desarrollo de una Arquitectura de la aplicación es la siguiente: 

Comprender la lista de aplicaciones o componentes de aplicaciones que se requieren, sobre la base de la línea de base del portafolio de aplicaciones, cuáles son los requisitos, y el alcance de arquitectura empresarial



Simplifique aplicaciones complejas mediante la descomposición en dos o más solicitudes



Asegúrese de que el conjunto de definiciones de aplicación es internamente coherente, mediante la eliminación de la funcionalidad duplicado medida de lo posible, y la combinación de aplicaciones similares en uno



Identificar las aplicaciones lógicas y las aplicaciones físicas más adecuadas



Desarrollar matrices a través de la arquitectura, relacionando aplicaciones al servicio de negocios, evento de negocios, datos, procesos, etc



Elaborar un conjunto de puntos de vista de arquitectura de aplicaciones mediante el examen de cómo funcionará la aplicación, la captura de la integración, la migración, el desarrollo y las preocupaciones operacionales

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

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

Página 116 de 670

The Open Group Architecture Framework TOGOF 9.1   Los siguientes catálogos deben ser considerados para el desarrollo dentro de una arquitectura de aplicaciones: 

Catálogo de la cartera de aplicaciones



Catálogo de interfaz

11.4.1.3 Identificar Matrices requeridos

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

Aplicación de la matriz / Organización

Página 117 de 670


Matriz de Papel / Aplicación



Matriz de interacción Aplicación



Matriz de Aplicación / Función

La estructura de las matrices se basa en los atributos de las entidades metamodelo, según se define en la Parte IV , 34. Metamodel contenido . 11.4.1.4 Identificar Diagramas requeridos

Diagramas presentan la información Arquitectura de la aplicación de un conjunto de diferentes perspectivas (puntos de vista) de acuerdo a los requisitos de las partes interesadas. Una vez conocida la funcionalidad deseada de una aplicación, es necesario realizar una evaluación interna de cómo debe estructurarse la aplicación para satisfacer sus necesidades. En el caso de aplicaciones empaquetadas, es probable que sea el caso de que la aplicación es compatible con una serie de opciones de configuración, módulos adicionales, o los servicios de aplicaciones que se pueden aplicar a la solución. Para las aplicaciones desarrolladas a medida, es necesario identificar la estructura de alto nivel de la aplicación en términos de módulos o subsistemas como base para organizar la actividad de diseño. Los siguientes diagramas deben ser considerados para el desarrollo dentro de una arquitectura de aplicaciones: 

Diagrama de comunicaciones de la aplicación



Aplicación y diagrama Ubicación



Diagrama de istración de Enterprise



Diagrama Realización de proceso / aplicación



Diagrama de Migración de aplicaciones



Diagrama de distribución de software



Software diagrama de Ingeniería



Esquema de aplicación de casos de uso

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

Una vez que los catálogos de arquitectura de la aplicación, matrices y diagramas han sido desarrollados, modelado de arquitectura se completa mediante la formalización de los requisitos de las aplicaciones enfocadas para la implementación de la arquitectura destino. Estos requisitos pueden:

Página 118 de 670


Se relacionan con el dominio de aplicación



Proporcionar los requisitos de entrada en las arquitecturas de datos y tecnología




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

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

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






Página 119 de 670







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

11.4.6 Impactos Resolver Across la Arquitectura del Paisaje Una vez que la arquitectura de la aplicación se finaliza, es necesario entender los impactos o repercusiones más amplias. En esta etapa, otros artefactos de arquitectura en la arquitectura del paisaje deben ser examinados para identificar: 

¿Crea esta arquitectura de aplicaciones un impacto en las arquitecturas preexistentes?



¿Se han hecho los cambios recientes que impactan la arquitectura de aplicaciones?



¿Hay oportunidades para aprovechar el trabajo de esta arquitectura de aplicaciones en otras áreas de la organización?



¿Impacta esta arquitectura de aplicaciones de otros proyectos (incluyendo los previstos, así como los actualmente en curso)?



¿Esta arquitectura de aplicaciones verse afectado por otros proyectos (incluidos los previstos, así como los actualmente en curso)?

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

Página 120 de 670

The Open Group Architecture Framework TOGOF 9.1   11.4.8 Finalizar la arquitectura de aplicaciones  Seleccione estándares para cada uno de los bloques de construcción, reutilizando la mayor cantidad posible de los modelos de referencia seleccionados del repositorio Arquitectura 




Realizar última comprobación cruzada de la arquitectura general de los requerimientos del negocio; documento de justificación de la construcción de las decisiones del bloque en el documento de la arquitectura






Documento de asignación definitiva de la arquitectura dentro del Repositorio de Arquitectura; de los bloques de construcción seleccionados, identificar las que podrían ser reutilizados, y publicar a través del Repositorio de Arquitectura




11.4.9 Crear Arquitectura Definición de documento  Justificación del documento para la construcción de bloquear decisiones en la definición de documento Arquitectura 

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

11.5 Salidas Los resultados de la Fase C (Arquitectura de la aplicación) pueden incluir, pero no se limitan a: 





o

Principios de aplicación validados, o nuevos principios de aplicación (si se generan aquí)


Línea de base de arquitectura de aplicaciones, la versión 1.0, en su caso

o

Objetivo de Arquitectura de aplicaciones, versión 1.0 

Modelo de sistemas de proceso



Modelo de sistemas Place



Tiempo modelo de sistemas

Página 121 de 670

The Open Group Architecture Framework TOGOF 9.1    o 



Modelo de sistemas Gente

Vistas correspondiente a los puntos de vista seleccionados, abordar las preocupaciones de interés clave

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo dichos requisitos arquitectura de aplicaciones como: o


o

Aplicaciones requisitos de interoperabilidad

o


o


o


o

Requisitos de datos actualizadas, en su caso

Componentes de la arquitectura de aplicación de una Arquitectura Roap (ver la Parte IV , 36.2.7 Arquitectura Roap )






Catálogos: o

Catálogo de la cartera de aplicaciones

o


Matrices: o

Aplicación de la matriz / Organización

o

Matriz de Papel / Aplicación

o

Matriz de Aplicación / Función

o

Matriz de interacción Aplicación

Diagramas: o

Diagrama de comunicaciones de la aplicación

o

Aplicación y diagrama Ubicación

o

Esquema de aplicación de casos de uso

o


o


Página 122 de 670



o


o


Página 123 de 670


. 12 Fase D: Architecture Tecnología En este capítulo se describe el desarrollo de una arquitectura de tecnología para un proyecto de arquitectura.

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

12.1 Objetivos Los objetivos de la Fase D son: 

Desarrollar la Arquitectura Tecnológica Objetivo que permite la aplicación lógica y física y los componentes de datos y el Architecture Vision, dirigiéndose a la Solicitud de Arquitectura Trabajo y preocupaciones de los interesados



Identificar los componentes de la Hoja de Ruta Arquitectura candidatos sobre la base de las brechas entre la tecnología objetivo Arquitecturas de referencia y


The Open Group Architecture Framework TOGOF 9.1   12.2.1 Arquitectura Repositorio Como parte de la fase D, el equipo de arquitectura tendrá que considerar qué recursos están disponibles Arquitectura Tecnología relevantes en la arquitectura de repositorio (véase la Parte V , 41. Arquitectura del repositorio ). En particular: 

Servicios de TI existentes tal como se documenta en el repositorio de IT o catálogo de servicios de TI



TOGAF Modelo Referencia técnica (TRM)



Modelos tecnológicos genéricos relacionados con la industria del sector "vertical" de la organización Por ejemplo, el TeleManagement Forum (TMF) - www.tmforum.org - ha desarrollado modelos de tecnología detallados relacionados con la industria de las Telecomunicaciones.



Modelos de tecnología relevante para los sistemas comunes Arquitecturas Por ejemplo, The Open Group cuenta con un modelo de referencia para la Información Integrada de Infraestructura (III-RM) - véase la parte VI , 44. Integrado de Información Infraestructura Modelo de referencia - que se centra en los componentes de nivel de aplicación y servicios básicos necesarios para proporcionar una infraestructura de información integrada.

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

12.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 

Información del producto en productos candidatos

12.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) 





12.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de Arquitectura ), incluyendo: o


o


Página 125 de 670




o


o


o


o




o


o




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














o


o


o


o



Línea de base de Empresas Arquitectura, Version 1.0 (detallado)

o

Target Business Architecture Version 1.0 (detallado)

o

Arquitectura de datos de línea de base, versión 1.0 (detallado)

o

Arquitectura de datos de destino, Versión 1.0 (detallado)

o

Línea de base de arquitectura de aplicaciones, versión 1.0 (detallado)

o

Objetivo de Arquitectura de aplicaciones, versión 1.0 (detallado)

o

Línea de Base Tecnológica de Arquitectura, Versión 0.1 (la visión)

o

Tecnología Target Arquitectura, Versión 0.1 (la visión)

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo:

Página 126 de 670




o

Los resultados del análisis de Gap (de negocios, datos, y aplicación de arquitecturas)

o

Requisitos técnicos pertinentes de las fases anteriores

Los componentes empresariales, datos y arquitectura de la aplicación de una Arquitectura Roap (ver la Parte IV , 36.2.7 Arquitectura Roap )

12.4 Pasos El nivel de detalle abordado en la Fase D dependerá del alcance y los objetivos del esfuerzo global de la arquitectura. Bloques de construcción nueva tecnología que se introducen como parte de este esfuerzo tendrá que ser definido en detalle durante la Fase D. existente bloques de construcción de tecnología para ser itidos en el entorno de destino pueden tener que redefinirse en la Fase D para garantizar la interoperabilidad y adaptarse a sus fines dentro de esta arquitectura tecnología específica. El orden de los pasos en la Fase D (véase más adelante), así como el momento en que se inician formalmente y completaron deben adaptarse a la situación en cuestión de acuerdo con el gobierno arquitectura establecida. En particular, determinar si en esta situación, es conveniente llevar a cabo Descripción de línea de base o desarrollo Arquitectura objetivo primero, como se describe en la Parte III , 19. Aplicando la iteración de la . Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante el finalizar el paso Arquitectura Tecnología (ver 12.4.8 finalizar la Arquitectura de Tecnología ). La documentación generada a partir de estas medidas debe ser publicada oficialmente en la Arquitectura paso Crear definición de documento (ver 12.4.9 Crear Arquitectura Definición de documento ). Los pasos en la Fase D son como sigue: 




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



12.4.3 Desarrollar Tecnología Target Arquitectura Descripción















12.4.8 Finalizar la Arquitectura Tecnología




Página 127 de 670

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

Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de vista específico necesario, utilizando la herramienta o método seleccionado.Asegúrese de que todas las preocupaciones de los interesados están cubiertos. Si no es así, crear nuevos modelos para hacer frente a ellos, o aumentar los modelos existentes (véase más arriba). El proceso para desarrollar una arquitectura de tecnología incorpora los siguientes pasos: 

Definir una taxonomía de los servicios de la plataforma y componentes tecnológicos lógicas (incluidas las normas)



Identificar lugares pertinentes en que se despliega la tecnología



Llevar a cabo un inventario físico de la tecnología desplegada y abstracto hasta encajar en la taxonomía



Mira las aplicaciones y de negocios requisitos para la tecnología



¿Es la tecnología en el lugar apto para el propósito de cumplir con los nuevos requisitos (es decir, no se cumplen los requisitos funcionales y no funcionales)? o

Refinar la taxonomía

o

Selección de productos (incluidos los productos dependientes)



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



Determinar el impacto: o

Dimensionamiento y cálculo de costos

Página 128 de 670


La planificación de capacidad

o

Impactos Instalación / governance / migración

En las primeras fases de la , ciertas decisiones que se toman en torno a la granularidad de servicio y los límites del servicio tendrán implicaciones en el componente de la tecnología y el servicio de la plataforma. Las áreas en las que pueden verse afectadas la Arquitectura Tecnología incluirán lo siguiente: 

Performance : La granularidad del servicio tendrá un impacto en los requisitos de servicio de la plataforma. Servicios de grano grueso contienen varias unidades de funcionalidad potencialmente con diferentes requisitos no funcionales, por lo que el rendimiento de plataforma debe ser considerado. Además, los servicios de granularidad gruesa a veces puede contener más información de la que realmente se requiere por el sistema solicitante.



Capacidad de mantenimiento : Si granularidad servicio es demasiado gruesa, entonces la introducción de cambios en los que el servicio se hace difícil y afecta el mantenimiento del servicio y de la plataforma en la que se entrega.



Localización y Latencia : Servicios pueden interactuar entre sí a través de enlaces a distancia y la comunicación entre los servicios tendrán latencia en-construido.Dibujo límites de los servicios y el establecimiento de la granularidad de servicio debe considerar el impacto de plataforma / ubicación de estas comunicaciones entre los distintos servicios.



Disponibilidad : invocación Servicio está sujeto a la red y / o deficiencia en el servicio. Así que la alta disponibilidad de comunicación es una consideración importante en la descomposición de servicio y la definición de un servicio granular

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

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

Sobre la base de los catálogos existentes en tecnología y análisis de las solicitudes realizadas en la fase de Arquitectura de la aplicación, se recoge una lista de los productos en uso.

Página 129 de 670


Si los requisitos identificados en la arquitectura de la aplicación no se cumplen por los productos existentes, ampliar la lista de productos por los productos que examinan disponibles en el mercado que proporcionan la funcionalidad y cumplir con los estándares requeridos.



Clasifica los productos contra el TOGAF TRM en su caso, la extensión del modelo según sea necesario para ajustarse a la clasificación de los productos de la tecnología en uso.



Si los estándares de tecnología están actualmente en vigor, se aplican estos para el catálogo de componentes de tecnología para obtener una visión de línea de base del cumplimiento de los estándares tecnológicos.

Los siguientes catálogos deben ser considerados para el desarrollo dentro de una Arquitectura de Tecnología: 

Los estándares tecnológicos



Cartera de Tecnología


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

Matriz de Aplicación / Tecnología

12.4.1.4 Identificar Diagramas requeridos

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

Página 130 de 670

The Open Group Architecture Framework TOGOF 9.1   Para cada medio ambiente, producir un diagrama lógico de la infraestructura de hardware y software que muestra los contenidos del medio ambiente y las comunicaciones lógicas entre los componentes. Cuando esté disponible, recopilar información sobre la capacidad de la infraestructura desplegada. Para cada entorno, producen un diagrama físico de la infraestructura de comunicaciones, tales como routers, switches, firewalls, y los enlaces de red. Cuando esté disponible, recopilar información sobre la capacidad de la infraestructura de comunicaciones. Los siguientes diagramas deben ser considerados para el desarrollo dentro de una Arquitectura de Tecnología: 

Ambientes y zonas diagrama



Diagrama de descomposición Plataforma



Diagrama de Procesamiento



Diagrama de Red Informática / Hardware



Ingeniería de Comunicaciones diagrama

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

Una vez que los catálogos de arquitectura tecnológica, matrices y diagramas han sido desarrollados, modelado de arquitectura se completa mediante la formalización de los requisitos de la tecnología centrada en la implementación de la arquitectura destino. Estos requisitos pueden: 

Se relacionan con el dominio de la tecnología




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

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

Página 131 de 670


Requisitos para los elementos específicos de la organización o de las decisiones preexistentes (según corresponda)



Elementos de organización preexistentes e invariables (según corresponda)



Limitaciones del entorno externo hereditarias

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

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

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

Página 132 de 670

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













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

12.4.6 Impactos Resolver Across la Arquitectura del Paisaje Una vez que la Tecnología de la Arquitectura está finalizado, es necesario entender los impactos o repercusiones más amplias. En esta etapa, otros artefactos de arquitectura en la arquitectura del paisaje deben ser examinados para identificar: 

¿Crea esto Arquitectura Tecnológica un impacto en las arquitecturas preexistentes?



¿Se han hecho los cambios recientes que impactan la Arquitectura de Tecnología?

Página 133 de 670


¿Hay oportunidades para aprovechar el trabajo de esta Arquitectura Tecnología en otras áreas de la organización?



¿Impacta esta Arquitectura Tecnológica otros proyectos (incluidos los previstos, así como los actualmente en curso)?



¿Esto Arquitectura Tecnología verse afectado por otros proyectos (incluidos los previstos, así como los actualmente en curso)?

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

12.4.8 Finalizar la Arquitectura Tecnología  Seleccione estándares para cada uno de los bloques de construcción, reutilizando la mayor cantidad posible de los modelos de referencia seleccionados del repositorio Arquitectura 




Realizar última comprobación cruzada de la arquitectura global contra objetivos de negocio; documento de justificación de la construcción de las decisiones del bloque en el documento de la arquitectura






Documento de asignación definitiva de la arquitectura dentro del Repositorio de Arquitectura; de los bloques de construcción seleccionados, identificar las que podrían ser re-utilizado (las prácticas de trabajo, roles y relaciones de negocio, descripciones de puestos, etc), y publican a través del Repositorio de Arquitectura




12.4.9 Crear Arquitectura Definición de documento Documentar las razones para la creación de bloquear decisiones en la definición de documento Architecture. Preparar las secciones de tecnología de la definición de documento de Arquitectura, que comprende una parte o todos los siguientes: 

Funcionalidad y atributos Fundamental -, incluyendo la capacidad de seguridad sin ambigüedades semánticas y manejabilidad



Bloques de construcción dependientes con la funcionalidad requerida y llamado interfaces



Interfaces - conjunto elegido, suministrado (APIs, formatos de datos, protocolos, interfaces de hardware, estándares)



Mapa de negocios / entidades organizativas y políticas

Página 134 de 670

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

12.5 Salidas Los resultados de la Fase D pueden incluir, pero no se limitan a: 





o

Principios tecnológicos validados, o nuevos principios tecnológicos (si se generan aquí)




Tecnología Target Arquitectura, Version 1.0 (detallado), incluyendo: 

Componentes tecnológicos y sus relaciones con los sistemas de información



Las plataformas tecnológicas y su descomposición, que muestra las combinaciones de tecnología necesarios para hacer realidad una tecnología de "pila" en particular



Entornos y localizaciones - una agrupación de la tecnología necesaria en entornos de computación (por ejemplo, desarrollo, producción)



Carga de procesamiento esperado y la distribución de la carga entre los componentes de tecnología



(Red) de las comunicaciones físicas



Las especificaciones de hardware y de red

o

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

o


Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo dichos requisitos Arquitectura Tecnología como: o


o

Requisitos de salida de las fases B y C

o

Requisitos tecnológicos actualizados

Página 135 de 670


Componentes Arquitectura de Tecnología de la Arquitectura Roap (ver la Parte IV , 36.2.7 Arquitectura Roap )




Catálogos: o

Catálogo de Normas de Tecnología

o

Catálogo Cartera Tecnológica

Matrices: o



Matriz de Aplicación / Tecnología

Diagramas: o

Ambientes y zonas diagrama

o

Diagrama de descomposición Plataforma

o


o


o


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

Página 136 de 670


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

Figura 13‐1: Fase E: Oportunidades y Soluciones

13.1 Objetivos Los objetivos de la Fase E son para: 

Generar la versión completa inicial de la Hoja de Ruta de la Arquitectura, en base al análisis de las deficiencias y candidatos Arquitectura componentes Hoja de ruta de las fases B, C y D



Determinar si se requiere un enfoque gradual, y si es así identificar las arquitecturas de transición que ofrecer un valor empresarial continuo

Página 137 de 670


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

Arquitectura Roap



Paquetes de Trabajo



Arquitecturas de transición



Implementación y Plan de Migración

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

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

13.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 

Información sobre producto

13.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo )

Página 138 de 670








Metodologías de planificación






o


o


o


o


o


o


Los modelos de gobernanza y los marcos para: o

Planificación Ejecutiva

o

Arquitectura Empresarial

o

Portafolio, Programa, Gestión de Proyectos

o

Desarrollo de Sistemas / Ingeniería

o

Operaciones (Servicio)



o


o












o


o


Página 139 de 670







o


o


o


o


o


o

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

o

Tecnología Target Arquitectura, Version 1.0 (detallado)


Requisitos arquitectónicos

o

Los resultados del análisis de Gap (de negocios, datos, aplicaciones, y Arquitectura de Tecnología)

o

Requisitos de gestión de servicios de TI



Solicitudes de cambio para los programas y proyectos de negocios existentes (véase la Parte IV , 36.2.11 Solicitud de cambio )



Arquitectura Candidato componentes Hoja de ruta de las fases B, C y D

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

Principales cambios corporativos Atributos 13.4.1 Determinar / Confirmar

Página 140 de 670


13.4.2 Determinar restricciones comerciales para la Implementación



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



13.4.4 Requisitos revisión consolidada en todas las funciones de negocio relacionadas



13.4.5 Consolidar y conciliar las exigencias de interoperabilidad



13.4.6 Afinar y Validate Dependencias



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



13.4.8 Formular Implementación y Estrategia de migración



13.4.9 Identificar y Grupo de Trabajo de los principales paquetes



13.4.10 Identificar Arquitecturas de transición



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

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

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

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

Página 141 de 670

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

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

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

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

Página 142 de 670

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

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

13.4.8 Formular Implementación y Estrategia de migración Crear una aplicación global y estrategia de migración que guiará la implementación de la arquitectura destino, y estructurar las arquitecturas de transición. La primera actividad consiste en determinar un enfoque estratégico global para la implementación de las soluciones y / o aprovechamiento de las oportunidades. Hay tres enfoques básicos como sigue: 

Greenfield: Una completamente nueva implementación.



Revolucionario: Un cambio radical (es decir, cambiar , Desactivar).



Evolutiva: una estrategia de convergencia, como correr en paralelo o en un enfoque por fases para introducir nuevas capacidades.

A continuación, determine un enfoque para la dirección estratégica general que tratar y mitigar los riesgos identificados en las lagunas consolidados, soluciones, y la matriz de dependencias. Las metodologías de implementación más comunes son: 

Victoria rápida (instantáneas)



Metas alcanzables



Método de la cadena de valor

Estos enfoques y las dependencias identificadas deberían ser la base para la creación de los paquetes de trabajo. Esta actividad termina con un acuerdo sobre la aplicación y estrategia de migración para la empresa.

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

Página 143 de 670

The Open Group Architecture Framework TOGOF 9.1   Uso de las Lagunas consolidados, soluciones, y la matriz de dependencias, junto con la evaluación de la instrumentación Factor y la matriz de deducción, lógicamente agrupar las diversas actividades en paquetes de trabajo. Rellene la columna "Solución" los boquetes consolidados, Soluciones, y la matriz de dependencias para recomendar los mecanismos de solución propuestos. Indique para cada hueco / actividad si la solución debe orientarse hacia un nuevo desarrollo, o basarse en un producto ya existente, y / o el uso de una solución que se puede comprar.Un sistema existente puede resolver el requisito con mejoras de menor importancia. Para nuevos desarrollos este es un buen momento para determinar si el trabajo debe llevarse a cabo dentro de la empresa oa través de un contrato. Clasifique cada sistema actual que se está considerando como: 

Mainstream: Parte de un futuro sistema de información.



Contener: Se espera que sea reemplazado o modificado en el horizonte de planificación (próximos tres años).



Vuelva a colocar: Se sustituirá en el horizonte de planificación.

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

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

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

Página 144 de 670

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

13.5 Salidas Los resultados de la Fase E pueden incluir, pero no se limitan a: 



Versión refinada y actualizada de los entregables de la fase Arquitectura Visión, en su caso, entre ellos: o

Architecture Vision, incluyendo la definición de los tipos y grados de interoperabilidad

o



Línea de base de Empresas Arquitectura, versión 1.0 actualiza si es necesario

o

Objetivo Negocio Arquitectura, versión 1.0 actualiza si es necesario

o

Arquitectura de datos de línea de base, versión 1.0 actualiza si es necesario

o

Arquitectura de datos de destino, versión 1.0 actualiza si es necesario

o

Línea de base de arquitectura de aplicaciones, la versión 1.0 actualiza si es necesario

Página 145 de 670




o

Objetivo de Arquitectura de aplicaciones, la versión 1.0 actualiza si es necesario

o

Línea de Base Tecnológica de la Arquitectura, la versión 1.0 actualiza si es necesario

o

Tecnología Target Arquitectura, versión 1.0 actualiza si es necesario

o

Arquitectura de transición, el número y el alcance que sea necesario

o







Brechas consolidados, soluciones y Dependencias de Evaluación

Evaluaciones de capacidad, entre ellos: o

Evaluación de la capacidad del negocio

o

Evaluación de Capacidad de TI

Arquitectura Roap (ver la Parte IV , 36.2.7 Arquitectura Roap ), incluyendo: o

o

Cartera Paquete de trabajo: 

Trabajo descripción del paquete (nombre, descripción, objetivos)



Requisitos funcionales



Dependencias



Relación con la oportunidad



Relación a la Arquitectura de definición de documento y Arquitectura Especificación de Requisitos



Relación con cualesquiera incrementos de capacidad



El valor del negocio



Evaluación Factor Implementación y Matrix Deducción



Impacto

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

o

Relación a la Arquitectura de definición de documento

Recomendaciones para la implementación: 

Criterios de valoración de la eficacia



Riesgos y problemas

Página 146 de 670

The Open Group Architecture Framework TOGOF 9.1    

Bloques de Solución de construcción (SBB)

Implementación y Plan de Migración, Versión 0.1, incluyendo: o

Implementación y Estrategia de migración


Diagramas: o

Diagrama de Contexto del Proyecto

o

Diagrama de Beneficios

Página 147 de 670


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

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

14.1 Objetivos Los objetivos de la Fase F son para: 

Finalizar la Arquitectura Hoja de Ruta y la aplicación de soporte y Plan de Migración



Asegúrese de que la aplicación y el Plan de Migración se coordina con el enfoque de la empresa para la gestión y la implementación de cambios en la cartera de cambio general de la empresa



Asegúrese de que el valor para el negocio y el costo de los paquetes de trabajo y transición Arquitecturas Se entiende por las partes interesadas clave

Página 148 de 670


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

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









o


o


o


o


o


o


Los modelos de gobernanza y los marcos para: o


Página 149 de 670




o


o


o


o

Operaciones (Servicio)



o


o















o


o


o


o




o


o


o


o


o


o

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

o

Tecnología Target Arquitectura, Version 1.0 (detallado)

o

Arquitecturas de transición, si los hay

Proyecto de Arquitectura Especificación de Requisitos (véase la Parte IV , 36.2.6 Arquitectura especificación de requisitos ), incluyendo:

Página 150 de 670



o

Los resultados del análisis de Gap (de negocios, datos, aplicaciones, y Arquitectura de Tecnología)

o




Solicitudes de cambio para los programas y proyectos de negocios existentes (véase la Parte IV , 36.2.11 Solicitud de cambio )



Arquitectura Roap, Versión 0.1 (véase la Parte IV , 36.2.7 Arquitectura Roap ), incluyendo:





o

Identificación de los paquetes de trabajo

o

Identificación de transición Arquitecturas

o

Evaluación Factor Implementación y Matrix Deducción

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

Evaluación de la capacidad del negocio

o

Evaluación de Capacidad de TI

Implementación y Plan de Migración, Versión 0.1 (véase la Parte IV , 36.2.14 Implementación y Plan de Migración ), incluyendo la aplicación de alto nivel y la estrategia de migración

14.4 Pasos El nivel de detalle abordado en la Fase F dependerá del alcance y los objetivos del esfuerzo global de la arquitectura. El orden de los pasos en la Fase F (véase más adelante), así como el momento en que se inician formalmente y completaron deben adaptarse a la situación en cuestión de acuerdo con el gobierno arquitectura establecida. Todas las actividades que se han iniciado en estos pasos deben estar cerradas durante las clases completar el ciclo de desarrollo de la arquitectura y documentar paso aprendido (ver 14.4.7 completar el ciclo de desarrollo de la arquitectura y de documentar las lecciones aprendidas ). Los pasos en la Fase F son como sigue: 

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



14.4.2 Asignar un valor de negocio para cada paquete de trabajo



14.4.3 Requisitos de Recursos de Estimación, Proyecto sincronizaciones, y la disponibilidad / vehículo Entrega

Página 151 de 670


14.4.4 Dar prioridad a los proyectos de migración a través de la realización de una evaluación costo / beneficio y Validación de Riesgos



14.4.5 Confirmar Arquitectura Roap y Actualización Arquitectura Definición de documento



14.4.6 Generar la aplicación y el Plan de Migración



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

14.4.1 Confirmar Management Framework Interacciones para la Aplicación y el Plan de Migración Este paso es sobre la coordinación de la aplicación y el Plan de Migración con los marcos de gestión dentro de la organización. En general, existen cuatro marcos de gestión que tienen que trabajar en estrecha colaboración para la Aplicación y el Plan de Migración para tener éxito: 

Planificación de Negocios que concibe, dirige y provee los recursos para todas las actividades necesarias para lograr los objetivos de negocio / resultados concretos.



Arquitectura Empresarial que estructura y da contexto a todas las actividades de la empresa la entrega de los resultados del negocio de concreto principalmente, pero no exclusivamente, en el dominio de TI.



Portafolio / Gestión de Proyectos que coordina, diseña y construye los sistemas de negocio que ofrecen los resultados de negocio concretos.



Gestión de Operaciones , que integra, opera y mantiene las prestaciones que ofrecen los resultados de negocio concretos.

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

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

Página 152 de 670


Criterios de evaluación de rendimiento son utilizados por la cartera y la capacidad de los gestores para aprobar y supervisar el progreso de la transformación de la arquitectura.



Retorno de la Inversión Criterios tienen que ser detallado y firmado por las distintas partes interesadas ejecutivos.



Valor de negocio tiene que ser definido, así como las técnicas, tales como la cadena de valor, que se van a utilizar para ilustrar el papel en el logro de los resultados de negocio tangibles. El valor del negocio será utilizada por la cartera y la capacidad de los gestores para asignar recursos y, en los casos en los que hay recortes, el valor del negocio en relación con el retorno de la inversión se puede utilizar para determinar si un esfuerzo avanza, se retrasa o se cancela.



Factores Críticos de Éxito (CSF) se deben establecer para definir el éxito de un proyecto y / o incremento de proyectos. Esto proporcionará los es y ejecutores con un medidor de lo que constituye una implementación exitosa.



Medidas de Efectividad (MOE) a menudo son los criterios de rendimiento y muchas empresas los incluyen en los MCA. Cuando se les trata de forma discreta, debe ser clara en cuanto a cómo estos criterios se deberán agrupar.



Fit Estratégico basado en la arquitectura de la empresa en general (todos los niveles) será el factor clave para permitir a la aprobación de cualquier nuevo proyecto o iniciativa y para la determinación del valor de cualquier entrega.

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

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

Página 153 de 670

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

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

Página 154 de 670

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

14.4.7 Completar el Ciclo de Desarrollo de Arquitectura y documentar las lecciones aprendidas Este paso transiciones de gobierno a partir del desarrollo de la arquitectura a la realización de la arquitectura. Si el vencimiento de las órdenes de Arquitectura de capacidad, un Modelo de Gobierno La implementación puede ser producido (véase la Parte IV , 36.2.15 Implementación Modelo de Gobierno ). Las lecciones aprendidas durante el desarrollo de la arquitectura deben estar documentados y capturados por el proceso de gobernanza adecuada en la Fase H como insumos para la gestión de la capacidad de Arquitectura. El detalle de la hoja de ruta de la Arquitectura y la aplicación y el Plan de Migración debe expresarse en un nivel de detalle similar a la definición de documento Arquitectura desarrollada en las fases B, C y D. Cuando se requiera el detalle adicional significativo para la próxima fase de la arquitectura es probable la transición a un nivel diferente.Dependiendo del nivel de la arquitectura seleccionada y ejecución y el Plan de Migración puede ser necesario para repetir otro ciclo de en un nivel más bajo de detalle.Ver Parte III , 19. Aplicando la iteración de la y 20. Aplicando la a través de la Arquitectura del Paisaje de técnicas para manejar la iteración y los diferentes niveles de detalle.

14.5 Salidas Los resultados de la Fase F pueden incluir, pero no se limitan a: 

Implementación y Plan de Migración, Versión 1.0 (véase la Parte IV , 36.2.14 Implementación y Plan de Migración ), incluyendo: o

Implementación y Estrategia de migración

o

Proyectos y Distribución de la cartera de la aplicación: 

Asignación de los paquetes de trabajo para proyectar y de cartera



Capacidades entregados por proyectos



Relación a la Arquitectura de destino y cualquier Arquitecturas de transición

Página 155 de 670


o





Hitos y calendario



Estructura de desglose del trabajo

Cartas del proyecto (opcional): 

Paquetes de trabajo relacionados






Riesgo, problemas, hipótesis, dependencias



Las necesidades de recursos y los costes



Beneficios de la migración



Estimación de los gastos de las opciones de migración

Finalizada Arquitectura definición de documento (ver la Parte IV , 36.2.3 Arquitectura de definición de documento ), incluyendo: o

Arquitecturas transición finalizados, en su caso



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



Finalizado Arquitectura Roap (véase la Parte IV , 36.2.7 Arquitectura Roap )



Reutilizables Arquitectura Bloques de construcción (véase la Parte IV , 36.2.1 Arquitectura Building Blocks )



Las solicitudes de Arquitectura de trabajo (ver la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo ) para una nueva iteración del ciclo de (si los hay)



Implementación Modelo de Gobierno (si las hubiera) (véase la Parte IV , 36.2.15 Implementación Modelo de Gobierno )



Solicitudes de cambio para la capacidad de la arquitectura que surge de las lecciones aprendidas

Página 156 de 670


. 15 Fase G: Gobernanza Aplicación Este capítulo proporciona una supervisión de arquitectura de la aplicación.

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

15.1 Objetivos Los objetivos de la Fase G son para: 

Asegurar la conformidad con la arquitectura destino por los proyectos de implementación



Realizar funciones de arquitectura de gobernanza adecuadas para la solución y cualquier arquitectura de solicitudes de cambio de aplicación impulsada

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

Página 157 de 670

The Open Group Architecture Framework TOGOF 9.1   Para habilitar la rápida obtención de valor para el negocio y los beneficios, y para minimizar el riesgo en el programa de transformación y la migración, el enfoque preferido es el despliegue de la arquitectura destino como una serie de transiciones. Cada transición representa un paso más hacia el objetivo, y cada uno ofrece un beneficio empresarial en su propio derecho. Por lo tanto, el enfoque global de la Fase G es: 

Establecer un programa de aplicación que permita la entrega de las arquitecturas de transición acordado para la implementación durante la fase de planeamiento de migración



Adoptar un programa de implementación por fases que refleja las prioridades de la empresa contenidos en la Hoja de Ruta de la Arquitectura



Siga estándar de la organización para las empresas, informática, arquitectura y gobierno



Utilice establecido enfoque de gestión de cartera / programa de la organización, siempre que exista



Definir un marco de operaciones para garantizar una larga vida útil de la solución implementada

Fase G establece la conexión entre la arquitectura y la organización de la ejecución, a través del Contrato de Arquitectura. Detalles del proyecto se desarrollan, entre ellas: 

Nombre, descripción y objetivos



Ámbito de aplicación, prestaciones y limitaciones



Medidas de efectividad



Los criterios de aceptación



Riesgos y problemas

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

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


Página 158 de 670






o


o


o


o


o


o




o


o












o


o


o




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



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


Página 159 de 670


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



Arquitectura Roap (véase la Parte IV , 36.2.7 Arquitectura Roap )



Gobierno Modelo de Implementación (véase la Parte IV , 36.2.15 Implementación Modelo de Gobierno )



Arquitectura Contrato (estándar) (véase la Parte VII , 49. Contratos de Arquitectura )



Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17 Solicitud de Arquitectura Trabajo ) identificados durante las fases E y F



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

15.4 Pasos El nivel de detalle abordado en Fase G dependerá del alcance y los objetivos del esfuerzo global de la arquitectura. El orden de los pasos en la Fase G (véase más adelante), así como el momento en que se inician formalmente y completaron deben adaptarse a la situación en cuestión de acuerdo con el gobierno arquitectura establecida. Los pasos en la Fase G son como sigue: 

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



15.4.2 Identificar recursos de implementación y Habilidades



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



15.4.4 Realizar revisiones Arquitectura Empresarial de Cumplimiento



15.4.5 Implementación de Negocios y Operaciones de TI



15.4.6 Realizar Revisión Post-Implementación y Cierre la Implementación

15.4.1 Confirmar alcance y las prioridades para la implementación con la Gestión del Desarrollo  Revise los resultados de planificación de migración y producir recomendaciones sobre la implementación 

Identificar las prioridades de arquitectura empresarial para los equipos de desarrollo



Identificar los problemas de implementación y hacer recomendaciones



Identificar los bloques de construcción para la sustitución, actualización, etc



Realizar análisis de las deficiencias en la arquitectura institucional y de soluciones

Página 160 de 670

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

Producir un informe de análisis de brecha

15.4.2 Identificar recursos de implementación y Habilidades Los recursos del proyecto se incluyen los recursos de desarrollo que tendrán que ser educados en los entregables de arquitectura empresarial en general y expectativas de los proyectos de desarrollo y de implementación específicos. Las siguientes consideraciones deben ser abordados en este paso: 

Identificar los métodos de desarrollo de sistemas necesarios para el desarrollo de soluciones Nota: Hay una serie de métodos y herramientas disponibles para los equipos de proyectos de desarrollo de sistemas. El método ideal debería ser capaz de interoperar con las salidas de la arquitectura; por ejemplo, generar código desde artefactos arquitectura entregadas hasta la fecha. Esto se podría lograr mediante el uso de lenguajes de modelado utilizadas para el desarrollo de la arquitectura de la empresa que pueden ser capturadas como insumos para los sistemas de herramientas de desarrollo y por lo tanto reducen el costo de desarrollo de soluciones.



Asegúrese de que el método de desarrollo de sistemas permite retroalimentación al equipo de arquitectura en diseños

15.4.3 Guía de desarrollo de la implementación de soluciones  Formular recomendación proyecto Para cada proyecto de implementación y despliegue independiente, haga lo siguiente: o

Alcance del documento de proyecto individual en el análisis del impacto

o

Documentar las necesidades estratégicas (desde el punto de vista arquitectónico) en el análisis de impacto

o

Las solicitudes de cambio de documento (como el soporte para una interfaz estándar) en el análisis de impacto

o

Reglas del documento para la conformidad en el análisis del impacto

o

Requisitos de la línea de tiempo del documento de hoja de ruta en materia de análisis de impacto

Página 161 de 670


Arquitectura de documento de contrato o

Obtenga la firma de desarrollo de las organizaciones y el patrocinio de toda la organización



Directorio Enterprise Update Continuum y el repositorio de soluciones



Guía de desarrollo de negocio y de TI modelos operativos para los servicios



Proporcionar los requisitos de servicio derivadas de la arquitectura empresarial



Definición Guía de negocios y de TI requisitos operativos



Llevar a cabo análisis de brechas entre la arquitectura de soluciones y operaciones



Producir Plan de Implementación

15.4.4 Realizar revisiones Arquitectura Empresarial de Cumplimiento  Revise la gobernanza aplicación en curso y la arquitectura de cumplimiento para cada bloque de construcción 

Una vez puestos en desarrollo



Cerrar desarrollo parte de los proyectos de implementación

15.4.5 Implementación de Negocios y Operaciones de TI  Llevar a cabo los proyectos de implementación, incluyendo: servicios de TI la implementación del parto; aplicación la prestación de servicios empresariales; el desarrollo de competencias y la implementación de capacitación; publicación de documentación comunicaciones 

Publicar nuevas arquitecturas de referencia para la arquitectura de repositorio y actualizar otros repositorios afectadas, tales como tiendas de gestión de la configuración operativa

15.4.6 Realizar Revisión Post-Implementación y Cierre la Implementación  Una vez puestos en ejecución 

Publicar comentarios y proyectos cercanos

Cierre de Fase G será cuando las soluciones están totalmente desplegados una vez.

15.5 Salidas Las salidas de Fase G pueden incluir, pero no se limitan a: 

Arquitectura contrato (firmado) (véase la Parte VII , 49. Arquitectura de Contratos ), como se recomienda en las arquitecturas implementadas compatible con arquitectura



Las evaluaciones de cumplimiento (ver la Parte IV , Evaluación del Cumplimiento 36.2.13 )



Solicitudes de cambio (véase la Parte IV , 36.2.11 Solicitud de cambio )

Página 162 de 670


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 . La participación directa del personal de la arquitectura en la aplicación variará de acuerdo con la política de la organización, como se describe en la Parte VII, 50. Arquitectura de Gobierno . o

Poblado Repositorio Arquitectura

o

Recomendaciones Arquitectura de cumplimiento y dispensas

o

Recomendaciones sobre los requisitos de prestación de servicios

o

Recomendaciones sobre las medidas de rendimiento

o

Acuerdos de Nivel de Servicio (SLAs)

o

Architecture Vision, posterior a la ejecución de actualización

o

Arquitectura Definición de documento, posterior a la ejecución de actualización

o

Modelos operativos de TI y de negocios de la solución implementada

Página 163 de 670


16 Fase H:. Gestión Arquitectura Cambio Este capítulo se centra en el establecimiento de procedimientos para la gestión del cambio a la nueva arquitectura.

Figura 16‐1: Fase H: Gestión Arquitectura Cambio

16.1 Objetivos Los objetivos de la Fase H son: 

Asegúrese de que se mantiene la arquitectura del ciclo de vida



Asegúrese de que se ejecute el Marco de Gobierno Arquitectura



Asegúrese de que la capacidad de la empresa Arquitectura cumple los requisitos actuales

Página 164 de 670


16.2 Enfoque El objetivo de un proceso de gestión del cambio arquitectura es garantizar que la arquitectura alcanza su valor de negocio objetivo original. Esto incluye la gestión de cambios en la arquitectura de una manera coherente y con arquitectura. Este proceso suele asegurar el seguimiento continuo de las cosas tales como las solicitudes de gobierno, los nuevos desarrollos en la tecnología y los cambios en el entorno empresarial. Cuando se identifican los cambios, la gestión del cambio determinará si ha de iniciar formalmente un nuevo ciclo de la evolución de la arquitectura. Además, el proceso de gestión de cambios de arquitectura tiene como objetivo establecer y apoyar la arquitectura de la empresa implementa como una arquitectura dinámica; es decir, uno que tiene la flexibilidad para evolucionar rápidamente en respuesta a cambios en el entorno de la tecnología y de negocios. Monitoreo de crecimiento del negocio y la decadencia es un aspecto crítico de esta fase. El uso de la arquitectura de la empresa es la parte más importante del ciclo de desarrollo de la arquitectura. Con demasiada frecuencia, el negocio se ha quedado con una arquitectura empresarial que trabaja para la organización de ayer, pero no puede dar vuelta la capacidad suficiente para satisfacer las necesidades de la empresa de hoy y del mañana. En muchos casos, la arquitectura sigue en forma, pero las soluciones que subyacen en ellas no puede, y se requieren algunos cambios. El arquitecto de la empresa tiene que ser consciente de estos requisitos de cambio y lo considera una parte esencial de la renovación constante de la arquitectura. Medición y recomendaciones para la planificación de la capacidad es un aspecto clave de esta fase. Mientras que la arquitectura se ha construido para ofrecer una arquitectura de negocios en estado estacionario con capacidad acordada durante el ciclo de vida de esta arquitectura de la empresa, el crecimiento o la disminución en el uso es necesario evaluar continuamente para asegurar que se consigue el máximo valor empresarial. Por ejemplo, algunos Solution Architectures no se prestan para ser escalable en un factor grande digamos 10 - o soluciones alternativas puede ser más económico cuando se escala hacia arriba. Mientras que las especificaciones de la arquitectura no pueden cambiar, las soluciones o su contexto operativo pueden cambiar. Si la gestión y la información de rendimiento se ha incorporado en los productos de trabajo a través de las fases anteriores, a continuación, esta fase se trata de garantizar la efectividad de los mismos. Si es necesario que haya supervisión o informes adicionales, entonces esta fase se encargará de los cambios. El proceso de gestión del valor y el cambio, una vez establecido, determinará: 

Las circunstancias en que la arquitectura de la empresa, o parte de ella, se le permitirá cambiar después de la implementación, y el proceso por el cual que va a pasar

Página 165 de 670


Las circunstancias bajo las cuales se iniciará de nuevo el ciclo de desarrollo de arquitectura para desarrollar una nueva arquitectura

La gestión del cambio arquitectura proceso está muy estrechamente relacionado con los procesos de gobernanza de la arquitectura de la empresa, y para la gestión del Contrato de Arquitectura (véase la Parte VII , 49. Contratos de Arquitectura ) entre la función de la arquitectura y los s de negocio de la empresa. En la Fase H es fundamental que el órgano de gobierno a establecer criterios para juzgar si una solicitud de cambio garantiza sólo una actualización arquitectura o si amerita iniciar un nuevo ciclo del Método de Desarrollo de Arquitectura (). Es especialmente importante evitar la "elegancia progresiva", y el órgano de gobierno debe continuar para buscar cambios que se relacionan directamente con el valor del negocio. Un informe de Cumplimiento Arquitectura debe indicar si el cambio es compatible con la arquitectura actual. Si es no conforme, una exención puede concederse con fundamento válido. Si el cambio tiene un alto impacto en la arquitectura, a continuación, una estrategia para gestionar su impacto debe ser definido. Directrices para el establecimiento de estos criterios son difíciles de establecer, ya que muchas empresas aceptan el riesgo de manera diferente, pero como el seejerce, el nivel de madurez del órgano de gobierno van a mejorar, y los criterios se pondrán de manifiesto para necesidades específicas.

16.2.1 Drivers for Change El objetivo principal para el desarrollo de la arquitectura de la empresa hasta ahora ha sido la dirección estratégica y la arquitectura de arriba hacia abajo y la generación de proyectos para lograr las capacidades empresariales. Sin embargo, la arquitectura de la empresa no opera en el vacío. Por lo general, una infraestructura y negocio existente que ya está proporcionando valor. Hay también, probablemente, los impulsores del cambio que a menudo son de abajo hacia arriba, en base a la modificación de la infraestructura existente para mejorar la funcionalidad. Arquitectura empresarial cambia este paradigma de un enfoque estratégico de arriba hacia abajo en un grado, aunque la entrega de los incrementos hace que la ecuación más compleja. Hay tres formas de cambiar la infraestructura existente que tiene que estar integrados: 

De arriba hacia abajo Cambio estratégico, dirigido a mejorar o crear nuevas capacidades (capital)



Cambios de abajo hacia arriba para corregir o mejorar la capacidad (operación y mantenimiento) para la infraestructura bajo la gestión de operaciones



Experiencias con los incrementos de los proyectos entregados previamente en el cuidado de la gestión de operaciones, pero aún siendo entregada por los proyectos en curso

Gobierno tendrá que manejar la coordinación de estas solicitudes para el cambio, además es necesario que haya un proceso de lecciones aprendidas para que si hay problemas con los incrementos entregados recientemente por resolver y los cambios realizados en el Arquitecturas Target está diseñado y planificado.

Página 166 de 670

The Open Group Architecture Framework TOGOF 9.1   Un lecciones aprendidas proceso asegura que los errores se hacen una vez y no se repiten. Ellos pueden venir de cualquier parte y cualquier persona y para abarcar cualquier aspecto de la arquitectura de la empresa a todos los niveles (estratégico, definición de arquitectura empresarial, la transición, o proyecto). A menudo, una lección relacionada con la arquitectura de la empresa puede ser un resultado indirecto de una lección aprendida en la organización en otro lugar. La Junta de Arquitectura (véase la Parte VII , 47. Architecture Board ) evalúa y aprueba las solicitudes para el Cambio (RFC). Un RFC es típicamente en respuesta a problemas conocidos, pero también puede incluir mejoras. Un reto para el Consejo de Arquitectura de la manipulación de un RFC es para determinar si se debe aprobar o si un proyecto en una Arquitectura Transición resolverá el problema. Cuando la evaluación de proyecto o solución de ajuste en la arquitectura, también puede ser el caso cuando una solución innovadora o RFC impulsa un cambio en la arquitectura. Además, hay muchos conductores relacionados con la tecnología para la arquitectura solicitudes de cambio. Por ejemplo: 

Informes Nueva tecnología



La reducción de costes de gestión de activos



Retirada Tecnología



Las iniciativas de estandarización

Este tipo de solicitud de cambio es normalmente manejable principalmente a través de la gestión de cambios de una empresa y los procesos de gobernanza de la arquitectura. Además, hay factores de negocio para el cambio de arquitectura, incluyendo: 

Business-as-usual desarrollos



Excepciones empresariales



Innovaciones empresariales



Innovaciones tecnológicas de negocios



El cambio estratégico

Este tipo de solicitud de cambio a menudo resulta en una re-desarrollo completo de la arquitectura, o al menos en una iteración de una parte del ciclo de desarrollo de la arquitectura, como se explica a continuación.

16.2.2 Arquitectura Empresarial Proceso de Gestión del Cambio El proceso de gestión de cambios de arquitectura empresarial necesita determinar cómo los cambios han de ser istrado, qué técnicas se deben aplicar, y qué metodologías utilizadas. El proceso también tiene una función de filtro que determina qué fases del proceso de desarrollo de la

Página 167 de 670

The Open Group Architecture Framework TOGOF 9.1   arquitectura se ven afectados por los requisitos. Por ejemplo, los cambios que afectan sólo a la migración pueden ser de interés en las fases de desarrollo de la arquitectura. Hay muchos enfoques válidos para el cambio de gestión, y de diversas técnicas y metodologías que se pueden utilizar para gestionar el cambio de gestión; por ejemplo, los métodos de gestión de proyectos como PRINCE2, métodos de gestión de servicios, tales como ITIL, los métodos de consultoría de gestión, como catalizador, y muchos otros. Una empresa que ya cuenta con una gestión de cambio proceso en su lugar en un campo distinto de la arquitectura (por ejemplo, en el desarrollo de sistemas o la gestión de proyectos) puede muy bien ser capaz de adaptarlo para su uso en relación con la arquitectura. A continuación se describe un enfoque para la gestión del cambio, dirigido especialmente a la ayuda de una arquitectura empresarial dinámico, que puede ser considerado para su uso si hay un proceso similar existe en la actualidad. El enfoque se basa en la clasificación de cambios en la arquitectura requeridos en una de tres categorías: 

Simplificación del cambio : Un cambio simplificación normalmente se puede manejar a través de técnicas de gestión del cambio.



Cambio incremental : Un cambio incremental puede ser susceptible de ser manejado a través de técnicas de gestión del cambio, o puede requerir una reestructuración de parcial, dependiendo de la naturaleza del cambio (ver 16.2.3 Directrices para Mantenimiento frente Arquitectura Rediseño de directrices).



Re-arquitectura de cambio : Un cambio re-arquitectura de requiere poner toda la arquitectura a través del ciclo de desarrollo de la arquitectura de nuevo.

Otra forma de ver estas tres opciones es decir que un cambio de la simplificación de la arquitectura es a menudo impulsada por una necesidad de reducir la inversión; un cambio incremental es impulsado por un requisito para obtener un valor adicional de la inversión existente; y un cambio re-arquitectura de es impulsado por una necesidad de aumentar la inversión con el fin de crear un nuevo valor para la explotación. Para determinar si un cambio es la simplificación, incremental o una reestructuración de, se realizarán las siguientes actividades:

1. Registro de todos los eventos que puedan afectar a la arquitectura 2. La asignación de recursos y la gestión de las tareas de arquitectura 3. El proceso o función responsable de recursos de arquitectura tiene que hacer balance de lo que se debe hacer 4. Evaluación de los impactos 16.2.3 Directrices para Mantenimiento frente Arquitectura Rediseño Una buena regla empírica es:

Página 168 de 670


Si los efectos del cambio de dos o más grupos de interés, entonces es probable que requiera un rediseño arquitectura y el reingreso a la .



Si los impactos del cambio sólo una de las partes interesadas, entonces es más probable que sea un candidato para la gestión del cambio.



Si el cambio se puede permitir bajo una dispensación, entonces es más probable que sea un candidato para la gestión del cambio.

Por ejemplo: 

Si el impacto es significativo para la estrategia de negocio, entonces puede haber una necesidad de rehacer toda la arquitectura de la empresa - por lo tanto un enfoque de una reestructuración de.



Si una nueva tecnología o normas surgen, entonces puede haber una necesidad de actualizar la arquitectura de Tecnología, pero no toda la arquitectura de la empresa - por lo tanto un cambio incremental.



Si el cambio se encuentra en un nivel de infraestructura - por ejemplo, diez sistemas reducidos o modificados a un sistema - esto puede no cambiar la arquitectura por encima de la capa física, sino que va a cambiar la descripción de línea de base de la arquitectura de la tecnología. Esto sería un cambio simplificación manejado a través de técnicas de gestión del cambio.

En particular, un ciclo de refresco (re-Architecting parcial o completa) puede ser necesario si: 

La Fundación de Arquitectura tiene que ser re-alineado con la estrategia de negocio.



Se requiere un cambio sustancial a los componentes y las directrices para el uso en el despliegue de la arquitectura.



Normas significativas utilizadas en la arquitectura del producto se cambian los cuales tienen un impacto significativo para el final; por ejemplo, los cambios regulatorios.

Si hay una necesidad de un ciclo de refresco, a continuación, una nueva solicitud de Arquitectura de trabajo deberá expedirla (para pasar a otro ciclo).

16.3 Entradas Esta sección define las entradas para la Fase H.

16.3.1 Materiales de Referencia Externa a la Empresa  Materiales de referencia Arquitectura (ver la Parte IV , 36.2.5 Arquitectura Repositorio ) 16.3.2 Entradas para no Arquitectónicos  Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17 Solicitud de Arquitectura de Trabajo )

Página 169 de 670

The Open Group Architecture Framework TOGOF 9.1   16.3.3 Entradas arquitectónicos  Modelo de organización de Arquitectura Empresarial (véase la Parte IV , 36.2.16 Modelo de Organización de Empresa de Arquitectura ), incluyendo:



o


o


o


o


o


o




o


o












o


o


o




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



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

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

o




Arquitectura Roap (véase la Parte IV , 36.2.7 Arquitectura Roap )



Solicitud de cambio (véase la Parte IV , 36.2.11 Solicitud de cambio ), - los cambios tecnológicos:

Página 170 de 670




o

Informes Nueva tecnología

o

Iniciativas de reducción de costes de gestión de activos

o

Informes de abstinencia Tecnología

o

Las iniciativas de estandarización

Solicitud de cambio (véase la Parte IV , 36.2.11 Solicitud de cambio ), - los cambios del negocio: o

Evolución de los negocios

o

Excepciones empresariales

o

Innovaciones empresariales

o

Innovaciones tecnológicas de negocios

o

Desarrollos del cambio estratégico



Solicitud de cambio (véase la Parte IV , 36.2.11 Solicitud de cambio ), - a partir de las lecciones aprendidas



Gobierno Modelo de Implementación (véase la Parte IV , 36.2.15 Implementación Modelo de Gobierno )



Arquitectura contrato (firmado) (véase la Parte VII , 49. Contratos de Arquitectura )



Las evaluaciones de cumplimiento (ver la Parte IV , Evaluación del Cumplimiento 36.2.13 )



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

16.4 Pasos El nivel de detalle abordado en la Fase H dependerá del alcance y los objetivos del esfuerzo global de la arquitectura. El orden de los pasos en la Fase H (véase más adelante), así como el momento en que se inician formalmente y completaron deben adaptarse a la situación en cuestión de acuerdo con el gobierno arquitectura establecida. Los pasos en la Fase H son los siguientes: 

16.4.1 Establecer proceso de realización del valor



16.4.2 Para desplegar Herramientas de Monitoreo



16.4.3 istrar Riesgos



16.4.4 Proporcionar Análisis de Arquitectura de Gestión del Cambio

Página 171 de 670


16.4.5 Desarrollar cambiar los requisitos para cumplir los objetivos de rendimiento



16.4.6 istrar Proceso Gobernanza



16.4.7 Activar el proceso para implementar el cambio

16.4.1 Establecer proceso de realización del valor Influencia proyectos empresariales de explotación de la arquitectura de la empresa para la realización de valor (resultados).

16.4.2 Para desplegar Herramientas de Monitoreo Herramientas de garantizar un seguimiento se implementan y aplican para permitir lo siguiente: 

Monitorear los cambios tecnológicos que podrían afectar la arquitectura de línea de base



Vigilar los cambios del negocio que podrían afectar la arquitectura de línea de base



Seguimiento de valor de negocios; por ejemplo, el método de evaluación de la inversión para determinar las métricas de valor para los objetivos de negocio



Monitorear la empresa Arquitectura Capability Maturity



Seguimiento y evaluación de los programas de gestión de activos



Seguimiento de las actuaciones de calidad de servicio y el uso



Determinar y localizar las necesidades de continuidad de negocio

16.4.3 istrar Riesgos Gestione la arquitectura riesgos de la empresa y proporcionar recomendaciones para la estrategia de TI.

16.4.4 Proporcionar Análisis de Arquitectura de Gestión del Cambio Proporcionar un análisis de la gestión de cambios de arquitectura: 

Analizar el rendimiento



Llevar a cabo revisiones de desempeño de la empresa con la arquitectura de gestión de servicios



Evaluar las solicitudes de cambio y presentación de informes para garantizar que se cumplan la realización valor esperado y el Acuerdo de Nivel de Servicio (SLA) expectativas de los clientes



Llevar a cabo un análisis de las deficiencias de la actuación de la arquitectura de la empresa

Página 172 de 670


Asegúrese de solicitudes de istración de cambios se adhieren a la gobernabilidad de arquitectura empresarial y el marco

16.4.5 Desarrollar cambiar los requisitos para cumplir los objetivos de rendimiento Hacer recomendaciones sobre requisitos de cambio para cumplir los objetivos y el desarrollo de condiciones de actuar de rendimiento.

16.4.6 istrar Proceso Gobernanza Gestione proceso de gobernanza y un marco para la arquitectura: 

Organizar reuniones de Junta de Arquitectura (u otro Consejo de Gobierno)



Celebrar una reunión de la Junta de Arquitectura con el objetivo de la reunión para decidir sobre los cambios de manejo (la tecnología y los negocios y dispensaciones)

16.4.7 Activar el proceso para implementar el cambio Activar el proceso de arquitectura para implementar el cambio: 

Producir una nueva Solicitud de Arquitectura Trabajo y solicitar a la inversión



Asegurar los cambios implementados en esta fase son capturados y documentados en el Repositorio de Arquitectura

16.5 Salidas Los resultados de la Fase H pueden incluir, pero no se limitan a: 

Actualizaciones Arquitectura (para cambios de mantenimiento)



Modificaciones del marco de arquitectura y los principios (por cambios de mantenimiento)



Nueva Solicitud de Arquitectura de trabajo (véase la Parte IV , 36.2.17 Solicitud de Arquitectura Trabajo ), para pasar a otro ciclo (para cambios importantes)






Arquitectura contrato (véase la Parte IV , 49. Contratos de Arquitectura ), actualizado en caso necesario



Evaluaciones de cumplimiento (véase la Parte IV , Evaluación del Cumplimiento 36.2.13 ), actualizado en caso necesario

Página 173 de 670


17. Arquitectura Gestión de Requisitos Este capítulo se centra en el proceso de gestión de requisitos de arquitectura en todo el .

Gestión de  Arquitectura Requisitos: Figura 17‐1

17.1 Objetivos Los objetivos de la fase de gestión de requisitos son los siguientes: 

Asegúrese de que el proceso de gestión de requisitos es sostenido y funciona para todas las fases pertinentes de



Gestione requisitos de arquitectura identificadas durante cualquier ejecución del ciclo o una fase



Asegúrese de que los requisitos de arquitectura relevantes están disponibles para uso de cada fase que se ejecuta la fase

17.2 Enfoque

Página 174 de 670

The Open Group Architecture Framework TOGOF 9.1   17.2.1 general Como se indica por el círculo "Gestión de Requisitos" en el centro de la gráfica , el es impulsado continuamente por el proceso de gestión de requisitos. Es importante señalar que el círculo de Gestión de Requisitos denota no un conjunto estático de requisitos, sino un proceso dinámico mediante el cual se identifican los requisitos de arquitectura de la empresa y los cambios posteriores de los mismos que, almacenan, y se introducen en y fuera de las fases de pertinentes, y También entre los ciclos de la . La capacidad para hacer frente a cambios en las necesidades es crucial. La arquitectura es una actividad que por sus ofertas propia naturaleza con la incertidumbre y el cambio - la "zona gris" entre lo que los actores aspiran y qué se puede especificar y diseñado como una solución. Requisitos de arquitectura son, por tanto, siempre sujeto a cambios en la práctica. Por otra parte, la arquitectura a menudo se ocupa de los conductores y las limitaciones, muchas de las cuales por su propia naturaleza están más allá del control de la empresa (cambio de las condiciones del mercado, las nuevas legislaciones, etc), y que puede producir cambios en los requisitos de forma imprevista. Tenga en cuenta también que el proceso de gestión de requisitos en sí no dispone de, dirección, o priorizar los requisitos; esto se hace dentro de la fase correspondiente de la . No es más que el proceso de gestión de requisitos en todo el general. Se recomienda que un repositorio de requisitos (véase la Parte IV , 41.6.1 Requisitos Repositorio ) se utiliza para registrar y istrar todos los requisitos de arquitectura. A diferencia de la Especificación de Requerimientos Arquitectura, y los requisitos de evaluación de impacto, los requisitos de depósito puede contener la información de múltiples ciclos de .

Desarrollo 17.2.2 Requisitos Los primeros requisitos de alto nivel se articulan como parte de la arquitectura de la Visión, generado mediante el escenario de negocios o una técnica similar. Cada fase de la , de preliminar a la fase H, debe seleccionar los requisitos aprobados para esa fase que se celebró en el repositorio y Arquitectura Requisitos de Especificación de Requisitos. A la finalización de la fase de la situación de estos requisitos tiene que ser actualizado. Durante la ejecución de fase nuevas necesidades generadas para el futuro trabajo de arquitectura en el marco de la Declaración de la corriente de Arquitectura de Trabajo han de estar documentados dentro de la arquitectura de Especificación de Requisitos, y las nuevas necesidades que se encuentran fuera del ámbito de aplicación de la Declaración de la corriente de Arquitectura Trabajo deben introducirse a los requisitos de depósito para la gestión a través del proceso de gestión de requisitos. En cada fase correspondiente de la el arquitecto debe identificar los tipos de requisitos que deben ser cumplidos por la arquitectura, incluyendo aplicable: 




Requisitos no funcionales

En la definición de los requisitos del arquitecto debería tener en cuenta:

Página 175 de 670


Supuestos para requisitos



Restricciones para los requisitos



Principios de dominio específico que impulsan requisitos



Las políticas que afectan los requisitos



Normas que deben cumplir los requisitos



Directrices de la Organización para los requisitos



Las especificaciones para los requisitos

Entregas en fases posteriores de también contienen asignaciones a los requisitos de diseño, y también pueden generar nuevos tipos de requisitos (por ejemplo, los requisitos de conformidad, tiempo ventanas para la implementación).

17.2.3 Recursos El mundo de la ingeniería de requisitos es rico con las recomendaciones emergentes y procesos para la gestión de requisitos. TOGAF no exige ni recomienda ningún proceso o herramienta específica; que se limita a establecer lo que es un proceso de gestión de requisitos efectiva debe lograr (es decir, los "requisitos de los requisitos", si se quiere). 17.2.3.1 Escenarios empresariales

Una técnica efectiva que se describe en sí mismo es TOGAF escenarios de negocio, que son una técnica apropiada y útil para descubrir y documentar los requerimientos del negocio, y para articular una visión de la Arquitectura, que responda a esas necesidades. Escenarios de negocio, se describen en detalle en la Parte III , 26.Escenarios empresariales y objetivos de negocio . 17.2.3.2 Requisitos Herramientas

No es un gran y creciente número de Commercial Off-The-Shelf (COTS) herramientas disponibles para el apoyo de la gestión de requisitos, aunque no necesariamente diseñado para requisitos de arquitectura. El sitio web Volere tiene una lista muy útil de las principales herramientas de requisitos (ver www.volere.co.uk / tools.htm ).

17.3 Entradas Las entradas a la fase de gestión de requisitos son: 

Un poblado Arquitectura repositorio (véase la Parte IV , 36.2.5 Arquitectura del repositorio ),





Página 176 de 670




o


o


o


o


o




o


o










Requisitos de arquitectura, que pueblan una especificación de Arquitectura requisitos (ver la Parte IV , 36.2.6 Arquitectura especificación de requisitos )



Requisitos de Evaluación de Impacto (véase la Parte IV , 36.2.18 Requisitos de Evaluación de Impacto )

17.4 Pasos Los pasos en la fase de gestión de requisitos se describen en la siguiente tabla: Pasos de Gestión de Requisitos Paso 1 Paso Requisitos de referencia: 2

Fase Pasos Identificar los requisitos / documentos - utilizar escenarios de negocios, o una técnica análoga

a. Determine las prioridades que surgen de la fase actual de b. Confirme los interesados buy-in a las prioridades resultantes c. Registros Requisitos prioridades y lugar en

Página 177 de 670

The Open Group Architecture Framework TOGOF 9.1   Requisitos Repositorio Paso Monitorear los requisitos básicos 3 Paso 4

Identificar requisitos modificados: a. Retire o re-evaluar las prioridades b. Añadir requisitos y reevaluar las prioridades c. Modificar los requisitos existentes

Paso Identificar requisitos modificados y prioridades de 5 registros: a. Identificar requisitos modificados y garantizar las exigencias son priorizados por el arquitecto (s) responsables de la fase actual, y por las partes interesadas b. Registre las nuevas prioridades c. Asegúrese de que los conflictos son identificados y gestionados a través de las fases de una conclusión exitosa y priorización d. Generar Requisitos Declaración de Impacto (ver 36.2.18 Requisitos de Evaluación de Impacto ) para dirigir el equipo de arquitectura Notas

Paso 6



Requisitos modificados pueden entrar a través de cualquier vía. Para asegurarse de que los requisitos se evalúan adecuadamente y se priorizan, este proceso necesita dirigir las fases de y registrar las decisiones relacionadas con los requisitos.



La fase de gestión de requisitos es necesario para determinar la satisfacción de las partes interesadas con las decisiones. Donde hay insatisfacción, la fase sigue siendo responsable de garantizar la resolución de los problemas y determinar los próximos pasos. a. Evaluar el impacto de las nuevas exigencias de la fase actual (activo) b. Evaluar el impacto de las nuevas exigencias en las fases anteriores . c Determinar si se debe implementar el cambio, o diferir el ciclo después; si la

Página 178 de 670

The Open Group Architecture Framework TOGOF 9.1   decisión es implementar, evaluar Cronograma de implantación de gestión del cambio d. Declaración de Impacto Requisitos Edición, Versión n 1 Paso 7

Implementar los requisitos derivados de la Fase H La arquitectura se puede cambiar a través de su ciclo de vida por la fase de Arquitectura de Gestión del Cambio (Fase H). El proceso de gestión de requisitos asegura que las nuevas o cambiantes necesidades que se derivan de la Fase H son manejadas en consecuencia.

Paso Actualizar el repositorio Requisitos con información 8 relativa a los cambios solicitados, incluyendo opiniones de los interesados afectados Paso Implementar el cambio en la actual fase 9 Paso Evaluar y revisar el análisis de las deficiencias en las 10 fases anteriores El análisis de las deficiencias en las fases de B a D identifica las brechas entre la línea de base y Target Arquitecturas. Ciertos tipos de brecha puede dar lugar a necesidades brecha. El se describen dos tipos de brecha:



Algo que está presente en la línea de base, pero no en el de destino (es decir, eliminado - por accidente o diseño)



Algo no está en la línea de base, pero presente en el objetivo (es decir, nuevo)

Un "requisito brecha" es cualquier cosa que ha sido eliminado por accidente, por lo que requiere un cambio en la arquitectura destino. Si el análisis de la brecha genera requisitos brecha, este paso se asegurará de que sus destinatarios, documentados y registrados en el Repositorio de Requisitos, y que la Arquitectura objetivo se revisó en consecuencia.

Página 179 de 670


17.5 Salidas Los resultados del proceso de gestión de requisitos pueden incluir, pero no se limitan a: 

Evaluación de Impacto 36.2.18 Requisitos



36.2.6 Arquitectura Especificación de Requisitos , si es necesario

El Repositorio de Requisitos se actualizará como parte de la fase de gestión de requisitos y debe contener toda la información de los requisitos. Cuando surgen nuevas necesidades, o las existentes se cambian, se genera una Declaración de Impacto Requisitos, que identifica las fases de la de que es necesario revisar el hacer frente a los cambios. La declaración continúa a través de diversas iteraciones hasta que la versión final, que incluye todas las implicaciones de los requisitos (por ejemplo, costos, plazos, y métricas de negocio) en el desarrollo de la arquitectura. Una vez que los requisitos para el ciclo actual de se han finalizado entonces la Arquitectura especificación de requisitos debe ser actualizada.

Página 180 de 670


PARTE III Directrices y Técnicas de

Página 181 de 670


18. Introducción Este capítulo proporciona una visión general de los contenidos de la parte III .

18.1 Pautas para adaptar el proceso de El proceso de Arquitectura Método de Desarrollo () se pueden adaptar para hacer frente a una serie de diferentes escenarios de uso, incluyendo diferentes estilos de proceso (por ejemplo, el uso de la iteración) y también las arquitecturas especializadas específicas (como la seguridad). Directrices incluidos dentro de esta parte de TOGAF son los siguientes: 

La aplicación de la iteración a la (véase 19. Aplicando la iteración a la ) discute el concepto de iteración y muestra las posibles estrategias para la aplicación de conceptos iterativos a la .



La aplicación de la a través de la arquitectura del paisaje (ver 20. Aplicando la a través de la Arquitectura del Paisaje ) discute los diferentes tipos de participación de arquitectura que pueden ocurrir en diferentes niveles de la empresa. Esta sección también discute a continuación, cómo el proceso de se puede enfocar para soportar diferentes tipos de compromiso.



Arquitectura de Seguridad y la (véase 21. Arquitectura de Seguridad y el ) proporciona una visión general de las consideraciones específicas de seguridad que deben tenerse en cuenta durante las diferentes fases de la .



Usando TOGAF para definir y Gobierno SOAs (ver 22. Uso TOGAF para definir y Gobierno SOAs ) muestra cómo los conceptos de SOA pueden ser apoyadas por el marco TOGAF y las consideraciones SOA específicos para las diferentes fases de la .

18.2 Técnicas para el Desarrollo de la Arquitectura Las siguientes técnicas se describen en la Parte III: Directrices y Técnicas de para apoyar tareas específicas dentro de la : 

Arquitectura Principios (ver 23 Arquitectura Principios. ) - los principios para la utilización y el despliegue de los recursos de TI en toda la empresa - Describe cómo desarrollar el conjunto de normas y directrices para la arquitectura se desarrolla en general.



Gestión de los interesados (véase 24. Gestión de las partes interesadas ) describe la istración de los interesados, una disciplina importante que los profesionales de la arquitectura de éxito puede utilizar para ganar apoyo para sus proyectos.



Arquitectura Patrones (ver 25. Arquitectura Patrones ) proporciona orientación sobre el uso de patrones de arquitectura.



Escenarios empresariales (véase 26. Escenarios empresariales y objetivos de la empresa ) se describe la técnica de escenarios empresariales, un método para derivar los requisitos de negocio para la arquitectura y los requisitos técnicos implicados.

Página 182 de 670


Análisis de Vacíos (ver 27. Análisis Gap ) describe la técnica conocida como análisis de brechas. Es ampliamente utilizado en el TOGAF para validar una arquitectura que se está desarrollando.



Técnicas de Planificación Migraciones (ver Técnicas de Planificación 28. Migración ) describe una serie de técnicas para apoyar la planificación de la migración en las fases E y F.



Requisitos de interoperabilidad (véase 29. Requisitos de interoperabilidad ) describe una técnica para determinar los requisitos de interoperabilidad.



Evaluación de la preparación de transformación de negocios (véase 30. Empresas Evaluación de la preparación de Transformación ) describe una técnica para la identificación de problemas de transformación empresarial.



Gestión del Riesgo (ver 31. Gestión de Riesgos ) describe una técnica para la gestión de riesgos durante un proyecto de transformación de la arquitectura / negocio.



Capacidad basada en Planificación (ver 32. Planificación de Capacidad basada ) describe la técnica de la planificación basada en la capacidad.

18.3 Uso de TOGAF con diferentes estilos arquitectónicos TOGAF está diseñado para ser flexible y puede ser utilizado con diversos estilos arquitectónicos. Esta parte de TOGAF incluye dos capítulos que pretenden ser ejemplos útiles. 

Arquitectura de Seguridad y la (véase 21. Arquitectura de Seguridad y el )



Usando TOGAF para definir y Gobierno SOAs (ver 22. Uso TOGAF para definir y Gobierno SOAs )

Los estilos arquitectónicos se diferencian en términos de enfoque, la forma, las técnicas, los materiales, el asunto y el período de tiempo. Algunos estilos pueden ser considerados como de moda, otros se centraron en aspectos particulares de la arquitectura empresarial. TOGAF es un marco genérico y destinado a ser utilizado en una amplia variedad de entornos. Es un marco flexible y extensible que se puede adaptar fácilmente a un número de estilos arquitectónicos. Arquitectura del Paisaje de una organización se puede esperar para contener obra de arquitectura que se desarrolla en diversos estilos arquitectónicos. TOGAF asegura que las necesidades de cada grupo de interés se abordan adecuadamente en el contexto de otras partes interesadas y la Arquitectura de Referencia. Al usar TOGAF para apoyar un estilo arquitectónico específico el profesional debe tener en cuenta la combinación de características distintivas en que se realiza o se expresa la arquitectura. Como primera medida, los rasgos distintivos de un estilo deben ser identificados. Por ejemplo, la definición de Open Group para SOA identifica las siguientes características distintivas: 

Se basa en el diseño de los servicios - que reflejan las actividades empresariales del mundo real - que comprenden la empresa (o entre empresas) los procesos de negocio.

Página 183 de 670


Representación del Servicio utiliza descripciones empresariales para proporcionar el contexto (es decir, los procesos de negocio, meta, regla, política, interfaz de servicio, y el componente de servicio) e implementa servicios utilizando la orquestación de servicios.



Coloca los requisitos únicos de la infraestructura -, se recomienda que las implementaciones utilizan estándares abiertos para darse cuenta de la interoperabilidad y la transparencia de ubicación.



Las implementaciones son favorables al medio específico - se ven limitados o habilitadas por el contexto y deben ser descritas dentro de ese contexto.

El segundo paso es determinar cómo se abordarán estas características distintivas. Dirigiéndose a un estilo distintivo no debe pedir cambios significativos en TOGAF; sino que debe ajustar los modelos, puntos de vista y las herramientas utilizadas por el profesional. En la fase B, fase C y la fase D se espera que el practicante para seleccionar los recursos arquitectura pertinentes, incluidos los modelos, puntos de vista y herramientas, para describir adecuadamente el dominio arquitectura y demostrar que las preocupaciones de los interesados se dirigen (ver Parte II , 8.4.1 Seleccionar modelos de referencia, puntos de vista y las herramientas , 10.4.1 Selección de modelos de referencia, puntos de vista y las herramientas , 11.4.1 Selección de modelos de referencia, puntos de vista y las herramientas , y 12.4.1 Selección de modelos de referencia, puntos de vista y herramientas ). Dependiendo de las características distintivas, diferentes estilos arquitectónicos añadirán nuevos elementos que se hará una descripción, resalte los elementos existentes, ajuste la notación utilizada para describir la arquitectura, y el enfoque del arquitecto en algunos grupos de interés o preocupación de las partes interesadas. Dirigiéndose a los rasgos distintivos suele incluir extensiones al Metamodel Arquitectura de contenidos y el uso de la notación específica o técnicas de modelado y la identificación de puntos de vista. Si el estilo es dominante determinará si es necesario volver a examinar la Etapa Preliminar y realizar cambios en la capacidad de Arquitectura o si el apoyo a la característica distintiva es posible en el ámbito de la selección se espera dentro de un solo ciclo de . Modelos de referencia-estilo específico y modelos de madurez son herramientas que apoyan a un practicante de uso común. Con el tiempo se espera que los nuevos estilos arquitectónicos que surjan para abordar los problemas clave que enfrentan los practicantes. Algunos estilos estarán transitoria, algunos se aguantan en un nicho, y algunos se funden en la corriente principal. Existen los Foros Open Group y Grupos de Trabajo para abordar los desafíos que enfrenta la industria. Estos organismos producen una amplia gama de material que sea útil a una practicante interesado en adaptar TOGAF, o un ciclo de en particular, a un estilo arquitectónico particular para los materiales actuales, incluyendo libros blancos y normas aplicables (ver www.opengroup.org/ togaf_docs ).

   Página 184 de 670


19. La aplicación de iteración para el 19.1 Información general La representación gráfica de la TOGAF , como se muestra en la Figura 5-1 , y la descripción de las fases de discretamente en orden en la Parte II , se puede leer que implica una metodología de cascada determinista. Este método se proporciona de presentación para el propósito de comunicar rápidamente los conceptos básicos de desarrollo de la arquitectura y la arquitectura del ciclo de vida. En la práctica, dos conceptos clave se utilizan para gestionar la complejidad del desarrollo de una empresade arquitectura y gestión de su ciclo de vida - la iteración y los niveles (véase . 20 La aplicación de la a través de la arquitectura del paisaje .) Los dos conceptos están estrechamente vinculados. El es compatible con una serie de conceptos que se caracterizan como iteración. En primer lugar, la iteración describe el proceso tanto de la descripción de un Arquitectura del Paisaje integral a través de múltiples ciclos de sobre la base de iniciativas individuales ligados al ámbito de la Solicitud de Arquitectura Obra. En segundo lugar, la iteración describe el proceso integrado de desarrollo de una arquitectura en la que las actividades descritas en las diferentes fases de interactúan para producir una arquitectura integrada. Con el fin de describir de manera concisa la actividad y salidas, esta última iteración se describe en términos secuenciales. En tercer lugar, la iteración describe el proceso de gestión del cambio a la Arquitectura de Capacidad de la organización. Iteración para desarrollar una arquitectura de paisaje integral: 

Proyectos ejercerán a través de todo el ciclo de , comenzando con la Fase A. Cada ciclo de la 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 al mismo tiempo, con las relaciones entre los diferentes proyectos.



Un proyecto puede desencadenar el inicio de otro proyecto. Normalmente, esto se usa cuando las iniciativas de arquitectura de alto nivel a identificar oportunidades o soluciones que requieren una arquitectura más detallada, o cuando un proyecto identifica impactos paisajísticos fuera del alcance de su solicitud de Arquitectura Obra.

La iteración dentro de un ciclo de (iteración Arquitectura Desarrollo): 

Los proyectos pueden operar múltiples fases simultáneamente. Normalmente, esto se utiliza para gestionar la interrelación entre la arquitectura de negocio, Sistemas de Información Arquitectura, Arquitectura y Tecnología.



Proyectos puede realizar un ciclo entre las fases de , en ciclos planificados abarcan múltiples fases. Normalmente, esto se usa para converger en una arquitectura detallada Target cuando la arquitectura de alto nivel no existe para proporcionar contexto y restricción.



Los proyectos pueden volver a etapas anteriores con el fin de círculo hacia atrás y actualizar los productos de trabajo con la nueva información. Normalmente, esto se usa

Página 185 de 670

The Open Group Architecture Framework TOGOF 9.1   para converger en un ejecutable Arquitectura Roap o Ejecución y Plan de Migración, cuando los detalles de la implementación y el alcance del cambio desencadenan un cambio o re-priorización de necesidades de los interesados. Iteración para gestionar la Arquitectura Capability (Capacidad Arquitectura iteración): 

Los proyectos pueden requerir una nueva iteración de la Fase Preliminar (re) establecer los aspectos de la capacidad Arquitectura identificados en la Fase A a dirigir una solicitud de Arquitectura Obra.



Los proyectos pueden requerir una nueva iteración de la Fase Preliminar para ajustar Arquitectura Capacidad de la organización como resultado de la identificación de requisitos nuevos o modificados para Arquitectura capacidad como resultado de una solicitud de cambio en la Fase H.

19.2 Iteración Ciclos Los ciclos de iteración sugeridas para el TOGAF se muestran en la Figura 19-1 , y se pueden utilizar de manera efectiva a los grupos relacionados con actividades de arquitectura para lograr un propósito específico. Estos ciclos de iteración se hace referencia en 19.3 Clases de Arquitectura de compromiso y 19,5 iteración Consideraciones .

Figura 19‐1: ciclos de iteración

Página 186 de 670


Arquitectura Capacidad iteraciones apoyan la creación 1 y la evolución de la capacidad Arquitectura necesario. Esto incluye la movilización inicial de la actividad de la arquitectura para un propósito o una arquitectura de tipo de compromiso dado al establecer o ajustar el enfoque de la arquitectura, los principios, el alcance, la visión y la gobernabilidad.



Arquitectura de Desarrollo iteraciones permiten la creación de contenido de la arquitectura por el ciclismo a través de, o integrar, Negocios, Sistemas de Información y Tecnología de la Arquitectura fases. Estas iteraciones asegurar que la arquitectura se considera como un todo. En este tipo de comentarios de las partes interesadas iteración son típicamente más amplio. A medida que las iteraciones convergen en un objetivo, extensiones en las oportunidades y soluciones y las fases de planeamiento de migración de asegurar que aplicabilidad de la arquitectura se considera que la arquitectura está finalizado.



Planificación de Transición iteraciones apoyan la creación de hojas de ruta del cambio formales para una arquitectura definida.



Arquitectura de Gobierno iteraciones apoyar la gobernabilidad de la actividad de cambio avanzar hacia una Arquitectura objetivo definido.

19.3 Clases de Arquitectura de compromiso Una función o servicios de organización de la arquitectura puede ser llamado para ayudar a una empresa en una serie de contextos diferentes, como las arquitecturas desarrolladas pueden variar de resumen al detalle, amplia cobertura estrecha, y el estado actual de estado futuro. En estos contextos, el concepto de iteración se debe utilizar en el desarrollo de la arquitectura. Por lo general, hay tres áreas de participación para los arquitectos: 

Identificación de Cambio Requerido : Fuera del contexto de cualquier iniciativa de cambio, la arquitectura puede ser utilizado como una técnica para proporcionar la mayor visibilidad de la capacidad de TI con el fin de apoyar la toma de decisiones y la alineación de la ejecución estratégica.



Definición de Cambio : ¿Dónde se ha identificado la necesidad de cambiar, la arquitectura puede ser utilizado como una técnica para definir la naturaleza y el alcance de los cambios de una manera estructurada. Dentro de las iniciativas de cambio gran escala, las arquitecturas pueden ser desarrollados para proporcionar información detallada Arquitectura Definición de las iniciativas de cambio que están delimitadas por el ámbito de un programa o cartera.



Implementación del Cambio : Arquitectura en todos los niveles de la empresa puede ser utilizado como una técnica para proporcionar la gobernabilidad de diseño para cambiar iniciativas, proporcionando visibilidad panorama general, el suministro de las limitaciones estructurales, y la definición de los criterios sobre los que evaluar las decisiones técnicas.

Figura 19-2 y la tabla siguientes muestran las clases de arquitectura de la participación de la empresa.

Página 187 de 670


Figura 19‐2: Clases de arquitectura empresarial de compromiso Cada uno de estos tipos de compromiso de la arquitectura se describe en la siguiente tabla. Área de Compromiso Identificación de Cambio Requerido

Arquitectura Compromiso Apoyo a Estrategia de Negocios

Descripción Como las estrategias de negocio, objetivos, metas y de cambio de conductores, es necesario para que la empresa cambie con el fin de mantener la alineación. La creación de nuevas estrategias de negocio puede ser apoyado por la arquitectura empresarial a través de:

Architectural Gestión de la cartera del Paisaje



Proporcionar visibilidad de las oportunidades de cambio



Proporcionar elaboración en los impactos prácticos de una elección estratégica particular,



Ofrecer pruebas sobre la viabilidad o la viabilidad de una dirección estratégica particular,

Es una práctica común en las grandes organizaciones para una organización de gestión de servicios para proporcionar información operativa y de gestión de la cartera de TI. Arquitectura empresarial puede añadir una nueva dimensión a los informes de gestión de servicios, mediante el apoyo a la vinculación entre el rendimiento operativo y la necesidad estratégica de TI. Uso de la trazabilidad entre TI y el negocio inherente a la arquitectura empresarial, es posible evaluar la cartera de TI

Página 188 de 670


Architectural Gestión de Cartera de Proyectos

frente a los datos de rendimiento operacional y las necesidades del negocio (por ejemplo, el coste, la funcionalidad, la disponibilidad, la capacidad de respuesta) para determinar las áreas donde está ocurriendo la desalineación y el cambio tiene que tener lugar. Es una práctica común en las grandes organizaciones para una organización de gestión de programas para proporcionar información operativa y de gestión de la cartera de cambio. Arquitectura empresarial puede añadir una nueva dimensión a los informes de gestión de cartera de proyectos, mediante el apoyo a la vinculación entre el alcance del proyecto, el impacto arquitectónico y el valor del negocio.

Factores arquitectónicos se pueden añadir a otros factores cuantitativos de proyectos para apoyar la toma de decisiones estratégicas en la prioridad del proyecto y los niveles de financiación. Definición de Cambio Architectural Definición de Iniciativas de cambio fundacionales son los esfuerzos de Fundacionales iniciativas de cambio que tienen un objetivo conocido, pero no son cambio estrictamente cuyo ámbito o delimitadas por una visión o requisitos compartida. En las iniciativas de cambio fundamentales, la prioridad inicial es comprender la naturaleza del problema y de una estructura a la definición del problema.

Architectural Definición de Iniciativas de Cambio delimitadas

Una vez que el problema se entiende de manera más eficaz, es posible definir soluciones apropiadas y para alinear las partes interesadas en torno a una visión y un propósito común. Iniciativas de cambio delimitadas son los esfuerzos de cambio que por lo general surgen como el resultado de una estrategia antes de arquitectura, la evaluación o la visión.

En las iniciativas de cambio acotadas, el resultado deseado ya está entendido y acordado. El foco de los esfuerzos de arquitectura en esta clase de compromiso es elaborar eficazmente una solución de línea base que responda a las necesidades identificadas, problemas, los controladores y las restricciones. Implementación del Gobernanza arquitectónico Una vez que un modelo de solución arquitectónica ha sido Cambio de Cambio Implementación definida, proporciona una base para el diseño y la implementación. Con el fin de garantizar que los objetivos y el valor de la arquitectura definida se realizan adecuadamente, es necesario para la continuación de la gobernanza arquitectura del proceso de implementación para facilitar la revisión del diseño, la arquitectura refinamiento, y el problema de ampliación.

Página 189 de 670

The Open Group Architecture Framework TOGOF 9.1   Las diferentes clases de participación arquitectura en diferentes niveles de la empresa requerirán atención en áreas específicas, como se muestra a continuación. Tipo de compromiso

Ciclos de Enfoque Alcance iteración Focus Apoyo a Estrategia de Negocios Arquitectura Amplio, consideración superficial dado a la arquitectura del Capability paisaje a fin de abordar una cuestión estratégica específica y definir los términos de los esfuerzos más detallados de arquitectura para hacer frente a la estrategia de realización. Arquitectura Desarrollo (Línea de base primero) Architectural Gestión de la cartera Arquitectura del Paisaje Capability

Centrarse en la evaluación física de las aplicaciones de línea de base y de la infraestructura de tecnología para identificar oportunidades de mejora, por lo general dentro de las limitaciones de mantenimiento de los negocios como de costumbre.

Arquitectura Desarrollo (Línea de base primero) Architectural Gestión de Cartera Planificación de la Centrarse en los proyectos, las dependencias del proyecto, y los impactos paisajísticos de alinear secuenciación proyecto de Proyectos Transición de manera que se optimiza arquitectónicamente.

Architectural Definición de Fundacionales iniciativas de cambio

Arquitectura de Gobierno Arquitectura Capability

Centrarse en la elaboración de una visión a través de la definición de la línea de base e identificar lo que debe cambiar para hacer la transición de la línea base a la meta.

Arquitectura Desarrollo (Línea de base primero) Planificación de la Transición Centrarse en la elaboración de la meta de satisfacer una Architectural Definición de Arquitectura visión previamente definido y acordado, el alcance, o un Iniciativas de Cambio delimitadas Desarrollo (Target primero) conjunto de restricciones. Use el destino como una base para el análisis para evitar la perpetuación de la línea de Planificación de la base, arquitecturas sub-óptimos. Gobernanza arquitectónico de Cambio Implementación

Transición Arquitectura de Gobierno

Utilice la Architecture Vision, limitaciones, principios, requisitos, Arquitectura Target definición, y un plan de transición para asegurar que los proyectos se dan cuenta de su beneficio previsto, están alineados entre sí, y están alineados con las necesidades de negocio más amplio.

19.4 Enfoques para el Desarrollo de la Arquitectura Dos enfoques se pueden adoptar dentro de la para el desarrollo de arquitecturas: 

Línea de Base Primera : En este estilo, se utiliza una evaluación del paisaje de referencia para identificar las áreas problemáticas y oportunidades de mejora. Este proceso es más adecuado cuando la línea de base es compleja, no se entiende claramente, o que

Página 190 de 670

The Open Group Architecture Framework TOGOF 9.1   convengan. Este enfoque es común en el que las unidades de organización han tenido un alto grado de autonomía. 

Objetivo Primero : En este estilo, la solución objetivo se elabora en detalle y luego asigna de nuevo a la línea de base, con el fin de identificar la actividad de cambio. Este proceso es adecuado cuando un estado de destino está de acuerdo en un nivel alto y cuando la empresa desea hacer la transición eficazmente a la modelo de destino.

Típicamente, si la línea de base se entiende en líneas generales un valor más alto será obtenido se centra en el objetivo primero y luego la línea de base en la medida necesaria para identificar los cambios. En términos prácticos, un equipo de la arquitectura siempre dará consideración informal a la línea de base en el análisis de la meta (y viceversa ). En situaciones donde se espera que la línea de base y el objetivo a considerar en paralelo por los interesados, se recomienda que el equipo de arquitectura se centra prioritaria en un Estado con el fin de mantener el enfoque y la coherencia de la ejecución.

19.5 Iteración Consideraciones Algunos ciclos de iteración puede ser ejecutado una vez, mientras que otros tienen un número mínimo natural de los ciclos. Para algunos ciclos de iteración, cada iteraciónsigue el mismo proceso; donde hay más de una iteración dentro de un ciclo, el proceso difiere ligeramente para cada una de las iteraciones. Cuando se considera el uso de ciclos de iteración, también es necesario considerar dónde colocar los puntos de control apropiados dentro del proceso. Si el nivel esperado de participación de los interesados es alto, puede ser razonable para llevar a cabo los puntos de control muy frecuentes pero informales para garantizar que el proceso se está moviendo en la dirección deseada. Si las partes interesadas no están tan estrechamente involucrados, entonces los puntos de control pueden ser menos frecuentes pero más formal. Los puestos de control en la finalización de cada ciclo de iteración, o al final de varios ciclos de iteración, son comunes.

19.5.1 La iteración entre Ciclos Cada iteración completa un ciclo de en un solo nivel de descripción de la arquitectura. Este enfoque de la utiliza la Fase F (Migration Planning) para iniciar nuevos proyectos más detallados de desarrollo de la arquitectura. Este enfoque se ilustra en la Figura 19-3 . Este tipo de iteración destaca la necesidad de una arquitectura de alto nivel para orientar y limitar la arquitectura más detallada. También destaca que la arquitectura del paisaje completo ha sido desarrollado por múltiples iteraciones .

Página 191 de 670


Figura 19‐3: Una Jerarquía de  Procesos Ejemplo 19.5.2 La iteración dentro de un ciclo de Cada ciclo de iteración pase por varias fases TOGAF . Las siguientes tablas muestran a un alto nivel que las fases se deben completar para que el ciclo de iteración, que muestra la actividad que es el núcleo (es decir, el enfoque principal de la iteración), actividad que es la luz (es decir, el objetivo secundario de la iteración), y actividad que puede llevarse a cabo de manera informal (es decir, algún tipo de actividad puede llevarse a cabo, pero no se menciona explícitamente en el ).

Página 192 de 670


Figura 19‐4: Actividad por iteración de Línea de Base Primera Arquitectura Definición

Página 193 de 670


Figura 19‐5: Actividad por iteración para Target Primera Arquitectura Definición Los ciclos de iteración sugeridas asignados a las fases TOGAF se describen en la siguiente tabla: La iteración Iteración Propósito del ciclo Arquitectura Iteración Definir la Arquitectura de Desarrollo 1 Referencia. (Línea de base primero)

Descripción Esta iteración comprende un paso a través de la arquitectura de negocios, Sistemas de Información Arquitectura y Arquitectura Tecnología fases de la , centrándose en la definición de la línea de base.

Oportunidades, soluciones y planes de migración también se consideran para sacar el foco para el cambio y la viabilidad de prueba. Iteración Definir la arquitectura destino Esta iteración comprende un paso a 2 y las lagunas. través de la arquitectura de negocios, Sistemas de Información Arquitectura y Arquitectura Tecnología fases de la , centrándose en la definición de los objetivos y análisis de brechas en contra de la línea de base.

Iteraciónn Refinar la línea de base, el objetivo, y las lagunas.

Oportunidades, soluciones y planes de migración también se consideran para probar la viabilidad. Iteraciones Arquitectura de desarrollo posteriores intentan corregir y

Página 194 de 670


Arquitectura Desarrollo (Target primero)

Iteración Definir la arquitectura 1 destino.

Iteración Definir la Arquitectura y las 2 lagunas de línea de base.

perfeccionar el objetivo de lograr un resultado que sea beneficioso, factible y viable. Esta iteración comprende un paso a través de la arquitectura de negocios, Sistemas de Información Arquitectura y Arquitectura Tecnología fases de la , centrándose en la definición de la meta. Oportunidades, soluciones y planes de migración también se consideran para sacar el foco para el cambio y la viabilidad de prueba. Esta iteración comprende un paso a través de la arquitectura de negocios, Sistemas de Información Arquitectura y Arquitectura Tecnología fases de la , centrándose en la definición de los espacios de referencia y análisis contra el objetivo.

Oportunidades, soluciones y planes de migración también se consideran para probar la viabilidad. Iteraciónn Refinar la línea de base, el Iteraciones Arquitectura de desarrollo objetivo, y las lagunas. posteriores intentan corregir y perfeccionar el objetivo de lograr un resultado que sea beneficioso, factible y viable. Planificación de Iteración Definir y acordar una serie de La primera iteración de la planificación la Transición 1 oportunidades de mejora, de la transición busca ganar buy-in a alineados contra una una cartera de oportunidades con arquitectura provisional de soluciones para las Oportunidades y transición. Soluciones fase de . Esta iteración también ofrece un plan de migración provisional. Iteraciónn Acordar la arquitectura de Iteraciones posteriores de planificación transición, el de la transición tratan de perfeccionar perfeccionamiento de las el plan de migración, la alimentación oportunidades de mejora de los números anteriores en las identificadas para adaptarse. oportunidades y soluciones para la fase de refinamiento. Arquitectura de Iteración Movilizar gobernabilidad La arquitectura de la gobernanza Gobierno 1 arquitectura y cambiar los iteración inicial establece un proceso procesos de gestión. para la gobernanza del cambio y también pone en su lugar a las personas adecuadas, procesos ytecnología para apoyar el controlado a y el cambio de la arquitectura definida. Iteraciónn Llevar a cabo la Iteraciones posteriores de la Arquitectura enfoque de ciclo de gobernabilidad y la Gobierno en la revisión periódica de arquitectura de control de las iniciativas de cambio para resolver cambios. los problemas y garantizar su cumplimiento. Los resultados de una

Página 195 de 670

The Open Group Architecture Framework TOGOF 9.1   solicitud de cambio pueden desencadenar otra fase a ser revisado; por ejemplo, la alimentación de nuevo un nuevo requisito para la Etapa Preliminar para mejorar la Capacidad de Arquitectura, o un nuevo requisito para la arquitectura en las fases de desarrollo de la arquitectura.

19.6 Conclusiones Todas estas técnicas son aplicaciones válidas de la . Combinado juntos, representan cómo el se puede utilizar en la práctica. El siempre se debe utilizar en un proceso iterativo. . ¿Cómo se ejerce este proceso depende de factores organizativos factores particulares a considerar incluyen: 

La formalidad y la naturaleza de los puestos de control de procesos establecidos dentro de la organización. ¿El mandato de la organización de que ciertos grupos de actividades se llevan a cabo entre los puestos de control? ¿Tiene el mandato de la organización de que ciertas actividades deben finalizarse antes de que otras actividades se puede realizar?



El nivel de participación de los interesados se esperaba dentro del proceso. Están interesados esperando a participar estrechamente en el desarrollo de una solución, o están a la espera de ver un conjunto completo de prestaciones para su revisión y aprobación?



El número de equipos participantes y de las relaciones entre los diferentes equipos. Es toda la arquitectura está siendo desarrollado por un equipo específico, o hay una jerarquía de equipos con las relaciones de gobierno entre ellos?



La madurez del área de la solución y la cantidad esperada de la reanudación y el refinamiento necesario para llegar a una solución aceptable. ¿Se puede lograr la solución en un solo paso, o requiere un extenso trabajo de prueba de concepto y prototipos para evolucionar un resultado adecuado ?



Actitud hacia el riesgo. ¿Reacciona la cultura organizacional negativamente a parcialmente los productos de trabajo completas se distribuyen? ¿Requiere la cultura organizacional soluciones que deben probarse en un entorno de prueba antes de que puedan ser implementadas por la aplicación general?



La clase de compromiso. ¿Cuál es el contexto para el desarrollo de la arquitectura de la empresa?



Página 196 de 670


20. Aplicando la a través de la Arquitectura del Paisaje 20.1 Información general En una empresa típica, muchas arquitecturas se describirán en la arquitectura del paisaje en cualquier punto en el tiempo. Algunas arquitecturas abordarán necesidades muy específicas; otros serán más general. Algunos abordar detalle; Algunos pueden ofrecer una gran imagen. Para hacer frente a esta complejidad TOGAF utiliza los conceptos de niveles y Enterprise Continuum para proporcionar un marco conceptual para la organización de la Arquitectura del Paisaje. Estos conceptos están estrechamente vinculados con la organización de contenido real en la arquitectura de repositorio y cualquier partición de arquitectura se discuten en la Parte V .

20.2 Arquitectura del Paisaje Niveles proporcionan un marco para dividir la arquitectura del paisaje en tres niveles de granularidad:

1. Arquitectura Estratégico proporciona un marco de organización de la actividad operativa y el cambio y permite la configuración de dirección a nivel ejecutivo. 2. Arquitectura Segmento proporciona un marco de organización de la actividad operativa y el cambio y permite la configuración de la dirección y el desarrollo de los planes de trabajo de arquitectura eficaces a nivel de programa o cartera.

3. Arquitectura Capability ofrece un marco organizativo para la actividad de cambio y el desarrollo de planes de trabajo eficaces arquitectura realizando incrementos de capacidad. La Figura 20-1 muestra un resumen del modelo de clasificación de Arquitectura Paisajes.

Página 197 de 670


Figura 20‐1: Resumen Clasificación Modelo de Arquitectura Paisajes La Arquitectura Continuum proporciona un método de dividir cada nivel de la arquitectura del paisaje (ver 39.4.1 Arquitectura Continuum ) por la abstracción. Ofrece una forma coherente de definir y entender las reglas genéricas, las representaciones y las relaciones en una arquitectura , incluyendo las relaciones de trazabilidad y de derivación. La Arquitectura Continuum muestra las relaciones de elementos de cimentación a la arquitectura específica de la organización, como se muestra en la Figura 20-2 . La Arquitectura Continuum es una herramienta útil para descubrir en común y eliminar la redundancia innecesaria.

Figura 20‐2: Resumen de Arquitectura Continuum Los niveles y la Continuum Arquitectura proporcionan un mecanismo amplio para describir y clasificar la Arquitectura del Paisaje. Estos conceptos pueden ser usados para organizar la arquitectura del paisaje en un conjunto de arquitecturas relacionadas con: 

Complejidad manejable para cada arquitectura o solución individual

Página 198 de 670


Agrupaciones definidas



Jerarquías definidas y estructuras de navegación



Procesos adecuados, roles y responsabilidades adjuntas a cada agrupación

No existe un modelo de organización definitiva de la arquitectura, ya que cada empresa debe adoptar un modelo que refleje su propio modelo de funcionamiento.

20.3 Organización de la Arquitectura del Paisaje para comprender el estado de la Empresa Las siguientes características se utilizan normalmente para organizar la Arquitectura del Paisaje: 

Amplitud : El área de amplitud (objeto) es por lo general la característica de organización primaria para la descripción de una arquitectura del paisaje. Arquitecturas están funcionalmente descomponerse en una jerarquía de áreas o segmentos de materias específicas.



Profundidad : Con áreas más amplias, se necesita menos detalle para asegurar que la arquitectura tiene un tamaño y una complejidad manejable. Áreas temáticas más específicas, generalmente permitir (y requerirá) arquitecturas más detalladas.



Tiempo : Para una amplitud y profundidad específica de una empresa puede crear una arquitectura de referencia y un conjunto de arquitecturas objetivo que se extienden hacia el futuro. Arquitecturas más amplios y menos detallados serán generalmente válidas por períodos más largos de tiempo y pueden proporcionar una visión de la empresa, que se extiende más hacia el futuro.



Fecha reciente : Finalmente, cada vista de la arquitectura va a progresar a través de un ciclo de desarrollo donde aumenta la precisión hasta que finalmente aprobado. Después de la aprobación, una arquitectura comenzará a disminuir en precisión si no se mantiene activa. En algunos casos de experiencia reciente se puede utilizar como un factor de la organización para las arquitecturas históricas.

Utilizando los criterios anteriores, las arquitecturas se pueden agrupar en, por segmentos y niveles de Arquitectura de la capacidad estratégica, tal como se describe en la Figura 20-1 .

20.4 Desarrollo de arquitecturas en diferentes niveles Las secciones anteriores han identificado que se requieren diferentes tipos de arquitectura para estudiar las distintas necesidades de los interesados en los diferentes niveles de la organización. Cada arquitectura típicamente no existe de manera aislada y por lo tanto debe sentarse dentro de una jerarquía de gobierno. Amplio, arquitecturas de síntesis que figura la dirección para arquitecturas estrechas y detalladas. . Un número de técnicas se puede emplear para utilizar el como un proceso que apoya tales jerarquías de arquitecturas Esencialmente hay dos estrategias que se pueden aplicar:

Página 199 de 670

The Open Group Architecture Framework TOGOF 9.1   1. Arquitecturas en los diferentes niveles se pueden desarrollar a través de iteraciones dentro de un solo ciclo del proceso de . 2. Arquitecturas en los diferentes niveles se pueden desarrollar a través de una jerarquía de procesos de , ejecutado simultáneamente. En los extremos de la escala, cualquiera de estas dos opciones se pueden adoptar plenamente. En la práctica, un arquitecto es probable que tenga que combinar elementos de cada uno para adaptarse a los requisitos exactos de su Solicitud de Arquitectura Obra. Cada uno de estos enfoques se describe en 19. La aplicación de iteración para el .

Página 200 de 670


21. Arquitectura de Seguridad y el 21.1 Información general El objetivo de este capítulo es explicar las consideraciones de seguridad que deben ser abordados durante la aplicación del Método de Desarrollo de Arquitectura TOGAF ().

21.2 Introducción Métodos de desarrollo de la arquitectura son herramientas en las manos del practicante de seguridad que se utilizarán para crear las mejores prácticas y la capacidad de seguridad específicas de cada organización. La orientación que se incluye aquí es ayudar a los dos arquitectos de la empresa y los profesionales de seguridad para evitar la pérdida de los problemas de seguridad críticos. En este capítulo se informa a la empresa artífice de lo que necesitará el arquitecto de seguridad para llevar a cabo durante los trabajos de arquitectura de seguridad. A menudo, la arquitectura de seguridad es tratado como un dominio de la arquitectura independiente dentro de la arquitectura de la empresa, mientras que necesitan ser integrados plenamente en el mismo. El enfoque del arquitecto de seguridad es la ejecución de las políticas de seguridad de la empresa, sin inhibir valor. Arquitecturas de seguridad generalmente tienen las siguientes características: 

Arquitectura de seguridad tiene su propia metodología de seguridad discreto.



Arquitectura de seguridad compone sus propias opiniones y puntos de vista diferenciados.



Arquitectura de seguridad se ocupa de los flujos no normativos a través de sistemas y entre las aplicaciones.



Arquitectura de seguridad presenta sus propios flujos normativos a través de sistemas y entre las aplicaciones.



Arquitectura de seguridad presenta, componentes de una sola función única en el diseño.



Arquitectura de seguridad requiere su propio conjunto único de habilidades y competencias de la empresa y los arquitectos de TI.

21.3 Orientación de Seguridad para los Dominios Arquitectura Los problemas de seguridad son omnipresentes en todo los ámbitos de la arquitectura y en todas las fases del desarrollo de la arquitectura. Seguridad es declarado out por separado debido a que es una infraestructura que no suele ser visible a la función empresarial. Su propósito fundamental es proteger el valor de los sistemas y activos de información de la empresa. Con frecuencia, la

Página 201 de 670

The Open Group Architecture Framework TOGOF 9.1   naturaleza de la seguridad en la empresa es que se considera exitoso si bien no ocurre nada es visible para el u otro observador, y / o no hay daños o pérdidas ocurren a la empresa. Por ejemplo, los datos en una base de datos de los registros de clientes no se filtraron o dañados - o un tema intangible, como el nombre de la empresa aparece en un artículo en las noticias diciendo que sus sistemas de datos habían sido comprometidos. La arquitectura de seguridad tiene sus propios componentes de un solo uso y se experimenta como una cualidad de los sistemas en la arquitectura. El punto de vista de Seguridad Empresarial de la arquitectura tiene sus propios bloques únicos de construcción, colaboraciones, y las interfaces. Estos elementos de seguridad-única deben interconectar con los sistemas de negocio de una manera equilibrada y rentable, a fin de mantener las políticas de seguridad de la empresa, aún no interferir con las operaciones del sistema y funciones. Es menos costoso y más eficaz para planificar y ejecutar funciones específicas de seguridad en la arquitectura de destino lo antes posible en el ciclo de desarrollo para evitar la costosa adaptación o reelaborar porque los bloques de construcción necesarios para la seguridad no se añadieron o se utilizan durante el desarrollo de sistemas y despliegue . El enfoque del arquitecto de seguridad en cuenta no sólo el flujo normal de la aplicación, sino también los flujos anormales, modos de falla, y las formas de los sistemas y las aplicaciones pueden ser interrumpidos y fallan. Todos los grupos de partes interesadas en la empresa se tienen problemas de seguridad y es deseable para traer un arquitecto de seguridad en el proyecto lo antes posible.A lo largo de las fases de la , la orientación se ofrecerá en la información específica de la seguridad que deben ser reunidos, los pasos que se deben tomar, y los artefactos que se deben crear. Arquitectura decisiones relacionadas con la seguridad deben realizarse de conformidad con las decisiones comerciales y políticas y su gestión de riesgos. Las áreas generalmente aceptadas de la preocupación por el arquitecto de seguridad son: 

Autenticación : La fundamentación de la identidad de una persona o entidad relacionada con la empresa o el sistema de alguna manera.



Autorización : La definición y la aplicación de las capacidades permitidas para una persona o entidad cuya identidad ha sido establecida.



Auditoría : La capacidad de proporcionar datos forenses que conste que los sistemas se han utilizado de acuerdo con las políticas de seguridad establecidas.



Aseguramiento : La capacidad de probar y demostrar que la arquitectura de la empresa tiene los atributos de seguridad necesarias para defender las políticas de seguridad establecidas.



Disponibilidad : La capacidad de la empresa para funcionar sin interrupción del servicio o el agotamiento a pesar de acontecimientos anormales o maliciosos.



Protección de Activos : La protección de los activos de información de la pérdida o divulgación no intencional, y los recursos de un uso no autorizado y no deseado.



istración : La capacidad de agregar y cambiar las políticas de seguridad, agregar o cambiar cómo se implementan las políticas de la empresa, y añadir o cambiar las personas o entidades vinculados a los sistemas.



Gestión de Riesgos : actitud y tolerancia al riesgo de la organización. (Esta gestión del riesgo es diferente de la definición especial que se encuentra en los mercados financieros

Página 202 de 670

The Open Group Architecture Framework TOGOF 9.1   y las instituciones de seguros que cuentan con departamentos formales de gestión de riesgo.) Típicos artefactos arquitectura de seguridad se incluyen: 

Las reglas de negocio con respecto al manejo de los activos de datos / información



Política de seguridad Escrito y publicado



Datos codificados / información de propiedad y custodia de activos



Documentación de análisis de riesgos



Documentación política de clasificación de datos

Gestión Arquitectura 21,4 Requisitos La política de seguridad y las normas de seguridad se convierten en parte del proceso de gestión de requisitos empresariales. La política de seguridad se establece en un nivel ejecutivo de la empresa, es de larga duración y resistente al cambio caprichoso. La política de seguridad no está ligado a ninguna tecnología específica. Una vez que se establecen las políticas de seguridad, pueden ser referidos como requisitos para todos los proyectos de arquitectura. Las normas de seguridad cambian con más frecuencia y las preferencias tecnológicas estatales utilizados para apoyar las políticas de seguridad. Las nuevas tecnologías que apoyan la implementación de políticas de seguridad de una mejor manera se pueden adoptar, según sea necesario. Las mejoras pueden estar en la reducción de costos o el aumento de los beneficios. Las normas de seguridad se manifestarán como bloques de construcción relacionados con la seguridad en la Empresa Continuum. Patrones de seguridad para el despliegue de estos bloques de construcción relacionadas con la seguridad se hace referencia en la Guía de Seguridad para la Fase E. Nuevos requisitos de seguridad surgen de muchas fuentes:

1. Un nuevo mandato estatutario o reglamentario 2. Una nueva amenaza se dio cuenta o experimentado 3. Una nueva iniciativa de la arquitectura de TI descubre nuevas partes interesadas y / o nuevos requerimientos En el caso en que 1. y 2. arriba ocurren, estos nuevos requisitos serían los conductores para la entrada al sistema de gestión del cambio discutido en la Fase H. Una nueva iniciativa de la arquitectura podría ser lanzado para examinar la infraestructura y las aplicaciones existentes para determinar el alcance de los cambios necesarios para satisfacer las nuevas demandas. En el caso de 3. arriba , un nuevo requisito de seguridad entrará en el sistema de gestión de requisitos. Es nuestra buena seguridad?

Esta pregunta surge inevitablemente de la istración para el arquitecto de seguridad. No hay medidas de seguridad son siempre perfecto, y existe la posibilidad de que la cantidad de dinero y

Página 203 de 670

The Open Group Architecture Framework TOGOF 9.1   esfuerzo realizado para llegar a ser muy grande para poca rentabilidad adicional. Pruebas de control de seguridad debe estar en su lugar para que los sistemas de seguridad se pueden medir para asegurarse de que se mantienen las políticas de seguridad para el que fueron diseñados. Auditorías de políticas de seguridad deben mantenerse y puede ser obligatorio por ley o reglamento. Estas auditorías de seguridad y los posibles cambios en las políticas de seguridad son la razón exacta por la separación de la aplicación de la política del código de la aplicación es tan fuertemente enfatizado. Nada útil se puede decir de una medida de seguridad fuera del contexto de una aplicación o de un sistema y su entorno

La eficacia de una medida de seguridad se considera en relación con el riesgo que mitiga. Una empresa no puede determinar cuánto va a estar dispuesto a gastar en la obtención de un activo hasta que se comprende el valor de los activos. Por ejemplo, el uso de ese activo en una aplicación y el riesgo concomitante el activo está expuesto a como resultado, determinará los verdaderos requisitos para la seguridad. Además, la tolerancia de la organización para el riesgo es un factor. En otras palabras, la pregunta que no debería ser: "¿Está seguro?" sino más bien: "¿Es lo suficientemente seguro?" Este último es en última instancia una pregunta que debe responderse mediante el análisis de riesgos.

21.5 Fase Preliminar Alcance de las organizaciones empresariales afectadas por la arquitectura de seguridad



Identificar empresa de la base (unidades) - aquellos que son los más afectados y lograr mayor valor de los trabajos de seguridad



Identificar empresariales blandos (unidades) - los que se ven el cambio a su capacidad y trabajar con unidades básicas, pero son de otra forma no directamente afectados



Identificar empresariales extendidas (unidades) - aquellas unidades fuera de la empresa de ámbito que necesitará para mejorar su arquitectura de seguridad para fines de interoperabilidad



Identificar las comunidades implicadas (empresas) - las partes interesadas que se verán afectados por las capacidades de seguridad y que se encuentran en los grupos de las comunidades



Identifique la gobernanza de la seguridad involucrados, incluidos los marcos jurídicos y geografías (empresas)

Si el modelo de negocio de la organización hace abarcar federación con otras organizaciones, en la medida de la federación de seguridad debe establecerse en este punto en el proceso. Acuerdos de federación contractuales deben ser examinados por sus implicaciones y acuerdos de seguridad. Puede que sea necesario establecer reuniones arquitectura conjuntas con otros de una federación para establecer interfaces y protocolos para el intercambio de información de seguridad relacionada con la identidad federada, autenticación y autorización. Definir y documentar los requisitos reglamentarios y de política de seguridad aplicables

El marco y los principios rara vez cambian, por lo que las implicaciones de seguridad llamados en los objetivos de esta fase debería ser bastante sencillo. Una política de seguridad por escrito de la

Página 204 de 670

The Open Group Architecture Framework TOGOF 9.1   organización debe estar en su lugar, y no debe haber notificación regular y la educación establecidos para los empleados. ISO / IEC 17799:2005 es un buen lugar para comenzar la formación de una política de seguridad, y se puede utilizar para evaluar la disposición de seguridad de una organización. Sin una política de seguridad por escrito y publicado, su aplicación es difícil. Las políticas de seguridad se refieren a muchos aspectos de la seguridad de la organización - como la seguridad locales físicos - que son remotamente relacionadas con la seguridad de los sistemas y aplicaciones. La política de seguridad debe ser examinada para encontrar secciones pertinentes, y se actualiza si es necesario. Arquitectura limitaciones establecidas en la política de seguridad deben ser comunicados a los demás del equipo de arquitectura. De manera similar, puede haber requisitos reglamentarios que especifican las obligaciones del sistema debe cumplir o acciones que se deben tomar. Si el sistema estará sujeto a la regulación dependerá de la funcionalidad del sistema y los datos recogidos o mantenidas. Además, la jurisdicción donde se despliega el sistema o servicio, donde residen los s, o en virtud de la cual la entidad está desplegando fletados o incorporados informará de esta decisión. Puede ser aconsejable obtener asesoramiento legal con respecto a estas obligaciones al inicio de las actividades. Definir la capacidad de seguridad requerido como parte de la arquitectura de Capacidad

Acuerdo sobre el papel del arquitecto de seguridad en el proceso de arquitectura de la empresa y en la arquitectura y el gobierno de TI también deben establecerse. Las consideraciones de seguridad pueden entrar en conflicto con consideraciones funcionales y se requiere un defensor de la seguridad para garantizar que todas las cuestiones se abordan y los conflictos de intereses no impiden la consideración explícita de temas difíciles. Decisiones políticas ejecutivas deben establecerse en este punto acerca de lo que las políticas de seguridad puede ser negociable y qué políticas deben hacerse cumplir por razones reglamentarias o estatutarias. Implementar herramientas de arquitectura de seguridad

El nivel de formalidad utilizado para definir y gestionar la seguridad de contenidos arquitectura será altamente dependiente de la escala, la sofisticación y la cultura de la función de la arquitectura de seguridad. El acercamiento a las herramientas de seguridad puede estar basado en el uso relativamente informal de aplicaciones de productividad de oficina estándar, o puede estar basada en una implementación personalizada de herramientas de arquitectura de seguridad especializadas y técnicas.

21.5.1 Entradas de seguridad  La política de seguridad por escrito 

Estatutos pertinentes



Lista de las jurisdicciones aplicables

Las salidas de seguridad 21.5.2  Lista de los reglamentos aplicables 

Lista de las políticas de seguridad aplicables



Equipo de seguridad roster

Página 205 de 670


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 . Las siguientes especificaciones de seguridad adecuadas para la arquitectura de seguridad deben abordarse en cada fase, además de las actividades de eliminación de genéricos. Las etapas de la fase de Visión Arquitectura son aplicables a garantizar que los requisitos de seguridad se abordan en las fases posteriores de la . Las consideraciones de seguridad tendrán un efecto en la empresa de tal manera que todo el desarrollo de la arquitectura empresarial debe ser informada y utilizar la política de seguridad, las limitaciones, la gobernanza, los artefactos, y bloques de construcción. Después de establecer cualquier proyecto de arquitectura de la empresa, las siguientes actividades relacionadas con la seguridad específicas deben llevarse a cabo. Definición de los grupos de interés y de descubrimiento pertinentes de sus preocupaciones y objetivos requerirá el desarrollo de un escenario de alto nivel. Requisitos de negocio clave También se establecerán a través de este trabajo de escenarios temprano. El proceso de escenario empresarial TOGAF puede ser útil aquí y en etapas posteriores. Obtener el apoyo de la gestión de las medidas de seguridad

En forma similar a obtener el reconocimiento y la gestión de aval para el proyecto en general la arquitectura, así también la aprobación de los aspectos relacionados con la seguridad de las actividades de desarrollo de arquitectura debe ser obtenido. Reconocimiento de que el proyecto podría tener el desarrollo y el impacto de infraestructuras que no son fácilmente visibles por mirar únicamente a los sistemas en cuestión debe quedar claro. Examinar a fondo y la mitigación de los problemas relacionados con el riesgo y la seguridad pueden ser percibidos como un desperdicio de recursos y de tiempo; el nivel de apoyo a la gestión debe entenderse y comunicarse en todo el equipo. Definir gestión hitos sign-off en materia de seguridad necesarias de este ciclo de desarrollo de la arquitectura

La trazabilidad de decisiones de arquitectura relacionados con la seguridad debe ser documentado y los ejecutivos apropiados y gestión de la línea que necesitan para estar informado de los aspectos relacionados con la seguridad del proyecto deben ser identificados y la frecuencia de los informes debe ser establecido. Se debe reconocer que existe la tensión entre la entrega de la nueva función empresarial y la ejecución de políticas de seguridad, y que un proceso para resolver tales disputas que surjan deben establecerse al principio del proyecto. Estas tensiones tienen a menudo el resultado de poner el arquitecto de seguridad aparentemente "en la forma de completar el proyecto." Se necesita ser entendido por la dirección y los demás arquitectos involucrados que el papel del arquitecto de seguridad es el de salvaguardar los activos de la empresa. Determinar y documentar la recuperación de desastres y continuidad de negocio aplicable planes / requisitos

Cualquier recuperación de desastres existentes y los planes de continuidad de negocio deben ser comprendidas y su relación con el sistema de planificación definidos y documentados.

Página 206 de 670

The Open Group Architecture Framework TOGOF 9.1   Identificar y documentar el / / ambiente anticipado física negocio regulatorio (s) en que se implementará el sistema (s)

Todas las decisiones de arquitectura deben hacerse en el contexto de los entornos en los que el sistema se puede colocar y operar. Entornos físicos que deben ser documentados pueden incluir entornos de batalla, ambientes comerciales, ambientes al aire libre, los entornos móviles y similares. De manera similar, el entorno empresarial se debe definir. Entornos empresariales potenciales pueden incluir diferentes supuestos sobre los s y las interfaces de s, y éstos o interfaces pueden llevar la carga de los entornos regulatorios en que debe operar el sistema (s de menores de trece años en los EE.UU., por ejemplo). Determinar y documentar la criticidad del sistema: safety-critical/mission-critical/non-critical

Establecer sistemas de seguridad crítica vive en peligro en caso de avería o mal funcionamiento. Establecer sistemas de dinero de misión crítica, la cuota de mercado, o el capital en riesgo en caso de fallo. Los sistemas no críticos tienen pocas o ninguna consecuencia en caso de fracaso.

21.6.1 Entradas de seguridad  Lista de las políticas de seguridad aplicables 

Lista de las jurisdicciones aplicables



Planes de recuperación de desastres completa y la continuidad del negocio

Las salidas de seguridad 21.6.2  Declaración entorno de seguridad física 

Declaración entorno de seguridad de negocios



Declaración Entorno regulatorio



Carta de la política de seguridad firmado por el consejero delegado o delegada



Lista de los puntos de control de desarrollo de la arquitectura de seguridad de cierre de sesión



Lista de los planes de recuperación de desastres y continuidad de negocio aplicable



Declaración Sistemas criticidad

21.7 Fase B: Arquitectura de Negocios Determinar quiénes son los actores legítimos que interactuarán con el producto / servicio / proceso

Elaboración de los escenarios de negocio y posteriores de alto nivel casos de uso del proyecto en cuestión traerá a la atención de las personas protagonistas y actores del sistema implicados. Muchos ulteriores decisiones sobre la autorización se basará en una sólida comprensión de los presuntos s, es y operadores del sistema, además de sus capacidades y características esperadas. Se debe tener en cuenta que los s pueden no ser

Página 207 de 670

The Open Group Architecture Framework TOGOF 9.1   los seres humanos; aplicaciones de software pueden ser los s legítimos. Los que cuidaban a las necesidades istrativas, tales como operadores de copia de seguridad, también deben ser identificados, ya que los s deben límites externos de confianza, tales como los clientes basados en Internet. Evaluar y los procesos de negocio específicos de seguridad de línea de base actuales (mejora de objetivo existente)

El proceso de negocio con respecto a cómo los actores son investigados ya que los s adecuados del sistema debe documentarse. También se debe hacer para los actores de fuera de la organización que son s propios del sistema. Las entidades externas se determinarán a partir de los escenarios de alto nivel desarrollados como parte de la Fase A. Determinar los cuales / cuánto es aceptable para inconveniente en la utilización de medidas de seguridad

Las medidas de seguridad, si bien son importantes, pueden imponer una carga sobre los s y el personal istrativo. Algunos responderán a esa carga mediante la búsqueda de formas de burlar las medidas. Algunos ejemplos son los es de encontrar maneras de crear "puertas traseras" o los clientes que eligen un competidor para evitar la carga percibida de la infraestructura. Las compensaciones pueden requerir equilibrar las ventajas de seguridad en contra de ventajas comerciales y exigir una elección juiciosa informado. Identificar y documentar los sistemas de interconexión más allá del control del proyecto

Cada sistema cibernético o negocio debe basarse en los sistemas existentes más allá del control del proyecto. Estos sistemas tienen ventajas y desventajas, riesgos y beneficios. Los ejemplos incluyen el sistema de nombres de dominio (DNS) que resuelve nombres de equipos y de servicios a las direcciones de Internet, o el papel moneda emitido por la Tesorería local. La dirección devuelta por el anfitrión o el servicio DNS no siempre puede ser digno de confianza; papel moneda no siempre puede ser genuina, y el recurso varía en la eficacia entre las jurisdicciones. Estas interfaces deben ser entendidos y documentados. Determinar los activos en riesgo, si algo sale mal - "¿Qué estamos tratando de proteger?"

Activos no siempre son tangibles y no siempre son fáciles de cuantificar. Algunos ejemplos son: la pérdida de la vida, la pérdida de la buena voluntad del cliente, la pérdida de una calificación de bonos AAA, la pérdida de cuota de mercado. Determinar el costo (tanto cualitativa como cuantitativa) de la pérdida de activos / impacto en casos de insuficiencia

Hay que recordar que dichos activos más difíciles de cuantificar pueden ser el más valioso y no debe ser descuidado. Incluso las estimaciones cualitativas resultar útiles en la evaluación de los riesgos comparativos. Identificar y documentar la propiedad de los activos

Los activos pueden ser propiedad de entidades externas, o por entidades de su interior. Dentro entidades pueden ser propiedad de los individuos o de las organizaciones.Determine:

Página 208 de 670


¿Dónde se supone que la confianza



¿Cómo se establece



¿Cómo se comunica

Siempre rastrearlo con el mundo real; es decir: 

Evaluación (búsquedas de crédito, que dé fe personal)



Responsabilidad civil (daños monetarios, penas de cárcel, sanciones)

Todas las decisiones de seguridad se basan en la confianza que se ha establecido de alguna manera. No hay supuestos fiduciarios tienen ningún valor si no pueden tener sus raíces en la evaluación y la responsabilidad en el mundo real. En la mayoría de los entornos de negocio, la confianza se establece a través de contratos que definen la responsabilidad cuando se rompe la confianza. La responsabilidad de la evaluación de la confianza es la responsabilidad de los que decidan entrar en los contratos y sus abogados. Es importante tener en cuenta que la tecnología (por ejemplo, certificados digitales, SAML, etc) no puede crear confianza, pero sólo se puede transmitir en el mundo de la electrónica de la confianza que ya existe en el mundo real a través de las relaciones comerciales, acuerdos legales y consistencias de política de seguridad .

Determinar y documentar los procesos forenses de seguridad apropiado

Para ser capaces de hacer cumplir las políticas de seguridad, infracciones de seguridad deben ser adecuadamente capturados por lo que la determinación de problemas y posibles políticas o acciones legales se pueden tomar contra la entidad que causa el incumplimiento. Prácticas forenses adecuados para proporcionar evidencia en su caso la necesidad de ser establecida y documentada. El personal de seguridad deben estar capacitados para seguir los procedimientos forenses y material de capacitación sobre la necesidad de reunir pruebas debe ser considerado para la educación de seguridad estándar proporcionada a los trabajadores. Identificar la criticidad de la disponibilidad y el correcto funcionamiento del servicio en general

Los riesgos asociados con la pérdida de la disponibilidad pueden ya han sido adecuadamente considerados en la evaluación mission-critical/safety-critical anterior. Determinar y documentar cuánta seguridad (coste) se justifica por las amenazas y el valor de los activos en riesgo

Un análisis de riesgos (la comprensión del valor de los activos en riesgo y la probabilidad de las amenazas potenciales) proporciona una guía importante para las inversiones en estrategias de mitigación para las amenazas identificadas. Vuelva a evaluar y confirmar las decisiones Architecture Vision

Página 209 de 670

The Open Group Architecture Framework TOGOF 9.1   El análisis de negocios implica una serie de ejercicios de pensamiento riguroso y puede poner en cuestión los supuestos iniciales identificadas en el Architecture Vision. Evaluar la alineación o conflicto de las políticas de seguridad identificados con los objetivos empresariales

Las políticas de seguridad identificadas en la Fase Preliminar pueden tener disposiciones que son difíciles o imposibles de conciliar con los objetivos de negocio a la luz de los riesgos identificados. Las posibles respuestas incluyen la alteración de los aspectos del entorno empresarial, la modificación de la población de s prevista, o técnico de mitigación de riesgos (tratados en la Fase C). Determinar "lo que puede salir mal?"

Realizar un análisis de las amenazas que identifica las amenazas de alto nivel que influyan en el sistema y su probabilidad.

21.7.1 Entradas de seguridad  Declaraciones de negocios y el medio ambiente de seguridad reglamentario inicial 

Lista de los planes de recuperación de desastres y continuidad de negocio aplicable



Lista de las políticas y normas de seguridad aplicables

Las salidas de seguridad 21.7.2  Lista de los procesos forenses 

Lista de los nuevos requisitos de recuperación de desastres y continuidad del negocio



Declaraciones de negocios y de entorno regulatorio validados



Lista de las políticas y normas de seguridad validadas



Lista de los procesos de seguridad de destino



Lista de los procesos de seguridad de línea de base



Lista de los actores de la seguridad



Lista de los sistemas de interconexión



Declaración de la tolerancia de seguridad para cada clase de agente de seguridad



Lista de activos con los valores y los propietarios



Lista de rutas de confianza



Declaración de impacto Disponibilidad (s)



Matriz de análisis de amenazas

21.8 Fase C: Arquitecturas de Sistemas de Información Página 210 de 670

The Open Group Architecture Framework TOGOF 9.1   Evaluar y elementos de referencia actuales de seguridad específicas de la arquitectura (de mejora de objetivo existente)

Un inventario completo de los elementos de la arquitectura que implementan servicios de seguridad debe ser compilado en la preparación de un análisis de brecha. Identificar acciones predeterminadas seguras y estados de fallo

Cada cambio de estado en cualquier sistema se precipita por algún disparador. Por lo general, un conjunto enumerado de los valores esperados de ese gatillo inicia un cambio en el estado. Sin embargo, hay probablemente otras entradas de disparo potenciales que deben ser acomodados en los casos no normativas. Además, un fallo del sistema puede tener lugar en cualquier momento en el tiempo. Acciones predeterminadas seguras y modos de falla deben ser definidas para el sistema informado por el estado actual, el entorno empresarial, las políticas aplicables y obligaciones reglamentarias. Modos predeterminados de seguros para un automóvil a velocidad cero ya no sean aplicables a toda velocidad. Estados de insuficiencia de seguros para los dispositivos médicos difieren notablemente de los estados de fallo de seguridad para la electrónica de consumo. Identificar y evaluar las directrices y normas reconocidas aplicables

Las normas son justamente acredita para la reducción de costes, la mejora de la interoperabilidad, y el aprovechamiento de la innovación. Desde el punto de vista de seguridad, protocolos estándar, bibliotecas de objetos estándares e implementaciones estándar que han sido examinados por expertos en sus campos ayudan a asegurar que los errores no encuentran su camino en las implementaciones. Desde un punto de vista de la seguridad, los errores son las vulnerabilidades de seguridad. Revisar las suposiciones relativas a los sistemas de interconexión más allá del control del proyecto

A la luz de las evaluaciones de riesgos realizadas, supuestos relativos a los sistemas de interconexión puede ser necesario modificar. Determinar y documentar el nivel de sensibilidad o de la clasificación de la información almacenada / creado / usado

La información almacenada, creado o manipulado por el sistema puede o no puede ser objeto de una clasificación oficial que define su sensibilidad y las obligaciones a las que el sistema y sus propietarios están sometidas. La ausencia de una clasificación oficial no exime necesariamente la responsabilidad en el mantenimiento de la confidencialidad de los datos. La consideración se debe hacer para los diferentes carga legislativa que pueda sostener la jurisdicción sobre el sistema y los datos almacenados. Identificar y custodia de documentos de los activos

Todos los activos de valor sean conservados y mantenidos en nombre del propietario. Las personas u organizaciones específicas encargadas de esta responsabilidad deben ser identificados. Identificar la criticidad de la disponibilidad y el correcto funcionamiento de cada función

Página 211 de 670

The Open Group Architecture Framework TOGOF 9.1   Es de suponer que, en caso de fallo del sistema o la pérdida de funcionalidad, algún valor se pierde a los interesados. El costo de esta pérdida de oportunidad debe ser cuantificada, si es posible, y se documenta. Determinar la relación del sistema en fase de diseño de los planes de negocios de desastres / continuidad existentes

Planes de desastre en el negocio / de continuidad existentes pueden acomodar el sistema considerado. Si no, algunos análisis se llama para determinar la brecha y el costo si esa brecha se va sin llenar. Identificar qué aspectos del sistema debe ser configurable para reflejar los cambios en el control de la política de medio ambiente / negocio /

Sin medio ambiente es estática y sistemas debe evolucionar para adaptarse a los cambios. Sistemas con arquitectura de listo reconfiguración se reflejan mejor que el cambio y el resultado en un menor costo durante la vida útil del sistema. La seguridad se mejora cuando los cambios relacionados con la seguridad se pueden implementar a bajo costo y son, por lo tanto, no dejados de lado. La seguridad también se ve reforzada cuando los cambios no requieren cambios en el código; cambios en el código introducen insectos y bichos introducir vulnerabilidades de seguridad. Identificar la vida útil de la información utilizada según la definición de las necesidades del negocio y los requisitos reglamentarios

La información mantenida más allá de su vida útil representa un desperdicio de recursos y, potencialmente, las decisiones de negocio basadas en datos subóptimos.Reglamento, sin embargo, a veces obliga el calendario de mantenimiento de la información como datos de archivo. Determinar los enfoques para hacer frente a los riesgos identificados:



Mitigar



Aceptar



Transferencia



Evitar

Hay varias formas estándar para hacer frente a los riesgos identificados y cuantificados. La lista anterior no pretende ser exhaustiva de todos los enfoques. Identificar las acciones / eventos que merecen el registro para su posterior revisión o desencadenar procesos forenses

Acciones anómalas y estados superarán en número a las acciones y los estados previstos. Estas transiciones se justifica la tala de reconstruir cadenas de eventos, facilitar el análisis de la causa raíz, y, posiblemente, establecer pruebas para la acción civil o penal. Hay que tener en cuenta que los registros deben ser revisados regularmente para ser introducido como evidencia en una corte de la ley en algunas jurisdicciones.

Página 212 de 670

The Open Group Architecture Framework TOGOF 9.1   Identificar y los requisitos de documentación para demostrar el rigor en la precisión de los eventos registrados (no repudio)

Desde manipulación malintencionada de los sistemas comúnmente se acompaña de alteración de los datos registrados para frustrar la investigación y de la aprehensión, la capacidad de proteger y establecer la veracidad de los registros a través de métodos criptográficos eliminará la incertidumbre de las investigaciones e impulsar los casos en los procedimientos judiciales.

Identificar potenciales probables vías de ataque /

Pensar como un adversario preparará el arquitecto para la creación de un sistema robusto que resiste la manipulación maliciosa y, providencialmente, mal funcionamiento derivado de error aleatorio. Determinar "lo que puede salir mal?"

21.8.1 Entradas de seguridad  Matriz de análisis de amenazas 

El análisis de riesgos



Procesos forenses Documentados



Políticas y regulaciones comerciales validados



Lista de los sistemas de interconexión



Nuevos requisitos de recuperación de desastres y continuidad del negocio

Las salidas de seguridad 21.8.2  Evento de la matriz y los requisitos de nivel de registro 

Estrategia de gestión de riesgos



Definiciones de ciclo de vida de datos



Lista de los elementos del sistema configurables



Lista básica de los elementos relacionados con la seguridad del sistema



Elementos nuevos o aumentados relacionados con la seguridad del sistema



Seguridad modelos de casos de uso:



o

Los modelos normativos

o

Los modelos no normativos

Relación de normas de seguridad aplicables:

Página 213 de 670


Protocolos

o

Bibliotecas de objetos

o

Otros ...



Lista del sistema interconectado Validado



Informe de clasificación Información



Lista de los depositarios de activos



Instrucción Function criticidad



Planes de recuperación de desastres y continuidad del negocio revisado



Matriz de análisis de amenazas refinado

21.9 Fase D: Architecture Tecnología Evaluar y tecnologías específicas de seguridad actuales de referencia (mejora de objetivo existente) Revisar las suposiciones relativas a los sistemas de interconexión más allá del control del proyecto Identificar y evaluar las directrices y normas reconocidas aplicables Identificar los métodos para regular el consumo de los recursos

Cada sistema se basará en los recursos que puede estar agotada en los casos que pueden o no pueden preverse en el punto de diseño del sistema. Los ejemplos incluyen el ancho de banda de red, carga de la batería, espacio en disco, la memoria disponible, y así sucesivamente. Como se utilizan los recursos que se acerca el agotamiento, la funcionalidad puede verse afectada o puede fallar por completo. Pasos de diseño que identifican los recursos no renovables, métodos que pueden reconocer el agotamiento de recursos, y las medidas que pueden responder a través de la limitación de los factores causales, oa través de la limitación de los efectos del agotamiento de los recursos a la funcionalidad no crítica, pueden mejorar la fiabilidad y la disponibilidad generales de la sistema. Diseñar un método por el cual se medirá la eficacia de las medidas de seguridad y se comunica de forma continua

Dado que los sistemas se despliegan y operan en entornos dinámicos, las medidas de seguridad funcionan según distintos grados de eficacia que surgen amenazas inesperadas y como amenazas esperados cambian en el medio ambiente. Un método que facilita la evaluación continua del valor de las medidas de seguridad informará a los cambios en curso en el sistema en respuesta a las cambiantes necesidades de los s, patrones de amenaza y los problemas encontrados. Identificar la confianza (holgura) nivel de:



Todos los s del sistema



Todos los es del sistema

Página 214 de 670


Todos los sistemas de interconexión más allá del control del proyecto

Los requisitos reglamentarios, los niveles de clasificación de la información, y las necesidades empresariales de los propietarios de activos influirán el nivel requerido de confianza que se necesitarán todas las entidades interactivas que cumplir para calificar para el a datos o servicios. Identificar los privilegios mínimos necesarios para cualquier entidad para lograr un objetivo técnico o empresarial

La concesión de las capacidades de radicales a cualquier , aplicación, u otra entidad puede simplificar finalización transacción exitosa a costa de complicar o que impiden el control y la auditoría eficaz. Muchas obligaciones reglamentarias son más difíciles de demostrar el cumplimiento donde los privilegios están barriendo y los controles están sueltos. Identificar las medidas de mitigación de seguridad, cuando esté justificado por la evaluación de riesgos

Este objetivo es donde los servicios de seguridad clásicos de identificación, autenticación, autorización, confidencialidad de datos, integridad de los datos, no repudio, la seguridad y la auditoría se ponen en juego, después de que se determine su aplicabilidad y la relación costo / valor de la protección de su identificación. Determinar "lo que puede salir mal?"

21.9.1 Entradas de seguridad  Lista de elementos relacionados con la seguridad del sistema 

Lista de los sistemas interconectados



Relación de normas de seguridad aplicables



Lista de los actores de la seguridad



Estrategia de gestión de riesgos



Políticas de seguridad validadas



Requisitos reglamentarios validados



Políticas de negocio validados relacionados con la confianza requisitos

Las salidas de seguridad 21.9.2  Lista básica de las tecnologías de seguridad 

Lista de sistemas interconectados Validado



Lista de las normas de seguridad seleccionadas



Plan de conservación de recursos



Métricas de seguridad y plan de monitoreo

Página 215 de 670


Las políticas de autorización del



Plan de gestión de riesgos



La confianza del requisitos (despacho)

21.10 Fase E: Oportunidades y Soluciones Identificar los servicios de seguridad existentes disponibles para su reutilización

A partir de la arquitectura de seguridad de línea de base y la empresa Continuum, habrá infraestructura de seguridad existente y bloques de construcción de la seguridad que se puede aplicar a las exigencias derivadas de este compromiso el desarrollo de la arquitectura. Por ejemplo, si existe el requisito para el control de de la aplicación externa a una aplicación en desarrollo, y ya existe un sistema de este tipo, que puede ser utilizado de nuevo. Los requisitos legales o reglamentarios pueden exigir la separación física de los dominios que puede eliminar la posibilidad de volver a utilizar la infraestructura existente. Los productos conocidos, herramientas, bloques de construcción, y los patrones se pueden utilizar, aunque de reciente aplicación. Medidas de mitigación que aborden Ingeniero riesgos identificados

Habiendo determinado los riesgos susceptibles de mitigación y evaluado la inversión apropiada en que la mitigación en lo que respecta a los activos en riesgo, las medidas de mitigación deben ser diseñados, implementados, desplegados y / u operados. Evaluar software de seguridad reutilizables y recursos del sistema de seguridad probado y

Desde el diseño, código, y los errores de configuración son las raíces de muchas vulnerabilidades de seguridad, aprovechando cualquier solución de problemas ya diseñada, revisados, probados y probados en campo reducirá la exposición a la seguridad y mejorar la fiabilidad. Identificar nuevos códigos / recursos / activos que son apropiados para la reutilización

Rellenar el repositorio Arquitectura con nuevos bloques de construcción de la seguridad. Determinar "lo que puede salir mal?"

21.11 Fase F: planeamiento de migración Evaluar el impacto de las nuevas medidas de seguridad sobre otros componentes nuevos o sistemas apalancados existentes

En una aplicación gradual de los nuevos componentes de seguridad son generalmente parte de la infraestructura en la que se implementa el nuevo sistema. La infraestructura de seguridad tiene que estar en una primera fase o principios para apoyar adecuadamente el proyecto. Implementar métodos de supervisión mediante las cuales se medirá la eficacia de las medidas de seguridad y comunicada en forma permanente

Página 216 de 670

The Open Group Architecture Framework TOGOF 9.1   Durante las fases de operación, mecanismos son utilizados para monitorear el desempeño de muchos aspectos del sistema. Su seguridad y la disponibilidad no son una excepción. Identificar parámetros correctos seguras de instalación, las condiciones iniciales y las configuraciones

La seguridad de cualquier sistema que no depende del diseño y puesta en práctica por sí sola, sino también después de la instalación y el estado operativo. Estas condiciones deben ser definidas y controladas no sólo en la implementación, sino también en toda la operación. Implementar la recuperación de desastres y planes de continuidad del negocio o modificaciones Determinar "lo que puede salir mal?"

21.12 Fase G: Gobernanza Aplicación Establecer artefacto arquitectura, el diseño, y las revisiones de código y definir los criterios de aceptación para la implementación exitosa de los hallazgos

Muchas vulnerabilidades de seguridad se originan como diseño o errores de código y el método más simple y menos costosa para localizar y encontrar estos errores es generalmente una pronta revisión por pares con experiencia en el oficio. Localización de tales errores, por supuesto, es el primer paso y la aplicación de correcciones a un punto apropiado en el ciclo de vida de desarrollo es necesaria para beneficiarse de la inversión. Seguimiento de las inspecciones o revisiones de aceptación formalizados puede justificarse en entornos de alta seguridad o de seguridad críticos. Implementar métodos y procedimientos para revisar las pruebas aportadas por el sistema que refleja la estabilidad operativa y la adhesión a las políticas de seguridad

Si bien es necesario que todos los aspectos de una empresa exitosa planificación y especificación, son insuficientes ante la ausencia de pruebas y auditoría para garantizar el cumplimiento de que la planificación y especificación tanto por su despliegue y operación. Entre los métodos que se deben ejercer son: 

Configuraciones del sistema de revisión con impacto en la seguridad que pueden ser modificados para garantizar los cambios de configuración no se han puesto en peligro la seguridad del diseño



Auditar el diseño, la implementación y las operaciones contra las políticas de seguridad



Auditar el diseño, la implementación y las operaciones contra objetivos de negocio



Ejecutar casos de prueba en contra de sistemas que garanticen los sistemas de seguridad se han implementado tal como fue diseñado



Ejecute las pruebas de recuperación de desastres



Ejecute las pruebas de continuidad de negocio

Implementar la capacitación necesaria para asegurar la implementación correcta, la configuración y el funcionamiento de los subsistemas y componentes relevantes para la seguridad; garantizar la

Página 217 de 670

The Open Group Architecture Framework TOGOF 9.1   formación de la conciencia de todos los s y los operadores no privilegiados del sistema y / o sus componentes

La formación no es necesario simplemente para impedir vulnerabilidades introducidas a través de operaciones y error de configuración, aunque esto es crítica para corregir el rendimiento seguro en curso. En muchas jurisdicciones, una formación adecuada debe realizarse y documentarse para demostrar la debida diligencia y justificar las medidas correctivas o sanciones en los casos en que explota o los objetivos de negocio de compromiso de error o para absolver a la responsabilidad contributiva para los eventos que provocan un daño o lesión. Determinar "lo que ha ido mal?"

El propósito mismo de la gobernanza es el establecimiento de un sistema de retroalimentación que determina la eficacia de la ejecución del plan y aplica correcciones, cuando se requiera. Hay que tener en cuenta que las imperfecciones en los planes ejecutados están arraigadas tanto en los procesos humanos y los procesos cibernéticos.

21.13 Fase H: Gestión Arquitectura Cambio Como se indica en la Parte II , 17. Arquitectura Requisitos de gestión (gestión de requisitos), el cambio se debe a las nuevas necesidades. Los cambios en los requisitos de seguridad son a menudo más perjudicial que una simplificación o cambio incremental. Los cambios en la política de seguridad pueden ser conducidos por el estatuto, reglamento, o algo que se ha hecho mal. Los cambios en las normas de seguridad son por lo general menos perjudicial desde el trade-off para su adopción se basa en el valor de cambio. Sin embargo, los cambios en estándares también pueden ser obligatorias. Enfoques similares a estos cambios, como se menciona más arriba son buenas reglas de oro para la seguridad también. Sin embargo, los cambios de seguridad son a menudo los cambios de infraestructura, y pueden tener un mayor impacto. Un cambio aparentemente pequeño requisito de seguridad puede provocar fácilmente un nuevo ciclo de desarrollo de la arquitectura. Determinar "lo que ha ido mal?"

Buenas prácticas forenses de seguridad en conjunto con una política de seguridad publicada por escrito hacen determinación de lo que ha ido mal posible. Además, hacen que la aplicación sea posible. A medida que la orientación anterior sugiere, pequeños cambios se pueden hacer en el contexto de la gestión del cambio y los principales cambios requerirán un nuevo esfuerzo de la arquitectura. Incorporar los cambios pertinentes a la seguridad para el medio ambiente en los requisitos para la futura mejora (mejora de objetivo existente)

Los cambios que surgen como consecuencia de un problema de seguridad o una nueva tecnología de seguridad se utilizarán en el proceso de gestión de requisitos.

21,14 Referencias 

NIST 80018: Guía para el desarrollo de Planes de Seguridad para Sistemas Informáticos

Página 218 de 670


NIST 80027: Principios de Ingeniería de Tecnologías de Seguridad Informática (una línea de base para el logro de la seguridad)



NIST 80030: Guía para la Gestión de Riesgos de Sistemas Informáticos

Página 219 de 670


22. Uso de TOGAF para definir y Gobierno SOAs 22.1 Información general En este capítulo se describen: 

Service-Oriented Architecture (SOA) como un estilo arquitectónico



Factores relacionados con la adopción y la implementación de SOA en la empresa



Usando el TOGAF Arquitectura Método de Desarrollo () para desarrollar su SOA

En este capítulo, en su caso, se incluyen referencias a las Normas Técnicas y Guías desarrolladas por el Grupo de Trabajo SOA Open Group.

22.2 Introducción A medida que el ambiente de negocios se vuelve más sofisticada, los desafíos que enfrentan las organizaciones están pasando de cuestiones de eficiencia y automatización hacia las cuestiones de la gestión de la complejidad y la agilidad del negocio. Redes complejas de aplicaciones e interfaces existentes crean paisajes de gran complejidad donde el cambio se vuelve más y más difícil y los impactos del cambio se vuelven más difíciles de predecir y entender. El concepto de SOA ofrece un estilo arquitectónico que se destina específicamente para simplificar el negocio y la interoperación de diferentes partes de ese negocio. Al estructurar la capacidad de los servicios significativos, granulares en oposición a, unidades de negocio silo'ed opacos, se hace posible identificar rápidamente las capacidades funcionales de una organización, evitar la duplicación de funciones similares a través de la organización y de montar rápidamente nuevas capacidades. Al estandarizar el comportamiento y la interoperabilidad de los servicios, es posible limitar los efectos del cambio y también para entender por adelantado la cadena de probabilidades de impactos. Desde una perspectiva de desarrollo de software, SOA se centra en las aplicaciones de la estructuración de una manera que facilita la flexibilidad del sistema y la agilidad - Una necesidad en el entorno complejo y de rápido movimiento de hoy del negocio. SOA pretende romper los silos de aplicaciones tradicionales en las carteras de servicios más granulares que operan en formas abiertas e interoperables, mientras que la extracción de la capacidad de los productos básicos en una plataforma de infraestructura virtual de los servicios públicos reutilizables compartidos.

Página 220 de 670


22.3 SOA Definición Nota: Esta sección se proporciona para conveniencia del lector. Parte I , 3. Definiciones deberían remitirse a las definiciones formales. Arquitectura Orientada a Servicios (SOA) es un estilo arquitectónico que apoya la orientación a servicios. La orientación a servicios es una manera de pensar en términos de servicios y el desarrollo basado en el servicio y los resultados de los servicios. Un servicio es una representación lógica de una actividad de negocio repetible que tiene un resultado específico (por ejemplo, verificación de crédito del cliente, proporcionar datos meteorológicos, consolidar los informes de perforación, etc) y: 

Es autónomo



Puede estar compuesto de otros servicios



Es un "recuadro negro" para los consumidores del servicio

Un estilo arquitectónico es la combinación de características distintivas en que se realiza o se expresa la arquitectura.

22.4 Características de SOA SOA se basa en el diseño de los servicios - que reflejan las actividades empresariales del mundo real - que comprenden la empresa (o entre empresas) los procesos de negocio. Representación del Servicio utiliza descripciones empresariales para proporcionar el contexto (es decir, los procesos de negocio, meta, regla, política, interfaz de servicio, componente de servicio, etc.) SOA coloca requisitos únicos de la infraestructura. Debido a esto, se recomienda que las implementaciones utilizan estándares abiertos para darse cuenta de la interoperabilidad y la transparencia de ubicación. Por ejemplo, la disponibilidad de servicios de alguna manera debe ser documentado en un lugar de fácil en las que requieren el uso de esos servicios. Un servicio de directorio en SOA específico y un Enterprise Service Bus (ESB) son dos ejemplos de implementaciones de tecnología que requieren la adhesión a los estándares abiertos relevantes para la interoperabilidad que SOA promete. Las implementaciones son específica del entorno de la empresa - que se ven limitados o habilitadas por el contexto y deben ser descritas dentro de ese contexto. Teniendo en cuenta que, SOA requiere un gobierno fuerte de la representación de servicios y la ejecución.

22.5 Arquitectura Empresarial y SOA

Página 221 de 670

The Open Group Architecture Framework TOGOF 9.1   Arquitectura Enterprise proporciona marcos, herramientas y técnicas para ayudar a las organizaciones en el desarrollo y mantenimiento de sus SOAs. Algunos de los beneficios clave que la arquitectura empresarial ofrece son: 

Abstracciones coherentes de estrategias de alto nivel y las prestaciones de apoyo a la planificación y el análisis



Vinculación de las diferentes perspectivas a un problema de negocio único (por ejemplo, los negocios, los sistemas de información, la tecnología, la amplitud, la profundidad, el nivel de detalle, etc) que proporcionan un modelo coherente para hacer frente a diversos dominios y pruebas de integridad



Identificación de las hojas de ruta claras para lograr el estado futuro



Trazabilidad que las TI y otros activos se vincula a los negocios que apoyan



El apoyo a la evaluación del impacto, análisis de riesgo / valor, y la gestión de carteras



Principios identificados y documentados, las limitaciones, los marcos, patrones y normas



Los marcos de gobernanza y procesos que aseguren la autoridad competente para la toma de decisiones

Arquitectura empresarial se convierte en una base para el servicio-orientar una organización, porque vincula partes interesadas, asegurando que las necesidades de cada comunidad de partes interesadas que se cumplan y que cada comunidad de interesados es consciente del contexto apropiado. Esta vinculación es la base para la interoperabilidad y la reutilización. A través de su vinculación al contexto empresarial para TI, arquitectura empresarial permite identificar con facilidad y proporciona justificación para el costo de los programas de cambio en relación con el valor de negocio que se derivan de la pena. Arquitectura empresarial puede proporcionar las capacidades de contexto y análisis de: 

Mostrar cómo las soluciones de SOA pueden con arquitectura eficaz para apoyar las capacidades empresariales



Mostrar que los servicios deben ser construidos y que se debe volver a utilizar



Mostrar cómo los servicios deben ser diseñados

Sin arquitectura de la empresa, los efectos negativos pueden incluir uno o más de los siguientes: 

Agilidad Limited



Dificultad para la identificación y la orquestación de servicios SOA



La expansión de servicios



Crecimiento exponencial desafíos de la gobernanza



Limited interoperabilidad de servicios SOA



SOA servicio de reutilización limitada

Página 222 de 670


Múltiple silo'ed SOAs



Dificultad evolucionando y cambiando las implementaciones de SOA

22.6 SOA y Niveles El tamaño y la complejidad de una empresa afecta a la forma en que la EA desarrolla su arquitectura. Donde hay muchos diferentes modelos organizativos y empresariales, no es práctico para integrarlos dentro de una única arquitectura. Hay muy pocos elementos de la infraestructura, con la excepción de la Internet y la World Wide Web, quese pueden aplicar en la totalidad de una gran organización. Incluso éstos sólo proporcionan un nivel básico de apoyo a los procesos de negocio. En general, puede no ser apropiado para desarrollar un único SOA integrada para una empresa grande y compleja. Para tal empresa, asumiendo una arquitectura del paisaje como se muestra en la Figura 20-1 , el arquitecto debe buscar primero en el desarrollo de una arquitectura estratégica que da un resumen descripción formal de la empresa, proporcionando un marco de organización de la actividad operativa y el cambio, y un ejecutivo nivel, visión a largo plazo para el ajuste de la dirección. Esto podría, por ejemplo, identificar segmentos particulares donde se debe utilizar SOA, y la convocatoria de uso de los servicios para la interacción entre los segmentos, pero es muy poco probable para especificar determinados servicios o grupos de servicios, o para prescribir una infraestructura detallada para SOA. El arquitecto podría entonces desarrollar arquitecturas de segmentos, cada uno de los cuales da una descripción detallada y formal de las áreas dentro de una empresa, que se utiliza a nivel de programa o de una cartera de organizar y alinear la actividad de cambio. Cada una de estas arquitecturas segmento podría ser un único, SOA integrada. Para una empresa pequeña y menos compleja cuyo negocio operaciones puede compartir una infraestructura común, puede usar TOGAF para crear una SOA integrada con grupos de servicios de apoyo a las actividades empresariales. A partir de aquí se supone que el alcance sea una empresa de este tipo. Podría ser autopermanente o de un segmento de una empresa más grande.

22.6.1 Nivel de detalle de Especificación de Implementación ¿Cómo se debe por completo la arquitectura de definir lo que para poner en práctica? En un extremo, se podría especificar el futuro de la empresa, y definir todos los cambios para alcanzar el objetivo, incluidos los proyectos que producirán los cambios, y un plan detallado de tiempo. En el otro extremo, sólo puede indicar áreas donde se necesita trabajo, y sugerir prioridades para abordarlos. Arquitectura desarrollo podría caer en cualquier lugar entre estos dos extremos. Para el tipo de SOA empresarial que estamos considerando aquí, es probable que se especificaría la infraestructura y definir los proyectos para su ejecución, con un plan detallado de tiempo. Usted puede hacer lo mismo para todas o algunas de las soluciones. Por otra parte, en particular cuando la agilidad es importante, es posible identificar las soluciones, y tal vez especifica las versiones iniciales de los mismos, pero permiten soluciones adicionales para ser identificados más tarde, y para los proyectos de implementación para desarrollar más versiones de las soluciones sin tener que pedir cambios en el arquitectura.

Página 223 de 670

The Open Group Architecture Framework TOGOF 9.1   22.6.2 Actividades de SOA en los diferentes niveles En el ámbito de la arquitectura estratégica de la cuestión básica de SOA es identificar si necesita SOA y en la que los segmentos. En la arquitectura estratégica que identifique: 

Las relaciones de alto nivel y los límites dentro de la organización



(Se necesita qué información y funcionalidad a través de segmentos) los requisitos de capacidad SOA Cross-segmento



Entre las principales funcionalidades mejor tratadas por SOA



Las capacidades clave necesarias para SOA



Segmentos mejor abordados por SOA



Principios y patrones de desarrollo de los servicios SOA y la descripción, que pueden ser definidas a nivel de segmento y la capacidad



Las funciones, responsabilidades, procesos y herramientas de gobierno de SOA



La Arquitectura de referencia específica de la organización

A nivel de segmento la cuestión básica de SOA describe la estructura de la arquitectura SOA. En las Arquitecturas Segmento definimos: 

¿Qué capacidades utilizarán SOA como un estilo de la arquitectura



(Se necesita qué información y funcionalidad a través de capacidades) relaciones cruzadas de capacidad



(Se necesita qué información y funcionalidad a través de segmentos) relaciones más detalladas segmentación cruzada



Servicios SOA Cross-capacidad de las posibilidades de reutilización



Principios y patrones de desarrollo de los servicios SOA y la descripción, que pueden ser definidos en el Plan Estratégico y los niveles de capacidad; es más común para definir estos como parte de la arquitectura del Segmento

Para Arquitectura Capability la cuestión básica de SOA es que los servicios estarán disponibles. En las arquitecturas de capacidad describiremos: 

Los requisitos funcionales y no funcionales de la capacidad



Requisitos de servicio SOA Cross-capacidad



Servicios SOA que permiten cruzada capacidad de reutilización



Servicios SOA que permiten la capacidad



Principios y patrones de desarrollo de los servicios SOA y la descripción, que pueden ser definidos a nivel estratégico y de segmento

Página 224 de 670

The Open Group Architecture Framework TOGOF 9.1   Independientemente del nivel de ser perseguido arquitectura es posible identificar soluciones SOA que mejor servicio de las necesidades de la empresa.

22.7 Uso de TOGAF para SOA En esta sección se describe, para cada fase del TOGAF , lo que debe considerarse cuando se busca aplicar el principio de la orientación a servicios, y cómo esto afecta a la fase. Esto no pretende ser una descripción autónomo y debe leerse en conjunción con otras secciones de este documento.

22.7.1 Fase Preliminar La fase preliminar es cuando la capacidad Arquitectura está adaptado para soportar SOA. Los resultados clave de esta fase son los principios, la estructura organizativa, la gobernanza y el contenido inicial de la arquitectura de repositorio. 22.7.1.1 Principio de la Orientación a Servicios

El punto de partida para el desarrollo de SOA con TOGAF es que la empresa adopta la orientación a servicios, como principio la arquitectura (véase el Principio 6: Servicio de Orientación ). Una empresa que desee utilizar TOGAF para SOA debe incluir este principio, ya sea en su forma actual o con modificaciones, en su conjunto de principios de arquitectura. Si el arquitecto es la introducción de TOGAF a una empresa que ya está comprometido con SOA, o que es parte de una empresa más grande que se ha tomado la decisión estratégica de utilizar SOA, a continuación, la adopción del principio de la orientación a servicios es sencillo. Si, por el contrario, SOA se está introduciendo a una empresa que no esté comprometido con él, entonces la decisión de adoptar este principio no debe tomarse a la ligera. El éxito de SOA depende en parte de la disposición de la empresa para convertirse orientada a servicios. La organización puede llevar a cabo una evaluación de la madurez de SOA en la fase preliminar, utilizando el Modelo de Madurez de Integración de Servicios Open Group (OSIMM) como parte de la revisión del contexto de la organización para la realización de la arquitectura empresarial. Esto ayudará a establecer los fundamentos de la empresa a adoptar el principio de la orientación a servicios. A pesar de que una empresa puede estar comprometida con SOA, no siempre es conveniente utilizar el estilo SOA para hacer frente a todos los problemas de la arquitectura. A medida que la sección sobre los niveles identificados segmentos específicos o capacidades pueden ser mejor servidos por SOA en una organización de otra manera no comprometida; o segmentos o capacidades específicas pueden no ser adecuados para SOA en una organización comprometida con SOA. A partir de aquí se supone que se adopta el principio de la orientación a servicios. 22.7.1.2 Gobernabilidad y estrategia de apoyo

Una revisión debe ocurrir de los procedimientos de gobierno existentes, lo que confirma que son apropiadas para SOA. Si no lo son, entonces se deben hacer recomendaciones para el cambio para que sean apropiadas.

Página 225 de 670

The Open Group Architecture Framework TOGOF 9.1   The Open Group cuenta con un marco de gobernanza estandarizado que se centra en la SOA y puede ser utilizada para mejorar los marcos de gobernanza existentes (ver El Gobierno Open Grupo SOA Framework Norma Técnica). Esto proporciona un modelo de referencia de alto nivel de cómo se extiende el gobierno de SOA y es compatible tanto con la arquitectura empresarial y de gobierno de TI. También incluye un método de vitalidad Gobernabilidad SOA (SGVM) que se puede utilizar para definir un régimen específico de gobierno de SOA adaptado a la visión de la organización de la gobernanza.

Figura 22‐1: El Marco de Gobernabilidad SOA Open Grupo 22.7.1.3 Particiones y Centros de Excelencia

Diferentes equipos trabajarán en los diferentes elementos de la arquitectura al mismo tiempo. Las particiones permiten a grupos específicos de los arquitectos a poseer y desarrollar elementos específicos de la arquitectura. Se sugiere que el equipo se inicia con una iniciativa enfocada antes de implementar en una amplia escala. El equipo responsable de SOA inicialmente debe estar estructurado como un Centro de Excelencia (CoE). Un éxito CoE tendrá varios atributos clave: 

Una clara definición de la misión del Consejo de Europa: por qué existe, de su ámbito de responsabilidad, y lo que la organización y la práctica de la arquitectura debe esperar del Consejo de Europa.



Metas claras para el Consejo de Europa, incluyendo mediciones e indicadores clave de rendimiento (KPI). Es importante asegurarse de que las medidas y KPI del Consejo de Europa no conducen la selección inadecuada de SOA como el estilo de la arquitectura.



El CoE ofrecerá la "prueba de fuego" de un buen servicio.



El CoE difundirá los conocimientos, experiencia y capacidades del Centro de SOA para el resto de la práctica de la arquitectura.

Página 226 de 670


Identificar cómo los del Consejo de Europa, y otros profesionales de la arquitectura, serán recompensados por el éxito.



El reconocimiento de que, al comienzo, es poco probable que la organización va a tener las habilidades necesarias para crear un Centro de Excelencia en pleno funcionamiento. Las habilidades y la experiencia necesarias deben ser cuidadosamente identificados, y donde no están presentes, adquirieron. Una habilidad fundamental para destacados profesionales dentro del Consejo de Europa es la capacidad de guiar a otros profesionales de la transferencia de conocimientos, habilidades y experiencia.



Primer plan de cuenta cuando el Consejo de Europa ha cumplido su propósito.

22.7.1.4 Arquitectura Repositorio

. Hay una serie de recursos SOA que se debe considerar cuando inicialmente poblar el repositorio de Arquitectura como se describe en la arquitectura de referencia SOA Open Group (véase La SOA Source Book Open Group) Estos incluyen: 

Los ladrillos de la SOA , que describe un conjunto de ABBS que representan los elementos clave de SOA



Una perspectiva de alto nivel de la arquitectura de referencia de SOA , lo que da una visión general de las nueve capas de la arquitectura de referencia, con ejemplos y razones que describen las principales responsabilidades de las capas y sus bloques de construcción primarios



Detalladas bloques de construcción de la arquitectura de referencia de SOA , que presenta modelos detallados que muestran cómo algunas de las características de SOA se puede implementar utilizando la arquitectura de referencia



Infraestructura para SOA , que describe Arquitectura Bloques de Construcción (Abs) que corresponden a los productos de infraestructura que están disponibles hoy para apoyar las aplicaciones orientadas a servicios



Industria Normas de SOA , como el marco de integración de TeleManagement Forum

Un gráfico de alto nivel que se describe la arquitectura de referencia SOA Open Group sigue:

Página 227 de 670


Figura 22‐2: La arquitectura de referencia SOA Open Group 22.7.2 Fase A: Architecture Vision La descripción de alto nivel se produce en la fase A reflejará la naturaleza orientada al servicio de la arquitectura que se preveía. Una diferencia obvia entre una descripción de la arquitectura SOA y una descripción de una arquitectura de otro estilo es el idioma. La descripción SOA utiliza un lenguaje diferente, con palabras tales como "política", "composicion", y "tarea", y cuenta con diferentes modelos, tales como matrices que muestran el uso de los servicios por parte de los procesos de negocio y el uso de aplicaciones de servicios. The Open Group SOA ontología proporciona una taxonomía y ontología para SOA. En un proyecto de SOA es importante para garantizar que las partes interesadas comprendan las implicaciones de SOA y se preparan para el impacto de la organización de los servicios de SOA componibles. Este impacto es aplicable si los servicios de SOA están disponibles como aplicaciones heredadas envueltos, utilizando los servicios expuestos a los productos comprados, servicios a medida, Cloud Computing Software as a Service (SaaS), etc 22.7.2.1 Las partes interesadas, inquietudes y requerimientos de negocio

Los interesados que consulten los requisitos para hacer frente, y los modelos, artefactos y puntos de vista para el desarrollo varían de un compromiso de la arquitectura a otra. Existen algunas preocupaciones que son específicos de SOA, o que son más propensos a surgir en la evolución de SOA. Las preocupaciones de los interesados direccionamiento en SOA sección de la SOA Source Book Open Group es un buen recurso para hacer frente a este tema.

Página 228 de 670

The Open Group Architecture Framework TOGOF 9.1   22.7.3 Arquitectura de Desarrollo: Fases B, C, y D En esta sección se considera el impacto de SOA en las fases B, C y D, los dominios de desarrollo de arquitectura. La siguiente gráfica de los TOGAF identifica el contenido Metamodel (señalados en rojo) las entidades que son clave para SOA.

Figura 22‐3: Entidades de SOA en el Metamodel contenido

   Personas clave incluyen: 

Evento



Proceso



Servicios de Negocio



Es el servicio



Plataforma de servicios

Página 229 de 670


Lógico Aplicación y Tecnología de componentes



Aplicación y Tecnología Componente Físico



Entidad de datos



Papel



Calidad de Servicio



Contrato



Ubicación



Información de o (no en el metamodelo)



Lógico Componentes de la información (no en metamodelo)



Reglas de Negocio (no en el metamodelo)

Extensiones del metamodelo son típicamente necesarios para apoyar plenamente SOA. Lo que sigue para cada dominio es una descripción de los artefactos que son apropiados para el desarrollo de la empresa del arquitecto de una SOA. Fase B: Arquitectura de Negocios

El punto de partida de los artefactos que se desarrollan en esta fase es el conjunto de requisitos empresariales clave identificadas en la Fase A. Para el tipo de SOA empresarial que estamos discutiendo aquí, los siguientes artefactos deben ser considerados para SOA, ya que contribuyen a la definición de bloques de construcción de SOA en la fase C y la fase D. Artefacto Business Service Interaction Diagrama

Propósito

Entidades Metamodel

Este diagrama muestra todos los Servicios comerciales, contratos, servicios a las empresas en el alcance información de negocios y sus relaciones y de la información que fluye entre los servicios de (Business Information es mencionado en la oficina. Se indicará cuáles son los Fase B, pero no hay una entidad servicios de negocio son comúnmente metamodelo.) reutilizados por otros servicios de negocios que indica las oportunidades para su posible reutilización de apoyo a los servicios de SI.

El diagrama también se utiliza para definir los procesos de negocio y las relaciones entre los procesos de negocio, ya que cada proceso está compuesto por un subconjunto de este modelo. Diagrama de Procesos Se trata de un conjunto de diagramas de Negocio que muestran los procesos de negocio y su descomposición, sus interacciones, así como la información con la que se refiere.

Subconjunto de Servicio Modelo de Negocio que muestra los servicios de negocios y contratos involucrados en los procesos y la información de la empresa pasó entre las Empresas de Servicios.

Página 230 de 670

The Open Group Architecture Framework TOGOF 9.1   Catálogo de vocabulario Esta es una lista de los principales Esta es una lista de elementos de de negocios términos utilizados en la descripción de información de negocios y las los procesos de negocio y la descripciones de los elementos. información. Es importante que la fase de la arquitectura de negocios (Business Information es mencionado en la establece el contexto de información Fase B, pero no hay una entidad para los servicios de software, según metamodelo.) se describe en la Arquitectura de la Información para SOA sección del libro Fuente Open Group, y un catálogo de términos de negocios es una parte importante de este contexto. El vocabulario de negocios puede derivarse mientras que el desarrollo del modelo de servicio de negocio. Servicios comerciales Esta es una lista de los servicios de Listado de Empresas de Servicios y sus catálogo negocio de la empresa y sus requisitos calidades de servicio no funcionales. Se utiliza para analizar los requisitos no funcionales. Business Service / Para entender de dónde los servicios Business Service, Ubicación Location Catálogo empresariales deben ser ejecutados. Catálogo Evento / Para entender qué proceso se ejecuta Listas de eventos y sus negocios efectuada Proceso en relación con un evento. Proceso Catálogo Calidad Para entender las propiedades no Listas de contratos y sus calidades de contrato / servicio funcionales de un contrato. servicio pertinentes Business Service Para mostrar las relaciones entre los Servicios comerciales en ambos ejes y Interaction Matrix servicios empresariales. Contratos en el punto de cruce Business Service / Para mostrar cómo los elementos de Servicios comerciales y elementos de Matrix Información información son utilizados por Servicios Información Empresarial (CRUD) comerciales y de encontrar fallas en ese modelo. (Business Information es mencionado en la

Información de los componentes del modelo

Fase B, pero no hay una entidad actual metamodelo TOGAF.) Para definir la estructura lógica de la Elementos de información de negocios, información en la organización. Puede Componentes de la información lógica y ser utilizado como insumo para el sus relaciones modelo de intercambio de definir las entradas y salidas de los servicios (Ninguno de ellos existe en el metamodelo SOA. actual.)

Los puntos de vista apropiados se deben producir para poder demostrar a las partes interesadas sobre cómo se tratan sus preocupaciones en SOA específicos relacionados con la Arquitectura Empresarial. Al hacer esto, el arquitecto se ocupa de las necesidades que pueden ser satisfechas por la Arquitectura Empresarial. Los requisitos de arquitectura restantes se abordarán en la fase C y la fase D. Fase C: Arquitecturas de Sistemas de Información

La fase se divide en dos sub-fases, Arquitectura de datos y aplicaciones de arquitectura. SOA hace poca diferencia a la sub-fase de Arquitectura de datos, pero tiene un impacto importante en la arquitectura de aplicaciones. Además de afectar los artefactos que se desarrollan, las vistas que se producen, las preocupaciones que se discuten, y los requisitos que se identifican, SOA afecta la manera en que el arquitecto hace el análisis de la brecha entre la línea de base y las arquitecturas objetivo en la Fase C.

Página 231 de 670

The Open Group Architecture Framework TOGOF 9.1   Con SOA, las aplicaciones de software tradicionales se sustituyen por conjuntos de servicios débilmente acoplados. Las aplicaciones existentes todavía deben describirse, como deberían las nuevas aplicaciones de las especies tradicionales que se requieren, y estas aplicaciones deben ser incluidos en la cartera de aplicaciones. Además, se deben identificar las áreas de funcionalidad de las aplicaciones que están cubiertos por los servicios. Estos serán (probablemente como parte de la implementación) pueden descomponer en los servicios, que se incluirán en la cartera de servicios. Pero SOA no es sólo acerca de los servicios, es también las soluciones creadas mediante el uso de combinaciones de servicios. Estas soluciones se suelen estructurarse utilizando los procesos de negocio y servicios de negocio definidos en la Fase B. Fase C artefactos SOA específico Artefacto Es el servicio de Interacción Diagrama

Propósito Uso Metamodel Entidad Esto muestra los requisitos para los servicios Son los servicios y los contratos entre potenciales de SOA (IS Services) y las ellos interacciones entre ellos, y su uso de la información. Se utiliza para mostrar el conjunto Los contratos indican lo Business completo de los requisitos para la solución y Information es las relaciones entre los requisitos. comunicado.Preferiblemente, la entidad

de Calidad de Servicio para los dos es el de servicios y los contratos se deriva de las actividades empresariales y sus contratos y las calidades de servicio relacionados. Business Process / IS Esta matriz muestra la relación entre cada uno Procesos de Negocio y su relación con el Matrix Servicio de Procesos de Negocio y de los servicios es servicio IS (s) apoyar el proceso. Se utiliza para mostrar el conjunto completo de los requisitos para los servicios de SOA para un negocio determinado proceso. ES Catalog Service El catálogo muestra todos es el de servicios, Lista de servicios de SI y sus calidades de Contract sus contratos, y las calidades de servicio servicio relacionados relacionados para permitir el análisis de los requisitos no funcionales (por ejemplo, la Además, son los contratos de servicio seguridad, el rendimiento, la carga, la para cada uno es el servicio están disponibilidad, políticas, etc) para los posibles incluidos. servicios SOA. Este catálogo es un insumo importante para el proceso de la Cartera de Servicios de Gestión en la gobernabilidad de SOA. Es el servicio / Este catálogo se conecta es el de servicios Es el servicio (s), Contratos relacionados, aplicación de catálogo (potenciales servicios SOA), Contratos, y y calidades de servicio relacionados con (existente) calidades de servicio con las aplicaciones tal y como son componentes de aplicación existentes (tal cual Física componentes de la física aplicación). Se utiliza para especificar los escenarios envolventes en las aplicaciones existentes y analizar los requisitos no funcionales. ES Servicio / Data Esta matriz muestra qué datos está a cargo de ES Services y sus entidades de datos Matrix Entidad los posibles servicios SOA (es el de relacionados servicios). Se utiliza para identificar potenciales de tratamiento de datos Servicios de SOA. Lógico SOA Matriz de Esta matriz muestra la relación entre la SOA Es el de servicios, Logical componentes

Página 232 de 670

The Open Group Architecture Framework TOGOF 9.1   componentes

Lógico SOA Solution Diagrama

Matriz de distribución de Servicio

componentes lógicos (Logical componentes de de aplicación, y los principios y Drivers aplicación) y los potenciales servicios SOA (es negocios (utilizadas para encontrar el de servicios). Se utiliza para estructurar los criterios que realiza una agrupación) componentes lógicos de los requisitos. Un SOA componentes lógicos (componente de aplicación de lógica), sería un candidato para un servicio en arquitecturas SOA a nivel de capacidad. Este diagrama muestra las relaciones entre los Componentes y Contratos aplicación componentes lógicos de SOA (componentes lógica y sus calidades de servicio de la aplicación lógica) y otras soluciones lógicas (Logical componentes de la Componentes tecnológicos lógicas y su aplicación). Se utiliza para mostrar y analizar asignación a los contratos se utilizan para los requisitos funcionales y no funcionales de los mecanismos de interfaz. las interfaces entre las soluciones. Esta matriz muestra los servicios distribuidos Es el servicio, Logical componente de en ubicaciones físicas para satisfacer el aplicación, Física componente de requisito legal o de otro tipo. El objetivo es aplicación, y ubicación mostrar y analizar si existen requisitos de ubicación en servicios. Esto se puede hacer en cualquiera de estos casos los servicios o componentes de aplicación lógicos.

El uso de los artefactos, el arquitecto debe desarrollar puntos de vista que muestran a los interesados cómo se tratan sus preocupaciones en SOA específicos relacionados con la Arquitectura de Aplicaciones. Los modelos que permitan la discusión de las preocupaciones relacionadas con la Arquitectura de datos también deben desarrollarse como parte de la Fase C. Estos son similares a los modelos que se desarrollarían de una arquitectura tradicional basada en las aplicaciones de software. Al hacer esto, esto responde a las necesidades que pueden ser satisfechas por los sistemas de información Arquitecturas. Los requisitos de arquitectura restantes se abordarán en la Fase D: Architecture Tecnología. En cada una de las fases B, C, y D un análisis de brechas se debe realizar entre la línea de base y Target Arquitecturas para determinar lo que hay que hacer para pasar de la línea de base a la meta. Para las fases B y D, y la sub-fase Arquitectura de datos de la Fase C, esto no se ve muy afectado por la SOA. Para las aplicaciones Arquitectura subfase de la Fase C, sin embargo, SOA hace una diferencia en la forma en que se realiza el análisis de las lagunas. Los ABBS definidos en la Fase C se incluyen aplicaciones y grupos de servicios que cubren las áreas de funcionalidad de las aplicaciones tradicionales. Ambos tipos de bloque de construcción deben ser incluidos en el análisis de las lagunas. Sin embargo, puede ser la intención de que un grupo de servicios puede implementar como una "envoltura" sobre las aplicaciones existentes. Esta situación, que es especial para SOA, debe indicarse en el análisis de las deficiencias, así como las situaciones en que han de ser removido o sustituido, o nuevas aplicaciones se vayan a añadir aplicaciones antiguas. Fase D: Architecture Tecnología

Para SOA, la arquitectura de la tecnología define el software y la infraestructura de hardware necesaria para apoyar la cartera de servicios. Un punto de partida para la Tecnología de la

Página 233 de 670

The Open Group Architecture Framework TOGOF 9.1   Arquitectura es la arquitectura de referencia SOA Open Group, que contiene la mayoría de los servicios posibles plataformas para una infraestructura SOA.Cada organización tendrá que personalizar la arquitectura de referencia de SOA a sus necesidades. Artefactos Fase D-SOA específico Artefacto Propósito Uso Metamodel Entidad Tecnología Lógica Este esquema se utiliza para mostrar y Servicio de Plataforma (Capability), Diagrama de la analizar el caso de la arquitectura de Logical Componente Tecnología (ABB) arquitectura referencia SOA Open Group. Contendrá todos ABBS y capacidades que se consideren necesarias para la solución SOA. Lógico Aplicación y Esta matriz se utiliza para mostrar y analizar Componentes aplicación lógica y sus Tecnología Matrix las relaciones entre los componentes de relaciones con los componentes lógicos aplicación lógicos y los componentes de tecnología, incluyendo derivaciones tecnológicos lógicas para asegurar el de las calidades de servicio arquitecto entienda lo que la tecnología se utilizará para los componentes de aplicación lógicos. También se utiliza para obtener y validar los requisitos no funcionales para los componentes tecnológicos.

The Open Group ha producido información adicional relativa a la adaptación de la infraestructura de una organización para la orientación a servicios, incluida la infraestructura orientada a servicios Open Group (SOI) Modelo de referencia (consulte El SOA Source Book Open Group para guía). El uso de los artefactos y SOI modelo de referencia, el arquitecto debe desarrollar puntos de vista que muestran a los interesados cómo se tratan sus preocupaciones en SOA específicos relacionados con la Tecnología de la Arquitectura. Al hacer esto, el arquitecto añade requisitos adicionales a los identificados en las Fases A, B y C, y se ocupa de las necesidades que pueden ser satisfechas por la Arquitectura de Tecnología. Todos los requisitos de arquitectura deberían haber sido abordados por el final de esta fase. Si todavía hay requisitos de arquitectura pendientes, entonces es necesario volver a la Fase B o Fase C para hacerles frente. Requisitos para la aplicación serán abordados por los proyectos que se han identificado en la Fase E. Fase E: Oportunidades y Soluciones

La identificación de soluciones SOA es una tarea clave para SOA. Las preguntas de qué soluciones SOA de la empresa tendrá, y cómo van a ser gestionados, deben ser considerados en esta fase. Opciones de entrega de soluciones se consideran normalmente como parte de esta fase. Una opción de la entrega que se debe considerar en particular para SOA es el uso de los servicios prestados por empresas externas, en comparación con el desarrollo de los servicios en la empresa o la adquisición de productos de software que realizan los servicios. Fase artefactos SOA específico E Artefacto Física SOA Solution Matrix

Propósito Uso Metamodel Entidad Esta matriz muestra la relación entre las SE Services, componentes de aplicación soluciones físicas SOA (Física lógica, física componentes de la aplicación

Página 234 de 670

The Open Group Architecture Framework TOGOF 9.1   componentes de la aplicación) y la lógica y los principios y Negocio Drivers (usado SOA Componentes. Se utiliza para definir para encontrar criterios que hacer la estructura física de la solución de SOA. estructuración) Física Solución Este diagrama muestra las relaciones Componentes y Contratos aplicación física Diagrama de SOA entre la solución SOA física (Physical y sus calidades de servicio componentes de aplicación) y otras soluciones (componentes de la aplicación Tecnología Física Componentes y su física). Se utiliza para mostrar y analizar correlación con los contratos se utilizan los requisitos funcionales y no para los mecanismos de interfaz. funcionales de las interfaces entre las soluciones. Servicio de Física Esta matriz muestra que se vuelven a ES Servicios, Física componentes de Matrix Solution utilizar los servicios existentes, que aplicación (tal y como son los servicios de servicios pueden ser proporcionados por SOA para su reutilización), otra aplicación los servicios externos (SaaS), y que los física Componentes (nuevos y existentes servicios deben desarrollarse como aplicaciones que pueden envolver), y envolturas de nuevas aplicaciones / nuevos componentes de aplicación física existentes y cuales necesitan ser (nuevos servicios a ser desarrollados o desarrolladas. adquiridos externamente) Se trata de una contribución al proceso de Gestión de la cartera de servicios de Gobierno SOA. Pautas de Este documento proporciona directrices aplicación sobre cómo desarrollar soluciones y servicios SOA. Sugerencias de posibles directrices se pueden encontrar en el Apéndice A del marco de gobernanza Open Grupo SOA. Tecnología Física Este diagrama se utiliza para mostrar y Plataforma de Servicios, Tecnología Diagrama de la analizar la solución técnica física para la Componente lógico, Tecnología arquitectura infraestructura SOA. Componente Físico Aplicación y Esta matriz se utiliza para mostrar y Componentes de aplicaciones físicas y sus Tecnología Física analizar la infraestructura física se utiliza relaciones con Componentes tecnología Matrix para ejecutar la aplicación física y para física, incluyendo derivaciones de las garantizar que los requisitos no calidades de servicio funcionales son derivados adecuadamente y entendidas. Catálogo Cartera Esta es una lista de productos y tipos de Física componentes de aplicación y su Tecnológica productos que se utilizarán en la relación con calidades de servicio ejecución, incluida la infraestructura de SOA en tiempo de ejecución, entorno de desarrollo de SOA, la tecnología de componentes de servicio, y la interfaz de servicio (portal, el canal, etc) la tecnología. También incluirá los requisitos no funcionales. Directrices Este documento proporciona directrices Tecnología sobre el uso de la infraestructura SOA.Sugerencias de posibles directrices se pueden encontrar en el Apéndice A del marco de gobernanza Open Grupo SOA.

Los proyectos de implementación que se identifican, y la estrategia de implementación y migración, dependerán de las decisiones tomadas en el nivel de detalle de la especificación de implementación, cuando el equipo de arquitectos de ámbito del desarrollo de la arquitectura en la Fase A.

Página 235 de 670

The Open Group Architecture Framework TOGOF 9.1   Fase C: planeamiento de migración

El modelo de gobierno de aplicación se revisa en la Fase F con el fin de asegurarse de que esté en su lugar antes de la siguiente fase - Gobierno Implementación - comienza. SOA requiere de reglas y procedimientos de gobierno en particular. La estrategia de gobierno y el apoyo se revisa en la Etapa Preliminar. Si necesita ser actualizado para SOA, entonces esto debe hacerse antes de que comience la ejecución. Esto debería utilizar los mismos recursos identificados en 22.7.1.2 Gobernabilidad y Estrategia de apoyo . Fase G: Gobernanza Aplicación

Las actividades que se realizan en la fase de implementación de Gobierno dependerá en parte de las decisiones tomadas en el nivel de detalle de la especificación de implementación, cuando el equipo de arquitectos de ámbito del desarrollo de la arquitectura en la Fase A. Durante la fase de implementación de Gobierno, la parte control de la SGVM debe ser poner en funcionamiento para asegurar que las actividades de gobierno de SOA se realizan en el nivel correcto. Fase H: Gestión Arquitectura Cambio

Es en este punto que el arquitecto debe determinar si es necesario revisar la Etapa Preliminar para ajustar la capacidad de la Arquitectura. Dónde SOA previamente no se ha utilizado dentro de una empresa, la Fase H de un desarrollo de la arquitectura es una oportunidad para evaluar la contribución que podría hacer SOA, y para considerar la adopción del principio de la orientación a servicios.

22.8 Resumen Hay una serie de métodos de SOA, herramientas y materiales de referencia disponibles para ayudar al Enterprise Architect desarrollar SOA. Se sugieren las normas y publicaciones Open Group. Algunos se centran directamente en SOA - como el Source Book SOA, OSIMM o la SGVM otros no están directamente enfocados pero regularmente útiles, tales como salidas de El Foro de Seguridad de Open Group. . Usando TOGAF para crear SOA requiere la adaptación de TOGAF para atender las exigencias de un estilo particular Abordar un estilo requerirá: 

La identificación de las entradas clave metamodelo



La identificación de extensiones al metamodelo contenido



La identificación de los artefactos clave



La identificación de los materiales de referencia de estilo específico y modelos de madurez

La adaptación de una capacidad de Arquitectura para apoyar SOA requiere una considerable actividad en la fase preliminar de TOGAF. Estas actividades y herramientas SOA específicas del Grupo de Trabajo SOA Open Group incluyen: 

Adaptar el principio de la orientación a servicios



La determinación de la organización la preparación para SOA: OSIMM

Página 236 de 670


Gobernanza: The Open Group SGVM



Particiones: Utilizar un Centro especializado de excelencia para apoyar SOA

En el resto de las fases TOGAF , lo que cambia es la forma de una arquitectura es descrito, analizado y documentado. Durante una iteración de la 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 variar. En el trabajo a nivel estratégico el objetivo es identificar si se necesita SOA, y en el que los segmentos. En el trabajo a nivel de segmento el propósito es describir la estructura y las capacidades de SOA. Por último, en el trabajo a nivel de capacidades para identificar y describir los requisitos de los servicios SOA que estarán disponibles. Cuando la entrega de SOA con TOGAF, el médico nunca debe perder de vista el objetivo final: soluciones SOA que se ocupan de la gestión de la complejidad de la empresa y proporcionar la agilidad del negocio.

Página 237 de 670


23. Principios de Arquitectura En este capítulo se describen los principios para el uso en el desarrollo de una empresa de arquitectura.

23.1 Introducción Los principios son normas generales y directrices, destinadas a ser duradera y rara vez modificada, que informan y apoyan la forma en que una organización se marca sobre el cumplimiento de su misión. A su vez, los principios pueden ser sólo un elemento de un conjunto estructurado de ideas que en conjunto definen y guías de la organización, a partir de los valores a través de acciones y resultados. Dependiendo de la organización, los principios pueden ser establecidos dentro de los diferentes ámbitos y en diferentes niveles. Dos dominios clave informan al desarrollo y la utilización de la arquitectura: 

Enterprise principios proporcionan una base para la toma de decisiones en toda la empresa, e informar de cómo la organización se marca sobre el cumplimiento de su misión. Tales principios se encuentran comúnmente como medio de armonizar la toma de decisiones en toda la organización. En particular, son un elemento clave para una estrategia exitosa de gobernabilidad arquitectura (ver 50. Arquitectura de Gobierno ). Dentro del amplio dominio de los principios empresariales, es común tener principios subsidiarios dentro de una empresa o unidad organizativa. Los ejemplos incluyen informática, recursos humanos, operaciones nacionales, o de las operaciones en el extranjero. Estos principios proporcionan una base para la toma de decisiones dentro del dominio subsidiario e informarán desarrollo de la arquitectura dentro del dominio. Se debe tener cuidado para asegurar que los principios utilizados para informar el desarrollo de arquitectura se alinean con el contexto organizativo de la Capacidad de Arquitectura.



Arquitectura principios son un conjunto de principios que se relacionan con el trabajo de la arquitectura. Son el reflejo de un nivel de consenso en toda la empresa, y encarnan el espíritu y el pensamiento de los principios empresariales existentes. Arquitectura principios rigen el proceso de arquitectura, que afecta el desarrollo, mantenimiento y uso de la arquitectura de la empresa.

Es común tener conjuntos de principios forman una jerarquía, en ese segmento principios serán informados por, y elaboran sobre los principios a nivel de empresa.Principios Arquitectura serán informados y limitados por principios empresariales. Principios Arquitectura pueden repetir otra orientación de la empresa en términos y forma que orientar eficazmente el desarrollo de la arquitectura. El resto de esta sección se refiere exclusivamente a los principios de la arquitectura.

Página 238 de 670


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

23,3 Componentes de Principios de Arquitectura Es útil tener una forma estándar de principios que definen. Además de una instrucción de definición, cada principio debe tener asociado declaraciones justificación e implicaciones, tanto para promover el entendimiento y la aceptación de los principios mismos, y para apoyar el uso de los principios en la explicación y justificación de por qué se toman las decisiones específicas. Una plantilla recomendada se da en la Tabla 23-1 . En caso ambos representan la esencia de la norma, así como ser fácil de recordar. Plataformas tecnológicas específicas no deben ser mencionadas en el nombre o la declaración de un principio. Evite las palabras ambiguas en el nombre y en el Estado, tales como: el "apoyo", "Abrir", "considerar", y por falta de una buena medida de la palabra "evitar", por sí mismo, tenga cuidado con " istrar ( ción) ", y buscar adjetivos y adverbios (pelusa) innecesarios. Declaración Sucinta y sin ambigüedades deben comunicar la regla fundamental. En su mayor parte, las declaraciones de principios para la gestión de la información son similares de una organización a otra. Es de vital importancia que la declaración de principios sea inequívoca. Razón Hará hincapié en los beneficios de negocio de adherirse al principio, utilizando fundamental la terminología de negocios. Apunte a la similitud de los principios de información y tecnología a los principios que rigen las operaciones de negocio. Describa también la relación con otros principios y las intenciones con respecto a una interpretación equilibrada. Describir situaciones en las que un principio se daría prioridad o tener más peso que otro para tomar una decisión. ImplicacionesHará hincapié en los requisitos, tanto para el negocio y de TI, para llevar a cabo el principio - en términos de recursos, costos y actividades / tareas. A menudo será evidente que los actuales sistemas, normas o prácticas serían incongruentes con el principio sobre la adopción. El impacto para el negocio y las consecuencias de la adopción de un principio debe quedar claro. El lector debe discernir fácilmente la respuesta a: "¿Cómo afecta esto a mí?" Es importante no simplificar demasiado, trivializar o juzgar el mérito del impacto.Algunas de las consecuencias serán identificados como sólo los impactos potenciales, y puede ser especulativa en lugar de totalmente analizado. Nombre

Tabla 23‐1: Formato recomendado para los principios que definen Un ejemplo conjunto de arquitectura siguientes principios de esta plantilla se da en el 23,6 Ejemplo Conjunto de Principios de Arquitectura .

Página 239 de 670


23.4 Desarrollo Principios Arquitectura Arquitectura principios se desarrollan típicamente por los arquitectos de la empresa, en conjunto con las principales partes interesadas, y son aprobados por el Consejo de Arquitectura. Principios Arquitectura serán informados por principios en el ámbito de la empresa, si es que existen. Principios Arquitectura deben estar claramente detectable y claramente articulado para orientar la toma de decisiones. Son elegidos con el fin de asegurar la alineación de la arquitectura y la implementación de la arquitectura destino con las estrategias de negocios y visiones. En concreto, el desarrollo de los principios de la arquitectura es típicamente influenciado por el siguiente: 

Misión de la empresa y los planes : la misión, planes e infraestructura organizativa de la empresa.



Enterprise iniciativas estratégicas : las características de la empresa - sus fortalezas, debilidades, oportunidades y amenazas - y sus iniciativas en toda la empresa actuales (tales como la mejora de procesos y gestión de la calidad).



La restricción externa : factores de mercado (time-to-market imperativos, las expectativas de los clientes, etc); legislación actual y potencial.



Sistemas y tecnologías actuales : el conjunto de recursos de información desplegados dentro de la empresa, incluyendo la documentación de sistemas, inventarios de equipos, diagramas de configuración de red, políticas y procedimientos.



Nuevas tendencias de la industria : las predicciones sobre los factores económicos, políticos, técnicos y de mercado que influyen en el entorno empresarial.

23.4.1 Cualidades de Principios Simple hecho de tener una declaración escrita que se llama un principio no significa que el principio es bueno, incluso si todo el mundo está de acuerdo con él. Un buen conjunto de principios se fundó en las creencias y valores de la organización y se expresa en un lenguaje que la empresa entiende y utiliza. Principios deben ser pocos en número, orientada hacia el futuro, y respaldado y defendido por la alta dirección. Ellos proporcionan una base sólida para la toma de decisiones de arquitectura y planificación, formulación de políticas, procedimientos y normas, y el apoyo a la resolución de situaciones contradictorias. Un pobre conjunto de principios se convertirá rápidamente en desuso, y las arquitecturas resultantes, políticas y normas aparecerá arbitrario o egoísta, y por lo tanto carecen de credibilidad. Esencialmente, principios impulsan el comportamiento. Hay cinco criterios que distinguen a un buen conjunto de principios: 

Comprensible : los principios subyacentes pueden ser captadas y entendidas por las personas en toda la organización de forma rápida. La intención del principio es clara e inequívoca, de modo que violaciónes, ya sea intencional o no, se reducen al mínimo.

Página 240 de 670


Robusto : permitir decisiones de buena calidad sobre arquitecturas y planes que se hacer, y las políticas y normas de obligado cumplimiento que se creen. Cada principio debe ser lo suficientemente definitivo y preciso para apoyar la toma de decisiones coherentes en situaciones complejas y potencialmente controversiales.



Completa :. todo principio potencialmente importante que rige la gestión de la información y la tecnología para la organización se define Los principios cubren cada situación percibida.



De acuerdo : la estricta adhesión a un principio puede requerir una interpretación libre de otro principio. El conjunto de principios debe ser expresado de una manera que permite un equilibrio de las interpretaciones. Los principios no deben estar en contradicción con el punto en el que se adhiere a un principio violaría el espíritu del otro. Cada palabra en un comunicado principio debe elegirse cuidadosamente para permitir una interpretación coherente, pero flexible.



Estable : principios deben ser duraderos, sin embargo, capaz de adaptarse a los cambios. Un proceso de enmienda debe ser establecido para agregar, eliminar o alterar los principios después de haber sido ratificadas inicialmente.

23.5 Aplicación de Principios de Arquitectura Arquitectura principios se utilizan para capturar las verdades fundamentales acerca de cómo la empresa va a utilizar y desplegar los recursos de TI y los activos. Los principios se utilizan en un número de diferentes maneras:

1. Para proporcionar un marco en el que la empresa puede empezar a tomar decisiones conscientes acerca de la arquitectura y proyectos que implementan la arquitectura de la empresa objetivo de la empresa

2. Como guía para el establecimiento de criterios de evaluación pertinentes, ejerciendo así una fuerte influencia en la selección de productos, soluciones y arquitecturas de soluciones en las últimas etapas de la gestión del cumplimiento de la arquitectura de la empresa

3. Como los controladores para la definición de los requisitos funcionales de la arquitectura 4. Como aporte a la evaluación de ambas implementaciones existentes y la cartera estratégica, para el cumplimiento de las arquitecturas definidas; estas evaluaciones proporcionarán información valiosa sobre las actividades de transición necesarios para implementar una arquitectura, en apoyo de los objetivos y prioridades de la empresa

5. Las declaraciones Justificación dentro de un Principio Arquitectura destacan el valor de negocio de las implementaciones consistentes con el principio y proporcionar orientación para las decisiones difíciles con los conductores o los objetivos en conflicto

6. Las declaraciones Implicaciones dentro de un Principio Arquitectura proporcionan un esquema de las principales tareas, recursos y costos potenciales para la empresa de seguir el principio; sino que también proporcionan una valiosa aportación a las futuras actividades de la iniciativa de transición y planificación

7. Apoyar las actividades de gobierno de la arquitectura en términos de: Página 241 de 670


Proporcionar un "back-stop" para las evaluaciones Arquitectura cumplimiento de estándares donde se permite o requiere alguna interpretación

o

El apoyo a la decisión de iniciar una solicitud de dispensa, donde las consecuencias de una modificación particular arquitectura no se pueden resolver dentro del procedimiento operativo local

Principios están interrelacionados y deben ser aplicadas como un conjunto. Principios a veces competir; por ejemplo, los principios de la "accesibilidad" y "seguridad" tienden a decisiones contradictorias. Cada principio debe considerarse en el contexto de "todas las cosas en igualdad". A veces se requiere una decisión sobre a qué principio tendrá prioridad sobre un tema en particular. La justificación de este tipo de decisiones siempre debe ser documentado. Una reacción común en la primera lectura de un principio es "esto es obvio y no necesita ser documentado". El hecho de que un principio parece obvio no significa que la orientación en un principio se siguió. Tener principios que aparecen evidentes ayuda a asegurar que las decisiones que en realidad siguen el resultado deseado. Aunque las sanciones específicas no se prescriben en una declaración de principios, violaciónes de los principios generalmente causan problemas operativos e inhiben la capacidad de la organización para cumplir su misión.

23.6 Ejemplo Conjunto de Principios de Arquitectura Demasiados principios pueden reducir la flexibilidad de la arquitectura. Muchas organizaciones prefieren definir sólo los principios de alto nivel, y para limitar el número a entre 10 y 20. El siguiente ejemplo ilustra tanto el contenido típico de un conjunto de principios de la arquitectura, y el formato recomendado para definirlos, como se explicó anteriormente.

23.6.1 Principios de Negocio Principio 1: Primacía de Principios

Declaración: Estos principios de gestión de la información se aplican a todas las organizaciones dentro de la empresa.

Página 242 de 670

The Open Group Architecture Framework TOGOF 9.1   Justificación: La única manera de que podamos proporcionar un nivel consistente y medible de información de calidad a los tomadores de decisiones es si todas las organizaciones se rigen por los principios. Implicaciones: 

Sin este principio, las exclusiones, el favoritismo y la inconsistencia socavaría rápidamente la gestión de la información.



iniciativas de gestión de la información no comenzarán hasta que se examinan para el cumplimiento de los principios.



Un conflicto con un principio se resuelve cambiando el marco de la iniciativa.

Principio 2: Maximizar beneficios a la Empresa

Declaración: Decisiones de gestión de la información se hacen para proporcionar el máximo beneficio a la empresa en su conjunto. Justificación: Este principio encarna "servicio por encima de uno mismo". Las decisiones tomadas desde una perspectiva de toda la empresa tienen un mayor valor a largo plazo de las decisiones tomadas desde cualquier punto de vista organizativo particular. Máximo rendimiento de la inversión requiere decisiones de gestión de la información a que se adhieran a los conductores y las prioridades de toda la empresa. Ningún grupo minoritario redundará en detrimento de la prestación de la totalidad. Sin embargo, este principio no impedirá cualquier grupo minoritario de conseguir hacer su trabajo. Implicaciones: 

Lograr el máximo beneficio de toda la empresa requerirá cambios en la forma en que planificamos y gestionar la información. sola tecnología no va a producir este cambio.



Algunas organizaciones pueden tener que reconocer sus propias preferencias para el mayor beneficio de toda la empresa.



las prioridades de desarrollo de aplicaciones deben ser establecidos por toda la empresa para toda la empresa.



Componentes Aplicaciones deben ser compartidos a través de las fronteras organizacionales.



las iniciativas de gestión de la información debe realizarse de acuerdo con el plan de empresa. Las distintas organizaciones deben perseguir iniciativas de gestión de la información que se ajustan a los planos y las prioridades establecidas por la empresa. Vamos a cambiar el plan, ya que necesitamos.

Página 243 de 670


A medida que surjan las necesidades, las prioridades deben ser ajustados. Un foro con representación global de la empresa debe tomar estas decisiones.

Principio 3: Gestión de la información es asunto de todos

Declaración: Todas las organizaciones de la empresa participan en las decisiones de gestión de información necesarios para lograr los objetivos de negocio. Justificación: s de la información son las principales partes interesadas, o clientes, en la aplicación de tecnología para hacer frente a una necesidad de negocio. Con el fin de garantizar la gestión de la información está alineada con el negocio, todas las organizaciones en la empresa deben participar en todos los aspectos del entorno de la información. Los expertos en negocios de toda la empresa y el personal técnico responsable del desarrollo y la preservación del entorno de información tienen que venir juntos como un equipo para definir conjuntamente los objetivos y metas de TI. Implicaciones: 

Para operar como un equipo, todos los grupos de interés, o cliente, tendrá que aceptar la responsabilidad de desarrollar el entorno de la información.



Compromiso de los recursos se requiere para poner en práctica este principio.

Principio 4: Continuidad del Negocio

Declaración: Las operaciones de la empresa se mantienen a pesar de las interrupciones del sistema. Justificación: Como las operaciones del sistema se torna más difundido, nos volvemos más dependientes de ellos; Por lo tanto, debemos tener en cuenta la fiabilidad de estos sistemas a través de su diseño y uso. Locales comerciales en toda la empresa debe proporcionar la capacidad de continuar con sus funciones de negocios, independientemente de los acontecimientos externos. Error de hardware, desastres naturales, y la corrupción de datos no se debe permitir que interrumpir o detener las actividades empresariales. Las funciones de negocio de la empresa debe ser capaz de operar sobre los mecanismos de entrega de información alternativos. Implicaciones: 

La dependencia de las aplicaciones compartidas mandatos del sistema que los riesgos de la interrupción del negocio se deben establecer de antemano y gestionados. El manejo incluye pero no se limita a las revisiones periódicas, control de la vulnerabilidad y la exposición, o el diseño de servicios de misión crítica para

Página 244 de 670

The Open Group Architecture Framework TOGOF 9.1   asegurar la continuidad del negocio a través de la función de las capacidades redundantes o alternativos. 

Recuperabilidad, redundancia y capacidad de mantenimiento deben ser abordadas en el momento del diseño.



Las solicitudes deben ser evaluados por la criticidad e impacto en la misión de la empresa, con el fin de determinar qué nivel de continuidad que se requiere y lo que el plan de recuperación correspondiente es necesario.

Principio 5: Common Use Aplicaciones

Declaración: Desarrollo de aplicaciones de uso en toda la empresa se prefiere sobre el desarrollo de aplicaciones similares o duplicados que se proporcionan únicamente a una organización en particular. Justificación: Capacidad de duplicación es costosa y prolifera datos contradictorios. Implicaciones: 

Las organizaciones que dependen de una capacidad que no sirve a toda la empresa debe cambiar a la capacidad de toda la empresa de reemplazo. Para ello será necesario el establecimiento de y la adhesión a una política que exige esto.



Organizaciones No se permitirá el desarrollo de capacidades para su propio uso, que son similares / duplicación de las capacidades de toda la empresa. De esta manera, se reducirán los gastos de los escasos recursos para desarrollar esencialmente la misma capacidad en marginalmente diferentes maneras.



Los datos y la información utilizada para apoyar a las empresas la toma de decisiones se normalizarán en mucha mayor medida que antes. Esto se debe a las capacidades de la organización, más pequeñas que producen diferentes datos (que no fue compartida por otras organizaciones) serán reemplazadas por las capacidades de toda la empresa. El impulso para la adición a la serie de capacidades en toda la empresa bien puede provenir de una organización que hace un caso convincente para el valor de los datos / información producida anteriormente por su capacidad de organización, pero la capacidad resultante pasará a formar parte del sistema en toda la empresa , y los datos que produce será compartida en toda la empresa.

Principio 6: Orientación al Servicio

Declaración: La arquitectura se basa en un diseño de los servicios que reflejan las actividades empresariales del mundo real que comprenden la empresa (o entre empresas) los procesos de negocio.

Página 245 de 670

The Open Group Architecture Framework TOGOF 9.1   Justificación: La orientación a servicios ofrece la agilidad empresarial y sin fronteras Flujo de Información. Implicaciones: 

Representación de servicio utiliza descripciones empresariales para proporcionar el contexto (es decir, los procesos de negocio, meta, regla, política, interfaz de servicio, y el componente de servicio) e implementa servicios utilizando la orquestación de servicios.



Orientación al servicio pone requisitos únicos de la infraestructura, y las implementaciones deben utilizar estándares abiertos para darse cuenta de la interoperabilidad y la transparencia de ubicación.



Las implementaciones son favorables al medio específico; se ven limitados o habilitadas por el contexto y deben ser descritas dentro de ese contexto.



Se requiere un gobierno fuerte de la representación de servicios y la ejecución.



Una "prueba de fuego", lo que determina un "buen servicio", se requiere.

Principio 7: El cumplimiento de la Ley

Declaración: Procesos de gestión de información de la empresa cumplen con todas las leyes, políticas y regulaciones. Justificación: La política de empresa es cumplir con las leyes, políticas y regulaciones. Esa disposición no impedirá la mejora de procesos de negocio que conducen a cambios en las políticas y regulaciones. Implicaciones: 

La empresa debe tener en cuenta para cumplir con las leyes, regulaciones y políticas exteriores relativas a la recogida, retención y gestión de datos.



La educación y el a las normas. Eficiencia, la necesidad y el sentido común no son los únicos pilotos. Los cambios en la ley y los cambios en las regulaciones pueden conducir los cambios en los procesos o aplicaciones.

Principio 8: IT Responsabilidad

Declaración: La organización de TI es responsable de la propiedad y la implementación de los procesos de TI y de infraestructura que permitan soluciones para satisfacer los requisitos definidos por el para la funcionalidad, los niveles de servicio, costo y tiempo de entrega.

Página 246 de 670

The Open Group Architecture Framework TOGOF 9.1   Justificación: Alinear eficazmente las expectativas con las capacidades y los costos de manera que todos los proyectos son rentables. Soluciones eficientes y eficaces tienen costos razonables y claros beneficios. Implicaciones: 

Un proceso debe ser creado para dar prioridad a los proyectos.



La función de TI debe definir los procesos para manejar las expectativas de las unidades de negocio.



Los datos, aplicaciones y modelos de tecnología deben ser creados para permitir soluciones integradas de calidad y para maximizar los resultados.

Principio 9: Protección de la Propiedad Intelectual

Declaración: Propiedad intelectual de la empresa (IP) debe ser protegido. Esta protección debe reflejarse en la arquitectura de TI, implementación y procesos de gobernanza. Justificación: Una parte importante de IP de una empresa se encuentra alojado en el dominio de TI. Implicaciones: 

Si bien la protección de los activos de propiedad intelectual es un asunto de todos, gran parte de la protección real se implementa en el dominio de TI.Incluso confiar en los procesos de TI no pueden ser manejados por los procesos de TI (correo electrónico, notas obligatorias, etc.)



Una política de seguridad, el gobierno y los actores humanos de TI, se requerirá que puede mejorar sustancialmente la protección de la propiedad intelectual. Esta debe ser capaz de tanto evitando compromisos y la reducción de pasivos.



Recursos sobre estas políticas se pueden encontrar en el Instituto SANS (consulte www.sans.org/security-resources/policies/ ).

23.6.2 Principios de datos Principio 10: Los datos son un activo

Declaración: Los datos son un activo que tiene valor para la empresa y se gestiona en consecuencia. Justificación: Los datos son un recurso valioso corporativa; que tiene un valor real y medible. En términos simples, el propósito de los datos es para facilitar la toma de decisiones. Precisa,

Página 247 de 670

The Open Group Architecture Framework TOGOF 9.1   los datos a tiempo es fundamental para las decisiones precisas y oportunas. La mayoría de los activos de la empresa se utilizan cuidadosamente, y los datos no es una excepción. Los datos son el fundamento de nuestra toma de decisiones, por lo que también debe gestionar cuidadosamente los datos para asegurarse de que sabemos donde está, puede confiar en su exactitud, y puede obtenerlo cuando y donde lo necesitamos. Implicaciones: 

Se trata de uno de los tres principios estrechamente relacionados con las relativas a los datos: los datos son un activo; los datos se comparten; y los datos de fácil . La implicación es que no es una tarea de educación para garantizar que todas las organizaciones dentro de la empresa a entender la relación entre el valor de los datos, intercambio de datos, y la accesibilidad a los datos.



es deben tener la autoridad y los medios para gestionar los datos de los que son responsables.



Hay que hacer la transición cultural de "propiedad de los datos" pensar que "la istración de datos" de pensar.



El papel del de datos es crítica porque los datos obsoletos, inexactos o incoherentes podrían ser pasados a personal de la empresa y afectan negativamente a las decisiones en toda la empresa.



Parte de la función de de datos, que gestiona los datos, es garantizar la calidad de los datos. Los procedimientos deben ser desarrollados y utilizados para prevenir y corregir errores en la información y mejorar los procesos que producen la información errónea. Tendrá que ser medido y las medidas adoptadas para mejorar la calidad de los datos de calidad de datos - es probable que tendrán las políticas y procedimientos que se han desarrollado para esto también.



Un foro con representación integral de toda la empresa debe decidir sobre cambios en los procesos sugeridos por el mayordomo.



Dado que los datos son un activo de valor para toda la empresa, los es de datos responsables de la gestión adecuada de los datos deben ser asignados a nivel de empresa.

Principio 11: Los datos se Compartido

Declaración: Los s tienen a los datos necesarios para llevar a cabo sus funciones; Por lo tanto, los datos se comparten a través de las funciones y de las organizaciones empresariales. Justificación: El oportuno a datos precisos es esencial para mejorar la calidad y eficiencia de la empresa la toma de decisiones. Es menos costoso de mantener datos precisos y oportunos en una sola aplicación, y luego compartirlo, de lo que es para mantener los

Página 248 de 670

The Open Group Architecture Framework TOGOF 9.1   datos duplicados en múltiples aplicaciones. La empresa tiene una gran cantidad de datos, sino que se almacena en bases de datos de cientos de tubos de la estufa incompatibles. La velocidad de recopilación de datos, la creación, la transferencia y la asimilación es impulsado por la capacidad de la organización para compartir de manera eficiente estas islas de datos en toda la organización. Los datos compartidos se traducirá en la mejora de las decisiones ya que vamos a contar con un menor número (en última instancia, uno virtual) de las fuentes de datos más precisos y gestionados oportuna para toda nuestra toma de decisiones. Datos compartidos electrónicamente tendrán como resultado una mayor eficiencia cuando se pueden utilizar las entidades de datos existentes, y sin volver a escribir, a crear nuevas entidades. Implicaciones: 




Para permitir el intercambio de datos que debemos desarrollar y cumplir con un conjunto común de políticas, procedimientos y normas que rigen la gestión de datos y el tanto a corto como a largo plazo.



Para el corto plazo, para preservar nuestra importante inversión en sistemas de legado, tenemos que invertir en software capaz de migrar los datos del sistema legado en un entorno de datos compartido.



También vamos a necesitar desarrollar modelos estándares de datos, elementos de datos, y otros metadatos que define a este entorno compartido y desarrollar un sistema de depósito para el almacenamiento de estos metadatos para que sea accesible.



Para el largo plazo, ya que los sistemas antiguos se sustituyen, debemos adoptar y hacer cumplir las políticas y directrices para los nuevos desarrolladores de aplicaciones comunes de a datos para asegurar que los datos en nuevas aplicaciones queda disponible para el medio ambiente que compartimos y que los datos en el entorno compartido puede seguir ser utilizados por las aplicaciones nuevas.



Tanto para el corto plazo y el largo plazo debemos adoptar métodos y herramientas comunes para crear, mantener y acceder a los datos compartidos en toda la empresa.



El intercambio de datos requerirá un cambio cultural significativo.



El principio de intercambio de datos continuamente "se topan con" el principio de seguridad de los datos. En ningún caso, el principio de intercambio de datos ocasionar que los datos confidenciales sean comprometidos.



Los datos puestos a disposición para el intercambio tendrán que confiar todos los s a ejecutar sus respectivas tareas. Esto asegurará que sólo los datos más

Página 249 de 670

The Open Group Architecture Framework TOGOF 9.1   precisa y oportuna que se invoque para la toma de decisiones. Los datos compartidos se convertirá en la "fuente única virtual" en toda la empresa de datos. Principio 12: Los datos son accesibles

Declaración: Los datos son accesibles a los s realizar sus funciones. Justificación: Amplio a los datos conduce a la eficiencia y la eficacia en la toma de decisiones, y ofrece respuesta oportuna a las solicitudes de información y prestación de servicios. Utilizando la información debe ser considerado desde el punto de vista de la empresa para permitir el de una amplia variedad de s. Se ahorra tiempo del personal y la consistencia de los datos se ha mejorado. Implicaciones: 




Accesibilidad consiste en la facilidad con la que los s obtengan información.



La forma en que se accede y visualiza la información debe ser suficientemente adaptable para satisfacer una amplia gama de s de la empresa y sus correspondientes métodos de .



El a los datos no constituye la comprensión de los datos. El personal debe tener cuidado de no malinterpretar la información.



El a los datos no otorga necesariamente los derechos de de para modificar o divulgar los datos. Para ello será necesario un proceso de educación y un cambio en la cultura organizacional, el cual actualmente es compatible con la creencia en la "propiedad" de los datos por unidades funcionales.

Principio 13: Depositario de datos

Declaración: Cada elemento de dato tiene un responsable de la calidad de datos. Justificación: Uno de los beneficios de un entorno Diseñada es la capacidad de compartir los datos (por ejemplo, texto, vídeo, sonido, etc) a través de la empresa. A medida que el grado de intercambio de datos crece y las unidades de negocio se basan en la información común, es esencial que sólo el de datos toma las decisiones sobre el contenido de

Página 250 de 670

The Open Group Architecture Framework TOGOF 9.1   los datos. Puesto que los datos se pueden perder su integridad cuando se introduce varias veces, el de datos será el único responsable de la introducción de datos que elimina el esfuerzo humano redundante y los recursos de almacenamiento de datos. Nota: Un fiduciario es diferente de un mayordomo - un fiduciario es responsable de la exactitud y actualidad de los datos, mientras que las responsabilidades de un pueden ser más amplias e incluyen la estandarización de datos y tareas de definición. Implicaciones: 

tutela real disuelve los problemas de la "propiedad" de datos y permite que los datos estén disponibles para satisfacer las necesidades de todos los s. Esto implica que un cambio cultural a partir de datos de la "propiedad" de los datos de "tutela" puede ser requerida.



El 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 en los datos en base a atributos tales como "fuente de datos".



Es esencial identificar la verdadera fuente de los datos con el fin de que la autoridad de datos se puede asignar esta responsabilidad fiduciaria. Esto no significa que las fuentes de anuncios serán revelados ni significa la fuente será el fiduciario.



La información debe ser capturada electrónicamente una vez e inmediatamente validada tan cerca de la fuente como sea posible. Medidas de control de calidad deben ser implementadas para garantizar la integridad de los datos.



Como resultado del intercambio de datos en toda la empresa, el fiduciario es responsable y responsable de la exactitud y actualidad de su elemento de datos designado (s) y, posteriormente, a continuación, debe reconocer la importancia de esta responsabilidad fiduciaria.

Principio 14: vocabulario común y definiciones de datos

Declaración: Los datos que se define consistentemente en toda la empresa, y las definiciones son comprensibles y estar disponibles para todos los s. Justificación: Los datos que se va a utilizar en el desarrollo de aplicaciones debe tener una definición común en toda la sede para permitir el intercambio de datos. Un vocabulario común facilitar las comunicaciones y de diálogo habilitado para ser eficaz. Además, se requiere para interfaz de los sistemas y los datos de cambio.

Página 251 de 670

The Open Group Architecture Framework TOGOF 9.1   Implicaciones: 

Estamos adormecidos en el pensamiento de que esta cuestión se aborde adecuadamente porque hay gente con "Gestión de datos" títulos de trabajo y foros con las cartas que implica responsabilidad. Energía y recursos adicionales significativos deben estar comprometidos con esta tarea. Es clave para el éxito de los esfuerzos para mejorar el entorno de la información. Esto es independiente de, pero relacionado con el tema de la definición del elemento de datos, que está dirigida por una amplia comunidad - esto es más como un vocabulario y una definición común.



La empresa debe establecer el vocabulario común inicial para el negocio. Las definiciones se utilizarán de manera uniforme en toda la empresa.



Siempre que se requiera una nueva definición de datos, el esfuerzo de definición será coordinada y reconciliada con el "glosario" corporativo de descripciones de datos. El de datos de la empresa proporcionará esta coordinación.



Las ambigüedades resultantes de múltiples definiciones parroquiales de datos deben dar paso a las definiciones aceptadas en toda la empresa y la comprensión.



Múltiples iniciativas de estandarización de los datos tienen que ser coordinados.



las responsabilidades de istración de datos funcionales deben ser asignados.

Principio 15: Seguridad de datos

Declaración: Los datos están protegidos por el uso y la divulgación no autorizada. Además de los aspectos tradicionales de clasificación de seguridad nacional, esto incluye, pero no se limita a, la protección de la pre-decisional, sensible, la fuente de selección sensible, información y propietaria. Justificación: Libre intercambio de información y la divulgación de información a través de la legislación pertinente debe equilibrarse con la necesidad de restringir la disponibilidad de la información clasificada, de propiedad y confidencial. Leyes y reglamentos existentes requieren la salvaguardia de la seguridad nacional y la privacidad de los datos, al tiempo que permite el libre y abierto.Información previa a la toma de decisiones (trabajo en progreso, aún no autorizados para la liberación) debe ser protegida para evitar la especulación injustificada, la mala interpretación y el uso inapropiado.

Página 252 de 670


La agregación de los datos, tanto clasificado, y no, va a crear un objetivo grande que requiere revisión y los procedimientos de clasificación DE para mantener un control adecuado. Los propietarios de datos y / o s funcionales deben determinar si los resultados de la agregación en un mayor nivel de clasificación. Vamos a necesitar de políticas y procedimientos adecuados para manejar esta revisión y clasificación DE. a la información sobre la base de una política de la necesidad de conocer obligará a revisiones periódicas de la cantidad de información.



La práctica actual de tener sistemas separados para contener diferentes clasificaciones necesita ser repensado. ¿Hay una solución de software para la separación de los datos clasificados y no clasificados? La solución de hardware actual es difícil de manejar, ineficaz y costosa. Es más caro para gestionar datos no clasificados en un sistema clasificado. Actualmente, la única manera de combinar los dos es para colocar los datos no clasificados en el sistema clasificado, donde debe permanecer.



Con el fin de proveer adecuadamente el para abrir la información, manteniendo la información segura, las necesidades de seguridad deben ser identificados y desarrollados a nivel de datos, no el nivel de aplicación.



medidas de seguridad de datos se pueden poner en marcha para restringir el a "sólo vista", o "no ver nunca". Etiquetado de sensibilidad para el a la clasificada, información previa a la toma de decisiones, toma de decisiones, sensible, ni de la propiedad debe ser determinado.



La seguridad debe ser diseñado en elementos de datos desde el principio; que no se puede añadir más tarde. Sistemas, datos y tecnologías deben ser protegidos contra el y la manipulación no autorizada. Información de la Sede debe salvaguardarse contra la alteración involuntaria o no autorizada, el sabotaje, el desastre o la divulgación.



Necesidad de nuevas políticas sobre la gestión de la duración de la protección de la información pre-decisional y otras obras en curso, teniendo en cuenta la actualización del contenido.

23.6.3 Principios de Aplicación Principio 16: Tecnología de la Independencia

Declaración: Las solicitudes son independientes de las opciones tecnológicas específicas y por lo tanto pueden operar en una variedad de plataformas tecnológicas.

Página 253 de 670

The Open Group Architecture Framework TOGOF 9.1   Justificación: Independencia de las aplicaciones de la tecnología subyacente permite que las aplicaciones a desarrollar, actualizar y operar de la manera más costo-efectiva y oportuna. De lo contrario, la tecnología, la cual está sujeta a continua obsolescencia y proveedor de la dependencia, se convierte en el controlador en lugar de los propios requisitos de los s. Al darse cuenta de que cada decisión tomada con respecto a IT nos hace depender de que la tecnología, la intención de este principio es garantizar que el software de aplicación no depende de hardware específico y software de sistemas operativos. Implicaciones: 

Este principio requiere normas que apoyan la portabilidad.



Para Commercial Off-The-Shelf (COTS) y Gobierno Off-The-Shelf (GOTS) aplicaciones, no se podrá limitar las opciones actuales, ya que muchas de estas aplicaciones son la tecnología y dependiente de la plataforma.



tendrán que ser desarrolladas para permitir que las aplicaciones de legado para interoperar con aplicaciones y entornos operativos desarrollados bajo la arquitectura de la empresa las interfaces del subsistema.



Middleware debería utilizarse para separar las aplicaciones de soluciones de software específicas.



A modo de ejemplo, este principio podría llevar al uso de Java, y los protocolos de Java como futuras, que le dan un alto grado de prioridad a la independencia de la plataforma.

Principio 17: Facilidad de Uso

Declaración: Las aplicaciones son fáciles de usar. La tecnología subyacente es transparente para los s, para que puedan concentrarse en las tareas a mano. Justificación: Cuanto más un tiene que entender la tecnología subyacente, menos productiva que el es. La facilidad de uso es un incentivo positivo para el uso de aplicaciones. Se anima a los s a trabajar dentro del entorno integrado de información en lugar de desarrollar sistemas aislados para realizar la tarea fuera del entorno de la información integrada de la empresa. La mayor parte de los conocimientos necesarios para operar un sistema será similar a los demás. Formación se mantiene a un mínimo, y el riesgo de usar un sistema de forma incorrecta es baja. Usando una aplicación debe ser lo más intuitivo como conducir un coche diferente.

Página 254 de 670


Se requiere aplicaciones para tener un "look-and-feel" común y apoyar a los requisitos ergonómicos. Por lo tanto, el estándar de look-and-feel común debe ser diseñado y criterios de prueba de usabilidad debe ser desarrollado.



Directrices para las interfaces de no deben ser limitados por supuestos estrechos acerca de la ubicación del , el idioma, la formación de sistemas, o capacidad física. Factores tales como la lingüística, los clientes achaques físicos (agudeza visual, capacidad de utilizar el teclado / ratón), y competencia en el uso de la tecnología tienen amplias ramificaciones en la determinación de la facilidad de uso de una aplicación.

23.6.4 Principios Tecnológicos Cambio de base-Requisitos: Principio 18

Declaración: Sólo en respuesta a las necesidades del negocio son cambios en las aplicaciones y la tecnología realizada. Justificación: Este principio será fomentar un ambiente en el que el entorno de la información cambia en respuesta a las necesidades de la empresa, en lugar de tener el cambio de negocio en respuesta a los cambios de TI. Esto es para asegurar que el objetivo de la ayuda la información - la operación de los negocios - es la base de cualquier cambio propuesto. Los efectos no intencionales en los negocios debido a que los cambios se reducen al mínimo. Un cambio en la tecnología puede proporcionar una oportunidad para mejorar los procesos de negocio y, por tanto, cambiar las necesidades del negocio. Implicaciones: 

Cambios en la aplicación seguirán examen completo de los cambios propuestos que utilizan la arquitectura empresarial.



No financiamos una mejora o un sistema de desarrollo técnico a menos que exista una necesidad de negocio documentado.



los procesos de gestión del cambio que se ajusten a este principio serán desarrollados e implementados.



Este principio puede chocar contra el principio de un cambio sensible. Debemos asegurar el proceso de documentación requisitos no impide el cambio de respuesta para satisfacer las necesidades comerciales legítimos. El propósito de este principio es mantenernos enfocados en los negocios, no las necesidades de tecnología - Cambio de respuesta es también una necesidad de negocio.

Página 255 de 670

The Open Group Architecture Framework TOGOF 9.1   Principio 19: Cambio Responsive Gestión

Declaración: Los cambios en el entorno de la información empresarial se implementan de una manera oportuna. Justificación: Si las personas son de esperar para trabajar en el entorno de la información empresarial, ese entorno la información debe ser sensible a sus necesidades. Implicaciones: 

Tenemos que desarrollar procesos para gestionar e implementar el cambio que no generan retrasos.



Un que sienta la necesidad de cambio tendrá que conectar con un "experto en los negocios" para facilitar la explicación y la aplicación de esa necesidad.



Si vamos a hacer cambios, debemos mantener las arquitecturas actualizado.



La adopción de este principio podría requerir recursos adicionales.



Este entrará en conflicto con otros principios (por ejemplo, el máximo beneficio de toda la empresa, las aplicaciones en toda la empresa, etc.)

Principio 20: Diversidad Técnica de Control

Declaración: La diversidad tecnológica es controlado para minimizar el costo no trivial de acumular conocimientos especializados y la conectividad entre múltiples entornos de procesamiento. Justificación: Existe un verdadero costo, no trivial de la infraestructura necesaria para apoyar las tecnologías alternativas para entornos de procesamiento. Hay otros costos de infraestructura incurridos para mantener múltiples construcciones de procesadores interconectados y mantenidos. La limitación del número de componentes soportados va a simplificar y reducir los costos de mantenimiento. Las ventajas comerciales de la diversidad técnicos mínimos son: un empaquetado estándar de los componentes; impacto de la implantación predecible;valoraciones y retornos predecibles; redefinido las pruebas; estado de utilidad; y aumento de la flexibilidad para acomodar los avances tecnológicos. Tecnología Común en toda la empresa brinda los beneficios de las economías de escala para la empresa. Costos de istración y de apoyo técnico se controlan mejor cuando los recursos limitados pueden centrarse en este conjunto compartido de la tecnología.

Página 256 de 670


Las políticas, normas y procedimientos que rigen la adquisición de la tecnología deben estar vinculados directamente a este principio.



Las opciones tecnológicas se verán limitados por las opciones disponibles dentro del plan de tecnología. Procedimientos para aumentar la tecnología aceptable establecido para satisfacer las nuevas necesidades tendrán que ser desarrollado y puesto en marcha.



No estamos congelando nuestra línea de base tecnológica. Damos la bienvenida a los avances tecnológicos y cambiaremos el plan de tecnología cuando la compatibilidad con la infraestructura actual, la mejora en la eficiencia operativa, o una capacidad requerida ha sido demostrada.

Principio 21: Interoperabilidad

Declaración: Software y hardware deben ajustarse a las normas definidas que promuevan la interoperabilidad de los datos, las aplicaciones y la tecnología. Justificación: Las normas ayudan a garantizar la coherencia, mejorando así la capacidad de istrar los sistemas y mejorar la satisfacción del , y proteger las inversiones existentes, maximizando así la rentabilidad de la inversión y la reducción de costos. Los estándares para la interoperabilidad, además, ayudan a asegurar el apoyo de múltiples proveedores para sus productos, y facilitan la integración de la cadena de suministro. Implicaciones: 

Los estándares de interoperabilidad y estándares de la industria serán seguidas a menos que exista una razón de negocios para implementar una solución no estándar.



Un proceso para el establecimiento de normas, examinar y revisar periódicamente, y la concesión de excepciones debe ser establecido.



Las plataformas existentes deben ser identificados y documentados.

Página 257 de 670


24. Gestión de las partes interesadas 24.1 Introducción Gestión de las partes interesadas es una disciplina importante que los profesionales de la arquitectura de éxito puede utilizar para ganar el apoyo de los demás. Esto les ayuda a garantizar que sus proyectos tengan éxito donde otros fracasan. Los beneficios de la exitosa gestión de los interesados son las siguientes: 

Los más poderosos partes interesadas pueden ser identificados temprano y su entrada a continuación, se pueden utilizar para dar forma a la arquitectura; esto asegura su apoyo y mejora la calidad de los modelos producidos.



El apoyo de los grupos de interés más poderosos ayudará a que el compromiso de ganar más recursos, con lo que la participación de la arquitectura más probabilidades de éxito.



Mediante la comunicación con las partes interesadas temprano y con frecuencia, el equipo de arquitectura puede asegurarse de que comprenden plenamente el proceso de la arquitectura, y los beneficios de la arquitectura de la empresa; esto significa que pueden apoyar al equipo de arquitectura más activa cuando es necesario.



El equipo de arquitectura se puede anticipar con mayor eficacia probables reacciones a los modelos de arquitectura e informes, y se puede incorporar en el plan de las acciones que serán necesarias para sacar provecho de reacción positiva, evitando o tratar cualquier reacción negativa.



El equipo de arquitectura puede identificar objetivos en conflicto o en competencia entre las partes interesadas temprana y desarrollar una estrategia para resolver los problemas que surgen de ellos.

Es esencial en cualquier iniciativa para identificar a los individuos y grupos dentro de la organización que contribuyan al desarrollo de la arquitectura, identificar aquellos que ganará y los que perderán a partir de su introducción, y luego desarrollar una estrategia para tratar con ellos.

24.2 Enfoque de gestión de los interesados Análisis de los interesados se debe utilizar durante la Fase A (Architecture Vision) para identificar los actores clave en el compromiso, y también se actualizará a lo largo de cada fase; diferentes grupos de interés pueden ser descubiertos como el compromiso progresa a través en oportunidades y soluciones, de planeamiento de migración, y Arquitectura de Gestión del Cambio. Arquitecturas complejas son muy difíciles de manejar, no sólo en términos del propio proceso de desarrollo de la arquitectura, sino también en términos de obtener el acuerdo de la gran cantidad de grupos de interés afectados por ella. Por ejemplo, al igual que un arquitecto de la construcción va a crear esquemas eléctricos, planos de planta y elevaciones para describir las distintas facetas de un edificio para sus diferentes grupos

Página 258 de 670

The Open Group Architecture Framework TOGOF 9.1   de interés (electricistas, propietarios, funcionarios de planificación), por lo que un arquitecto de la empresa debe crear diferentes puntos de vista de la empresa, arquitectura de sistemas de información y tecnología para los grupos de interés que tienen inquietudes relacionadas con estos aspectos. TOGAF identifica específicamente este tema en todo el a través de los siguientes conceptos (como se define en 35.1 Conceptos Básicos ): 

Las partes interesadas



Preocupaciones



Vistas



Puntos de Vista

24.3 Pasos en el proceso de gestión de los grupos de interés Las siguientes secciones detallan recomienda la actividad de gestión de los grupos de interés.

24.3.1 Identificar a los Interesados Identificar los grupos de interés clave de la arquitectura de la empresa. La primera tarea es la de una lluvia de ideas que los principales grupos de interés de arquitectura empresarial son. Como parte de esto, piensa en todas las personas que se ven afectados por ella, que tienen influencia o poder sobre él, o tienen un interés en su conclusión exitosa o no. Puede incluir los altos ejecutivos, los roles de organización de proyectos, roles de la organización cliente, los desarrolladores de sistemas, socios de la alianza, los proveedores, las operaciones de TI, clientes, etc En la identificación de los interesados, existe el peligro de concentrarse demasiado en la estructura formal de una organización como la base para la identificación. Los grupos informales de partes interesadas pueden ser tan poderosos e influyentes como los formales. La mayoría de los individuos pertenecen a más de un grupo de interesados, y estos grupos tienden a surgir como resultado de eventos específicos. Mira quién está afectado por el proyecto de arquitectura de la empresa: 

¿Quién gana y quién pierde con este cambio?



¿Quién controla la gestión del cambio de los procesos?



¿Quién diseña nuevos sistemas?



¿Quién tomará las decisiones?



¿Quién adquiere sistemas de TI y quién decide qué comprar?

Página 259 de 670


¿Quién controla los recursos?



¿Quién tiene habilidades especiales que necesita el proyecto?



¿Quién tiene influencia?

En particular, los influyentes deben ser identificados. Estos serán muy respetados y se mueve hacia arriba, participar en las reuniones y comités importantes (ver actas de reuniones), saben lo que está pasando en la empresa, ser valorado por sus compañeros y superiores, y no necesariamente estar en cualquier posición formal de poder. Aunque los interesados pueden ser tanto organizaciones como personas, en última instancia, el equipo de arquitectura de la empresa tendrá que comunicarse con la gente.Se trata de los actores individuales correctas dentro de una organización de las partes interesadas que necesitan ser identificados formalmente. Análisis de los actores 24.3.1.1 Muestra

Un análisis de los actores muestra que distingue 22 tipos de grupos de interés en cinco grandes categorías, se muestra en la Figura 24-1 . Cualquier proyecto de arquitectura en particular puede tener más, menos o diferentes grupos de interés; y pueden ser agrupadas en más, menos, o de diferentes categorías.

Figura 24‐1: Las partes interesadas de la muestra y Categorías Página 260 de 670

The Open Group Architecture Framework TOGOF 9.1   Tenga en cuenta tanto el Visible equipo - los obviamente asociado al proyecto / cambio - y el equipo Invisible - los que tienen que hacer una verdadera contribución al proyecto / cambio para que sea un éxito, pero que no han estado vinculadas al mismo (por ejemplo, los proveedores de servicios de apoyo).

24.3.2 Posiciones Clasifique las partes interesadas Desarrollar una buena comprensión de los actores más importantes y grabar este análisis para referencia y refrescarse durante el proyecto. Un análisis de los interesados ejemplo se muestra en la Tabla 24-1 .

Grupo de Tenedor de Capacidad partes apuestas de alterar el interesadas Cambio CIO John Smith H CFO Jeff Brown M

Actual comprensión M M

Se requiere la comprensión H M

-Promiso actual L L

-Promiso Apoyo Requerido Requerido M M

H M

Ejemplo de análisis de las partes interesadas: Tabla 24‐1 También es importante evaluar la disposición de cada uno de los interesados que se comporten de una manera que apoye (es decir, demostrar su compromiso con la iniciativa de arquitectura de la empresa).

Esto se puede hacer haciendo una serie de preguntas: 

¿Es esa persona dispuesta a cambiar de dirección y comenzar a moverse hacia la Arquitectura objetivo? Si es así, ¿listo?



¿Es esta persona capaz de ser un defensor creíble o agente de la iniciativa de la arquitectura empresarial propuesto? Si es así, cómo es capaz?



¿Qué tan involucrado está el individuo en la iniciativa de arquitectura de la empresa? Son simplemente un observador interesado, o qué tienen que estar involucrados en los detalles?



Esa persona ha hecho un compromiso contractual para el desarrollo de la arquitectura de la empresa, y su papel en la gobernanza del desarrollo de la organización?

Luego, para cada persona cuyo compromiso es fundamental para garantizar el éxito, hacer un juicio acerca de su actual nivel de compromiso y el nivel deseado de compromiso futuro.

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

Página 261 de 670

The Open Group Architecture Framework TOGOF 9.1   pueden cuidar. Este paso permite al equipo ver fácilmente que se espera que los interesados para ser bloqueantes o los críticos, y que son susceptibles de ser defensores y partidarios de la iniciativa de las partes interesadas. Calcula el poder de las partes interesadas, la influencia y los intereses, a fin de enfocar la participación de arquitectura empresarial de los individuos clave. Estos se pueden asignar a una matriz de poder / interés, lo que también indica la estrategia a adoptar para colaborar con ellos. Figura 24-2 muestra un ejemplo de matriz red eléctrica.

Figura 24‐2: Stakeholder Power Grid 24.3.4 Tailor Engagement Entregables Identificar los catálogos, matrices y diagramas que el compromiso arquitectura necesita para producir y validar con cada grupo de interés para ofrecer un modelo de arquitectura eficaz. Es importante prestar especial atención a los intereses de los participantes mediante la definición de los catálogos específicos, matrices y diagramas que son relevantes para un modelo de arquitectura de la empresa en particular. Esto permite que la arquitectura se comunique a, y entendida por todos los interesados, y les permite verificar que la iniciativa de arquitectura de la empresa se ocupará de sus preocupaciones.

24.4 Plantilla Stakeholder Mapa La siguiente tabla proporciona un ejemplo mapa de las partes interesadas para un proyecto de arquitectura TOGAF que tiene grupos de interés identificados en la Figura 24-1 . Tenedor de apuestas CxO (Funciones Corporativas), por ejemplo, el CEO, CFO, CIO, COO

Oficina del Programa de Gestión

Preocupaciones claves

Clase

Los pilotos de alto nivel, las MANTENGA metas y objetivos de la SATISFECHO organización, y cómo éstos se traducen en un proceso efectivo y la arquitectura de TI para avanzar en el negocio. Priorizar, la financiación, y MANTENGA la alineación de la actividad SATISFECHO

Catálogos, matrices y diagramas Diagrama de Huella de negocios Meta / Objetivo diagrama / Servicio Organización diagrama de descomposición Catálogo de Requisitos

Página 262 de 670

The Open Group Architecture Framework TOGOF 9.1   (Funciones Corporativas), por ejemplo, los Gerentes de Cartera de Proyectos

de cambio. La comprensión de los contenidos del proyecto y las dependencias técnicas entre los proyectos apoya la gestión de carteras de toma de decisiones.

Diagrama de Contexto del Proyecto Diagrama de Beneficios Diagrama de Huella de negocios Diagrama de comunicaciones de la aplicación

Diagrama de descomposición funcional Adquisiciones Entender lo que los bloques JUGADORES CLAVE Catálogo Cartera (Funciones de construcción de la Tecnológica Corporativas); arquitectura se pueden por ejemplo, los comprar, y qué Catálogo de Normas de compradores restricciones (o reglas) son Tecnología relevantes para la compra. Los compradores harán compras con múltiples proveedores en busca de la mejor solución de coste, si bien respetando las restricciones (o reglas) derivados de la arquitectura, como las normas. La principal preocupación es hacer que las decisiones de compra que se ajustan a la arquitectura. Recursos Humanos (HR) Se requieren los roles y MANTENGA Organización diagrama de (Funciones actores para apoyar la INFORMADO descomposición Corporativas), arquitectura y los cambios a por ejemplo, directores de la misma. La principal Catálogo de Organización recursos humanos, preocupación es la gestión / Actor Formación y Gerentes de de las personas Desarrollo transiciones. Ubicación catálogo

Enterprise Security (Funciones Corporativas), por ejemplo, Gestión de Riesgo Corporativo, Oficiales de Seguridad, Gerentes de Seguridad

Aplicación y diagrama Ubicación Asegurar que la JUGADORES CLAVE Diagrama del ciclo de vida información, los datos y los del producto sistemas de la organización están disponibles sólo para Diagrama de Divulgación aquellos que tienen el de Datos permiso, y la protección de la información, los datos y Diagrama de seguridad los sistemas de de datos manipulación no autorizada. Matriz Actor / Rol Diagrama de Hardware en

Página 263 de 670

The Open Group Architecture Framework TOGOF 9.1   Red Informática Ingeniería de Comunicaciones diagrama QA / Standards Group Asegurar la gobernabilidad JUGADORES CLAVE Proceso / Evento / Control (Funciones consistente de negocio de / Catálogo de productos Corporativas), la organización, datos, por ejemplo, los aplicaciones y activos de Catálogo Contract / propietarios de los datos, tecnología. Medida los dueños de procesos, normas técnicas Cuerpos Catálogo de la cartera de aplicaciones Catálogo de interfaz Catálogo de Normas de Tecnología

Ejecutivo Los pilotos de alto nivel, las MANTENGA (End Organization); metas y objetivos de la SATISFECHO por ejemplo, los organización, y cómo éstos Directores de Unidad de se traducen en un proceso Negocio, CxOs Unidad de y la arquitectura para Negocios, Business Unit avanzar en el negocio Director de TI / eficaz. Arquitectura

Catálogo Cartera Tecnológica Diagrama de Huella de negocios Meta / Objetivo diagrama / Servicio Organización diagrama de descomposición Diagrama de Flujo del Proceso

Diagrama de comunicaciones de la aplicación Gestión de líneas Funciones de nivel superior JUGADORES CLAVE Diagrama de Huella de (Organización para el y los procesos de la negocios final); organización, y cómo las por ejemplo, los altos aplicaciones clave de Organización diagrama de directivos empresariales, apoyar estos procesos. descomposición Gerentes Regionales de Operaciones, Gerentes de Diagrama de TI descomposición funcional Diagrama de Flujo del Proceso Diagrama de comunicaciones de la aplicación Aplicación y diagrama Ubicación

Página 264 de 670

The Open Group Architecture Framework TOGOF 9.1   Negocios Expertos de dominio (Organización para el final); por ejemplo, expertos de procesos de negocio, Business Analyst / Proceso, Proceso Arquitecto, Diseñador de procesos, gerentes funcionales, Analista de Negocios

Aspectos funcionales de los JUGADORES CLAVE procesos y sistemas de apoyo. Esto puede cubrir los actores humanos involucrados en el sistema, los procesos de que intervienen en el sistema, las funciones que se requieren para apoyar los procesos y la información necesarios para fluir en apoyo de los procesos.

Matriz de interacción de negocios Matriz Actor / Rol Diagrama de Business Service / Information Diagrama de descomposición funcional Diagrama del ciclo de vida del producto Negocios diagrama de casos de uso Esquema de aplicación de casos de uso Diagrama de comunicaciones de la aplicación

IT Service Management Asegurar que los servicios MANTENGA (Operaciones de de TI proporciona a la INFORMADO Sistemas), organización a cumplir con por ejemplo, el los niveles de servicio de servicios requeridos por la de entrega organización para tener éxito en los negocios.

Entity Data / matriz de funciones de negocios Catálogo de Normas de Tecnología Catálogo Cartera Tecnológica Catálogo Contract / Medida Diagrama Realización de proceso / aplicación

Operaciones de TI Aplicaciones (Operaciones de sistema); por ejemplo, la arquitectura de aplicaciones, sistemas y software Ingenieros

Diagrama de istración de Enterprise Enfoque de Desarrollo, la JUGADORES CLAVE Diagrama Realización de modularidad del software y proceso / aplicación la reutilización, portabilidad de migración, y la Aplicación / matriz de interoperabilidad. datos Diagrama de Migración de aplicaciones Software diagrama de Ingeniería

Página 265 de 670

The Open Group Architecture Framework TOGOF 9.1   Diagrama de la descomposición Plataforma Diagrama de Red Informática / Hardware Diagrama de distribución de software Operaciones de TI Ubicación, modificabilidad, JUGADORES CLAVE Diagrama de Infraestructura reusabilidad y la descomposición (Operaciones de disponibilidad de todos los Plataforma sistema); componentes del por ejemplo, Arquitecto de sistema.Asegurar que los Catálogo de Normas de Infraestructura, apoyo componentes adecuados se Tecnología Wintel, soporte de gama desarrollan y despliegan media, DBA Operacional, dentro del sistema de una Catálogo Cartera Service Desk manera óptima. Tecnológica Diagrama de istración de Enterprise Diagrama de Red Informática / Hardware Diagrama de Procesamiento Ambientes y zonas diagrama Comunicaciones de datos Ubicación, modificabilidad, JUGADORES CLAVE Ingeniería de / voz - Operaciones de TI reusabilidad y la Comunicaciones ; (Operaciones del disponibilidad de servicios diagrama sistema) de comunicaciones y de por ejemplo, redes. Asegurar que las istración de red correspondientes comunicaciones y los servicios de redes se desarrollan y despliegan dentro del sistema de una manera óptima. Ejecutivo En tiempos, entrega en el MANTENGA Catálogo de Requisitos (Organización del presupuesto de una INFORMADO proyecto); iniciativa de cambio que va Catálogo de Principios por ejemplo, el a darse cuenta de los Patrocinador, el beneficios esperados para Diagrama de la cadena de de la organización. valor programas Diagrama conceptual de soluciones Diagrama de

Página 266 de 670

The Open Group Architecture Framework TOGOF 9.1   descomposición funcional

istración de Línea (Organización del proyecto); por ejemplo, Gerente de Proyectos

El logro de vista operativo a MANTENGA tiempo, entrega del INFORMADO presupuesto de una iniciativa de cambio con un alcance acordado.

Aplicación y diagrama Ubicación Diagrama de comunicaciones de la aplicación Diagrama de descomposición funcional

Ambientes y zonas diagrama Business Process / La adición de más detalle a JUGADORES CLAVE Diagrama de Flujo del Experto Funcional las necesidades funcionales Proceso (Organización del de una iniciativa de cambio proyecto); basado en la experiencia y Negocios diagrama de por ejemplo, Finanzas la interacción con expertos casos de uso FICO Consultor en el dominio de negocio de Funcional, HR Consultor la organización del Diagrama de Business Funcional final. Service / Information Diagrama de descomposición funcional Diagrama de comunicaciones de la aplicación Especialista de Producto Especificación de diseños JUGADORES CLAVE Software diagrama de (Organización del de productos de tecnología Ingeniería proyecto); con el fin de cumplir con los por ejemplo, Especialista requisitos del proyecto y Aplicación / matriz de Product Portal cumplir con la Visión de datos Arquitectura de la solución.

Técnico Especialista (Organización del proyecto); por ejemplo, la solicitud de Arquitecto

En un entorno de paquetes y servicios empaquetados, experiencia con el producto se puede utilizar para identificar las capacidades de productos que se pueden aprovechar fácilmente y pueden proporcionar orientación sobre las estrategias de personalización del producto. Especificación de diseños JUGADORES CLAVE de productos de tecnología con el fin de cumplir con los requisitos del proyecto y cumplir con la Visión de Arquitectura de la solución.

Software diagrama de Ingeniería Diagrama de descomposición Plataforma Diagrama Realización de

Página 267 de 670

The Open Group Architecture Framework TOGOF 9.1   proceso / aplicación Aplicación / matriz de datos

Organismos Reguladores (Servicios exteriores); por ejemplo, Regulador Financiero, Reguladora de la Industria

La recepción de la MANTENGA información que necesitan SATISFECHO con el fin de regular la organización del cliente, y asegurar que sus requisitos de información se satisfacen correctamente. Interesado en los procesos de información, y los datos y las aplicaciones que se utilizan para proporcionar información de retorno reguladora. Proveedores Asegurarse de que sus MANTENGA (Servicios exteriores); necesidades de intercambio SATISFECHO por ejemplo, la Alianza de información se reunieron socios, proveedores clave con el fin de que los contratos de servicio de acuerdo con las organizaciones de los clientes se pueden cumplir.

Diagrama de Migración de aplicaciones Diagrama de Huella de negocios Diagrama de comunicaciones de la aplicación

Diagrama de Huella de negocios Diagrama de Business Service / Information Diagrama de comunicaciones de la aplicación

25. Patrones Arquitectura Este capítulo proporciona directrices para el uso de patrones de arquitectura.

25.1 Introducción Patrones para architecting sistema son muy mucho en su infancia. Ellos se han introducido en TOGAF esencialmente para atraerlos a la atención de la comunidad de arquitectura de sistemas como un importante recurso emergente, y como marcador de posición para las descripciones de esperar más rigurosos y las referencias a los recursos más abundantes en las futuras versiones de TOGAF. Han no (todavía) han integrado en TOGAF. Sin embargo, en la siguiente, se intenta indicar el valor potencial de TOGAF, y qué partes de la Arquitectura Método de Desarrollo de TOGAF () que podrían ser relevantes.

Página 268 de 670

The Open Group Architecture Framework TOGOF 9.1   25.1.1 Antecedentes Un "modelo" se ha definido como: "una idea que ha sido útil en un contexto práctico y probablemente será útil para los demás" [ Los patrones de análisis - modelos de objetos reutilizables ]. En TOGAF, los patrones son considerados como una forma de poner bloques de construcción en su contexto; por ejemplo, para describir una solución reutilizable a un problema. Bloques de construcción son lo que usted utiliza: patrones pueden decir cómo usarlos, cuándo, por qué, y qué ventajas y desventajas que tiene que hacer con ello. Los patrones ofrecen la promesa de ayudar al arquitecto a identificar combinaciones de Arquitectura y / o solución de Building Blocks (Abs / SBB) que han sido probados para ofrecer soluciones eficaces en el pasado, y pueden proporcionar la base para soluciones eficaces en el futuro. Técnicas patrón generalmente se reconoce que se han establecido como una valiosa técnica de diseño de la arquitectura de Christopher Alexander, arquitecto de los edificios, que describió este enfoque en su libro The Way intemporal de la Construcción , publicado en 1979. Este libro ofrece una introducción a las ideas detrás de la uso de patrones, y Alexander siguió con dos libros más ( un lenguaje de patrones y el experimento de Oregon ) en la que se expandió en su descripción de las características y beneficios de un enfoque patrones de arquitectura. Software y edificios los arquitectos tienen muchos problemas similares a la dirección, y por lo que era natural para los arquitectos de software que se interesan por los patrones como una herramienta arquitectónica. Muchos artículos y libros han sido publicados en ellos desde 1979 el libro de Alexander, quizás los más reconocidos bienestar Patrones de diseño: Elementos de la Reusable de Software Orientado a Objetos . Este libro describe las soluciones simples y elegantes a problemas específicos en el diseño de software orientado a objetos.

25.1.2 Contenido de un Patrón Varios formatos se utilizan en la literatura para describir los patrones, y hay un formato único ha logrado una aceptación generalizada. Sin embargo, existe un amplio acuerdo sobre los tipos de cosas que un patrón debe contener. Los títulos que siguen están tomadas de Pattern-Oriented Architecture Software: Un sistema de modelos .Los elementos que se describen a continuación se pueden encontrar en la mayoría de los patrones, aunque diferentes partidas se usan para describirlos. Nombre Una manera significativa y memorable para referirse al patrón, por lo general una sola palabra o frase corta. Problema Una descripción del problema que indica la intención de aplicar el patrón - las metas y objetivos previstos que han de alcanzarse en el contexto y las fuerzas se describen a continuación (quizás con alguna indicación de sus prioridades). Contexto

Página 269 de 670

The Open Group Architecture Framework TOGOF 9.1   Las condiciones en las que el patrón es aplicable - una descripción de la situación inicial antes de que el patrón se aplican. Fuerzas Una descripción de las fuerzas y limitaciones correspondientes, y cómo interactúan / conflicto entre sí y con las metas y objetivos previstos. La descripción debe aclarar las complejidades del problema y hacer explícitos los tipos de compensaciones que se deben considerar. (La necesidad de tales concesiones es típicamente lo que hace que el problema difícil, y genera la necesidad de que el patrón en el primer lugar.) La noción de "fuerzas" equivale en muchos aspectos a las "cualidades" que los arquitectos buscan la optimización, y las preocupaciones que tratan de dirección, en el diseño de arquitecturas. Por ejemplo: 

Seguridad, robustez, fiabilidad, tolerancia a fallos



Capacidad de istración



La eficiencia, el rendimiento, el rendimiento, los requisitos de ancho de banda, la utilización del espacio



Escalabilidad (crecimiento gradual en la demanda)



extensibilidad, capacidad de evolución, mantenibilidad



La modularidad, la independencia, la reutilización, la apertura, la componibilidad (plug-and-play), la portabilidad



Integridad y exactitud



Facilidad de construcción



Facilidad de uso



etc, ...

Solución Una descripción, el uso de texto y / o gráficos, de cómo alcanzar las metas y objetivos previstos. La descripción debe identificar tanto la estructura de la solución estática y su comportamiento dinámico - el pueblo y los actores de computación y sus colaboraciones. La descripción puede incluir instrucciones para implementar la solución. Variantes o especializaciones de la solución también se pueden describir. Resultando Contexto Los post-condiciones después el patrón ha sido aplicada. La implementación de la solución suele requerir compensaciones entre las fuerzas de la competencia.Este elemento describe que las fuerzas se han resuelto y cómo, y que siguen sin resolverse. También puede indicar otros patrones que pueden ser aplicables en el nuevo contexto. (Un patrón puede ser un paso más en el cumplimiento de una meta más grande.) Ninguno de estos otros modelos se describen en detalle en los patrones relacionados.

Página 270 de 670

The Open Group Architecture Framework TOGOF 9.1   Ejemplos Una o más aplicaciones de ejemplo del patrón que ilustran cada uno de los otros elementos: un problema específico, el contexto y conjunto de fuerzas; cómo se aplica el patrón; y el contexto resultante. Razón fundamental Una explicación / justificación del modelo en su conjunto, o de los componentes individuales dentro de ella, lo que indica cómo funciona realmente el patrón, y por qué cómo resuelve los esfuerzos para alcanzar las metas y objetivos deseados, y por qué es "bueno". El elemento de la solución de un patrón describe la estructura externa y el comportamiento de la solución: la Razón da una idea de su funcionamiento interno. Patrones Relacionados . Las relaciones entre este patrón y otros Estos pueden ser patrones predecesoras, cuyos contextos resultantes corresponden al contexto inicial de éste; o patrones sucesores, cuyos contextos iniciales corresponden al contexto resultante de éste; o patrones alternativos, que describen una solución diferente para el mismo problema, pero bajo diferentes fuerzas; o patrones de co-dependientes, que pueden / deben ser aplicadas junto con este patrón. Usos conocidos Aplicaciones conocidas del patrón dentro de los sistemas existentes, la verificación de que el patrón de hecho describe una solución probada a un problema recurrente. Usos conocido también puede servir de ejemplo. Los patrones también pueden comenzar con un resumen de proporcionar una visión general de la estructura y la indicación de los tipos de problemas que trata. El Resumen también puede identificar el público objetivo y qué suposiciones se hacen del lector.

25.1.3 Terminología Aunque los patrones de diseño han sido el centro de gran interés en la industria del software por varios años, particularmente en los campos de orientación a objetos y software basado en componentes, es sólo recientemente que se ha producido un creciente interés en los patrones de la arquitectura - la ampliación de los principios y conceptos de patrones de diseño al dominio de la arquitectura. La literatura técnica relacionada con este campo es complicado por el hecho de que muchas personas en los campos de software usan el término "arquitectura" para referirse al software, y muchos patrones se describe como "patrones de arquitectura" son los patrones de diseño de software de alto nivel. Esto simplemente hace que sea aún más importante para ser precisos en el uso de la terminología. 25.1.3.1 patrones de arquitectura y patrones de diseño

El término "patrón de diseño" se usa con frecuencia para referirse a cualquier modelo que trata temas de arquitectura de software, el diseño o la implementación de programación. En Pattern-

Página 271 de 670

The Open Group Architecture Framework TOGOF 9.1   Oriented Software Architecture: Un sistema de modelos , los autores definen estos tres tipos de patrones de la siguiente manera: 

Un modelo de arquitectura expresa una organización estructural fundamental o esquema para sistemas de software. Proporciona un conjunto de subsistemas predefinidos, especifica sus responsabilidades, e incluye reglas y directrices para la organización de las relaciones entre ellos.



Un patrón de diseño proporciona un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. En él se describe una estructura comúnmente recurrentes de comunicar componentes que resuelve un problema de diseño general en un contexto particular.



Un Idiom es un patrón de bajo nivel específicos de un lenguaje de programación. Un modismo describe cómo implementar aspectos particulares de los componentes o las relaciones entre ellas utilizando las características de la lengua dada.

Estas distinciones son útiles, pero es importante tener en cuenta que los patrones de la arquitectura en este contexto todavía se refiere únicamente a la arquitectura de software. La arquitectura de software es sin duda una parte importante del enfoque de TOGAF, pero no es su único objetivo. En esta sección nos ocupamos de las pautas architecting sistema de la empresa. Estos son análogos a la arquitectura de software y patrones de diseño, y piden prestado muchos de sus conceptos y la terminología, sino que se centran en la prestación de los modelos y métodos reutilizables específicamente para el architecting de los sistemas de información de la empresa que comprende software, hardware, redes, y la gente - en oposición puramente a los sistemas de software. 25.1.3.2 Los patrones y el Continuum Arquitectura

Aunque los patrones de arquitectura han no (todavía) han integrado en TOGAF, cada una de las primeras cuatro fases principales de la (fases A a D) da una indicación de la etapa en que los activos de arquitectura reutilizables relevantes del Continuum Arquitectura empresa debe ser considerado para el uso. Patrones de arquitectura son uno de esos activos. Una empresa que adopta un enfoque formal para el uso y re-uso de patrones de arquitectura normalmente integrar su uso en el Continuum Arquitectura empresarial. 25.1.3.3 Patrones y Vistas

Arquitectura vistas son partes de uno o más modelos que representan seleccionan una completa arquitectura del sistema, centrándose en los aspectos que abordan las preocupaciones de uno o más grupos de interés. Los patrones pueden proporcionar ayuda en el diseño de este tipo de modelos, y en la composición de puntos de vista basados en ellos. 25.1.3.4 Los patrones y escenarios empresariales

Patrones de arquitectura pertinentes pueden también ser identificados en el trabajo sobre los escenarios de negocio.

Página 272 de 670

The Open Group Architecture Framework TOGOF 9.1   25.1.4 patrones de arquitectura en uso Dos ejemplos de patrones de arquitectura en uso se describen en los apartados siguientes, uno por el dominio de la propia estructura la arquitectura de una empresa cliente de TI, y el otro de un proveedor del sistema principal que ha hecho un montón de trabajo en los últimos años en el campo de la arquitectura patrones. 

La Guía de Desarrollo de Arquitectura del Tesoro de EE.UU. (TADG) documento (ver 25.2 del Tesoro de EE.UU. Arquitectura Orientación para el Desarrollo (TADG) ) proporciona una serie de patrones de arquitectura explícitas, además de explicar la razón de ser, la estructura, y la taxonomía de patrones de arquitectura y su relación con los EE.UU. Tesoro.



Los Patrones de IBM para el sitio web de e-Business (ver 25.3 Patrones de IBM para eBusiness ) da una serie de patrones de arquitectura que van desde el problema de negocio para soluciones específicas, en primer lugar, a nivel genérico y luego en términos de soluciones específicas de productos de IBM. Un recurso de apoyo es del conjunto de IBM Libros Rojos .

El siguiente material está diseñado para dar a los punteros del lector a algunos de los lugares en los que ya están siendo utilizados y puestos a disposición patrones de arquitectura, con el fin de ayudar a los lectores a tomar sus propias opiniones en cuanto a la utilidad de esta técnica para sus propios entornos.

25.2 del Tesoro de EE.UU. Arquitectura Orientación para el Desarrollo (TADG) El Tesoro de EE.UU. Arquitectura Orientación para el Desarrollo (TADG) documento - antes conocido como el Sistema de Información Arquitectura de Marco Tesoro (TISAF) - ofrece una serie de patrones de arquitectura explícitas. Sección 7 del documento TADG describe una razón de ser, la estructura, y la taxonomía de patrones de arquitectura, mientras que los patrones en sí se documentan formalmente en el Apéndice D. Los patrones de arquitectura presentados abarcan un conjunto más amplio de los sistemas que sólo los sistemas orientados a objetos.Algunos patrones de arquitectura se centran en los sistemas de legado, algunos en sistemas concurrentes y distribuidos, y algunos de los sistemas en tiempo real.

25.2.1 TADG contenido Pattern El contenido de un patrón de arquitectura como se define en el documento de TADG contiene los siguientes elementos: Nombre Cada patrón de arquitectura tiene un nombre descriptivo único, corto. La colección de nombres de los motivos arquitectura se puede utilizar como un vocabulario para describir, verificar y validar la información de arquitecturas de sistemas. Problema

Página 273 de 670

The Open Group Architecture Framework TOGOF 9.1   Cada patrón de arquitectura contiene una descripción del problema a resolver. El planteamiento del problema puede describir una clase de problemas o un problema específico. Razón fundamental La justificación describe y explica un problema específico típico que es representativa de la amplia clase de problemas a resolver por el patrón de la arquitectura.Para un problema específico, puede proporcionar información adicional sobre la naturaleza del problema y los requisitos para su resolución. Supuestos Los supuestos son condiciones que deben cumplirse para que el patrón de arquitectura que pueda utilizarse en la solución del problema. Incluyen restricciones en la solución y los requisitos que pueden hacer que la solución más fácil de usar.

Estructura El patrón de la arquitectura se describe en los diagramas y palabras en el mayor detalle que se requiere para transmitir al lector los componentes del patrón y sus responsabilidades. Interacciones Las relaciones e interacciones importantes entre los componentes del patrón se describen y limitaciones sobre estas relaciones e interacciones se identifican. Consecuencias Las ventajas y desventajas del uso de este patrón se describen, en particular en términos de otros patrones (ya sea necesaria o excluidos), así como las limitaciones de recursos que puedan surgir de su uso. Implementación Asesoramiento sobre la ejecución adicional que puede ayudar a los diseñadores en modificar este patrón de diseño arquitectónico para los mejores resultados.

25.2.2 TADG Arquitectura Patrones El documento TADG contiene los siguientes patrones. Diseño Arquitectónico Nombre del patrón -Client Proxy Server

Sinopsis Actúa como un concentrador para muchos enlaces de baja velocidad para acceder a un servidor.

Página 274 de 670

The Open Group Architecture Framework TOGOF 9.1   Atención al cliente Reactor Servidores replicados Arquitectura en capas Pipe y filtro de Arquitectura Interfaz Subsistema

Soporta complejo o con el cliente a través de múltiples organizaciones. Desacopla un evento de su procesamiento. Replica los servidores para reducir la carga en el servidor central. Una descomposición de los servicios tales que la mayoría de las interacciones ocurren sólo entre capas vecinas. Transforma la información en una serie de pasos o procesos incrementales. istra las dependencias entre grupos cohesivos de funciones (subsistemas).

25.3 Patrones de IBM para e-Business Los Patrones de IBM para e-Business web site (consulte www.ibm.com / framework / patrones ) proporciona un grupo de activos reutilizables destinada a acelerar el proceso de desarrollo de aplicaciones de e-business. A apoyar el sitio web de IBM está Patrones de Recursos eBusiness (consulte www.ibm.com / developerworks / patrones / biblioteca ). Esto también se conoce como los "Libros Rojos". La razón fundamental para la prestación de estos patrones de IBM es: 

Proporciona una manera simple y consistente para traducir las prioridades y requerimientos de negocio en soluciones técnicas



Asistir y acelerar el desarrollo de la solución y el proceso de integración, facilitando el montaje de una solución y minimizando personalizada implementaciones uno-de-unobueno



Captura el conocimiento y las mejores prácticas de los expertos y ponerla a disposición para su uso por personal menos experimentados



Facilitar la reutilización del capital intelectual, como las arquitecturas de referencia, marcos y otros activos de arquitectura

Patrones de IBM se centran específicamente en soluciones para e-Business; es decir, los que permiten a una organización para aprovechar las tecnologías web para negocios rediseñar los procesos, mejorar las comunicaciones y las fronteras organizacionales inferiores con: 

Los clientes y los accionistas (a través de Internet)



Los empleados y grupos de interés (a través de una Intranet corporativa)



Los vendedores, proveedores y socios (a través de una Extranet)

Tienen la finalidad de abordar los siguientes desafíos encontrados en este tipo de entorno: 

Alto grado de integración con sistemas heredados dentro de la empresa y con los sistemas fuera de la empresa



Las soluciones tienen que llegar a los s más rápido; esto no significa sacrificar la calidad, pero sí significa dar con maneras mejores y más rápidos para desarrollar estas soluciones

Página 275 de 670


Acuerdos de Nivel de Servicio (SLAs) son críticos



Necesidad de adaptarse a las tecnologías y los ciclos de producción reducido drásticamente cambiando rápidamente



Dirección una aguda escasez de las habilidades clave necesarias para desarrollar soluciones de calidad

IBM define cinco tipos de patrón: 



Patrones de Negocios , que identifican a los actores principales de negocio, y describen las interacciones entre ellos en términos de las diferentes interacciones de negocios arquetípicos tales como: o

Servicio (aka--to-business) - Los s que acceden a las transacciones sobre una base 24x7

o

Colaboración (alias de a ) - los s que trabajan con otros para compartir datos e información

o

Información Aggregation (aka de a los datos) - datos de múltiples fuentes agregan y se presentó a través de múltiples canales

o

Extended Enterprise (también conocido como de empresa a empresa) - integración de datos y procesos a través de las fronteras empresariales

Patrones de Integración , que proporcionan el "pegamento" para combinar negocios patrones para formar soluciones. Caracterizan el problema de negocio, procesos de negocio / rules y el entorno existente para determinar si se requiere front-end o back-end de la integración. o

Integración Front-end (aka la integración de ) - centrado en proporcionar un transparente y coherente para funciones de negocios. Funciones típicas incluyen siempre de sesión único, personalización, transcodificación, etc

o

Back-end de integración (también conocido como la integración de aplicaciones) se centró en la conexión, interfaces, o la integración de bases de datos y sistemas. Integración típica se puede basar en la función, el tipo de la integración, el modo de integración, y por topología.



Patrones compuestos , que son previamente identificados combinaciones y selecciones de patrones comerciales y de integración, para las situaciones previamente identificados como: soluciones de comercio electrónico, (públicos) de portales empresariales, portal de intranet de la empresa, la colaboración ASP, etc



Patrones de aplicaciones : Cada patrón de negocios e integración puede ser implementada utilizando uno o más patrones de aplicación. Un patrón de aplicación caracteriza la estructura de grano grueso de la aplicación - los principales componentes de la aplicación, la asignación de funciones de procesamiento y las interacciones entre ellos, el grado de integración entre ellos, y la colocación de los datos relativos a las aplicaciones.



Los patrones de tiempo de ejecución : los patrones de aplicaciones pueden ser implementadas por los patrones de tiempo de ejecución, lo que demuestra, las características de nivel de servicio no funcionales, como el rendimiento, capacidad,

Página 276 de 670

The Open Group Architecture Framework TOGOF 9.1   escalabilidad y disponibilidad. Identifican las principales limitaciones de recursos y las mejores prácticas. El sitio web de IBM también proporciona (IBM) las asignaciones de productos específicos para los patrones de tiempo de ejecución, lo que indica las opciones tecnológicas específicas para su implementación.

25.4 Algunos Recursos Patrón 

Los patrones Home Page (consulte hillside.net / patrones ) organizada por el Grupo de Hillside proporciona información acerca de los patrones, enlaces a modelos en línea, artículos y libros relacionados con los patrones y patrones relacionados con las listas de correo.



El Patrones-Discusión FAQ (consulte g.oswego.edu / dl / pd-FAQ / pd-FAQ.html ) mantenido por Doug Lea ofrece un FAQ muy completa y de fácil lectura sobre los patrones.



Modelos y Software: Conceptos Esenciales y Terminología de Brad Appleton (se refieren a www.bradapp.com / docs / patrones intro.html ) proporciona otra cuenta completa y legible del campo patrones.

Página 277 de 670


26. Escenarios empresariales y objetivos de la empresa En este capítulo se describe un método para derivar los requisitos de negocio para la arquitectura y los requisitos técnicos implicados. También proporciona directrices sobre la definición de metas y objetivos para el desarrollo de la arquitectura.

26.1 Introducción Un factor clave en el éxito de una empresa de arquitectura es la medida en la que esté vinculada a los requerimientos del negocio, y se puede demostrar el apoyo y permite a la empresa a alcanzar sus objetivos de negocio. Escenarios de negocios son una técnica importante que puede ser utilizado en diversas etapas de la arquitectura de la empresa, principalmente la Visión Arquitectura y Arquitectura de negocios, sino también en otros dominios de la arquitectura, así, si es necesario, para deducir las características de la arquitectura directamente de la alta los requisitos de nivel de la empresa. Se utilizan para ayudar a identificar y entender las necesidades del negocio, y por lo tanto para obtener los requisitos de negocio que el desarrollo de la arquitectura tiene que abordar. Un escenario de negocios describe: 

Un proceso de negocio, una aplicación o conjunto de aplicaciones que pueden ser habilitadas por la arquitectura



El ambiente de negocios y la tecnología



El pueblo y componentes informáticos (llamados "actores") que ejecutan el escenario



El resultado deseado de la correcta ejecución

Un buen escenario de negocios es representativo de una necesidad de negocio importante o problema, y permite a los proveedores a comprender el valor de la organización del cliente de una solución desarrollada. Un buen escenario de negocios es también "SMART": 

Específico , mediante la definición de lo que hay que hacer en el negocio



Medible , a través de métricas claras para el éxito



Actionable , a través de:



o

Claramente segmentar el problema

o

Proporcionar la base para determinar los elementos y los planes para la solución

Realista , en que el problema puede resolverse dentro de los límites de la realidad física, el tiempo, y las limitaciones de costo

Página 278 de 670


De duración determinada , en el que hay una declaración clara de cuándo caduca la oportunidad solución

26.9 Directrices sobre Metas y Objetivos proporciona ejemplos detallados sobre los objetivos que se podrían considerar. Independientemente objetivos que utilice, la idea es hacer que los objetivos de SMART.

26.2 Beneficios de escenarios empresariales Un escenario de negocios es esencialmente una descripción completa de un problema de negocio, tanto en los negocios como en términos de arquitectura, que permite a los requisitos individuales para ser visto en relación unos con otros, en el contexto del problema general. Sin una descripción tan completa a servir como contexto : 

Existe el peligro de la arquitectura se basa en un conjunto incompleto de los requisitos que no se suman a una descripción del problema en conjunto, y por lo tanto que puede confundir a obra de arquitectura.



El valor de negocio de la solución del problema no está clara.



La relevancia de las posibles soluciones es clara.

También, debido a que la técnica requiere de la participación de la gerencia de línea de negocios y otras partes interesadas en una fase temprana en el proyecto de arquitectura, sino que también desempeña un papel importante en la obtención de la buy-in de este personal clave para el proyecto en general y su producto final - la arquitectura de la empresa. Una ventaja adicional de escenarios de negocios se encuentra en comunicación con los proveedores. La mayoría arquitectura hoy en día se lleva a cabo haciendo uso máximo de Commercial Off-The-Shelf (COTS) de soluciones de software, a menudo de múltiples proveedores, adquirido en el mercado abierto. El uso de escenarios de negocio por un cliente que puede ser una ayuda importante para los proveedores de TI en la entrega de soluciones adecuadas. Los vendedores deben asegurarse de que sus componentes de soluciones agregan valor a una solución abierta y son negociables. Escenarios de negocio proporcionan un lenguaje con el que la comunidad de proveedores puede vincular los problemas del cliente y soluciones técnicas. Además de hacer evidente lo que se necesita, y por qué, que permiten a los proveedores para resolver problemas de manera óptima, usando estándares abiertos y el aprovechamiento de las habilidades de cada uno.

26.3 Crear el escenario de negocios 26.3.1 Proceso general Creación de un escenario de negocio consiste en la siguiente, como se ilustra en la Figura 26-1 :

1. Identificar, documentar y clasificar el problema de conducir el escenario 2. Identificar el entorno empresarial y técnica del escenario y documentarla en modelos de escenarios Página 279 de 670

The Open Group Architecture Framework TOGOF 9.1   3. Identificar y documentar los objetivos deseados (los resultados de la manipulación de los problemas con éxito); conseguir "SMART" 4. La identificación de los actores humanos (participantes) y su lugar en el modelo de negocio 5. La identificación de los actores de ordenador (elementos de computación) y su lugar en el modelo de la tecnología 6. Identificar y documentar los roles, responsabilidades y medidas de éxito por el actor; la documentación de los scripts requeridos por el actor, y los resultados del manejo de la situación

7. Comprobación de la "aptitud para el propósito" y refinación sólo si es necesario

Figura 26‐1: Crear un escenario de negocios Un escenario empresarial se desarrolla en una serie de fases iterativas de la recopilación, análisis y revisión de la información en el escenario de negocios. En cada fase, cada una de las áreas antes mencionadas se mejora sucesiva. El refinamiento paso consiste en decidir si se debe considerar el escenario completo y pasar a la siguiente fase, o si un mayor refinamiento es necesario. Esto se logra al preguntar si el estado actual del escenario de negocio es apto para el propósito de llevar a los requerimientos aguas abajo en el proceso de la arquitectura.

Página 280 de 670

The Open Group Architecture Framework TOGOF 9.1   Las tres fases del desarrollo de un escenario de negocios se describen en detalle más adelante, y representan en la Figura 26-2 .

Figura 26‐2: Fases del desarrollo de escenarios empresariales 26.3.2 Reunión La fase de recopilación es donde se recoge información sobre cada una de las áreas en la Figura 26-1 . Si los procedimientos y las prácticas de recopilación de información ya están en su lugar en una organización - por ejemplo, para reunir información para la planificación estratégica - que se debe utilizar según el caso, ya sea durante los talleres de escenarios de negocios o en lugar de los talleres de escenarios de negocios. Múltiples técnicas se pueden utilizar en esta fase, como la búsqueda de información, el análisis cualitativo, análisis cuantitativo, encuestas, solicitudes de información, etcComo la mayor información posible se debe reunir y pre-procesado "off-line" antes de cualquier cara a cara, talleres de cara (descritos a continuación). Por ejemplo, una solicitud de información pueden incluir una solicitud de planes estratégicos y operativos. Estos documentos suelen ofrecer grandes ideas, pero la información que contienen por lo general requiere preprocesamiento significativo. La información puede ser utilizada para generar un proyecto inicial de la situación empresarial antes del taller, si es posible. Esto aumentará la comprensión y la confianza del arquitecto, y el valor del taller a sus participantes. Una manera muy útil para recopilar información es la realización de talleres de escenarios de negocio, por lo que un consultor escenario de negocios lleva a un grupo selecto y pequeño de representantes de las empresas a través de una serie de preguntas para obtener la información que rodea el problema que se aborda por el esfuerzo de la arquitectura. Los asistentes al taller deben ser cuidadosamente seleccionados de altos niveles en los lados empresariales y técnicos de la organización. Es importante que la gente que puede y va a proporcionar información abierta y

Página 281 de 670

The Open Group Architecture Framework TOGOF 9.1   honestamente. Si ya existe un borrador del escenario de negocios - por ejemplo, como resultado de la decodificación previa información recogida durante esta fase, tal como se describe más arriba - el taller también se puede usar para examinar el estado del proyecto de escenario de negocios. A veces es necesario tener varios talleres: en algunos casos, para separar la recolección de información en la parte comercial de la recogida de información sobre los aspectos técnicos; y en otros casos simplemente para obtener más información de más personas. Cuando la recolección de información, el arquitecto puede fortalecer enormemente el escenario de negocios mediante la obtención de "ejemplos de la vida real"; es decir, los estudios de casos para los que el lector puede relacionar fácilmente. Al citar ejemplos del mundo real, es importante para mantener un nivel de anonimato de las partes involucradas, para evitar la culpa.

26.3.3 Analizar La fase de Análisis es donde una gran cantidad de trabajo de Arquitectura de negocios de bienes se hace realidad. Aquí es donde la información que se recopila es procesada y documentada, y donde se crean los modelos para representar esa información, por lo general visualmente. La fase de Análisis se aprovecha de los conocimientos y la experiencia del consultor escenario de negocios utilizando trabajos anteriores y experiencia para desarrollar los modelos necesarios para representar la información capturada. Tenga en cuenta que los modelos y documentos producidos no son necesariamente reproducen textualmentelas entrevistas, sino que se filtran y se traducen de acuerdo a las necesidades reales subyacentes. En la fase de Análisis es importante para mantener los vínculos entre los elementos clave de la situación empresarial. Una técnica que ayuda en el mantenimiento de tales enlaces es la creación de matrices que se utilizan para relacionar los procesos de negocio de cada uno de: 

Circunscripciones



Actores Humanos



Actores Informática



Cuestiones



Objetivos

De esta manera, el proceso de negocio se convierte en el punto focal de unión, lo que hace que una gran cantidad de sentido, ya que en la mayoría de los casos, es la mejora de procesos de negocio que se está buscando.

26.3.4 Revisión La fase de Revisión es donde los resultados son alimentados de nuevo a los patrocinadores del proyecto para asegurar que existe un entendimiento compartido de todo el alcance del problema, y la profundidad potencial del impacto técnico. Se recomiendan varios talleres de escenarios de negocios o reuniones de "lectura" con los patrocinadores y las partes involucradas. Las reuniones deben ser configurados para ser abierto e

Página 282 de 670

The Open Group Architecture Framework TOGOF 9.1   interactivo. Se recomienda contar con ejercicios incorporados en las agendas de reuniones, con el fin de probar la comprensión de los asistentes y de los niveles de interés, así como para poner a prueba los propios supuestos y resultados del arquitecto. Esta fase es muy importante, ya que la ausencia de expectativas compartidas en muchos casos es la causa fundamental del fracaso de los proyectos.

26.4 Contenido de un escenario de negocios La documentación de un escenario de negocios debe contener todos los detalles importantes sobre el escenario. Debe capturar, y la secuencia, los pasos críticos e interacciones entre actores que se ocupan de la situación. También debe declarar toda la información relevante acerca de todos los actores, en concreto: las diferentes responsabilidades de los actores; las condiciones previas fundamentales que han de cumplirse antes de la funcionalidad correcta del sistema; y los requisitos técnicos para el servicio sean de calidad aceptable. Hay dos tipos principales de contenido:. Gráficas (modelos), y un texto descriptivo Ambos tienen un papel que desempeñar. 

Modelos escenario empresarial vistas captura de negocios y tecnología en una forma gráfica, para facilitar la comprensión. En concreto, se relacionan los actores e interacciones, y dan un punto de partida para confirmar los requisitos específicos.



Descripciones de escenarios de negocios capturar detalles en forma textual. Una lista del contenido típico de un escenario de negocios es la siguiente.

Tabla de contenidos PRÓLOGO RESUMEN EJECUTIVO DOCUMENTO DE HOJA DE RUTA ESCENARIO DE NEGOCIO Visión general del escenario NEGOCIO ANTECEDENTES DE ESCENARIO PROPÓSITO DEL ESCENARIO DEFINICIONES / DESCRIPCIÓN DE LOS TÉRMINOS UTILIZADOS OPINIONES DE LOS ENTORNOS Y PROCESOS ENTORNO EMPRESARIAL Circunscripciones Descripciones de procesos Proceso de "a" etc .... ENTORNO TÉCNICO Entorno técnico "a" etc .... ACTORES Y SUS ROLES Y RESPONSABILIDADES ACTORES Y ROLES DEL ORDENADOR RELACIÓN DE LOS COMPONENTES Y PROCESOS ACTORES Y ROLES HUMANOS RELACIÓN DE LAS PERSONAS Y LOS PROCESOS ANÁLISIS DE FLUJO DE INFORMACIÓN PRINCIPIOS Y LIMITACIONES

Página 283 de 670

The Open Group Architecture Framework TOGOF 9.1   Principios de TI Restricciones REQUISITOS ANÁLISIS DE ESCENARIOS DE NEGOCIO Resumen del problema Cuestiones Objetivos RESUMEN ANEXOS ANEXO A: ESCENARIOS DE NEGOCIOS - INFORMACIÓN ADICIONAL APÉNDICE Bn: NOTAS ESCENARIO DEL TALLER

26.5 Las contribuciones al Escenario de Empresas Es importante darse cuenta de que la creación de un escenario de negocios no es el único de la provincia del arquitecto. Como se mencionó anteriormente, la gestión de la línea de negocios y otras partes interesadas en la empresa están involucrados, para asegurar que los objetivos de negocio se capturan con precisión. Además, dependiendo de la relación que la organización tiene con sus proveedores de TI, estos últimos también pueden estar involucrados, para garantizar que las funciones de las soluciones técnicas también se capturan con precisión, y para asegurar la comunicación con los proveedores. Por lo general, la participación de la gestión empresarial es mayor en las primeras etapas, mientras que los problemas de las empresas se están explorando y capturados, mientras que la participación del arquitecto es mayor en las etapas posteriores, y cuando se están describiendo soluciones arquitectónicas. Del mismo modo, si los vendedores están involucrados en el proceso de escenarios de negocio, la participación del lado del cliente (gestión empresarial, más arquitectos de la empresa) es mayor en las primeras etapas, mientras que la de los vendedores es el mayor en las etapas posteriores, cuando el papel de la técnica específica soluciones se están explorando y capturaron. Este concepto se ilustra en la Figura 26-3 .

Figura 26‐3: Contribuciones relación con un escenario de negocios

Página 284 de 670

The Open Group Architecture Framework TOGOF 9.1   Arquitectos de TI de proveedores podrían ser capaces de ayudar a los arquitectos de TI de la empresa con la integración de los productos de los vendedores en la arquitectura de la empresa. Esta asistencia muy probablemente cae en medio de la línea de tiempo en la Figura 263.

26.6 Escenarios de Negocio y el TOGAF Escenarios empresariales figura más prominente en la fase inicial del Método Arquitectura Desarrollo (), Architecture Vision, cuando se utilizan para definir los requisitos de negocio relevantes, y para construir un consenso con la gestión de las empresas y otros grupos de interés. Sin embargo, los requerimientos del negocio se hace referencia a lo largo de todas las fases del ciclo de , como se ilustra en la Figura 26-4 .

Página 285 de 670


Figura 26‐4: Importancia de los Requisitos A lo largo de la   Debido a los requerimientos del negocio son importantes en todas las fases del ciclo de , la técnica de escenario de negocios tiene un papel importante que desempeñar en el TOGAF , 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, es de empresas, s finales) le dirán lo que quieran, pero como arquitecto que aún deben obtener una comprensión de los negocios, por lo que deben saber los actores más importantes en el sistema. Si las partes interesadas no saben lo que quieren: 

Tómese su tiempo, observar y grabar cómo están trabajando hoy



Estructura de información de tal manera que se puede utilizar más tarde



Destape las reglas de negocio críticos de los expertos de dominio



Manténgase enfocado en lo que se necesita lograr, y cómo se va a lograr

Este esfuerzo proporciona el ancla para una cadena de la razón a partir de los requerimientos del negocio a través de soluciones técnicas. Se dará sus frutos más adelante ser diligente y crítica en la salida.

26.7.2 Preguntas que debe hacer para cada área El escenario de negocios talleres mencionó anteriormente en la fase de recopilación de entrevistas son muy estructurados. Si bien no existe un único conjunto de preguntas apropiadas para preguntar en todas las situaciones, lo siguiente puede servir de orientación para ayudar a los consultores de escenarios de negocio en hacer preguntas. La identificación, documentación, y Clasificación del Problema

¿El problema se describe como una declaración de lo que se necesita hacer, como los pasos de un proceso, y no la forma (con la tecnología "push")? Si el problema es demasiado específico o un "cómo": 

Levantar una bandera roja



Pregunte "¿Por qué necesita para hacerlo de esa manera?" preguntas

Página 286 de 670

The Open Group Architecture Framework TOGOF 9.1   Si el problema es demasiado vaga o no recurribles: 

Levantar una bandera roja



Pregunta "¿Qué es lo que hay que hacer, o va a ser capaz de hacer si se resuelve este problema?" preguntas

Haga preguntas que ayuden a identificar dónde y cuándo existe el problema: 

¿Adónde experimentando este problema en particular? En qué negocio proceso?



¿Cuándo se encuentra con estos problemas? Durante el inicio del proceso, el medio, el extremo?

Haga preguntas que ayuden a identificar los costos del problema: 

Cómo se explica por los costos asociados con este problema? Si es así, ¿cuáles son?



¿Hay costos ocultos? Si es así, ¿cuáles son?



¿El costo de este problema cubierto por el costo de algo más? Si es así, qué y cuánto?



¿El problema se manifiesta en términos de mala calidad o una percepción de una organización ineficaz?

Identificar el entorno empresarial y Técnico y Documentación de Modelos

Preguntas que debe hacer sobre el entorno empresarial: 

¿Qué proceso clave sufre de los problemas? ¿Cuáles son los pasos principales que necesitan ser procesados?



Ubicación / escala de departamentos internos de negocios?



Ubicación / escala de socios de negocios externos?



Cualquier reglas y regulaciones de negocios específicos relacionados con la situación?

Preguntas que debe hacer sobre el entorno tecnológico actual: 

¿Qué componentes de tecnología ya se presuponen estar relacionados con este problema?



¿Existen limitaciones de la tecnología?



¿Existen principios tecnológicos que se aplican?

Identificar y documentar los objetivos

¿Es el "qué" suficientemente respaldada con la justificación de "por qué"? Si no, pida razón de ser medible en las siguientes áreas:

Página 287 de 670


Retorno de la inversión



Escalabilidad



Necesidades de rendimiento



Conformidad con las normas



La facilidad de uso de las medidas de

La identificación de los actores humanos y su lugar en el Modelo de Negocio

Un actor representa cualquier cosa que interactúa con o dentro del sistema. Esto puede ser una un programa de ordenador humano, o una máquina, o. Actores iniciar la actividad con el sistema, por ejemplo: 

de la computadora con el ordenador



del teléfono con el teléfono



Empleado de la nómina con el sistema de nómina



Suscriptor de Internet con el navegador web

Un actor representa un rol que un juega; es decir, el es una persona que juega un papel mientras se utiliza el sistema (por ejemplo, John () 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





La identificación de los actores de ordenador y su lugar en el Modelo de Tecnología

Pregunte acerca de los componentes que pueden intervenir, de nuevo desde diferentes puntos de vista de la computadora. ¿Qué deben hacer? Roles Documentar, responsabilidades Medidas de éxito, Scripts Requeridos

En la definición de los roles, hacer preguntas como: 

¿Cuáles son las principales tareas del actor?



¿Será que el actor tenga que leer / escribir / modificar la información?

Página 288 de 670


¿Será que el actor tiene que informar al sistema acerca de los cambios externos?



¿Desea el actor para ser informado sobre cambios inesperados?

Comprobación de Aptitud para el propósito, y el perfeccionamiento de si es necesario

¿Hay suficiente información para identificar a quién / qué podría cumplir el requisito? Si no es así, indagar más a fondo. ¿Hay una descripción de cuándo y con qué frecuencia, el requisito debe ser abordado? Si no, pregunte acerca de la sincronización.

26.8 Documentación Escenario empresarial 26.8.1 Pruebas de documentación La documentación efectiva escenario empresarial requiere un equilibrio entre la garantía de que el detalle es accesible, y evitando que eclipsa los resultados y abrumar al lector. Con este fin, el documento de escenario de negocios debe tener los principales hallazgos en el cuerpo del documento y los detalles en los apéndices. En los apéndices: 

Capture todos los detalles importantes acerca de un escenario de negocios: o

Descripción Situación y razón

o

Todas las mediciones

o

Todos los roles de actor y sub-mediciones

o

Todos los servicios requeridos



Capture los pasos críticos entre los actores que se ocupan de la situación, y la secuencia de las interacciones



Declarar la información relevante acerca de todos los actores: o

Se reparte la responsabilidad de los actores

o

Lista de condiciones previas que deben cumplirse antes del funcionamiento correcto del sistema

o

Proporcionar los requisitos técnicos para que el servicio sea de calidad aceptable

En el cuerpo principal del escenario de negocios: 

Generalizar todos los datos relevantes de los detalles en los apéndices

26.8.2 Modelos escenario empresarial  Recuerde que el propósito de la utilización de modelos:

Página 289 de 670






o

Ayuda comprensión

o

Dar un punto de partida para confirmar los requisitos

o

Relacionar los actores y las interacciones

Mantenga dibujos clara y ordenada: o

No ponga demasiado en un diagrama

o

Diagramas más simples son más fáciles de entender

Esquemas numéricos para una fácil referencia: o

Mantener un catálogo de los números para evitar duplicados

26.9 Directrices sobre Metas y Objetivos 26.9.1 Importancia de los Objetivos de Uno de los primeros pasos en el desarrollo de una arquitectura es definir los objetivos generales y los objetivos para el desarrollo. Los objetivos deben derivarse de los objetivos de negocio de la organización, y la forma en que se ve a contribuir al logro de esos objetivos. Cada organización se comporta de manera diferente en este sentido, algunas de verlo como la fuerza motriz de la empresa y los demás ver que en un papel de apoyo, simplemente automatizar los procesos de negocio ya existentes. Lo esencial es que los objetivos arquitectónicos deben ser muy estrechamente alineados con las metas y objetivos de la organización de negocios.

26.9.2 Importancia de Objetivos SMART No sólo deben metas sean expresados en términos generales, sino también medidas específicas necesitan ser unidos a ellos para que sean de SMART, como se describe anteriormente. La cantidad de esfuerzo empleado en hacer esto dará lugar a una mayor claridad para los patrocinadores del ciclo de la evolución de la arquitectura. Se pagará por la conducción soluciones propuestas mucho más de cerca a los objetivos en cada etapa del ciclo. Es extremadamente útil para los diferentes grupos de interés dentro de la organización, así como para los proveedores y consultores, para tener un criterio claro para medir la aptitud para el propósito. Si se hace bien, el se puede utilizar para rastrear las decisiones específicas de regreso a los criterios, por lo que no darán su justificación. Las metas de abajo han sido adaptados de los que figuran en las versiones anteriores de TOGAF. Estas son las categorías de objetivos, cada uno con una lista de posibles objetivos. Cada uno de estos objetivos debe hacerse de SMART con medidas y métricas específicas para la tarea. Sin embargo, ya que el trabajo real que hacer será específica para el proyecto de arquitectura que se trate, no es posible proporcionar una lista de objetivos SMART genéricos que relacionarse con cualquier proyecto. En su lugar, ofrecemos aquí algunos ejemplos de objetivos SMART.

Página 290 de 670

The Open Group Architecture Framework TOGOF 9.1   Ejemplo de hacer objetivos SMART

En el marco del objetivo general de la rúbrica "Mejorar la productividad del " a continuación, hay un objetivo de proporcionar una "interfaz de uniforme" y se describe como sigue: "Una interfaz de consistente garantizará que todas las funciones y servicios accesibles para el aparecerán y se comportan de una manera predecible similares independientemente de la aplicación o el sitio. Esto dará lugar a una mayor eficiencia y un menor número de errores de los s, que a su vez puede resultar en menor recuperación costos ". Para realizar este objetivo de SMART, nos preguntamos si el objetivo es específico, medible y aplicable, realistas y de duración determinada, y luego aumentar el objetivo de manera apropiada. La siguiente captura de un análisis de estos criterios para el objetivo declarado: 

Específico :. El objetivo de proporcionar "una interfaz de coherente que asegure todas las funciones y servicios accesibles para el aparecerán y se comportan de una manera predecible similares independientemente de la aplicación o el sitio" es bastante específico. Sin embargo, las medidas que figuran en la segunda frase podría ser más específico ...



Medible : Como se indicó anteriormente, el objetivo es medible, pero podría ser más específico. La segunda frase podría modificarse para leer (por ejemplo): "Esto llevará a un 10% de mayor eficiencia del y de la orden de 20% menos de errores de de entrada, que a su vez puede dar lugar a un 5% más bajos costos de entrada de pedidos."



Actionable : El objetivo parece ser procesable. Parece claro que se debe proporcionar la consistencia de la interfaz de , y que podría ser manejado por los responsables de proporcionar la interfaz de para el dispositivo del .



Realista : El objetivo de proporcionar "una interfaz de coherente que asegure todas las funciones y servicios accesibles para el aparecerán y se comportan de una manera predecible similares independientemente de la aplicación o el sitio" podría no ser realista. Teniendo en cuenta el uso actual de la PDA al final el podría llevarnos a aumentar este objetivo de asegurar que los desarrolladores de aguas abajo no crean indebidamente diseños que dificultan el uso de las nuevas tecnologías. El objetivo podría ser re-declaró como "una interfaz consistente , a través de dispositivos de interfaz de que proporcionan similares funcionalidades, que se asegurará de ... ", etc



Limitado en el Tiempo : El objetivo como se ha dicho, no es de duración determinada. Para ser de duración determinada el objetivo podría ser re-declaró como "Al final de la Q3, proporcionar una constante ... ".

Los resultados anteriores en un objetivo de SMART que se parece más a esto (de nuevo recuerda que esto es un ejemplo): "Para el final de la Q3, proporcionar una interfaz de consistente a través de dispositivos de interfaz de que proporcionan una funcionalidad similar para asegurar aparecen todas las funciones y servicios accesibles para el y se comportan de una manera similar cuando se utilizan estos dispositivos en una forma predecible independientemente de la aplicación o el sitio. Esta dará lugar a un 10% de mayor eficiencia de los s y el 20% menos de errores de

Página 291 de 670

The Open Group Architecture Framework TOGOF 9.1   de entrada de pedidos, que a su vez puede dar lugar a un 5% más bajos costos de entrada de pedidos. "

26.9.3 Categorías de Metas y Objetivos Aunque cada organización tendrá su propio conjunto de objetivos, algunos ejemplos pueden ayudar en el desarrollo de una lista específica de la organización. Los objetivos que figuran a continuación son categorías de objetivos, cada uno con una lista de posibles objetivos, los cuales han sido adaptados a partir de los objetivos que figuran en las versiones anteriores de TOGAF. Cada uno de los objetivos que figuran a continuación deben hacerse de SMART con medidas y métricas específicas para la tarea en cuestión, como se ilustra en el ejemplo anterior. Sin embargo, el trabajo real que hacer será específica para el proyecto de arquitectura que se trate, y no es posible proporcionar una lista de objetivos SMART genéricos que relacionarse con cualquier proyecto. Objetivo: Mejorar el rendimiento de procesos de negocio

Mejoras en los procesos de negocios se pueden realizar a través de los siguientes objetivos: 

Mayor rendimiento proceso



Calidad de impresión consistente



Costes del proceso predecibles



El aumento de la reutilización de los procesos existentes



Reducción del tiempo de envío de información comercial de un proceso a otro proceso

Meta: Reducir Costos

Las mejoras en costes se pueden realizar a través de los siguientes objetivos: 

Menores niveles de redundancia y la duplicación de los activos en toda la empresa



Disminución de la dependencia de los proveedores de servicios de TI externos para integración y personalización



Menores costos de mantenimiento

Objetivo: Mejorar Operaciones de Negocios

Mejoras de operaciones comerciales se pueden realizar a través de los siguientes objetivos: 

Aumento del presupuesto disponible para las nuevas características de negocio



Reducción de costes de funcionamiento de la empresa



Disminución del tiempo de salida al mercado para los productos o servicios

Página 292 de 670


Aumento de la calidad de los servicios a los clientes



Mejora de la calidad de la información empresarial

Objetivo: Mejorar la Eficacia de Gestión

Mejoras de eficacia de gestión se pueden realizar a través de los siguientes objetivos: 

Mayor flexibilidad de los negocios



Menos tiempo para tomar decisiones



Decisiones de mayor calidad

Meta: Reducir el Riesgo

Mejoras de riesgo se pueden realizar a través de los siguientes objetivos: 

Facilidad de implementación de nuevos procesos



Errores introducidos en los procesos de negocio a través de sistemas complejos y defectuosos Disminución



Riesgos para la seguridad del mundo real disminuyó (incluidos los peligros que causan la pérdida de la vida)

Objetivo: Mejorar la Efectividad de la organización de TI

Organización de TI efectividad puede ser realizado a través de los siguientes objetivos: 

El aumento de lanzamiento de nuevos proyectos



Disminución de tiempo a la implantación de nuevos proyectos



Menor costo en el despliegue de nuevos proyectos



Disminución de la pérdida de continuidad de servicio cuando el despliegue de nuevos proyectos



El desarrollo común: las aplicaciones que son comunes a múltiples áreas de negocio serán desarrollados o adquiridos una vez y reutilizarse en lugar de desarrollar por separado por cada área de negocio.



Los sistemas abiertos de entorno: un entorno operativo común basado en estándares, que da cabida a la inyección de nuevos estándares, tecnologías y aplicaciones de nivel de toda la organización, se establecerán. Este entorno basado en estándares, servirá de base para el desarrollo de aplicaciones comunes y facilitar la reutilización de software.



El uso de productos: en la medida de lo posible, independiente del hardware, elementos fuera de la plataforma deben ser utilizados para satisfacer los requisitos con el fin de reducir la dependencia de desarrollos a medida y para reducir los costes de desarrollo y mantenimiento.

Página 293 de 670


Software reutilización: para aquellas aplicaciones que se deben desarrollar, desarrollo de aplicaciones móviles a medida reducirá la cantidad de software desarrollado y añadir al inventario de software adecuado para su reutilización por otros sistemas.



Compartir recursos: los recursos de procesamiento de datos (hardware, software y datos) será compartido por todos los s 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 s

Mejoras en la productividad del se pueden realizar a través de los siguientes objetivos: 

Interfaz de consistente: una interfaz de consistente garantizará que todas las funciones y servicios accesibles para el aparecerán y se comportan de una manera predecible similares independientemente de la aplicación o el sitio. Esto dará lugar a una mayor eficiencia y un menor número de errores de los s, que a su vez puede resultar en menores costos de recuperación.



Aplicaciones integradas: las aplicaciones disponibles para el se comportará de una manera lógicamente consistente a través de entornos de , lo que conducirá a los mismos beneficios que una interfaz de consistente.



El intercambio de datos: bases de datos se comparten a través de la organización en el contexto de la seguridad y las consideraciones operacionales, lo que aumenta la facilidad de a los datos requeridos.

Objetivo: mejorar la portabilidad y escalabilidad

La portabilidad y escalabilidad de las aplicaciones será a través de los siguientes objetivos: 

Portabilidad: aplicaciones que se adhieren a los estándares abiertos de sistemas serán portables, lo que aumenta la facilidad de movimiento-a través de plataformas informáticas heterogéneas. Aplicaciones portátiles pueden permitir que los sitios para actualizar sus plataformas conforme tengan lugar mejoras tecnológicas, con un impacto mínimo en las operaciones.



Escalabilidad: las aplicaciones que se ajustan al modelo será configurable, lo que permite el funcionamiento en todo el espectro de plataformas requeridas.

Objetivo: Mejorar la interoperabilidad

Mejoras de interoperabilidad entre aplicaciones y áreas de negocio se pueden realizar a través de los siguientes objetivos: 

Infraestructura común: la arquitectura debe promover una infraestructura de comunicaciones y computación basados en sistemas abiertos y sistemas de transparencia, incluyendo, pero no limitado a, sistemas operativos, istración de bases de datos, intercambio de datos, servicios de red, gestión de redes e interfaces de .

Página 294 de 670


Normalización: mediante la implementación de las plataformas basadas en estándares, las aplicaciones se le proporcionará y será capaz de utilizar un conjunto común de servicios que mejoren las oportunidades de interoperabilidad.

Objetivo: Aumentar el proveedor de la Independencia

La independencia del proveedor se incrementará a través de los siguientes objetivos: 

Componentes intercambiables: sólo el hardware y el software que tiene las interfaces basadas en estándares se seleccionarán, por lo que las actualizaciones o la inserción de nuevos productos darán lugar a una interrupción mínima en el entorno del .



Especificaciones no propietarias: capacidades se definen en términos de especificaciones no propietarias que soportan una competencia plena y abierta, y están a disposición de cualquier fabricante para su uso en el desarrollo de productos comerciales.

Meta: Reducir los costos de ciclo de vida

Los costos de ciclo de vida se puede reducir a través de la mayor parte de los objetivos mencionados anteriormente. Además, los siguientes objetivos se refieren directamente a la reducción de los costes del ciclo de vida: 

Reducción de la duplicación: la sustitución de los sistemas y las islas de automatización con sistemas abiertos interconectados aislados conducirá a la reducción de la funcionalidad de superposición, duplicación de datos y la redundancia innecesaria porque los sistemas abiertos pueden compartir datos y otros recursos.



Los costos de mantenimiento de software Reducido: reducciones en la cantidad y variedad de software utilizado en la organización dará lugar a reducciones en la cantidad y el costo de mantenimiento del software. El uso de software estándar off-the-shelf conducirá a nuevas reducciones de costes, ya que los proveedores de este tipo de software distribuyen sus costos de mantenimiento del producto a través de una base de s mucho mayor.



Sustitución incremental: interfaces comunes a los componentes de infraestructura compartida permite la sustitución gradual o actualizar con una perturbación operativa mínima.



Reducción de costos de formación, con sistemas comunes y compatibles Interfaces Hombre-Computadora (HCI) conducirán a la reducción de los costes de formación.

Objetivo: Mejorar la Seguridad

La seguridad puede ser mejorada en la información de la organización a través de los siguientes objetivos: 

Interfaces de seguridad consistentes para aplicaciones: las interfaces de seguridad consistentes y procedimientos dará lugar a un menor número de errores en el desarrollo de aplicaciones y la portabilidad de aplicaciones aumentado. No todas las aplicaciones tienen el mismo conjunto de características de seguridad, pero las características utilizadas serán consistentes en todas las aplicaciones.

Página 295 de 670


Interfaces de seguridad consistentes para los s: una interfaz de común a las características de seguridad dará lugar a una reducción del tiempo de aprendizaje cuando se pasa de un sistema a otro.



Independencia de Seguridad: la implementación de aplicaciones pueden utilizar la política de seguridad y los mecanismos apropiados para el entorno en particular si hay una buena estratificación en la arquitectura.



Una reducción del 25% en las llamadas a la mesa de ayuda en relación con las cuestiones de seguridad.



Una reducción del 20% en los "falsos positivos" detectados en la red (un falso positivo es un evento que parece ser un evento de seguridad procesable, pero en realidad es una falsa alarma).

Objetivo: Mejorar la capacidad de istración

Mejora de la gestión se puede realizar a través de los siguientes objetivos: 

Consistente interfaz de gestión: las prácticas y procedimientos de gestión coherentes facilitarán la gestión a través de todas las aplicaciones y sus estructuras de soporte subyacentes. Una interfaz consistente puede simplificar la tarea de gestión, lo que aumenta la eficiencia del .



El servicio reducido, istración y mantenimiento de los costos: el funcionamiento, la istración y los costos de mantenimiento se pueden reducir a través de la disponibilidad de productos mejorados de gestión y una mayor estandarización de los objetos que se manejan.

26.10 Resumen Escenarios empresariales ayudan a abordar uno de los problemas más comunes que enfrentan los ejecutivos de TI: la alineación de TI con el negocio. El éxito de cualquier gran proyecto de TI se mide por el grado en que se vincula a los requerimientos del negocio, y se puede demostrar apoya y permite a la empresa a alcanzar sus objetivos de negocio. Escenarios de negocios son una técnica importante que puede ser utilizado en diversas etapas de la definición de arquitectura de la empresa, o de cualquier otro gran proyecto de TI, para deducir las características de la arquitectura directamente de los requisitos de alto nivel de la empresa. Escenarios de negocio se utilizan para ayudar a identificar y entender las necesidades del negocio, y por lo tanto para derivar los requerimientos de negocio que el desarrollo de la arquitectura, y en última instancia, la tecnología informática, ha de abordar. Sin embargo, es importante recordar que los escenarios de negocios son sólo una herramienta, no el objetivo. Son una parte de, y permiten, el proceso más amplio de desarrollo de la arquitectura. El arquitecto debe usarlos, pero no perderse en ellos. La clave es mantener la concentración cuidado con los "invasión de características", y abordar los temas más importantes que tienden a devolver el valor más grande.

Página 296 de 670


27. Análisis Gap La técnica conocida como análisis de brechas se utiliza ampliamente en el TOGAF Arquitectura Método de Desarrollo () para validar una arquitectura que se está desarrollando. La premisa básica es poner de relieve un déficit entre la arquitectura de línea de base y de la arquitectura de destino; es decir, los elementos que se han omitido deliberadamente, accidentalmente dejados de lado, o aún no definidas.

27.1 Introducción Un paso clave en la validación de una arquitectura es considerar lo que pudo haber sido olvidado. La arquitectura debe ser compatible con todas las necesidades de procesamiento de la información esenciales de la organización. La fuente más importante de las brechas que se deben considerar es preocupaciones de los interesados que no han sido abordados en la obra arquitectónica previa. Las fuentes potenciales de lagunas incluyen: 



Lagunas de dominio de negocios: o

Gente lagunas (por ejemplo, los requisitos de entrenamiento cruzado)

o

Lagunas de proceso (por ejemplo, las ineficiencias del proceso)

o

Herramientas lagunas (por ejemplo, duplicar o falta de funcionalidad de la herramienta)

o

Los vacíos de información

o

Lagunas de medición

o

Brechas financieras

o

Instalaciones lagunas (edificios, oficinas, etc)

Lagunas de dominio de datos: o

Datos no de moneda suficiente

o

Los datos que no se encuentren donde se necesita

o

No los datos que se necesita

o

Datos no disponibles cuando se necesiten

o

Los datos no se ha creado

o

Los datos no se consume

o

Lagunas relación de datos

Página 297 de 670


Aplicaciones afectados, eliminados, o creados



Tecnologías afectados, eliminados, o creados

27.2 Pasos sugeridos Los pasos sugeridos son los siguientes: 

Elaborar una matriz con todos los Arquitectura Bloques de Construcción (Abs) de la Arquitectura de referencia en el eje vertical, y todo el ABBS de la arquitectura seleccionada en el eje horizontal.



Añadir a la Arquitectura de referencia eje A última fila con la etiqueta "Nuevo", y al eje de Arquitectura Target una última columna etiquetada "Eliminado".



Cuando un ABB está disponible tanto en la línea de base y Target Arquitecturas, grabar esto con "incluido" en la celda de intersección.



Cuando un ABB de la Arquitectura de referencia no se encuentra en la arquitectura destino, cada uno debe ser revisado. Si se elimina correctamente, lo marca como tal en el apropiado "Eliminado" célula. Si no lo fuera, una omisión accidental en la Arquitectura objetivo se ha descubierto que debe abordarse mediante el restablecimiento de la ABB en la próxima iteración del diseño de la arquitectura - marcarlo como tal en el apropiado "Eliminado" célula.



Cuando un ABB de la Arquitectura objetivo no se puede encontrar en la arquitectura de referencia, marcarlo en la intersección con la línea "Nuevo", como una brecha que hay que cubrir, ya sea mediante el desarrollo o adquisición de la piedra angular.

Cuando el ejercicio se ha completado, cualquier cosa bajo "Eliminado" o "Nuevo" es una brecha, que debería o bien ser explicado como correctamente eliminado o marcado como ser abordado mediante el restablecimiento o el desarrollo / adquisición de la función.

27.3 Ejemplo La Figura 27-1 muestra un ejemplo de análisis de ABBS que son los servicios de la categoría de servicios de red del modelo de referencia técnica (TRM), y muestra una serie de servicios a partir de la arquitectura de referencia que faltan de la arquitectura destino.

Página 298 de 670


Figura 27‐1: Ejemplo de análisis de carencias

Página 299 de 670


28. Técnicas de Planificación Migración Este capítulo contiene una serie de técnicas que se utilizan para apoyar la planificación de la migración en las fases E y F.

Evaluación Factor 28.1 Implementación & Matrix Deducción La técnica de creación de una evaluación de la instrumentación Factor y la matriz de deducción se puede utilizar para documentar los factores que afectan la implementación de la arquitectura y el Plan de Migración. La matriz debe incluir una lista de los factores a tener en cuenta, sus descripciones, y las deducciones que indican las acciones o las limitaciones que deben ser tenidas en cuenta a la hora de formular los planes. Los factores incluyen típicamente: 

Riesgos



Cuestiones



Supuestos



Dependencias



Acciones



Impactos

Una matriz de ejemplo se muestra en la Figura 28-1 .

Figura 28‐1: Evaluación Factor Implementación y Matrix Deducción

Página 300 de 670


   28.2 Las lagunas consolidados, soluciones, y Matrix Dependencias La técnica de creación de unas lagunas consolidados, soluciones, y la matriz de dependencias permite al arquitecto grupo de las lagunas identificadas en la arquitectura de dominio resultados de análisis de carencias y evaluar las posibles soluciones y las dependencias a uno o más espacios. Esta matriz se puede utilizar como una herramienta de planificación cuando la creación de paquetes de trabajo. Las dependencias identificadas impulsarán la creación de proyectos y planificación de la migración en las fases E y F. Una matriz de ejemplo se muestra en la Figura 28-2 .

Figura 28‐2: Consolidado Gaps, soluciones y Matrix Dependencias

28.3 Arquitectura Definición Incrementos Tabla La técnica de creación de una tabla de incrementos de definición de la arquitectura permite al arquitecto para planear una serie de Transición Arquitecturas esbozar el estado de la arquitectura de la empresa en los momentos especificados. Una tabla debe elaborarse, como se muestra en la Figura 28-3 , que enumera los proyectos y la asignación de sus entregas incrementales a través de las arquitecturas de transición.

Figura 28‐3: Incrementos de Arquitectura definición de la tabla Página 301 de 670


   28.4 Transición Arquitectura Estado Tabla de la Evolución La técnica de creación de la tabla de transición Architecture Evolution Estado permite que el arquitecto que muestra el estado de las arquitecturas propuestas en varios niveles utilizando el Modelo de Referencia Técnica (TRM). Una tabla debe ser dibujada, una lista de los servicios de la TRM se utiliza en la empresa, las arquitecturas de transición, y las transformaciones propuso, como se muestra en la Figura 28-4 . Todos los bloques de construcción de la solución (SBB) deben ser descritos con respecto a su entrega y el impacto en estos servicios. También deben estar marcados para mostrar el progreso de la arquitectura empresarial. En el ejemplo, donde se ha alcanzado la capacidad objetivo, esto se muestra como "nuevos" o "retener"; donde la capacidad es la transición a una nueva solución, esta se marca como "de transición"; y donde una capacidad va a ser reemplazado, esta se marca como "sustituir".

Figura 28‐4: Arquitectura de transición de estados Tabla Evolution Otra técnica (no mostrado aquí) es el uso de la codificación de color en la matriz; por ejemplo: 

Verde: Servicio de SBB en su lugar (ya sea nuevo o retenido).



Amarillo: Servicio realiza la migración a una nueva solución.



Rojo: Servicio a sustituir.

Página 302 de 670


28.5 Evaluación del Valor de Negocio Técnica Una técnica para evaluar el valor del negocio es la elaboración de una matriz basada en una dimensión índice de valor y una dimensión de índice de riesgo. Un ejemplo se muestra en la Figura 28-5 . El índice de valor debe incluir criterios tales como el cumplimiento de los principios, la contribución financiera, la alineación estratégica, y la posición competitiva. El índice de riesgo debería incluir criterios tales como el tamaño y la complejidad, la tecnología, la capacidad de organización, y el impacto de un fracaso. A cada criterio se le debe asignar un peso individual. El índice y sus criterios y ponderación deben ser elaborados y aprobados por la alta dirección. Es importante establecer los criterios para la toma de decisiones antes de conocer las opciones.

Figura 28‐5: Ejemplo de Evaluación de Proyectos con respecto a los negocios de valor y de Riesgo

Página 303 de 670


29. Requisitos de interoperabilidad Este capítulo proporciona directrices para la definición y el establecimiento de requisitos de interoperabilidad.

29.1 Información general Una definición de la interoperabilidad es "la capacidad de compartir información y servicios". Definir el grado en que la información y los servicios han de ser compartidos es un requisito arquitectónico de gran utilidad, sobre todo en una organización compleja y / o de la empresa extendida. La determinación de la interoperabilidad está presente en todo el Método de desarrollo de la arquitectura () de la siguiente manera: 

En el Architecture Vision (Fase A), la naturaleza y las consideraciones de seguridad de los intercambios de información y de servicios se reveló por primera vez dentro de los escenarios de negocio.



En la arquitectura de negocios (Fase B), los intercambios de información y de servicios se definen más en términos de negocio.



En la arquitectura de datos (fase C), el contenido de los intercambios de información se detallan el uso de los datos de la empresa y / o modelo de intercambio de información.



En se especifica la arquitectura de la aplicación (fase C), la forma en que las distintas aplicaciones son para compartir la información y los servicios.



En la arquitectura de la tecnología (Fase D), se especifican los mecanismos técnicos adecuados que permitan el intercambio de información y servicios.



En Oportunidades y Soluciones (Fase E), se seleccionan las soluciones reales (por ejemplo, paquetes de Commercial Off-The-Shelf (COTS)).



En planeamiento de migración (Fase V), la interoperabilidad es implementado con lógica.

29.2 Definición de Interoperabilidad Hay muchas maneras de definir la interoperabilidad y el objetivo es definir una que se aplicará de manera uniforme dentro de la empresa y de la empresa extendida. Lo mejor es que tanto la empresa y la empresa extendida usan las mismas definiciones. Muchas organizaciones consideran que es útil para categorizar la interoperabilidad de la siguiente manera: 

Operacional o de negocios Interoperabilidad define cómo los procesos de negocio han de ser compartidos.



Información sobre interoperabilidad define cómo es la información para ser compartida.

Página 304 de 670


Interoperabilidad Técnica define cómo los servicios técnicos han de ser compartidos o al menos conectar entre sí.

Desde una perspectiva de TI, sino que también es útil tener en cuenta la interoperabilidad en una línea similar a la Integración de Aplicaciones Empresariales (EAI);específicamente: 

Presentación de integración / interoperabilidad es que un enfoque común look-and-feel través de una solución de portal común guía al a la funcionalidad subyacente del conjunto de sistemas.



Integración de la Información / Interoperabilidad es donde la información corporativa está perfectamente compartida entre las distintas aplicaciones de la empresa para lograr, por ejemplo, un conjunto común de información del cliente. Normalmente, esto se basa en una ontología corporativa comúnmente aceptado y servicios compartidos para la estructura, la calidad, el y la seguridad / privacidad de la información.



Integración de Aplicaciones / Interoperabilidad es donde la funcionalidad corporativa está integrada y compartida de modo que las aplicaciones no están duplicados (por ejemplo, un cambio de servicio de dirección / componente; no una para cada aplicación) y están perfectamente conectados entre sí a través de la funcionalidad como el flujo de trabajo. Esto afecta a las aplicaciones de negocio y de infraestructura, y está muy estrechamente vinculados a las empresas de procesos de negocio unificación / la interoperabilidad.



Técnica de integración / interoperabilidad incluye métodos comunes y servicios compartidos para la comunicación, el almacenamiento, el procesamiento y el a los datos sobre todo en la plataforma de aplicaciones y dominios de la infraestructura de comunicaciones. Esta interoperabilidad se basa en el grado de racionalización de la infraestructura de TI de la empresa, sobre la base de normas y / o plataformas comunes. Por ejemplo, varias aplicaciones compartiendo una infraestructura o 10.000 sitios web corporativos mediante uno de gestión de contenidos / servidor web centralizado (en lugar de miles de servidores y extienden por todo el país / mundo).

Muchas organizaciones crean sus propios modelos de interoperabilidad, como se ilustra en el siguiente ejemplo del Gobierno de Canadá. Tienen una definición de alto nivel de las tres clases de interoperabilidad e identificar la naturaleza de la información y servicios que desean compartir. La interoperabilidad se acuñó en términos de los facilitadores electrónicos para la eistración. Su desglose interoperabilidad es el siguiente: 



Información sobre interoperabilidad: o

Gestión del conocimiento

o

La inteligencia empresarial

o

Gestión de la información

o

Identidad de confianza

Interoperabilidad del comercio: o

Redes de entrega

Página 305 de 670




o

e-Democracia

o

e-Business

o

Gestión de recursos empresariales

o

Gestión de las relaciones y el caso

Interoperabilidad Técnica: o

Infraestructura de TI

En ciertos enfoques arquitectónicos, tales como sistema de sistemas o un modelo federado, la interoperabilidad es una práctica muy recomendable que va a determinar cómo los sistemas interactúan entre sí. Una consideración clave será el modelo operativo de negocio de la empresa.

29.3 Empresa Modelo Operativo La clave para el establecimiento de la interoperabilidad es la determinación del modelo de funcionamiento empresarial, donde el modelo de funcionamiento es "el nivel necesario de la integración de procesos de negocio y la normalización para la entrega de los bienes y servicios a los clientes. Un modelo operativo se describe cómo una empresa quiere prosperar y crecer. Por proporcionando una visión más estable y procesable de la empresa de estrategia, el modelo operativo impulsa el diseño de la base para su ejecución. " 1 Por ejemplo, si las líneas de unidades de negocio o comerciales sólo necesitan compartir documentos, la Arquitectura y Soluciones Building Blocks (ABBS y SBB) puede ser más sencillo que si hay una necesidad de compartir datos de transacciones estructuradas. Del mismo modo, si el Architecture Vision incluye un entorno de servicios compartidos, entonces es útil para definir el nivel de los servicios que se van a compartir. El modelo de funcionamiento empresarial normalmente indica qué tipo de enfoque de interoperabilidad será apropiado. Este modelo debe ser determinado en la Fase A (Architecture Vision) si no está en la Fase B (Arquitectura de negocios), y, definitivamente, por la Fase E (Oportunidades y Soluciones). Empresas complejas y / o las empresas extendidas (por ejemplo, la cadena de suministro) pueden tener más de un tipo de modelo de funcionamiento. Por ejemplo, es común para el modelo de funcionamiento interno (y apoyar modelo de interoperabilidad) a diferir de la utilizada para la empresa extendida.

29.4 Interoperabilidad Refinación La implementación de la interoperabilidad requiere de la creación, la gestión, la aceptación y cumplimiento de las normas realistas que sean SMART (específicos, mensurables, acciones concretas, realistas y de duración determinada). Medidas claras de interoperabilidad son clave para el éxito. La arquitectura es la clave para la identificación de las normas y sesiones facilitadas (lluvia de ideas), examinará posibles formas pragmáticas (que caben dentro de la cultura empresarial actual o emergente) para alcanzar el grado requerido de interoperabilidad.

Página 306 de 670

The Open Group Architecture Framework TOGOF 9.1   La interoperabilidad debe ser refinado para que cumpla con las necesidades de la empresa y / o empresa extendida de una manera inequívoca. Las medidas de interoperabilidad refinados (grados, tipos y objetivos de alto nivel) deben ser parte de o remitirse a la dirección estratégica de la arquitectura empresarial. Estas medidas se crean instancias dentro de una estrategia de transformación que deben ser incrustado dentro de la definición de la arquitectura de destino y pragmáticamente a cabo en el Arquitecturas Transición. Al finalizar, también actualizar los resultados del análisis de brecha consolidados y dependencias para asegurarse de que todas las pepitas de brainstorming son capturados. Un ejemplo de la especificación de interoperabilidad es el grado de interoperabilidad (utilizados en el Departamento de la Defensa Nacional y la OTAN canadiense). Estas organizaciones se han centrado en el intercambio de información y se acercó con cuatro grados de interoperabilidad de la siguiente manera: 

Grado 1: No estructurado de intercambio de datos implica el intercambio de datos no estructurados-humanos interpretable, como el texto libre que se encuentra en las estimaciones operacionales, análisis y documentos.



Grado 2: Structured Data Exchange implica el intercambio de datos estructuradoshumanos interpretable destinados manual y / o tratamiento automatizado, pero requiere de la compilación manual, la recepción y / o envío de mensajes.



Grado 3: Distribución transparente de datos implica el intercambio automático de datos entre los sistemas basados en un modelo de intercambio común.



Grado 4: Distribución transparente de la Información es una extensión de grado 3 a la interpretación universal de la información a través del procesamiento de datos basada en aplicaciones de co-operación.

Estos títulos deben ser perfeccionado y hecho técnicamente significativo para cada uno de los grados. Un ejemplo refinamiento de grado 3 con cuatro subclasificaciones sigue: 

3A: Formal de mensajes de Exchange



3B: Intercambio de datos comunes



3C: Completa el intercambio de datos



3D: en tiempo real de intercambio de datos

El propósito es especificar los grados detallados de interoperabilidad al nivel requerido de detalle de manera que sean técnicamente significativa. Estos grados son muy útiles para especificar la forma en que la información debe ser intercambiada entre los distintos sistemas y proporcionar orientación crítica a los proyectos de ejecución de los sistemas. Medidas similares se deben establecer para determinar el servicio / negocio y la interoperabilidad técnica.

Página 307 de 670


29.5 Determinación de los requisitos de interoperabilidad La coexistencia entre los países emergentes y los sistemas existentes, sobre todo durante la transformación, será un gran desafío y de intercambio de ideas debe tratar de averiguar lo que hay que hacer para reducir el dolor. Es imperativo involucrar al personal y los arquitectos de gestión de las operaciones en este paso, ya que será responsable de la operación de los entregables de la cartera. Por ejemplo, puede haber una necesidad de una aplicación de "contenedor" (una aplicación que actúa como interfaz [intérprete alias] entre el uso de la herencia y de la infraestructura emergente). De hecho, pragmáticamente, en el "si funciona, no lo arregles" mundo, el "envoltorio" podría llegar a ser una solución permanente. En cualquier caso, el uso de los resultados de análisis de carencias y escenarios de negocio como una fundación, una lluvia de ideas de los problemas de TI y trabajar a través de ellos para asegurarse de que todas las respuestas estén claramente identificadas y tratadas y verificar que se cumplan los requisitos específicos de la organización. Es importante señalar que el proceso de desarrollo posterior debe incluir el reconocimiento de las dependencias y los límites de las funciones y debe tener en cuenta qué productos están disponibles en el mercado. Un ejemplo de cómo esto puede ser expresado se puede ver en el ejemplo de bloques de construcción (véase la Parte III , 37.Building Blocks ). Si se utiliza un mecanismo como los grados de interoperabilidad, a continuación, una matriz que muestra los requisitos de interoperabilidad es una herramienta útil, como se ilustra en la Figura 291 y Figura 29-2 , y señaló que el grado de intercambio de información no es necesariamente simétrica o bidireccional entre los sistemas y / o grupos de interés. La siguiente matriz se puede utilizar dentro de la empresa y / o dentro de la empresa extendida como una forma de detallar que la información y / o servicios pueden ser compartidos. La matriz debe comenzar en la Arquitectura de Negocios (Fase B) para capturar la naturaleza del intercambio de información entre las partes interesadas, y evolucionar para determinar la cuota de lo que los sistemas de información que en la Fase C.

Figura 29‐1: Business Information Matriz de interoperabilidad

Página 308 de 670

The Open Group Architecture Framework TOGOF 9.1   La figura 29-1 muestra que los grupos de interés requiere un intercambio estructurado de datos (nivel 2) con los interesados / Sistemas B y D, y el intercambio fluido de datos (grado 3) con las partes interesadas / Sistemas C, E, F y G. La matriz de interoperabilidad de la información del negocio debe ser refinado dentro de la arquitectura de sistemas de información utilizando medidas refinados y especificando los sistemas actuales utilizados por los grupos de interés. Un ejemplo se muestra en la Figura 29-2 .

Figura 29‐2: Sistemas de Información Matriz de interoperabilidad En la Figura 29-2 , tanto la naturaleza del cambio es más detallada (por ejemplo, Grado 3A frente único grado 3) y el intercambio entre los sistemas específicos en lugar de las partes interesadas. Por ejemplo, la información de las acciones del Sistema de A con los demás sistemas de conformidad con las normas técnicas de la empresa. En muchas organizaciones las arquitecturas empresariales describen la naturaleza de la información compartida entre las partes interesadas y / u organizaciones (por ejemplo, en defensa del término es "nodo operativo"), y la arquitectura de datos especifica la información que se comparte entre los sistemas. Actualizar los datos de destino definido y Arquitectura de la aplicación (versión 1.0) con los problemas de interoperabilidad que se plantearon.

29.6 Requisitos de Conciliación de interoperabilidad con las soluciones potenciales El arquitecto de la empresa tendrá que asegurarse de que no hay conflictos de interoperabilidad, sobre todo si existe la intención de reutilizar SBB y / o cunas existentes. La cuestión más importante a abordar es, de hecho, la interoperabilidad empresarial. La mayoría de SBB o COTS tendrán sus propios procesos empresariales incrustados.El cambio de los procesos de negocio integrados menudo requerirá mucho trabajo, que se perderán las ventajas de las soluciones de reutilización de. Hay numerosos ejemplos de esto en el pasado. Además, no es el aspecto de flujo de trabajo entre los diversos sistemas que tiene que ser tomada en cuenta. El arquitecto de la empresa tendrá que asegurarse de que cualquier cambio en los

Página 309 de 670

The Open Group Architecture Framework TOGOF 9.1   requisitos de interoperabilidad de negocios está firmado por los arquitectos comerciales y patrocinadores de arquitectura en una declaración revisada de Arquitectura Obra.

29.7 Resumen Definición de interoperabilidad de forma clara e inequívoca en varios niveles (negocio / servicio, la información, y técnicos) es una herramienta de planificación de la arquitectura de utilidad. Las nociones de interoperabilidad serán cada vez más importante en la arquitectura orientada a servicios (SOA), donde los servicios serán compartidos internamente y externamente en las empresas cada vez más interdependientes extendidas.



Página 310 de 670


30. Evaluación de la preparación de transformación de negocios En este capítulo se describe una técnica conocida como Evaluación de la preparación de transformación de negocios, que se utiliza para evaluar y cuantificar la disposición de una organización a sufrir modificaciones. En este capítulo se basa en el trabajo por la de su Programa de capacitación de la transformación del negocio (BTEP) Gobierno Canadiense y. 1

30.1 Introducción Arquitectura empresarial es una tarea importante dentro de una organización y la mayoría de las veces un innovador Architecture Vision (Fase A) y apoyando Definición Arquitectura (Fases B a D) supondrá un cambio considerable. Hay muchas dimensiones de cambiar, pero con mucho, el más importante es el elemento humano. Por ejemplo, si la empresa prevé una consolidación de las explotaciones de la información y el paso a un nuevo paradigma como la orientación de servicios para la prestación de servicios integrados, entonces las consecuencias para los recursos humanos son importantes. Potencialmente, junto con una cultura de cambio adverso y una fuerza de trabajo por poco calificada, la arquitectura más sólida y innovador podría ir a ninguna parte. La comprensión de la disposición de la organización para aceptar el cambio, la identificación de los problemas, y luego tratar con ellos en la Implementación y planes de migración es clave para la transformación lograda arquitectura en las fases E y F. Este será un esfuerzo conjunto entre las empresas (especialmente los recursos humanos) personal, líneas de negocio, y los planificadores de TI. Las actividades recomendadas en una evaluación de la preparación de la organización para hacer frente a la transformación del negocio son: 

Determinar los factores de preparación que tendrán impacto en la organización



Presentar los factores de preparación para el uso de modelos de madurez



Evaluar los factores de preparación, incluida la determinación de las calificaciones de los factores de preparación



Evaluar los riesgos para cada factor de preparación e identificar acciones de mejora para mitigar el riesgo



El trabajo de estas acciones en la Fase E y F Implementación y Plan de Migración

30.1.1 Programa de capacitación de la transformación del negocio (BTEP) El Programa de capacitación de la transformación del negocio Gobierno canadiense (BTEP) se proporciona orientación sobre la manera de identificar las cuestiones relacionadas con la transformación de los negocios.

Página 311 de 670

The Open Group Architecture Framework TOGOF 9.1   El BTEP recomienda que todos los proyectos llevan a cabo una evaluación de la preparación de transformación, al menos, descubrir los problemas de transformación empresarial. Esta evaluación se basa en la determinación y el análisis / calificación de una serie de factores de preparación. El resultado es una mayor comprensión de los desafíos y oportunidades que se podrían presentar en el transcurso de la tarea. Muchos de los desafíos que se traducen directamente en los riesgos que tienen que ser abordados, supervisado, y, si es posible, mitigados. Las siguientes secciones describen Evaluación de la preparación de transformación de negocios usando el método BTEP, incluyendo algunas de las lecciones aprendidas.Los lectores deben tener en cuenta que la mayoría de las organizaciones tienen su propio conjunto único de factores y criterios, pero la mayoría son similares.

30.2 Determinar los factores de Preparación El primer paso es determinar qué factores tendrán un impacto en la transformación de los negocios asociados a la migración desde la línea de base a Target Arquitecturas. Esto puede lograrse mejor a través de la realización de un taller dirigido a personas de diferentes partes de la organización. Es importante que todas las perspectivas son buscados como se variarán los temas. En este taller, es muy útil empezar con una lista tentativa de los factores que los participantes puedan reutilizar, rechazar, aumentar o reemplazar. Un ejemplo conjunto de factores extraídos de la BTEP sigue: 

Visión es la capacidad de definir y comunicar lo que se quiere lograr con claridad. Aquí es donde la gestión es capaz de definir con claridad los objetivos, tanto en términos estratégicos y específicos. El liderazgo en la definición de la visión y necesidades proviene de la parte comercial de IT de entrada. Existen procesos predecibles y probadas para pasar de la visión a la exposición de las necesidades. Los principales impulsores de la iniciativa son claros. El alcance y el enfoque de la iniciativa de transformación se han definido claramente en toda la organización.



Deseo, Voluntad, y resolver es la presencia de un deseo de alcanzar los resultados, la disposición a aceptar el impacto de hacer el trabajo, y la decisión de seguir adelante y completar la tarea. Hay una discusión activa sobre el impacto que la ejecución del proyecto pueda tener en la organización, con indicación clara de la intención de aceptar las consecuencias. Recursos clave (por ejemplo, financieros, humanos, etc) se asignan para el esfuerzo y los altos ejecutivos proyectar el mensaje claro de que la organización va a seguir adelante; un mensaje que identifica el esfuerzo, así como los beneficios. Vista organizativo hay antecedentes de terminar lo que está en marcha y de llegar a un cierre en temas en los plazos necesarios y hay un consenso en toda la organización que la iniciativa de transformación es la cosa "correcta" de hacer.



Necesita , en que hay una necesidad imperiosa de ejecutar la tarea. Hay declaraciones claras en cuanto a lo que la organización no va a ser capaz de hacer si el proyecto no avanza, y las declaraciones igualmente claras de lo que el proyecto permitirá a la organización a hacer. Hay consecuencias visibles y ampliamente entendido de criterios de fallo esfuerzo y éxito han sido claramente identificada y comunicada.



Caso de Negocio existe eso crea un fuerte enfoque en el proyecto, la identificación de los beneficios que se deben alcanzar y creando con ello un imperativo para tener éxito. El documento de modelo de negocio identifica beneficios concretos (ingresos o ahorros) que

Página 312 de 670

The Open Group Architecture Framework TOGOF 9.1   la organización se compromete a entregar y con claridad y, sin duda, los puntos a los objetivos que la organización se ha comprometido a lograr. 

La financiación , en forma de una clara fuente de recursos fiscales, existe que cumple una inversión potencial del emprendimiento.



Patrocinio y Liderazgo existe y es ampliamente compartido, pero no tan amplio como para difundir la rendición de cuentas. Liderazgo mantiene a todos "a bordo" y mantiene todas ellas centradas en los objetivos estratégicos. El esfuerzo es patrocinado por un ejecutivo que está alineado adecuadamente para proporcionar el liderazgo de las necesidades empeño y capaz de articular y defender las necesidades de la empresa a nivel de la alta dirección. Estos patrocinadores ejecutivos son y seguirán siendo participar en todo.



Gobernabilidad es la capacidad de involucrar a la participación y el apoyo de todas las partes con un interés o responsabilidad de la empresa con el objetivo de garantizar que se sirven a los intereses corporativos y los objetivos alcanzados. Es evidente que hay grupos de interés identificados y un sentido claro de su interés y responsabilidad con el proyecto; una cultura que fomenta la participación hacia objetivos corporativos en lugar de locales; una historia de ser capaces de gestionar con éxito las actividades que cruzan áreas de interés; una cultura que fomenta significativa, en comparación con simbólica, la participación en los procesos de gestión; y un compromiso de constante revisión y desafío y la apertura a asesoramiento externo del proyecto.



Responsabilidad es la asignación de responsabilidades específicas y apropiadas, el reconocimiento de las expectativas medibles por todas las partes interesadas, y la alineación de la toma de decisiones con áreas de responsabilidad y con el lugar donde se sentirá el impacto de las decisiones. Rendición de cuentas está alineada con la zona en la que se harán sentir los beneficios del éxito o consecuencias del fracaso del esfuerzo, así como con las áreas de responsabilidad.



Enfoque y Ejecución Modelo realizable es un enfoque que tiene sentido en relación con la tarea, con un ambiente de apoyo, el modelo de un método de probada eficacia. Hay nociones claras del cliente y del cliente papel en relación con el constructor o contratista principal y la organización tiene experiencia con los esfuerzos de este tipo para que los procesos, las disciplinas, los conocimientos y la gobernabilidad ya están en marcha, probado y disponible para aplicar para el esfuerzo de transformación. Todos los jugadores saben su papel porque los han jugado antes con éxito. En particular, las funciones de "cliente" y "constructor de sistemas" son maduros y estables. Hay un plan de comunicación que cubren todos los niveles de la organización y la satisfacción de las necesidades que van desde la conciencia de la disponibilidad de los detalles técnicos. Hay una recompensa y el plan de reconocimiento en lugar de reconocer los equipos y los individuos que utilizan buenas prácticas de gestión del cambio, la planificación y la prevención de conductas de crisis, y que reforzar las conductas apropiadas para la nueva forma de hacer negocios. Es claro para todos cómo se producirá la aplicación, cómo va a ser monitoreada, y cómo las acciones reajuste se hará y hay suficientes recursos dedicados a la vida de la transformación.



Capacidad de TI para ejecutar es la capacidad de realizar todas las tareas de TI que requiere el proyecto, incluyendo las habilidades, herramientas, procesos y capacidad de gestión. Ha habido una reciente ejecución exitosa de un esfuerzo similar de tamaño y complejidad similar y existen procesos adecuados, la disciplina, las habilidades, y un modelo justificación para decidir qué habilidades y actividades a la fuente externa.

Página 313 de 670


Empresa capacidad de ejecución es la capacidad de la empresa para llevar a cabo todas las tareas requeridas por la empresa, en áreas fuera de las TI, incluyendo la capacidad de tomar decisiones dentro de las limitaciones de tiempo típicos para entornos basados en la reciente ejecución exitosa de un proyecto similar esfuerzo de por lo menos la mitad del tamaño y complejidad. Existen procesos no-IT-específicos, disciplina y habilidades para hacer frente a este tipo de esfuerzo. La empresa tiene una capacidad demostrada para tratar con el tipo de problemas de gestión de la cartera en curso / proyecto y los requisitos. Hay un reconocimiento de la necesidad de conocimientos y desarrollo de habilidades para la nueva forma de trabajar, así como el valor de un análisis de las deficiencias formales sobre las capacidades y comportamientos.



Capacidad empresarial para implementar y operar los elementos de transformación y de sus procesos de negocio relacionados, absorber los cambios derivados de la aplicación, y la capacidad continua para operar en el nuevo entorno. La empresa tiene una capacidad probada recientemente para hacer frente a los problemas de gestión de cambios derivados de nuevos procesos y sistemas y que ha establecido un programa sólido y disciplinado proceso impulsado por los servicios de gestión que facilite las operaciones, el mantenimiento y el apoyo a los sistemas existentes.

Una vez que se han identificado y definido los factores, es útil para llamar a un taller de seguimiento en donde se evaluarán los factores con más detalle en términos de su impacto / riesgo. En la siguiente sección se ocupará de la preparación para una evaluación eficaz de estos factores.

30.3 Factores de preparación actuales Una vez que se determinan los factores, es necesario presentar de una manera tal que la evaluación es clara y el valor máximo se deriva de los participantes. Uno de tales presentación es a través del uso de modelos de madurez. Si cada factor se convierte en un modelo de madurez (un activo reutilizable gobierno también) acompañado de una plantilla de hoja de cálculo estándar que contiene toda la información y las deducciones que deben ser reunidos, puede ser una herramienta muy útil. El modelo de madurez debe permitir a los participantes: 

Evalúe su (Arquitectura de referencia) nivel de madurez actual



Determinar el nivel de madurez de destino que tendría que ser alcanzado a darse cuenta de la arquitectura destino



Determine un objetivo intermedio que serían realizables en un plazo menor

El cuidado empleado en la preparación de los modelos (que no es insignificante) será recuperado por un taller enfocado que rápidamente pasará a través de un número importante de factores. Es importante que cada factor sea bien definido y que el alcance de la empresa de arquitectura empresarial (planificación preliminar) se reflejarán en los modelos para mantener a los participantes del taller enfocado y productivo.

Página 314 de 670

The Open Group Architecture Framework TOGOF 9.1   Circulación de los modelos antes del taller para los comentarios sería útil, aunque sólo sea para asegurarse de que están completos, así como permitir a los participantes a prepararse para el taller. Tenga en cuenta que el modelo que figura a continuación también ha estado objetivo recomendado realizado por el arquitecto empresarial; esta vez actúa como gobierno. Un ejemplo de un modelo de madurez se muestra en la Figura 30-1 para uno de los factores BTEP:

Figura 30‐1: Negocio Evaluación de la preparación de Transformación ‐ Modelo de Madurez

30.4 Evaluar los factores de Preparación Lo ideal es que los factores deben ser evaluados en un taller multidisciplinario. El uso de un mecanismo como modelos de madurez, arquitectos de la empresa normalmente tiene que cubrir una gran cantidad de terreno en poco tiempo. El uso de una serie de plantillas para cada factor aceleraría la evaluación, y garantizar la coherencia entre la amplia gama de factores. La evaluación debe abordar tres cosas, a saber: 

Factor de Preparación Vision



Factor de Preparación Clasificación



Factor de Preparación Riesgos y Acciones

30.4.1 Factor de Preparación Vision La visión de un factor de disposición es la determinación de cuando la empresa tiene que evolucionar para abordar el factor. En primer lugar, el factor debe evaluarse con respecto a su estado base y entonces su estado de destino.

Página 315 de 670

The Open Group Architecture Framework TOGOF 9.1   Por ejemplo, si la "capacidad de TI para ejecutar" factor se califica como baja, el factor debe estar preferentemente a "alto" para realizar el objetivo Architecture Vision. Un objetivo intermedio podría ser útil para dirigir la puesta en práctica. Los modelos de madurez son excelentes vehículos para guiar a esta determinación.

30.4.2 Factor de Preparación Clasificación Una vez establecidas las visiones de los factores, entonces es útil para determinar la importancia de cada factor es a la consecución de la arquitectura destino, así como lo difícil que será para migrar el factor en un estado visionario aceptable. El BTEP utiliza un esquema de preparación de Calificación que puede ser utilizado como un punto de inicio para cualquier organización en cualquier vertical. Cada uno de los factores de preparación son clasificados con respecto a: 

Urgencia , de forma que si un factor de disposición es urgente, que significa que es necesario actuar antes de que pueda comenzar una iniciativa de transformación.



Estado de disponibilidad , que está clasificado como sea baja (necesita trabajo importante antes de proceder), Feria (necesita un poco de trabajo antes de proceder), aceptable (existen algunos problemas de preparación, no hay motivos para desistir), Bueno (existen cuestiones relativamente menores) o Alta (sin preparación cuestiones).



Grado de dificultad para corregir las tasas de esfuerzo requerido para superar los problemas identificados como bien No Acción Necesaria, Fácil, Moderado o Difícil.

Aunque una plantilla más amplia se puede utilizar en el taller, es útil para crear una tabla resumen de los resultados de consolidar los factores y ofrecer una visión de gestión. Un resumen como se muestra en la Figura 30-2 .

Figura 30‐2: Cuadro Resumen de Evaluación de la preparación de transformación de negocios Página 316 de 670

The Open Group Architecture Framework TOGOF 9.1   30.4.3 Factor de Preparación Riesgos y Acciones Una vez que los factores han sido valorados y evaluados, se derivan una serie de acciones que permitan a los factores de cambiar a un estado favorable. Cada factor debe evaluarse en relación con el riesgo de utilizar el proceso de relieve en la parte III , 31. Gestión de Riesgos , que incluye una estimación del impacto y frecuencia. Cada factor debe ser evaluado de forma discreta y una serie de acciones de mejora se indica. Antes de comenzar de nuevo, las acciones existentes descritos en las arquitecturas deben ser revisados antes de crear otros nuevos. Estas acciones recientemente identificados deben luego ser incorporados formalmente a la Implementación emergentes y Plan de Migración. Desde una perspectiva de riesgo, estas acciones están diseñadas para mitigar los riesgos y producir un riesgo residual aceptable. Como riesgos, deben ser parte del proceso de gestión de riesgos y un estrecho seguimiento como se está implementando la arquitectura empresarial.

30.5 Preparación y planeamiento de migración El ejercicio de evaluación proporcionará una evaluación realista de la organización y será un aporte importante para la planificación de la migración estratégica que se inició en la fase E y se terminó en Fase F. Es importante tener en cuenta si las acciones de transformación de negocio estarán en la visión de ruta crítica y, de ser así, determinar cómo van a afectar a la ejecución. No tiene sentido el despliegue de nueva capacidad de TI sin empleados formados para ello y apoyar al personal listo para sostenerlo. Los factores de preparación, como parte de una implementación global y el Plan de Migración, tendrán que ser supervisados de forma continua (Fase G) y las acciones correctivas rápidas tomadas a través del marco de gobierno de TI para asegurar que las arquitecturas definidas se pueden implementar. La evaluación de los factores de preparación será un documento vivo y durante la planificación y ejecución de las arquitecturas de Transición de migración, las actividades de transformación empresarial desempeñará un papel clave.

30.6 La comercialización del Plan de Implementación La definición de la arquitectura no debe ser ampliamente difundido hasta que los problemas de transformación de negocio sean identificados y mitigados, y acciones parte asociada de un plan general de "marketing" para la visión y la aplicación y el Plan de Migración. Por ejemplo, la concentración parcelaria de la información podría resultar en cientos de puestos de trabajo perdidos y esta visión no debe ser anunciado antes de que un plan de recursos de la transformación del negocio / humanos de apoyo está formulado para una nueva formación o apoyar los esfuerzos de los trabajadores para el nuevo empleo. Los talleres de transformación de negocio son una parte fundamental del Plan de Comunicación mediante el cual los individuos clave dentro de la organización se reúnen para evaluar las

Página 317 de 670

The Open Group Architecture Framework TOGOF 9.1   consecuencias de la transformación de la empresa. Para ello van a tomar conciencia de la Arquitectura Visión y definición de la arquitectura (si no estaban ya involucrados a través de los escenarios de negocios y Arquitectura de Negocios). Este grupo se sentirá la propiedad de la arquitectura de la empresa, el reconocimiento de la EA como mayordomo valioso. Su determinación de los factores que volverá a crear una cultura de entendimiento entre la empresa y proporcionar información útil para la aplicación y el Plan de Migración. Este último plan debe incluir un plan de comunicación, sobre todo para mantener al personal afectado informado. En muchos casos, la colaboración con los sindicatos y delegados sindicales asistirá nuevamente a una transición integridad personal (y pacífica) al estado de destino.

30.7 Conclusión En resumen, la implementación de arquitectura empresarial requiere un profundo conocimiento y la conciencia de toda la transformación del negocio los factores que impactan la transición al estado visionario. Con la evolución de las TI, la tecnología actual no es el verdadero problema más en la arquitectura de la empresa, pero los factores críticos son más a menudo las culturales. Cualquier aplicación y el Plan de Migración tiene que tener tanto en cuenta. Descuidar estos y centrándose en los aspectos técnicos, invariablemente resultará en una aplicación mediocre que no llega a darse cuenta de la verdadera promesa de un visionario de arquitectura empresarial.

Página 318 de 670


31. Gestión de Riesgos En este capítulo se describe la gestión del riesgo, que es una técnica que se utiliza para mitigar el riesgo en la aplicación de un proyecto de arquitectura.

31.1 Introducción Siempre habrá riesgo con cualquier esfuerzo de transformación arquitectura / negocio. Es importante identificar, clasificar y mitigar estos riesgos antes de empezar, para que puedan realizar un seguimiento durante todo el esfuerzo de transformación. La mitigación es un esfuerzo en curso y, a menudo los factores desencadenantes de riesgo puede estar fuera del alcance de los planificadores de transformación (por ejemplo, la fusión, de adquisición) para los planificadores deben monitorear el contexto de transformación constante. También es importante señalar que la empresa arquitecto puede identificar los riesgos y mitigar ciertas personas, pero está dentro del marco de gobernanza que los riesgos tienen que ser primero aceptado y luego logró. Hay dos niveles de riesgo que deben ser considerados, a saber:

1. Nivel Inicial del Riesgo : categorización del riesgo antes de determinar e implementar acciones de mitigación. 2. Nivel Residual de Riesgo : categorización del riesgo después de la implementación de medidas de mitigación (si los hay). El proceso para la gestión de riesgos se describe en las siguientes secciones y consta de las siguientes actividades: 

La clasificación de riesgo



Identificación de riesgos



Evaluación del riesgo inicial



La mitigación del riesgo y evaluación del riesgo residual



Seguimiento del riesgo

31.2 Clasificación de Riesgo El riesgo es omnipresente en cualquier actividad arquitectura de la empresa y está presente en todas las fases en el desarrollo de métodos de Arquitectura (). Desde una perspectiva de gestión, es útil para clasificar los riesgos para que la mitigación de los riesgos se puede ejecutar con la mayor rapidez posible.

Página 319 de 670

The Open Group Architecture Framework TOGOF 9.1   Una forma común de riesgos para ser clasificado es con respecto al impacto sobre la organización (como se explica en 31.4 Evaluación del riesgo inicial ), por el cual los riesgos con ciertos impactos tienen que ser abordadas por ciertos niveles de gobernanza. Los riesgos se clasifican normalmente como el tiempo (horario), el costo (presupuesto), y alcance, sino que también podrían incluir riesgos de relación de transformación de cliente, los riesgos contractuales, riesgos tecnológicos, riesgos alcance y complejidad, los riesgos ambientales (de empresa), los riesgos del personal, y la aceptación del cliente riesgos. Otra forma de delegar la gestión de riesgos es clasificar aún más los riesgos de los dominios de la arquitectura. La clasificación de los riesgos como los negocios, la información, las aplicaciones y la tecnología es útil, pero puede haber formas organizativo-específicas de expresar el riesgo de que la empresa corporativa arquitectura dirección debe adoptar o ampliar en lugar de modificar. En última instancia, la arquitectura riesgos de la empresa son los riesgos corporativos y deben clasificarse y según proceda manejadas en el mismo o prolongado camino.

31.3 Identificación de Riesgos Las evaluaciones de preparación y transformación de vencimiento generarán una gran cantidad de riesgos. Identificar los riesgos y determinar la estrategia para hacer frente a ellos a través de la transformación. El uso de Modelos de Madurez de Capacidad (CMM) es adecuada para los factores específicos asociados con la entrega de la arquitectura para identificar primera referencia y objetivos estados y luego identificar las acciones necesarias para pasar al estado de destino. Las consecuencias de no alcanzar el estado de destino pueden resultar en el descubrimiento de los riesgos. Consulte 30. Transformación del Negocio Evaluación de preparación para los detalles específicos. Documentación de riesgos se realiza en el contexto de un Plan de Gestión de Riesgos, para los que existen plantillas en las metodologías de gestión de proyectos estándar (por ejemplo, gestión de proyectos libro del conocimiento y PRINCE2), así como con las diferentes metodologías de gobierno. Normalmente estas metodologías implican procedimientos para la planificación de contingencia, el seguimiento y la evaluación de los niveles de riesgo; reaccionar a los cambios en factores de nivel de riesgo, así como los procesos de documentación, información y comunicación de los riesgos a los interesados.

31.4 Evaluación del riesgo inicial El siguiente paso consiste en clasificar los riesgos con respecto a los efectos y frecuencia de acuerdo con los baremos empleados dentro de la organización. Combine efecto y la frecuencia para llegar a una evaluación preliminar del riesgo. No hay reglas duras y rápidas con respecto a los efectos y frecuencia de medición. Las siguientes directrices se basan en las mejores prácticas de gestión de riesgos existentes. efecto podría ser evaluada utilizando los siguientes criterios de ejemplo:

Página 320 de 670


Catastrófico infiere la pérdida financiera crítica que podría resultar en la quiebra de la organización.



Crítica infiere graves pérdidas económicas en más de una línea de negocio que lleva a una pérdida de la productividad y no retorno de la inversión en la inversión en TI.



Marginal infiere una pérdida financiera de menor importancia en una línea de negocio y un retorno de la inversión en la reducción de la inversión en TI.



Insignificante infiere un impacto mínimo en una línea de negocio 'capacidad de prestar servicios y / o productos.

Frecuencia podría indicarse como sigue: 

Frecuente : Probabilidad de que ocurra muy a menudo y / o de manera continua.



Probable : ocurre varias veces en el transcurso de un ciclo de transformación.



Ocasionales : Ocurre esporádicamente.



Rara vez : remotamente posible y probablemente se produciría no más de una vez en el curso de un ciclo de transformación.



Improbable : probablemente no ocurrir durante el curso de un ciclo de transformación.

La combinación de los dos factores para inferir el impacto se llevará a cabo utilizando una heurística basada en el esquema de clasificación pero consistente para los riesgos. Un esquema de potencial para evaluar el impacto corporativa podría ser como sigue: 

Extremadamente Alto Riesgo (E) : El esfuerzo de transformación lo más probable es un error con consecuencias graves.



Riesgo alto (H) : insuficiencia significativa de partes del esfuerzo de transformación que resulta en ciertas metas no están alcanzados.



Riesgo Moderado (M) : insuficiencia notoria de partes del esfuerzo de transformación que amenaza el éxito de ciertas metas.



Riesgo bajo (L) : Ciertas metas no serán un éxito completo.

Estos impactos se pueden derivar utilizando un esquema de clasificación, como se muestra en la Figura 31-1 .

Página 321 de 670

The Open Group Architecture Framework TOGOF 9.1   Figura 31‐1: Esquema de Clasificación de Riesgo

31.5 Mitigación de Riesgos y Evaluación de Riesgo Residual La mitigación del riesgo se refiere a la identificación, planificación y ejecución de acciones que reduzcan el riesgo a un nivel aceptable. El esfuerzo de mitigación podría ser un sistema de seguimiento y / o simple aceptación del riesgo para un plan de contingencia en toda regla llamando para la redundancia completa en un Plan de Continuidad de Negocio (con todo el alcance de dicha reglamentación, el coste y las implicaciones de tiempo). Debido a las implicaciones de esta evaluación de riesgos, tiene que llevarse a cabo de una manera pragmática, pero sistemática. Con prioridad va a riesgos de alto impacto frecuentes, cada riesgo debe ser mitigado a su vez.

31.6 Conducta Evaluación del Riesgo Residual Una vez que el esfuerzo de mitigación se ha identificado para cada uno de los riesgos, re-evaluar el efecto y la frecuencia y luego volver a calcular los impactos y ver si el esfuerzo de mitigación realmente ha hecho una diferencia aceptable. Los esfuerzos de mitigación suelen consumir muchos recursos y un desembolso importante para poco o ningún riesgo residual debe ser impugnada. Una vez que se mitiga el riesgo inicial, entonces el riesgo que queda se llama el "riesgo residual". La consideración clave es que el esfuerzo atenuante reduce realmente el impacto empresarial y no sólo pasar el riesgo a otra igualmente alto cuadrante. Por ejemplo, cambiar el riesgo de frecuentes / catastrófico frecuentes / crítico todavía ofrece un extremadamente de riesgo elevado. Si esto ocurre, entonces el esfuerzo de mitigación tiene que ser re-examinado. El entregable final debe ser una evaluación del riesgo de transformación que podría ser estructurado como una hoja de cálculo, como se muestra en la Figura 31-2 .

Figura 31‐2: Ejemplo de Identificación de Riesgos y Mitigación Hoja de evaluación

Monitoreo 31.7 Riesgos y Gobierno (Fase G) Los riesgos residuales tienen que ser aprobados por el marco de gobierno de TI y, potencialmente, en el gobierno corporativo, donde se requiere la aceptación comercial de los riesgos residuales.

Página 322 de 670

The Open Group Architecture Framework TOGOF 9.1   Una vez que se han aceptado los riesgos residuales, la ejecución de las acciones de mitigación tiene que ser controlada cuidadosamente para asegurarse de que la empresa está tratando con residual en lugar de riesgo inicial. Las hojas de trabajo de evaluación de la identificación y mitigación de riesgos se mantienen como los artefactos de gobierno y se mantienen al día en la Fase G (Gobernanza Aplicación) donde se lleva a cabo el seguimiento del riesgo. Gobernabilidad implementación puede identificar los riesgos críticos que no están siendo mitigados y podrían requerir otro ciclo total o parcial.

31.8 Resumen Gestión de riesgos es una parte integral de la arquitectura empresarial. Se anima a los profesionales a utilizar su metodología de gestión de riesgos corporativos o ampliarlo mediante la orientación de este capítulo. En ausencia de una metodología corporativa formal, los arquitectos pueden utilizar las instrucciones de este capítulo como una buena práctica.

Página 323 de 670


32. Planificación de Capacidad basada en Este capítulo proporciona una visión general de la planificación basada en la capacidad, una técnica de planificación de negocios que se centra en los resultados de negocio.También arregla bien con la fricción de coordinar proyectos a través de dominios funcionales empresariales que en conjunto permiten a la empresa para lograr esa capacidad (por ejemplo, la prestación de servicios electrónicos).

32.1 Información general Planificación basada en la capacidad se centra en la planificación, la ingeniería, y la entrega de las capacidades estratégicas de negocio para la empresa. Es impulsada por los negocios y las empresas dirigidas y combina los esfuerzos necesarios de todas las líneas de negocio para alcanzar la capacidad deseada. Planificación basada en la capacidad de alojar la mayoría, si no todos, de los modelos de negocio de las empresas y es especialmente útil en las organizaciones donde se requiere una capacidad latente para responder (por ejemplo, una unidad de preparación para emergencias) y los mismos recursos están implicados en múltiples capacidades. A menudo, lanecesidad de que estas capacidades se descubrió y perfeccionó el uso de escenarios de negocios (véase la Parte III , 26. Escenarios empresariales y objetivos de la empresa ). Desde una perspectiva de TI, la planificación basada en la capacidad es particularmente relevante. Por ejemplo, la creación de un centro de datos es realmente acerca de la consolidación de los datos corporativos y de la prestación de los servicios relacionados. Arquitectos de la empresa de entrega para esta capacidad se verán involucrados en la gestión de la construcción, la capacitación del personal, y otras tareas de gestión del cambio, así como las tareas de arquitectura de TI. En el pasado, muchos proyectos de TI fueron menos de éxito a pesar de la implementación de TI real era brillante, pero las otras tareas asociadas (proceso de reingeniería de negocios, formación de clientes, apoyo a la formación, las infraestructuras, etc) fueron no controlados por la empresa arquitectos y planificadores ya menudo no se completaron satisfactoriamente. Por otra parte, los proyectos de TI a menudo se describen en términos de prestaciones técnicas y no como resultados de negocio, lo que hace difícil para las empresas para apreciar lo que se está entregando ya menudo los arquitectos de TI perdió de vista el objetivo empresarial fundamental. Marcos de planificación basado en la capacidad de todas las fases del desarrollo de la arquitectura en el contexto de los resultados del negocio, vinculando claramente la visión de TI, arquitecturas (ABBS y SBB), y la aplicación y los planes de migración con la estratégica corporativa, de negocios, y la línea de planes de negocios. En muchos gobiernos, la interoperabilidad horizontal y servicios compartidos se perfilan como piedras angulares de sus implementaciones de e-gobierno y la gestión basada en la capacidad es también prominente aunque bajo muchos disfraces. En el sector privado, los conceptos de gestión de la cadena de suministro y la Arquitectura Orientada a Servicios (SOA) están obligando cada vez más planificadores / gestores de gobernar tanto horizontal como verticalmente.

32,2 capacidad basada en Planificación Paradigma Planificación basada en la capacidad de mucho tiempo se ha afianzado en el ámbito de Defensa de los EE.UU., Reino Unido, Australia y Canadá. Los mecanismos de gobernanza asociados, así

Página 324 de 670

The Open Group Architecture Framework TOGOF 9.1   como la capacidad de derivación rigurosa (ingeniería de la capacidad), están surgiendo sobre todo en el dominio de la ingeniería de sistemas.Estos conceptos son fácilmente transferibles a otros ámbitos, como el de TI.

32.3 Concepto de Planificación de Capacidad basada en De una arquitectura empresarial y la perspectiva de TI, la planificación basada en la capacidad es un poderoso mecanismo para asegurar que el plan estratégico de negocios conduce la empresa desde un enfoque de arriba hacia abajo. También es adaptable a la ingeniería la capacidad de aprovechar las innovaciones emergentes de abajo hacia arriba. No importa cómo las estructuras de la corporación en sí , tendrá que hacer frente a la entrega de capacidades de negocio cuya entrega se requerirá la coordinación y la alineación a través de verticales de negocio. Las capacidades son los negocios impulsados y lo ideal sería impulsado por las empresas. Uno de los principales retos es que los beneficios son recogidos muy a menudo en la empresa y no la línea de nivel de negocios. En consecuencia, los proyectos dentro de la línea de carteras de negocios dirigidas tienden a adoptar una línea de negocio en lugar de la perspectiva empresarial. Gestión de la entrega de una capacidad es un reto, pero el afianzamiento de una perspectiva basada en la capacidad de una organización es un poderoso mecanismo para proporcionar un valor comercial derivado sinérgica que resonará en la rentabilidad y el valor de las acciones. Capacidades deben especificarse utilizando la misma disciplina en la especificación de los objetivos como en los escenarios de negocio; concretamente, se deben seguir las pautas de SMART para evitar ambigüedades. Como se muestra en la Figura 32-1 , muchas capacidades son "horizontal" y van a contrapelo de gobierno corporativo vertical normal. Muy a menudo, la gestión de la dirección, así como el marco de rendición de cuentas de gestión empresarial se basan en la línea de las métricas de negocio, no métricas empresariales. Arquitectura empresarial es también una función horizontal que se ve a nivel de empresa (así como la línea de nivel empresarial) la optimización y la prestación de servicios. Como era de esperar, la planificación basada en la capacidad y la arquitectura de la empresa se apoyan mutuamente. Ambos suelen operar contra la corriente corporativa y ambos tienen que hacer frente a entornos empresariales exigentes. Apoyo a las empresas de arquitectura de la empresa es crucial para su éxito y es lógico que se alinea con los planificadores de capacidad de las empresas, así como proporcionar apoyo a las personas dentro de las líneas verticales de negocio.

Página 325 de 670


Figura 32‐1: Concepto de planificación basado en capacidad Las capacidades también pueden ser verticales y manejado en el contexto de la estructura de organización de negocios. De hecho, los requisitos de capacidad a menudo conducen el diseño organizacional, pero dentro de una organización en el proceso de transformación de la empresa, la organización pueden estar detrás de las necesidades de capacidad. Capacidades verticales son más fáciles de manejar y el apoyo de la función de la arquitectura empresarial, pero todavía desafiante cuando los servicios se racionalizan a nivel de empresa y de las líneas de negocio reciben servicios compartidos que no controlan directamente (proporcionan un control indirecto a través de la gobernanza de TI en el Consejo de Arquitectura tal como fue creado en la planificación preliminar y se utiliza en la fase G (Gobernanza de Implementación). Para la planificación basada en la capacidad de tener éxito, tiene que ser controlada con respecto a las dimensiones y los incrementos, tal como se explica en las dos secciones siguientes.

32.3.1 Capacidad Dimensiones Las capacidades están diseñadas / generan teniendo en cuenta las diversas dimensiones que se sitúan en las carteras funcionales corporativas. Cada organización tiene un conjunto de dimensiones diferentes pero similares. Un ejemplo de ajuste (con base en el Departamento de Defensa Nacional de Canadá) podría incluir personal, investigación y desarrollo, infraestructura / instalaciones, conceptos / procesos, gestión de la información y material. Lo que se seleccionan las dimensiones, deben ser bien explicadas y entendidas.

Página 326 de 670


Figura 32‐2: Incrementos de Capacidad y Dimensiones 32.3.2 Los incrementos de capacidad Una capacidad se llevará un tiempo prolongado para entregar (detalles estarán en función de la organización y de la industria vertical) y participará normalmente muchos proyectos que entregan numerosos incrementos. Además, la capacidad debe proporcionar un valor empresarial real a los interesados lo antes posible y mantener el impulso para lograr el Objetivo de Arquitectura, así como el apoyo ejecutivo asociado y la financiación de las empresas. Por lo tanto, es útil para romper la capacidad en incrementos de capacidad que permitan conseguir resultados discretos, visibles y cuantificables, así como proporcionar el foco para la Transición Arquitecturas y los entregables de numerosos proyectos interdependientes. Estos resultados son los factores críticos de éxito (CSF) para apoyo constante capacidad. Comunicar la potencialmente compleja evolución incremental de una capacidad de la comunidad de partes interesadas es esencial para establecer un buy-in en el inicio y para mantener su buy-in durante la transición. El Incremento de Capacidad diagrama "Radar" (ver Figura 32-3 ) es un método de probada eficacia para describir cómo una capacidad evolucionará con el tiempo. El arquitecto selecciona los aspectos de capacidad que son importantes para la comunidad de interesados como las líneas que irradian desde el centro. Contra cada línea, el arquitecto dibuja puntos que representan importantes "puntos de capacidad" (puntos de "inferiores" de capacidad más cercanas al centro, "superior" puntos de capacidad más lejanos del centro). Con estos "marcadores" en su lugar el arquitecto puede, uniendo los puntos de capacidad en un circuito cerrado, demostrar de una forma sencilla cómo cada "incremento de capacidades" se extenderá sobre el incremento anterior. Esto, por supuesto, requiere que cada punto de la capacidad se define formalmente y "etiqueta" de una manera que tenga sentido para los grupos de interés. En el siguiente diagrama, que hemos representado Capacidad Incremento 0 como la capacidad de arranque.

Página 327 de 670


Figura 32‐3: Incremento de Capacidad "Radar"

32.4 Capacidades en un Contexto de Arquitectura Empresarial Las capacidades se derivan directamente de la plan estratégico corporativo por los planificadores estratégicos corporativos que son y / o incluyen los arquitectos de la empresa y satisfacer las metas de la empresa, objetivos y estrategias. La mayoría de las organizaciones también tendrán un plan de negocios anual que describe cómo la organización tiene la intención de continuar durante el próximo ejercicio fiscal con el fin de cumplir con los objetivos estratégicos de la empresa. La figura 32-4 ilustra las relaciones cruciales entre la planificación basada en la capacidad, la arquitectura empresarial y gestión de la cartera / del proyecto. Por el lado de la mano izquierda, la gestión de la capacidad está alineada con la arquitectura empresarial. La clave es que todas las arquitecturas se expresará en términos de resultados empresariales y de valor más que en términos de TI (por ejemplo, el establecimiento de una granja de servidores), asegurando así la alineación de TI con el negocio. La intención es que la dirección estratégica corporativa impulsa la visión de la Arquitectura en la Fase A, así como la organización de la empresa, que será la base para la creación de carteras. Las capacidades específicas dirigidas para la finalización será el tema central de la definición de la arquitectura (las fases B, C y D) y, en base a la labor mencionadapaquetes, se concibieron proyectos Fase E.

Página 328 de 670

The Open Group Architecture Framework TOGOF 9.1   Los incrementos de capacidad serán los controladores para las arquitecturas de transición (Fase E) que estructurarán los incrementos de los proyectos. La entrega real será coordinado a través de la aplicación y los planes de migración (Fase F).

Figura 32‐4: Relación Entre Capacidades, Arquitectura Empresarial y Proyectos Gerentes de capacidad al desarrollo de tareas similares a las de los gestores de carteras, pero a través de las carteras de la alineación de los proyectos y los incrementos del proyecto para entregar valor de negocio continuo. Considerando que los gestores de cartera se ocupará de la coordinación de sus proyectos para diseñar de manera óptima, construir y entregar los bloques de construcción de la solución (SBB). Lo ideal sería que los es de capacidad también gestionarán los fondos que pueden utilizar las arquitecturas de transición como puertas. La coordinación entre la cartera y los es de capacidad tendrá que ser proporcionada a nivel corporativo.

32.5 Resumen Planificación basada en la capacidad es un paradigma de la planificación empresarial versátil que es muy útil desde el punto de vista de arquitectura empresarial. Ayuda a la alineación de TI con el negocio y ayuda a los arquitectos de TI se centran en la creación continua de valor para el negocio.

Página 329 de 670


PARTE IV Marco de Arquitectura de contenido

Página 330 de 670


33. Introducción 33.1 Información general Arquitectos ejecutar el método de Desarrollo Arquitectura () producirán una serie de resultados, como resultado de sus esfuerzos, como los flujos de procesos, requisitos arquitectónicos, planes de proyectos, evaluaciones de cumplimiento de proyectos, etc El marco de contenido proporciona un modelo estructural para el contenido arquitectónico que permite a los principales productos de trabajo que un arquitecto crea que definirse constantemente, estructurada y presentada. El marco de contenido proveído aquí tiene por objeto permitir TOGAF para ser utilizado como un marco independiente para la arquitectura dentro de una empresa. Sin embargo, existen otros marcos de contenido (como el Marco Zachman) y se prevé que algunas empresas pueden optar por usar un marco externo en conjunto con TOGAF.En estos casos, el marco de contenido proporciona una referencia útil y punto de partida para el contenido TOGAF estar asignada a otros marcos. La Arquitectura del marco de contenido usa las siguientes tres categorías para describir el tipo de producto de trabajo de arquitectura dentro del contexto de uso: 

Un entregable es un producto de trabajo que se especifica y, a su vez revisado formalmente, de acuerdo, y firmado por las partes interesadas contractualmente.Entregables representan la salida de los proyectos y los resultados que se tenga en forma de documentación serán típicamente archivadas en la finalización de un proyecto, o la transición hacia un repositorio arquitectura como un modelo de referencia, estándar o instantánea de la arquitectura del paisaje en un punto en el tiempo.



Un artefacto es un producto del trabajo arquitectónico que describe un aspecto de la arquitectura. Los artefactos se clasifican generalmente como catálogos (listas de cosas), matrices (que muestran las relaciones entre las cosas), y diagramas (imágenes de las cosas). Los ejemplos incluyen un catálogo de necesidades, matriz de interacción de negocios, y un diagrama de casos de uso. Un entregable arquitectónica puede contener muchos objetos y artefactos formarán el contenido de la Arquitectura Repository.



Un bloque de construcción representa un (potencialmente reutilizable), componente de negocio, TI, o la capacidad de la arquitectura que se puede combinar con otros bloques de construcción para ofrecer arquitecturas y soluciones. Bloques de construcción se pueden definir en varios niveles de detalle, dependiendo de la etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una etapa temprana, un bloque de construcción puede consistir simplemente en un nombre o una breve descripción. Más tarde, un bloque de construcción se puede descomponer en varios bloques de edificios de apoyo y puede ir acompañada de una especificación completa. Bloques de construcción pueden relacionarse con "arquitecturas" o "soluciones". o

Arquitectura Bloques de Construcción (Abs) suelen describir la capacidad requerida y dar forma a la especificación de soluciones de Bloques de Construcción (SBB). Por ejemplo, una capacidad de servicio al cliente puede ser

Página 331 de 670

The Open Group Architecture Framework TOGOF 9.1   necesaria dentro de una empresa, con el apoyo de muchos SBB, como los procesos, datos y software de aplicación. o

Solución Building Blocks (SBB) representan los componentes que se utilizarán para implementar la capacidad requerida. Por ejemplo, una red es un bloque de construcción que se puede describir a través de artefactos complementarios y luego objeto de un uso para darse cuenta de las soluciones para la empresa.

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

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

Página 332 de 670


Figura 33‐2: Ejemplo ‐ Arquitectura de definición de documento

33.2 Metamodel contenido El metamodelo de contenidos proporciona una definición de todos los tipos de bloques de construcción que puedan existir dentro de una arquitectura, que muestra cómo estos bloques de construcción pueden ser descritos y relacionados entre sí. Por ejemplo, al crear una arquitectura , un arquitecto identificará las aplicaciones, "entidades de datos", realizado dentro de las aplicaciones y tecnologías que implementan esas aplicaciones. Estas aplicaciones serán a su vez apoyar a determinados grupos de s de negocios o actor, y se utilizarán para cumplir con los "servicios empresariales". El metamodelo contenido identifica todas estas preocupaciones (es decir, la aplicación, entidad de datos, tecnología, actor, y servicios empresariales), muestra las relaciones posibles entre ellos (por ejemplo, los actores consumen servicios de negocios), y, finalmente, identifica los artefactos que se pueden utilizar para que los represente. La Figura 33-3 muestra una visión general del metamodelo contenido.

Página 333 de 670


Figura 33‐3: Contenido Metamodel Información general

33.3 Marco de Contenido y el TOGAF El TOGAF describe el proceso de pasar de un estado de la línea de base de la empresa a un estado objetivo de la empresa. El se abordará una necesidad de negocio a través de un proceso de la visión, la definición de la arquitectura, la planificación de la transformación, y la gobernanza de la arquitectura. En cada etapa de este proceso, el requiere información como entradas y salidas creará como resultado de la ejecución de un número de pasos. El marco de contenido proporciona una estructura subyacente para el que define las entradas y salidas con más detalle y pone cada resultado en el contexto de la vista de la arquitectura global de la empresa. Por tanto, el marco de contenidos debe ser utilizado como un complemento de la . El se describe lo que hay que hacer para crear una arquitectura y el marco de contenido describe lo que la arquitectura debe ser similar, una vez que se hace.

33.4 Estructura de la Parte IV Parte IV: Arquitectura del marco de contenido está estructurado de la siguiente manera: 

Introducción (este capítulo)

Página 334 de 670


Metamodel contenido (véase 34. Metamodel contenido )



Architectural Artifacts (ver 35. Architectural Artifacts )



Arquitectura Entregables (ver 36. Arquitectura entregables )



Bloques de construcción (ver 37. Building Blocks )

Página 335 de 670


34. Metamodel contenido

34.1 Información general La Arquitectura Método de Desarrollo de TOGAF () brinda un ciclo de vida de procesos para crear y gestionar arquitecturas dentro de una empresa. En cada fase dentro de la , una discusión de entradas, salidas, y los pasos se describen una serie de productos o artefactos de trabajo de arquitectura, como proceso y aplicación. El metamodelo contenido proveído aquí define una estructura formal de estos términos para garantizar la coherencia dentro de la y también para proporcionar una guía para las organizaciones que desean implementar su arquitectura dentro de una herramienta de arquitectura.

34.2 Contenido Metamodel Visión y Conceptos Esta sección proporciona una visión general de los objetivos del metamodelo contenido, los conceptos que sustentan el metamodelo, y una visión general de la propia metamodelo. En las secciones siguientes y luego ir a discutir cada área del metamodelo con más detalle. Contenido de esta sección son los siguientes: 



Conceptos del metamodelo de contenido básico (ver 34.2.1 Conceptos básicos Metamodel contenido ) identifica los conceptos clave dentro del metamodelo contenido básico, que incluye: o

Core y contenido extensión

o

Modelado formal e informal

o

Entidades metamodelo Core

o

Catálogo, matriz, y el concepto de diagrama

Información general sobre el contenido metamodelo TOGAF (ver 34.2.2 Descripción general del Metamodel contenido ) proporciona una visión general de alto nivel del contenido del metamodelo.

34.2.1 Conceptos básicos Metamodel contenido A TOGAF arquitectura se basa en la definición de una serie de bloques de construcción de arquitectura dentro de la arquitectura catálogos, especificando las relaciones entre esos bloques de construcción de matrices de arquitectura, y luego la presentación de los diagramas de comunicación que muestran de una manera precisa y concisa lo que la arquitectura es. En esta sección se presentan los conceptos principales que conforman el contenido metamodelo TOGAF, a través de los siguientes apartados:

Página 336 de 670


Core y Extensión de contenido proporciona una introducción a la forma en que TOGAF emplea un metamodelo núcleo básico y luego se aplica una serie de módulos de extensión para abordar los problemas arquitectónicos específicos en más detalle.



Entidades Metamodel Core introduce las centrales entidades metamodelo TOGAF, que muestra el propósito de cada entidad y las relaciones claves que apoyan la trazabilidad arquitectónico.



Catálogo, Matrix, y árbol conceptual describe el concepto de catálogos, matrices y diagramas.

Core y Contenido de Extensión

El papel de TOGAF es proporcionar un estándar abierto para la arquitectura, que es aplicable en muchos escenarios y situaciones. Con el fin de cumplir con esta visión, es necesario proporcionar una completa empresa metamodelo arquitectura destacado de contenido y también para proporcionar la capacidad de evitar la realización de actividades innecesarias mediante el apoyo a la adaptación. El metamodelo debe proporcionar un modelo básico con el conjunto mínimo de características y luego apoyar la inclusión de extensiones opcionales durante el enganche sastrería. El núcleo TOGAF contenido metamodelo y sus extensiones se ilustran en la Figura 34-1 .

Figura 34‐1: TOGAF Metamodel contenido y sus extensiones El metamodelo núcleo proporciona un conjunto mínimo de contenido arquitectónico para apoyar la trazabilidad a través de artefactos. Conceptos adicionales metamodelo para apoyar el modelado más específico o más detallado están contenidas dentro de un grupo de extensiones que los catálogos lógicamente racimo de extensión, matrices y diagramas, lo que permite el enfoque en áreas de interés y el enfoque específico.

Página 337 de 670

The Open Group Architecture Framework TOGOF 9.1   Todos los módulos de extensión son opcionales y deben seleccionarse durante la Etapa Preliminar del desarrollo de la arquitectura para satisfacer las necesidades de la organización. Además, los grupos de extensión descritos por el metamodelo contenido son sólo una sugerencia y, además de sastrería se pueden llevar a cabo para adaptarse a las necesidades específicas a la discreción de los arquitectos. Este núcleo y el concepto de extensión se pretende como un paso hacia el apoyo a los enfoques de extensión de métodos formales dentro TOGAF, tales como el método de plug-in concepto que se encuentra dentro del Proceso de Ingeniería de Software Metamodel (SPEM) desarrollado por el Object Management Group (OMG). 1 Entidades Metamodel Core

El metamodelo de contenido utiliza la terminología debatido en el TOGAF como base para un metamodelo formal. Se utilizan los siguientes términos básicos: 

Actor : Una persona, organización o sistema que está fuera de la consideración del modelo de arquitectura, sino que interactúa con él.



Componente de aplicación : Una encapsulación de funcionalidad de la aplicación que está alineado con la estructuración de la implementación.



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



Entity Data : Una encapsulación de datos que es reconocido por un experto dominio del negocio como un concepto discreto. Entidades de datos pueden estar vinculados a las aplicaciones, repositorios y servicios y pueden ser estructurados de acuerdo con las consideraciones de implementación.



Función : Proporciona capacidades de negocio estrechamente alineadas a una organización, pero no rige explícitamente por la organización.



Servicio de Sistema de Información : Los elementos automáticos de un servicio empresarial. Un servicio del sistema de información puede ofrecer o apoyar la totalidad o parte de uno o varios servicios de oficina.



Unidad de Organización : Una unidad autónoma de los recursos con las metas, objetivos y medidas. Unidades organizativas pueden incluir partes externas y las organizaciones asociadas de negocios.



Plataforma de Servicios : Una capacidad técnica requerida para proporcionar la infraestructura que permite que apoya la entrega de aplicaciones.



Rol : Un actor asume un papel para realizar una tarea.



Componente Tecnología : Una encapsulación de la infraestructura de tecnología que representa una clase de producto de la tecnología o producto de tecnología específica.

Una definición más detallada de los términos utilizados en el metamodelo contenido se puede encontrar en la parte I , 3. Definiciones .

Página 338 de 670

The Open Group Architecture Framework TOGOF 9.1   Algunos de los conceptos clave relacionados con la relación de las entidades metamodelo fundamentales se describen a continuación: 

Proceso normalmente debe ser usado para describir el flujo de Un proceso es un flujo de interacciones entre las funciones y servicios, y no se puede implementar físicamente. Todos los procesos deben describir el flujo de ejecución de una función y, por tanto, el despliegue de un proceso es a través de la función que soporta; es decir, una aplicación implementa una función que tiene un proceso, no una aplicación implementa un proceso.



Función describe unidades de capacidad de negocio en todos los niveles de granularidad El término "función" se utiliza para describir una unidad de capacidad de negocio en todos los niveles de granularidad, encapsulando términos tales como cadena de valor, área de proceso, la capacidad, la función empresarial, etc Cualquier unidad acotado de la función empresarial debe ser descrito como una función.



Servicios a empresas apoyan los objetivos organizacionales y se definen a un nivel de granularidad en consonancia con el nivel de la gobernabilidad necesaria Un servicio de negocio opera como un límite para una o más funciones. La granularidad de los servicios de negocio depende del enfoque y el énfasis de la empresa (como se refleja en sus controladores, metas y objetivos). Un servicio en la Arquitectura Orientada a Servicios (SOA) terminología (por ejemplo, una unidad de despliegue de la funcionalidad de la aplicación) es en realidad mucho más cerca de un servicio de aplicación, componente de la aplicación o componente de tecnología, lo que puede implementar o apoyar a un servicio de negocio.



Servicios a empresas se han desplegado en los componentes de aplicaciones Servicios a empresas puedan ser realizados por la actividad empresarial que no se refiere a él, o pueden ser apoyados por TI. Servicios a empresas que son apoyados por TI se despliegan en los componentes de la aplicación. Componentes de aplicación se pueden descomponer jerárquicamente y pueden soportar uno o más servicios de oficina. Es posible que un servicio de negocio a ser apoyado por múltiples componentes de la aplicación, pero esto es problemático desde el punto de vista de la gobernabilidad y es sintomático de servicios a las empresas que son demasiado grano grueso, o componentes de aplicaciones que son demasiado fino.



Los componentes de aplicación se despliegan en los componentes tecnológicos Un componente de la aplicación se lleva a cabo por un conjunto de componentes de tecnología. Por ejemplo, una aplicación, como "Sistema de Recursos Humanos" normalmente se llevaría a cabo en varios componentes de la tecnología, incluyendo el hardware, el software de servidor de aplicaciones y servicios de aplicación.

La figura 34-2 ilustra las entidades centrales y sus relaciones.

Página 339 de 670


Figura 34‐2: Las entidades centrales y sus relaciones Catálogo, Matriz y Diagrama Concept

El metamodelo de contenido se utiliza como una técnica para estructurar la información de arquitectura de una forma ordenada de manera que se puede procesar para satisfacer las necesidades de los interesados. La mayoría de los grupos de interés de arquitectura en realidad no necesita saber lo que la arquitectura metamodelo es y sólo se preocupan de temas específicos, tales como "¿Qué funcionalidad de este soporte de aplicaciones?", "Qué procesos se verán afectadas por este proyecto? ", etc Con el fin de satisfacer las necesidades de estos grupos de interés, se utilizan los conceptos TOGAF de bloques de construcción, catálogos, matrices y diagramas. Bloques de construcción son entidades de un tipo particular en el metamodelo (por ejemplo, un servicio de negocio llamado "Orden de Compra"). Bloques de construcción llevan metadatos según el metamodelo, que apoya la consulta y análisis. Por ejemplo, los servicios de negocios tienen un atributo de metadatos para el propietario, el cual permite que un grupo de interés para consultar todos los servicios a las empresas de propiedad de una organización en particular. Bloques de construcción también pueden incluir las entidades dependientes o contenidos, según corresponda al contexto de la arquitectura (por ejemplo, un servicio de negocio llamado "Orden de Compra" puede incluir implícitamente una serie de procesos, entidades de datos, componentes de la aplicación, etc.) Los catálogos son listas de bloques de construcción de un tipo específico, o de que lo incluya, que se utilizan para los propósitos de gobierno o de referencia (por ejemplo, un organigrama, que

Página 340 de 670

The Open Group Architecture Framework TOGOF 9.1   muestra la ubicación y los actores). Al igual que con bloques de construcción, catálogos llevan metadatos según el metamodelo, que apoya la consulta y análisis. Las matrices son redes que muestran las relaciones entre dos o más entidades de modelo. Las matrices se utilizan para representar las relaciones que son basados en la lista en lugar de gráfica en su uso (por ejemplo, una matriz que muestra qué aplicaciones CRUD crear, leer, actualizar y eliminar un determinado tipo de datos es difícil de representar visualmente). Los diagramas son representaciones de contenido arquitectónico en un formato gráfico para permitir a las partes interesadas para recuperar la información requerida.Diagramas también se pueden utilizar como una técnica para poblar gráficamente contenido de arquitectura o para comprobar la integridad de la información que se ha recogido. TOGAF define un conjunto de diagramas de arquitectura que se creen (por ejemplo, el organigrama). Cada uno de estos diagramas se pueden crear varias veces para una arquitectura con un estilo diferente o la cobertura de contenido de acuerdo a las preocupaciones de las partes interesadas. Bloques de construcción, catálogos, matrices y diagramas son conceptos que están bien apoyados por los principales herramientas de arquitectura empresarial. En los entornos donde se utilizan herramientas para modelar la arquitectura, estas herramientas suelen apoyar mecanismos para buscar, filtrar y consultar la Arquitectura Repository. Consultas a petición del Repositorio Arquitectura (como el ejemplo de la propiedad de servicio de negocio se ha mencionado anteriormente) se puede utilizar para generar ad hoc, catálogos, matrices y diagramas de la arquitectura. Como este tipo de consulta es, por naturaleza, exige ser flexible, es, por tanto, no se limita o define dentro del metamodelo contenido. Las interacciones entre bloques metamodelo, construcción, diagramas, y las partes interesadas se muestran en la Figura 34-3 .

Página 341 de 670


Figura 34‐3: Interacciones entre Metamodel, bloques de construcción, diagramas, y las partes interesadas 34.2.2 Descripción general del Metamodel contenido El metamodelo de contenido define un conjunto de entidades que permiten a los conceptos arquitectónicos que se capturen, almacenen, se filtró, consultan, y se representan en una manera que apoye la consistencia, integridad y trazabilidad. Al más alto nivel, el marco de contenido se divide de acuerdo con las fases TOGAF , como se muestra en la Figura 34-4 .

Página 342 de 670

The Open Group Architecture Framework TOGOF 9.1   Figura 34‐4: Contenido Marco por Fases   

Principios Arquitectura, Visión y Requerimientos artefactos están destinados a captar el contexto que lo rodea de modelos de arquitectura formales, incluyendo los principios generales de arquitectura, el contexto estratégico que constituye la entrada para el modelado de la arquitectura, y los requisitos generados a partir de la arquitectura. El contexto arquitectura típicamente queda recogida en las fases preliminares y Arquitectura de la visión.



Arquitectura Profesiones artefactos captan los modelos arquitectónicos de la operación del negocio, centrándose específicamente en los factores que motivan a la empresa, cómo se estructura organizativamente la empresa, y también lo que las capacidades funcionales de la empresa tiene.



Sistemas de Información Arquitectura modelos artefactos arquitectura de captura de los sistemas de TI, mirando a las aplicaciones y datos de acuerdo con las fases TOGAF .



Arquitectura Tecnología artefactos captura adquirió los activos tecnológicos que se utilizan para poner en práctica y hacer realidad soluciones de sistemas de información.



Arquitectura Realización hojas de ruta del cambio artefactos de captura que muestran la transición entre los estados de arquitectura y estados de enlace que se utilizan para dirigir y gobernar una implementación de la arquitectura.

Una representación más detallada de la metamodelo contenido se muestra en la Figura 34-5 .

Página 343 de 670

The Open Group Architecture Framework TOGOF 9.1   Figura 34‐5: Representación detallada de la Metamodel contenido

34.3 Metamodel contenido al detalle Esta sección contiene los siguientes apartados: 

Metamodel contenido Core (ver 34.3.1 Contenido Core Metamodel ) describe las entidades metamodelo que forman el metamodelo contenido básico.



Artefactos arquitectura de núcleo (véase 34.3.2 Arquitectura del núcleo Artifacts ) enumera el conjunto de artefactos destinados a acompañar el metamodelo contenido básico.



Metamodel contenido completo (véase 34.3.3 completa Metamodel contenido ) describe las entidades metamodelo que forman extensiones al metamodelo contenido.

34.3.1 Contenido Core Metamodel La figura 34-6 muestra las entidades metamodelo y relaciones que están presentes dentro del metamodelo contenido básico.

Figura 34‐6: Entidades y relaciones presentes en el Metamodel contenido Core

Página 344 de 670

The Open Group Architecture Framework TOGOF 9.1   34.3.2 Arquitectura del núcleo Artefactos 35. Architectural Artifacts discute en detalle la forma en que el metamodelo contenido subyacente puede ser utilizado para presentar un conjunto de catálogos, matrices y diagramas para hacer frente a las preocupaciones de las partes interesadas. El siguiente conjunto de artefactos están destinadas a acompañar el metamodelo contenido básico: Fase Preliminar Architecture Vision

Arquitectura de Negocios

Sistemas de Información (Arquitectura de Datos)

Sistemas de Información (Solicitud de Arquitectura)

Arquitectura Tecnología

Oportunidades y Soluciones Gestión de Requisitos

Artefactos Principios Catálogo Stakeholder Mapa Matrix Diagrama de la Cadena de Valor Solución Concepto Diagrama Catálogo Organización / Actor Catálogo de funciones Business Service / Función catálogo Matriz de Interacción de Negocios Matrix Actor / Rol Negocios Huella Diagrama Business Service / Diagrama de Información Diagrama de Descomposición Funcional Diagrama del ciclo de vida del producto Catálogo de Entity Data / componente de datos Entity Data / Matrix Función comercial Aplicación / Data Matrix Diagrama conceptual de datos Diagrama de lógica de datos Diagrama de Divulgación de Datos Catálogo cartera de aplicaciones Catálogo de interfaz Aplicación / Matrix Organización Matrix Papel / Aplicación Matrix Aplicación / Función Aplicación matriz de interacción Aplicación Diagrama Comunicación Solicitud y Ubicación Diagrama Diagrama de Casos de Uso Catálogo de Estándares de Tecnología Catálogo Cartera Tecnológica Aplicación / Matrix Tecnología Entornos y diagrama de las ubicaciones Plataforma Descomposición Diagrama Proyecto Diagrama de Contexto Diagrama de Beneficios Requisitos del catálogo

34.3.3 completa Metamodel contenido Cuando todas las extensiones se aplican al metamodelo contenido básico, se introducen una serie de nuevas entidades metamodelo. Figura 34-7 muestra qué entidades están contenidos en el metamodelo contenido básico y que nuevas entidades se introducen mediante el cual la extensión.

Página 345 de 670


Figura 34‐7: Metamodel contenido con extensiones Las relaciones entre las entidades del metamodelo completo se muestran en la Figura 34-8 .

Página 346 de 670


Figura 34‐8: Las relaciones entre las entidades del metamodelo completo

Página 347 de 670


34.4 Extensiones Metamodel contenido Como se señaló anteriormente, el contenido metamodelo TOGAF es compatible con una serie de módulos de extensión que permiten una reflexión más profunda para las preocupaciones particulares de la arquitectura. Figura 34-9 muestra el metamodelo contenido básico y módulos de extensión predefinidos.

Figura 34‐9: Core Metamodel Contenido y Módulos de Extensión predefinidos Durante la fase de Visión Arquitectura de un compromiso en particular, el alcance del trabajo se puede utilizar para hacer una determinación sobre extensiones adecuadas para ser utilizadas con el fin de abordar adecuadamente los requisitos de arquitectura. Por ejemplo, el alcance de un compromiso podría ser definida como el contenido de núcleo, además de las extensiones de gobierno, como se muestra en la figura 34-10 .

Figura 34‐10: Contenido Core con extensiones de Gobierno Las siguientes secciones proporcionan una descripción más detallada de la finalidad y el contenido de cada uno de los módulos de ampliación.

Página 348 de 670

The Open Group Architecture Framework TOGOF 9.1   34.4.1 Extensiones de Gobierno Propósito

La extensión de gobierno tiene la intención de permitir que los datos estructurados adicionales que se celebrarán con los objetivos y servicios a las empresas, el apoyo a la gobernabilidad operacional del paisaje. El alcance de esta extensión es como sigue: 

La posibilidad de aplicar medidas destinadas a objetivos y vincular estas medidas a los servicios



La capacidad de aplicar los contratos para el servicio de comunicaciones o de servicios de interacción con los s y los sistemas externos



La capacidad de definir calidades de servicio reutilizables definir un perfil de nivel de servicio que se puede utilizar en los contratos



Creación de diagramas adicionales para mostrar la propiedad y gestión de los sistemas

Esta ampliación se debe utilizar en las siguientes situaciones: 

Cuando una organización está considerando cambios de TI que se traducirá en un impacto significativo en los modelos de gobernanza operacionales existentes



Cuando una organización tiene requisitos granulares para los niveles de servicio que difieren de un servicio a otro



Cuando una organización está tratando de transformar su práctica de gobierno operativa



Cuando una organización tiene muy fuerte enfoque en los impulsores del negocio, las metas y objetivos y cómo se traza en los niveles de servicio

Los beneficios de usar esta extensión son los siguientes: 



Los niveles de servicio se definen de una manera más estructurada, con: o

Más detalles

o

La capacidad de reutilizar los perfiles de servicio a través de contratos

o

Más fuerte rastreo de objetivos de negocio

Impactos a las operaciones y modelos de gobernanza operacionales se consideran de una manera más estructurada, con: o

Diagramas adicionales del sistema y los datos de propiedad

o

Diagramas adicionales de funcionamiento del sistema y las dependencias en los procesos de operaciones

Página 349 de 670

The Open Group Architecture Framework TOGOF 9.1   Además de las extensiones descritas aquí, las organizaciones que deseen centrarse en la gobernanza arquitectura también deben consultar: 

El marco COBIT para la gobernanza de TI proporcionados por los Sistemas de Información de Auditoría y Control Association (ISACA); consulte www.isaca.org



El Fondo para el IT Portfolio Management (ITPMF) del OMG; consulte www.omg.org / spec / ITPMF

Cambios necesarios en el Metamodel

Los cambios en las entidades metamodelo y relaciones se muestran en la Figura 34-11 .

Figura 34‐11: Extensiones de Gobierno: Cambios en Metamodel Los cambios en las entidades metamodelo y relaciones son las siguientes:

Página 350 de 670


Medida se añade como una nueva entidad que une objetiva y servicio de negocio.



Calidad de servicio se añade como una nueva entidad que ofrece un servicio de plantilla de perfil genérico que se aplica a los servicios empresariales o contratos.



Contrato se añade como una nueva entidad que formaliza las características funcionales y no funcionales de una interacción de servicio con otros servicios, aplicaciones externas, o los s.

Los cambios en los atributos metamodelo son los siguientes: 

Los atributos se añaden a las nuevas entidades metamodelo de Medida, Calidad de Servicio y Contrato de Servicios

Diagramas adicionales que se creen son los siguientes: 


34.4.2 Servicios Extensiones Propósito

La extensión de los servicios tiene por objeto permitir más sofisticado modelado de la cartera de servicios mediante la creación de un concepto de los servicios es, además del concepto básico de servicios de oficina. SE servicios están soportados directamente por las aplicaciones y la creación de la capa de abstracción relaja las restricciones en los servicios empresariales al tiempo que permite a la vez actores técnicos que ponen más formalidad en un catálogo de servicios de SI. El alcance de esta extensión es como sigue: 

Creación de servicios de SI como una extensión del servicio de negocio


Cuando la empresa tiene una definición preestablecida de sus servicios que no se alinea así con las necesidades técnicas y arquitectónicas



Cuando el negocio y TI utilizan un lenguaje diferente para describir capacidades similares



Cuando el servicio de TI está desalineado con necesidad de negocio, especialmente en torno a las áreas de calidad de servicio, la visibilidad del rendimiento y granularidad de gestión



¿Dónde está tomando las primeras medidas para la participación del comercio en los debates sobre la arquitectura de TI


Servicios de negocios se pueden definir fuera de las limitaciones que existen en el metamodelo básico. Esto permite una participación más natural con accionistas de la empresa.

Página 351 de 670


Servicios de SI pueden ser definidos de acuerdo a un modelo que correlaciona estrechamente con la aplicación, proporcionando una abstracción solución más realista para dar soporte a la toma de decisiones.



Relaciones de servicios de negocios y es muestran donde la vista de negocios se alinea con la vista y donde hay desajustes.

Además de las extensiones descritas aquí, las organizaciones que deseen centrarse en arquitecturas de servicios centrada también deben consultar: 

El Service Component Architecture (SCA) especificación desarrollada por la Arquitectura Orientada a Servicios Abiertos colaboración (OSOA); consulte www.oasis-opencsa.org/sca



Los Service Data Objects (SDO) de la especificación desarrollada por la Arquitectura Orientada a Servicios Abiertos colaboración (OSOA); consulte www.oasisopencsa.org/sdo



Figura 34‐12: Servicios de Extensión: Los cambios en Metamodel Los cambios en las entidades metamodelo y relaciones son las siguientes:

Página 352 de 670


Es el servicio se añade como una nueva entidad metamodelo, extender el servicio de negocio.



ES Servicio hereda todas las relaciones de un servicio de negocio.



Se crea una nueva relación que conecte a un servicio es un servicio de negocio.


Es el servicio se añade como un nuevo tipo de servicio de negocio.


Diagrama de negocios de casos de uso



Organización Descomposición Diagrama

34.4.3 Extensiones de modelado de procesos Propósito

La extensión de modelado de procesos tiene por objeto permitir el modelado detallado de los flujos de procesos mediante la adición de eventos, productos y controles para el metamodelo. Típicamente, arquitectura de la empresa no perforar en el flujo de proceso, pero en ciertas organizaciones proceso-céntrica o-centrado de eventos puede ser necesario para la elaboración de proceso de una manera mucho más formal utilizando este módulo de extensión. El alcance de esta extensión es como sigue: 

Creación de eventos como desencadenantes de procesos



Creación de controles que la lógica de negocio y de gobierno puertas para la ejecución de procesos



Creación de productos para representar la salida de un proceso de



Creación de diagramas de eventos para realizar un seguimiento de los disparadores y los cambios de estado en toda la organización


Cuando la arquitectura debe prestar especial atención a estado y eventos



Cuando se requiera la arquitectura para identificar de manera explícita y medidas de control de proceso de almacenamiento; por ejemplo, para apoyar el cumplimiento regulatorio



Cuando la arquitectura cuenta con críticos o fluye elaborado proceso

Los beneficios de usar esta extensión son los siguientes:

Página 353 de 670


Esta extensión permite el modelado de procesos detallado y la catalogación de los artefactos de proceso.



Puede ser utilizado para apoyar las actividades de cumplimiento normativo.



Se puede utilizar para volver a propósito de la herencia o el análisis de descomposición de procesos no-arquitectónico.

Además de las extensiones descritas aquí, las organizaciones que deseen centrarse en arquitecturas basadas en procesos también deben consultar: 

El Business Process Modeling Notation (BPMN) especificación, proporcionada por el OMG; consulte www.bpmn.org



El Proceso de Ingeniería de Software Metamodel (SPEM) especificación, proporcionada por el OMG; consulte www.omg.org / Spec / SPEM



Figura 34‐13: Proceso Extensiones Modelado: Cambios en Metamodel Los cambios en las entidades metamodelo y relaciones son las siguientes:

Página 354 de 670


Evento se añade como una entidad metamodelo, sentado entre Actor, proceso y servicio



El control se agrega como una entidad metamodelo, relativa a un proceso.



El producto se añade como una entidad metamodelo, vinculando Organización y Procesos.


Los atributos se añaden a las nuevas entidades metamodelo de eventos, control y del producto.


Diagramas de flujo del proceso, que muestran la forma en que las funciones de negocios, eventos, controles y productos están relacionados con apoyar un escenario de negocios en particular



Diagramas de eventos, mostrando los acontecimientos, se que se reciben, y qué procesos se desencadenan

34.4.4 de Extensiones Propósito

La extensión de datos está destinado a permitir el modelado más sofisticado y la encapsulación de datos. El modelo básico ofrece un concepto de entidad de datos que soporta la creación de modelos de datos, que se extendió luego por esta extensión para incluir el concepto de un componente de datos. Los componentes de datos forman un encapsulamiento lógica o física de las entidades de datos abstractos en unidades que pueden ser gobernados y desplegados en las aplicaciones. El alcance de esta extensión es como sigue: 

Creación de componentes de datos lógicos que las entidades de datos de grupo en módulos encapsulados con fines de gobernabilidad, seguridad y despliegue



Creación de componentes físicos de datos que implementan los componentes de datos lógicos y son análogas a las bases de datos, registros, depósitos, esquemas y otras técnicas de segmentación de datos



Creación del ciclo de vida de los datos, seguridad de datos y diagramas de migración de datos de la arquitectura para mostrar las preocupaciones de datos con más detalle


Cuando la arquitectura cuenta con complejidad y riesgo significativo en torno a la ubicación, la encapsulación, y la gestión o el a los datos

Los beneficios de usar esta extensión son los siguientes:

Página 355 de 670


La estructura de los datos se modela independientemente de su ubicación, lo que permite modelos de datos que deben desarrollarse que abarcan múltiples sistemas sin estar atado a las preocupaciones físicas.



Agrupaciones lógicas de datos pueden ser utilizados para establecer la gobernabilidad, la seguridad, o límites de despliegue alrededor de los datos, proporcionando una apreciación mucho más holística de los problemas de datos en torno a la arquitectura.



Figura 34‐14: Extensiones de datos: Los cambios en Metamodel Los cambios en las entidades metamodelo y relaciones son las siguientes: 

Componente lógica de datos se agrega como una nueva entidad metamodelo, encapsulando las entidades de datos.



Componente Físico de Datos se añade como una nueva entidad metamodelo, que se extiende de componentes lógica de datos.



Se crea una relación entre el Componente Físico de Datos y componente de aplicación. Si se aplica la extensión de consolidación de la infraestructura, esta debe ser física componente de aplicación.



Si se aplica la extensión de consolidación de la infraestructura, componentes de datos física tendrá una relación con Location.


Los atributos se añaden a las nuevas entidades metamodelo de lógica de componentes de datos y componentes de datos físicos.

Diagramas adicionales que se creen son los siguientes:

Página 356 de 670









34.4.5 Extensiones de Consolidación de Infraestructura Propósito

La extensión de la consolidación de la infraestructura está destinado a ser utilizado en los paisajes donde las aplicaciones y tecnología carteras hayan fragmentado y la arquitectura busca consolidar el negocio como de costumbre en la capacidad de un menor número de ubicaciones, aplicaciones o componentes de tecnología. El alcance de esta extensión es como sigue: 

La creación de una entidad de ubicación para mantener la ubicación de los activos de TI y consumidores externos de servicio



Creación de componentes de la aplicación lógica y física para abstraer la capacidad de una aplicación fuera de las aplicaciones reales de existencia



Creación de componentes de la aplicación lógica y física a Tipo de producto abstracto de los productos de tecnología de reales en existencia



Creación de diagramas adicionales centrados en la ubicación de los activos, cumplimiento de las normas, la estructura de las aplicaciones, migración de la aplicación, y configuración de la infraestructura


Donde muchos productos tecnológicos están en su lugar con el duplicado o la capacidad de superposición



Donde muchas aplicaciones están en su lugar, con duplicado o funcionalidad de superposición



Cuando las solicitudes están geográficamente dispersos y la lógica de decisión para determinar la ubicación de una aplicación no se conoce bien



Cuando las aplicaciones se van a migrar a una plataforma consolidada



Cuando las funciones de aplicación van a migrar en una aplicación consolidada


Permite la visibilidad y análisis de la duplicación redundante de la capacidad en los ámbitos de aplicación y tecnología



Soporta análisis del cumplimiento de las normas

Página 357 de 670


Soporta el análisis del impacto de la migración de aplicaciones o tecnología consolidación



Soporta definición arquitectónica detallada de la estructura de la aplicación

Además de las extensiones descritas aquí, las organizaciones que deseen centrarse en la consolidación de la infraestructura deben también consultar: 

El Lenguaje de Modelado Unificado (UML), proporcionado por el OMG; consulte www.uml.org



El Sistemas de Lenguaje de Modelado (SysML) - www.sysml.org - que reduce la complejidad y el software de enfoque de ingeniería de UML para los propósitos de modelado de sistemas



El Fondo para el IT Portfolio Management (ITPMF) del OMG; consulte www.omg.org / spec / ITPMF



Figura 34‐15: Infraestructura Extensiones de consolidación: Cambios en Metamodel Los cambios en las entidades metamodelo y relaciones son las siguientes: 

Ubicación atributos de Organización, Actor, componente de aplicación, el componente de datos y componentes de Tecnología se han mejorado para crear una entidad de la ubicación dentro del metamodelo.



Componentes de aplicación se amplían para incluir Lógico componentes de aplicación (una clase de aplicación) y Física componentes de aplicación (una aplicación real).



Componentes tecnológicos se amplían para incluir componentes lógicos Tecnología (una clase de producto de tecnología) y componentes Tecnología Físicas (un producto de la tecnología actual).

Página 358 de 670

The Open Group Architecture Framework TOGOF 9.1   Los cambios en los atributos metamodelo son los siguientes: 

Creación de atributos para las nuevas entidades Metamodel de Logical componente de aplicación, Física componente de aplicación, lógica Componente Tecnología, Tecnología del componente físico y Ubicación



La eliminación de ubicación como un atributo de las entidades que tienen un lugar y su sustitución por una relación con la entidad Ubicación





















34.4.6 Extensiones Motivación Propósito

La extensión de la motivación tiene por objeto permitir la modelización estructurada adicional de los controladores, las metas y objetivos que influyen en una organización para proporcionar servicios de negocio a sus clientes. Esto a su vez permite la definición más efectiva de los contratos de servicios y una mejor medición de los resultados empresariales. El alcance de esta extensión es como sigue: 

Creación de una nueva entidad metamodelo para el conductor que muestra los factores que motivan o limitan generalmente a una organización



Creación de una nueva entidad metamodelo para el objetivo que muestra el propósito estratégico y la misión de una organización



Creación de una nueva entidad metamodelo para el objetivo que se muestra cerca de los logros a mediano plazo que una organización desea alcanzar



Creación de un diagrama de Meta / Objetivo / servicio que muestra la trazabilidad de los conductores, las metas y objetivos a través de los servicios

Esta ampliación se debe utilizar en las siguientes situaciones:

Página 359 de 670


Cuando la arquitectura tiene que entender la motivación de las organizaciones con más detalle que los principios de negocios o de compromiso de estándares y objetivos que se modelan de manera informal dentro del metamodelo contenido básico



Cuando las organizaciones tienen los conductores y los objetivos en conflicto y que el conflicto tiene que ser entendido y tratado en una forma estructurada



Cuando los niveles de servicio son desconocidos o poco clara


Destacados desalineación de las prioridades de toda la empresa y cómo éstas se cruzan con los servicios compartidos (por ejemplo, algunas organizaciones pueden estar tratando de reducir los costos, mientras que otros están tratando de aumentar la capacidad)



Muestra la demanda de servicios empresariales que compiten de manera más estructurada, permitiendo niveles de servicio de compromiso para definir

Además de las extensiones descritas aquí, las organizaciones que deseen centrarse en la arquitectura de modelado de motivación empresarial, también deben consultar: 

El Modelo Motivación Negocio (BMM) especificación, proporcionada por el OMG; consulte www.omg.org / tecnología / documents / bms_spec_catalog.htm



Página 360 de 670


Extensiones de motivación: Figura 34‐16 Cambios en Metamodel Los cambios en las entidades metamodelo y relaciones son las siguientes: 

Conductor, Meta y Objetivo se agregan como nuevas entidades que enlazan Unidad de Organización de Servicios de Negocio.


Los atributos se añaden a las nuevas entidades metamodelo de Conductor, Meta y Objetivo.



Página 361 de 670


34.5 Contenido Entidades Metamodel La siguiente tabla muestra y describe las entidades dentro del metamodelo contenido. Metamodel Entidad Actor

Descripción

Una persona, organización o sistema que tiene un papel que inicia o interactúa con las actividades; por ejemplo, un representante de ventas que viaja a visitar a los clientes. Los actores pueden ser internos o externos a la organización. En la industria automotriz, un fabricante de equipo original se considera un actor por un concesionario de automóviles que interactúa con sus actividades de la cadena de suministro. Componente de Una encapsulación de funcionalidad de la aplicación alineado con aplicación estructura de ejecución. Por ejemplo, una aplicación de procesamiento de solicitud de compra.

Asunción

Servicios de Negocio Capacidad

Restricción

Contrato

Control

Entity Data

Conductor

Evento

Ver también lógico componente de aplicación y Física componente de aplicación . Una declaración de un hecho probable de que no ha sido plenamente validado en esta etapa, debido a las restricciones externas. Por ejemplo, se puede suponer que una aplicación existente apoyará un cierto conjunto de requisitos funcionales, sin que tal exigencia aún no hayan sido validados de forma individual. Soporta capacidades de negocio a través de una interfaz definida explícitamente y se rige explícitamente por una organización. Un resultado centrado en las empresas que se entrega por la realización de uno o más paquetes de trabajo. El uso de un enfoque de planificación basado en las capacidades, las actividades de cambio pueden ser secuenciados y se agrupan con el fin de proporcionar un valor empresarial continuo e incremental. Un factor externo que impide que una organización de la búsqueda de enfoques particulares para cumplir sus objetivos. Por ejemplo, los datos del cliente no está armonizada dentro de la organización, regional o nacional, lo que limita la capacidad de la organización para ofrecer un servicio al cliente eficaz. Un acuerdo entre un consumidor de servicios y un proveedor de servicios que establece los parámetros funcionales y no funcionales para la interacción. Un paso de toma de decisiones con el acompañamiento de la lógica de decisión utilizado para determinar el enfoque de ejecución de un proceso o para asegurar que un proceso cumple con los criterios de gobierno. Por ejemplo, un control de cierre de sesión en el proceso de tramitación de solicitud de compra que comprueba si el valor total de la solicitud está dentro de los límites de sesión fuera de la solicitante, o si necesita una escalada a la autoridad superior. Una encapsulación de datos que es reconocido por un experto de dominio de negocios como una cosa. Entidades de datos lógicos pueden estar vinculados a las aplicaciones, repositorios y servicios y pueden ser estructurados de acuerdo con las consideraciones de implementación. Una condición externa o interna que motiva a la organización a definir sus metas. Un ejemplo de un controlador externo es un cambio en la reglamentación o normas de cumplimiento que, por ejemplo, requieren cambios en la forma en que una organización opera; es decir, la Ley Sarbanes-Oxley en los EE.UU.. Un cambio de estado de la organización que desencadena eventos de procesamiento; puede provenir de dentro o fuera de la organización y

Página 362 de 670

The Open Group Architecture Framework TOGOF 9.1   Función

Brecha

puede ser resuelto dentro o fuera de la organización. Proporciona capacidades de negocio estrechamente alineadas a una organización, pero no necesariamente gobernadas de forma explícita por la organización. También se conoce como "función empresarial". Una declaración de la diferencia entre los dos estados. Se utiliza en el contexto de análisis de las carencias, donde se identifica la diferencia entre la línea de base y Arquitectura Target.

Nota: El análisis de brechas se describe en la Parte III , 27.Análisis Gap . Meta

Una declaración de alto nivel de la intención o la dirección de una organización. Normalmente se utiliza para medir el éxito de una organización. Sistema de Los elementos automáticos de un servicio empresarial. Un servicio del Información de sistema de información puede ofrecer o apoyar la totalidad o parte de uno Servicio o varios servicios de oficina. Ubicación Un lugar donde la actividad empresarial se lleva a cabo y se puede descomponer jerárquicamente. Lógico Una encapsulación de funcionalidad de la aplicación que es independiente Aplicación de una implementación particular. Por ejemplo, la clasificación de todas Componente las aplicaciones de procesamiento de solicitud de compra implementados en una empresa. Lógica de datos Una zona de frontera que encapsula las entidades de datos relacionados de componentes para formar una ubicación lógica que se realizará; por ejemplo, la información de aprovisionamiento externo. Lógico Una encapsulación de la infraestructura de tecnología que es Tecnología independiente de un producto en particular. Una clase de producto de la Componente tecnología; por ejemplo, el software de gestión de la cadena de suministro, como parte de un paquete de planificación de recursos empresariales (ERP), o un servicio de la empresa de procesamiento de solicitud de compra Commercial Off-The-Shelf (COTS). Medida Un indicador o factor que se puede controlar, por lo general en forma permanente, para determinar el éxito o el alineamiento con los objetivos y metas. Objetivo Un hito de tiempo limitado para que una organización utiliza para demostrar el progreso hacia una meta; por ejemplo, "Aumentar la utilización de la capacidad en un 30% a finales de 2009 para apoyar el aumento previsto de la cuota de mercado". Unidad de Una unidad autónoma de los recursos con metas, objetivos y Organización medidas.Unidades organizativas pueden incluir partes externas y las organizaciones asociadas de negocios. Física Una aplicación, módulo de aplicación, servicios de aplicaciones, u otro componente de despliegue de la funcionalidad. Por ejemplo, una instancia Aplicación de componentes de una planificación de recursos empresariales (ERP) de suministro Comercial Off-The-Shelf (COTS) configurado y desplegado la aplicación de gestión de la cadena. Datos físicos Una zona de frontera que encapsula las entidades de datos relacionados de componentes para formar un lugar físico que se celebrará. Por ejemplo, un objeto de negocio de la orden de compra, que comprende encabezado de la orden de compra y nodos de objetos de negocios artículo. Tecnología Un producto de infraestructura de tecnología o la tecnología instancia de Física producto infraestructura. Por ejemplo, un determinado modelo de una Componente solución comercial Off-The-Shelf (COTS), o de una marca específica y la versión del servidor.

Página 363 de 670

The Open Group Architecture Framework TOGOF 9.1   Plataforma de Servicios Principio

Una capacidad técnica que se requiere para proporcionar la infraestructura que permite que apoya la entrega de aplicaciones. Una declaración de intenciones cualitativo que debe ser satisfecha por la arquitectura. Tiene al menos un sustento racional y una medida de importancia.

Nota: Un conjunto de muestras de principios de arquitectura se define en la Parte III , 23. Arquitectura Principios . Proceso

Producto Requisito Papel

Servicio

Calidad de Servicio Componente Tecnología Paquete de Trabajo

Un proceso representa flujo de control entre o dentro de las funciones y / o servicios (depende de la granularidad de la definición). Los procesos representan una secuencia de actividades que en conjunto logran un resultado determinado, puede descomponerse en sub-procesos, y pueden mostrar el funcionamiento de una función o servicio (en el siguiente nivel de detalle). Los procesos también pueden ser utilizados para conectar o componer organizaciones, funciones, servicios y procesos. La salida generada por el negocio. El producto de negocios de la ejecución de un proceso. Una declaración cuantitativa de las necesidades de negocio que debe ser cumplida por una arquitectura o paquete de trabajo en particular. La función habitual o esperado de un actor, o la parte que alguien o algo juega en una acción o evento en particular. Un actor puede tener una serie de funciones. Ver también Actor . Un elemento de comportamiento que proporciona una funcionalidad específica en respuesta a las peticiones de los actores o otros servicios.Un servicio de entrega o apoya las capacidades de negocio, tiene una interfaz definida explícitamente, y se rige de forma explícita. Los servicios se definen para los negocios, los sistemas de información y plataformas. Una configuración preestablecida de atributos no funcionales que pueden ser asignadas a un servicio o contrato de servicio. Una encapsulación de infraestructura tecnológica que representa una clase de producto de la tecnología o producto de tecnología específica. Un conjunto de acciones identificadas para alcanzar uno o más objetivos para el negocio. Un paquete de trabajo puede ser una parte de un proyecto, un proyecto completo, o un programa.

34.6 Contenido Atributos Metamodel La siguiente tabla muestra los atributos típicos para cada una de las entidades metamodelo descritos anteriormente.

Metamodel Descripción Entidad Atributo Todas las Identificación Entidades

Identificador único para la entidad la arquitectura

Página 364 de 670

The Open Group Architecture Framework TOGOF 9.1   Metamodel Nombre Descripción Categoría

Capacidad

Fuente Propietario El valor del negocio Incrementos

Restricción Brecha Ubicación

Principio

Requisito

Actor


No hay atributos adicionales No hay atributos adicionales Categoría

Breve nombre de la entidad arquitectura Descripción textual de la entidad arquitectura. Taxonomía de categorización definible por el para cada entidad metamodelo. Lugar desde donde se obtuvo la información. Propietario de la entidad arquitectura. Describe cómo esta capacidad proporciona valor a la empresa. Enumera los posibles niveles de madurez / calidad para la capacidad. Esta entidad metamodelo sólo tiene atributos básicos. Esta entidad metamodelo sólo tiene atributos básicos.

Las siguientes categorías de ubicación aplican: Región (se aplica a un grupo de países o territorio, por ejemplo, el sudeste de Asia, Reino Unido e Irlanda), País (se aplica a un solo país, por ejemplo, EE.UU.), Construcción (se aplica a un sitio de operación, donde se recogen varias oficinas en una sola ciudad, esta categoría puede representar una ciudad), y la ubicación específica (se aplica a cualquier ubicación específica dentro de un edificio, como una sala de servidores). La naturaleza de la empresa puede introducir otras ubicaciones: Nave o puerto para una compañía de ferry, Minas para una compañía de oro, coches de policía, el Hotel para los trabajadores que viajan de cualquier empresa, y así sucesivamente. Categoría Las siguientes categorías de principios se aplican: Principio Rector, Principio de negocio, el Principio de datos, el principio de aplicación, el principio de integración, Tecnología Principio. Prioridad Prioridad de este principio en relación con otros principios. Declaración de principios Declaración de lo que el principio es. Razón fundamental Declaración de por qué es necesario el principio y el resultado a alcanzar. Implicación Declaración de lo que significa el principio en términos prácticos. Métrico Identifica los mecanismos que se utilizarán para medir si el principio se ha cumplido o no. Norma de exigencia Declaración de lo que el requisito es, incluyendo una definición de si se cumple el requisito, debe cumplirse, o puede cumplirse. Razón fundamental Declaración de por qué existe el requisito. Los criterios de aceptación Declaración de qué pruebas se llevarán a cabo para garantizar que se cumpla el requisito. # ETC Número estimado de FTE que operan como este actor. Objetivo Actor Los objetivos que este actor tiene, en términos generales. Tareas Actor Las tareas que realiza este actor, en términos generales. Clase de Normas No estándar, de Norma, Norma Provisional, Standard, phasing-out estándar, Jubilado estándar.

Página 365 de 670


Contrato

Fecha de creación del estándar Última fecha de revisión estándar La próxima fecha de revisión estándar Fecha de jubilarse Características de comportamiento Nombre del servicio "el que llama" Nombre del servicio "llama" Características de calidad de servicio Características Disponibilidad Los tiempos de servicio Características de manejabilidad Características Facilidad de servicio Características de rendimiento Requisitos de respuesta Características de confiabilidad Calidad de la información requerida Requisitos de control de Contrato Los requisitos de control de resultados

Si el producto es un estándar, cuando se creó la norma. Última fecha en que la norma fue revisada. La próxima fecha para que la norma sea revisada. Fecha en la que la norma se será retirado /. Comportamiento funcional para ser soportado dentro del alcance del contrato. El consumo de servicios. Proporcionar servicio. El comportamiento no funcional para el apoyo en el ámbito del contrato. Grado en que algo está disponible para su uso. Horas en las que el servicio debe estar disponible. Capacidad de recopilar información sobre el estado de algo y controlarlo. Capacidad para identificar problemas y tomar medidas correctivas, tales como reparar o actualizar un componente en un sistema en funcionamiento. Capacidad de un componente para realizar sus tareas en un tiempo apropiado. Los tiempos de respuesta que el proveedor de servicios debe cumplir para operaciones particulares. Resistencia al fracaso.

Requisitos contratados sobre la exactitud e integridad de la información. Nivel de gobierno y aplicación de aplicarse a los parámetros contractuales para el servicio en general. Las medidas previstas para asegurar que cada solicitud de servicio cumple con los criterios contratados. Características Capacidad para restaurar un sistema a un estado de Recuperabilidad trabajo después de una interrupción. Características estado de Capacidad de un sistema que se encuentran cuando localización sea necesario. Características de Capacidad de un sistema para evitar el no seguridad autorizado a las funciones y datos. Características Privacidad Protección de datos de s no autorizados. Características de Capacidad de un sistema para asegurar que los datos integridad no se ha dañado. Características de Capacidad de un sistema para asegurar que la credibilidad solicitud de servicio se origina de una fuente autorizada. Características de Capacidad de un servicio para apoyar las variantes localización localizadas para diferentes grupos de consumidores. Características de Capacidad de un servicio para soportar las internacionalización variaciones internacionales en la lógica empresarial y la representación de datos (como conjunto de caracteres). Características de La capacidad del servicio para interactuar con interoperabilidad diferentes entornos técnicos, dentro y fuera de la organización.

Página 366 de 670

The Open Group Architecture Framework TOGOF 9.1   Características de escalabilidad

Control Conductor Evento Función

Meta Medida Objetivo Unidad de Organización Proceso

Producto

Capacidad del servicio para aumentar o reducir su rendimiento o capacidad adecuada a las exigencias del entorno en el que opera. Portabilidad características De datos, personas, aplicaciones y componentes. Características de Capacidad para aceptar la nueva funcionalidad. extensibilidad Características de Capacidad contratada del proveedor de servicios para capacidad atender las solicitudes. Rendimiento Capacidad de producción requerida. Período de rendimiento El periodo de tiempo necesario para entregar la capacidad de rendimiento. Crecimiento Tasa de crecimiento futuro esperado de solicitud de servicio. Período de crecimiento El periodo de tiempo necesario para alcanzar la tasa de crecimiento esperada. Perfil pico a corto plazo Perfil de corto plazo del tráfico de las horas pico. Perfil pico largo plazo Perfil a largo plazo del tráfico de las horas pico. No hay atributos Esta entidad metamodelo sólo tiene atributos básicos. adicionales No hay atributos Esta entidad metamodelo sólo tiene atributos básicos. adicionales No hay atributos Esta entidad metamodelo sólo tiene atributos básicos. adicionales Clase de Normas No estándar, de Norma, Norma Provisional, Standard, phasing-out estándar, Jubilado estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. No hay atributos Esta entidad metamodelo sólo tiene atributos básicos. adicionales No hay atributos Esta entidad metamodelo sólo tiene atributos básicos. adicionales No hay atributos Esta entidad metamodelo sólo tiene atributos básicos. adicionales Número de empleados Número de FTE que trabajan dentro de la organización. Clase de Normas No estándar, de Norma, Norma Provisional, Standard, phasing-out estándar, Jubilado estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Criticidad del proceso La criticidad de este proceso para las operaciones comerciales. Manuales o automáticas, Si este proceso es apoyado por IT o es un proceso manual. Volumetría Proceso Los datos sobre la frecuencia de ejecución de procesos. No hay atributos Esta entidad metamodelo sólo tiene atributos básicos.

Página 367 de 670

The Open Group Architecture Framework TOGOF 9.1   adicionales Número estimado de FTE Esta entidad metamodelo sólo tiene atributos básicos. que operan en este Rol Calidad de No hay atributos Esta entidad metamodelo sólo tiene atributos básicos. Servicio adicionales Servicio Clase de Normas No estándar, de Norma, Norma Provisional, Standard, phasing-out estándar, Jubilado estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Componente de Clase de Normas No estándar, de Norma, Norma Provisional, Standard, aplicación phasing-out estándar, Jubilado estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Sistema de Clase de Normas No estándar, de Norma, Norma Provisional, Standard, Información de phasing-out estándar, Jubilado estándar. Servicio Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Lógico Aplicación Clase de Normas No estándar, de Norma, Norma Provisional, Standard, Componente phasing-out estándar, Jubilado estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Física Aplicación El estado del ciclo de vida Propuso en el Desarrollo, en vivo, eliminación de componentes gradual, jubilado . Clase de Normas No estándar, de Norma, Norma Provisional, Standard, phasing-out estándar, Jubilado estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Fecha vivo inicial Fecha en la que la primera versión de la aplicación fue / será lanzado en la producción. Fecha de la última versión Fecha en la que la última versión de la aplicación fue Papel

Página 368 de 670

The Open Group Architecture Framework TOGOF 9.1   Fecha de la próxima versión Fecha de retiro Características Disponibilidad Los tiempos de servicio Características de manejabilidad Características Facilidad de servicio Características de rendimiento Características de confiabilidad Características Recuperabilidad Características estado de localización Características de seguridad Características Privacidad Características de integridad Características de credibilidad

Entity Data

lanzada en la producción. Fecha en la que la próxima versión de la aplicación se dará a conocer en producción. Fecha en la que la solicitud fue / será retirado. Grado en que algo está disponible para su uso. Horas en las que la aplicación debe estar disponible. Capacidad de recopilar información sobre el estado de algo y controlarlo. Capacidad para identificar problemas y tomar medidas correctivas, tales como reparar o actualizar un componente en un sistema en funcionamiento. Capacidad de un componente para realizar sus tareas en un tiempo apropiado. Resistencia al fracaso.

Capacidad para restaurar un sistema a un estado de trabajo después de una interrupción. Capacidad de un sistema que se encuentran cuando sea necesario. Capacidad de un sistema para evitar el no autorizado a las funciones y datos. Protección de datos de s no autorizados. Capacidad de un sistema para asegurar que los datos no se ha dañado. Capacidad de un sistema para asegurar que la solicitud de servicio se origina de una fuente autorizada. Características de Capacidad de un servicio para apoyar las variantes localización localizadas para diferentes grupos de consumidores. Características de Capacidad de un servicio para soportar las internacionalización variaciones internacionales en la lógica empresarial y la representación de datos (como conjunto de caracteres). Características de La capacidad del servicio para interactuar con interoperabilidad diferentes entornos técnicos, dentro y fuera de la organización. Características de Capacidad del servicio para aumentar o reducir su escalabilidad rendimiento o capacidad adecuada a las exigencias del entorno en el que opera. Portabilidad características De datos, personas, aplicaciones y componentes. Características de Capacidad para aceptar la nueva funcionalidad. extensibilidad Características de Capacidad contratada del proveedor de servicios para capacidad atender las solicitudes. Rendimiento Capacidad de producción requerida. Período de rendimiento El periodo de tiempo necesario para entregar la capacidad de rendimiento. Crecimiento Tasa de crecimiento futuro esperado de solicitud de servicio. Período de crecimiento El periodo de tiempo necesario para alcanzar la tasa de crecimiento esperada. Perfil pico a corto plazo Perfil de corto plazo del tráfico de las horas pico. Perfil pico largo plazo Perfil a largo plazo del tráfico de las horas pico. Categoría Las siguientes categorías de entidad de datos se aplican: Mensaje, internamente almacenados Entidad.

Página 369 de 670

The Open Group Architecture Framework TOGOF 9.1   Clasificación de Privacidad Nivel de restricción puesta sobre el a los datos. Clasificación de Retención Duración de la retención que se colocará en los datos. Lógica de datos Clase de Normas No estándar, de Norma, Norma Provisional, Standard, de componentes phasing-out estándar, Jubilado estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Datos físicos Clase de Normas No estándar, de Norma, Norma Provisional, Standard, de componentes phasing-out estándar, Jubilado estándar. Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Lógico Clase de Normas No estándar, de Norma, Norma Provisional, Standard, Tecnología phasing-out estándar, Jubilado estándar. Componente Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Categoría Componentes tecnológicos lógicos se clasifican de acuerdo a la TOGAF TRM, que podrá ampliarse para satisfacer las necesidades de una organización individual. Tecnología Clase de Normas No estándar, de Norma, Norma Provisional, Standard, Física phasing-out estándar, Jubilado estándar. Componente Fecha de creación del Si el producto es un estándar, cuando se creó la estándar norma. Última fecha de revisión Última fecha en que la norma fue revisada. estándar La próxima fecha de La próxima fecha para que la norma sea revisada. revisión estándar Fecha de jubilarse Fecha en la que la norma se será retirado /. Categoría Componentes tecnológicos físicas se clasifican de acuerdo con el TOGAF TRM, que podrá ampliarse para satisfacer las necesidades de una organización individual. Nombre del producto Nombre del producto que constituyen el componente de tecnología. Nombre del módulo Módulo u otro sub-producto, el nombre que constituyen el componente de tecnología. Vendedor Vendor proporcionar el componente de tecnología. Versión Versión del producto que constituyen el componente de tecnología.

Página 370 de 670

The Open Group Architecture Framework TOGOF 9.1   Plataforma de Servicios

Clase de Normas Categoría

Componente Tecnología Paquete de Trabajo

Clase de Normas Categoría

Capacidad de entrega

No estándar, de Norma, Norma Provisional, Standard, phasing-out estándar, Jubilado estándar. Servicios de la Plataforma se clasifican de acuerdo con el TOGAF TRM, que podrá ampliarse para satisfacer las necesidades de una organización individual. No estándar, de Norma, Norma Provisional, Standard, phasing-out estándar, Jubilado estándar. Las siguientes categorías de paquete de trabajo se aplican: Paquete de Trabajo, Arroyo trabajo, proyecto, programa, Portfolio . Describe la contribución de este paquete de trabajo hace a la entrega de capacidades.

34.7 Metamodel Relaciones Entidad Fuente

Entidad Target

Actor Actor Actor Actor Actor

Evento Evento Función Función Ubicación

Actor Actor Actor Actor Actor Actor Capacidad Contrato Contrato Control

Unidad de Organización Proceso Papel Servicio Actor Entity Data Paquete de Trabajo Servicio Calidad de Servicio Proceso

Entity Data

Lógico Aplicación Componente Lógica de datos de componentes Servicio Entity Data Entity Data Meta Unidad de Organización Conductor Actor Actor Proceso Proceso Servicio Actor Actor Unidad de Organización Proceso

Entity Data Entity Data Entity Data Entity Data Conductor Conductor Conductor Evento Evento Evento Evento Evento Función Función Función Función

Nombre

Módulo de extensión Genera Proceso Resuelve Proceso Interactúa con Núcleo Realiza Núcleo Opera en Infraestructura Consolidación Pertenece a Núcleo Participa en Núcleo Realiza tareas en Núcleo Consume Núcleo Se descompone Núcleo Suministros / Consume Núcleo Se entrega por Núcleo Gobierna y Medidas Gobernancia Cumple Gobernancia Asegura el correcto funcionamiento de Proceso los Es procesado por Núcleo Reside en

Datos

Se accede y actualizada a través de Se descompone Se relaciona con Crea Motiva Se descompone RESUELVE Es generado por RESUELVE Es generado por RESUELVE Apoyos Se realiza por Es propiedad de Apoyos

Núcleo Núcleo Núcleo Motivación Motivación Motivación Proceso Proceso Proceso Proceso Proceso Núcleo Núcleo Núcleo Núcleo

Página 371 de 670

The Open Group Architecture Framework TOGOF 9.1   Función Función Función Función Función Meta Meta Meta Ubicación

Proceso Papel Servicio Función Función Conductor Objetivo Meta Actor

Se realiza por Se puede acceder por Está delimitada por Se descompone Se comunica con Direcciones Se realiza a través Se descompone Contiene

Ubicación

Unidad de Organización

Contiene

Ubicación

Física Aplicación de componentes Componente Físico de Datos Tecnología Física Componente Ubicación

Contiene

Lógico Aplicación Componente Lógico Aplicación Componente Lógico Aplicación Componente Lógico Aplicación Componente Lógico Aplicación Componente Lógica de datos de componentes Lógica de datos de componentes Lógico Tecnología Componente Lógico Tecnología Componente Lógico Tecnología Componente Lógico Tecnología Componente Lógico Tecnología Componente Medida

Entity Data

Funciona con

Física Aplicación de componentes Servicio

Está extendida por Implementos

Infraestructura Consolidación Núcleo

Lógico Aplicación Componente Lógico Aplicación Componente Entity Data

Se descompone

Núcleo

Se comunica con

Núcleo

Encapsula

Datos

Componente Físico de Datos Tecnología Física Componente Plataforma de Servicios

Está extendida por

Datos

Está extendida por Suministros


Servicio

Proporciona plataforma para

Núcleo

Lógico Tecnología Componente Lógico Tecnología Componente Objetivo

Se descompone

Núcleo

Depende

Núcleo Gobernancia

Medida

Servicio

Medida Objetivo Objetivo Objetivo Unidad de Organización Unidad de Organización

Medida Meta Medida Objetivo Actor

Establece criterios de desempeño para Establece criterios de desempeño para Se descompone Se da cuenta de Se realiza un seguimiento en contra Se descompone Contiene

Conductor

Está motivada por

Núcleo

Ubicación Ubicación Ubicación

Contiene Contiene Se descompone

Núcleo Núcleo Núcleo Núcleo Núcleo Motivación Motivación Motivación Infraestructura Consolidación Infraestructura Consolidación Infraestructura Consolidación Infraestructura Consolidación Infraestructura Consolidación Infraestructura Consolidación Núcleo

Gobernancia Gobernancia Motivación Gobernancia Motivación Núcleo

Página 372 de 670

The Open Group Architecture Framework TOGOF 9.1   Unidad de Organización Unidad de Organización Unidad de Organización Unidad de Organización Unidad de Organización Física Aplicación de componentes Física Aplicación de componentes Física Aplicación de componentes Física Aplicación de componentes Física Aplicación de componentes Física Aplicación de componentes Datos físicos de componentes Datos físicos de componentes Datos físicos de componentes Datos físicos de componentes Tecnología Física Componente Tecnología Física Componente Tecnología Física Componente Tecnología Física Componente Tecnología Física Componente Plataforma de Servicios Proceso Proceso Proceso Proceso Proceso Proceso Proceso Proceso Proceso Proceso Proceso Producto Producto Papel

Función

Posee

Núcleo

Ubicación

Opera en

Núcleo

Producto

Produce

Núcleo

Servicio

Posee y gobierna

Núcleo


Se descompone

Núcleo

Ubicación

Está alojado en

Lógico Aplicación Componente Datos físicos de componentes Tecnología Física Componente Física Aplicación de componentes Física Aplicación de componentes Ubicación

Extiende Encapsula

Infraestructura Consolidación Infraestructura Consolidación Modelado de Datos

Se realiza por

Núcleo

Se descompone

Núcleo

Se comunica con

Núcleo

Está alojado en

Lógica de datos de componentes Datos físicos de componentes Física Aplicación de componentes Ubicación

Extiende

Infraestructura Consolidación Datos

Se descompone

Núcleo

Encapsula

Modelado de Datos

Está alojado en

Física Aplicación de componentes Lógico Tecnología Componente Tecnología Física Componente Tecnología Física Componente Lógico Tecnología Componente Actor Control Evento Evento Función Función Producto Servicio Servicio Proceso Proceso Unidad de Organización Proceso Actor

Se da cuenta de

Consolidación de Infraestructura Núcleo

Extiende Se descompone


Depende

Núcleo

Se suministra por

Núcleo

Involucra Se guía por Genera Resuelve Orquesta Se descompone Produce Orquesta Se descompone Se descompone Precede / Follows Es producido por Es producido por Se realiza por

Núcleo Proceso Proceso Proceso Núcleo Núcleo Proceso Núcleo Núcleo Núcleo Núcleo Proceso Proceso Núcleo

Página 373 de 670

The Open Group Architecture Framework TOGOF 9.1   Papel Papel Servicio Servicio Servicio Servicio Servicio Servicio

Función Papel Actor Contrato Entity Data Entity Data Evento Función

Servicio

Lógico Aplicación Componente Lógico Tecnología Componente Medida Unidad de Organización Proceso Proceso Calidad de Servicio Servicio Servicio Contrato

Servicio Servicio Servicio Servicio Servicio Servicio Servicio Servicio Calidad de Servicio Calidad de Servicio Paquete de Trabajo

s Se descompone Se proporciona a Se rige y se mide por Proporciona Consume Resuelve Proporciona una interfaz gobernado al Se realiza a través

Núcleo Núcleo Núcleo Gobernancia Núcleo Núcleo Proceso Núcleo

Se implementa en

Núcleo

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

Gobernancia Núcleo Núcleo Núcleo Gobernancia Núcleo Núcleo Gobernancia

Servicio

Se aplica a los

Gobernancia

Capacidad

Entrega

Núcleo

Núcleo



Página 374 de 670


35. Architectural Artifacts Este capítulo trata de los conceptos que rodean arquitectura artefactos y luego describe los artefactos que se recomiendan que se creará para cada fase en el Método de Desarrollo de Arquitectura (). También se presenta una guía para el desarrollo de un conjunto de puntos de vista, algunos o todos de los cuales pueden ser apropiadas en un desarrollo de la arquitectura en particular.

35.1 Conceptos básicos Artefactos arquitectónicos se crean con el fin de describir un sistema, solución, o el estado de la empresa. Los conceptos tratados en esta sección han sido adaptados de las definiciones más formales contenidos en la norma ISO / IEC 42010:2007 e ilustrados en la Figura 35-1 . Nota: La notación utilizada es del Lenguaje Unificado de Modelado (UML) especificación.

Figura 35‐1: Conceptos básicos de la arquitectura Un "sistema" es una colección de componentes organizados para llevar a cabo una función o conjunto de funciones específicas.

Página 375 de 670

The Open Group Architecture Framework TOGOF 9.1   La "arquitectura" de un sistema es la organización fundamental del sistema, encarnada en sus componentes, sus relaciones entre sí y con el medio ambiente, y los principios que guían su diseño y evolución. Una "descripción de la arquitectura" es una colección de artefactos que documentan una arquitectura . En TOGAF, vistas de arquitectura son los artefactos claves en una descripción de la arquitectura. "Las partes interesadas" son personas que tienen un papel clave en, o preocupaciones sobre el sistema; por ejemplo, como s, desarrolladores o es.Diferentes actores con diferentes roles en el sistema tendrán diferentes inquietudes. Las partes interesadas pueden ser individuos, grupos u organizaciones (o clases de los mismos). "La preocupación" son los intereses dominantes que son de crucial importancia para las partes interesadas en el sistema, y determinar la aceptabilidad del sistema. Las preocupaciones pueden referirse a cualquier aspecto de funcionamiento del sistema, el desarrollo o la operación, incluyendo consideraciones tales como el rendimiento, la fiabilidad, la seguridad, la distribución y capacidad de evolución. Una "vista" es una representación de todo un sistema desde la perspectiva de un conjunto relacionado de preocupaciones. Al capturar o representar el diseño de un sistema de arquitectura, el arquitecto normalmente crear uno o más modelos de arquitectura, posiblemente utilizando diferentes herramientas. Una vista comprenderá partes seleccionadas de uno o más modelos, elegidos con el fin de demostrar a un actor o grupo de actores que sus preocupaciones están siendo abordadas adecuadamente en el diseño de la arquitectura del sistema. Un "punto de vista", define la perspectiva desde la cual se toma una vista. Más específicamente, un punto de vista define: cómo construir y utilizar un punto de vista (por medio de un esquema o plantilla adecuada); la información que debe aparecer en la vista; las técnicas de modelado para expresar y analizar la información; y una justificación de estas decisiones (por ejemplo, describiendo el propósito y destinatario de la vista). 

Un punto de vista es lo que ves. Un punto de vista es donde se busca desde - el punto de vista o perspectiva que determina lo que ves.



Puntos de vista son genéricos, y pueden ser almacenados en las bibliotecas para la reutilización. Un punto de vista es siempre específica a la arquitectura para la que se creó.



Cada posición tiene un punto de vista asociada que describe, al menos implícitamente. ISO / IEC 42010:2007 anima a los arquitectos para definir los puntos de vista de forma explícita. Hacer esta distinción entre el contenido y el esquema de una vista puede parecer a primera vista una sobrecarga innecesaria, sino que proporciona un mecanismo para que los puntos de vista reutilizar en diferentes arquitecturas.

En resumen, pues, vistas de arquitectura son representaciones de la arquitectura global en términos significativos para las partes interesadas. Permiten a la arquitectura que se comunicará a y entendido por las partes interesadas, para que puedan verificar que el sistema se ocupará de sus preocupaciones.

Página 376 de 670

The Open Group Architecture Framework TOGOF 9.1   Nota: Los términos "preocupación" y "requisito" no son sinónimos. Una preocupación es un área de interés. Por lo tanto, la fiabilidad del sistema podría ser una preocupación / área de interés para algunos interesados. La razón por la que los arquitectos deberían identificar las preocupaciones y asociarlos con los puntos de vista, es garantizar que esas preocupaciones serán abordadas de alguna manera por los modelos de la arquitectura. Por ejemplo, si el único punto de vista seleccionado por un arquitecto es un punto de vista estructural, a continuación, problemas de fiabilidad es casi seguro que no se abordan, ya que no pueden ser representados en un modelo estructural. Dentro de esa preocupación, los interesados pueden tener muchas necesidades distintas: diferentes clases de s pueden tener diferentes requisitos de fiabilidad para las diferentes capacidades del sistema. Las preocupaciones son la raíz del proceso de descomposición en los requisitos. Las preocupaciones están representados en la arquitectura de estos requisitos.Los requisitos deben ser SMART (por ejemplo, las métricas específicas).

35.1.1 Ejemplo simple de un Mirador y Vista Para muchas arquitecturas , un punto de vista útil es la de los dominios de negocio, que se puede ilustrar con un ejemplo tomado de The Open Group en sí. El punto de vista se especifica de la siguiente manera: Elemento Viewpoint Las partes interesadas Preocupaciones Técnica de modelado

Descripción Consejo de istración, Director General Mostrar las relaciones de alto nivel entre los sitios geográficos y funciones de negocios. Anidado diagrama de cajas. cajas exterior = lugares; cajas internas = funciones de negocios. Semántica de anidación = funciones realizadas en las localidades.

La vista correspondiente de The Open Group (en 2008) se muestra en la Figura 35-2 .

Página 377 de 670


Figura 35‐2: Ejemplo View ‐ The Open Group Negocio Dominios en 2008

35.2 Vistas desarrollo en el 35.2.1 Directrices Generales La elección de qué puntos de vista particulares de arquitectura para desarrollar es una de las decisiones clave que el arquitecto tiene que hacer. El arquitecto tiene la responsabilidad de asegurar la integridad (aptitud para el propósito) de la arquitectura, en términos de abordar adecuadamente todos los intereses pertinentes de las partes interesadas; y la integridad de la arquitectura, en cuanto a la conexión de todos los diferentes puntos de vista de la otra, la conciliación de forma satisfactoria las preocupaciones conflictivas de los diferentes grupos de interés, y que muestra las compensaciones hechas en hacerlo (como entre la seguridad y el rendimiento, por ejemplo). La elección tiene que ser limitada por consideraciones de orden práctico, y por el principio de la aptitud para el propósito (es decir, la arquitectura debe ser desarrollado sólo hasta el punto en el que es apto para el propósito, y no reiteró el infinito como un ejercicio académico). Como se explica en la Parte II: Arquitectura Método de Desarrollo () , el desarrollo de puntos de vista de arquitectura es un proceso iterativo. La progresión típica es de negocio a la tecnología, el uso de una técnica como escenarios de negocios (véase la Parte III , 26. Escenarios empresariales y objetivos de la empresa ) para identificar correctamente todas las preocupaciones pertinentes; y de introducción de alto nivel a los detalles de bajo nivel, refiriéndose continuamente de nuevo a las preocupaciones y necesidades de las partes interesadas en todo el proceso.

Página 378 de 670

The Open Group Architecture Framework TOGOF 9.1   Por otra parte, cada una de estas progresiones tiene que ser hecho por dos ambientes distintos: el entorno existente (conocida como la línea de base en el ) y el entorno de destino. El arquitecto debe desarrollar puntos de vista pertinentes de arquitectura, tanto de la arquitectura de línea de base y la arquitectura destino. Esto proporciona el contexto para el análisis de las deficiencias en el final de las fases B, C y D de la , que establece los elementos de la arquitectura de referencia que deban traspasarse y los elementos que pueden añadir, eliminar o sustituir. Todo este proceso se explica en la Parte III , 27. Análisis Gap .

35.2.2 Ver Proceso de Creación Como se mencionó anteriormente, en el momento actual TOGAF alienta pero no obliga a la utilización de la norma ISO / IEC 42010:2007. Por tanto, la siguiente descripción se refiere tanto a la situación en la ISO / IEC 42010:2007 ha sido adoptado y en las que no tiene. ISO / IEC 42010:2007 en sí no requiere ningún proceso específico para el desarrollo de puntos de vista o la creación de puntos de vista de ellos. Cuando la norma ISO / IEC 42010:2007 ha sido adoptado y convertido en una práctica bien establecida dentro de una organización, a menudo será posible crear los puntos de vista necesarios para una arquitectura particular, siguiendo estos pasos:

1. Consulte una biblioteca existente de puntos de vista 2. Seleccione los puntos de vista apropiados (basados en los grupos de interés y preocupaciones que deben ser cubiertos por los puntos de vista) 3. Generar vistas del sistema mediante el uso de los puntos de vista seleccionados como plantillas Este enfoque se puede esperar para llevar a los siguientes beneficios: 

Menos trabajo para los arquitectos (debido a que los puntos de vista ya se han definido, por lo que las vistas se pueden crear más rápido)



Una mejor comprensión de las partes interesadas (debido a que los puntos de vista ya están familiarizados)



Mayor confianza en la validez de los puntos de vista (debido a que sus puntos de vista tienen una trayectoria conocida)

Sin embargo, las situaciones siempre pueden surgir en los que se necesita una vista para la que ningún punto de vista adecuado ha predefinido. Esta es también la situación, por supuesto, cuando una organización aún no ha incorporado la norma ISO / IEC 42010:2007 en su práctica de la arquitectura y establecido una biblioteca de puntos de vista. En cada caso, el arquitecto puede elegir para desarrollar un nuevo punto de vista que cubrirá la necesidad excepcional y, a continuación, generar una vista de ella. (Esta es la norma ISO / IEC 42010:2007 práctica recomendada.) Por otra parte, un enfoque más pragmático puede ser igualmente exitosa: el arquitecto puede crear un especialpunto de vista de un sistema específico y luego considerar si una forma generalizada de la perspectiva implícita debería definirse

Página 379 de 670

The Open Group Architecture Framework TOGOF 9.1   explícitamente y guardado en una biblioteca, de modo que pueda ser reutilizado. (Esta es una manera de establecer una biblioteca de puntos de vista inicialmente.) Sea cual sea el contexto, el arquitecto debe ser consciente de que cada punto de vista tiene un punto de vista, al menos implícitamente, y que define el punto de vista de una manera sistemática (según lo recomendado por la norma ISO / IEC 42010:2007) ayudará en la evaluación de su eficacia; es decir, cubre el punto de vista de las preocupaciones de las partes interesadas pertinentes?.

35.3 Vistas, Herramientas y lenguajes La necesidad de puntos de vista de arquitectura, y el proceso de desarrollo de ellos después de la , se explicaron anteriormente. Esta sección describe las relaciones entre puntos de vista de arquitectura, las herramientas utilizadas para desarrollar y analizarlos, y una que permite la interoperabilidad entre lenguajes estándar entre las herramientas.

35.3.1 Información general Con el fin de alcanzar los objetivos de la integridad y la integridad en una arquitectura , vistas de arquitectura suelen ser desarrollados, visualizar, comunican y gestionan mediante una herramienta. En el estado actual del mercado, diferentes herramientas normalmente tienen que ser utilizados para desarrollar y analizar diferentes puntos de vista de la arquitectura. Es altamente deseable que una descripción de la arquitectura se codifica en un lenguaje estándar, para permitir un enfoque estándar para la descripción de la arquitectura semántica y su reutilización entre distintas herramientas. Un punto de vista también se desarrolló normalmente, visualizar, comunicar y istrar mediante una herramienta, y también es muy deseable que se desarrollen puntos de vista estándar (por ejemplo, plantillas o esquemas), de modo que las diferentes herramientas que se ocupan en los mismos puntos de vista pueden interoperar, la elementos fundamentales de una arquitectura pueden ser reutilizados, y la descripción de la arquitectura pueden ser compartidas entre las herramientas. Las cuestiones relativas a la evaluación de las herramientas para el trabajo de la arquitectura se discuten en detalle en la Parte V , 42. Herramientas para el desarrollo de la arquitectura .

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

Página 380 de 670

The Open Group Architecture Framework TOGOF 9.1   El punto de vista del piloto comprende algunas preocupaciones que no son relevantes para el controlador, como pasajeros y combustible, mientras que el punto de vista del controlador comprende algunas preocupaciones que no son pertinentes para el piloto, como otros aviones. También hay elementos comunes entre los dos puntos de vista, tales como el modelo de comunicación entre el piloto y el controlador, y la información vital sobre el avión en sí. Un punto de vista es un modelo (o descripción) de la información contenida en una vista. En nuestro ejemplo, un punto de vista es la descripción de cómo el piloto ve el sistema, y el otro punto de vista es cómo el controlador ve el sistema. Pilotos describen el sistema desde su perspectiva, utilizando un modelo de su posición y el vector hacia o lejos de la pista de aterrizaje. Todos los pilotos utilizar este modelo, y el modelo tiene un lenguaje específico que se utiliza para capturar la información y rellenar el modelo. Controladores describen el sistema de forma diferente, utilizando un modelo del espacio aéreo y los lugares y vectores de aeronave dentro del espacio aéreo. Una vez más, todos los controladores utilizan un lenguaje común derivada del modelo común con el fin de capturar y comunicar la información pertinente a su punto de vista. Afortunadamente, cuando los controladores de hablar con los pilotos, que utilizan un lenguaje común de comunicación. (En otras palabras, los modelos que representan sus puntos de vista individuales se cruzan parcialmente.) Parte de este lenguaje común es acerca de la ubicación y vectores de aeronaves, y es esencial para la seguridad. Así que, en esencia, cada punto de vista es un modelo abstracto de cómo todas las partes interesadas de un tipo particular - todos los pilotos, o todos los controladores - Ver el sistema aeroportuario. Existen herramientas para ayudar a las partes interesadas, sobre todo cuando están interactuando con los modelos complejos, como el modelo de un espacio aéreo , o el modelo de vuelo del aire. La interfaz para el humano de una herramienta es típicamente cerca de la del modelo y de idioma asociado con el punto de vista. Las herramientas únicas de la prueba piloto son el combustible, la altitud, la velocidad y los indicadores de lugar. La herramienta principal del controlador es el radar. La herramienta común es una radio. Para resumir el ejemplo anterior, podemos ver que una vista puede subconjunto del sistema a través de la perspectiva de la parte interesada, como el piloto contra el controlador. Este subconjunto puede ser descrito por un modelo abstracto llamado un punto de vista, tal como un vuelo de aire en comparación con un modelo de espacio de aire. Esta descripción de la vista se documenta en un idioma parcialmente especializada, como "piloto-speak" frente "controladorspeak". Las herramientas son usadas para ayudar a las partes interesadas, y que interactúan entre sí en cuanto a la lengua derivada del punto de vista ("piloto-speak" versus " "controladorspeak"). Cuando los actores usan herramientas comunes, como el o de radio entre piloto y controlador, un idioma común es esencial.

Página 381 de 670

The Open Group Architecture Framework TOGOF 9.1   35.4.2 Vistas y puntos de vista en la arquitectura empresarial Ahora vamos a mapear este ejemplo para la arquitectura empresarial. Consideremos dos partes interesadas en un nuevo sistema informático pequeño: los s y los desarrolladores. Los s del sistema tienen un punto de vista que refleja sus inquietudes al interactuar con el sistema, y los desarrolladores del sistema de tener un punto de vista diferente. Visto que se desarrollan para tratar cualquiera de los dos puntos de vista son poco probable para describir exhaustivamente todo el sistema, porque cada perspectiva reduce cómo cada uno ve el sistema. El punto de vista del se compone de todas las formas en que el interactúa con el sistema, no ver ningún detalle, como aplicaciones o sistemas de gestión de bases de datos (DBMS). El punto de vista del desarrollador es uno de productividad y herramientas, y no incluye cosas tales como los datos reales en vivo y las conexiones con los consumidores. Sin embargo, hay cosas que se comparten, tales como descripciones de los procesos que están habilitados por el sistema y / o protocolos de comunicación establecido para que los s comuniquen directamente los problemas del desarrollo. En este ejemplo, un punto de vista es la descripción de cómo el ve el sistema, y el otro punto de vista es cómo el desarrollador ve el sistema. Los s describen el sistema desde su perspectiva, utilizando un modelo de disponibilidad, tiempo de respuesta, y el a la información. Todos los s del sistema de utilizar este modelo, y el modelo tiene un lenguaje específico. Desarrolladores describir el sistema de manera diferente que los s, usando un modelo de software conectado al hardware distribuido sobre una red, etc Sin embargo, hay muchos tipos de desarrolladores (base de datos, seguridad, etc) del sistema, y no tienen un común idioma derivada del modelo.

35.4.3 necesidad de un lenguaje común y herramientas interoperables para Arquitectura Descripción Existen herramientas para los s y desarrolladores. Herramientas tales como la ayuda en línea están allí específicamente para los s, y tratan de utilizar el idioma del . Existen muchas herramientas diferentes para diferentes tipos de desarrolladores, pero adolecen de la falta de un lenguaje común que se requiere para que el sistema en conjunto. Es difícil, si no imposible, en el estado actual del mercado de herramientas para tener una herramienta de interoperar con otra herramienta. Las cuestiones relativas a la evaluación de las herramientas para el trabajo de la arquitectura se discuten en detalle en la Parte V , 42. Herramientas para el desarrollo de la arquitectura .

35.5 Conclusiones Esta sección se trata de hacer frente a puntos de vista en forma estructurada, pero esto de ninguna manera es un tratado completo de puntos de vista.

Página 382 de 670

The Open Group Architecture Framework TOGOF 9.1   . En general, TOGAF abarca los conceptos y definiciones que se presentan en la norma ISO / IEC 42010:2007, específicamente los conceptos que ayudan a guiar el desarrollo de una visión y hacer que la visión accionable Estos conceptos se pueden resumir en: 

Selección de una de las partes interesadas clave



Entender sus preocupaciones y generalizando / documentar esas preocupaciones



Entender cómo modelar y hacer frente a esas preocupaciones

35.6 Architectural Artifacts por Fase La Figura 35-3 muestra los artefactos que están asociados con el metamodelo contenido de núcleo y cada una de las extensiones de contenido.

Figura 35‐3: artefactos asociados con el metamodelo y Extensiones Core Las clases específicas de artefacto son los siguientes: 

Catálogos son listas de bloques de construcción.



Matrices muestran las relaciones entre los componentes básicos de los tipos específicos.



Diagramas actuales bloques de construcción, además de sus relaciones e interconexiones de un modo gráfico que soporta la comunicación efectiva de los interesados.

Los artefactos recomendadas para la producción en cada fase de son los siguientes.

Página 383 de 670

The Open Group Architecture Framework TOGOF 9.1   35.6.1 Fase Preliminar A continuación se describen los catálogos, matrices y diagramas que se pueden crear dentro de la Etapa Preliminar, como se indica en la Parte II , 6.5 Salidas . Principios Catálogo

El catálogo Principios capta principios de los principios de negocio y la arquitectura que describen lo que una solución o arquitectura "buena" debe ser similar. Principios se utilizan para evaluar y acordar un resultado para los puntos de decisión arquitectura. Principios también se utilizan como una herramienta para ayudar en la gestión de arquitectura de las iniciativas de cambio. El catálogo Principios contiene las siguientes entidades metamodelo: 

Principio

35.6.2 Fase A: Architecture Vision A continuación se describen los catálogos, matrices y diagramas que se pueden crear dentro de la Fase A (Architecture Vision) que se enumeran en 7.5 Salidas . Stakeholder Mapa Matrix

El propósito de la matriz de los interesados mapa es identificar los grupos de interés para la contratación arquitectura, su influencia sobre el compromiso, y sus preguntas clave, temas o preocupaciones que deben ser abordados en el marco de la arquitectura. Entender las partes interesadas y sus necesidades permite a un arquitecto para enfocar los esfuerzos en las áreas que satisfagan las necesidades de los interesados (véase la Parte III , 24. Gestión de los grupos de interés ). Debido a la naturaleza potencialmente confidencial de la información de mapeo de los interesados y el hecho de que la fase Architecture Vision está destinado a ser llevado a cabo utilizando técnicas de modelado informales, no hay entidades metamodelo específicos se utilizan para generar un mapa de las partes interesadas. Diagrama de la Cadena de Valor

Un diagrama de la cadena de valor ofrece una vista de orientación de alto nivel de una empresa y cómo interactúa con el mundo exterior. En contraste con el diagrama de descomposición funcional más formal desarrollado en la Fase B (Business Architecture), el diagrama de la cadena de valor se centra en el impacto de presentación. El propósito de este diagrama es rápidamente a bordo y alinear las partes interesadas de una iniciativa particular el cambio, de modo que todos los participantes entiendan el contexto funcional y organizativa de alto nivel de la participación de la arquitectura.

Página 384 de 670

The Open Group Architecture Framework TOGOF 9.1   Solución Concepto Diagrama

Un diagrama Solution Concept ofrece una orientación de alto nivel de la solución que se prevé el fin de cumplir los objetivos de la participación de la arquitectura. En contraste con los esquemas más formales y detalladas de arquitectura desarrollado en las siguientes fases, el concepto de solución representa un "dibujo a lápiz" de la solución esperada al inicio del contrato. Este diagrama puede incorporar objetivos clave, requisitos y restricciones para la participación y también poner de relieve las áreas de trabajo para ser investigado con más detalle con el modelado de la arquitectura formal. Su propósito es rápidamente a bordo y alinear las partes interesadas de una iniciativa particular el cambio, de modo que todos los participantes entiendan lo que el compromiso de la arquitectura está tratando de lograr y cómo se espera que un enfoque de solución particular será satisfacer las necesidades de la empresa.

35.6.3 Fase B: Arquitectura de Negocios A continuación se describen los catálogos, matrices y diagramas que se pueden crear dentro de la Fase B (Business Architecture) como se indica en 8.5 Salidas . Catálogo Organización / Actor

El propósito del catálogo Organización / Actor es capturar una lista definitiva de todos los participantes que interactúan con él, incluidos los s y los propietarios de los sistemas de TI. El catálogo Organización / Actor se puede hacer referencia al elaborar los requisitos con el fin de comprobar la integridad. Por ejemplo, los requisitos para una aplicación que da servicio a los clientes se pueden probar por la totalidad mediante la verificación de exactamente qué tipos de clientes necesitan ser apoyados y si existen requisitos o restricciones particulares para tipos de . El / catalog Actor Organización contiene las siguientes entidades metamodelo: 




Actor



Ubicación (puede incluirse en este catálogo, si un catálogo independiente de la ubicación no se mantiene)

Conductor / Meta / Objetivo Catálogo

El propósito del Conductor / Meta / Objetivo catálogo es ofrecer una referencia de toda la Organización de cómo una organización responde a sus pilotos en la práctica a través de metas, objetivos, y (opcionalmente) las medidas. La publicación de una ruptura definitiva de los conductores, las metas y objetivos permite que las iniciativas de cambio dentro de la empresa para identificar las sinergias en toda la organización

Página 385 de 670

The Open Group Architecture Framework TOGOF 9.1   (por ejemplo, múltiples organizaciones que intentan lograr objetivos similares), que a su vez permiten a las partes interesadas para identificar e iniciativas de cambio vinculadas a alinear o consolidados. El Conductor / Meta / Objetivo catálogo contiene las siguientes entidades metamodelo: 




Conductor



Meta



Objetivo



Medida (pueden estar opcionalmente incluido)


El propósito del catálogo de papel es el de proporcionar una lista de todos los niveles de autorización o zonas dentro de una empresa. Con frecuencia, la seguridad de aplicaciones o el comportamiento se define en contra de los conceptos entendidos a nivel local de la autorización que crean consecuencias complejas e inesperadas cuando se combina en el escritorio del . Si se definen los roles, entendidos, y alineados en todas las organizaciones y aplicaciones, lo que permite una experiencia de más fluida y aplicaciones en general, más seguras, ya que los es no tengan que recurrir a soluciones alternativas con el fin de permitir a los s para llevar a cabo su trabajo. Además de apoyar la definición de seguridad para la empresa, el catálogo de funciones también forma un insumo clave para la identificación de los impactos de la organización de gestión del cambio, la definición de las funciones de trabajo, y la ejecución de la capacitación del final. Como cada rol implica el a una serie de funciones de la empresa, si alguna de estas funciones de la empresa se ven afectados, a continuación, cambiar será necesario el manejo, es posible que las responsabilidades organizativas que redefinirse, y puede ser necesaria la reconversión. El catálogo contiene las siguientes clases, entidades metamodelo: 

Papel

Business Service / Función catálogo

El propósito de el catálogo de servicios de negocios / función es la de proporcionar una descomposición funcional en una forma que se puede filtrar, informó sobre, y preguntó, como un suplemento a los diagramas de descomposición funcional gráficas. El catálogo de servicios de negocios / La función puede utilizarse para identificar las capacidades de una organización y para comprender el nivel de gobierno que se aplica a las funciones de una organización. Esta descomposición funcional se puede utilizar para identificar nuevas capacidades

Página 386 de 670

The Open Group Architecture Framework TOGOF 9.1   requeridas para apoyar el cambio de negocios o se puede usar para determinar el alcance de las iniciativas de cambio, aplicaciones o componentes de la tecnología. El catálogo de servicios de negocios / Función contiene las siguientes entidades metamodelo: 




Función comercial






Información de servicio del sistema (opcionalmente puede incluirse aquí)


El catálogo Ubicación proporciona un listado de todos los lugares en los que la empresa lleva a cabo operaciones de negocios o casas de activos arquitectónicamente relevantes, tales como los centros de datos o equipos de computación de final. El mantenimiento de una lista definitiva de los lugares permite iniciativas de cambio para definir rápidamente un alcance ubicación y para la prueba de integridad en la evaluación de los paisajes actuales o soluciones destinatarios propuestos. Por ejemplo, un proyecto para actualizar los sistemas operativos de escritorio deberá identificar todas las ubicaciones donde se utilizan los sistemas operativos de escritorio. Del mismo modo, cuando se están implementando nuevos sistemas, un diagrama de las ubicaciones es esencial con el fin de desarrollar estrategias de implementación adecuadas que comprenden tanto al como ubicación de la aplicación e identificar los problemas relacionados con la ubicación, como la internacionalización, localización, los impactos sobre los impactos de zona horaria de disponibilidad, distancia en latencia, los impactos de la red de ancho de banda, y el . El catálogo contiene Ubicación las siguientes entidades metamodelo: 

Ubicación

Proceso / Evento / Control / Catálogo de Productos

El proceso / evento / Control / Catálogo de productos proporciona una jerarquía de procesos, eventos que desencadenan los procesos, los productos procedentes de los procesos y controles que se aplican a la ejecución de los procesos. Este catálogo ofrece un complemento a cualquier diagrama de flujo de proceso que se crean y permite a una empresa que va a filtrar, informe y consulta a través de las organizaciones y procesos para identificar el alcance, en común, o impacto. Por ejemplo, el proceso / evento / Control / Catálogo de productos permite a una empresa para ver las relaciones de los procesos a los sub-procesos con el fin de identificar la cadena de impactos resultantes de cambiar un proceso de alto nivel. El proceso / evento / Control / Catálogo de productos incluye las siguientes entidades metamodelo:

Página 387 de 670


Proceso



Evento



Control



Producto

Contrato / Medida Catálogo

El catálogo Contract / Medida proporciona un listado de todos los contratos de servicio acordados y (opcionalmente) las medidas adjuntas a esos contratos. Forma la lista maestra de los niveles de servicio acordados para toda la empresa. El Contrato / catalog Medida contiene las siguientes entidades metamodelo: 




Información de servicio del sistema (opcional)



Contrato



Medida

Matriz de Interacción de Negocios

El propósito de esta matriz es representar las interacciones de la relación entre las organizaciones y funciones de negocio en toda la empresa. Comprender la interacción de negocios de una empresa es importante ya que ayuda a resaltar la cadena de valor y las dependencias en todas las organizaciones. La matriz de interacción de negocios muestra las siguientes entidades metamodelo y relaciones: 

Organización



Función comercial






Business Service comunica con relaciones de servicios empresariales



Servicios de Negocio depende de las relaciones de servicio de negocios

Matrix Actor / Rol

El propósito de esta matriz es mostrar que los actores realizan que los roles, el apoyo a la definición de los requisitos de seguridad y de cualificaciones.

Página 388 de 670

The Open Group Architecture Framework TOGOF 9.1   Comprender las relaciones actor-a roles es una herramienta de apoyo clave en la definición de las necesidades de capacitación, la configuración de seguridad del y la gestión del cambio organizacional. La matriz Actor / Rol muestra las siguientes entidades metamodelo y relaciones: 

Actor



Papel



Actor realiza relaciones de rol

Negocios Huella Diagrama

Un diagrama de negocios Huella describe los vínculos entre los objetivos de negocio, unidades organizativas, funciones de oficina y servicios, y los mapas de estas funciones a los componentes técnicos que entregan la capacidad requerida. Un diagrama de negocios Huella proporciona una trazabilidad clara entre un componente técnico y el objetivo comercial que satisface, a la vez que demuestra la propiedad de los servicios identificados. Un diagrama de negocios Huella demuestra solamente los hechos clave que relacionan funciones de la unidad de organización de los servicios de entrega y se utiliza como una plataforma de comunicación para los de categoría superior (CxO) las partes interesadas. Business Service / Diagrama de Información

El diagrama de Servicios de Negocio / Información muestra la información necesaria para apoyar uno o más servicios de oficina. El diagrama de Business Service / Information muestra los datos que se consume en o producido por un servicio de negocio y también puede mostrar la fuente de información. El diagrama de Business Service / Information muestra una representación inicial de la información incorporada dentro de la arquitectura y por lo tanto constituye una base para elaboración y perfeccionamiento dentro de la fase C (Arquitectura de Datos). Diagrama de Descomposición Funcional

El propósito del diagrama de descomposición funcional es mostrar en una sola página de las capacidades de una organización que son relevantes para la consideración deuna arquitectura . Mediante el examen de las capacidades de una organización desde una perspectiva funcional, es posible desarrollar rápidamente modelos de lo que hace la organización sin ser arrastrado a prolongar el debate sobre cómo la organización hace. Una vez que un diagrama básico de descomposición funcional se ha desarrollado, se hace posible a la capa de calor-maps en la parte superior de este diagrama para mostrar el alcance y las decisiones. Por ejemplo, la capacidad para ser implementadas en diferentes fases de un programa de cambio.

Página 389 de 670

The Open Group Architecture Framework TOGOF 9.1   Diagrama del ciclo de vida del producto

El propósito del diagrama del ciclo de vida del producto es ayudar en la comprensión de los ciclos de vida de las entidades clave dentro de la empresa. Entender los ciclos de vida de productos es cada vez más importante con respecto a las preocupaciones ambientales, la legislación y la reglamentación cuando los productos deben ser rastreados desde su fabricación hasta su eliminación. Del mismo modo, las organizaciones que crean productos que involucran información personal o sensible deben tener un conocimiento detallado de la vida útil del producto durante el desarrollo de la arquitectura de negocios con el fin de garantizar el rigor en el diseño de los controles, procesos y procedimientos. Ejemplos de esto incluyen tarjetas de crédito, tarjetas de débito, tarjetas de la tienda / de fidelidad, tarjetas inteligentes, credenciales de identidad de (documentos de identidad, pasaportes, etc.) Meta / Objetivo Diagrama / Servicio

El propósito de un diagrama de Meta / Objetivo / Servicio es definir las formas en que un servicio contribuye a la consecución de una visión o estrategia de negocio. Los servicios se asocian con los controladores, metas, objetivos y medidas que apoyan, lo que permite a la empresa a entender que los servicios contribuyen a aspectos similares de rendimiento empresarial. El diagrama de Meta / Objetivo / servicio también proporciona entrada cualitativa sobre lo que constituye un alto rendimiento para un servicio en particular.

Diagrama de negocios de casos de uso

Un diagrama de negocios de caso de uso muestra las relaciones entre consumidores y proveedores de servicios de oficina. Servicios a empresas son consumidos por los actores u otros servicios de negocios y el diagrama de negocios de caso de uso proporciona riqueza agregada al describir la capacidad del negocio mediante la ilustración de cómo y cuándo se utiliza esa capacidad. El propósito del diagrama de casos de uso de negocios es ayudar a describir y validar la interacción entre los actores y sus roles en los procesos y funciones. Como la arquitectura avanza, el caso de uso puede evolucionar desde el nivel de negocio para incluir datos, aplicaciones, y detalles de tecnología. Negocio casos de uso de arquitectura también se pueden volver a utilizar en los sistemas de trabajo de diseño. Organización Descomposición Diagrama

Un diagrama de Organización Descomposición describe los vínculos entre actores, roles, y la ubicación dentro de un árbol de organización. Un mapa de la organización debe proporcionar una cadena de mando de los propietarios y encargados de tomar decisiones en la organización. Aunque no es la intención de la Organización diagrama de descomposición vincular meta de la organización, debería ser posible vincular de forma intuitiva las metas a las partes interesadas en el diagrama de la Organización de descomposición.

Página 390 de 670

The Open Group Architecture Framework TOGOF 9.1   Diagrama de Flujo de Proceso

El propósito del diagrama de flujo de proceso es representar todos los modelos y las asignaciones relacionadas con la entidad metamodelo proceso. Los diagramas de flujo de procesos muestran el flujo secuencial de control entre las actividades y pueden utilizar las técnicas de natación carriles para representar la propiedad y la realización de los pasos del proceso. Por ejemplo, la aplicación que soporta una fase del proceso se puede mostrar como un baño carriles. Además de mostrar una secuencia de la actividad, flujos de proceso también pueden ser utilizados al detalle los controles que se aplican a un proceso, los eventos que desencadenan o resultan de la finalización de un proceso, y también los productos que se generan a partir de la ejecución del proceso. Los diagramas de flujo de proceso son útiles en la elaboración de la arquitectura con especialistas en la materia, ya que permiten al especialista para describir "cómo el trabajo está hecho" para una función en particular. A través de este proceso, cada paso del proceso puede llegar a ser una función de grano más fino y puede, a su vez ser elaborado como un proceso. Diagrama de eventos

El propósito del diagrama de eventos es para representar la relación entre los eventos y proceso. Ciertos eventos - como la llegada de cierta información (por ejemplo, el cliente envía pedido de cliente) o de un determinado punto en el tiempo (por ejemplo, al final del trimestre fiscal) necesitan causa el trabajo y ciertas acciones que deben emprenderse en el negocio. Éstos se refieren a menudo como "eventos de negocios" o simplemente "eventos" y se consideran como factores desencadenantes de un proceso. Es importante tener en cuenta que el evento tiene que desencadenar un proceso y generar una respuesta de negocios o resultado.

35.6.4 Fase C: Arquitectura de Datos A continuación se describen los catálogos, matrices y diagramas que se pueden crear dentro de la fase C (Arquitectura de datos) que se enumeran en 10.5 Salidas . Catálogo de Entity Data / componente de datos

El propósito del catálogo de Entity Data / componente de datos es identificar y mantener una lista de todo el uso de los datos en toda la empresa, incluyendo las entidades de datos y también los componentes de datos donde se almacenan las entidades de datos. Un catálogo de Entity Data / componente de datos acordado apoya la definición y aplicación de políticas de gestión de la información y gobierno de datos y también fomenta el intercambio de datos eficaz y reutilización. El catálogo Entity Data / componente de datos contiene las siguientes entidades metamodelo: 

Entity Data



Componente lógica de datos



Componente Físico de Datos

Página 391 de 670

The Open Group Architecture Framework TOGOF 9.1   Entity Data / Matrix Función comercial

El propósito de la matriz de funciones de Entity Data / Negocios es ilustrar las relaciones entre las entidades de datos y funciones de negocios dentro de la empresa.Funciones de negocio se apoyan en los servicios empresariales con límites definidos de forma explícita y contarán con el apoyo y se dieron cuenta de los procesos de negocio. El mapeo de la relación de funciones de Entity DataBusiness permite lo siguiente a tener lugar: 

Asignar la propiedad de entidades de datos a las organizaciones



Comprender los datos y las necesidades de intercambio de información de los servicios de negocio



Apoyar el análisis de las deficiencias y determinar si las entidades de datos se han perdido y es necesario crear



Definir solicitud de origen, solicitud de registro, y la aplicación de referencia para entidades de datos



Habilitar el desarrollo de los programas de gobierno de datos en toda la empresa (establecer de datos, el desarrollo de estándares de datos pertinentes a la función de negocios, etc)

La matriz de datos de entidad / Función negocios muestra las siguientes entidades y relaciones: 

Entity Data



Función comercial



Relación Entity Data para ser propietario de unidad organizativa

Aplicación / Data Matrix

El propósito de la matriz de aplicación / datos es para representar la relación entre las aplicaciones (es decir, componentes de la aplicación) y las entidades de datos que se tiene y actualizados por ellos. Las solicitudes serán crear, leer, actualizar y eliminar entidades específicas de datos que se asocian con ellos. Por ejemplo, una aplicación de CRM será crear, leer, actualizar y eliminar información de la entidad cliente. Las entidades de datos en un entorno de paquetes / servicios empaquetados se pueden clasificar como datos maestros, datos de referencia, datos de transacciones, datos de contenido y datos históricos. Las aplicaciones que operan en las entidades de datos incluyen aplicaciones transaccionales, aplicaciones de gestión de la información y las aplicaciones de almacenamiento empresarial. El mapeo de la relación componente de aplicación-Entity Data es un paso importante, ya que permite lo siguiente a tener lugar: 

Asigne de datos para aplicaciones específicas en la organización

Página 392 de 670


Entender el grado de duplicación de datos en diferentes aplicaciones, y la escala del ciclo de vida de los datos



Entender donde los mismos datos se actualiza por diferentes aplicaciones



Apoyar el análisis de las deficiencias y determinar si alguna de las aplicaciones están desaparecidos y como consecuencia es necesario crear

La matriz de aplicaciones / datos es una tabla de dos dimensiones con Logical componente de aplicación en un eje y Entity Data en el otro eje. Diagrama conceptual de datos

El propósito fundamental del esquema conceptual de datos es representar las relaciones entre las entidades de datos críticos dentro de la empresa. Este esquema se ha desarrollado para atender las preocupaciones de los interesados del negocio. Las técnicas utilizadas son: 

Modelos de relación Entidad



Diagramas de clases UML simplificado


El propósito fundamental del esquema lógico de datos es mostrar vistas lógicas de las relaciones entre las entidades de datos críticos dentro de la empresa. Este esquema ha sido desarrollado para atender las preocupaciones de: 

Los desarrolladores de aplicaciones



Los diseñadores de bases de datos


El propósito del diagrama de Divulgación de Datos es mostrar la relación entre la entidad de datos, servicio de negocios, y componentes de la aplicación. El diagrama muestra cómo las entidades lógicas se han de realizar físicamente por componentes de la aplicación. Esto permite dimensionamiento eficaz para llevar a cabo y la huella de TI para ser refinado. Por otra parte, mediante la asignación de valor para el negocio a los datos, una indicación de la criticidad del negocio de componentes de la aplicación se puede ganar. Además, el diagrama puede mostrar la replicación de datos y la propiedad de las aplicaciones de la referencia principal para los datos. En este caso, puede mostrar dos copias y la relación amo-copia entre ellos. Este diagrama puede incluir servicios; es decir, los servicios encapsulan datos y residen en una aplicación o servicios que se encuentran en una aplicación y acceder a datos encapsulados dentro de la aplicación. Diagrama de seguridad de datos

Página 393 de 670

The Open Group Architecture Framework TOGOF 9.1   Los datos se consideran como un activo para la empresa y la seguridad de datos, simplemente significa asegurar que los datos de la empresa no está comprometida y que el a la misma se controla adecuadamente. El propósito del diagrama de seguridad de datos es describir qué actor (persona, organización o sistema) pueden acceder a que los datos empresariales. Esta relación se puede mostrar en forma de matriz entre dos objetos o puede mostrarse como una asignación. El diagrama también se puede utilizar para demostrar el cumplimiento de las leyes de privacidad de datos y demás normativa aplicable (HIPAA, SOX, etc). Este diagrama también debe considerar las implicaciones de confianza donde los socios de una empresa o de terceros pueden tener a los sistemas de la empresa, como una situación subcontratada donde la información puede ser istrado por otras personas e incluso puede ser alojado en un país diferente. Diagrama de migración de datos

La migración de datos es fundamental en la aplicación de un paquete o una solución basada en los servicios empaquetados. Esto es particularmente cierto cuando una aplicación heredada existente se reemplaza por un paquete o una empresa se va a migrar a una mayor huella de paquetes / servicios empaquetados. Paquetes tienden a tener su propio modelo de datos y durante la migración de datos pueden necesitar los datos de aplicaciones heredadas a ser transformado antes de cargarlos en el paquete. Actividades de migración de datos por lo general implicará los siguientes pasos: 

Extraer los datos de las aplicaciones de código (sistemas de referencia)



Perfil de datos de origen



Realizar las operaciones de transformación de datos, incluidos los procesos de calidad de datos:



o

Estandarizar, normalizar, los datos-de duplicado de origen (limpieza de datos)

o

Partido, fusionar y consolidar datos de diferentes fuentes (s)

o

Asignaciones de fuente a destino

Cargue en aplicaciones de destino (sistemas de destino)

El propósito del diagrama de migración de datos es para mostrar el flujo de datos desde la fuente a las aplicaciones de destino. El diagrama proporcionará una representación visual de la propagación de fuentes / objetivos y servir como herramienta de auditoría de datos y el establecimiento de la trazabilidad. Este diagrama puede ser elaborado o mejorado como se detalla en caso necesario. Por ejemplo, el diagrama puede contener sólo una disposición general de la migración de paisaje o podría entrar en el nivel de elementos de metadatos aplicación individual de detalle.

Página 394 de 670

The Open Group Architecture Framework TOGOF 9.1   Diagrama del ciclo de vida de datos

El diagrama de datos del ciclo de vida es una parte esencial de la gestión de los datos de negocio a lo largo de su ciclo de vida, desde su concepción hasta su eliminación dentro de las limitaciones del proceso de negocio. Los datos se considera como una entidad en sí mismo, desvinculado de los procesos de negocio y de la actividad. Cada cambio en el estado está representado en el diagrama que puede incluir el evento o reglas que desencadenan que el cambio en el estado. La separación de los datos de proceso permite a los requisitos de datos comunes que se identifiquen, que permite el intercambio de recursos para alcanzar con mayor eficacia.

35.6.5 Fase C: Arquitectura de aplicaciones A continuación se describen los catálogos, matrices y diagramas que se pueden crear dentro de la fase C (Application Architecture) como se indica en 11.5 Salidas . Catálogo cartera de aplicaciones

La finalidad de este catálogo es identificar y mantener una lista de todas las aplicaciones de la empresa. Esta lista ayuda a definir el alcance horizontal de las iniciativas de cambio que puedan afectar a determinados tipos de aplicaciones. Un portafolio de aplicaciones permite acordado un conjunto estándar de aplicaciones que se definan y gobernados. El catálogo del portafolio de aplicaciones proporciona una base sobre la cual basar las matrices y diagramas restantes. Normalmente es el punto de inicio de la fase de Arquitectura de la aplicación. El catálogo de la Cartera de Aplicaciones contiene las siguientes entidades metamodelo: 

Servicio de Sistema de Información



Lógico componente de aplicación



Física componente de aplicación


El propósito de el catálogo de interfaz es el alcance y documentar las interfaces entre las aplicaciones que permitan a las dependencias globales entre aplicaciones a ser de ámbito tan pronto como sea posible. Las solicitudes serán crear, leer, actualizar y eliminar datos en otras aplicaciones; esto se logrará por algún tipo de interfaz, ya sea a través de un archivo por lotes que se carga periódicamente, una conexión directa con la base de datos de otra aplicación, o por medio de algún tipo de API o servicio web. El mapeo de la relación entidad de la aplicación del Componente-aplicación es un paso importante, ya que permite lo siguiente a tener lugar:

Página 395 de 670


Entender el grado de interacción entre las aplicaciones, identificando aquellos que son esenciales en términos de sus dependencias en otras aplicaciones



Entender el número y tipos de interfaces entre aplicaciones



Entender el grado de duplicación de interfaces entre aplicaciones



Identificar las posibilidades de simplificación de las interfaces cuando se considera la cartera de aplicaciones de destino




El catálogo de interfaz contiene las siguientes entidades metamodelo: 

Lógico componente de aplicación



Física componente de aplicación



Aplicación comunica con relación aplicación

Aplicación / Matrix Organización

El propósito de esta matriz es representar la relación entre las aplicaciones y unidades de la organización dentro de la empresa. Funciones de negocio son realizadas por unidades organizativas. Algunas de las funciones y servicios prestados por las unidades organizativas serán apoyados por las aplicaciones. El mapeo de la relación Aplicación Unidad Componente-Organización es un paso importante, ya que permite lo siguiente a tener lugar: 

Asignar el uso de aplicaciones a las unidades de la organización que realizan funciones empresariales



Comprender los requisitos de soporte de aplicaciones de los servicios de negocios y procesos llevados a cabo por una unidad de organización






Definir el conjunto de aplicaciones que utiliza una unidad de organización en particular

La matriz de Aplicación / Organización es una tabla de dos dimensiones con el componente lógico de aplicación / física en un eje y unidad de organización en el otro eje. La relación entre estas dos entidades es un compuesto de un número de relaciones metamodelo que necesitan validar: 

Unidades de Organización de poseer Servicios



Actores que pertenecen a unidades de organización utilizan Servicios

Página 396 de 670


Los servicios se realizan por componentes de aplicación lógicas / físicas

Matrix Papel / Aplicación

El propósito de la matriz de Papel / Aplicación es describir la relación entre las aplicaciones y los roles de negocio que los utilizan en la empresa. La gente en una organización interactúan con las aplicaciones. Durante esta interacción, estas personas asumen un papel específico para realizar una tarea; por ejemplo, el comprador del producto. El mapeo de la relación de componentes-función de aplicación es un paso importante, ya que permite que el siguiente tenga lugar: 

Asignar el uso de aplicaciones a las funciones específicas en la organización



Entender los requisitos de seguridad de la aplicación de los servicios y procesos de apoyo a la función de negocio, y se les trata de acuerdo con la política actual






Definir el conjunto de aplicaciones que utiliza una función de negocio en particular; esencial en cualquier movimiento hacia la computación basada en roles

La matriz de roles / aplicaciones es una tabla de dos dimensiones con Logical componente de aplicación en un eje y Papel en el otro eje. La relación entre estas dos entidades es un compuesto de un número de relaciones metamodelo que necesitan validar: 

Papel accede Función



Función es limitado por servicio




Matrix Aplicación / Función

El propósito de la matriz de Uso / función es representar la relación entre las aplicaciones y funciones de negocios dentro de la empresa. Funciones de negocio son realizadas por unidades organizativas. Algunas de las funciones y los servicios financieros serán mantenidos por las aplicaciones. El mapeo de la relación de componentes-función de aplicación es un paso importante, ya que permite lo siguiente a tener lugar: 

Asignar el uso de aplicaciones a las funciones de negocio que son compatibles con ellos



Comprender los requisitos de soporte de aplicaciones de los servicios de negocios y procesos llevados a cabo

Página 397 de 670





Definir el conjunto de aplicaciones utilizado por una empresa particular la función

La matriz de aplicación / función es una tabla de dos dimensiones con lógica componente de aplicación en un eje y Función en el otro eje. La relación entre estas dos entidades es un compuesto de un número de relaciones metamodelo que necesitan validar: 

Función es limitado por servicio




Aplicación matriz de interacción

El propósito de la matriz de interacción de aplicaciones es para representar relaciones de comunicación entre aplicaciones. El mapeo de las interacciones de las aplicaciones muestra en la matriz de formar el equivalente de la Catálogo de interfaz o un diagrama de comunicaciones de la aplicación. La matriz de la interacción de aplicaciones es una tabla de dos dimensiones con servicios de aplicaciones, Logical componente de aplicación, y Física componente de aplicación en las filas y las columnas de la tabla. Las relaciones representadas por esta matriz incluyen: 

Application Service consume Application Service



Lógico componente de aplicación se comunica con Logical componente de aplicación



Física componente de aplicación se comunica con Física componente de aplicación

Aplicación Diagrama Comunicación

El propósito del diagrama de comunicaciones de la aplicación es para representar todos los modelos y las asignaciones relacionadas con la comunicación entre las aplicaciones en la entidad metamodelo. Muestra los componentes de aplicaciones e interfaces entre los componentes. Las interfaces pueden estar asociados con las entidades de datos en su caso. Las aplicaciones pueden estar asociados con los servicios de negocio en su caso. La comunicación debe ser lógica y sólo debe mostrar la tecnología intermedia donde es arquitectónicamente relevante. Solicitud y Ubicación Diagrama

El Esquema de aplicación y Ubicación muestra la distribución geográfica de las solicitudes. Se puede utilizar para mostrar donde las aplicaciones se utilizan por el final; la

Página 398 de 670

The Open Group Architecture Framework TOGOF 9.1   distribución de donde se ejecuta y / o entrega en los escenarios de cliente ligero de la aplicación host; la distribución de donde se desarrollan aplicaciones, probados y puestos en libertad; etcétera El análisis puede revelar oportunidades para la racionalización, así como la duplicación y / o lagunas. El propósito de este diagrama es representar claramente las ubicaciones de la empresa de la que los s de negocios por lo general interactúan con las aplicaciones, sino también la ubicación de alojamiento de la infraestructura de aplicaciones. El diagrama permite: 

Identificación del número de instancias de paquetes necesarios para soportar suficientemente la población de s que pueden estar dispersas geográficamente



Estimación del número y el tipo de licencias de para el paquete u otro software



Estimación del nivel de apoyo necesario para los s y la ubicación de centro de apoyo



Selección de las herramientas de istración del sistema, la estructura y el sistema de gestión necesarios para apoyar las empresas los s / clientes / socios tanto a nivel local como a distancia



La planificación adecuada para los componentes tecnológicos de la empresa, es decir, el ancho de banda tamaño del servidor y de la red, etc



Consideraciones sobre el rendimiento, mientras que la implementación de soluciones de arquitectura de aplicaciones y tecnología

Normalmente, los s interactúan con las aplicaciones en una variedad de maneras; por ejemplo: 

Para apoyar las operaciones de los negocios del día a día



Para participar en la ejecución de un proceso de negocio



Para tener a la información (búsqueda, lectura)



Para desarrollar la aplicación



istrar y mantener la aplicación

Diagrama de Casos de Uso

Un Esquema de aplicación de casos de uso muestra las relaciones entre consumidores y proveedores de servicios de aplicación. Los servicios de aplicación son consumidos por los actores u otros servicios de la aplicación y el diagrama de casos de uso de aplicaciones proporciona riqueza agregada en la descripción de funciones de la aplicación mediante la ilustración de cómo y cuándo se utiliza esa funcionalidad.

Página 399 de 670

The Open Group Architecture Framework TOGOF 9.1   El propósito del diagrama de aplicación de casos de uso es ayudar a describir y validar la interacción entre los actores y sus roles con las aplicaciones. Como la arquitectura avanza, el caso de uso puede evolucionar a partir de información funcional para incluir detalles realización técnica. Aplicación casos de uso también pueden ser reutilizadas en los sistemas más detallado trabajo de diseño. Empresa Manejabilidad Diagrama

El diagrama muestra cómo la empresa de istración de una o más aplicaciones interactúan con aplicaciones y tecnología de componentes que soportan la gestión operativa de una solución. Este diagrama es realmente un filtro en el diagrama de comunicaciones de la aplicación, en concreto para el software de clase de gestión empresarial. El análisis puede revelar duplicaciones y lagunas y oportunidades en la operación de gestión de servicios de TI de una organización. Realización de proceso / aplicación Diagrama

El propósito del diagrama Realización Proceso / aplicación es de representar claramente la secuencia de eventos cuando múltiples aplicaciones están implicados en la ejecución de un proceso de negocio. Realza el diagrama de comunicaciones de la aplicación añadiéndole las restricciones de secuenciación, y los puntos de la mano-off entre lotes y procesamiento en tiempo real. Sería identificar secuencias complejas que podrían simplificarse, e identificar posibles puntos de racionalización en la arquitectura con el fin de proporcionar información más oportuna a los s de negocios. También puede identificar las mejoras en la eficiencia de procesos que pueden reducir el tráfico de la interacción entre aplicaciones. Software Diagrama Ingeniería

El diagrama de la Ingeniería del Software rompe aplicaciones en paquetes, los módulos, los servicios y las operaciones desde una perspectiva de desarrollo. Permite a un análisis más detallado del impacto en la planificación de las etapas de la migración, y el análisis de las oportunidades y soluciones. Es ideal para los equipos de desarrollo de aplicaciones y equipos de gestión de aplicaciones en la gestión de los entornos de desarrollo complejos. Diagrama de aplicación de Migración

El diagrama de Migración de aplicaciones identifica la migración de aplicaciones de línea de base a los componentes de la aplicación. Permite a una estimación más precisa de los costos de migración al mostrar con precisión qué se deben asignar entre las etapas de migración de aplicaciones e interfaces.

Página 400 de 670

The Open Group Architecture Framework TOGOF 9.1   Sería identificar aplicaciones temporales, áreas de estacionamiento, y la infraestructura necesaria para apoyar las migraciones (por ejemplo, entornos de ejecución paralelas, etc.) Diagrama de distribución de software

El diagrama de distribución de software, se muestra cómo el software de aplicación se estructura y se distribuye a través de la finca. Es útil en la actualización de los sistemas o de los proyectos de consolidación de aplicaciones. Este diagrama muestra cómo las aplicaciones físicas se distribuyen a través de la tecnología física y de la ubicación de esa tecnología. Esto permite una visión clara de cómo se encuentra alojado el software, sino que también permite que gestiona el personal de operaciones pueda comprender como que el software de aplicación se mantiene una vez instalado.

35.6.6 Fase D: Architecture Tecnología La siguiente sección describe los catálogos, matrices y diagramas que se pueden crear dentro de la Fase D (Architecture Technology) que se enumeran en 12.5 Salidas .

Catálogo de Estándares de Tecnología

El catálogo de Estándares de Tecnologías documenta las normas acordadas para la tecnología en toda la empresa que cubren las tecnologías y las versiones, los ciclos de vida de la tecnología, y los ciclos de actualización de la tecnología. Dependiendo de la organización, esto también puede incluir la ubicación o dominio específico de información comercial estándares. Este catálogo ofrece una visión general de las tecnologías estándares de la empresa que son o pueden ser desplegados, y también ayuda a identificar las discrepancias en toda la empresa. Si los estándares de tecnología están actualmente en vigor, se aplican estos para el catálogo Cartera Tecnológica para obtener una visión de base del cumplimiento de los estándares tecnológicos. El catálogo Cartera Tecnológica contiene las siguientes entidades metamodelo: 

Plataforma de Servicios



Lógico Componente Tecnología



Componente Tecnología Física

Página 401 de 670

The Open Group Architecture Framework TOGOF 9.1   Catálogo Cartera Tecnológica

La finalidad de este catálogo es identificar y mantener una lista de toda la tecnología en uso en toda la empresa, incluyendo hardware, software de infraestructura y software de aplicación. Una cartera de tecnología acordado apoya la gestión del ciclo de vida de productos de tecnología y versiones, y también es la base para la definición de estándares de tecnología. El catálogo Cartera Tecnológica proporciona una base sobre la cual basar las matrices y diagramas restantes. Normalmente es el punto de inicio de la fase de Tecnología de la Arquitectura. Registros de tecnología y bases también proporcionan aportación a este catálogo de una línea de base y se dirigen a la perspectiva. Tecnologías en el catálogo deben clasificarse en contra de la tecnología Modelo de Referencia TOGAF (TRM) - véase la parte VI , 43. Fundación Arquitectura: Modelo de referencia técnica - la extensión del modelo según sea necesario para ajustarse a la clasificación de los productos de la tecnología en uso. El catálogo Cartera Tecnológica contiene las siguientes entidades metamodelo: 

Plataforma de Servicios



Lógico Componente Tecnología



Componente Tecnología Física

Aplicación / Matrix Tecnología

La matriz de Aplicación / Tecnología documenta el mapeo de aplicaciones para la plataforma tecnológica. Esta matriz debe estar alineada con y complementar uno o varios diagramas de descomposición de la plataforma. La Aplicación / matriz Tecnología muestra: 

Componentes lógicos de aplicación / Física



Servicios, Componentes Tecnológicos lógicos y Componentes Tecnología Físicas



Tecnología del componente físico se da cuenta de las relaciones de componente de aplicación de Física

Entornos y diagrama de las ubicaciones

El diagrama de ambientes y zonas representa qué lugares albergan las aplicaciones, lo que identifica las tecnologías y / o aplicaciones que se utilizan en las ubicaciones y, finalmente, identifica los lugares desde los que los s de negocios por lo general interactúan con las aplicaciones.

Página 402 de 670

The Open Group Architecture Framework TOGOF 9.1   Este diagrama también debe mostrar la existencia y ubicación de los diferentes entornos de implementación, incluyendo entornos no productivos, como el desarrollo y la producción de pre. Plataforma Descomposición Diagrama

El diagrama de la Plataforma de descomposición representa la plataforma tecnológica que soporta las operaciones de la Arquitectura de Sistemas de Información. El esquema cubre todos los aspectos de la plataforma de infraestructura y proporciona una visión general de la plataforma tecnológica de la empresa. El diagrama se puede ampliar para mapear la plataforma de tecnología para componentes de aplicación apropiadas dentro de un área funcional o proceso específico. Este diagrama puede mostrar detalles de las especificaciones, como las versiones de producto, número de U, etc, o simplemente podría ser un "ojo-chart" informal que proporciona una visión general del entorno técnico. El diagrama debe mostrar claramente las aplicaciones empresariales y la plataforma de tecnología para cada área de aplicación más se puede descomponer de la siguiente manera: 



Hardware: o

Componentes tecnológicos lógicos (con atributos)

o

Componentes tecnológicos física (con atributos)

Software: o

Componentes tecnológicos lógicos (con atributos)

o

Componentes tecnológicos física (con atributos)

Dependiendo del alcance de la obra de arquitectura empresarial, la tecnología de la información adicional entre plataformas (por ejemplo, comunicaciones, telecomunicaciones y la información de video) se puede abordar. Diagrama de Procesamiento

El diagrama de procesamiento se centra en unidades de despliegue de código / configuración y cómo éstas se implementan en la plataforma tecnológica. Una unidad de implementación representa la agrupación de las funciones de negocios, servicio, o componentes de la aplicación. El diagrama de procesamiento se dirige a la siguiente: 

Que deben ser agrupados conjunto de componentes de la aplicación para formar una unidad de despliegue



Como una unidad de despliegue conecta / interactúa con otro (LAN, WAN, y los protocolos aplicables)



Como formas de configuración de la aplicación y uso generan requerimientos de carga o de capacidad para los distintos componentes de la tecnología

La organización y agrupación de unidades de implementación depende de las preocupaciones de separación de la presentación, lógica de negocio y almacenamiento de datos capas y los requisitos

Página 403 de 670

The Open Group Architecture Framework TOGOF 9.1   de nivel de servicio de los componentes. Por ejemplo, unidad de despliegue capa de presentación se agrupa en base a la siguiente: 

Los componentes de aplicación que proporcionan funciones de interfaz de o de de s



Los componentes de aplicación que se diferencian por ubicación y funciones de

Hay varias consideraciones para determinar cómo se agrupan los componentes de aplicaciones. Cada unidad de despliegue se compone de sub-unidades, tales como: 

Instalación : Parte que contiene el código ejecutable o configuración de paquetes (en el caso de los paquetes).



Ejecución : el componente de la aplicación con su estado asociado en tiempo de ejecución.



Persistencia : Los datos que representa el estado persistente de la componente de la aplicación.

Por último, estas unidades de implementación se implementan en los componentes tecnológicos y dedicar o compartidos (estación de trabajo, servidor web, servidor de aplicaciones o servidor de base de datos, etc.) Es importante tener en cuenta que el procesamiento de la tecnología puede influir y repercutir en la definición de servicios y granularidad. Red Informática / Hardware Diagrama

A partir de la transformación de los sistemas cliente-servidor de mainframes y más tarde con la llegada del e-Business y J2EE, las grandes empresas movido principalmente en un entorno distribuido de computación en red altamente red basada en servidores de seguridad y zonas desmilitarizadas. En la actualidad, la mayoría de las aplicaciones tienen un front-end web y, mirando a la arquitectura de implementación de estas aplicaciones, es muy común encontrar tres capas distintas en el panorama de la red; a saber, una capa de presentación de la tela, una lógica de negocio o capa de aplicación, y una capa de almacenamiento de datos back-end. Es una práctica común para las aplicaciones que se desplegarán y alojados en un entorno de infraestructura compartida y común. Por lo que es muy crítico para documentar la correspondencia entre las aplicaciones lógicas y los componentes de la tecnología (por ejemplo, servidores) que apoya la aplicación tanto en los entornos de desarrollo y producción. El propósito de este diagrama es para mostrar la vista lógica "como desplegado" de componentes de aplicaciones lógicas en un entorno informático de red distribuida. El diagrama es útil para las siguientes razones: 

Habilitar la comprensión de que la aplicación se implementa en donde en el entorno informático de red distribuida



El establecimiento de la autorización, la seguridad y el a estos componentes de la tecnología



Entender la Arquitectura Tecnología que soporta las aplicaciones durante la resolución de problemas y solución de problemas

Página 404 de 670


Aislar los problemas de rendimiento encontradas por las aplicaciones, determine si es relacionado con el código de la aplicación o relacionada con la plataforma de la tecnología, y realizar la actualización necesaria para los componentes específicos de la tecnología física



Identificar las áreas de optimización a medida que las nuevas tecnologías están disponibles que eventualmente reducir costos



Habilitar application / tecnología de auditación y acreditar el cumplimiento de las normas de tecnología de la empresa



Servir como una herramienta importante para introducir cambios en la arquitectura de la tecnología, de tal modo apoyando la gestión del cambio efectiva



Establecer la trazabilidad y el cambio de dirección de punto final de la aplicación mientras se mueve la aplicación ya sea de un entorno compartido de un entorno dedicado o viceversa

El alcance del diagrama puede ser definido apropiadamente para cubrir una aplicación específica, la función de negocios, o toda la empresa. Si es elegido para ser desarrollado en el ámbito de la empresa, entonces el panorama de la informática de la red puede ser representado de una manera agnóstica aplicación también. Comunicaciones Diagrama Ingeniería

El diagrama de Ingeniería de Comunicaciones se describen los medios de comunicación - el método de envío y recepción de información - entre estos activos en la Arquitectura de Tecnología; siempre que la selección de paquetes de soluciones en las arquitecturas anteriores imponer requisitos específicos sobre las comunicaciones entre las aplicaciones. El diagrama de Ingeniería de Comunicaciones tendrá conexiones lógicas entre el cliente y componentes de servidor y de identificar los límites de la red y la infraestructura de red necesaria para implementar físicamente esas conexiones. No describe el formato de la información o el contenido, pero se ocupará de cuestiones de protocolo y de capacidad.

35.6.7 Fase E: Oportunidades y Soluciones La siguiente sección describe los catálogos, matrices y diagramas que se pueden crear dentro de la Fase E (Oportunidades y Soluciones) que se enumeran en 13.5 Salidas . Proyecto Diagrama de Contexto

Un diagrama de contexto del proyecto se muestra el alcance de un paquete de trabajo para ser implementado como parte de un plan más amplio de transformación. El diagrama de contexto del proyecto vincula un paquete de trabajo de las organizaciones, funciones, servicios, procesos, aplicaciones, datos y tecnología que se agrega, se quita o afectado por el proyecto. El diagrama de contexto del proyecto es también una valiosa herramienta para la gestión de la cartera de proyectos y la movilización de proyectos. Diagrama de Beneficios

Página 405 de 670

The Open Group Architecture Framework TOGOF 9.1   El diagrama muestra Beneficios oportunidades identificadas en la definición de la arquitectura, que se clasifica en función de su tamaño relativo, el beneficio y la complejidad. Este diagrama puede ser utilizado por los interesados para hacer la selección, priorización y secuenciación de las decisiones sobre las oportunidades identificadas.

Gestión 35.6.8 Requisitos La siguiente sección describe los catálogos, matrices y diagramas que se pueden crear dentro de la fase de gestión de requisitos que se enumeran en 17.5 Salidas . Requisitos del catálogo

El catálogo Requisitos capta las cosas que la empresa tiene que hacer para cumplir con sus objetivos. Requisitos generados a partir de la arquitectura compromisos se aplican normalmente a través de las iniciativas de cambio identificados y con ámbito en la Fase E (Oportunidades y Soluciones). Los requisitos también pueden ser utilizados como una herramienta de control de calidad para asegurarse de que una arquitectura particular, es apto para el propósito (es decir, la arquitectura puede cumplir todos los requisitos identificados). El catálogo contiene los requisitos de las siguientes entidades metamodelo: 

Requisito



Asunción



Restricción



Brecha

35.7 Vistas Arquitectura recomendados para ser desarrollados Parte III , 24. Gestión de los grupos de interés se presenta un resumen de los principales grupos de interés que se encuentran normalmente en el desarrollo de la arquitectura empresarial. Los probables preocupaciones de cada grupo de interés también son identificados junto con los artefactos pertinentes (catálogos, matrices y diagramas). Los puntos de vista de arquitectura, y puntos de vista correspondientes, que se pueden crear para apoyar cada uno de estos grupos de interés se dividen en las siguientes categorías: 

Vistas Arquitectura Profesiones, que abordan las preocupaciones de los s del sistema, y describen los flujos de información empresarial entre las personas y los procesos de negocio



Puntos de vista de arquitectura de datos, que responden a las preocupaciones de los diseñadores de bases de datos y es de bases de datos e ingenieros de sistemas responsables de desarrollo e integración de los distintos componentes de bases de datos del sistema



Vistas arquitectura de la aplicación, que abordan las preocupaciones de los sistemas y software ingenieros responsables del desarrollo y la integración de los diversos componentes de software de aplicación del sistema de

Página 406 de 670


Vistas Arquitectura Tecnología, que abordan las preocupaciones de los compradores (el personal de adquisiciones responsables de la adquisición de la Commercial Off-The-Shelf (COTS) de software y hardware que se incluirán en el sistema), el personal de operaciones, es de sistemas y es de sistemas

En las siguientes subsecciones TOGAF presenta algunas vistas recomendadas, algunos o todos de los cuales pueden ser apropiadas en un desarrollo de la arquitectura en particular. Esto no pretende ser un conjunto exhaustivo de puntos de vista, sino simplemente como un punto de partida. Los descritos podrán complementarse con visitas adicionales según sea necesario. Este material debe ser considerado como guías para el desarrollo y el tratamiento de una vista, no como una definición completa de un punto de vista. Los artefactos identificados en 35.6 Architectural Artifacts por fase se pueden utilizar para hacer frente a las preocupaciones específicas de los grupos de interés, y en algunos casos los artefactos se pueden utilizar con la vista del mismo nombre; por ejemplo, el diagrama de Ingeniería de Software, Ingeniería de Comunicaciones diagrama, y el diagrama de la Empresa de istración. Cada subsección se describen los grupos de interés relacionados con la vista, sus preocupaciones y las entidades modeladas y el lenguaje utilizado para describir la vista (el punto de vista). El mirador ofrece conceptos de arquitectura de los diferentes puntos de vista, incluidos los componentes, interfaces y asignación de los servicios esenciales para la vista. Los idiomas punto de vista, los métodos analíticos, y de modelado métodos asociados con vistas se aplican típicamente con el uso de herramientas apropiadas.

35.7.1 Desarrollo de una arquitectura empresarial Visualizar El punto de vista de la Arquitectura de Negocios se ocupa de atender las preocupaciones de los s. 35.7.1.1 Las partes interesadas y Preocupaciones

Este punto de vista debe ser desarrollado para los s. Se centra en los aspectos funcionales del sistema desde la perspectiva de los s del sistema. Responder a las expectativas de los s incluye la consideración de los siguientes: Personas Los aspectos de recursos humanos del sistema. Examina los actores humanos involucrados en el sistema. Proceso Se ocupa de los procesos de que intervienen en el sistema. Función Se ocupa de las funciones requeridas para soportar los procesos. Información de o Se ocupa de la información necesaria para fluir en apoyo de los procesos.

Página 407 de 670

The Open Group Architecture Framework TOGOF 9.1   Usabilidad Considera los aspectos de usabilidad del sistema y de su entorno. Rendimiento Considera los aspectos de rendimiento del sistema y de su entorno. 35.7.1.2 Desarrollo de la Vista

Escenarios de negocios (véase la Parte III , 26. Escenarios empresariales y objetivos de la empresa ) son una técnica importante que puede utilizarse antes y como un insumo clave para el desarrollo de la vista de arquitectura de negocio, para ayudar a identificar y entender las necesidades del negocio, y por lo tanto para obtener los requerimientos del negocio y las limitaciones que el desarrollo de la arquitectura tiene que abordar. Escenarios de negocios son una manera muy útil para describir lo que debe suceder cuando se planifican y se producen acontecimientos imprevistos. Es altamente recomendable que los escenarios de negocio pueden crear para el cambio planificado, y para el cambio no planificado. La siguiente sección describe algunas de las cuestiones clave que el arquitecto podría tener en cuenta al construir escenarios de negocio. 35.7.1.3 Cuestiones clave

La vista Business Architecture considera los aspectos funcionales del sistema; es decir, lo que el nuevo sistema se pretende hacer. Esto puede ser construido a partir de un análisis del entorno existente y de los requisitos y limitaciones que afectan al nuevo sistema. Los nuevos requisitos y limitaciones aparecerán a partir de un número de fuentes, incluyendo posiblemente: 

Existentes especificaciones internas y las listas de productos aprobados



Metas y objetivos de negocio



Actividades de reingeniería de procesos de negocio



Los cambios en la tecnología

Lo que debería salir de la vista de arquitectura de negocio es una comprensión clara de los requisitos funcionales de la nueva arquitectura, con frases como: "Se necesitan mejoras en el manejo de consultas de los clientes a través del uso más amplio de integración computadora / telefonía". La vista Business Architecture considera los aspectos de usabilidad del sistema y de su entorno. . También debe tener en cuenta los impactos sobre el , tales como los niveles de cualificación requeridos, la necesidad de formación especializada, y la migración de la práctica actual Al considerar la usabilidad del arquitecto debería tener en cuenta: 

El, y cómo intuitiva facilidad de uso de la interfaz de es

Página 408 de 670


Sea o no un transparente a los datos y aplicaciones, independientemente de la ubicación



La facilidad de gestión del entorno de por el



Interoperabilidad de aplicaciones a través de medios tales como arrastrar y soltar



Servicios de ayuda en línea



La claridad de la documentación



Seguridad y contraseña aspectos, tales como evitar la necesidad de múltiples cuadros de diálogo de inicio de sesión y contraseña



El a las aplicaciones de productividad, como el correo o una hoja de cálculo

Tenga en cuenta que, aunque la seguridad y la gestión se cree por aquí, es desde el punto de vista de la facilidad de uso y funcionalidad. Los aspectos técnicos de la seguridad y la gestión son considerados en la vista de seguridad de la empresa (ver 35.7.2 Desarrollar un Vista Enterprise Security ) y la visión empresarial de istración (ver 35.7.7 Desarrollo de una empresa de istración Ver ).

35.7.2 Desarrollo de un Vista Enterprise Security La vista Enterprise Security se ocupa de los aspectos de seguridad del sistema. 35.7.2.1 Las partes interesadas y Preocupaciones

Este punto de vista se debe desarrollar para los ingenieros de seguridad del sistema. Se centra en cómo se implementa el sistema desde el punto de vista de la seguridad, y cómo afecta a la seguridad de las propiedades del sistema. Se examina el sistema para establecer qué información es almacenada y procesada, lo valioso que es, lo que las amenazas existen, y cómo se pueden abordar. Las principales preocupaciones de este punto de vista son la comprensión de cómo asegurarse de que el sistema está disponible sólo a aquellos que tienen permiso, y cómo proteger el sistema contra cambios no autorizados. 35.7.2.2 Desarrollo de la Vista

Los temas de la arquitectura general de un "sistema de seguridad" son componentes que están asegurados, o componentes que proporcionan servicios de seguridad.Además Listas de control de (ACL) y definiciones de esquema de seguridad se utilizan para modelar e implementar la seguridad. 35.7.2.3 Conceptos Básicos

En esta sección se presentan los conceptos básicos necesarios para la comprensión de la seguridad del sistema de información.

Página 409 de 670

The Open Group Architecture Framework TOGOF 9.1   La esencia de la seguridad es el uso controlado de la información. El propósito de esta sección es proporcionar una breve descripción de cómo se lleva a cabo la protección de seguridad de los componentes de un sistema de información. Mecanismos doctrinales o de procedimiento, tales como los procedimientos y políticas de seguridad físicas y de personal, no se discuten aquí en profundidad. La Figura 35-4 muestra una vista abstracta de una Arquitectura de Sistemas de la Información, que hace hincapié en el hecho de que un sistema de información desde la perspectiva de la seguridad es ya sea parte de un entorno local de abonado (LSE) o una Red de Comunicaciones (CN). Un LSE puede ser fijo o móvil. Las empresas grandes, por definición, están bajo el control de la organización utilizando. En una aplicación de computación distribuida de sistemas abiertos, casi con toda seguridad se requerirán LSE seguras y no seguras para interoperar.

Figura 35‐4: Abstracto Seguridad Arquitectura Vista Dominios de Información

El concepto de un dominio de información proporciona la base para la discusión de los requisitos de protección de la seguridad. Un dominio de la información se define como un conjunto de s, sus objetos de información, y una política de seguridad. Una política de seguridad de la información de dominio es la declaración de los criterios de adhesión en el ámbito de la información y la protección necesaria de los objetos de información. Rompiendo la información de una organización hasta en dominios es el primer paso en la reducción de la tarea de la elaboración de políticas de seguridad a un tamaño manejable. El negocio de la mayoría de las organizaciones requiere que sus operan en más de un dominio de información. La diversidad de las actividades comerciales y la variación en la percepción de las amenazas a la seguridad de la información dará lugar a la existencia de diferentes dominios de información dentro de una política de seguridad de la organización. Una actividad específica puede utilizar varios dominios de información, cada uno con su propia información distinta la política de seguridad de dominio. Dominios de información no están necesariamente limitadas por los sistemas de información o incluso redes de sistemas. Los mecanismos de seguridad implementados en los componentes del sistema de información pueden ser evaluados por su capacidad para cumplir con las políticas de seguridad de dominio de información.

Página 410 de 670

The Open Group Architecture Framework TOGOF 9.1   Aislamiento Estricto

Dominios de información puede ser vista como estrictamente aislados unos de otros. Objetos de información deben ser transferidos entre dos dominios de información sólo de acuerdo con las reglas establecidas, condiciones y procedimientos expresados en la política de seguridad de cada dominio de la información. Protección Absoluta

El concepto de "protección absoluta" se utiliza para lograr el mismo nivel de protección en todos los sistemas de información de apoyo a la información de dominio particular. Se llama la atención sobre los problemas creados por la interconexión de las empresas grandes que proporcionan diferentes puntos fuertes de protección de seguridad. Esta interconexión es probablemente porque los sistemas abiertos pueden consistir en un número indeterminado de empresas grandes heterogéneos. Análisis de los requisitos mínimos de seguridad se asegurará de que el concepto de protección absoluta se conseguirá para cada dominio de información a través de las empresas grandes. 35.7.2.4 Generic Security Architecture Vista

La Figura 35-5 muestra una vista de la arquitectura genérica que puede ser utilizado para discutir la asignación de los servicios de seguridad y la implementación de mecanismos de seguridad. Este punto de vista se identifican los componentes de la arquitectura dentro de una LSE. Las empresas grandes están conectados por la CNS.Las empresas grandes son los sistemas finales, sistemas de retransmisión y Sistemas Locales de Comunicaciones (LCS), que se describen a continuación.

Figura 35‐5: Generic Security Architecture Vista 

Relay System (RS) : El componente de la LSE, cuya funcionalidad se limita a la transferencia de información y es sólo indirectamente accesible por los s (por ejemplo, router, switch, multiplexor, Agente de transferencia de mensajes (MTA)). Se puede tener una funcionalidad similar a un sistema final, sino un final no utilizarlo directamente. Tenga en cuenta que las funciones del sistema de relé se pueden proporcionar en un sistema final.

Página 411 de 670


Sistema de Comunicación Local (LCS) : Una red que proporciona capacidades de comunicación entre las empresas grandes o dentro de un LSE con todos los componentes bajo el control de un LSE.



Red de Comunicaciones (CN) : Una red que proporciona inter-LSE capacidades de comunicación, pero no es controlado por las empresas grandes (por ejemplo, los transportistas comerciales).

El sistema de cierre y el sistema de relé son vistos como que requiere el mismo tipo de protección de seguridad. Por esta razón, una discusión de la protección de seguridad en un sistema de extremo generalmente también se aplica a un sistema de relé. Las protecciones de seguridad en un sistema final podría ocurrir en el hardware y el software. 35.7.2.5 Asignación de Servicios de Seguridad

La protección de seguridad de un sistema de información es proporcionada por los mecanismos implementados en el hardware y el software del sistema y por el uso de los mecanismos doctrinales. Los mecanismos implementados en el hardware y el software del sistema se concentran en el sistema final o sistema de relé. Este enfoque para la protección de seguridad se basa en el sistema abierto, el enfoque de computación distribuida para sistemas de información. Esto implica el uso de portadores comunes comerciales y sistemas de comunicación de uso común privadas como el proveedor de CN entre las empresas grandes. Por lo tanto, para la operación de sistemas de extremo en un entorno distribuido, un mayor grado de protección de seguridad puede asegurarse de la aplicación de mecanismos en el sistema final o sistema de relé. Sin embargo, las redes de comunicación deben satisfacer el elemento de disponibilidad de la seguridad con el fin de proporcionar una protección de seguridad adecuada para el sistema de información. Esto significa que los CN debe proporcionar un nivel acordado de la capacidad de respuesta, la continuidad del servicio, y la resistencia a las amenazas accidentales e intencionales a la disponibilidad de servicios de comunicaciones. La aplicación de la protección de la seguridad necesaria en el sistema final se produce en tres áreas de servicio del sistema de TOGAF. Ellos están operando los servicios del sistema, servicios de red y servicios de istración de sistemas. La mayor parte de la implementación de la protección de seguridad se espera que ocurra en el software. Se espera que el hardware para proteger la integridad del software de sistema de extremo. Mecanismos de seguridad de hardware incluyen la protección contra la manipulación, emanaciones no deseadas, y la criptografía. Servicios del sistema operativo

Un "contexto de seguridad" se define como un proceso controlado el espacio objeto de una política de seguridad de la información de dominio. Por tanto, el contexto de seguridad es análogo a una noción de sistema operativo común de espacio de proceso de . Se requiere aislamiento de contextos de seguridad. Se requieren los contextos de seguridad para todas las aplicaciones (aplicaciones por ejemplo, los s finales y la gestión de la seguridad). La atención se centra en el aislamiento estricto de los dominios de información, gestión de los recursos del sistema final, y el uso compartido controlado y la transferencia de información entre los dominios de información. Cuando sea posible, las funciones críticas de seguridad deben ser aislados en relativamente pequeños módulos que se relacionan de maneras bien definidas .

Página 412 de 670

The Open Group Architecture Framework TOGOF 9.1   El sistema operativo aislará múltiples contextos de seguridad entre sí mediante funciones de protección de hardware (por ejemplo, registro de estado del procesador, registros de asignación de memoria) para crear espacios de direcciones separados para cada uno de ellos. Software no fiable utilizará recursos del sistema final sólo invocando funciones críticas de seguridad a través del núcleo de la separación. La mayor parte de las funciones críticas de seguridad son las funciones de bajo nivel de los sistemas operativos tradicionales. Servicios de red

Dos clases básicas de comunicaciones se prevén para los que distribuyen contextos de seguridad pueden necesitar ser establecida. Estos son interactivos y protagonizaron (almacenamiento y retransmisión) de comunicaciones. El concepto de una "asociación de seguridad" constituye un contexto interactivo seguridad distribuida. Una asociación de seguridad se define como todos los mecanismos de comunicación y de seguridad y funciones que amplían las protecciones exigidas por una política de seguridad de la información de dominio dentro de un sistema de extremo a la información en la transferencia entre múltiples sistemas finales. La asociación de seguridad es una extensión o ampliación de una asociación de capa de aplicación de OSI. Una asociación de capa de aplicación se compone de funciones y protocolos de capa de aplicación apropiadas, además de todas las funciones y protocolos de comunicaciones subyacentes en otras capas del modelo OSI. Múltiples protocolos de seguridad pueden ser incluidos en un solo asociación de seguridad para proporcionar una combinación de servicios de seguridad. Para las comunicaciones de entrega por etapas (por ejemplo, correo electrónico), se hará uso de una técnica de encapsulación (denominado "proceso de envoltura") para transmitir los atributos de seguridad necesaria con los datos que se transfieren como parte de los servicios de red. Los atributos de seguridad envueltos pretenden permitir que el sistema extremo receptor para establecer el contexto de seguridad necesarias para el procesamiento de los datos transferidos. Si el proceso de envoltura no puede proporcionar toda la protección de la seguridad es necesario, contextos de seguridad de interacción entre sistemas finales tendrán que ser utilizados para garantizar la transferencia segura en escena de la información. Sistema de Servicios de Gestión de la Seguridad

Gestión de la seguridad es un caso particular de las funciones de gestión de sistemas de información que se analiza en los capítulos anteriores. Servicios de gestión de la seguridad del sistema de información se refieren a la instalación, mantenimiento y observancia de dominio de la información y las reglas de política de seguridad de sistemas de información en el sistema de información destinado a proporcionar estos servicios de seguridad. En particular, la función de gestión de la seguridad controla la información que necesitan los servicios del sistema operativo dentro de la arquitectura de seguridad del sistema final. Además de estos servicios básicos, gestión de seguridad requiere el manejo de eventos, la auditoría y la recuperación. La normalización de las funciones de gestión de seguridad, estructuras de datos y protocolos permitirá la interoperabilidad de los procesos de aplicación de gestión de seguridad (smaps) a través de muchas plataformas de apoyo a la gestión de seguridad distribuida.

35.7.3 Desarrollo de un Software Engineering Ver La vista de la Ingeniería de Software tiene que ver con el desarrollo de nuevos sistemas de software.

Página 413 de 670

The Open Group Architecture Framework TOGOF 9.1   35.7.3.1 Las partes interesadas y Preocupaciones

La construcción de un sistema de software intensivo es a la vez caro y consume mucho tiempo. Debido a esto, es necesario establecer directrices para ayudar a minimizar el esfuerzo requerido y los riesgos involucrados. Este es el propósito de la vista de la Ingeniería del Software, que debe ser desarrollado para los ingenieros de software que van a desarrollar el sistema. Las principales preocupaciones de estos grupos de interés son: 

Enfoque de Desarrollo



La modularidad del software y de re-uso



Portabilidad



Migración e interoperabilidad

Enfoque de Desarrollo

Hay muchos modelos de ciclo de vida definido para el desarrollo de software (cascada, prototipos, etc.) Una consideración para el arquitecto es la mejor manera de alimentar las decisiones arquitectónicas en el modelo de ciclo de vida que va a ser utilizado para el desarrollo del sistema. Software Modularidad y Reutilización

Como una pieza de software crece en tamaño, por lo que la complejidad y las interdependencias entre diferentes partes del aumento de código. Confiabilidad caerá drásticamente a menos que esta complejidad puede ser controlada. La modularidad es un concepto por el cual una pieza de software se agrupa en un número de subunidades distintas y lógicamente cohesivos, la presentación de los servicios para el mundo exterior a través de una interfaz bien definida. En términos generales, los componentes de un módulo se compartir el a los datos comunes, y la interfaz proporcionará el controlado a estos datos. El uso de la modularidad, se hace posible construir una aplicación de software de forma incremental en una base fiable de código antes de la prueba. Un beneficio adicional de un sistema modular bien definida es que los módulos definidos dentro de ella pueden ser reutilizadas en el mismo o en otros proyectos, cortar drásticamente el tiempo de desarrollo mediante la reducción tanto en el desarrollo y prueba de esfuerzo. En los últimos años, el desarrollo de los lenguajes de programación orientados a objetos se ha incrementado en gran medida el apoyo lenguaje de programación para el desarrollo del módulo y la reutilización del código. Estos lenguajes permiten al desarrollador definir "clases" (una unidad de modularidad) de objetos que se comportan de una manera controlada y bien definido. Técnicas tales como la herencia - que permite a las partes de una interfaz existente a un objeto que cambiar - aumentar el potencial de reutilización al permitir que las clases predefinidas para ser adaptados o ampliados cuando los servicios que ofrecen no llegan a cumplir con el requisito del desarrollador. Si la modularidad y la reutilización del software es probable que sean los objetivos principales de los nuevos desarrollos de software, se debe prestar atención a si las partes que componen un

Página 414 de 670

The Open Group Architecture Framework TOGOF 9.1   proyecto de arquitectura puede facilitar o prohibir el nivel deseado de la modularidad en las áreas apropiadas. Portabilidad

Software portabilidad - la capacidad de tomar un pedazo de software escrito en un entorno y hacer que se ejecute en otro - es importante en muchos proyectos, especialmente el desarrollo de productos. Se requiere que todos los aspectos de software y hardware de una Arquitectura Tecnológica elegido (no sólo la aplicación de nuevo desarrollo) estarán disponibles en la nueva plataforma. Será, por lo tanto, ser necesario para asegurar que las partes componentes de cualquier arquitectura elegida están disponibles a través de todas las plataformas de destino apropiadas. Migración e interoperabilidad

La interoperabilidad es siempre necesaria entre las partes componentes de una nueva arquitectura. También podrá, sin embargo, precisa entre una nueva arquitectura y las piezas de un sistema heredado existente; Por ejemplo, durante la sustitución escalonada de un sistema antiguo. La interoperabilidad entre las nuevas y viejas arquitecturas puede, por lo tanto, ser un factor en la elección de la arquitectura. 35.7.3.2 Cuestiones clave



Data-intensiva contra los sistemas de software de información-intensivos



Lograr la interoperabilidad



Niveles de software



Usos de un nivel de a datos



Distribución

Data-Intensive frente a los sistemas de software de información-intensivos

Este punto de vista considera dos categorías generales de sistemas de software. En primer lugar, están los sistemas que requieren sólo una interfaz de a una base de datos, que requieren poco o nada de la lógica de negocio integrada en el software. Estos sistemas pueden ser llamados "uso intensivo de datos." En segundo lugar, están los sistemas que requieren los s manipular la información que pueda ser distribuido a través de múltiples bases de datos, y para ello la manipulación de acuerdo con un predefinido lógica de negocio. Estos sistemas se pueden llamar "información-intensiva" Sistemas de uso intensivo de datos se pueden construir con relativa facilidad mediante el uso de herramientas 4GL. En estos sistemas, la lógica de negocio está en la mente de los s; es decir, el entiende las reglas para la manipulación de los datos y utiliza esas reglas mientras que hace su trabajo. Sistemas de información intensiva son diferentes. La información se define como "datos significativos"; es decir, los datos en un contexto que incluye la lógica de negocio.La información es diferente de datos. Los datos son las fichas que están almacenados en bases de datos u otros almacenes de datos. La información es varias fichas de datos combinados para transmitir un

Página 415 de 670

The Open Group Architecture Framework TOGOF 9.1   mensaje. Por ejemplo, "3" son los datos, pero "3 widgets" es la información. Normalmente, la información refleja un modelo. Sistemas de información intensiva también tienden a requerir información de otros sistemas y, si este camino de la transmisión de información está automatizado, por lo general se requiere un poco de mediación para convertir el formato de la información que llega a un formato que puede ser utilizado a nivel local. Debido a esto, los sistemas de información intensiva tienden a ser más complejos que otros, y requieren el máximo esfuerzo para construir, integrar y mantener. Este punto de vista se ocupa principalmente de los sistemas de información intensiva. Además de los sistemas que pueden manejar la información, a pesar de la construcción, los sistemas también deben ser lo más flexible posible. Esto tiene una serie de beneficios. Se permite que el sistema para ser utilizado en diferentes entornos; por ejemplo, el mismo sistema debería pueda utilizarse con diferentes fuentes de datos, incluso si el nuevo almacén de datos es una configuración diferente. Del mismo modo, podría tener sentido utilizar la misma funcionalidad pero con los s que necesitan una interfaz de diferente. Así los sistemas de información deben ser construidos de manera que puedan ser reconfigurados con diferentes almacenes de datos o diferentes interfaces de . Si un sistema está construido para permitir esto, permite a la empresa a las partes volver a utilizar (o componentes) de un sistema en otro. El logro de la interoperabilidad

La palabra "interoperar" implica que un sistema de procesamiento realiza una operación en nombre o bajo requerimiento de otro sistema de procesamiento. En la práctica, la petición es una oración completa que contiene un verbo (en funcionamiento) y uno o más sustantivos (identidades de los recursos, donde los recursos pueden ser la información, datos, dispositivos físicos, etc.) Interoperabilidad proviene de funcionalidad compartida. Interoperabilidad sólo puede lograrse cuando se pasa información, no cuando se pasa de datos. La mayoría de los sistemas de información de hoy en día reciben información tanto de sus propios almacenes de datos y otros sistemas de información. En algunos casos, la red de la conectividad entre los sistemas de información es bastante extensa. La Fuerza Aérea de EE.UU., por ejemplo, tiene un concepto conocido como "La interoperabilidad A5". Esto significa que los datos requeridos se encuentra disponible en cualquier momento y en cualquier lugar, por cualquier persona , que está autorizada, de cualquier manera. Esto requiere que muchos sistemas de información están vinculados arquitectónicamente y proporcionan información a la otra. Tiene que haber algún tipo de conectividad física entre los sistemas. Esto podría ser una red de área local (LAN), una red de área amplia (WAN), o, en algunos casos, podría ser simplemente el paso de medios de almacenamiento de datos entre sistemas. Suponiendo una red conecta los sistemas, debe haber un acuerdo sobre los protocolos utilizados. Esto permite la transferencia de bits. Cuando los bits se ensamblan en el sistema de recepción, que deben ser colocados en el contexto de que el sistema de recepción debe. En otras palabras, tanto los sistemas de origen y de destino deben estar de acuerdo en un modelo de información. El sistema de origen utiliza este modelo para convertir su información en datos que se pasan, y el sistema de destino utiliza este mismo modelo para transformar los datos obtenidos en información que puede utilizar. Esto por lo general requiere de un acuerdo entre los arquitectos y diseñadores de los dos sistemas. En el pasado, este acuerdo fue a menudo documentado en la forma de un Documento de Control de Interfaz (ICD). La CIE define la sintaxis y la semántica exacta de que el sistema de envío utilizará para que el sistema receptor sabrá qué hacer cuando lleguen los datos. El mayor

Página 416 de 670

The Open Group Architecture Framework TOGOF 9.1   problema con los DCI es que tienden a ser soluciones únicas entre dos sistemas. Si un sistema dado debe compartir información con notros sistemas, existe la necesidad potencial de N 2 DAI. Esta integración extremadamente apretado prohíbe la flexibilidad y la capacidad de un sistema para adaptarse a un entorno cambiante. El mantenimiento de todos estos DAI es también un desafío. Las nuevas tecnologías, como el Extensible Markup Language (XML), tiene la promesa de hacer que los datos de "auto describe". uso de las nuevas tecnologías como XML, una vez que estén fiable y bien documentada, que podría eliminar la necesidad de un DAI. Además, hay sería Comercial productos (COTS) disponibles para analizar y manipular los datos XML Off-The-Shelf, eliminando la necesidad de desarrollar estos productos en el local. También debe aliviar el dolor de mantener todas las interfaces. Otro enfoque es la construcción de "mediadores" entre los sistemas. Los mediadores usarían metadatos que se envía con los datos para comprender la sintaxis y la semántica de los datos y convertirlos en un formato utilizable por el sistema receptor. Sin embargo, los mediadores no se requiere que se le envíe metadatos bien formado, añadiendo a la complejidad de la interfaz.

Niveles de Software

Por lo general, las arquitecturas de software son un bien de dos niveles o de tres niveles. 2 Cada nivel se presenta típicamente al menos una capacidad. De dos niveles

En un dos -tier arquitectura, la interfaz de y la lógica de negocio están estrechamente acopladas mientras los datos se mantiene independiente. Esto le da la ventaja de permitir que los datos residen en un servidor de datos dedicado. También permite que los datos se mantienen de forma independiente. El estrecho acoplamiento de la interfaz de y la lógica de negocio a asegurar que van a trabajar bien juntos, para este problema en este ámbito. Sin embargo, el estrecho acoplamiento de la interfaz de y la lógica de negocio aumenta drásticamente los riesgos de mantenibilidad, mientras que la reducción de la flexibilidad y oportunidades para su reutilización. Three-Tier

Un enfoque de tres niveles, añade un nivel que separa la lógica de negocio de la interfaz de . En principio, esto permite que la lógica de negocio para ser utilizado con diferentes interfaces de , así como con diferentes almacenes de datos. Con respecto a la utilización de diferentes interfaces de , los s podrían querer la misma interfaz de , pero usando diferentes servidores de presentación COTS; por ejemplo, Java Virtual Machine (JVM). Del mismo modo, si la lógica de negocio se va a utilizar con distintos almacenes de datos, a continuación, cada almacén de datos debe utilizar el mismo modelo de datos 3 (estandarización de los datos), o un nivel de mediación debe ser añadido por encima del almacén de datos (encapsulación de datos). Cinco Tier

Página 417 de 670

The Open Group Architecture Framework TOGOF 9.1   Para lograr la máxima flexibilidad, el software debería utilizar un esquema de cinco niveles para el software que amplía el paradigma de tres niveles (ver Figura 35-6 ). Este régimen está destinado a proporcionar una fuerte separación de las tres principales áreas funcionales de la arquitectura. Puesto que hay de cliente y servidor aspectos tanto de la interfaz de y el almacén de datos, el esquema a continuación, tiene cinco niveles. 4 El nivel de presentación es típicamente basados en COTS. La interfaz de presentación puede ser un servidor de X, Win32, etc No debe haber un nivel separado para el cliente de interfaz de . Este cliente establece el look-and-feel de la interfaz; el servidor (capa de presentación) en realidad lleva a cabo las tareas mediante la manipulación de la pantalla. El cliente de interfaz de oculta el servidor de presentación de la lógica empresarial de la aplicación. La lógica empresarial de la aplicación (por ejemplo, un motor de programación) debe ser un nivel separado. Este nivel se denomina "lógica de la aplicación" y funciona como un servidor para el cliente de interfaz de . Se conecta a la interfaz de típicamente a través de devoluciones de llamada. La capa de lógica de aplicación también funciona como un cliente para el nivel de a datos. Si hay un necesita utilizar una aplicación con múltiples bases de datos con diferentes esquemas, entonces se necesita un nivel diferente para el a datos.Este cliente podría acceder a los almacenes de datos utilizando la interfaz apropiada COTS 5 y luego convertir los datos en bruto en un tipo de datos abstracto que representa las partes del modelo de información. La interfaz de esta red sería entonces objeto proporcionar una interfaz de a datos generalizada (DAI), que ocultar los detalles de almacenamiento de los datos de cualquier aplicación que utilice esos datos. Cada nivel en este esquema puede tener cero o más componentes. La organización de los componentes dentro de un nivel es flexible y puede reflejar un número de diferentes arquitecturas basadas en necesidad. Por ejemplo, puede haber muchos componentes diferentes en el nivel de aplicación de la lógica (programación, contabilidad, control de inventario, etc) y la relación entre ellos puede consistir en una arquitectura tiene sentido, pero ninguno de ellos debe ser un cliente para el servidor de presentación. Esta separación limpia de interfaz de , la lógica de negocio, y la información dará lugar a la máxima flexibilidad y el software en componentes que se presta a las prácticas de desarrollo línea de productos. Por ejemplo, es concebible que la misma funcionalidad debe ser construido de una vez y sin embargo ser utilizable por diferentes servidores de presentación (por ejemplo, en los ordenadores o cajas de sistema UNIX), que se muestran con un aspecto diferente y se siente en función de las necesidades del , y se puede usar con múltiples bases de datos heredadas . Por otra parte, esta flexibilidad no debe requerir reescrituras masivas para el software cada vez que se necesita un cambio.

Página 418 de 670


Figura 35‐6: La Organización de cinco niveles Algunos usos de un nivel de a datos

El nivel de a datos proporciona una vista estandarizada de ciertas clases de datos, y como tal funciona como un servidor para uno o más niveles lógica de la aplicación. Si se aplica correctamente, no habría necesidad de que el código de aplicación "saber" acerca de los detalles de implementación de los datos. El código de la aplicación sólo tendría que saber acerca de una interfaz que presenta un nivel de abstracción superior a los datos. Esta interfaz se denomina interfaz de a datos (DAI). Por ejemplo, en caso de necesitar un motor de programación para saber qué eventos están programados entre dos fechas, dicha consulta no debería requerir el conocimiento de tablas y combinaciones en una base de datos relacional. Por otra parte, el DAI podría proporcionar técnicas de estandarizados para los datos. Por ejemplo, el DAI podría proporcionar una publicación y suscripción (P & S) de interfaz mediante el cual los sistemas que requieren el a almacenes de datos podría registrar un interés en ciertos tipos de datos, tal vez, en determinadas condiciones, y el DAI podría proporcionar los datos requeridos cuando se producen esas condiciones . Una posible instanciación de un DAI

Uno de los medios para crear una instancia de un componente de de datos es con tres capas, como se muestra en la Figura 35-7 . Este no es el único medio para construir un DAI, pero se presenta como una posibilidad.

Página 419 de 670


Figura 35‐7: Data Access Interface (DAI) Mientras que la capa de a datos directo contiene los detalles de implementación de uno o varios almacenes de datos, la Red de objetos y la capa de Distribución de la Información no requieren de tal conocimiento. En cambio, las dos capas superiores reflejan la necesidad de estandarizar la interfaz de un dominio determinado. La capa de a datos directo extiende la brecha entre el nivel de a datos y el nivel de almacén de datos, y por lo tanto tiene conocimiento de los detalles de implementación de los datos. SQL declaraciones, ya sea incrustadas oa través de una norma como la DRDA u ODBC, se encuentran aquí. La capa de red del objeto es la creación de instancias de software del modelo de información. Como tal, es un medio eficaz para mostrar las relaciones que se dan entre piezas de datos. La traducción de los datos de los s a los objetos de la red sería la función de la capa de a datos directo. Dentro de la capa de Distribución de la Información se encuentra la interfaz con el "mundo exterior". Esta interfaz normalmente utiliza un bus de datos para distribuir los datos (véase más adelante). 6 También podría contener diversos servicios relacionados con la información; Por ejemplo, un registro de P & S y servicio de publicación o una interfaz a un servidor de seguridad para el control de a datos. 7 la capa de información de distribución pueden también ser usados para distribuir aplicaciones o applets requeridos para procesar información distribuida. Los objetos en la red objeto señalarían las aplicaciones o applets, lo que permite un fácil al código de procesamiento requerido. IAA Habilitar Flexibilidad

El DAI permite una arquitectura muy flexible. Capacidades primas múltiples pueden acceder a los mismos o diferentes almacenes de datos, todo a través de la misma DAI.Cada DAI podría implementarse de muchas maneras, de acuerdo a las necesidades específicas de las capacidades de primas que lo usan. Figura 35-8 ilustra una serie de posibilidades, incluyendo múltiples IAA diferentes en diferentes ámbitos con el a la misma base de datos, un único DAI acceder a múltiples bases de datos, y varias instancias de la misma DAI acceden a la misma base de datos.

Página 420 de 670

The Open Group Architecture Framework TOGOF 9.1   No siempre está claro que se necesita un DAI, y que parece requerir un trabajo adicional durante todas las fases de desarrollo. Sin embargo, si una base de datos cada vez ser rediseñado, o si una aplicación se va a volver a utilizar y no hay ningún control sobre cómo se implementa la nueva información, el uso de un DAI ahorra tiempo en el largo plazo.

Figura 35‐8: usos múltiples de una interfaz de  a datos (IAA) Distribución

El modelo de referencia ISO para el procesamiento distribuido abierto (RM-ODP) ofrece un metaestándar que se pretende permitir normas más específicas que surjan.Define el modelo de referencia de RM-ODP un conjunto de transparencias de distribución que sean aplicables a la vista TOGAF Software Engineering. 

Transparencia máscaras diferencias en la representación de datos y los mecanismos de invocación para permitir el interfuncionamiento entre objetos. Esta transparencia resuelve muchos de los problemas de interfuncionamiento entre sistemas heterogéneos, y por lo general se proporciona de forma predeterminada.



Transparencia El incumplimiento máscaras de un objeto del fracaso y la posible recuperación de otros objetos (o sí) para permitir la tolerancia a fallos. Cuando se proporciona esta transparencia, el diseñador puede trabajar en un mundo idealizado en el que no se produce la clase correspondiente de fracasos.



Ubicación Transparencia enmascara el uso de la información sobre la ubicación en el espacio cuando la identificación y unión a las interfaces. Esta transparencia proporciona una vista lógica de nombrar, independientemente de la ubicación física real.



Transparencia Migración máscaras de un objeto de la capacidad de un sistema para cambiar la ubicación de ese objeto. La migración se utiliza a menudo para alcanzar el equilibrio de carga y reducir la latencia.



Transparencia Reubicación máscaras reubicación de una interfaz de otras interfaces asociadas a la misma. Reubicación permite la operación del sistema para continuar incluso cuando la migración o el reemplazo de algunos objetos crea inconsistencias temporales en la vista visto por sus s.

Página 421 de 670


Transparencia de replicación enmascara el uso de un grupo de objetos mutuamente compatibles conductualmente para sustentar una interfaz. replicación se utiliza a menudo para mejorar el rendimiento y la disponibilidad.



Transparencia Transacción máscaras de coordinación de las actividades entre una configuración de los objetos para lograr consistencia.

Bus Infraestructura

El bus de la infraestructura representa el middleware que establece la relación de cliente / servidor. Este software comercial es como un plano posterior en la que las capacidades se pueden conectar. Un sistema debe cumplir con una aplicación comercial de un estándar middleware. Esto es para asegurar que las capacidades utilizando diferentes implementaciones comerciales de la norma pueden interoperar. Si se utiliza más de una norma comercial (por ejemplo, COM y CORBA), entonces el sistema debe permitir la interoperabilidad entre las implementaciones de estos estándares a través del uso de software de puente comercial. 8 Cuando sea posible, las interfaces deben ser especificados en la adecuada descripción de la interfaz Idioma (IDL). Tomado de esta forma, todas las interfaces en el esquema de cinco niveles representa una oportunidad para su distribución. Los clientes pueden interactuar con los servidores a través del bus de la infraestructura. En esta interacción, el transporte real de la red (T / IP, HTTP, etc), la plataforma / proveedor del servidor y del sistema operativo del servidor son todos transparentes.

Página 422 de 670

The Open Group Architecture Framework TOGOF 9.1   Figura 35‐9: nocional Modelo de Distribución 35.7.3.3 Conclusión

La vista de la Ingeniería de Software proporciona orientación sobre la forma de estructurar el software de una manera muy flexible. Siguiendo estas pautas, el software resultante será por componentes. Esto permite la reutilización de los componentes en diferentes entornos. Por otra parte, mediante el uso de un bus de infraestructura y las interfaces limpias, el software resultante será independiente de la ubicación, lo que permite su distribución a través de una red.

35.7.4 Desarrollo de un sistema de ingeniería Ver El punto de vista de Ingeniería de Sistemas se ocupa de reunir software y componentes de hardware en un sistema de trabajo. 35.7.4.1 Las partes interesadas y Preocupaciones

Este punto de vista se debe desarrollar para el personal de ingeniería de sistemas del sistema, y debe centrarse en cómo se implementa el sistema desde el punto de vista de hardware / software y redes. Los ingenieros de sistemas están normalmente preocupados por la ubicación, modificabilidad, reusabilidad y la disponibilidad de todos los componentes del sistema. El punto de vista de Ingeniería de Sistemas presenta un número de diferentes formas en que los componentes de software y hardware se puede montar en un sistema de trabajo. En gran medida, la elección del modelo determina las propiedades del sistema final. Se ve en la tecnología que ya existe en la organización, y lo que está disponible en la actualidad o en un futuro próximo. Esto revela áreas en las que las nuevas tecnologías pueden contribuir a la función o la eficiencia de la nueva arquitectura, y cómo los diferentes tipos de procesamiento de la plataforma puede soportar diferentes partes del sistema en general. Las principales preocupaciones de este punto de vista son la comprensión de los requisitos del sistema. En general, estos grupos de interés tienen que ver con garantizar que los componentes adecuados se desarrollan y despliegan dentro del sistema de una manera óptima. El desarrollo de este punto de vista ayuda en la selección de las mejores configuraciones para el sistema. 35.7.4.2 Cuestiones clave

Este punto de vista de la arquitectura se centra en los modelos de computación que son apropiados para un entorno de computación distribuida. Para apoyar la migración de sistemas heredados, esta sección también presenta modelos que son apropiados para un entorno centralizado. Las definiciones de muchos de los modelos de computación (por ejemplo, basado en host, maestro / esclavo, y de tres niveles) históricamente precedieron a la definición del modelo de cliente / servidor, que trata de ser un modelo de propósito general. En la mayoría de los casos, los modelos no se han redefinido en la literatura informática en términos de contrastes con el modelo cliente / servidor. Por lo tanto, algunas de las distinciones de características no siempre están limpios. En general, sin embargo, los modelos se distinguen por la asignación de funciones para una aplicación de sistema de información a los distintos componentes (por ejemplo, terminales,

Página 423 de 670

The Open Group Architecture Framework TOGOF 9.1   plataformas de computación). Estas funciones que componen una aplicación de sistema de información son la presentación, la función de la aplicación y gestión de datos. Modelo cliente / servidor

Figura 35‐10: Básico Modelo Cliente / Servidor Procesamiento cliente / servidor es un tipo especial de computación distribuida denominado "proceso cooperativo", porque los clientes y servidores cooperan en el procesamiento de una aplicación total de (presentación, procesamiento funcional, datos de gestión). En el modelo, los clientes son procesos que solicitan servicios y servidores son procesos que proporcionan servicios. Los clientes y los servidores pueden estar ubicados en el mismo procesador, diferentes nodos multi-procesador, o en procesadores separados en ubicaciones remotas. El cliente normalmente inicia las comunicaciones con el servidor. El servidor normalmente no inicia una petición de un cliente. Un servidor puede soportar muchos clientes y puede actuar como un cliente a otro servidor. Figura 35-10 muestra un modelo cliente / servidor de base, que hace hincapié en las relaciones de solicitud-respuesta. Figura 35-11 muestra el mismo tipo elaborado siguiendo el TOGAF TRM, mostrando cómo las diversas entidades e interfaces se pueden utilizar para soportar un modelo de cliente / servidor, si el servidor es local o remoto para el cliente. En estas representaciones, las relaciones de solicitud-respuesta se definirían en el API.

Página 424 de 670


Figura 35‐11: Referencia Modelo Representación de modelo de cliente / servidor

Los clientes tienden a generalizarse y pueden ejecutarse en uno de los muchos nodos. Los servidores suelen estar especializados y se ejecutan en un par de nodos. Los clientes suelen implementarse como una llamada a una rutina. Los servidores se implementan normalmente como un proceso continuo a la espera de las solicitudes de servicio (de los clientes). Muchas implementaciones de cliente / servidor implican comunicaciones remotas a través de una red. Sin embargo, nada en el modelo cliente / servidor dicta comunicaciones remotas, y la ubicación física de los clientes es normalmente transparente para el servidor. La comunicación entre un cliente y un servidor puede implicar una comunicación local entre dos procesos independientes en la misma máquina. Un programa de aplicación se puede considerar que constará de tres partes: 

El manejo de datos



Función de aplicación



Presentación

En general, cada uno de ellos puede ser asignado a un cliente o aplicación de servidor, haciendo un uso adecuado de los servicios de la plataforma. Esta asignación define una configuración específica de cliente / servidor. Master / Slave y Modelos Jerárquicos

En este modelo, los ordenadores esclavos están conectados a un ordenador central. En cuanto a la distribución, el modelo maestro / esclavo es un paso adelante respecto al modelo basado en host. La distribución se proporciona en una sola dirección - del maestro a los esclavos. Los ordenadores esclavos realizan la tramitación del expediente sólo cuando es dirigido por el equipo maestro. Además, los procesadores esclavos pueden realizar el procesamiento local limitado, tales como la edición, procesamiento de tecla de función y la validación del campo. Una configuración

Página 425 de 670

The Open Group Architecture Framework TOGOF 9.1   típica podría ser una unidad central como el maestro con los PC como los esclavos que actúan como terminales inteligentes, como se ilustra en la figura 35-12 . El modelo jerárquico es una extensión del modelo maestro / esclavo con más capacidades de distribución. En este enfoque, la capa superior es generalmente un mainframe de gran alcance, que actúa como un servidor para el segundo nivel. La segunda capa consiste en servidores y clientes de la LAN a la primera capa, así como servidores de la tercera capa. La tercera capa consiste en PCs y estaciones de trabajo. Este modelo ha sido descrita como la adición de un verdadero procesamiento distribuido en el modelo maestro / esclavo. Figura 35-12 muestra un ejemplo modelo jerárquico en la tercera configuración, y por debajo, la figura 35-13 muestra el modelo jerárquico representado en términos de las entidades e interfaces de la TRM.

Figura 35‐12: Host‐Based, Master / Slave y Modelos Jerárquicos

Página 426 de 670


Figura 35‐13: Modelo jerárquico utilizando el modelo de referencia Modelo Peer-to-Peer

En el modelo peer-to-peer existen procesos de coordinación. Todos los equipos son servidores que puedan recibir las solicitudes de servicios y responder a ellos; y todos los equipos son clientes, ya que pueden enviar solicitudes de servicios a otras computadoras. En las implementaciones actuales, a menudo hay funciones redundantes en las plataformas participantes. Se han hecho intentos para implementar el modelo de los sistemas de bases de datos heterogéneas (o federados) distribuidos. Este modelo podría ser considerado como un caso especial del modelo de cliente / servidor, en el que todas las plataformas son servidores y clientes. Figura 35-14 (A) muestra un ejemplo de configuración del par-a-par en el que todas las plataformas tienen funciones completas.

Página 427 de 670


Figura 35‐14: Peer‐to‐Peer y distribuidos Modelos de Gestión de objetos Distribuido Modelo de Gestión de Objetos

En este modelo, el procedimiento remoto llamadas Se utiliza normalmente para la comunicación en el cliente / servidor y otros modelos de procesamiento distribuido son reemplazados por los mensajes enviados a los objetos. Los servicios prestados por los sistemas en una red son tratados como objetos. . Un solicitante no necesita conocer los detalles de cómo se configura el objeto El enfoque requiere: 

Un mecanismo para enviar mensajes

Página 428 de 670


Un mecanismo para coordinar la entrega de los mensajes



Las aplicaciones y servicios que soportan una interfaz de mensajería

Este enfoque no contrasta con el cliente / servidor o modelos de peer-to-peer, pero especifica una interfaz consistente para la comunicación entre plataformas de co-operación. Es considerado por algunos como un enfoque de implementación de cliente / servidor y modelos peer-to-peer. Figura 35-14 presenta dos ejemplos de modelos de objetos distribuidos. Ejemplo B muestra cómo se alteraría una configuración cliente / servidor para dar cabida al modelo de gestión de objetos distribuidos. Ejemplo C muestra cómo se vería alterada un modelo peer-to-peer para llevar a cabo la gestión de objetos distribuidos. El Object Management Group (OMG), un consorcio de participantes de la industria que trabajan hacia los estándares de objeto, se ha desarrollado una arquitectura - Common Object Request Broker Architecture (CORBA) - que especifica el protocolo de una aplicación de cliente debe utilizar para comunicarse con un intermediario de solicitud de objetos ( ORB), que presta servicios. El ORB especifica cómo los objetos de manera transparente pueden hacer peticiones y recibir respuestas. Además, Object Linking de Microsoft e incrustación de objetos (OLE) estándar para Windows es un ejemplo de una aplicación de gestión de objetos distribuidos, por lo que cualquier aplicación compatible con OLE puede trabajar con datos de cualquier otra aplicación compatible con OLE.

35.7.5 Desarrollo de un Comunicaciones Ingeniería View La vista de la Ingeniería de Comunicaciones se ocupa de las comunicaciones de estructuración y elementos de red para simplificar la planificación y diseño de la red. 35.7.5.1 Las partes interesadas y Preocupaciones

Este punto de vista debe ser desarrollado para las comunicaciones del personal de ingeniería del sistema, y debe centrarse en cómo se implementa el sistema desde la perspectiva del ingeniero de comunicaciones. Ingenieros de comunicaciones son típicamente preocupado por la ubicación, modificabilidad, reusabilidad y la disponibilidad de servicios de comunicaciones y redes. Las principales preocupaciones de este punto de vista son la comprensión de los requisitos de comunicaciones de red y. En general, estos grupos de interés tienen que ver con garantizar que las correspondientes comunicaciones y los servicios de redes se desarrollan y despliegan dentro del sistema de una manera óptima. El desarrollo de este punto de vista ayuda en la selección de la mejor modelo de comunicaciones para el sistema. 35.7.5.2 Cuestiones clave

Las redes de comunicaciones se construyen de dispositivos finales (por ejemplo, impresoras), nodos de procesamiento, los nodos de comunicación (elementos de conmutación), y los medios de comunicación de enlace que los conectan. La red de comunicaciones proporciona los medios por los cuales se intercambia información. Las formas de información incluyen datos, imágenes, voz y video. Dado que los sistemas de información automatizados aceptan y procesan la información usando los formatos de datos digitales en lugar de los formatos analógicos, los conceptos de

Página 429 de 670

The Open Group Architecture Framework TOGOF 9.1   comunicación TOGAF y orientación se centrará en las redes digitales y los servicios digitales.Servicios multimedia integrados están incluidos. La vista de la Ingeniería de Comunicaciones se describe la arquitectura de comunicaciones con respecto a la geografía, se analiza el modelo de referencia de interconexión de sistemas abiertos (OSI), y describe un marco general destinado a permitir el análisis de sistemas eficaces y planificación. Infraestructura de comunicaciones

La infraestructura de comunicaciones puede contener hasta tres niveles de transporte - local, regional / metropolitano, y global - como se muestra en la Figura 35-15 . Los nombres de los componentes de transporte se basan en su respectivo ámbito geográfico, pero también existe una relación jerárquica entre ellos. Los componentes de transporte corresponden a una estructura de gestión de la red en la que la gestión y el control de los recursos de red se distribuyen a través de los diferentes niveles. Los componentes locales se refieren a los activos que se encuentran relativamente cerca geográficamente. Este componente contiene equipos de comunicaciones fijas y pequeñas unidades de equipos de comunicaciones móviles. LAN, a la que se conectará la mayoría de los dispositivos finales, están incluidos en este componente. Las interfaces estándar facilitará la portabilidad, flexibilidad e interoperabilidad de las redes LAN y dispositivos finales. Redes de área metropolitana (MAN) Regional y están geográficamente dispersos en una gran superficie. Una red regional o metropolitano podría conectar componentes locales en varias bases fijas o conectarse puestos remotos separados. En la mayoría de los casos, las redes regionales y metropolitanas se utilizan para conectar redes locales. Sin embargo, las bases de datos compartidas, plataformas regionales de procesamiento y centros de gestión de red pueden conectarse directamente oa través de una red LAN. Las interfaces estándar serán proporcionados para conectar redes locales y dispositivos finales. Redes de Área Global o amplia (WAN) se encuentran en todo el mundo, proporcionando conectividad a las redes regionales y metropolitanas en el entorno fijo y desplegado.Además, unidades móviles, bases de datos compartidas, y centros de procesamiento central se pueden conectar directamente a la red mundial, como se requiera. Las interfaces estándar serán proporcionados para conectar las redes regionales y metropolitanas y los dispositivos finales.

Página 430 de 670


Figura 35‐15: Infraestructura de comunicaciones

   Comunicaciones Modelos

La infraestructura geográficamente dividido descrito anteriormente es la base de un marco global de comunicaciones. Estas divisiones geográficas permiten la aplicación por separado de las diferentes responsabilidades de gestión, las actividades de planificación, las funciones operacionales y tecnologías de apoyo que deben aplicarse en cada área. Componentes y servicios de hardware y software instalados en el marco forman el modelo completo. Los siguientes puntos se describe el modelo de referencia OSI y una agrupación de las capas OSI que facilita la discusión de los problemas de interoperabilidad. El modelo de referencia OSI

La interconexión de sistemas abiertos (OSI) Modelo de referencia, representada en la figura 3516 , es el modelo utilizado para las comunicaciones de datos en TOGAF.Cada una de las siete capas del modelo representa uno o más servicios o protocolos (un conjunto de normas que regulan las comunicaciones entre sistemas), que definen la operación funcional de las comunicaciones entre los s y los elementos de red. Cada capa (con la excepción de la capa superior)

Página 431 de 670

The Open Group Architecture Framework TOGOF 9.1   proporciona servicios para la capa por encima de ella. Este modelo tiene por objeto establecer el funcionamiento de sistemas abiertos e implica la implementación basada en estándares. Se esfuerza para permitir diferentes sistemas para llevar a cabo la interoperabilidad completa y la calidad de funcionamiento en toda la red. Las siete capas del modelo OSI están estructurados para facilitar el desarrollo independiente dentro de cada capa y para proporcionar cambios independientes de otras capas. Protocolos estándares internacionales estables en conformidad con las definiciones de capas OSI modelo de referencia han sido publicadas por diversos organismos de normalización. Esto no quiere decir que los únicos protocolos que se ajustan en TOGAF son protocolos OSI. Otras normas de protocolo, como SNA o T / IP se pueden describir utilizando el modelo de capas OSI de siete como referencia. Soporte y áreas de negocio de aplicaciones, tal como se define en TOGAF, están por encima de la pila de protocolos modelo de referencia OSI y el uso de sus servicios a través de la capa de aplicaciones. Marco de comunicaciones

Un sistema de comunicaciones basado en el modelo de referencia OSI incluye los servicios en todas las capas pertinentes, el apoyo y el software de aplicación de área de negocio que se encuentra por encima de la capa de aplicación del modelo de referencia OSI y el equipo físico que lleva los datos. Estos elementos se pueden agrupar en niveles arquitectónicos que representan las principales capacidades funcionales, tales como la conmutación y el enrutamiento, la transferencia de datos y el rendimiento de las aplicaciones.

Figura 35‐16: modelo de referencia OSI Página 432 de 670

The Open Group Architecture Framework TOGOF 9.1   Estos niveles arquitectónicos son: 

El nivel de transmisión (por debajo de la capa física del modelo de referencia OSI) proporciona todas las capacidades físicas y electrónicas, las cuales establecen una ruta de transmisión entre los elementos funcionales del sistema (cables, circuitos arrendados, interconexiones, etc.)



La red de conmutación de nivel (capas OSI 1 a 3), establece la conectividad a través de los elementos de la red para soportar el encaminamiento y control del tráfico (interruptores, controladores, software de red, etc.)



El nivel de intercambio de datos (capas OSI 4 a 7) lleva a cabo la transferencia de la información después de que la red se ha establecido (de extremo a extremo, la transferencia de a ) que incluye elementos más capaces de procesamiento (hosts, estaciones de trabajo, servidores, etc ). En el TRM, servicios de la capa de aplicación OSI se consideran parte de la entidad plataforma de aplicaciones, ya que ofrecen interfaces estandarizadas a la entidad de programación de aplicaciones.



El nivel del Programa de Aplicaciones (por encima de la OSI) incluye el apoyo y aplicaciones en áreas de negocios (programas de aplicación no de gestión).

El marco de las comunicaciones se define para consistir en los tres componentes geográficos de la infraestructura de comunicaciones (local, regional y global) y los cuatro niveles de la arquitectura (Programa de Aplicaciones de transmisión, conmutación de red, intercambio de datos, y), y se representa en la figura 35 - 17 . Los servicios de comunicaciones se llevan a cabo en uno o más de estos niveles de la arquitectura dentro de los componentes geográficos. Figura 35-17 muestra computación elementos (que operan a nivel de programa de aplicaciones) con el apoyo a elementos de intercambio de datos, vinculados entre sí a través de diversos elementos de conmutación (que funcionan a la Nivel de conmutación de red), cada uno situado dentro de su respectivo componente geográfico. Figura 35-17 también identifica la relación de TOGAF a la arquitectura de comunicación.

Página 433 de 670


Figura 35‐17: Marco de comunicaciones Asignación de Servicios a Componentes

La infraestructura de comunicaciones consta de los componentes de transporte local, regional y global. Los servicios destinados a estos componentes son idénticos a los servicios del programa de aplicación, el intercambio de datos, conmutación de red, o los niveles de arquitectura de transmisión que se aplican a un componente. Intercambio de datos y servicios de nivel de conmutación de red son idénticos a los servicios de las correspondientes capas de modelo de referencia OSI. Normalmente, sólo conmutación de redes y servicios de transmisión se asignan a los componentes regionales y globales, que consisten en nodos de comunicación y medios de transmisión. Todos los servicios se pueden realizar en el componente local, que incluye los dispositivos finales, nodos de procesamiento, nodos de comunicaciones, y los medios de comunicación de enlace. Transporte, transformación, transporte y aplicaciones son todas realizadas en este componente.

35.7.6 Desarrollo de un Vista de flujo de datos El punto de vista de flujo de datos se refiere a almacenamiento, recuperación, procesamiento, archivo y seguridad de los datos.

Página 434 de 670


Este punto de vista se debe desarrollar para los ingenieros de bases de datos del sistema. Las principales preocupaciones de este punto de vista son la comprensión de cómo proporcionar datos a las personas adecuadas y las aplicaciones con las interfaces adecuadas en el momento adecuado. Esta visión se refiere a la arquitectura del almacenamiento, recuperación, procesamiento, archivo y seguridad de los datos. Se ve en el flujo de datos a medida que se almacena y se procesa, y en qué se requerirá componentes para apoyar y gestionar tanto el almacenamiento y el procesamiento. En general, estos grupos de interés tienen que ver con garantizar el ubicuo a la información de alta calidad. 35.7.6.2 Desarrollo de la Vista

Los temas de la arquitectura general de un "sistema de base de datos" son componentes de base de datos o componentes que proporcionan servicios de bases de datos. El modelado de una "base de datos" se suele hacer con los diagramas de entidad-relación y definiciones de esquema, incluyendo las definiciones de tipo de documento. 35.7.6.3 Cuestiones clave

. Servicios de gestión de datos pueden ser proporcionados por una amplia gama de implementaciones Algunos ejemplos son: 

Las mega-centros que proporcionan las bases de datos corporativas orientación funcional de apoyo a las necesidades de datos locales y remotas



DBMS distribuido que apoyan el uso interactivo de las bases de datos con particiones y parcialmente replicados



Los sistemas de archivos proporcionados por los sistemas operativos, los cuales pueden ser utilizados por las aplicaciones de procesamiento tanto interactivos y por lotes

Servicios de gestión de datos incluyen el almacenamiento, la recuperación, la manipulación, la copia de seguridad, reinicio / recuperación, seguridad y funciones asociadas para texto, datos numéricos y de datos complejos, tales como documentos, gráficos, imágenes, audio y video. El sistema operativo proporciona servicios de gestión de archivos, pero que se consideran aquí porque existen muchas bases de datos de legado como uno o más archivos, sin los servicios de un DBMS. Los componentes principales que ofrecen servicios de gestión de datos que se describen en esta sección son: 

Sistemas de gestión de bases de datos (ver Sistemas de gestión de bases de datos )



Diccionario de Datos / Sistemas de directorios (ver diccionario de datos / Directory Systems )



istración de datos (en la istración de datos )

Página 435 de 670


Seguridad de los datos (ver Seguridad de Datos )

Estos son los aspectos críticos de la gestión de datos por las siguientes razones. El DBMS es el componente más crítico de cualquier capacidad de gestión de datos, y un sistema / directorio de diccionario de datos es necesario en colaboración con el DBMS como una herramienta para ayudar a la istración de la base de datos.Seguridad de los datos es una parte necesaria de toda política global para la seguridad en el procesamiento de información. Sistemas de Gestión de Base de Datos

Un sistema de gestión de bases de datos (DBMS) prevé la gestión sistemática de los datos. . Este componente de gestión de datos proporciona servicios y capacidades para la definición de los datos, la estructuración de los datos, acceder a los datos, así como la seguridad y la recuperación de los datos Un DBMS realiza las siguientes funciones: 

Estructuras de datos de una manera coherente



Proporciona a los datos



Minimiza la duplicación



Permite reorganización; es decir, cambios en el contenido de los datos, estructura, y el tamaño



Soporta las interfaces de programación



Proporciona seguridad y control

Un DBMS debe proporcionar: 

Persistencia; los datos siguen existiendo después de la ejecución de la aplicación se ha completado



Gestión de almacenamiento secundario



Concurrencia



Recuperación



Definición de Datos / Data Manipulation Language (DDL / DML), que puede ser una interfaz gráfica

Base de datos Modelos

El modelo de datos lógica que subyace a la base de datos que caracteriza a un DBMS. Los modelos de datos lógicos comunes son las siguientes: 

Modelo Relacional : Un sistema de gestión de base de datos relacional de datos (RDBMS) estructuras en tablas que tienen ciertas propiedades: o

Cada fila de la tabla es distinta de cada dos filas.

Página 436 de 670


Cada fila contiene sólo datos atómicos; es decir, no hay datos de repetición o estructuras tales como matrices.

o

Cada columna de la tabla relacional define campos o atributos de datos con nombre.

Una colección de tablas relacionadas en el modelo relacional constituye una base de datos. La teoría matemática de las relaciones subyace en el modelo relacional - tanto a la organización de los datos y los lenguajes que manipulan los datos. Edgar Codd, a continuación, en IBM, ha desarrollado el modelo relacional en 1973. Ha sido popular, en términos de uso comercial, desde principios de 1980. 

Modelo Jerárquico : El modelo de datos jerárquico organiza los datos en una estructura de árbol. Hay una jerarquía de segmentos de padres y de datos de niños.Esta estructura implica que un registro puede haber repetición de la información, en general, en los segmentos de datos secundarios. Por ejemplo, una organización puede almacenar información sobre un empleado, como nombre, número de empleado, departamento, salario. La organización también puede almacenar información acerca de los niños de un empleado, como nombre y fecha de nacimiento. Los datos de los empleados y los niños forman una jerarquía, donde los datos de empleado representa el segmento de los padres y de los datos de los niños representa el segmento infantil. Si un empleado tiene tres hijos, entonces no habría tres segmentos secundarios asociados con un segmento de los empleados. En una base de datos jerárquica de la relación padre-hijo es uno-amuchos. Esto restringe un segmento niño a tener sólo un segmento de matriz. DBMS jerárquicos fueron populares desde finales de 1960, con la introducción del Sistema de Gestión de la Información de IBM (IMS) DBMS, a través de la década de 1970.



Modelo de la Red : La popularidad del modelo de datos de la red coincide con la popularidad del modelo de datos jerárquico. Algunos datos se modelan de forma más natural con más de un padre por niño. Así, el modelo de red permite el modelado de muchos-a-muchos en los datos. En 1971, la Conferencia sobre Sistemas de Datos Idiomas (CODASYL) define formalmente el modelo de red. La construcción básica de modelado de datos en el modelo de red es la construcción de conjunto.Un conjunto consiste en un tipo de propietario registro, un nombre de conjunto, y un tipo de registro miembro. Un tipo de registro miembro puede tener ese papel en más de un conjunto, de ahí el concepto multipadre es compatible. Un tipo de registro propietario también puede ser miembro o propietario en otro conjunto. El modelo de red CODASYL se basa en la teoría matemática de conjuntos.



Orientada a objetos Modelo : Un sistema de gestión de base de datos orientada a objetos (SGBDOO) debe ser a la vez un DBMS y un sistema orientado a objetos. Como DBMS debe proporcionar las capacidades identificadas anteriormente. OODBMS normalmente puede modelar datos tabulares, datos complejos, datos jerárquicos, y las redes de datos. Las siguientes son características importantes de un sistema orientado a objetos: o

Los objetos complejos: por ejemplo, los objetos pueden estar compuestos de otros objetos.

o

Objeto de identidad: cada objeto tiene un identificador único externo a los datos.

o

Encapsulación: un objeto consta de datos y los programas (o métodos) que manipularlo.

Página 437 de 670




o

Tipos o clases: una clase es una colección de objetos similares.

o

Herencia: subclases heredan los atributos y los métodos de las clases de datos.

o

Reemplazar con el enlace en tiempo: el método particular de una subclase puede reemplazar el método de una clase en tiempo de ejecución.

o

Extensibilidad: por ejemplo, un puede definir nuevos objetos.

o

Completitud computacional: un lenguaje de propósito general (tal como Ada, C o C + +) es computacionalmente completa. El lenguaje SQL de propósito especial no lo es. La mayoría de OODBMS incorporan un lenguaje de programación de propósito general.

Archivos planos : Un sistema de archivos planos está estrechamente asociada con un método de de almacenamiento. Un ejemplo es el método de secuencial indizado de IBM (ISAM). Los modelos analizados anteriormente en esta sección son modelos de datos lógicos; archivos planos requieren que el trabajar con la disposición física de los datos en un dispositivo de almacenamiento. Por ejemplo, el debe conocer la ubicación exacta de un elemento de datos en un registro. Además, los archivos planos no proporcionan todos los servicios de un DBMS, tales como la designación de los datos, la eliminación de la redundancia y control de concurrencia. Además, no hay independencia de los datos y el programa de aplicación. El programa de aplicación debe conocer la disposición física de los datos.

SGBD Distribuidos

Un DBMS distribuido gestiona una base de datos que se extiende sobre más de una plataforma. La base de datos puede basarse en cualquiera de los modelos de datos mencionados anteriormente (excepto el archivo plano). La base de datos puede ser replicado, particiones, o una combinación de ambos. Una base de datos replicada es una en la que existen copias completas o parciales de la base de datos en las diferentes plataformas. Una base de datos particionada es una en la que parte de la base de datos es en una plataforma y partes son en otras plataformas. La partición de una base de datos puede ser vertical u horizontal. Una partición vertical pone algunos campos y los datos asociados en una sola plataforma y algunos campos y los datos asociados en otra plataforma. Por ejemplo, considere una base de datos con los siguientes campos: identificación de empleado, nombre del empleado, departamento, número de dependientes, proyecto asignado, tasa de salario, impuesto tasa. Una partición vertical podría colocar la identificación del empleado, número de dependientes, la tasa de salario y tasa de impuestos en una plataforma y el nombre del empleado, departamento y proyecto asignado en otra plataforma. Una partición horizontal puede mantener todos los campos en todas las plataformas, pero la distribución de los registros. Por ejemplo, una base de datos con 100.000 registros podría poner los primeros 50.000 registros en una plataforma y los segundos 50.000 registros en una segunda plataforma. Si la base de datos distribuida se replica o se repartió, un único DBMS gestiona la base de datos. Hay un único esquema (descripción de los datos en una base de datos en términos de un modelo de datos; por ejemplo, relacional) para una base de datos distribuida. La distribución de la base de datos es generalmente transparente para el . El término "DBMS distribuido" implica homogeneidad. Distribuidos Heterogéneos DBMS

Página 438 de 670

The Open Group Architecture Framework TOGOF 9.1   Un sistema distribuido de bases de datos heterogéneas es un conjunto de bases de datos independientes, cada uno con sus propios DBMS, presenta a los s como una única base de datos y sistema. "Federados" se utiliza como sinónimo de "distribuido heterogéneo". La heterogeneidad se refiere a las diferencias en los modelos de datos (por ejemplo, de la red y relacionales), los DBMS de diferentes proveedores, plataformas de hardware diferentes, u otras diferencias. Los tipos más simples de los sistemas de bases de datos federadas son comúnmente llamadas "puertas de ". En una puerta de entrada, un proveedor (por ejemplo, Oracle) proporciona unidireccional a través de sus DBMS a otra base de datos gestionada por DBMS de un proveedor diferente (por ejemplo, DB2 de IBM). Los dos DBMS no necesitan compartir el mismo modelo de datos. Por ejemplo, muchos proveedores de RDBMS son portales a los DBMS jerárquicos y de red. Hay sistemas de bases de datos federadas, tanto en el mercado y en la investigación que proporcionan un más general a los diversos DBMS. Estos sistemas suelen proporcionar un componente de integración de esquemas para integrar los esquemas de las diversas bases de datos y presentarlos a los s como una única base de datos, un componente de gestión de consultas para distribuir las consultas a los diferentes DBMS en la federación, y un componente de gestión de transacciones, para distribuir y gestionar los cambios en las distintas bases de datos de la federación. Diccionario de Datos / Sistemas de directorios

El segundo componente de la prestación de servicios de gestión de datos, el Diccionario / Sistema de Directorio de Datos (DD / DS), se compone de los servicios públicos y los sistemas necesarios para el catálogo, documentar, gestionar, y el uso de metadatos (datos sobre los datos). Un ejemplo de los metadatos es la siguiente definición: una larga cadena alfanumérica de seis caracteres, en el que el primer carácter es una letra del alfabeto y cada uno de los restantes cinco caracteres es un número entero entre 0 y 9; el nombre de la cadena es "la identificación del empleado " . Las utilidades DD / DS hacen uso de archivos especiales que contienen el esquema de base de datos. (Un esquema, el uso de metadatos, define el contenido y la estructura de una base de datos.) Este esquema está representado por un conjunto de tablas para incluir en la compilación de definición de datos (DDL) Idioma. El DD / DS normalmente se proporciona como parte de un DBMS pero a veces está disponible a partir de fuentes alternativas. En la gestión de datos distribuidos, información de distribución también se puede mantener en el sistema de directorio de red. En este caso, la interfaz entre los DD / DS y el sistema de directorio de red sería a través de la API del componente de servicios de red en la plataforma. En los entornos actuales, diccionarios de datos se suelen integrar con el DBMS y sistemas de directorio se limitan por lo general a una sola plataforma. Directorios de red se usan para expandir el reino DD / DS. La relación entre los DD / DS y el directorio de red es una combinación compleja de fuentes físicos y lógicos de datos. istración de Datos

La istración de datos aborda adecuadamente la arquitectura de datos, que está fuera del alcance de TOGAF. Se discuten brevemente aquí debido a las áreas de superposición. Se ocupa de todos los recursos de datos de una empresa, y como tal hay solapamientos con la gestión de datos, que se ocupa de los datos en bases de datos. Dos áreas específicas de superposición son los depositarios y istración de base de datos, que se describen brevemente a continuación. Repositorio

Página 439 de 670

The Open Group Architecture Framework TOGOF 9.1   Un repositorio es un sistema que gestiona todos los datos de la empresa, que incluye datos y modelos de procesos y otra información de la empresa. Por lo tanto, los datos en un repositorio es mucho más extensa que la de una DD / DS, que por lo general sólo define los datos que forman una base de datos. istración de bases de datos

La istración de datos y istración de base de datos son procesos complementarios. La istración de datos es responsable de los datos, estructura de datos, y la integración de datos y procesos. istración de base de datos, por otro lado, incluye el diseño físico, desarrollo, implementación, seguridad y mantenimiento de las bases de datos físicos. istración de base de datos es responsable de la gestión y aplicación de las políticas de la empresa relacionadas con bases de datos individuales. Seguridad de los datos

El tercer componente de la prestación de servicios de gestión de datos es la seguridad de los datos. Esto incluye los procedimientos y las medidas tecnológicas aplicadas para prevenir el no autorizado, modificación, uso y difusión de los datos almacenados o procesados por un sistema informático. La seguridad de datos incluye también la integridad de datos (es decir, preservar la exactitud y validez de los datos), y proteger el sistema de daños físicos (incluidas las medidas preventivas y los procedimientos de recuperación). Control de autorización permite sólo los s autorizados tengan a la base de datos en el nivel adecuado. Directrices y procedimientos se pueden establecer para la rendición de cuentas, los niveles de control, y el tipo de control. Autorización para el control de los sistemas de bases de datos difiere de la de los sistemas de archivos tradicionales, ya que, en un sistema de base de datos, no es raro para que diferentes s tienen diferentes derechos a los mismos datos. Este requisito abarca la capacidad de especificar subconjuntos de datos y para distinguir entre grupos de s. Además, el control descentralizado de las autorizaciones es de particular importancia para los sistemas distribuidos. La protección de datos es necesario para evitar que los s no autorizados de comprender el contenido de la base de datos. El cifrado de datos, como uno de los métodos primarios para la protección de datos, es útil tanto para la información almacenada en el disco y de la información intercambiada en una red.

35.7.7 Desarrollo de una empresa de istración Ver La visión empresarial de istración se ocupa de las operaciones, la istración y gestión del sistema. 35.7.7.1 Las partes interesadas y Preocupaciones

Este punto de vista debe ser desarrollado para las operaciones, la istración y el personal de gestión del sistema. Las principales preocupaciones de estos grupos de interés son la comprensión de cómo el sistema se gestiona como un todo, y cómo se controlan todos los componentes del sistema. La preocupación principal es la gestión de cambio en el sistema y predecir el mantenimiento preventivo necesario.

Página 440 de 670

The Open Group Architecture Framework TOGOF 9.1   En general, estos grupos de interés tienen que ver con garantizar que la disponibilidad del sistema no sufre cuando se produzcan cambios. istrar el sistema incluye istración de componentes como: 

Componentes de seguridad



Los activos de datos



Activos de software



Los activos de hardware



Redes activos

35.7.7.2 Desarrollo de la Vista

Escenarios de negocios son una manera muy útil para describir lo que debe suceder cuando se planifican y se producen acontecimientos imprevistos. Es altamente recomendable que los escenarios de negocio pueden crear para el cambio planificado, y para el cambio no planificado. A continuación se describen algunas de las cuestiones clave que el arquitecto podría considerar en la construcción de escenarios de negocio.

35.7.7.3 Cuestiones clave

La visión empresarial de istración actúa como un control y equilibrio sobre las dificultades y el día a día los gastos de funcionamiento de los sistemas construidos en la nueva arquitectura. A menudo, la gestión del sistema no se considera hasta que se hayan tomado todas las decisiones de compra y de desarrollo importantes, y tener una visión de gestión independiente en una etapa temprana en el desarrollo de la arquitectura es una forma de evitar este escollo. Es una buena práctica para desarrollar la visión empresarial de istración con un examen atento de la opinión de Ingeniería de Sistemas , ya que, en general, la gestión es difícil de adaptar en un diseño existente. Los elementos clave de la visión empresarial de istración son: 

Las políticas, los procedimientos y directrices que impulsan sus necesidades de gestión (por ejemplo, una política para restringir la descarga de software desde Internet)



Cómo su disponibilidad del sistema de medidas de la tienda



Los servicios de gestión y los servicios públicos necesarios



La magnitud que pueda, calidad y ubicación del personal de gestión y apoyo



La capacidad de los s para asumir las tareas de istración del sistema, tales como el mantenimiento de contraseñas



La capacidad de istración de los componentes existentes y previstas en cada una de las categorías de componentes

Página 441 de 670


Si la istración debe ser centralizada o distribuida



Si la seguridad es responsabilidad de los es de sistemas o un grupo separado, teniendo en cuenta todos los requisitos legales

Componentes técnicos principales categorías que son objeto de la operación vista empresarial de istración con el cambio, ya sean mejoras previstas, o interrupciones no planificadas. La siguiente tabla muestra las preocupaciones específicas de cada categoría de componente.

Categoría de Consideraciones sobre el cambio componentes planeadas Componentes de ¿Cómo se propaga un cambio de seguridad seguridad en todo el sistema?

Modificación imprevista Consideraciones ¿Qué debe suceder cuando se viola la seguridad?

¿Quién es responsable de hacer los cambios; s finales, o guardias de seguridad? Activos de Datos ¿Cómo se añaden nuevos elementos de datos?

¿Qué debe ocurrir si un componente de seguridad falla?

¿Cuáles son los procedimientos de respaldo y son todas las capacidades del sistema de copia de seguridad allí en el ¿Cómo se importan los datos / exportados tiempo? o carga / sin carga? ¿Cómo se gestiona la copia de seguridad mientras se ejecuta de forma continua?

Activos de Software

¿Cómo se propaga el cambio de datos en un entorno distribuido? ¿Qué es lo que quieres que ocurra cuando ¿Cómo es una nueva aplicación introducida en los sistemas? falla una aplicación? ¿Qué procedimientos existen para controlar la calidad del software?

¿Qué es lo que quieres que ocurra cuando falla un recurso de la aplicación?

¿Cómo se propagan los cambios de aplicaciones en un entorno distribuido?

Activos de Hardware Networking Activo

¿Cómo es la introducción de software no deseado restringido dada la Internet? ¿Cómo evalúa el impacto del nuevo ¿Qué es lo que quieres que ocurra cuando hardware en el sistema, especialmente la se producen interrupciones de hardware? red de carga? ¿Cómo evalúa el impacto de los nuevos componentes de red? ¿Cómo optimizar los componentes de red?

35.7.8 Desarrollo de un Adquirente Ver La vista adquiriente tiene que ver con la adquisición de Commercial Off-The-Shelf (COTS) de software y hardware.

Página 442 de 670


Este punto de vista debe ser desarrollado para el personal que participa en la adquisición de cualquiera de los componentes de la arquitectura de tema. Las principales preocupaciones de estos grupos de interés son la comprensión de lo que la construcción de bloques de la arquitectura se pueden comprar, y qué restricciones (o reglas) existen que son relevantes para la compra. La adquirente comprará con múltiples proveedores en busca de la mejor solución de coste, si bien respetando las restricciones (o reglas) aplicadas por la arquitectura, como las normas. La principal preocupación es hacer que las decisiones de compra que se ajustan a la arquitectura, y por lo tanto reducir el riesgo de los costos adicionales que surjan a partir de componentes que no cumplen. 35.7.8.2 Desarrollo de la Vista

La vista adquirente normalmente se representa como una arquitectura de soluciones de Bloques de Construcción (SBB), complementados con vistas a las normas que deben ser respetados por los bloques de construcción individuales. 35.7.8.3 Cuestiones clave

El adquirente normalmente se ejecuta un proceso similar a la de abajo. Dentro de las descripciones de pasos que podemos ver las preocupaciones y problemas que enfrenta la entidad adquirente.

Etapas del Paso Descripción y Salida Proceso de Contratación Planificación Crea el plan para la compra de algún componente. Para los sistemas de TI, las siguientes consideraciones son pertinentes a la construcción de bloques. Adquisición Este paso requiere el a la Arquitectura Bloques de Construcción (Abs) y SBB.

Exploración Concept



El proxeneta necesita saber qué ABBS aplicar restricciones (estándares) para su uso en la evaluación y para la creación de RFP / RFI.



El proxeneta necesita saber qué SBB candidatos se adhieran a estos estándares.



El procurador también necesita saber qué proveedores ofrecen SBB aceptados, y en el que han sido desplegados.



El procurador tiene que saber cuál es el presupuesto de este componente fue dada en relación con el coste total del sistema.

En este paso, el procurador mira a la viabilidad del concepto. Bloques de construcción dan el planificador de un sentido de los riesgos existentes; si existen muchos ABBS o SBB que coinciden con el concepto, el riesgo es menor.

Página 443 de 670

The Open Group Architecture Framework TOGOF 9.1   Este paso requiere el a ABBS y SBB. El planificador necesita saber qué ABBS aplicar restricciones (estándares), y necesita saber qué SBB candidatos se adhieran a estos estándares. Demostración En este paso, el proxeneta trabaja con el desarrollo de un prototipo de una Concepto aplicación. El procurador recomienda los dispositivos SBB reutilizables basados en y Validación estándares en forma, y la experiencia pasada con los proveedores.

Desarrollo

Este paso requiere el a SBB reutilizables. En este paso, el proxeneta trabaja con el desarrollo para gestionar la relación con los proveedores que suministran los dispositivos SBB. Bloques de construcción que han demostrado ser aptos para esta finalidad y son marcados como aprobados.

Producción

Este paso requiere una actualización de la situación de "aprobado la contratación" de un SBB. En este paso, el proxeneta trabaja con el desarrollo para gestionar la relación con los proveedores que suministran los dispositivos SBB. Bloques de construcción que se ponen en producción consiguen debidamente marcado.

Despliegue

Este paso requiere una actualización de la situación a "la producción" de SBB, con el identificador del sistema de donde se está desarrollando el bloque de construcción. En este paso, el proxeneta trabaja con el desarrollo para gestionar la relación con los proveedores que suministran los dispositivos SBB. Bloques de construcción que están totalmente desplegados obtener debidamente marcado. Este paso requiere una actualización del estado a "desplegado" de SBB, con el identificador del sistema de que se ha desplegado el bloque de construcción.



Página 444 de 670


36. Arquitectura Entregables En este capítulo se ofrece una descripción de los entregables que se hace referencia en el Método de Desarrollo de Arquitectura ().

36.1 Introducción Este capítulo define los entregables que se suele consumidos y producidos en todo el ciclo de TOGAF . Como prestaciones suelen ser los productos de trabajo contractuales o formales de un proyecto de arquitectura, es probable que estas prestaciones se verán limitados o alterados por cualquier proyecto global o la gestión de procesos de la empresa (como CMMI, PRINCE2, PMBOK, o MSP). Por tanto, este capítulo está destinado a proporcionar una línea de base típica de la arquitectura entregables con el fin de definir mejor las actividades que se requieren en el y actuar como un punto de partida para la adaptación dentro de una organización específica. El marco de contenido TOGAF (ver la Parte IV , 33. Introducción ) identifica los entregables que se producen como salidas de la ejecución del ciclo y potencialmente consumidos como insumos en otros puntos de la . Otros entregables pueden producirse en otros lugares y consumidos por el . Entregables producidos por la ejecución de la se muestran en la tabla a continuación. Entregable Arquitectura Bloques de Construcción (Ver 36.2.1 Arquitectura Building Blocks ) Arquitectura Contrato (Ver 36.2.2 Arquitectura de licitación ) Arquitectura Definición de documento (Ver 36.2.3 Arquitectura de definición de documento ) Principios Arquitectura (Ver 36.2.4 Principios de Arquitectura ) Arquitectura Repositorio (Ver 36.2.5 Arquitectura Repositorio )

La producción de ... F, H

De entrada a ... A, B, C, D, E

-

-

B, C, D, E, F

C, D, E, F, G, H

Preliminar, A, B, C, D Preliminar

Arquitectura Requisitos Especificación (ver 36.2.6 Arquitectura Especificación de Requisitos ) Arquitectura Roap (Ver 36.2.7 Arquitectura Roap ) Architecture Vision (Ver 36.2.8 Architecture Vision ) Principios de Actuación, objetivos de negocio, y los impulsores del negocio (Ver 36.2.9 Principios de Actuación, objetivos de negocio, y los impulsores del negocio ) Evaluación de Capacidad

B, C, D, E, F, Gestión de Requisitos

Preliminar, A, B, C, D, E, F, G, H Preliminar, A, B, C, D, E, F, G, H, Gestión de Requisitos C, D, Gestión de Requisitos

B, C, D, E, F

B, C, D, E, F

A, E Preliminar, A, B

B, C, D, E, F, G, H, Gestión de Requisitos A, B

A, E

B, C, D, E, F

Página 445 de 670

The Open Group Architecture Framework TOGOF 9.1   (Ver 36.2.10 Evaluación de Capacidad ) Solicitud de cambio (Ver 36.2.11 Solicitud de cambio ) Plan de Comunicación (Ver 36.2.12 Plan de Comunicaciones ) Evaluación de cumplimiento (Ver Evaluación del Cumplimiento 36.2.13 ) Implementación y Plan de Migración (Ver 36.2.14 Implementación y Plan de Migración ) Gobierno Modelo de Implementación (Ver 36.2.15 Implementación Modelo de Gobierno ) Modelo de Organización de Empresa Arquitectura (ver 36.2.16 Modelo de Organización de Empresa de Arquitectura ) Solicitud de Arquitectura Trabajo (Ver 36.2.17 Solicitud de Arquitectura de Trabajo ) Evaluación de Impacto Requisitos (Ver 36.2.18 Requisitos de Evaluación de Impacto ) Solución Building Blocks (Ver Solución 36.2.19 Building Blocks ) Declaración de Arquitectura de Trabajo (Ver 36.2.20 Declaración de Arquitectura de Trabajo ) Marco de Arquitectura Adaptado (Ver 36.2.21 Tailored Architecture Framework )

F, G, H

-

La

B, C, D, E, F

T

H

E, F

F

F

G, H

Preliminar

Preliminar, A, B, C, D, E, F, G, H,

Preliminar, F, H

Gestión de Requisitos A, G

Gestión de Requisitos

Gestión de Requisitos

T

A, B, C, D, E, F, G

A, B, C, D, E, F, G, H

B, C, D, E, F, G, H, Gestión de Requisitos

Preliminar, A

Preliminar, A, B, C, D, E, F, G, H, Gestión de Requisitos

36.2 Descripciones Entregables Las siguientes secciones ofrecen ejemplos de las descripciones de los entregables que se hace referencia en el . Tenga en cuenta que no todo el contenido descrito aquí tiene que estar contenido en una entrega especial. Más bien, se recomienda el uso de referencias externas cuando sea posible; por ejemplo, los planes estratégicos de una empresa no deben ser copiados a una Solicitud de Arquitectura Trabajo, sino más bien el título de los planes estratégicos deben ser referenciados. Además, no se sugiere que estas descripciones se deben seguir a la letra. Sin embargo, cada elemento debe ser considerado cuidadosamente; haciendo caso omiso de cualquier elemento de entrada o de salida puede causar problemas aguas abajo.

36.2.1 Arquitectura Bloques de Construcción Documentación de Arquitectura y modelos de arquitectura de repositorio de la empresa; véase la Parte IV , 37. Building Blocks .

Página 446 de 670

The Open Group Architecture Framework TOGOF 9.1   36.2.2 Arquitectura Contrato Propósito

Arquitectura contratos son los acuerdos conjuntos entre los socios de desarrollo y los patrocinadores de los entregables, la calidad y la aptitud para el propósito de una arquitectura . La implementación exitosa de estos acuerdos será entregado a través de la gobernanza arquitectura eficaz (véase la Parte VII , 50. Arquitectura de Gobierno). Mediante la implementación de un enfoque regido a la gestión de los contratos, lo siguiente será garantizada: 

Un sistema de monitoreo continuo para comprobar la integridad, los cambios, la toma de decisiones, y la auditoría de todas las actividades relacionadas con la Arquitectura dentro de la organización



La adhesión a los principios, las normas y los requisitos de las arquitecturas existentes o en desarrollo



Identificación de los riesgos en todos los aspectos del desarrollo y la implementación de la arquitectura (s) que cubre el desarrollo interno contra las normas aceptadas, políticas, tecnologías y productos, así como los aspectos operativos de las arquitecturas de tal manera que la organización pueda continuar sus actividades dentro de un entorno resistente



Un conjunto de procesos y prácticas que garanticen la rendición de cuentas, la responsabilidad y la disciplina en relación con el desarrollo y el uso de todos los artefactos arquitectónicos



Una comprensión formal de la organización de gobierno responsable del contrato, su nivel de autoridad, y el ámbito de la arquitectura bajo el gobierno de este órgano

Contenido

Contenido típico de un diseño y desarrollo de contratos de Arquitectura son: 

Introducción y antecedentes



La naturaleza del acuerdo



Alcance de la arquitectura



Arquitectura y estratégicos principios y los requisitos



Los requisitos de conformidad



Proceso y las funciones de desarrollo y gestión de la Arquitectura



Medidas Arquitectura Target



Fases definidas de entregables



Plan de trabajo conjunto priorizado



Ventana de tiempo (s)

Página 447 de 670


Arquitectura de entrega y de negocios métricas

Los contenidos típicos de la arquitectura de licitación de un negocio de los s son: 

Introducción y antecedentes



La naturaleza del acuerdo



Alcance



Requisitos estratégicos



Los requisitos de conformidad



Arquitectura adoptantes



Ventana de tiempo



Arquitectura métricas de negocio



Arquitectura de servicios (que incluye el contrato de nivel de servicio (SLA))

Para más detalles sobre el uso de la arquitectura de Contratos, consulte la Parte VII , 49. Arquitectura de Contratos .

36.2.3 Arquitectura de definición de documento Propósito

La definición de documento La arquitectura es el contenedor de entrega de los artefactos arquitectónicos básicos creados durante el proyecto y para obtener información importante relacionada. La definición de documento Arquitectura abarca todos los ámbitos de arquitectura (negocio, datos, aplicaciones y tecnología) y también examina todos los estados relevantes de la arquitectura (línea de base, transición y meta). Una arquitectura de transición muestra la empresa en un estado de gran importancia arquitectónica entre la línea de base y Target Arquitecturas. Arquitecturas de transición se utilizan para describir las arquitecturas objetivo transitorias necesarias para la realización efectiva de la arquitectura destino. La definición de documento La arquitectura es un complemento de la arquitectura de Especificación de Requisitos, con un objetivo complementario: 

La definición de documento Arquitectura proporciona una visión cualitativa de la solución y tiene por objeto comunicar la intención de los arquitectos.



La especificación de arquitectura Requisitos ofrece una visión cuantitativa de la solución, indicando los criterios cuantificables que deben cumplirse durante la implementación de la arquitectura.

Contenido

Página 448 de 670

The Open Group Architecture Framework TOGOF 9.1   Los contenidos típicos de una definición de arquitectura de documento son: 

Alcance



Metas, objetivos y limitaciones



Principios Arquitectura



Arquitectura de línea de base



Modelos de arquitectura (por cada estado para modelar): o

Modelos Arquitectura Profesiones

o

Modelos de arquitectura de datos

o

Modelos de arquitectura de la aplicación

o

Modelos de arquitectura tecnológica



Fundamento y justificación de enfoque arquitectónico



Mapeo de Arquitectura Repositorio: o

Mapeo de Arquitectura del Paisaje

o

Mapeo para referenciar los modelos

o

Mapeo de las normas

o

Evaluación Reutilización



Análisis de las deficiencias



La evaluación del impacto



Arquitectura de transición: o

Definición de estados de transición

o

Arquitectura de negocios para cada estado de transición

o

Arquitectura de datos para cada estado de transición

o

Arquitectura de aplicaciones de cada estado de transición

o

Arquitectura Tecnológica para cada estado de transición

36.2.4 Principios Arquitectura Propósito

Los principios son normas generales y directrices, destinadas a ser duradera y rara vez modificada, que informan y apoyan la forma en que una organización se marca sobre el cumplimiento de su misión.

Página 449 de 670

The Open Group Architecture Framework TOGOF 9.1   A su vez, los principios pueden ser sólo un elemento de un conjunto estructurado de ideas que en conjunto definen y guías de la organización, a partir de los valores a través de acciones y resultados. Contenido

Ver Parte III , 23. Principios de Arquitectura de directrices y un conjunto detallado de principios de arquitectura genéricos, entre ellos: 

Principios empresariales (véase 23.6.1 Principios de Negocios )



Principios de datos (véase 23.6.2 Datos Principios )



Principios de aplicación (ver 23.6.3 Principios de Aplicación )



Principios Tecnología (ver 23.6.4 Principios Tecnológicos )

36.2.5 Arquitectura Repositorio Propósito

La arquitectura de repositorio actúa como una zona de espera para todos los proyectos relacionados con la arquitectura dentro de la empresa. El repositorio permite que los proyectos para la gestión de sus entregables, localizar reutilizables activos, y publicar los resultados a las partes interesadas y otras partes interesadas. Contenido

Véase la Parte V , 41. Arquitectura Repositorio para obtener una descripción detallada del contenido de un repositorio de Arquitectura.

36.2.6 Arquitectura Especificación de Requisitos Propósito

La especificación de arquitectura Requisitos proporciona un conjunto de enunciados cuantitativos que describen lo que un proyecto de implementación debe hacer para cumplir con la arquitectura. Una arquitectura de Especificación de Requisitos típicamente formará un componente importante de un contrato de ejecución o contratar más detallada Arquitectura Definición. Como se mencionó anteriormente, la arquitectura de Especificación de Requisitos es un complemento de la definición de documento de Arquitectura, con un objetivo complementario: 

La definición de documento Arquitectura proporciona una visión cualitativa de la solución y tiene por objeto comunicar la intención del arquitecto.



La especificación de arquitectura Requisitos ofrece una visión cuantitativa de la solución, indicando los criterios cuantificables que deben cumplirse durante la implementación de la arquitectura.

Contenido

Página 450 de 670

The Open Group Architecture Framework TOGOF 9.1   Los contenidos típicos de una arquitectura de Especificación de Requisitos son: 

Medidas de éxito



Requisitos de arquitectura



Contratos de servicios de negocios



Contratos de servicios de aplicaciones



Directrices de implementación



Las especificaciones de implementación



Las normas de aplicación



Requisitos de interoperabilidad






Restricciones



Supuestos

36.2.7 Arquitectura Roap Propósito

La Arquitectura Roap enumera los paquetes de trabajo individuales que realizarán la arquitectura destino y las coloca en una línea de tiempo para mostrar la progresión de la Arquitectura de referencia para la arquitectura destino. La Hoja de Ruta de la arquitectura destaca el valor del negocio paquetes de trabajo individuales en cada etapa.Arquitecturas de transición necesarias para realizar eficazmente la Arquitectura objetivo se identifican como pasos intermedios. La Hoja de Ruta de la arquitectura se desarrolla gradualmente a lo largo de las fases E y F, e informada por los componentes de la hoja de ruta fácilmente identificables de la Fase B, C y D dentro de la . Contenido

Los contenidos típicos de una hoja de ruta de la Arquitectura son: 

Cartera Paquete de trabajo: o

Descripción Paquete de trabajo (nombre, descripción, objetivos, entregables)

o


o

Dependencias

o

Relación con la oportunidad

o

Relación a la Arquitectura de definición de documento y Arquitectura Especificación de Requisitos

Página 451 de 670





Evaluación Factor de Aplicación y de la matriz de deducción, incluyendo: o

Riesgos

o

Cuestiones

o

Supuestos

o

Dependencias

o

Acciones

o

Entradas

Brechas consolidados, soluciones, y la matriz de dependencias, entre ellas: o

Arquitectura dominio

o

Brecha

o

Posibles soluciones

o

Dependencias



Cualquier Arquitecturas de transición



Recomendaciones para la implementación: o

Criterios de valoración de la eficacia de los proyectos

o

Riesgos y problemas

o

Bloques de Solución de construcción (SBB)

36.2.8 Architecture Vision Propósito

El Architecture Vision se crea desde el principio en el ciclo de . Proporciona un resumen de los cambios a la empresa que se derivarán de la implementación exitosa de la arquitectura destino. El propósito de la Architecture Vision es proporcionar actores clave con un resultado acordado formalmente. Pronto acuerdo sobre el resultado permite a los arquitectos para centrarse en los detalles necesarios para validar la factibilidad. Proporcionar una Architecture Vision también es compatible con la comunicación de las partes interesadas, proporcionando una versión resumida de la arquitectura Definición completa. Contenido

Los contenidos típicos de una Visión Arquitectura son: 

Descripción del problema:

Página 452 de 670


Las partes interesadas y sus preocupaciones

o

Lista de temas / situaciones que deben abordarse






Resumen considera necesaria para la solicitud de Arquitectura Trabajo y la versión 0.1 de negocios, aplicaciones, datos y tecnología Arquitecturas creó; típicamente incluyendo: o

Diagrama de la cadena de valor

o

Diagrama conceptual de soluciones



Requisitos asignados



Referencia al proyecto de arquitectura Definición de documento

36.2.9 Principios de Actuación, objetivos de negocio, y los impulsores del negocio Propósito

Principios de Actuación, los objetivos de negocio, y los impulsores del negocio proporcionan un contexto para el trabajo de la arquitectura, mediante la descripción de las necesidades y formas de trabajo empleado por la empresa. No obstante, muchos factores que están fuera de la consideración de la arquitectura la disciplina pueden tener implicaciones importantes para la forma en que la arquitectura se desarrolla. Contenido

El contenido y la estructura del contexto de negocios para la arquitectura puede variar considerablemente de una organización a otra.

36.2.10 Evaluación de Capacidad Propósito

Antes de embarcarse en una arquitectura detallada definición, es valioso para comprender la línea de base y el nivel de capacidad objetivo de la empresa. Esta evaluación de la capacidad puede ser examinado en varios niveles: 

¿Cuál es el nivel de capacidad de la empresa en su conjunto? ¿De dónde viene la empresa desean aumentar u optimizar la capacidad? ¿Cuáles son las áreas de enfoque de arquitectura que apoyarán el desarrollo deseado de la empresa?



¿Cuál es la capacidad o nivel de madurez de la función de TI dentro de la empresa? ¿Cuáles son las posibles consecuencias de la realización del proyecto de arquitectura en términos de gobernanza o el diseño, la gestión operativa, habilidades y estructura de la organización? ¿Qué es un estilo apropiado, nivel de formalidad, y la cantidad de detalle para el proyecto de arquitectura para encajar con la cultura y la capacidad de la organización de TI?

Página 453 de 670


¿Cuál es la capacidad y la madurez de la función de la arquitectura dentro de la empresa? ¿Qué activos de arquitectura se encuentran actualmente en la existencia?¿Se mantienen y precisa? ¿Qué normas y modelos de referencia deben ser considerados? ¿Es probable que haya oportunidades para crear reutilizables activos durante el proyecto de arquitectura?



Cuando existan vacíos de capacidad, en qué medida es el negocio listo para transformar con el fin de alcanzar la capacidad de objetivo? ¿Cuáles son los riesgos para la transformación, las barreras culturales y otras consideraciones que deben abordarse más allá de la brecha de capacidades básicas?

Contenido

Los contenidos típicos de una Evaluación de Capacidad son: 





Evaluación de la capacidad del negocio, incluyendo: o

Capacidades del negocio

o

Evaluación del estado basal del nivel de rendimiento de cada capacidad

o

Futuro aspiración estado para el nivel de rendimiento de cada capacidad

o

Evaluación del estado de línea de base de cómo se realiza cada capacidad

o

Futuro aspiración estado para saber cómo debe ser realizado cada capacidad

o

Evaluación de los posibles impactos a la organización de la empresa resultante de la implementación exitosa de la arquitectura destino

Evaluación de capacidades de TI, incluyendo: o

Línea de base y objetivo de nivel de madurez del proceso de cambio

o

Nivel de partida y de destino de madurez de los procesos operativos

o

Evaluación de la capacidad de línea de base y la capacidad

o

Evaluación de los impactos probables a la organización de TI como resultado de la implementación exitosa de la arquitectura destino

Evaluación de la madurez de la Arquitectura, que incluye: o

Procesos de gobernanza Arquitectura, organización, funciones y responsabilidades

o

Evaluación de habilidades Arquitectura

o

Amplitud, profundidad y calidad de la definición del paisaje con el Repositorio de Arquitectura

o

Amplitud, profundidad y calidad de definición las normas con el Repositorio Arquitectura

o

Amplitud, profundidad y calidad de la determinación del modelo de referencia con el Repositorio de Arquitectura

Página 454 de 670


Evaluación de re-uso potencial

Preparación para la transformación del negocio de Evaluación, que incluye: o

Factores de Preparación

o

Visión para cada factor de preparación

o

Las calificaciones de preparación actuales y de destino

o

Riesgos de Preparación

36.2.11 Solicitud de Cambio Propósito

Durante la implementación de una arquitectura , a medida que más datos se dan a conocer, es posible que la definición y los requisitos de arquitectura original no son adecuadas o no son suficientes para completar la implementación de una solución. En estas circunstancias, es necesario que los proyectos de implementación de cualquiera desvían del enfoque arquitectónico sugerido o solicitar ampliaciones de ámbito. Además, los factores externos - como los factores del mercado, cambios en estrategia de negocios y nuevas oportunidades de la tecnología - pueden abrir oportunidades para ampliar y refinar la arquitectura. En estas circunstancias, una solicitud de cambio puede ser presentada con el fin de poner en marcha un nuevo ciclo de trabajo de la arquitectura. Contenido

Los contenidos típicos de una solicitud de cambio son: 

Descripción del cambio propuesto



Justificación del cambio propuesto



La evaluación del impacto del cambio propuesto, incluyendo:



o

Referencia a los requisitos específicos

o

Prioridad de los interesados de los requisitos a la fecha

o

Fases para ser revisitados

o

Fase de llevar sobre los requisitos de priorización

o

Los resultados de las investigaciones de fase y prioridades revisadas

o

Recomendaciones sobre la gestión de requisitos

Número de referencia del Repositorio

36.2.12 Plan de Comunicación Propósito

Página 455 de 670

The Open Group Architecture Framework TOGOF 9.1   Las arquitecturas empresariales contienen grandes volúmenes de información compleja e interdependiente. La comunicación efectiva de información dirigida a las partes interesadas adecuadas en el momento adecuado es un factor crítico de éxito para la arquitectura empresarial. Desarrollo de un Plan de Comunicación para la arquitectura permite esta comunicación se lleve a cabo dentro de un proceso planificado y gestionado. Contenido

Contenido típico de un plan de comunicaciones son: 

Identificación de las partes interesadas y la agrupación por las necesidades de comunicación



Identificación de las necesidades de comunicación, los mensajes clave en relación con el Architecture Vision, los riesgos de la comunicación, y factores críticos de éxito (CSF)



Identificación de los mecanismos que se utilizan para comunicarse con las partes interesadas y permitir el a la arquitectura de la información, tales como reuniones, boletines, repositorios, etc



Identificación de un calendario de comunicaciones, mostrando qué comunicaciones se produzcan con cuál grupo de participantes en qué momento y en qué lugar

36.2.13 Evaluación de cumplimiento Propósito

Una vez que una arquitectura se ha definido, es necesario para gobernar que la arquitectura a través de la aplicación para asegurarse de que el original Architecture Vision se realiza de manera adecuada y que ningún aprendizajes de implementación se introducen de nuevo en el proceso de la arquitectura. Revisiones de cumplimiento del período de los proyectos de aplicación proporcionan un mecanismo para revisar el progreso del proyecto y asegurarse de que el diseño y la implementación se avanzan en línea con los objetivos estratégicos y arquitectónicos. Contenido

Los contenidos típicos de una Evaluación de Cumplimiento son: 

Información general sobre el progreso y el estado del proyecto



Descripción general de la arquitectura del proyecto / diseño



Completadas las listas de verificación de arquitectura: o

Hardware y sistema operativo lista

o

Los servicios de software y middleware lista

o

Aplicaciones listas de comprobación

o

Listas de control de gestión de la información

o

Listas de control de seguridad

Página 456 de 670


Listas de control de gestión del sistema

o

Listas de control de ingeniería de sistemas

o

Métodos y herramientas de listas de verificación

36.2.14 Implementación y Plan de Migración Propósito

La aplicación y el Plan de Migración ofrece un calendario de los proyectos que realizarán la arquitectura destino. La aplicación y el Plan de Migración incluye proyectos ejecutables agrupados en carteras y programas gestionados. La Implementación y Estrategia de migración de identificar el enfoque para el cambio es un elemento clave de la aplicación y el Plan de Migración. Contenido

Contenido típico de una aplicación y el Plan de Migración son: 



Implementación y Estrategia de migración: o

Dirección estratégica aplicación

o

Enfoque de secuenciación de Implementación

Proyectos y Distribución de la cartera de ejecución: o

Asignación de los paquetes de trabajo para proyectar y de cartera

o

Capacidades entregados por proyectos

o

Hitos y calendario

o

Estructura de desglose del trabajo

o

Puede incluir el impacto sobre la cartera existente, programa y proyectos

Puede contener: 

Cartas del proyecto: o

Paquetes de trabajo incluidos

o


o

Riesgo, problemas, hipótesis, dependencias

o

Las necesidades de recursos y los costes

o

Beneficios de la migración, determinados (incluyendo la asignación a los requerimientos del negocio)

o

Estimación de los gastos de las opciones de migración

Página 457 de 670

The Open Group Architecture Framework TOGOF 9.1   36.2.15 Implementación Modelo de Gobierno Propósito

Una vez que una arquitectura se ha definido, es necesario planificar cómo la arquitectura de transición que implementa la arquitectura se regirá mediante la aplicación.Dentro de las organizaciones que han establecido las funciones de la arquitectura, no es probable que sea un marco de gobernanza que ya existen, pero los procesos específicos, las organizaciones, los roles, las responsabilidades y las medidas puede ser necesario definir sobre una base de proyecto por proyecto. El Gobierno asegura Modelo de Aplicación de que un proyecto de transición a la aplicación también pasa de manera ordenada en la gobernanza arquitectura apropiada. Contenido

Contenido típico de un Modelo de Gobierno de Ejecución se encuentran: 

Los procesos de gobernanza



Estructura de la organización de Gobierno



Funciones y responsabilidades de Gobierno



Los puestos de control de gobierno y los criterios de éxito / fracaso

36.2.16 Modelo Organizacional para Arquitectura Empresarial Propósito

Para que un marco de arquitectura para ser utilizado con éxito, debe ser apoyado por la correcta organización, las funciones y las responsabilidades dentro de la empresa.De particular importancia es la definición de los límites entre los distintos profesionales de arquitectura empresarial y de las relaciones de gobernanza que se extienden a través de estas fronteras. Contenido

Contenido típico de un modelo organizativo para la arquitectura de la empresa son los siguientes: 

















Página 458 de 670

The Open Group Architecture Framework TOGOF 9.1   36.2.17 Solicitud de Arquitectura Trabajo Propósito

Este es un documento que se envía desde la organización patrocinadora de la organización Arquitectura para desencadenar el inicio de un ciclo de desarrollo de la arquitectura. Las solicitudes de Arquitectura trabajo se pueden crear como una salida de la fase preliminar, a raíz de las solicitudes de cambio aprobadas arquitectura, o los términos de referencia para el trabajo de arquitectura procedentes de planificación de la migración. En general, toda la información contenida en este documento debe estar a un nivel alto. Contenido

Las solicitudes de Arquitectura trabajo suelen incluir: 

Patrocinadores Organización



Declaración de la misión de la Organización



Los objetivos de negocio (y cambios)



Los planes estratégicos de la empresa



Plazos



Los cambios en el entorno empresarial



Limitaciones de organización



La información presupuestaria, las limitaciones financieras



Las restricciones externas, restricciones comerciales



Descripción del sistema de negocio actual



Descripción del sistema actual arquitectura / TI



Descripción de desarrollar organización



Descripción de los recursos disponibles para el desarrollo de la organización

Evaluación de Impacto 36.2.18 Requisitos Propósito

A lo largo de la , la nueva información se recoge en relación con una arquitectura . Como se recoge esta información, nuevos hechos pueden salir a la luz que invalida los aspectos actuales de la arquitectura. A Requisitos de evaluación de impacto evalúa los requisitos de arquitectura actuales y las especificaciones para identificar los cambios que se deben hacer y las implicaciones de esos cambios.

Página 459 de 670

The Open Group Architecture Framework TOGOF 9.1   Contenido

Los contenidos típicos de una Evaluación de Impacto Los requisitos son: 

Referencia a los requisitos específicos



Prioridad de los interesados de los requisitos a la fecha



Fases para ser revisitados



Fase de llevar sobre los requisitos de priorización



Los resultados de las investigaciones de fase y prioridades revisadas



Recomendaciones sobre la gestión de requisitos



Número de referencia del Repositorio

Solución 36.2.19 Building Blocks -Implementación específica bloques de construcción de la empresa Arquitectura repositorio; véase la Parte IV , 37. Building Blocks .

36.2.20 Declaración de Arquitectura de Trabajo Propósito

La Declaración de Arquitectura Trabajo define el alcance y el enfoque que se utilizará para completar un ciclo de desarrollo de la arquitectura. La Declaración de Arquitectura El trabajo es por lo general el documento contra el cual se medirá la ejecución exitosa del proyecto de arquitectura y puede constituir la base de un acuerdo contractual entre el proveedor y el consumidor de servicios de arquitectura. Contenido

Los contenidos típicos de una Declaración de Arquitectura Trabajo son: 

Título



Arquitectura solicitud de proyecto y antecedentes



Arquitectura Descripción y alcance del proyecto



Descripción general de Arquitectura Visión



Cambio específico de los procedimientos de alcance



Las funciones, las responsabilidades y los entregables



Criterios y procedimientos de aceptación



Plan de la configuración y programación del proyecto

Página 460 de 670


Aprobaciones

36.2.21 Tailored Architecture Framework Propósito

TOGAF proporciona un marco estándar de la industria para la arquitectura que se puede utilizar en una amplia variedad de organizaciones. Sin embargo, antes de TOGAF se puede utilizar con eficacia dentro de un proyecto de arquitectura, sastrería a dos niveles es necesario. En primer lugar, es necesario adaptar el modelo TOGAF para la integración en la empresa. Esta adaptación incluye la integración con los marcos de los proyectos y de gestión de procesos, la personalización de la terminología, el desarrollo de estilos de presentación, selección, configuración y despliegue de herramientas de arquitectura, etc La formalidad y el detalle de las estructuras adoptadas también deben alinearse con otros factores contextuales para la empresa, tales como la cultura, las partes interesadas, los modelos comerciales para la arquitectura de la empresa, y el nivel actual de la arquitectura de Capacidad. Una vez que el marco se ha adaptado a la empresa, más la adaptación es necesaria con el fin de adaptar el marco del proyecto de arquitectura específica. Adaptación a este nivel seleccionará entregables y artefactos adecuados para satisfacer las necesidades del proyecto y las partes interesadas. Véase la Parte II , 6.4.5 Tailor TOGAF y, en su caso, Otros arquitectura marco seleccionado (s) para otras consideraciones al seleccionar y adaptar el marco de la arquitectura. Contenido

Contenido típico de un Marco de Arquitectura Tailored son: 










Interfaces con modelos de gobierno y otros marcos: o


o


o


o


o

Operaciones (Servicios)

Página 461 de 670


37. Bloques de Construcción En este capítulo se explica el concepto de bloques de construcción.

37.1 Información general Esta sección tiene por objeto explicar e ilustrar el concepto de bloques de construcción en la arquitectura. Después de esta visión general, hay dos partes principales: 

Introducción a los Bloques de construcción (véase 37.2 Introducción a los Bloques de Construcción ), discute los conceptos generales de bloques de construcción, y explica las diferencias entre Arquitectura Bloques de Construcción (Abs) y solución Building Blocks (SBB).



Bloques de Construcción y la ( 37.3 Bloques de Construcción y el ), resume las etapas en las que el diseño y la especificación de bloque de construcción se produce dentro de la Arquitectura Método de Desarrollo de TOGAF ().

37.2 Introducción a los Bloques de Construcción Esta sección es una introducción al concepto de bloques de construcción.

37.2.1 Información general En esta sección se describen las características de los bloques de construcción. La utilización de bloques de construcción en el se describe por separado en 37.3 Bloques de Construcción y el .

37.2.2 Características genéricas Bloques de construcción tienen características genéricas de la siguiente manera: 

Un bloque de construcción es un paquete de funcionalidad definida para satisfacer las necesidades del negocio en toda la organización.



Un bloque de construcción tiene un tipo que corresponde al contenido metamodelo TOGAF (como actor, servicio de negocios, la aplicación, o entidad de datos)



Un bloque de construcción tiene un límite definido y es generalmente reconocido como "una cosa" por los expertos de dominio.



Un bloque de construcción puede interoperar con otros, bloques de construcción, interdependientes.



Un buen bloque de construcción tiene las siguientes características:

Página 462 de 670


Se considera la implementación y el uso, y evoluciona para explotar la tecnología y las normas.

o

Se puede ensamblar a partir de otros bloques de construcción.

o

Puede ser un subconjunto de otros bloques de construcción.

o

Lo ideal es un bloque de construcción es reutilizable y reemplazable, y bien especificado.

Frontera y la especificación de un bloque de construcción deben ser débilmente acoplados a su aplicación; es decir, debe ser posible realizar un bloque de construcción de varias maneras diferentes sin impactar en el límite o la especificación del bloque de construcción. La forma en que los medios y capacidades se montan en bloques de construcción pueden variar ampliamente entre las arquitecturas individuales. Cada organización debe decidir por sí mismo lo que la disposición de bloques de construcción que funciona mejor para él. Una buena elección de bloques de construcción puede conducir a mejoras en la integración de sistemas de legado, la interoperabilidad y la flexibilidad en la creación de nuevos sistemas y aplicaciones. Los sistemas están construidos a partir de colecciones de bloques de construcción, por lo que la mayoría de los bloques de construcción que interoperar con otros bloques de construcción. Dondequiera que eso es cierto, es importante que las interfaces con un bloque de construcción se publican y razonablemente estable. Bloques de construcción se pueden definir en varios niveles de detalle, dependiendo de la etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una etapa temprana, un bloque de construcción puede consistir simplemente en un nombre o una breve descripción. Más tarde, un bloque de construcción se puede descomponer en varios bloques de edificios de apoyo y puede ir acompañada de una especificación completa. El nivel de detalle al que se debe especificar un bloque de construcción depende de los objetivos de la arquitectura y, en algunos casos, menos detalle puede ser de mayor valor (por ejemplo, en la presentación de las capacidades de una empresa, una única clara y concisa la imagen tiene más valor que una densa especificación de 100 páginas). El OMG ha desarrollado un estándar para la Especificación de activos reutilizables (RAS) , 1 que proporciona un buen ejemplo de cómo los bloques de construcción pueden ser descritas formalmente y gestionados.

37.2.3 Arquitectura Bloques de Construcción Arquitectura Bloques de Construcción (Abs) se refieren a la Arquitectura Continuum (véase la Parte V , 39.4.1 Arquitectura Continuum ), y se definen o seleccionados como resultado de la aplicación de la . 37.2.3.1 Características

Abs:

Página 463 de 670


Captura de requisitos de arquitectura; requisitos, por ejemplo, de negocio, datos, aplicaciones y tecnología



Dirigir y orientar el desarrollo de SBB

37.2.3.2 Especificación Contenido

Especificaciones de ABB son los siguientes, como mínimo: 

Funcionalidad y atributos fundamentales: semántico, sin ambigüedades, incluyendo la capacidad de seguridad y capacidad de gestión



Interfaces: conjunto elegido, suministrado



La interoperabilidad y la relación con otros bloques de construcción



Bloques de construcción dependientes con la funcionalidad requerida y las interfaces de con nombre



Mapa de negocios / entidades organizativas y políticas

37.2.4 Solución Building Blocks Solución Building Blocks (SBB) se relacionan con el Continuum Solutions (véase la Parte V , 39.4.2 Soluciones Continuum ), y puede ser o bien adquieren o se desarrollan. 37.2.4.1 Características

SBB: 

Definir cuáles son los productos y componentes serán implementar la funcionalidad



Definir la ejecución



Cumplir los requisitos de negocio



Son producto o proveedores conscientes

37.2.4.2 Especificación Contenido

Especificaciones SBB incluyen los siguientes, como mínimo: 

Funcionalidad y atributos específicos



Interfaces; el conjunto implementado



SBB necesarios que se utilizan con la funcionalidad y los nombres de las interfaces utilizadas requerido



Mapeo de la SBB con la topología de TI y las políticas operacionales

Página 464 de 670


Especificaciones de atributos compartidos a través del medio ambiente (que no debe confundirse con la funcionalidad), tales como seguridad, manejabilidad, localizabilidad, escalabilidad



Rendimiento, capacidad de configuración



Conductores Diseño y limitaciones, incluyendo la arquitectura física



Las relaciones entre los SBB y ABBS

37.3 Bloques de Construcción y el 37.3.1 Principios básicos Esta sección se centra en el uso de los bloques de construcción de la . Consideraciones generales y características de los bloques de construcción se describen en 37.2 Introducción a los Bloques de Construcción . 37.3.1.1 pilares en Arquitectura

Una arquitectura es un conjunto de bloques de construcción representados en un modelo arquitectónico, y una especificación de cómo esos bloques de construcción están conectados a cumplir con los requisitos generales de la empresa. Los diversos bloques de construcción en una arquitectura especifican el alcance y el enfoque que se utilizará para hacer frente a un problema de negocio específico. Hay algunos principios generales que sustentan el uso de bloques de construcción en el diseño de arquitecturas específicas: 

Una arquitectura sólo debe contener elementos básicos que son relevantes para el problema de negocio que la arquitectura está tratando de resolver.



Bloques de construcción pueden tener relaciones complejas entre sí. A una cuadra del edificio puede soportar múltiples bloques de construcción o puede apoyar parcialmente un solo bloque de construcción (por ejemplo, el servicio de negocio de "la tramitación de reclamaciones" sería apoyada por muchas entidades de datos y, posiblemente, varios componentes de la aplicación).



Bloques de construcción deben ajustarse a las normas pertinentes de su tipo, los principios de la empresa, así como las normas de la empresa.

37.3.1.2 Módulo de Diseño

El proceso de identificación de bloques de construcción incluye el estudio de las colecciones de las capacidades o activos que interactúan entre sí y luego dibujarlos juntos o haciéndolos diferente: 

Considere tres clases de bloques de construcción: o

Bloques de construcción reutilizables, como los elementos heredados

Página 465 de 670




o

Bloques de construcción a ser objeto de desarrollo, tales como las nuevas aplicaciones

o

Bloques de construcción a ser objeto de adquisición; es decir, Commercial OffThe-Shelf (COTS) aplicaciones

Utilice el nivel deseado de integración para unir o combinar funciones en bloques de construcción. Por ejemplo, los elementos heredados podrían ser tratados como grandes bloques de construcción para evitar que éstas se descompongan.

En las primeras etapas y durante visitas de la empresa de más alto nivel, los bloques de construcción son a menudo mantenidos en una definición amplia integración. Es durante estos ejercicios en que las definiciones de servicios a menudo puede ser mejor vieron. Como se abordan consideraciones de implementación, vistas más detalladas de bloques de construcción a menudo pueden utilizarse para hacer frente a las decisiones de implementación, se centran en las decisiones estratégicas críticas, o la ayuda en la evaluación del valor y el impacto futuro de lo común y reutilización.

37.3.2 Módulo Especificación de procesos en el El proceso de definición de bloque de construcción se lleva a cabo gradualmente a medida que la es seguido, sobre todo en las fases A, B, C y D. Se trata de un proceso iterativo porque como definición procede, información detallada sobre la funcionalidad requerida, las limitaciones impuestas a la arquitectura , y la disponibilidad de los productos puede afectar a la elección y el contenido de bloques de construcción. Las partes clave de la en el que los bloques de construcción están diseñados y especificados se resumen a continuación. La obra más importante en estos pasos consiste en identificar los ABBS necesarios para cumplir con las metas y objetivos de negocio. El conjunto seleccionado de ABBS se refina en un proceso iterativo para llegar a un conjunto de SBB, que puede ser comprado o bien off-the-shelf o la costumbre desarrollada. La especificación de la construcción de bloques utilizando el es un proceso evolutivo e iterativo. Las fases y etapas del en el que se desarrollaron y se especifican los bloques de construcción principales se resumen a continuación, y se ilustran en la Figura 37-1 .

Página 466 de 670


Figura 37‐1: Fases  / Pasos clave en la que los bloques de construcción están Evolved / especificado

Página 467 de 670


Parte V

Continuum Empresarial y Herramientas



Página 468 de 670


38. Introducción Este capítulo proporciona una introducción y una visión general de los contenidos de la Parte V: Empresa Continuum y Herramientas .

38.1 Introducción Por lo general es imposible crear una única arquitectura unificada que reúne todos los requisitos de todas las partes interesadas de todos los tiempos. Por lo tanto, la empresa arquitecto tendrá que lidiar no sólo con una única arquitectura de la empresa, pero con muchas arquitecturas empresariales relacionados. Cada arquitectura tendrá un propósito diferente y arquitecturas se relacionan entre sí. Efectivamente delimita el ámbito de aplicación de una arquitectura , por tanto, es un factor crítico de éxito en permitir que los arquitectos para romper un espacio de problemas complejos en componentes manejables que se pueden abordar de forma individual. The Enterprise Continuum ofrece una vista del Repositorio de Arquitectura que muestra la evolución de estas arquitecturas relacionadas de genérico a lo específico, de lo abstracto a concreto y de lógica física. Esta parte de TOGAF Enterprise Continuum discute; incluyendo el Continuum Arquitectura y el Continuum Solutions. En él se describe cómo las arquitecturas se pueden particionar y organizados dentro de un repositorio. También se describen las herramientas para el desarrollo de la arquitectura.

38.2 Estructura de la Parte V Parte V: Empresa Continuum y Herramientas se estructura de la siguiente manera: Introducción (este capítulo) The Enterprise Continuum (ver 39. Empresa Continuum ) describe una vista del Repositorio de Arquitectura que proporciona métodos para clasificar la arquitectura y los artefactos de la solución, que muestra cómo los diferentes tipos de artefactos evolucionan, y cómo pueden ser aprovechados y reutilizados. Arquitectura Particionamiento (ver 40. Arquitectura de particionamiento ) describe las diversas características que se pueden aplicar para clasificar y luego arquitecturas de partición. La Arquitectura Repositorio (ver 41. Arquitectura Repositorio ) muestra cómo las clasificaciones abstractas de la arquitectura se pueden aplicar a una estructura de repositorio para que las arquitecturas pueden ser organizadas y de fácil .

Página 469 de 670

The Open Group Architecture Framework TOGOF 9.1   Herramientas para el desarrollo de la arquitectura (véase 42. Herramientas para el desarrollo de la arquitectura ) proporciona directrices sobre la selección de un conjunto de herramientas para crear y istrar los artefactos arquitectónicos.

Página 470 de 670




39. Continuum Empresarial 39.1 Información general The Enterprise Continuum ofrece métodos para clasificar la arquitectura y los artefactos de la solución, tanto internos como externos en el Repositorio de Arquitectura, a medida que evolucionan a partir de genéricos Arquitecturas Fundación a las arquitecturas Organización Específicos. The Enterprise Continuum permite al arquitecto para articular la perspectiva amplia de qué, por qué, y cómo la arquitectura de la empresa ha sido diseñado con los factores y los conductores considerados. The Enterprise Continuum es una ayuda importante para la comunicación y el entendimiento, tanto dentro de las empresas individuales, y entre las empresas de los clientes y organizaciones de vendedores. Sin una comprensión de "qué lugar del continuum que eres", gente discutiendo la arquitectura a menudo pueden hablar con propósitos cruzados, ya que hacen referencia a diferentes puntos en el continuo, al mismo tiempo, sin darse cuenta. Cualquier arquitectura es un contexto específico; Por ejemplo, hay arquitecturas que son específicos a los clientes individuales, industrias, subsistemas, productos y servicios. Arquitectos, tanto en el lado de la compra y el lado de la oferta, deben tener a su disposición un lenguaje coherente para comunicar eficazmente las diferencias entre las arquitecturas. Tal lenguaje permitirá eficiencia de la ingeniería y el aprovechamiento eficaz de Commercial Off-The-Shelf (COTS) la funcionalidad del producto. The Enterprise Continuum establece que un lenguaje coherente. The Enterprise Continuum permite a la organización de los artefactos de arquitectura reutilizables y activos de soluciones para maximizar las oportunidades de inversión de arquitectura empresarial.

39.2 de Enterprise Continuum y Arquitectura Re-Uso La manera más simple de pensar de la Empresa Continuum es como una vista del repositorio de todos los activos de la arquitectura. Puede contener descripciones de arquitectura, maquetas, bloques de construcción, modelos, puntos de vista, y otros artefactos - que existen tanto dentro de la empresa y en la industria de TI en general, que la empresa considere haya disponible para el desarrollo de arquitecturas para la empresa. Los ejemplos de artefactos de arquitectura y soluciones internas son los entregables del trabajo previo de la arquitectura, que están disponibles para su reutilización.Los ejemplos de la arquitectura y la solución artefactos externos son la gran variedad de modelos de Página 471 de 670


referencia de la industria y los patrones de arquitectura que existen, y están continuamente surgiendo, incluyendo aquellas que son muy genérico (como el modelo de referencia técnica TOGAF (TRM)); las específicas de ciertos aspectos de la tecnología (por ejemplo, una arquitectura de servicios web, o una arquitectura de gestión genéricos); las específicas de ciertos tipos de tratamiento de la información, tales como el comercio electrónico, gestión de la cadena de suministro, etc; y las específicas de ciertas industrias verticales, como los modelos generados por consorcios verticales como TMF (en el sector de las Telecomunicaciones), ARTE (Retail), Energistics (petrotécnicos), etc La arquitectura de la empresa determina que la arquitectura y los artefactos de la solución de una organización incluye en su arquitectura de repositorio. La reutilización es una consideración importante en esta decisión.

39.3 Los constituyentes de la Empresa Continuum Una visión general del contexto y de los constituyentes de la Empresa Continuum se muestra en la Figura 39-1 .

Figura 39‐1: Empresa Continuum

Página 472 de 670


The Enterprise Continuum está dividida en tres continua distinta de la siguiente manera: La empresa Continuum (ver 39.4 Empresa Continuum en detalle ) es el continuum más externa y clasifica los activos relacionados con el contexto de la estructura general de la empresa. Las clases de Enterprise Continuum de activos pueden influir en las arquitecturas, pero no se utilizan directamente durante el desarrollo de la arquitectura . The Enterprise Continuum clasifica los activos contextuales utilizados para desarrollar arquitecturas, como las políticas, normas, iniciativas estratégicas, estructuras organizativas y capacidades de nivel empresarial. The Enterprise Continuum también puede clasificar las soluciones (a diferencia de las descripciones o especificaciones de soluciones). Por último, la empresa Continuum contiene dos especialidades, a saber, la Arquitectura y Soluciones Continua. La Arquitectura Continuum (ver 39.4.1 Arquitectura Continuum ) ofrece una manera consistente para definir y entender las reglas genéricas, las representaciones y las relaciones en una arquitectura, incluyendo las relaciones de trazabilidad y de derivación (por ejemplo, para demostrar que una Arquitectura Organización Específico se basa en una industria o norma genérica). La Arquitectura Continuum representa una estructuración de Arquitectura Bloques de Construcción (Abs) que son activos arquitectura reutilizables. ABBS evolucionan a través de su ciclo de vida de desarrollo de entidades abstractas y genéricas que expresan plenamente activos Organización de una arquitectura específica. Los activos Arquitectura Continuum se utilizarán para orientar y seleccionar los elementos de la serie continua de soluciones (véase más adelante). La Arquitectura Continuum muestra las relaciones entre los marcos fundamentales (como TOGAF), arquitecturas de sistemas comunes (como el III-RM), arquitecturas industriales y arquitecturas empresariales. La Arquitectura Continuum es una herramienta útil para descubrir en común y eliminar la redundancia innecesaria. El Continuum Soluciones (ver 39.4.2 Soluciones Continuum ) proporciona una forma consistente para describir y comprender la aplicación de los activos definidos en la Arquitectura Continuum. El Continuum Soluciones define lo que está disponible en el entorno de la organización como reutilizables Solution Building Blocks (SBB). Las soluciones son el resultado de acuerdos entre los clientes y los socios de negocios que implementan las reglas y relaciones definidas en el espacio de la arquitectura. El Continuum Soluciones aborda los aspectos comunes y las diferencias entre los productos, sistemas y servicios de los sistemas implementados.

The Enterprise Continuum clasifica los activos de arquitectura que son aplicables en todo el ámbito de la arquitectura de la empresa. Estos activos, que pueden ser referidos como bloques de construcción, pueden representar una variedad de elementos que en conjunto definen y limitan la arquitectura empresarial. Ellos pueden tomar la forma de los objetivos de negocio y objetivos, iniciativas estratégicas, capacidades, políticas, normas y principios. The Enterprise Continuum también contiene el Continuum Arquitectura y el Continuum Solutions. Cada uno de estos Continua se describe en mayor detalle en las siguientes secciones.

Página 473 de 670


39.4 Continuum Empresarial en detalle The Enterprise Continuum pretende representar la clasificación de todos los activos que están disponibles para una empresa. Clasifica los activos que existen dentro de la empresa junto con otros activos en el medio ambiente en general que son relevantes para la empresa, como los productos, la investigación, los factores del mercado, factores comerciales, estrategias de negocios, y la legislación. TOGAF pretende ser un marco para la realización de arquitectura de la empresa, y como resultado muchos de los activos que se encuentran dentro de la Empresa Continuum están más allá de la consideración específica del marco TOGAF. Sin embargo, las arquitecturas están conformadas fundamentalmente por las preocupaciones fuera de la práctica de la arquitectura y por lo tanto de suma importancia es que toda la arquitectura debe reflejar con precisión el contexto externo. Los factores contextuales específicas a ser identificados e incorporados en una arquitectura variarán desde la arquitectura a la arquitectura. Sin embargo, los factores contextuales típicos para el desarrollo de la arquitectura es probable que incluyan: Factores que influyen externos, como el cambio de reglamentación, los avances tecnológicos, y la actividad de la competencia Estrategia y el contexto de negocios, incluyendo fusiones, adquisiciones y otros requisitos de transformación empresarial Operaciones de negocios actuales, lo que refleja las arquitecturas y soluciones implementadas

Al observar el contexto de la arquitectura, se puede observar que existe actividad de desarrollo de la arquitectura dentro de un ciclo de vida de la empresa más amplia de cambio continuo. ABBS se definen en relación a un conjunto de factores contextuales y luego se dio cuenta a través de SBB. SBB se despliegan en forma de soluciones en vivo y se convierten en una parte del modelo de operación de línea de base de la empresa. El modelo de explotación de la empresa y la información empírica sobre el desempeño de la empresa conforma el contexto y los requisitos para el cambio futuro. Por último, estos nuevos requisitos para el cambio crean una retroalimentación de lazo para influir en la creación de nuevas arquitecturas de destino. 39.4.1 Arquitectura Continuum

La Arquitectura Continuum ilustra cómo se desarrollan y evolucionan las arquitecturas a través de un continuo que va desde la Fundación arquitecturas, como la proporcionada por TOGAF, a través de los Sistemas Comunes de Arquitecturas y Industria Arquitecturas y las propias arquitecturas específicos de la organización de una empresa. Página 474 de 670


Las flechas en el Continuum Arquitectura representan la relación que existe entre las diferentes arquitecturas de la Arquitectura Continuum. La dirección hacia la izquierda se centra en satisfacer las necesidades de la empresa y los requerimientos del negocio, mientras que la dirección hacia la derecha se centra en el aprovechamiento de los componentes arquitectónicos y bloques de construcción.

Figura 39‐2: Arquitectura Continuum

Las necesidades de la empresa y los requerimientos del negocio se abordan en detalle creciente de izquierda a derecha. El arquitecto tendrá una apariencia típica de encontrar elementos arquitectónicos reutilizables hacia la izquierda del continuo. Cuando no se encuentran elementos, los requisitos para los elementos que faltan se pasan a la izquierda de la continuo para su incorporación. Esas arquitecturas de aplicación dentro de sus propias organizaciones pueden utilizar los mismos modelos continuos especializados para su negocio. Los cuatro tipos de arquitectura particulares ilustradas en la Figura 39-2 están destinados a indicar la gama de diferentes tipos de arquitectura que se puedan desarrollar en diferentes puntos en el continuo; que no son fijos etapas en un proceso. Muchos tipos diferentes de la arquitectura pueden ocurrir en los puntos entre las ilustradas en la Figura 39-2 . Aunque la serie continua transformación evolutiva ilustrado no representa un proceso formal, representa una progresión, que se produce en varios niveles: Lógico para física Horizontal (IT centrada) a vertical (centrado en las empresas) Generalización de la especialización Taxonomía para completar y especificación específica de la arquitectura

En cada punto del continuo, una arquitectura está diseñada en función de los conceptos de diseño y los módulos disponibles y pertinentes a ese punto. Página 475 de 670


Las cuatro arquitecturas ilustrados en la Figura 39-2 representan principales clasificaciones de las arquitecturas posibles, y serán relevantes y familiar para muchos arquitectos. Ellos se analizan en detalle a continuación. Fundación Arquitectura

Una Fundación de Arquitectura consta de componentes genéricos, interrelaciones, principios y directrices que proporcionan una base sobre la que las arquitecturas más específicas se pueden construir. El TOGAF es un proceso que apoye la especialización de dichas arquitecturas de la Fundación con el fin de crear modelos específicos de la organización. El TOGAF TRM describe una arquitectura fundamental sobre el que pueden basarse otras arquitecturas, más específicos. Ver 43. Fundación Arquitectura: Técnico Modelo de Referencia para más detalles. Sistemas Comunes Arquitecturas

Sistemas Comunes Arquitecturas guiar la selección e integración de los servicios específicos de la Architecture Foundation para crear una arquitectura útil para la construcción de soluciones comunes (es decir, altamente reutilizables) en una amplia serie de ámbitos pertinentes. Ejemplos de sistemas comunes Arquitecturas incluyen: un título de arquitectura, una arquitectura de gestión, una arquitectura de red, una arquitectura operaciones, etc Cada uno es incompleto en términos de funcionalidad general del sistema, pero es completa en términos de un dominio determinado problema (seguridad, capacidad de gestión, la creación de redes, operaciones, etc), por lo que las soluciones que implementan la arquitectura constituyen bloques de construcción reutilizables para la creación de estados de funcionamiento funcionalmente completos de la empresa. Otras características de los sistemas comunes Arquitecturas incluyen: Refleja los requisitos específicos de un dominio del problema genérico Define componentes básicos específicos de un dominio del problema genérico Define los estándares de negocios, datos, aplicaciones, o de tecnología para la implementación de estos bloques de construcción Proporciona elementos básicos para los gastos fáciles reutilización y bajos

El TOGAF Integrado de Información de Referencia Infraestructura Modelo (III-RM) véase la parte VI , 44. Integrado de Información Infraestructura Modelo de referencia- es un modelo de referencia que apoya la descripción de los sistemas de Common Architecture en el dominio Página 476 de 670


de aplicación que se centra en los requisitos, bloques de construcción, y las normas relativas a la visión del flujo de información sin fronteras. Arquitecturas de la Industria

Arquitecturas Industria guían la integración de los componentes de los sistemas comunes con componentes específicos de la industria, y orientar la creación de soluciones de la industria para los problemas de los clientes específicos dentro de una industria en particular. Un ejemplo típico de un componente específico de la industria es un modelo de datos que representa las funciones y los procesos de negocio específicos de un sector vertical en particular, como la arquitectura de la industria al por menor "Activo tienda", o un Sector Arquitectura que incorpora el modelo de datos Energistics (consulte www.energistics.org ). Otras características de la Industria Arquitecturas incluyen: Refleja los requisitos y las normas específicas de un sector vertical Define componentes básicos específicos de un dominio del problema genérico Contiene datos lógicos específicos de la industria y modelos de procesos Contiene aplicaciones específicas de la industria y modelos de procesos, así como las reglas de negocio específicos de la industria Proporciona directrices para las pruebas de las colecciones de los sistemas Alienta a los niveles de interoperabilidad en toda la industria Arquitecturas-organización específica

Arquitecturas específicos de la organización describen y guían la implementación final de componentes de la solución para una empresa en particular o red de empresas conectadas extendido. Puede haber una variedad de arquitecturas de Organización-específicas que se necesitan para cubrir eficazmente las necesidades de la organización mediante la definición de las arquitecturas de los crecientes niveles de detalle. Alternativamente, esto podría dar lugar a varias arquitecturas más detallados-organización específica para entidades específicas dentro de la empresa global. Desglosando Arquitecturas-organización específica en piezas constituyentes se aborda en el 40. Arquitectura de particionamiento . La Arquitectura Organización-específico guía la personalización final de la solución, y tiene las siguientes características:

Página 477 de 670

The Open Group Architecture Framework TOGOF 9.1   Proporciona un medio para comunicar y gestionar las operaciones de negocio a través de las cuatro áreas de arquitectura Refleja los requisitos específicos para una empresa en particular Define bloques de construcción específicos para una empresa en particular Contiene modelos de negocio específicos de la organización, datos, aplicaciones y tecnologías Proporciona un medio para fomentar la implementación de soluciones adecuadas para satisfacer las necesidades empresariales Proporciona los criterios para medir y seleccionar los productos adecuados, soluciones, y servicios Proporciona un camino evolutivo para apoyar el crecimiento y las nuevas necesidades de la empresa

39.4.2 Soluciones Continuum

El Continuum Soluciones representa la especificación detallada y la construcción de las arquitecturas en los niveles correspondientes de la Arquitectura Continuum. En cada nivel, el Continuum Solutions es una población de la arquitectura con bloques de construcción de referencia - bien los productos comprados o componentes integrados - que representan una solución a las necesidades de negocio de la empresa expresaron en ese nivel. Un repositorio poblada basado en el Continuo Soluciones puede considerarse como un inventario de soluciones o re-uso de la biblioteca, que se puede añadir un valor significativo a la tarea de gestionar e implementar mejoras a la empresa. El Continuum Soluciones se ilustra en la Figura 39-3 .

   Figura 39‐3: Soluciones de Continuidad

"Mover a la derecha" en el Continuo Soluciones se centra en proporcionar soluciones de valor (es decir, las soluciones de cimentación proporcionan valor en la creación de soluciones de sistemas comunes; soluciones de sistemas comunes se utilizan para crear soluciones de la industria, y las soluciones industriales que se utilizan para crear soluciones Página 478 de 670


específicas de la organización ). "Mover a la izquierda" en el Continuo Soluciones se centra en hacer frente a las necesidades empresariales. Estos dos puntos de vista son importantes para una empresa tratando de centrarse en sus necesidades y aumentar al máximo el uso de los recursos disponibles a través del apalancamiento. Los apartados siguientes describen cada uno de los tipos de soluciones dentro del Continuum Solutions. Soluciones Fundación

Soluciones Fundación son conceptos muy genéricos, herramientas, productos, servicios y componentes de la solución, que son los proveedores fundamentales de capacidades. Los servicios incluyen servicios profesionales - tales como la capacitación y servicios de consultoría - que garantizan el valor máximo de inversión de las soluciones en el menor tiempo posible; y servicios de apoyo - como el Help Desk - que garantizan el máximo valor posible de las soluciones (servicios que aseguran las actualizaciones oportunas y mejoras de los productos y sistemas). Soluciones Ejemplo Fundación incluirían los lenguajes de programación, sistemas operativos, estructuras de datos fundamentales (como EDIFACT), enfoques genéricos organización estructuración, estructuras fundamentales para la organización de las operaciones de TI (como ITIL), etc Sistemas Comunes Soluciones

Una solución común de sistemas es una implementación de un sistema de arquitectura común compuesto por un conjunto de productos y servicios, que pueden ser certificados o con la marca. Representa el máximo común denominador para una o más soluciones en los segmentos de la industria que la solución de los Sistemas Comunes apoya. Sistemas Comunes Soluciones representan colecciones de requisitos y capacidades comunes, en lugar de los específicos de un cliente o industria en particular.Sistemas Comunes soluciones proporcionan a las organizaciones con entornos operativos específicos para las necesidades operativas y de información, como la alta disponibilidad de los sistemas de almacenamiento de datos escalable de procesamiento de transacciones y. Ejemplos de sistemas comunes de soluciones incluyen: un producto de sistema de gestión de la empresa o un producto de sistema de seguridad. Proveedores de sistemas informáticos son los proveedores típicos de centradas en la tecnología de sistemas comunes Solutions. "Software como servicio" proveedores son proveedores habituales de las soluciones de aplicaciones comunes. Proveedores de Página 479 de 670


outsourcing de procesos de negocios son típicas del negocio proporciona capacidad centrada en sistemas comunes Solutions. Soluciones para la Industria

Una solución de la Industria es una implementación de una Arquitectura de la Industria, que ofrece paquetes reutilizables de componentes y servicios comunes específicos para una industria. Componentes fundamentales son proporcionados por sistemas comunes Soluciones y / o Fundación Solutions, y se complementan con los componentes específicos de la industria. Los ejemplos incluyen: un esquema de base de datos física o un dispositivo de punto de servicio específico de la industria. Soluciones para la industria son específicas de la industria, las compras agregadas que están listos para ser adaptado a las necesidades de una organización individual. En algunos casos, una solución de la industria puede incluir no sólo una implementación de la arquitectura de la Industria, pero también otros elementos de la solución, como los productos específicos, servicios y soluciones de sistemas que sean apropiadas a esa industria. Solutions-organización específica

Una solución-organización específica es una implementación de la arquitectura de la Organización específica que proporciona las funciones de la empresa necesarios.Dado que las soluciones están diseñadas para operaciones específicas de negocio, que contienen la mayor cantidad de contenido único con el fin de dar cabida a las personas y los procesos de las organizaciones específicas que varían. Soluciones Building Organización específicas sobre Soluciones para la industria, sistemas comunes Soluciones y Fundación Solutions es el principal propósito de conectar el Continuum Arquitectura al Continuum Solutions, como guiado por los arquitectos dentro de una empresa. Una solución-organización específica se estructura con el fin de apoyar los acuerdos específicos Nivel de Servicio (SLA) para asegurar el apoyo de los sistemas operativos en los niveles de servicio deseados. Por ejemplo, una aplicación de terceros proveedor de alojamiento puede ofrecer diferentes niveles de apoyo a los sistemas operativos. Estos acuerdos definen los términos y condiciones de ese apoyo. Otros factores clave que deben ser definidos dentro de una solución de Organización Específicos son los parámetros operativos clave y métricas de calidad que pueden utilizarse para controlar y gestionar el medio ambiente. Página 480 de 670


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

39.5 La Empresa Continuum y el El TOGAF describe el proceso de desarrollo de una arquitectura específica de la empresa y una solución (s) específica de la empresa que se ajustan a la arquitectura mediante la adopción y la adaptación (en su caso) arquitecturas y soluciones (de izquierda a derecha en la clasificación continua) genéricos. De manera similar, las arquitecturas y soluciones específicas que han demostrado ser efectivos y creíbles serán generalizados para su reutilización (de derecha a izquierda en la clasificación continua). En los lugares pertinentes en todo el TOGAF , hay punteros a los activos de arquitectura útiles al nivel pertinente de generalidad en la clasificación continuum. En algunos casos - por ejemplo, en el desarrollo de una arquitectura Tecnología - esto puede ser la Fundación Arquitectura TOGAF TRM (ver más abajo). En otros casos - por ejemplo, en el desarrollo de una arquitectura de negocios - que puede ser un modelo de referencia para el comercio electrónico tomada de la industria en general. Sí TOGAF ofrece dos modelos de referencia para la consideración para su uso en el desarrollo de la arquitectura de una organización: 1. La Fundación Arquitectura TOGAF , que comprende una TRM de los servicios y funciones genéricas que proporciona una base firme sobre la cual las arquitecturas más específicos y componentes arquitectónicos se pueden construir.

2. La Integrado de Información de Referencia Infraestructura Modelo (III-RM), que se basa en la Fundación Arquitectura TOGAF, y está específicamente diseñado para ayudar a la realización de arquitecturas que permiten y apoyan la visión de Flujo de información sin fronteras.

Sin embargo, en el desarrollo de las arquitecturas de los distintos dominios dentro de una arquitectura global de la empresa, el arquitecto tendrá que considerar el uso y re-uso de una amplia variedad de diferentes activos de la arquitectura, y la Empresa Continuum ofrece un enfoque para clasificar y comunicar estos diferentes activos .

39.6 La Empresa Continuum y su organización Las secciones anteriores han descrito la empresa Continuum, la Arquitectura Continuum, y el Continuum Solutions. Las siguientes secciones describen las relaciones entre cada uno de los tres continuos y cómo deben aplicarse estas relaciones dentro de su organización. Página 481 de 670

The Open Group Architecture Framework TOGOF 9.1   39.6.1 Relaciones

Cada uno de los tres continuos contiene información acerca de la evolución de las arquitecturas durante su ciclo de vida: The Enterprise Continuum ofrece un contexto general de las arquitecturas y soluciones y clasifica los activos que se aplican en todo el ámbito de la empresa. La Arquitectura Continuum proporciona un mecanismo de clasificación de los activos que definen colectivamente la arquitectura en diferentes niveles de evolución de genérico a lo específico. El Continuum Soluciones ofrece la clasificación de los activos para describir las soluciones específicas para la organización que pueden ser implementadas para lograr el propósito de la arquitectura.

Las relaciones entre el Continuum Arquitectura y Soluciones Continuum se muestran en la Figura 39-4 .

Figura 39‐4: Las relaciones entre la arquitectura y Soluciones Continua

La relación entre la arquitectura y el Continuum Continuum Solutions es una de orientación, dirección y apoyo. Por ejemplo, la Fundación Arquitecturas guían la creación o selección de la Fundación Solutions. Soluciones Fundación de Apoyo a la Architecture Foundation, ayudando a comprender la arquitectura definida en la Arquitectura Continuum. La Architecture Foundation también guía el desarrollo de la Fundación Solutions, proporcionando arquitectónicos de dirección, los requisitos y los principios que guían la selección y realización de soluciones apropiadas. Una relación similar existe entre los otros elementos de la empresa Continuum. Página 482 de 670


The Enterprise Continuum presenta mecanismos para ayudar a mejorar la productividad a través del apalancamiento. La Arquitectura Continuum ofrece una manera consistente para entender las diferentes arquitecturas y sus componentes. El Continuum Soluciones ofrece una manera consistente para entender los diferentes productos, sistemas, servicios y soluciones que se requieren. The Enterprise Continuum no se debe interpretar como la representación de las relaciones estrictamente encadenados. Arquitecturas específicos de la organización pueden tener componentes de una arquitectura común de sistemas y soluciones de Organizaciónespecíficas podrían contener soluciones Fundación. Las relaciones que se muestran en la figura 39-1 son una ilustración que muestra las oportunidades para el aprovechamiento de los componentes de la arquitectura y de la solución. 39.6.2 Su Empresa

TOGAF proporciona un método para que usted pueda "arquitecto" de los sistemas de su empresa. Su organización arquitectura tendrá que hacer frente a cada tipo de arquitectura se ha descrito anteriormente. Por ejemplo, se recomienda que usted tiene su propio Architecture Foundation que rige todos sus sistemas. Usted también debe tener sus propias arquitecturas de sistemas comunes que rigen los principales sistemas compartidos - como el sistema de red o sistema de gestión. Usted puede tener sus propias arquitecturas específicas de la industria que rigen la forma en que sus sistemas deben comportarse dentro de su industria. Por último, cualquier departamento u organización dentro de su negocio puede necesitar su propia Arquitectura-Organización Específica individuo para gobernar los sistemas dentro de ese departamento. Su organización arquitectura o bien adoptar o adaptar las arquitecturas existentes, o desarrollará sus propias arquitecturas desde cero. En cualquier caso, TOGAF es una herramienta para ayudar. Proporciona un método para ayudarle a generar / mantener cualquier tipo de arquitectura dentro de la Arquitectura Continuum tiempo de aprovechar los activos de arquitectura ya definidos, interno o externo a la organización. El TOGAF que a los activos de arquitectura reutilizar ayuda, por lo que su organización arquitectura más eficiente y eficaz.

Página 483 de 670


40. Arquitectura de particionamiento 40.1 Información general Las particiones se utilizan para simplificar el desarrollo y la gestión de la arquitectura empresarial. Las particiones se encuentran en la base de la arquitectura de la gobernanza y son distintos de los niveles y los conceptos organizadores del Continuum Arquitectura (ver 39. Empresa Continuum ). Arquitecturas están divididas debido a que: Arquitecturas de unidad organizativa en conflicto entre sí. Los diferentes equipos tienen que trabajar en los diferentes elementos de la arquitectura al mismo tiempo y particiones permiten a grupos específicos de los arquitectos poseen y desarrollan los elementos específicos de la arquitectura. Arquitectura reutilización efectiva requiere segmentos modulares de arquitectura que pueden adoptarse e incorporarse en las arquitecturas y soluciones más amplias.

No es práctico para presentar un modelo de partición definitiva de la arquitectura. Cada empresa tiene que adoptar un modelo de partición que refleja su propio modelo de funcionamiento. Este capítulo trata de los criterios de clasificación que se aplican en general a las arquitecturas y cómo estos se pueden aprovechar para dividir la empresa en un conjunto de arquitecturas con complejidad manejable y una gobernanza eficaz.

40.2 Clasificación Aplicar para crear arquitecturas con particiones Por las razones expuestas en la sección anterior, es valioso para dividir y organizar la empresa Continuum en un conjunto de soluciones y arquitecturas relacionadas con: Complejidad manejable para cada arquitectura o solución individual Agrupaciones definidas Jerarquías definidas y estructuras de navegación Procesos adecuados, roles y responsabilidades adjuntas a cada agrupación

Página 484 de 670


La siguiente tabla muestra cómo los criterios de clasificación adecuados pueden ser utilizados para apoyar el particionamiento de soluciones:

Característica Uso de Apoyo a la Solución de particionamiento Asunto (Manga) Las soluciones se organizan naturalmente en grupos para apoyar la gestión operativa y control. Ejemplos de particiones de soluciones de acuerdo a la materia incluirían aplicaciones, departamentos, divisiones, productos, servicios, centros de servicio, sitios, etc

Tiempo

Vencimiento / Volatilidad

Descomposición de soluciones por tema suele ser la técnica fundamental para la estructuración de las dos soluciones y las arquitecturas que las representan. Los ciclos de vida de la solución se suelen organizar en torno a una línea de tiempo, lo que permite que el impacto del desarrollo de la solución, implantación, operación y retiro para ser manejado contra otra actividad económica que ocurre en períodos de tiempo similares. La madurez y la volatilidad de una solución típicamente afectar la velocidad de ejecución necesaria para el ciclo de vida de la solución. Además, la volatilidad y la madurez darán forma a las prioridades de inversión. Soluciones existentes en entornos altamente volátiles pueden ser más adecuados para, técnicas de desarrollo ágil rápidos.

La siguiente tabla muestra cómo cada criterio de clasificación se pueden utilizar para apoyar el particionamiento de arquitecturas:

Característica Uso de fomentar una arquitectura de particionamiento Profundidad El nivel de detalle dentro de una arquitectura tiene una fuerte correlación con los grupos de interés que estén interesados en la arquitectura. Arquitecturas Típicamente menos detallados serán de interés para las partes interesadas ejecutivos. Como arquitecturas aumentan en detalle, su relevancia para la implementación y el personal de operaciones también se incrementará. Página 485 de 670


En términos prácticos, la arquitectura disciplina se utiliza para soportar un número de diferentes tipos de arquitectura que se utilizan para diferentes objetivos. Los criterios de clasificación antes mencionados, pueden ser utilizados en diferentes formas de apoyar el logro de cada objetivo. Las siguientes características no se utilizan para dividir una Arquitectura del Paisaje: Arquitecturas utilizadas para describir la arquitectura del paisaje en general, no son abstractos. Volatilidad Solución general evita las arquitecturas de ser definido, que están lejos en el futuro. La volatilidad también reduce la precisión de los edificios históricos en el tiempo, ya que los cambios en la organización y se adapta a las nuevas circunstancias.

El uso de los criterios anteriores, las arquitecturas se pueden agrupar en las particiones. 40.2.1 Las actividades dentro de la Etapa Preliminar

El objetivo clave de la Etapa Preliminar es establecer la capacidad Arquitectura para la empresa. En la práctica esta actividad requerirá el establecimiento de un número de particiones de arquitectura, proporcionando límites definidos, gobierno y propiedad. En términos generales, cada equipo que lleva a cabo la actividad de la arquitectura dentro de la empresa será propietaria de una o más particiones de arquitectura y ejecutará el de definir, gobernar, y hacer realidad sus arquitecturas. Si se espera que más de un equipo para trabajar en una sola arquitectura, esto puede llegar a ser problemático, ya que las responsabilidades precisas de cada equipo son difíciles de establecer. Por esta razón, es preferible aplicar la partición a la arquitectura hasta cada arquitectura tiene un equipo propietaria. Por último, vale la pena considerar la distinción entre las capacidades permanentes de la empresa y los equipos temporales movilizados para apoyar una iniciativa de cambio en particular. Aunque las competencias de los equipos permanentes dentro de la empresa se puede definir con precisión, es más difícil de prever y especificar las responsabilidades de (posiblemente desconocidos) equipos de arquitectura de carácter temporal. En los casos de estos equipos temporales, cada equipo debe venir bajo el gobierno de un equipo de arquitectura en pie y debe haber un proceso dentro del ciclo de de estos equipos para establecer partición arquitectura apropiada. Pasos en la Etapa Preliminar para apoyar la arquitectura de partición son los siguientes: Determinar la estructura de la organización para la arquitectura dentro de la empresa : Los diversos equipos permanentes que va a crear la arquitectura deben ser identificados. Para cada uno de estos equipos, los límites apropiados deben ser establecidos, incluyendo:

Página 486 de 670

The Open Group Architecture Framework TOGOF 9.1   o Los órganos de gobierno que son aplicables al equipo o de del equipo o Equipo de las líneas de responsabilidad Determinar las responsabilidades de cada equipo de arquitectura de pie : Para cada equipo de arquitectura, las responsabilidades deben ser identificados.Este paso se aplica la lógica de repartición en la arquitectura de la empresa con el fin de identificar en primer lugar, el alcance de cada equipo y en segundo lugar a la partición de la arquitectura bajo el mandato de un solo equipo. Una vez completado, este paso debería haber particionado todo el ámbito de la empresa y debería haber asignado la responsabilidad para cada arquitectura particionada a un solo equipo. El particionamiento debe crear una definición de cada arquitectura que incluya: o áreas temáticas están cubiertos o Nivel de detalle que el equipo trabajará en o Los períodos de tiempo que deben cubrirse o Grupos de Interés Determinar las relaciones entre arquitecturas : Una vez que se ha creado un conjunto de arquitecturas con particiones, las relaciones entre las arquitecturas deben desarrollarse. Este paso permite que las relaciones de gobernanza para formalizarse y también muestra donde los artefactos de una arquitectura se espera que sean reutilizados en otras arquitecturas. Áreas de consideración incluyen: o ¿Dónde se superponen diferentes arquitecturas / cola de milano / drill-down? o ¿Cuáles son los requisitos de cumplimiento entre las arquitecturas?

Una vez que la fase preliminar se completa, los equipos a cargo de la arquitectura debe entenderse. Cada equipo debe tener un alcance definido y las relaciones entre los equipos y la arquitectura debe ser entendido. Asignación de equipos a alcance arquitectura se muestra en la Figura 40-1 .

Página 487 de 670


Figura 40‐1: Asignación de equipos a Arquitectura Alcance

40.3 Integración La creación de arquitecturas con particiones corre el riesgo de producir una colección fragmentada y desarticulada de las arquitecturas que no pueden integrarse para formar un panorama general (ver Parte II , 5.6 Arquitectura de Integración ). Para las grandes empresas complejas arquitecturas federados - desarrollados de forma independiente, mantenidos y istrados arquitecturas que se integran posteriormente dentro de un marco de integración - son típicos. Arquitecturas federados normalmente se utilizan en los gobiernos y los conglomerados, donde las unidades organizativas separadas necesitan arquitecturas diferentes. Dicho marco especifica los principios de interoperabilidad, la migración, y la conformidad. Esto permite que las unidades de negocio específicas que tienen arquitecturas desarrolladas y reguladas como proyectos de arquitectura independientes. Información adicional y orientación sobre cómo especificar los requisitos de interoperabilidad para las diferentes soluciones se pueden encontrar en la Parte III , 29. Requisitos de interoperabilidad . Con el fin de mitigar este riesgo, las normas para la integración de contenidos deben ser definidos y la gobernanza arquitectura deben abordar la integración de contenidos como condición para el cumplimiento de la arquitectura. Marcos de contenido, tales como el marco TOGAF contenido (consulte la Parte IV: Marco de Arquitectura de contenido ) se puede utilizar para especificar bloques de construcción estándar y artefactos que son objeto de las normas de integración de contenidos. Por ejemplo, un catálogo estándar de los procesos de negocio puede ser acordado por una empresa. Arquitecturas posteriores a continuación pueden facilitar la integración mediante Página 488 de 670


el uso de la misma lista de procesos y referencias cruzadas a otros aspectos de la arquitectura de los procesos estándar. La integración puede ser dirigido desde un número de dimensiones: Integración a través de los dominios de arquitectura proporciona una vista en corte de dominio del estado de un segmento de la empresa para un punto en el tiempo. Integración a través del ámbito organizativo de la empresa proporciona una vista en corte del segmento de la empresa. El Architecture Vision proporciona un resumen integral de la arquitectura Definiciones, que proporcionan un resumen integrado de Transición Arquitecturas. La Figura 40-2 muestra cómo el contenido arquitectónico se puede agregar utilizando una variedad de técnicas.

Figura 40‐2: Arquitectura de Agregación de Contenidos

Página 489 de 670


41. Arquitectura Repositorio 41.1 Información general El funcionamiento de una Arquitectura Capability madura dentro de una gran empresa crea un enorme volumen de la producción arquitectónica. La gestión eficaz y el apalancamiento de estos productos de trabajo de arquitectura requieren una taxonomía formal para los diferentes tipos de activos de arquitectura junto a los procesos y herramientas dedicadas para el almacenamiento de contenido arquitectónico. Esta sección de TOGAF proporciona un marco estructural para un repositorio de Arquitectura que permite a una empresa para distinguir entre diferentes tipos de activos arquitectónicas que existen en diferentes niveles de abstracción en la organización. Este repositorio de arquitectura es una parte de la más amplia Enterprise Repository, que proporciona la capacidad de vincular elementos arquitectónicos a los componentes del diseño detallado, distribución y servicio de istración de repositorios. A un alto nivel, se espera que seis clases de información arquitectónica que se celebrará dentro de un repositorio de Arquitectura: La Arquitectura Metamodel describe la aplicación organizativo adaptado de un marco de arquitectura, incluyendo un método para el desarrollo de la arquitectura y un metamodelo para el contenido de la arquitectura. La Capacidad de Arquitectura define los parámetros, estructuras y procesos que ayuden a la gobernabilidad de la arquitectura de repositorio. La arquitectura del paisaje presenta una representación arquitectónica de los activos en uso, o previsto, por la empresa en determinados puntos en el tiempo. La Base de información de Normas captura las normas que deben cumplir las nuevas arquitecturas, que pueden incluir normas de la industria, los productos y servicios seleccionados de proveedores o servicios compartidos ya desplegados dentro de la organización. La Biblioteca de Referencia proporciona directrices, plantillas, patrones y otras formas de material de referencia que se puede aprovechar el fin de acelerar la creación de nuevas arquitecturas para la empresa. El Gobierno Log proporciona un registro de la actividad de gobierno en toda la empresa.

Las relaciones entre estas áreas del Repositorio de Arquitectura se muestran en la Figura 411.

Página 490 de 670


Figura 41‐1: Visión general de la arquitectura de repositorio

Esta sección de TOGAF describe la estructura y el contenido de las áreas de depósito que tienen la salida de los proyectos, es decir, la arquitectura del paisaje, la Biblioteca, la Base de información de normas y el registro de la gobernanza. Esta sección, además, los requisitos que deben considerarse al seleccionar las herramientas para la gestión de un repositorio de Arquitectura.

41.2 Arquitectura del Paisaje La Arquitectura del Paisaje tiene vistas arquitectónicas del estado de la empresa en determinados puntos en el tiempo. Debido a la gran cantidad y las diversas necesidades de los interesados a lo largo de toda la empresa, la arquitectura del paisaje se divide en tres niveles de granularidad: 1. Arquitecturas Estratégicas (ver Parte I , 3,70 Arquitectura Estratégica ) muestran una vista de resumen a largo plazo de toda la empresa. Arquitecturas estratégicos proporcionan un

Página 491 de 670

The Open Group Architecture Framework TOGOF 9.1   marco de organización de la actividad operativa y el cambio y permiten una configuración de dirección a nivel ejecutivo.

2. Arquitecturas del segmento (véase la Parte I , Arquitectura 3.62 Segmento ) proporcionar modelos operativos más detallados para las áreas dentro de una empresa.Arquitecturas del segmento se pueden utilizar a nivel de programa o de una cartera de organizar y operativamente alinear actividad de cambio más detallada.

3. Arquitecturas de capacidad (véase la Parte I , Arquitectura 3,27 Capability ) muestran de una forma más detallada cómo la empresa puede soportar una unidad particular de la capacidad. Arquitecturas de capacidad se utilizan para proporcionar una visión general de la capacidad de corriente, capacidad de objetivo, y los incrementos de capacidad y permitir paquete de obras y proyectos a ser agrupados dentro de las carteras y los programas gestionados.

41.3 Referencia de la Biblioteca 41.3.1 Información general

La Biblioteca proporciona un depósito para contener los materiales de referencia que se deben utilizar para desarrollar arquitecturas. Materiales de referencia de que se pueden obtener a partir de una variedad de fuentes, incluyendo: Los organismos de normalización De productos y servicios proveedores Comunidades o foros de la industria Las plantillas estándar Mejores prácticas empresariales

La Biblioteca debe contener: Arquitecturas de Referencia Modelos de Referencia Biblioteca Mirador Plantillas Nota: Los términos arquitectura de referencia y modelo de referencia no se utilizan con cuidado en la mayoría de la literatura. Arquitectura de referencia y modelo de referencia tienen la misma relación que la arquitectura y el modelo. Cualquiera puede existir como un estado genérico o específico de la organización. Típicamente,un genérico arquitectura de referencia proporciona el equipo de arquitectura con un esbozo de su arquitectura de referencia específica de la organización que se personaliza para una organización específica. Por ejemplo, un genérico arquitectura de referencia puede identificar que existe

Página 492 de 670

The Open Group Architecture Framework TOGOF 9.1   una necesidad de modelos de datos.Una organización que selecciona el SID del TMF como un modelo de datos de referencia es la creación de una arquitectura de referencia específicos de cada organización.

Con el fin de separar las diferentes clases de materiales de referencia de arquitectura, la Biblioteca puede utilizar el Continuum La arquitectura como un método para la clasificación.

Figura 41‐2: Arquitectura Continuum

La Arquitectura Continuum, como se muestra en la Figura 41-2 , se puede ver como un esquema de clasificación Reference Library. Como tal, ilustra cómo las arquitecturas de referencia se pueden organizar a través de una gama - desde la Fundación Arquitecturas y Arquitecturas específicos de la industria, para una Arquitectura Organización Específico. Las necesidades de la empresa y los requerimientos del negocio se abordan en la disminución de la abstracción de izquierda a derecha. El arquitecto tendrá típicamente encontrar más elementos arquitectónicos reutilizables hacia la izquierda de la gama. Cuando no se encuentran elementos, los requisitos para los elementos que faltan se pasan a la izquierda de la gama para su incorporación. A través de este ejercicio, es importante tener en cuenta los conceptos de niveles y particiones. En diferentes niveles de granularidad puede existir materiales de referencia apropiados para el nivel, y las particiones dentro de la arquitectura del paisaje se puede esperar para utilizar el material de referencia diferente (ver 40. Arquitectura de particionamiento y la Parte III , 20. Aplicando la a través de la Arquitectura del Paisaje ).

41.4 Normas de Información de Base 41.4.1 Información general

La Base de información de Normas proporciona un área de depósito para contener un conjunto de especificaciones, a la que deben ajustarse las arquitecturas.Establecimiento de Página 493 de 670


una base de información de Normas proporciona una base inequívoca para la gobernanza de la arquitectura debido a que: Las normas son de fácil a los proyectos y, por tanto, las obligaciones del proyecto pueden ser comprendidas y previstas para Las normas se establecen en forma clara e inequívoca, de modo que el cumplimiento se puede evaluar objetivamente

41.4.2 Tipos de Norma

Normas normalmente se dividen en tres clases: Obligaciones legales y reglamentarias : Estas normas son obligatorias por ley y, por tanto, una empresa debe cumplir o enfrentar graves consecuencias. Estándares de la industria : Estas normas son establecidas por organismos de la industria, tales como The Open Group, y luego son seleccionados por la empresa para su aprobación. Estándares de la industria ofrecen un potencial para la interoperación y compartir a través de las empresas, sino que también quedan fuera del control de la empresa y, por tanto, se debe supervisar de manera activa. Normas de organización : Estas normas se establecen dentro de la organización y se basan en la aspiración de la empresa (por ejemplo, la selección de las aplicaciones estándar de apoyo a la cartera de consolidación). Normas de organización requieren procesos para permitir exenciones y normas evolución.

Normas 41.4.3 Ciclo de Vida

Normas generalmente no existen para todos los tiempos. . Las nuevas normas se identifican y gestionan a través de un proceso de ciclo de vida general, las normas pasan a través de las siguientes etapas: Norma : Norma potencial ha sido identificado por la organización, pero que aún no ha sido evaluada para su aprobación. Norma Provisional (también conocido como un estándar de prueba ): Un estándar provisional ha sido identificado como un posible estándar para la organización, pero no se ha probado a un nivel en el que su valor se entiende completamente. Los proyectos que deseen adoptar las Normas provisionales podrán hacerlo, pero bajo condiciones experimentales específicas, por lo que la viabilidad de la norma puede ser examinado con más detalle. Estándar (también conocido como un estándar activo ): Una Norma define una solución de la corriente principal que se debe utilizar generalmente como el enfoque de elección. Supresión gradual estándar (también conocido como un estándar de Deprecated ): Un estándar Phasing-Out se acerca al fin de su ciclo de vida útil. Los proyectos que se reutilizando componentes existentes en general, puede seguir haciendo uso de la supresión gradual de las Normas. Despliegue de nuevas instancias de la Norma Phasing-Out son generalmente desalentada.

Página 494 de 670

The Open Group Architecture Framework TOGOF 9.1   Estándar Retirado (también conocido como un estándar obsoleto ): Un estándar Retirado ya no es aceptada como válida en el paisaje. En la mayoría de los casos, se deben tomar medidas correctivas para eliminar la Norma Retirado del paisaje. Cambio de la actividad en un estándar Jubilado sólo debe ser aceptado como parte de un plan general de desmantelamiento.

Todas las normas deben ser revisadas periódicamente para asegurar que se sientan en el lado derecho del escenario del ciclo de vida de normas. Como parte de la gestión del ciclo de vida de las normas, el impacto de cambiar el estado del ciclo de vida debe ser dirigida a comprender el impacto paisajístico de un cambio de las normas y el plan de acción adecuado para abordarlo. 41.4.4 Normas de Clasificación dentro de la Base de Información de Normas

Normas dentro de la Base de información de normas se clasifican de acuerdo a los bloques de construcción dentro del contenido metamodelo TOGAF. Cada entidad metamodelo puede potencialmente tener estándares asociados (por ejemplo, servicios de negocios, Componente Tecnología). Las normas pueden relacionarse con bloques de construcción (por ejemplo, una lista de componentes de tecnología estándar) "aprobado" o puede especificar el uso adecuado de un bloque de construcción (por ejemplo, los escenarios donde la infraestructura de mensajería es el caso, las normas de comunicación de aplicación se definen). En el nivel superior, las normas se clasifican de acuerdo con los ámbitos de arquitectura TOGAF, incluyendo las siguientes áreas: Normas Comerciales : o Norma compartió las funciones de negocio o definiciones de roles y actores estándar o normas de gobierno para la actividad empresarial y de Seguridad Estándares de Datos : o la codificación y valores de datos estándar o estructuras y formatos de datos estándar o Normas de origen y la propiedad de los datos o restricciones a la reproducción y el Aplicaciones Estándares : o aplicaciones estándar / compartidos que apoyan las funciones de negocio específicas

Página 495 de 670

The Open Group Architecture Framework TOGOF 9.1   o Normas para la comunicación de solicitud y la interoperación o Normas de , presentación y estilo Estándares de Tecnología ; o Los productos de hardware estándar o Los productos de software estándar o Normas para el desarrollo de software

41.5 Gobierno Entrar 41.5.1 Información general

El Gobierno de registro proporciona un área repositorio para almacenar la información compartida en relación con la gobernanza en curso de los proyectos. El mantenimiento de un repositorio compartido de información de gobierno es importante, debido a que: Las decisiones tomadas durante los proyectos (por ejemplo, desviaciones estándares o la justificación de un enfoque arquitectónico particular) son importantes para retener y acceder en forma permanente. Por ejemplo, si un sistema se va a sustituir, que tiene la vista de las decisiones arquitectónicas clave que dieron forma a la implementación inicial es muy valiosa, ya que pondrá de relieve las limitaciones que de otra manera puedan estar tapados. Muchos actores están interesados en los resultados de gestión del proyecto (por ejemplo, otros proyectos, los clientes del proyecto, el Consejo de Arquitectura, etc.)

41.5.2 Contenido de la sesión de Gobierno

El Registro de la gobernanza debe contener los siguientes elementos: Decisión Log :. Un registro de todas las decisiones de gran importancia arquitectónica que se han hecho en la organización Esto suele incluir: o selecciones de producto o Justificación de las principales características arquitectónicas de proyectos o desviaciones de Normas o Normas cambios de ciclo de vida o Solicitud de cambio de las evaluaciones y aprobaciones o evaluaciones de Re-uso Evaluaciones de cumplimiento : En el puesto de control hitos clave en el progreso de un proyecto, una revisión formal de la arquitectura se llevarán a cabo. . Esta revisión se mida

Página 496 de 670

The Open Group Architecture Framework TOGOF 9.1   la conformidad del proyecto con los estándares de arquitectura definidos para cada proyecto, este registro debe incluir: o Visión general del proyecto o visión Progreso (línea de tiempo, estado, problemas, riesgos, dependencias, etc) o listas de control completadas arquitectura o Los estándares de evaluación del cumplimiento o Acciones recomendadas Evaluaciones de capacidad : En función de sus objetivos, algunos proyectos se llevará a cabo evaluaciones de los negocios, o Arquitectura de capacidad. . Estas evaluaciones deben llevarse a cabo periódicamente y realiza un seguimiento para asegurar que se está logrando progreso adecuado Este registro debe incluir: o Los modelos de referencia para la ejecución de evaluaciones de capacidad Plantillas y o evaluaciones de la capacidad de Empresas o evaluaciones de la capacidad de TI, de madurez y de impacto o evaluaciones de madurez Arquitectura Calendario : El calendario debería mostrar un calendario de proyectos en vuelo y las sesiones formales de revisión, que se celebrará en contra de estos proyectos. Cartera de Proyectos : La cartera de proyectos debe contener información resumida acerca de todos los proyectos en vuelo que se incluyen en la gobernanza de arquitectura, incluyendo: o El nombre y la descripción del proyecto o ámbito arquitectónico del proyecto o Los roles y las responsabilidades asociadas con el proyecto arquitectónico Medición del desempeño : En base a un estatuto de la función de la arquitectura, por lo general se define una serie de criterios de rendimiento. El registro de medición del desempeño debe capturar las métricas relacionadas para que el rendimiento puede ser medido y evaluado de forma continua a la gobernanza y cualquier otra medida de rendimiento en relación con la carta de la arquitectura del proyecto.

41.6 El Enterprise Repository Mientras que el Repositorio de Arquitectura contiene información relativa a la arquitectura de la empresa y los artefactos asociados hay un número considerable de repositorios empresariales que apoyan la arquitectura. Esto incluye los requisitos requisitos de acopio de repositorio y el Depósito Soluciones de almacenamiento Soluciones Building Blocks (SBB). Ver Figura 41-1 . Página 497 de 670


Los resultados de negocio para los requisitos se reflejarán en el Repositorio de soluciones a través del tiempo. Cuando esto ocurre se cumplen y se archivan para fines de auditoría con los requisitos. 41.6.1 Requisitos Repositorio

El Repositorio de Requisitos es utilizado por la fase de gestión de requisitos del Método de Desarrollo de Arquitectura () para registrar y gestionar toda la información pertinente a las necesidades de la arquitectura. Los requisitos frente a los muchos tipos de requisitos de arquitectura; es decir, los requisitos, estratégicos y de capacidad de segmento que son los motores principales de la arquitectura de la empresa. Los requisitos pueden ser recogidos en todas las etapas del ciclo de vida del desarrollo de la arquitectura y deben ser aprobados a través de las diferentes fases y procesos de gobernanza. 41.6.2 Soluciones Repositorio

El Repositorio Soluciones mantiene los bloques de construcción de la solución (SBB).

41.7 Repositorios externos 41.7.1 Modelos de referencia externos

Hay muchos modelos de referencia de la industria disponibles que pueden ayudar a comprender el papel de los y el desarrollo de las arquitecturas de referencia. Los ejemplos incluyen MDA de OMG, FEA de Gobierno de los EE.UU., TMF de la industria de las telecomunicaciones, los modelos de referencia de SOA de OASIS y The Open Group. Normas externos 41.7.2

Estos se refieren a la industria, mejores prácticas o estándares definidos formales utilizados por organizaciones líderes. Los ejemplos incluyen ISO, IEEE, y las normas gubernamentales. Aprobaciones 41.7.3 Arquitectura de la Junta

Las decisiones tomadas por el Consejo de Arquitectura que afectan a la arquitectura de la empresa a menudo se registran en las actas de las reuniones. Estas actas se celebran a menudo en los archivos de documentación que están excluidos de la Arquitectura Repositorio por motivos legales o reglamentarios.

Página 498 de 670




42. Herramientas para el Desarrollo de la Arquitectura 42.1 Información general Como un marco de arquitectura empresarial, TOGAF proporciona una base para el desarrollo de arquitecturas de una manera uniforme y consistente. Su objetivo en este sentido es asegurar que las diversas descripciones de arquitectura desarrollados dentro de una empresa, tal vez por diferentes arquitectos o equipos de arquitectura, soportan la comparación y la integración de arquitecturas de dentro y fuera de los dominios de la arquitectura (de negocios, datos, aplicaciones, tecnología), y en relación a diferentes ámbitos de la zona de negocios dentro de la empresa. Para apoyar este objetivo, TOGAF define numerosos productos en forma de arquitecturas, representados como modelos de arquitectura, vistas de la arquitectura de los modelos, y otros artefactos. Con el tiempo, estos artefactos se convierten en un recurso que debe ser gestionado y controlado, en particular con vistas a su reutilización. Este concepto se refiere el TOGAF como la "Empresa Continuum". Modelos de arquitectura y las vistas son discutidos en detalle por separado en la Parte IV , 35. Architectural Artifacts . Esta sección trata sobre las consideraciones en la elección de las herramientas automatizadas para generar este tipo de modelos de arquitectura y vistas, y para su mantenimiento en el tiempo.

42.2 Problemas de la Herramienta de Normalización En el estado actual del mercado de herramientas, muchas empresas de desarrollo de arquitecturas empresariales luchan con el tema de la estandarización de herramientas, ya sea que busquen un solo "una talla para todos" herramienta o un conjunto multiherramienta para el modelado de arquitecturas y la generación de los diferentes puntos de vista de arquitectura requerida. Hay ventajas aparentes asociadas con la selección de una sola herramienta. Organizaciones siguientes tal política puede aspirar a obtener beneficios tales como reducción de la formación, las licencias compartidas, descuentos por cantidad, el mantenimiento y el intercambio de datos más fácil. Sin embargo, también hay razones para negarse a identificar a una sola herramienta mandato, incluyendo razones de principio (que respaldan una única herramienta de la arquitectura no alentaría la innovación comercial competitiva o el desarrollo de la capacidad de la herramienta avanzada); y el hecho de que una sola herramienta no tendría en cuenta una variedad de desarrollo de la arquitectura "niveles de madurez" y necesidades específicas a través de una empresa. Página 499 de 670


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

Página 500 de 670




PARTE VI Modelos TOGAF Referencia

Página 501 de 670




. 43 Architecture Foundation: Referencia técnica Modelo En este capítulo se describe el modelo de referencia técnica (TRM), incluida la taxonomía básica, la representación gráfica y la detallada taxonomía plataforma. La taxonomía detallada plataforma se describe en 43.5 Taxonomía Plataforma detallada .

43.1 Conceptos En esta sección se describe el papel de la TRM, los componentes de la TRM, y el uso de otros TRM. 43.1.1 Función de la TRM en la Architecture Foundation

La Fundación Arquitectura TOGAF es una arquitectura de servicios genéricos y las funciones que proporciona una base sobre la que las arquitecturas más específicos y componentes arquitectónicos se pueden construir. Esta Architecture Foundation se encarna en el modelo de referencia técnica (TRM), que proporciona un modelo y taxonomía de los servicios de la plataforma genéricos. El TRM es universalmente aplicable y, por lo tanto, se puede utilizar para construir cualquier arquitectura de sistema. 43.1.2 TRM Componentes

Cualquier TRM tiene dos componentes principales: 1. Una taxonomía , que define la terminología, y proporciona una descripción coherente de los componentes y la estructura conceptual de un sistema de información 2. Un asociado gráfico TRM , que proporciona una representación visual de la taxonomía, como una ayuda para la comprensión

El objetivo de la TOGAF TRM es proporcionar un ampliamente aceptado taxonomía núcleo, y una representación visual apropiada de que la taxonomía. El gráfico TRM se ilustra en 43,3 TRM en detalle , y la taxonomía se explica en un 43,4 Application Platform Taxonomía . 43.1.3 Otros TRM

Una de las grandes dificultades en el desarrollo de un marco de arquitectura es en la elección de una TRM que funcione para todos. Página 502 de 670


El TOGAF TRM fue derivado originalmente de la Arquitectura del marco de Técnico de Gestión de la Información (TAFIM) TRM (que a su vez se deriva del modelo de IEEE 1003.0). Esta TRM es "plataforma-centric": se centra en los servicios y la estructura de la plataforma subyacente necesario para apoyar el uso y la reutilización de aplicaciones (es decir, la portabilidad de la aplicación). En particular, se centra en las interfaces entre la plataforma y que las aplicaciones soportadas, y entre la plataforma y el medio ambiente externo. La corriente TOGAF TRM es una versión modificada de la TAFIM TRM, que tiene como objetivo hacer hincapié en el aspecto de la interoperabilidad, así como el de la portabilidad. El objetivo de la TRM es permitir definición estructurado de la plataforma de aplicaciones estandarizada y sus interfaces asociadas. El resto de entidades, que son necesarios en cualquier arquitectura específica, sólo se abordan en la TRM en la medida en que influyen en la plataforma de aplicaciones. El objetivo que subyace en este enfoque es asegurar que los bloques de construcción de alto nivel que constituyen soluciones de negocio tienen una completa plataforma sólida sobre la que ejecutar. Otros modelos arquitectónicos - taxonomías y / o gráficos - no sólo son posibles, pero puede ser preferible para algunas empresas. Por ejemplo, un modelo de este tipo específico de la empresa podría ser derivado por extensión o adaptación del TOGAF TRM. Alternativamente, una taxonomía diferente puede ser realizada en el legado de la obra arquitectónica anterior por una empresa, y la empresa puede preferir a perpetuar el uso de esta taxonomía. Del mismo modo, una empresa puede preferir para representar la taxonomía TOGAF (o su propia taxonomía) utilizando una forma diferente de gráfico, que capta mejor los conceptos heredados y resulta más fácil para los propósitos de comunicación interna. Además de su uso como un modelo de referencia para el desarrollo de la arquitectura de la tecnología, la TRM se puede utilizar como una taxonomía para desarrollar una Base de Información de Normas (SIB) dentro de una organización específica. El núcleo de TOGAF es su : el TRM es una herramienta utilizada en la aplicación de la en el desarrollo de arquitecturas específicas. Coherencia prevista entre TRM y SIB se mantienen, el TOGAF es válida cualquiera que sea la elección de la taxonomía específica, TRM gráfico, o SIB conjunto de herramientas.

43.2 Desglose de Alto Nivel En esta sección se describen los principales elementos de la TRM. 43.2.1 Información general

El detalle más gruesa de la TRM se muestra en la Figura 43-1 , que muestra tres entidades principales (software de aplicación, la plataforma de aplicaciones y la infraestructura de Página 503 de 670


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

   Figura 43‐1: Referencia técnica Modelo ‐ de Alto Nivel de Vista

El diagrama no dice nada acerca de las relaciones detalladas entre las entidades; sólo que ellos existen. Cada uno de los elementos de este diagrama se discute en detalle en el 43,3 TRM en detalle . 43.2.2 Portabilidad e Interoperabilidad

La TRM de alto nivel busca destacar dos importantes objetivos arquitectónicos comunes: 1. Portabilidad de aplicaciones , a través de la plataforma de interfaz de aplicación - la identificación del conjunto de servicios que van a ser puestos a disposición en una forma estándar de aplicaciones a través de la plataforma

2. Interoperabilidad , a través de la interfaz de comunicaciones Infraestructura - la identificación del conjunto de servicios de infraestructura de comunicaciones que han de ser aprovechados de una manera estándar por la plataforma

Página 504 de 670


Ambos objetivos son esenciales para permitir la integración dentro de la empresa y la interoperabilidad de confianza a escala mundial entre las empresas. En particular, el modelo de alto nivel busca reflejar el papel cada vez más importante de Internet como base para la interoperabilidad inter e intra-empresa. La dimensión horizontal de la modelo en la Figura 43-1 representa la diversidad, y la forma del modelo se pretende hacer hincapié en la importancia de la diversidad mínima en la interfaz entre la plataforma de aplicaciones y la infraestructura de comunicaciones. Esto a su vez significa centrarse en el conjunto básico de servicios que pueden ser garantizados con el apoyo de todas las redes basadas en IP, como la base sobre la que construir entornos informáticos empresariales interoperables de hoy.

43.3 TRM en detalle En esta sección se describe la TRM en detalle, incluyendo las categorías de servicios de plataforma y entorno externo sub-entidades. 43.3.1 Introducción Figura 43-2 se expande en la Figura 43-1 para presentar las categorías de servicios de la plataforma de aplicaciones y las dos categorías de software de aplicación.

Página 505 de 670


Figura 43‐2: Modelo de referencia técnica detallada (Mostrando Categorías de servicio) Figura 43-2 es sólo una representación de las entidades de TRM: ni implica ni inhibe las

interrelaciones entre ellos. Arquitecturas de TI derivados de TOGAF pueden variar considerablemente en función de los requisitos del sistema de información. En la práctica, muchas arquitecturas no incluirán todos los servicios aquí descritos, y muchos van a incluir servicios adicionales para apoyar el software de aplicación que es específico de la organización o de su industria vertical. En la construcción de una arquitectura , los s de TOGAF deben evaluar sus propias necesidades y seleccionar los servicios, interfaces y estándares que satisfagan sus propias necesidades de negocio. 43.3.2 Entidades TRM e Interfaces

Las secciones siguientes describen en detalle cada elemento de la TRM se ilustra en la Figura 43-2 . Ambos se incluyen en el siguiente orden: Las tres entidades:

Página 506 de 670

The Open Group Architecture Framework TOGOF 9.1   o software de aplicación (ver 43.3.3 Aplicación de Software ) o plataforma de aplicaciones (ver 43.3.4 Application Platform ) o infraestructura de comunicaciones (ver 43.3.5 Infraestructura de Comunicaciones ) Las dos interfaces: o Aplicación Interface Platform (ver 43.3.6 Aplicación Interface Platform ) o Interfaz de infraestructura de comunicaciones (ver 43.3.7 Interfaz de Comunicaciones Infraestructura )

43.3.3 Aplicación de Software

La TRM detallada reconoce dos categorías de Software de aplicación: 1. Aplicaciones empresariales , que implementan negocio procesos para una empresa en particular o sector vertical. La estructura interna de las aplicaciones de negocio se relaciona estrechamente con la configuración de software de aplicación específico seleccionado por una organización.

2. Aplicaciones de Infraestructura , que proporcionan funcionalidad empresarial de uso general, con base en los servicios de infraestructura.

Durante el desarrollo de la arquitectura de la tecnología, aplicaciones de negocios y aplicaciones de infraestructura son importantes fuentes de requisitos para los servicios de arquitectura de la tecnología, y la selección de las normas para la plataforma de aplicaciones se verán influenciados fuertemente por la configuración del software de aplicación para ser itido. 43.3.3.1 Aplicaciones empresariales

Las aplicaciones empresariales son las aplicaciones que son específicas de una empresa en particular o industria vertical. . Dichas aplicaciones suelen modelar elementos de dominio de una empresa de actividad o proceso de negocios Ejemplos de las aplicaciones de negocio pueden incluir: Servicios de gestión de archivo de historias clínicas utilizadas en la industria médica Servicios de gestión de inventario utilizados en la industria al por menor Servicios de modelado de datos geológicos utilizados en la industria del petróleo

Con el tiempo, las aplicaciones de negocio en particular puede convertirse en aplicaciones de infraestructura, si llegan a ser lo suficientemente ubicuos, interoperables y de propósito general que es potencialmente útil para una amplia gama de s de TI de la empresa. 43.3.3.2 Aplicaciones Infraestructura

Página 507 de 670


Aplicaciones de infraestructura son las aplicaciones que tienen todas, o casi todas, de las siguientes características: La amplia disponibilidad como Commercial Off-The-Shelf (COTS) de software significa que es poco rentable para considerar la implementación personalizada. La interacción del es una parte importante de la función de la aplicación. Las implementaciones se basan en los servicios de infraestructura. Las implementaciones pueden incluir extensiones significativas más allá de la necesaria para utilizar los servicios de infraestructura subyacentes. La interoperabilidad es un requisito fuerte.

Ejemplos de las aplicaciones en esta categoría incluyen: Servicios de pago y transferencia electrónica de fondos Servicios de cliente de correo electrónico Publicar y suscribirse Los agentes inteligentes Servicios de calendario y programación Servicios Groupware Los servicios de flujo de trabajo Hojas de cálculo El software de presentación Edición de documentos y presentación Aplicaciones de gestión, sistema de uso general rendimiento y gestión de redes funciones para el del sistema Herramientas de ingeniería de software, proporcionando funciones de desarrollo de software para el personal de desarrollo de sistemas

Aplicaciones de infraestructura tienen fuertes dependencias de servicios de nivel inferior en la arquitectura. Por ejemplo, una aplicación de flujo de trabajo puede utilizar los servicios de la plataforma, como la mensajería o el procesamiento de transacciones para implementar el flujo de trabajo entre tareas. Del mismo modo, una aplicación de trabajo en grupo es probable que hacer un uso extensivo de los datos y servicios de comunicación para la estructura de los documentos, así como la mecánica de almacenar y acceder a ellos. Aplicaciones de infraestructura, por definición, son aplicaciones que se consideran suficientemente ubicuos, interoperables y de uso general dentro de la empresa puedan Página 508 de 670


considerarse de hecho como parte de la infraestructura de TI. Al igual que las aplicaciones de negocio pueden con el tiempo llegan a ser consideradas como aplicaciones de infraestructura, por lo que las aplicaciones de infraestructura suelen ser candidatos para ser incluidos como servicios de infraestructura en las futuras versiones de un TI arquitectura. 43.3.4 Plataforma de Aplicaciones 43.3.4.1 Plataforma Concept

El término "plataforma" se utiliza de muchas maneras diferentes en la industria de TI hoy en día. Debido a los diferentes usos, el término a menudo calificado; por ejemplo, "la plataforma de aplicaciones", "normalizado" y "plataformas propietarias", "cliente" y "plataformas de servidor", "plataforma informática distribuida", "plataforma de portabilidad". Común a todos estos usos es la idea de que alguien necesita un conjunto de servicios prestados por un determinado tipo de plataforma, y pondrá en marcha una función de "alto nivel" que hace uso de esos servicios. El TOGAF TRM se centra en la plataforma de aplicaciones, y la "función de nivel superior" es el conjunto de software de aplicación, que se ejecuta en la parte superior de la plataforma de aplicaciones, que se necesita para hacer frente a los requerimientos del negocio de la empresa. Es importante reconocer que la plataforma de aplicaciones en el TOGAF TRM es un genérico, entidad, conceptual. Desde el punto de vista de la TOGAF TRM, la Plataforma de Aplicaciones contiene todos los servicios posibles. En una arquitectura específica de destino, la plataforma de aplicaciones contendrá sólo aquellos servicios necesarios para apoyar las funciones requeridas. Por otra parte, la plataforma de aplicaciones para una arquitectura específica Target normalmente no ser una entidad única, sino más bien una combinación de diferentes entidades para diferentes funciones más necesarias, como cliente de escritorio, servidor de archivos, servidor de impresión, servidor de aplicaciones, servidor de Internet, bases de datos servidor, etc, cada uno de los cuales estará integrado por un conjunto específico, definido de servicios necesarios para apoyar la función específica de que se trate. También es importante reconocer que muchos de los sistemas de TI del mundo real que sean comprados y utilizados en la actualidad para implementar una arquitectura de tecnología están totalmente equipadas con numerosos servicios avanzados, que a menudo se dan por sentados por el comprador. Por ejemplo, un sistema de ordenador de sobremesa típico de hoy viene con el software que implementa los servicios de la mayoría, si no todas las categorías de servicios de la TOGAF TRM. Dado que el comprador de un sistema de este tipo a menudo no se considera nada "más pequeño" que el paquete total de servicios que viene con el sistema, ese paquete de servicio puede llegar a ser muy fácilmente la "plataforma". En efecto, en ausencia de una Arquitectura Tecnológica para guiar el proceso Página 509 de 670


de adquisición, esto es, invariablemente, lo que sucede. Como este proceso se repite en toda la empresa, los diferentes sistemas adquiridos para funciones similares (como el cliente de escritorio, servidor de impresión, etc) pueden contener marcadamente diferentes paquetes de servicios. Paquetes de servicios están representados en una Arquitectura Tecnológica en forma de "bloques de construcción". Una de las tareas clave del arquitecto de TI para pasar de la plataforma de aplicaciones conceptual de la TRM para una Arquitectura Tecnológica específica de la empresa es mirar más allá del conjunto de plataformas del mundo real que ya existen en la empresa. El arquitecto de TI debe analizar los servicios realmente necesarios a fin de implementar una infraestructura de TI que cumpla con los requerimientos del negocio de la empresa en la forma óptima, y para definir el conjunto de óptimas soluciones de Bloques de Construcción (SBB) - en el mundo real "plataformas" para poner en práctica esa arquitectura. 43.3.4.2 La extensión de la TRM

El TOGAF TRM identifica un conjunto genérico de servicios de la plataforma, y proporciona una taxonomía en la que estos servicios de la plataforma se dividen en categorías de funcionalidad similar. Una organización en particular puede que tenga que aumentar este conjunto con servicios adicionales o categorías de servicios que se consideran ser genéricos en su propio segmento de mercado vertical. El conjunto de servicios identificados y definidos para la plataforma de aplicaciones va a cambiar con el tiempo. Se necesitarán nuevos servicios como aparece la nueva tecnología y a medida que cambian las necesidades de aplicación. 43.3.4.3 Interfaces entre Servicios

Además de apoyar el software de aplicación a través de la plataforma de aplicaciones de interfaz (API), los servicios de la plataforma de aplicaciones pueden apoyarse unos a otros, ya sea mediante interfaces especificadas abiertamente lo que puede o no ser la misma que la API, o por interfaces no expuestas privadas. Un objetivo clave del desarrollo de la arquitectura es para módulos de servicios sean capaces de sustitución por otros módulos que proporcionan la misma funcionalidad del servicio a través de la misma API de servicio. El uso de las interfaces privadas, sin impresionar entre módulos de servicio puede comprometer la capacidad de sustituir. Interfaces privadas representan un riesgo que debe ser resaltado para facilitar la futura transición. 43.3.4.4 Desarrollos futuros

La TRM se ocupa de la futura evolución de la plataforma de aplicaciones de dos formas. En primer lugar, como las interfaces con los servicios que se estandaricen, funcionalidad que formaba parte anteriormente de la entidad de software de aplicación migra a formar parte Página 510 de 670


de la plataforma de aplicaciones. En segundo lugar, la TRM se puede ampliar con nuevas categorías de servicios que aparece una nueva tecnología. Ejemplos de áreas funcionales que pueden incluirse en las categorías de servicio de la plataforma de aplicaciones en el futuro incluyen: Funciones de hoja de cálculo, incluyendo la capacidad de crear, manipular y presentar la información en tablas o gráficos; esta capacidad debe incluir la capacidad de habla como de cuarta generación que permiten el uso de la lógica de programación dentro de las hojas de cálculo Funciones de apoyo a las decisiones, incluidas las herramientas que apoyan la planificación, istración y gestión de proyectos Funciones de cálculo, incluyendo la capacidad de realizar cálculos aritméticos rutinarias y complejas Funciones de calendario, incluyendo la capacidad para gestionar proyectos y horarios coordinados a través de un calendario automatizado

Una taxonomía detallada de la plataforma de aplicaciones se da en el 43,4 Application Platform - Taxonomía . 43.3.5 Comunicaciones Infraestructura

La infraestructura de comunicaciones proporciona los servicios básicos para la interconexión de sistemas y proporcionar los mecanismos básicos para la transferencia de datos opaco. Contiene los elementos de hardware y software que forman los enlaces de comunicaciones en red y físicos utilizados por el sistema, y por supuesto todos los otros sistemas conectados a la red. Tiene que ver con el complejo mundo de las redes y la infraestructura de comunicaciones físico, incluyendo interruptores, proveedores de servicios y los medios de transmisión física. Un conductor primario en Arquitectura Tecnología de toda la empresa en los últimos años ha sido la creciente conciencia de la utilidad y el costo-efectividad de Internet como la base de una infraestructura de comunicaciones para la integración de la empresa. Esto está causando un rápido aumento en el uso de Internet y un aumento constante en la gama de aplicaciones que unen a la red para el servicio descentralizado. Esto se considera aún más en 43.3.7 Interfaz de Comunicaciones Infraestructura . 43.3.6 Aplicación Interface Platform

La plataforma de interfaz de aplicaciones (API) especifica una interfaz completa entre el software de aplicación y la plataforma de aplicaciones subyacente a través del cual se proporcionan los servicios. Una definición rigurosa de los resultados de la interfaz en portabilidad de la aplicación, a condición de que tanto la plataforma y la aplicación se Página 511 de 670


ajustan a la misma. Para que esto funcione, la definición de la API debe incluir la sintaxis y la semántica de no sólo la interfaz de programación, sino también todo el protocolo necesario y definiciones de estructuras de datos. Portabilidad depende de la simetría de la conformidad de las aplicaciones y de la plataforma a la API con arquitectura. Es decir, la plataforma debe ser compatible con la API de lo especificado, y la aplicación debe utilizar no más de la API especificada. El API especifica una interfaz completa entre una aplicación y uno o más servicios que ofrece la plataforma de aplicaciones subyacente. Una aplicación puede utilizar varios APIs, y puede incluso utilizar diferentes APIs para implementaciones diferentes de un mismo servicio. Interface 43.3.7 Comunicaciones Infraestructura

La interfaz de la infraestructura de comunicaciones es la interfaz entre la plataforma de aplicaciones y la infraestructura de comunicaciones. Figura 43-1 busca reflejar el papel cada vez más importante de Internet como base para la interoperabilidad inter e intra-empresa. La dimensión horizontal de la modelo en la Figura 431 representa la diversidad, y la forma de la modelo está destinado específicamente para enfatizar la diversidad mínima en la interfaz entre la plataforma de aplicaciones y la infraestructura de comunicaciones.

En particular, el modelo hace hincapié en la importancia de centrarse en el conjunto básico de servicios que pueden ser garantizados con el apoyo de todas las redes basadas en IP, como la base sobre la que construir entornos informáticos empresariales interoperables de hoy. 43.3.8 Cualidades

Además del conjunto de componentes que forman el TRM, hay un conjunto de atributos o cualidades que son aplicables a todos los componentes. Por ejemplo, para el servicio de gestión para ser eficaz, capacidad de gestión debe ser una cualidad omnipresente de todos los servicios de la plataforma, aplicaciones y servicios de infraestructura de comunicaciones. Figura 43-2 capta este concepto representa los componentes de TRM se sientan en un plano

posterior de cualidades. Otro ejemplo de una calidad de servicio es la seguridad. La aplicación adecuada de todo el sistema de seguridad requiere no sólo un conjunto de servicios de seguridad, que corresponden a la categoría de los servicios de seguridad se muestra en la plataforma, sino también el apoyo (es decir, la "conciencia de seguridad") de software en otras partes de la Página 512 de 670


TRM. Por lo tanto, una aplicación podría utilizar un servicio de seguridad para marcar un archivo como de sólo lectura, pero es la aplicación correcta de la calidad de la seguridad en los servicios del sistema operativo que impide que las operaciones de escritura en el archivo. Servicios de seguridad y del sistema operativo deben cooperar para hacer el archivo seguro. Cualidades se especifican en detalle durante el desarrollo de una arquitectura de destino. Algunas cualidades son más fáciles que otros para describir en términos de estándares. Por ejemplo, el apoyo de un conjunto de locales se puede definir como parte de la especificación de la calidad a escala internacional. Otras cualidades mejor pueden especificarse en términos de medidas en lugar de los estándares. Un ejemplo sería el rendimiento, para el que las API o protocolos estándar son de uso limitado.

43.4 Plataforma de Aplicaciones - Taxonomía En esta sección se describe la taxonomía plataforma de aplicaciones, incluidos los principios fundamentales y un resumen de los servicios y calidades. Una taxonomía detallada de servicios de la plataforma y cualidades se puede encontrar en 43,5 Taxonomía Plataforma detallada . 43.4.1 Principios básicos

El TOGAF TRM tiene dos componentes principales: 1. Una taxonomía , que define la terminología, y proporciona una descripción coherente de los componentes y la estructura conceptual de un sistema de información 2. Un asociado gráfico TRM , que proporciona una representación visual de la taxonomía, como una ayuda para la comprensión

En esta sección se describe en detalle la taxonomía del TOGAF TRM. El objetivo es proporcionar una taxonomía central que proporciona una definición útil, coherente y estructurado de la entidad Plataforma de aplicaciones y es ampliamente aceptable. No se hacen afirmaciones que la clasificación elegida es la única posible, o que representa la mejor opción. De hecho, es importante hacer hincapié en que el uso de TOGAF, y, en particular, el TOGAF , es de ninguna manera depende del uso de la taxonomía TOGAF TRM. Otros taxonomías son perfectamente posibles, y pueden ser preferibles para algunas organizaciones. Por ejemplo, una taxonomía diferente puede ser realizada en el legado de la obra arquitectónica anterior por una organización, y la organización puede preferir a perpetuar el uso de esta taxonomía. Alternativamente, una organización puede decidir que se puede Página 513 de 670


derivar una taxonomía específica de la organización más adecuada mediante la extensión o adaptación de la taxonomía TOGAF TRM. De la misma manera, una organización puede preferir para representar la taxonomía TOGAF (o su propia taxonomía) utilizando una forma diferente de gráfico TRM, que capta mejor los conceptos heredados y resulta más fácil para los propósitos de comunicación interna. 43.4.2 Aplicación de Servicios Plataforma Categorías

Las principales categorías de servicios definidos para la plataforma de aplicaciones se enumeran a continuación. Tenga en cuenta que "los servicios de objetos" no aparece como una categoría de la taxonomía TRM. Esto se debe a que todos los servicios de objetos individuales se incorporan en las principales categorías de servicios pertinentes. Sin embargo, las diversas descripciones también se recogen en un único apartado (véase 43.4.2.1 orientada a objetos Prestación de Servicios ) con el fin de proporcionar un único punto de referencia que muestra cómo los servicios de objetos relacionados con las principales categorías de servicios. Servicios de Intercambio de Datos (ver 43.5.1 Servicios de datos de intercambio ): o Documentar los servicios de tipos de datos y conversión genéricos o servicios de intercambio de datos gráficos o servicios de intercambio de datos especializadas o servicios de intercambio electrónico de datos o Los servicios de fax o funciones de la interfaz gráfica Raw o funciones de procesamiento de texto o funciones de procesamiento de documentos o Las funciones de publicación o funciones de procesamiento de vídeo o funciones de procesamiento de audio o funciones de procesamiento multimedia o funciones de sincronización de medios o funciones de presentación y distribución de información

Página 514 de 670

The Open Group Architecture Framework TOGOF 9.1   o funciones de hipertexto Servicios de gestión de datos (véase 43.5.2 Servicios de gestión de datos ): o diccionario de datos / servicios de repositorio o Sistema de Gestión de Base de Datos de los servicios (DBMS) o servicios de Sistema de Gestión de Base de datos orientada a objetos (SGBDOO) o Los servicios de gestión de archivos o funciones de procesamiento de consultas o funciones de generación de pantalla o Informe funciones de generación de o Redes funciones de / concurrentes o las funciones de almacenamiento Gráficos y Servicios de imágenes (véase 43.5.3 Gráficos y servicios de imágenes ): o Los servicios de gestión gráfica de objetos o servicios de Dibujo o funciones de imagen Servicios Internacionales de la operación (ver 43.5.4 Internacionales Servicios de Operación ): o Los conjuntos de caracteres y servicios de representación de datos o Los servicios de convenciones Cultural o Los servicios de apoyo en el idioma local Ubicación y servicios de directorio (véase 43.5.5 Ubicación y servicios de directorio ): o Los servicios de directorio o Los servicios de nombres para usos especiales o los servicios de ubicación de servicio o Los servicios de inscripción o Los servicios de filtrado o Servicios de contabilidad Servicios de red (véase 43.5.6 Servicios de red ): o Los servicios de comunicaciones de datos

Página 515 de 670

The Open Group Architecture Framework TOGOF 9.1   o los servicios de correo electrónico o servicios de datos distribuidos o servicios de archivos distribuidos o servicios de nombres distribuidos o servicios de tiempo Distribuido o servicios de procesos a distancia () o Los servicios de cola de impresión remota y la distribución de salidas o funciones de telefonía mejoradas o funciones de la pantalla compartida o funciones de conferencia de vídeo o funciones de difusión o funciones de la lista de correo Servicios del sistema operativo (véase 43.5.7 Servicios del sistema operativo ): o Los servicios de operaciones del kernel o servicios de intérprete de comandos y de servicios públicos o Los servicios de procesamiento por lotes o Los servicios de archivos y sincronización de directorios Servicios de Ingeniería de Software (ver 43.5.8 Software Engineering Services ): o Los servicios de lenguaje de programación o Código objeto vincular los servicios o servicios de ingeniería de software asistida por ordenador (CASE) medio ambiente y herramientas o servicios de la interfaz gráfica de (GUI) de construcción o Los servicios de lenguaje de secuencias de comandos o servicios de Idioma vinculante o Los servicios de entorno de tiempo de ejecución o servicios de interfaz de aplicación binaria

Página 516 de 670

The Open Group Architecture Framework TOGOF 9.1   Servicios de procesamiento de transacción (ver 43.5.9 Servicios de Procesamiento de Transacciones ): o Los servicios de de transacciones Servicios de la interfaz de (ver 43.5.10  Servicios Interface ): o servicios Cliente gráfico / servidor o mostrar los objetos de servicios o Los servicios de istración de Ventana o servicios de apoyo de diálogo o Servicios de impresión o servicios de formación y de ayuda en línea basados en ordenador o Los servicios basados en caracteres Servicios de seguridad (ver Servicios de Seguridad 43.5.11 ): o servicios de autenticación de Identificación y o servicios de control de entrada del sistema o Los servicios de Auditoría o Los servicios de control de o Los servicios de no repudio o Los servicios de gestión de seguridad o servicios de recuperación de confianza o Los servicios de cifrado o servicios de comunicaciones de confianza Sistema y Servicios de Gestión de Red (ver 43.5.12 Sistema y los Servicios de Gestión de Red ): o Los servicios de gestión de o Configuración de la gestión de servicios (CM) o Los servicios de gestión de rendimiento o Disponibilidad y gestión de fallos servicios o Los servicios de gestión de la contabilidad

Página 517 de 670

The Open Group Architecture Framework TOGOF 9.1   o Los servicios de gestión de seguridad o Imprimir Servicios de gestión o Los servicios de gestión de red o Copia de seguridad y los servicios de restauración o Los servicios de gestión de disco en línea o Los servicios de gestión de Licencia o Los servicios de gestión de la capacidad o Los servicios de instalación de software o Dificultad para venta de entradas de servicios 43.4.2.1 orientada a objetos Prestación de Servicios

Una descripción detallada de cada una de estas categorías de servicios se da en 43.5.13 orientada a objetos Prestación de Servicios . Object Request Broker (ORB) Servicios: o Los servicios de repositorio de Implementación o Servicios de instalación y activación o servicios de repositorio de interfaz o Los servicios de replicación Comunes Servicios de objeto: o cambiar los servicios de gestión o Los servicios de Colecciones o Los servicios de control de concurrencia o Los servicios de intercambio de datos o servicios de gestión de eventos o Los servicios de Externalización o Servicios de cesión o Los servicios de ciclo de vida o servicios de nombres

Página 518 de 670

The Open Group Architecture Framework TOGOF 9.1   o Los servicios de objetos persistentes o Propiedades de los servicios o Los servicios de consulta o Los servicios de relaciones o Servicios de seguridad o servicios de puesta en marcha o Los servicios de Tiempo o Los servicios de comercio o Servicios de transacción,

43.4.3 Cualidades aplicación de servicio de la plataforma 43.4.3.1 Principios

Además de las categorías de servicios de plataforma delineados por categoría funcional, calidades de servicio afectan Arquitecturas de Sistemas de Información. A la calidad de servicio se describe un comportamiento, como la capacidad de adaptación o de gestión. Calidades de servicio tienen un efecto penetrante en el funcionamiento de la mayoría o la totalidad de las categorías de servicios funcionales. En general la exigencia de un determinado nivel de calidad de servicio en particular requiere una o más categorías de servicios funcionales a cooperar en la consecución del objetivo. Por lo general, esto significa que los bloques de construcción de software que implementan los servicios funcionales contienen software que contribuye a la implementación de la calidad. Por la calidad que se proporciona adecuadamente, todos los servicios funcionales pertinentes deben haber sido diseñados para apoyarlo. Cualidades de servicios también tienen que sujetarse en software en la entidad de software de aplicación y el ambiente externo, así como la plataforma de aplicaciones. En algunos casos, una calidad de servicio afecta a cada una de las categorías de servicios en una manera similar, mientras que en otros casos, la calidad del servicio tiene una influencia única en una categoría de servicio particular. Por ejemplo, la operación internacional depende de la mayor parte de las categorías de servicios de la misma manera, tanto a los servicios ya la necesidad de su cooperación para la localización de los mensajes, las fuentes y otras características de un local, pero puede tener un efecto más profundo en la servicios de ingeniería de software, que quizá requiera de instalaciones para la producción de software internacionalizado. Página 519 de 670


Durante el proceso de desarrollo de la arquitectura, el arquitecto debe ser consciente de la existencia de las cualidades y el grado de su influencia en la elección de los bloques de construcción de software utilizado en la implementación de la arquitectura. La mejor manera de asegurarse de que las cualidades no se olvidan es crear una matriz de calidad, que describe las relaciones entre cada servicio funcional y las cualidades que influyen en ella. 43.4.3.2 Taxonomía de calidades de servicio

Las calidades de servicio actualmente identificados en la taxonomía TRM son: Disponibilidad (el grado en que algo está disponible para su uso), incluyendo: o Capacidad de istración , la capacidad de reunir información sobre el estado de algo y para controlarlo o de servicio , la capacidad de identificar los problemas y tomar medidas correctivas, tales como reparar o actualizar un componente en un sistema que ejecuta o de rendimiento , la capacidad de un componente para ejercer sus funciones en el momento oportuno o fiabilidad , o la resistencia al fracaso o valorización , o la capacidad de restaurar un sistema a un estado de trabajo después de una interrupción O el estado de localización , la capacidad de un sistema para encontrar cuando sea necesario Aseguramiento , incluyendo: o de seguridad , o la protección de la información contra s no autorizados o integridad o la seguridad de que los datos no se ha dañado o credibilidad , o el nivel de confianza en la integridad del sistema y sus datos Usabilidad , o la facilidad de operación de los s, incluyendo: o la operación internacional , incluyendo habilidades multilingües y multiculturales Adaptabilidad , incluyendo: o la interoperabilidad , ya sea dentro o fuera de la organización (por ejemplo, la interoperabilidad de las funciones de calendario o programación puede ser clave para la utilidad de un sistema) O escalabilidad , la capacidad de un componente para aumentar o reducir su rendimiento o capacidad adecuada a las exigencias del entorno en el que opera o Portabilidad , de datos, de personas, aplicaciones y componentes

Página 520 de 670

The Open Group Architecture Framework TOGOF 9.1   o extensibilidad , o la capacidad de aceptar la nueva funcionalidad o La capacidad de ofrecer a los servicios en los nuevos paradigmas, tales como la orientación a objetos

43.5 Taxonomía Plataforma detallada En esta sección se ofrece una taxonomía detallada de los servicios de la plataforma y cualidades. 43.5.1 Servicios de datos de intercambio

Servicios de intercambio de datos proporcionan apoyo especializado para el intercambio de información entre las aplicaciones y el entorno externo. Estos servicios están diseñados para manejar el intercambio de datos entre aplicaciones en la misma plataforma y aplicaciones en diferentes plataformas (heterogéneas). Existe un conjunto análogo de los servicios de intercambio de datos orientada a objetos, que se puede encontrar en Servicios de Intercambio de Datos y Servicios de Externalización de 43.5.13 orientada a objetos Prestación de Servicios . Documento Generic Data Typing y Conversión servicios están respaldados por las especificaciones para la codificación de los datos (por ejemplo, texto, imagen, carácter numérico, especial) y tanto las estructuras lógicas y visuales de los documentos electrónicos, incluidos los documentos compuestos. Gráficos de datos de intercambio de servicios se apoyan en las descripciones independientes del dispositivo de elementos de imagen para gráficos basados en vectores y descripciones de gráficos basados en raster. Especializada Data Interchange servicios están respaldados por las especificaciones que describen los datos utilizados por mercados verticales específicos.Mercados cuando éstas existan incluyen las industrias del petróleo Médico, Biblioteca, Dental, Assurance, y. Electronic Data Interchange servicios se utilizan para crear un entorno electrónico (sin papel) para llevar a cabo el comercio y lograr ganancias significativas en la calidad, capacidad de respuesta, y el ahorro que ofrece este entorno. Ejemplos de las aplicaciones que utilizan servicios de comercio electrónico incluyen: búsqueda y selección de proveedores; adjudicación del contrato; datos de los productos; envío, reenvío y recepción; costumbres; información de pago; control de inventarios; mantenimiento; los datos relacionados con los impuestos; y los datos relacionados con los seguros. Fax servicios se utilizan para crear, analizar, transmitir y / o recibir imágenes de fax.

Las siguientes áreas funcionales están soportados principalmente por el software de aplicación, pero están avanzando hacia la migración a la plataforma de aplicaciones: Gráficos Raw Interfaz formatos de archivos de datos gráficos de apoyo a funciones tales como TIFF, JPEG, GIF, y CGM.

Página 521 de 670

The Open Group Architecture Framework TOGOF 9.1   Tratamiento de Textos funciones, incluyendo la capacidad de crear, editar, combinar, y dar formato al texto. Procesamiento de Documentos funciones, incluyendo la capacidad de crear, editar, combinar, y formatear documentos. Estas funciones permiten a la composición de los documentos que incorporan gráficos, imágenes, e incluso anotación de voz, junto con el texto estilizado. Se incluyen de formato y edición avanzadas funciones como guías de estilo, corrección ortográfica, el uso de múltiples columnas, tabla de la generación de contenido, encabezados y pies de página, herramientas Esquema, y el apoyo para la digitalización de imágenes en formatos de mapas de bits. Otras capacidades incluyen la compresión y descompresión de imágenes o documentos enteros. Publicación funciones, incluyendo la incorporación de imágenes de calidad fotográfica y gráficos en color y características de formato y estilo avanzadas, tales como el ajuste de texto alrededor de objetos gráficos o fotos y kerning (es decir, cambiar el espaciado entre caracteres de texto). Estas funciones también interactuar con sofisticados equipos de impresión y producción. Otras capacidades incluyen la representación de color y la compresión y descompresión de imágenes o documentos enteros. Video Processing funciones, incluyendo la capacidad de capturar, componer, editar, comprimir y descomprimir la información de vídeo utilizando formatos como MPEG. Aún así también se proporcionan gráficos y funciones de generación de título. Procesamiento de audio funciones, incluyendo la capacidad de capturar, componer, editar, comprimir y descomprimir datos de audio. Procesamiento Multimedia funciones, incluyendo la capacidad de almacenar, recuperar, modificar, ordenar, buscar e imprimir todos o cualquier combinación de los medios de comunicación mencionados. Esto incluye el apoyo a los medios de comunicación microfilm, tecnología de almacenamiento óptico que permite el almacenamiento de los documentos escaneados o produce computadora que utilizan técnicas digitales de almacenamiento, una función de barrido, y la compresión y descompresión de datos. Sincronización de medios funciones permiten la sincronización de los flujos de datos, tales como audio y video para presentaciones. Presentación de la Información y de distribución funciones se utilizan para gestionar la distribución y presentación de información de lotes y aplicaciones interactivas. Estas funciones se utilizan para proteger las aplicaciones en áreas de negocio de cómo se utiliza la información. Permiten a las aplicaciones en áreas de negocio para crear piscinas genéricas de información sin la incorporación de controles que determinan el uso de esa información. Funciones de distribución de la información y de presentación incluyen la selección de las funciones de formato apropiadas requeridas para llevar a cabo la distribución y presentación de la información a una variedad de aplicaciones en áreas de negocio y los s. Funciones de presentación y distribución de la información también incluye la capacidad de almacenar, archivar, priorizar, restringir, y volver a crear información. Hipertexto funciones apoyan la generación, distribución, localización, búsqueda y visualización de texto e imágenes, ya sea local o global. Estas funciones incluyen la búsqueda y la navegación, los enlaces de hipertexto, y la presentación de información multimedia.

Página 522 de 670

The Open Group Architecture Framework TOGOF 9.1   Servicios de gestión de datos 43.5.2

. Central a la mayoría de los sistemas es la gestión de datos que se puede definir de forma independiente de los procesos que crean o utilizan, mantenerse indefinidamente, y se comparte entre muchos procesos de los servicios de gestión de datos incluyen: Diccionario de Datos / Repositorio servicios permiten a los es de datos y los ingenieros de la información para acceder y modificar los datos acerca de los datos (es decir, metadatos). Estos datos pueden incluir formatos interna y externa, la integridad y reglas de seguridad, y la ubicación dentro de un sistema distribuido. Diccionario de datos y servicios de repositorio también permiten a los s finales y las aplicaciones para definir y obtener datos que está disponible en la base de datos. La istración de datos define la normalización y registro de los tipos de elementos de datos individuales para cumplir con los requisitos para el intercambio de datos y la interoperabilidad entre los sistemas de información en toda la empresa. Funciones de istración de datos incluyen los procedimientos, pautas y métodos para la planificación efectiva de datos, análisis, normas, modelos, gestión de configuración, almacenamiento, recuperación, protección, la validación y la documentación. Los diccionarios de datos a veces son atados a un único sistema de gestión de bases de datos (DBMS), pero los diccionarios de datos heterogéneas apoyarán el a diferentes DBMS. Repositorios pueden contener una amplia variedad de información, incluyendo bases de información de istración (MIB), o información relacionados con las causas. Sistemas orientados a objetos pueden proporcionar repositorios de objetos e interfaces, descritas en los servicios de repositorio de implementación y servicios de repositorio de interfaz en 43.5.13 orientada a objetos Prestación de Servicios . Sistema de Gestión de Base de Datos (DBMS) servicios proporcionan controlado a los datos estructurados. Para gestionar los datos, el DBMS proporciona control de concurrencia y facilidades para combinar datos de diferentes esquemas. Los diferentes tipos de DBMS soportan diferentes modelos de datos, entre ellos, la red, los modelos orientados a objetos, y de archivos planos relacionales, jerárquicas. Algunos DBMS están diseñados para funciones especiales tales como el almacenamiento de objetos grandes o datos multimedia. Servicios de DBMS son accesibles a través de una interfaz de lenguaje de programación, una interfaz de lenguaje de manipulación de datos interactivos (como SQL), o un interfaz de lenguaje interactivo / cuarta generación. Look-up y recuperación de datos para los objetos se describen por separado en los servicios de consulta en 43.5.13 orientada a objetos Prestación de Servicios . Para una mayor eficiencia, los DBMS a menudo ofrecen servicios específicos para crear, rellenar, mover, copia de seguridad, restaurar, recuperar, y bases de datos de archivos, aunque algunos de estos servicios podrían ser proporcionados por las capacidades de istración de archivos generales descritos en 43.5.7 Servicios del sistema operativo o una específica servicio de copia de seguridad. Algunos distribución apoyo DBMS de la base de datos, incluyendo las instalaciones para la actualización de registros de forma remota, replicación de datos, localizar y almacenar datos en caché, y la istración remota. Sistema de gestión de base de datos orientada a objetos de servicios (SGBDOO) proporcionan almacenamiento para objetos e interfaces a esos objetos.Estos servicios pueden apoyar el Repositorio de Ejecución, Interface Repository, y los servicios de objetos persistentes en 43.5.13 orientada a objetos Prestación de Servicios . istración de archivos proporcionan servicios de gestión de datos a través de métodos de a archivos incluidos secuencial indizado (ISAM) y hash de

Página 523 de 670

The Open Group Architecture Framework TOGOF 9.1   aleatorio. Servicios de archivos planos y directorios se describen en 43.5.7 servicios del sistema operativo .

Las siguientes áreas funcionales están soportados principalmente por el software de aplicación, pero están avanzando hacia la migración a la plataforma de aplicaciones: Procesamiento de consultas funciones que proporcionan para la selección interactiva, la extracción y el formato de la información almacenada en los archivos y bases de datos. Funciones de procesamiento de consultas se invocan a través de lenguajes orientados a los s y herramientas (a menudo referida como lenguajes de cuarta generación), que simplifican la definición de criterios y la búsqueda de ayuda en la creación de presentación eficaz de la información recuperada (incluyendo el uso de gráficos). Generación Screen funciones que proporcionan la capacidad de definir y generar pantallas que apoyan la recuperación, presentación y actualización de datos. Informe Generación funciones que proporcionan la capacidad de definir y generar informes impresos compuestos por los datos extraídos de una base de datos. Redes / simultáneo funciones que gestionan el de s simultáneos al sistema de gestión de bases de datos (DBMS) funciones. Almacenaje funciones que proporcionan la capacidad de almacenar grandes cantidades de datos - generalmente capturados de otros sistemas de bases de datos - y para realizar el procesamiento analítico en línea sobre el mismo en apoyo de ad hoc consultas.

43.5.3 Gráficos y Servicios de Imágenes

. Servicios Gráficos proporcionan funciones necesarias para crear, almacenar, recuperar y manipular imágenes Estos servicios incluyen: Gestión de objetos gráficos de servicios, incluyendo la definición de los objetos gráficos multidimensionales en una forma que es independiente de los dispositivos de salida, y la gestión de las estructuras jerárquicas que contienen datos de los gráficos. Formatos gráficos de datos incluyen dos y dibujos geométricos tridimensionales, así como imágenes. Dibujo servicios de apoyo a la creación y manipulación de imágenes con software como GKS, PEX, PHIGS o OpenGL.

Las siguientes áreas funcionales están soportados principalmente por el software de aplicación, pero están avanzando hacia la migración a la plataforma de aplicaciones: Imaging funciones que prevén la exploración, creación, edición, compresión y descompresión de imágenes de acuerdo con los estándares de formato de imagen reconocidos; por ejemplo, PIKS / IPI, OpenXIL o XIE.

43.5.4 Internacionales Servicios de Operación

Como práctica, los desarrolladores de sistemas de información tienen sistemas para satisfacer las necesidades de un segmento de mercado geográfico o lingüístico específico, Página 524 de 670


que puede ser una nación o de un mercado cultural particular diseñado y desarrollado en general. Para hacer que el sistema de información viable, o comercial, a un segmento diferente del mercado, por lo general se requiere un proceso de reingeniería completa. Los s u organizaciones que necesitan para operar en un entorno multi-nacional o multicultural típicamente hicieron lo mismo con varios sistemas de procesamiento de información en general, incompatibles. Operación Internacional proporciona un conjunto de servicios e interfaces que permiten a un definir, seleccionar y cambiar entre diferentes entornos de aplicaciones culturalmente relacionados con el apoyo de la aplicación particular. En general, estos servicios deben proporcionarse de tal manera que las cuestiones de internacionalización son transparentes a la lógica de la aplicación. Conjuntos de caracteres y representación de datos servicios incluyen la capacidad de introducir, almacenar, manipular, recuperar, comunicar y presentar datos de forma independiente del esquema de codificación utilizado. Esto incluye la capacidad de mantener y acceder a un repositorio central de juego de caracteres de todos los conjuntos de caracteres codificados que se usan a lo largo de la plataforma. Los conjuntos de caracteres se identifican de forma única para que el o la aplicación final puede seleccionar el conjunto de caracteres codificados para ser utilizado. Esta representación independiente del sistema soporta la transferencia (o compartir) de los valores y la sintaxis, pero no la semántica, de registros de datos entre sistemas de comunicación. Las especificaciones son independientes de los registros y campos representaciones internas de los sistemas de comunicación. También se incluye la capacidad de reconocer el conjunto de caracteres codificados de entidades de datos y, posteriormente, a la entrada, comunicar y presentar esos datos. Convenio Cultural servicios proporcionan la capacidad de almacenar y acceder a las reglas y convenciones para las entidades culturales que se mantienen en un repositorio convención cultural llamado un "locale". Locales deben estar disponibles para todas las aplicaciones. Locales suelen incluir la fecha y la moneda formatos, las secuencias de clasificación y formatos de número. Formatos estandarizados de localización y APIs permiten a las entidades de software que utilizan la información de localización desarrollado por otros. Asistencia de idiomas locales los servicios proporcionan la capacidad de soportar más de un idioma al mismo tiempo en un sistema. Mensajes, menús, formularios y documentación en línea se pueden visualizar en el idioma seleccionado por el . Las aportaciones de los teclados que se han modificado a nivel local para apoyar a los conjuntos de caracteres locales puede ser interpretada correctamente.

El buen funcionamiento de los servicios de operación internacionales depende de todas las entidades de software que participan tienen la capacidad de: Utilice locales Cambie entre locales según sea necesario Mantener varias configuraciones regionales activas

Página 525 de 670

The Open Group Architecture Framework TOGOF 9.1   a las fuentes adecuadas

Esto requiere que las entidades de software que se escriben en un estilo particular y en ser diseñado desde el principio con la internacionalización en mente. 43.5.5 Ubicación y Servicios de Directorio

Ubicación y directorio de servicios proporcionan apoyo especializado para la localización de los recursos necesarios y la mediación entre los consumidores de servicios y los proveedores de servicios. La World Wide Web, basada en Internet, ha creado la necesidad de localizar los recursos de información, que actualmente está satisfecho principalmente mediante el uso de motores de búsqueda. Los avances en la Internet global, y en los sistemas distribuidos heterogéneos, demandan una mediación activa a través de servicios de correduría que incluyen el registro automático y dinámico, al directorio, la comunicación de directorios, filtración, y servicios de contabilidad para el a los recursos. Directorio de servicios proporcionan los servicios para que los clientes establecen que los recursos son, y, por extensión, la forma en que se puede llegar. "Los clientes" pueden ser los seres humanos o los programas de ordenador, y "recursos" pueden ser una gran variedad de cosas, tales como nombres, direcciones de correo electrónico, los certificados de seguridad, impresoras, páginas web, etc Nomenclatura de Propósitos Especiales servicios proporcionan servicios que hagan referencia los nombres (cadenas ordenadas de caracteres imprimibles) a los objetos dentro de un contexto determinado (namespaces). Los objetos son normalmente organizados jerárquicamente dentro de los espacios de nombres. Ejemplos son: o Sistemas de archivos o las bases de datos de seguridad o colas de proceso Servicio de Localización de servicios proporcionan a "Páginas Amarillas" servicios en respuesta a las preguntas sobre la base de las limitaciones. Registro de servicios proporcionan servicios para registrar la identidad, la descripción de los servicios de un recurso está proporcionando y descripciones de los medios para acceder a ellos. Filtrado de servicios proporcionan servicios para seleccionar información útil de datos utilizando criterios definidos. Contabilidad servicios proporcionan servicios como cuenta abierta, actualización de cuenta, saldo de la cuenta, cuenta detalle, cierre contable, descuentos, recuento proyecto cuenta / uso, la cuenta del acuerdo de pago basado en el tráfico de mensajes, y / o el tiempo de conexión y / o utilización de los recursos, y / o específicos de agente (por ejemplo, basado en el valor).

Página 526 de 670

The Open Group Architecture Framework TOGOF 9.1   Servicios de red 43.5.6

Los servicios de red se proporcionan para soportar aplicaciones distribuidas que requieren a datos y aplicaciones de la interoperabilidad en entornos de red heterogéneos u homogéneos. Un servicio de red consiste tanto una interfaz y un protocolo subyacente. Comunicaciones de datos , que incluyen las interfaces y protocolos para la transmisión de datos fiable, transparente de extremo a extremo a través de redes de comunicaciones. Servicios de comunicaciones de datos incluyen tanto las funciones de alto nivel (tales como transferencia de archivos, remoto, ejecución de procesos a distancia, o los servicios de integración de PC) y funciones de bajo nivel (como un API de sockets) que da directo a los protocolos de comunicación. El correo electrónico servicios incluyen la capacidad de enviar, recibir, reenviar, almacenar, visualizar, recuperar, priorizar, autenticar y gestionar los mensajes.Esto incluye la capacidad para anexar archivos y documentos a los mensajes. Los mensajes pueden incluir cualquier combinación de datos, texto, audio, gráficos e imágenes, y deben ser capaces de ser formateado en formatos de intercambio de datos estándar. Este servicio incluye el uso de directorios y listas de distribución de información de enrutamiento, la capacidad de asignar prioridades, el uso de los formularios electrónicos con formato previo, y la capacidad de seguir el estado de los mensajes. Servicios asociados incluyen una lista resumida de los mensajes entrantes, un registro de los mensajes recibidos y leer, la posibilidad de presentar o mensajes de impresión, y la capacidad de responder o reenviar mensajes. Datos Distribuidos servicios proporcionan a, y la modificación de los datos / metadatos en las bases de datos locales o remotos. En un entorno distribuido, los datos no disponibles en la base de datos local es descabellada desde un servidor de datos a distancia, a petición del cliente local. Distribuidos de archivos servicios proporcionan para el remoto a archivos transparente. Las aplicaciones tienen un equivalente a los datos independientemente de la ubicación física de los datos. Servicios auxiliares para esta función pueden incluir direcciones, datos transparentes en caché, replicación de datos, bloqueo de archivos y el registro de archivos. Nombre Distribuidos servicios proporcionan un medio para la identificación única de los recursos dentro de un sistema de computación distribuida. Estos servicios están disponibles para aplicaciones dentro de la red y proporciona información que puede incluir el nombre de los recursos, atributos asociados, la ubicación física y la funcionalidad de los recursos. Tenga en cuenta que todos los recursos del sistema deben ser identificables, en todos los sistemas de información, por el nombre distribuida. Esto permite que la ubicación física de cambiar, no sólo para acomodar el movimiento, sino también equilibrio de carga, la utilización del sistema, la ampliación (añadiendo procesadores y moviendo los recursos para acomodar el aumento de recursos), procesamiento distribuido, y todos los aspectos de los sistemas abiertos. Servicios de nombres distribuidas incluyen los servicios de directorio, como los servicios X.500 y de navegación de la red. Servicios de nombres distribuidas incluyen maneras de localizar objetos de datos tanto por nombre como por su función. 43.5.13 orientada a objetos Prestación de Servicios describe los servicios equivalentes al amparo de los servicios de nomenclatura y Servicios comerciales, respectivamente.

Página 527 de 670

The Open Group Architecture Framework TOGOF 9.1   Tiempo Distribuidos proveen servicios de tiempo sincronizado coordinación tan necesaria entre procesos distribuidos en diferentes zonas horarias. Un servicio equivalente se describe en Servicios de Tiempo en 43.5.13 orientada a objetos Prestación de Servicios . Proceso Remoto () los servicios proporcionan los medios para aplicaciones dispersas para comunicarse a través de una red informática. Estos servicios facilitan las comunicaciones de programa a programa, independientemente de su naturaleza distribuida o una operación en plataformas heterogéneas. Servicios de procesos a distancia, incluyendo la llamada a procedimiento remoto (RPC) y los mecanismos de mensajería asíncrona sustentan aplicaciones cliente / servidor. Cola de impresión remota y Distribución de salida servicios proporcionan los medios para la impresión de producción de forma remota. Los servicios incluyen la gestión de la impresión remota incluyendo impresora y selección de medios, el uso de las formas, la seguridad y la gestión de colas de impresión.

Las siguientes áreas funcionales están soportados principalmente por el software de aplicación, pero están avanzando hacia la migración a la plataforma de aplicaciones: Telefonía mejoradas funciones, incluyendo el establecimiento de llamada, llaman la coordinación, desvío de llamadas, llamada en espera, directorios programadas, las teleconferencias, distribución automática de llamadas (útil para los ocupados categorías de servicio al cliente), y la grabación de llamadas detalle. Pantalla compartida funciones que proporcionan las teleconferencias de audio con ventanas de estaciones de trabajo comunes entre dos o más s. Esto incluye la capacidad para actualizar ventanas cada vez que alguien muestra nuevo material o cambia una batería existente. Cada dispone de la capacidad para anotar de forma gráfica o modificar la ventana de conferencia compartida. Video-conferencia funciones que proporcionan la transmisión de video de dos vías entre los diferentes sitios. Estas funciones incluyen establecimiento de llamada, llame a la coordinación, la pantalla de movimiento completo de eventos y participantes de una manera bidireccional, el apoyo a la gestión de la dirección de las cámaras, que van desde la posición fija, al remitente dirigido, dirigido al receptor, al sonido automatizado recogida. Broadcast funciones que proporcionan un solo sentido funciones de audio o las comunicaciones de audio / vídeo entre una ubicación y envío de múltiples emplazamientos de recepción o entre múltiples enviar y recibir ubicaciones. Listas de Correo de funciones que permiten a los grupos a participar en las conferencias. Estas conferencias pueden o no ocurrir en tiempo real. Los conferenciantes o invitados pueden caer dentro o fuera de las conferencias o subconferencias a voluntad. Se proporciona la capacidad de rastrear los intercambios.Las funciones incluyen el intercambio de documentos, gestión de conferencias, instalaciones de grabación, y la búsqueda y la capacidad de recuperación.

43.5.7 servicios del sistema operativo

Servicios del sistema operativo son los responsables de la gestión de los recursos de la plataforma, incluyendo el procesador, la memoria, los archivos, y la entrada y salida. . Por Página 528 de 670


lo general protegen las aplicaciones de los detalles de implementación de la máquina de los servicios del sistema operativo se incluyen: Operaciones del núcleo proporcionan servicios de bajo nivel necesarias para: o Creación y gestión de los procesos y subprocesos de ejecución o Ejecutar programas o Definir y comunicar eventos asíncronos o Definir y operaciones del reloj del sistema proceso o Implementar las funciones de seguridad o Gestión de archivos y directorios o Entrada de control / procesamiento de salida hacia y desde los dispositivos periféricos

Algunos servicios del núcleo tienen análogos descritos en 43.5.13 orientada a objetos Prestación de Servicios , como los servicios de control de concurrencia. Intérprete de comandos y utilitarios servicios incluyen mecanismos de servicios a nivel de operador, tales como: o contenidos Comparando, impresión y archivos que muestran o Edición de archivos o patrones de búsqueda o expresiones Evaluación o Los mensajes de registro o mover archivos entre directorios o Ordenación de datos o Ejecución de scripts de comandos o cola de impresión local o Los procesos de ejecución de señal de programación o a la información del entorno El procesamiento por lotes los servicios de apoyo a la capacidad de la cola de trabajo (puestos de trabajo) y gestionar la secuencia de procesamiento basado en comandos de control de trabajo y listas de datos. Estos servicios también incluyen el apoyo a la gestión de la salida de procesamiento por lotes, lo que con frecuencia incluye archivos actualizados o bases de datos y productos de información tales como informes impresos o

Página 529 de 670

The Open Group Architecture Framework TOGOF 9.1   documentos electrónicos. El procesamiento por lotes se realiza de forma asíncrona desde el que solicita el trabajo. De archivos y sincronización de directorios servicios permiten copias locales y remotas de los archivos y directorios que se hagan idénticos. Los servicios de sincronización normalmente se utilizan para actualizar los archivos después de períodos de trabajo sin conexión en un sistema portátil.

43.5.8 Software Engineering Services

El aspecto funcional de una aplicación se materializa en los lenguajes de programación utilizados para codificarlo. Además, los desarrolladores de sistemas profesionales requieren herramientas adecuadas para el desarrollo y mantenimiento de aplicaciones. Estas capacidades son proporcionados por los servicios de ingeniería de software, las cuales incluyen: Lenguaje de programación de servicios proporcionan la sintaxis básica y definición semántica para su uso por un desarrollador de software para describir la función del software de aplicación deseada. Shell y servicios lingüísticos ejecutivo de guión permiten el uso de los comandos del sistema operativo o de los servicios públicos en lugar de un lenguaje de programación. Shells y scripts ejecutivos suelen ser interpretados en lugar de compilarse, pero los compiladores de apoyo algunos sistemas operativos para los scripts de ejecutivos. Por el contrario, algunos compiladores producen código para ser interpretado en tiempo de ejecución.Otras herramientas de este grupo incluyen formateadores de código fuente y los compiladores del compilador. Código Object Linking servicios proporcionan la capacidad de los programas para acceder a la aplicación y el sistema operativo de la plataforma subyacente a través de las API que se han definido de forma independiente del lenguaje de programación. Es utilizado por los programadores para acceder a estos servicios utilizando métodos compatibles con el sistema operativo y el idioma específico usado. La unión se dependiendo del sistema operativo, pero independiente del lenguaje. Computer-Aided Software Engineering (CASE) Medio ambiente y Herramientas servicios incluyen sistemas y programas que ayudan en el desarrollo automatizado y mantenimiento de software. Estos incluyen, pero no están limitados a, herramientas para la especificación de requisitos y análisis, para el trabajo de diseño y análisis, para crear, editar, probar, y el código de programa de depuración, para documentar, para la creación de prototipos, y para la comunicación de grupo. Las interfaces entre estas herramientas incluyen servicios para almacenar y recuperar información acerca de los sistemas y el intercambio de esta información entre los diversos componentes del sistema de entorno de desarrollo. Un complemento de estas capacidades es la capacidad de gestionar y controlar la configuración de los componentes de software, los datos de prueba, y las bibliotecas para registrar los cambios en el código fuente o para acceder a los repositorios CASE. Otras herramientas de idioma incluyen generadores de código y traductores, herramientas de inteligencia artificial, y herramientas como el comando del sistema UNIX make , que utiliza el conocimiento de las interdependencias entre los módulos de recompilar y enlazar los sólo aquellas partes de un programa que han cambiado. Interfaz gráfica de (GUI) de construcción servicios de ayuda en el desarrollo de la Interfaz Hombre-Computadora (HCI) elementos de las aplicaciones.Las herramientas

Página 530 de 670

The Open Group Architecture Framework TOGOF 9.1   incluyen servicios para la generación y la captura de los diseños de pantalla, y para definir la apariencia, la función, el comportamiento, y la posición de los objetos gráficos. Scripting Language servicios proporcionan los lenguajes interpretados que permiten al llevar a cabo alguna función complicada de un modo simple. Las áreas de aplicación servidos por lenguajes de scripting de propósito especial incluyen cálculo, desarrollo de la interfaz gráfica de , y el desarrollo de prototipos de aplicaciones. Binding Language servicios proporcionan asignaciones de las interfaces proporcionadas por los lenguajes de programación en los servicios prestados por la plataforma de aplicaciones. En muchos casos, el mapeo es sencillo ya que la plataforma suministra servicios análogos a los esperados por la aplicación. En otros casos, el servicio de enlace lenguaje debe utilizar una combinación de los servicios de la plataforma de aplicaciones para proporcionar una cartografía totalmente funcional. Medio ambiente en tiempo de ejecución de servicios proporcionan soporte para el software de aplicación en tiempo de ejecución. Este soporte incluye la localización y la conexión de bibliotecas de enlace dinámico, o incluso de emulación de un entorno operativo diferente a la que realmente existe. Interfaz de aplicación binaria servicios proporcionan servicios que hacen que la plataforma de aplicaciones de cumplir con los estándares de interfaz binaria de aplicación definidos.

Servicios de Procesamiento de Transacciones 43.5.9

Servicios de procesamiento de transacciones (TP) proporcionan soporte para el procesamiento en línea de información en unidades discretas llamadas "transacciones", con la garantía del estado de la información al final de la transacción. Normalmente, esto implica secuencias predeterminadas de entrada de datos, la validación, la pantalla y la actualización o la investigación en contra de un archivo o base de datos. También incluye los servicios para priorizar y rastrear transacciones.Servicios de TP pueden incluir el apoyo a la distribución de las transacciones a una combinación de los procesadores locales y remotos. Una transacción es una unidad completa de trabajo. Se puede comprender muchas tareas de cálculo, que puede incluir interfaz de , de recuperación de datos, y comunicaciones. Una típica transacción modifica los recursos compartidos. Las transacciones también deben ser capaces de ser revertido (es decir, sin hacer) si es necesario, en cualquier etapa. Cuando una transacción se ha completado sin fallos, se ha comprometido. Finalización de una transacción significa cualquiera de compromiso o retrotracción. Normalmente, un servicio de TP contendrá un gestor de transacciones, que une la entrada de datos y de software de visualización con el procesamiento, la base de datos, y otros recursos para formar el servicio completo.

Página 531 de 670


La suma de todo el trabajo realizado en cualquier parte del sistema en el transcurso de una sola transacción se llama una "transacción global." Las transacciones no se limitan a una sola plataforma de aplicaciones. Gestor de transacciones . servicios, que permiten a una aplicación demarcar transacciones, y dirigir su realización los servicios del gestor de transacciones incluyen: o Inicio de una transacción o Coordinación de recursos recuperables que intervienen en una transacción o Confirmación o retrotracción de transacciones o Control de los tiempos de espera en las transacciones o Encadenamiento de transacciones, conjuntamente, o situación de la operación de Monitoreo

Algunos servicios de gestor de transacciones tienen equivalentes descritos en 43.5.13 orientada a objetos Prestación de Servicios , bajo Servicios de transacción. 43.5.10 Servicios al de la interfaz

Servicios de interfaz de definen cómo los s pueden interactuar con una aplicación. Dependiendo de las capacidades requeridas por los s y las aplicaciones, estas interfaces pueden incluir los siguientes: Gráficos de cliente / servidor de servicios que definen las relaciones entre cliente y servidor los procesos operativos de interfaz gráfica de muestra, por lo general dentro de una red. En este caso, el programa que controla cada unidad de visualización es un proceso de servidor, mientras que los programas de independientes son procesos clientes que solicitan servicios de visualización del servidor. Display Objetos servicios que definen las características de los elementos de visualización, tales como color, forma, tamaño, movimiento, contexto gráfico, las preferencias del , la gestión de la fuente, y las interacciones entre los elementos de la pantalla. Gestión Ventana servicios que definan cómo deben ventanas creadas, mover, almacenar, recuperar, eliminar, y relacionados entre sí. Soporte de diálogo servicios se traducen los datos introducidos para la exhibición a la que en realidad se muestra en la pantalla (por ejemplo, los movimientos del cursor, la entrada de datos del teclado, y los dispositivos de entrada de datos externos). Impresión de salida de soporte de servicios de texto y / o los datos gráficos, incluyendo cualquier filtración o la conversión del formato necesario. Servicios de impresión pueden incluir la capacidad de imprimir todo o parte de un documento, imprimir y compaginar más de una copia, para seleccionar el tamaño y la orientación de la producción, para elegir la

Página 532 de 670

The Open Group Architecture Framework TOGOF 9.1   resolución de impresión, los colores, y el comportamiento gráfico, y para especificar las fuentes y otros características. Entrenamiento y Ayuda Online Computer-Based servicios proporcionan un entorno de formación integrada en estaciones de trabajo de . La formación está disponible en una base como-necesaria para cualquier aplicación disponible en el entorno. Los mensajes electrónicos se proporcionan en el golpe de una tecla desde cualquier lugar dentro de la aplicación. Esto incluye la formación tutorial sobre la aplicación en el uso y la disponibilidad de conexión, capacitación interactiva en el sitio. Carácter-Basado servicios, que tienen que ver con el apoyo a los terminales no gráficas. Servicios basados en caracteres incluyen soporte para terminal de control de tipo independiente de atributos de visualización, movimientos del cursor, teclas programables, señales acústicas, y otras funciones.

Los servicios asociados a un sistema de ventanas incluyen la presentación visual de la información en una pantalla que contiene una o más ventanas o es, el apoyo a señalar a un objeto en la pantalla mediante un dispositivo señalador como un ratón o pantalla táctil, y la manipulación de un conjunto de objetos en la pantalla a través del dispositivo de señalización oa través de la entrada de teclado. Otras interfaces de que se incluyen son los controles industriales y dispositivos de realidad virtual. 43.5.11 Servicios de Seguridad

Los servicios de seguridad son necesarias para proteger la información sensible en el sistema de información. El nivel adecuado de protección se determina en base al valor de la información a los s finales de la zona de negocios y de la percepción de las amenazas a la misma. Para ser eficaz, la seguridad debe hacerse fuerte, nunca debe darse por sentado, y debe ser diseñado en una arquitectura y no agregada después. Si un sistema es independiente o distribuido, la seguridad debe ser aplicado a todo el sistema. No hay que olvidar que la exigencia de la seguridad se extiende no sólo a través de la gama de entidades de un sistema, sino también a través del tiempo. En el establecimiento de una fianza . arquitectura, el mejor enfoque es considerar qué se está defendiendo, ¿qué valor tiene, y cuáles son las amenazas a que son las principales amenazas que deben contrarrestarse son: La pérdida de la confidencialidad de los datos Falta de disponibilidad de datos o servicios La pérdida de integridad de los datos El uso no autorizado de los recursos

Contadores a estas amenazas son proporcionados por los siguientes servicios: Página 533 de 670

The Open Group Architecture Framework TOGOF 9.1   Identificación y autenticación de los servicios ofrecen: o Identificación, rendición de cuentas y auditoría de los s y sus acciones o Los datos de autenticación y de cuentas o Protección de datos de autenticación o información del estado de de Active o Los mecanismos de autenticación Contraseña Control de Sistema de Entrada servicios ofrecen: o advertencia a los s no autorizados de que el sistema es consciente de la seguridad o Autenticación de s o de la Información, aparece en la entrada, a unos exitosos y no exitosos intentos de conexión anteriores o bloqueo iniciado por el de una sesión de prevenir aún más el hasta que el se ha autenticado re- Auditoría servicios ofrecen un control autorizado y la protección de la pista de auditoría, el registro de información de eventos relevantes para la seguridad detalladas, y control de seguimiento de auditoría, la gestión y la inspección. Control de proporcionan servicios: o los atributos de control de para los sujetos (tales como procesos) y objetos (como archivos) o La aplicación de normas para la asignación y modificación de atributos de control de o Ejecución de los controles de o de control de la creación y eliminación de objeto, incluso asegurando que la reutilización de objetos no permite sujetos para obtener accidentalmente el a la información preexistente en el objeto

Servicios de control de también aparecen bajo los servicios de seguridad en 43.5.13 orientada a objetos Prestación de Servicios . No repudio servicios proporcionan la prueba de que un realiza una acción, o enviar o recibir información, en un momento determinado. Servicios de no repudio también aparecen bajo los servicios de seguridad en 43.5.13 orientada a objetos Prestación de Servicios . Gestión de Seguridad de servicios proporcionan seguro sistema de configuración e inicialización, el control de los parámetros de la política de seguridad, la gestión de los

Página 534 de 670

The Open Group Architecture Framework TOGOF 9.1   datos de registro del , y los recursos del sistema y las restricciones en el uso de las funciones istrativas. Recuperación de confianza los servicios proporcionan instalaciones de recuperación como la restauración de las copias de seguridad de forma que no comprometan la protección de seguridad. Cifrado servicios proporcionan formas de codificación de datos de tal manera que sólo puede ser leído por alguien que posee una tecla apropiada, o alguna otra pieza de información secreta. Además de proporcionar confidencialidad de los datos para la comunicación de confianza, los servicios de cifrado se utilizan para sustentar muchos otros servicios, como la identificación y autenticación, control de entrada del sistema, y los servicios de control de . Comunicación Trusted servicios ofrecen: o Una forma segura para la comunicación partidos para autenticarse entre sí, sin el riesgo de un espía, posteriormente, haciéndose pasar por una de las partes o Una forma segura de generar y verificar los valores de comprobación de integridad de los datos o cifrado y descifrado de la confidencialidad y otros fines de Datos o una manera de producir un hash irreversible de los datos para el apoyo de las funciones de firma digital y el no repudio o Generación, derivación, distribución, almacenamiento, recuperación y eliminación de claves criptográficas

Los servicios de seguridad requieren otras entidades de software para cooperar en: Control de para los recursos gestionados por la entidad Contabilidad y auditoría de los eventos relevantes para la seguridad La importación y exportación de datos Potencialmente todos los otros servicios de seguridad, según el enfoque de implementación particular

Los servicios de seguridad son una categoría en la que una amplia vista es particularmente importante, ya que una cadena es tan fuerte como su eslabón más débil.Esta es una categoría de servicios cuando el ambiente externo tiene implicaciones críticas en la plataforma de aplicaciones. Por ejemplo, la presencia de un servidor de seguridad puede proporcionar un único punto de a una red del mundo exterior, por lo que es posible concentrar el control de en un lugar y relajar los requisitos de detrás del firewall.

Página 535 de 670

The Open Group Architecture Framework TOGOF 9.1   43.5.12 Sistema y los Servicios de Gestión de Red

Los sistemas de información están compuestos por una gran variedad de diversos recursos que se debe manejar de manera efectiva a la consecución de los objetivos de un entorno de sistema abierto. Mientras que los recursos individuales (por ejemplo, impresoras, software, s, procesadores) pueden ser muy diferentes, la abstracción de estos recursos como objetos istrados permite el tratamiento de una manera uniforme. Los conceptos básicos de la gestión - incluyendo la operación, istración y mantenimiento - pueden entonces aplicar a todo el conjunto de componentes del sistema de información junto con sus servicios de ayudante. Sistema y funcionalidad de gestión de red se pueden dividir en varias maneras diferentes; Una forma es hacer una división de acuerdo a los elementos de gestión que genéricamente se aplican a todos los recursos funcionales. Esta división reduce como sigue: Gestión de s de servicios ofrecen la posibilidad de mantener las preferencias y privilegios de un . Gestión de la Configuración (CM) los servicios de dirección de cuatro funciones básicas: o Identificación y especificación de todos los recursos del componente o de control, o la capacidad de congelar los elementos de configuración, el cambio sólo a través de procesos acordados o la contabilidad de estado de cada elemento de configuración o Verificación a través de una serie de revisiones para asegurar la conformidad entre el elemento de configuración actual y la información registrada sobre él

Estos servicios incluyen: Procesador CM, CM Red, Sistema Distribuido de CM, CM Topología y Aplicación CM. Procesador CM toma un enfoque de plataforma centrada. Servicios de CM Red y Sistema Distribuido de CM permiten a los sistemas remotos a ser gestionados y controlados incluyendo el intercambio de estado de la red. Topología de CM se utiliza para controlar la topología de las entidades físicas o lógicas que se distribuyen. CM aplicación se centra en las aplicaciones. Gestión de la configuración aparece también como servicios de gestión del cambio en 43.5.13 orientada a objetos Prestación de Servicios . Gestión del rendimiento de servicios monitorean aspectos de rendimiento de hardware, la plataforma y el software de aplicación, y los componentes de red y proporcionar maneras de ajustar el sistema para cumplir con los objetivos de rendimiento. Disponibilidad y gestión de fallos servicios permiten un sistema para reaccionar ante la pérdida o el funcionamiento incorrecto de los componentes del sistema, incluyendo hardware, software de plataforma y software de aplicación. Gestión Contable servicios proporcionan la capacidad de gastos de los servicios para la carga y el reembolso.

Página 536 de 670

The Open Group Architecture Framework TOGOF 9.1   Gestión de Seguridad de los servicios de control de los servicios de seguridad de acuerdo con las políticas de seguridad aplicables. istración de impresión servicios ofrecen la posibilidad de gestionar los servicios de cola de impresión, tanto locales como remotos. istración de red de servicios comprenden elementos de todos los servicios descritos anteriormente, pero a menudo se tratan como un servicio separado. Copia de seguridad y restauración de servicios proporcionan una instalación de almacenamiento multi-nivel para garantizar la seguridad continua de datos en caso de fallo de un componente o subsistema. Online istración de discos servicios gestionar la utilización del almacenamiento en disco frente a los valores de umbral e invocan una acción correctiva. istración de licencias de servicios de apoyo a la aplicación efectiva de los acuerdos de licencia de software. Servicios de cesión de objetos se describen en la sección de Licencias de servicios en 43.5.13 orientada a objetos Prestación de Servicios . Gestión de Capacidad servicios abordan tres funciones básicas: o en curso de análisis de gestión de la capacidad y el desempeño histórico y la capacidad o gestión de carga de trabajo para identificar y comprender las aplicaciones que utilizan el sistema o Planificación de la capacidad para planificar los recursos de hardware necesarios para el futuro Instalación de software de distribución de servicios de apoyo, la instalación, retirada, traslado, la activación y actualización automática de software o paquetes de datos desde medios transportables o a través de redes. Servicios similares para los objetos se describen en los servicios de instalación y activación en 43.5.13 orientada a objetos Prestación de Servicios .

Las siguientes áreas funcionales están soportados principalmente por el software de aplicación, pero están avanzando hacia la migración a la plataforma de aplicaciones: Trouble Ticketing servicios de apoyo a la generación, procesamiento y seguimiento de los informes de problemas. Problemas de venta de entradas es un término de origen en el mundo de las telecomunicaciones, en referencia a la capacidad de pasar informes de faltas tanto dentro como entre los proveedores de servicios de telecomunicaciones. En este entorno, las fallas se encuentran a menudo por un cliente de un proveedor, mientras que la causa del problema se encuentra en el dominio istrativo de otro proveedor. Venta de entradas El problema es que un servicio común que puede ser útil para una gama creciente de aplicaciones si el trabajo se hace necesario hacer que descienda de las telecomunicaciones en las zonas más amplias de aplicaciones distribuidas, tales como el correo electrónico.

Página 537 de 670


Esta ruptura de los servicios del sistema y gestión de la red es paralela a la ruptura de las nuevas de gestión de red OSI, lo cual representa un marco global coherente que se aplica por igual a las redes integrales y los nodos individuales de las redes. Una consideración importante de las normas de apoyo a los servicios de esta categoría es que no deben hacer cumplir las políticas de gestión específicas, sino más bien permitir que una amplia variedad de diferentes políticas de gestión a implementar, seleccionados de acuerdo con las necesidades particulares de las instalaciones del final. Servicios de gestión del sistema y de red necesitan la cooperación de otras entidades de software en: Proporcionar información sobre el estado Eventos notificantes En respuesta a las instrucciones de manejo

43.5.13 orientada a objetos Prestación de Servicios

En esta sección se muestra cómo se prestan los servicios de una manera orientada a objetos. "Servicios de objeto" no aparece como una categoría en el modelo de referencia técnica (TRM), ya que todos los servicios de objetos individuales se incorporan en su caso, en las categorías de servicios dados. Un objeto es una entidad identificable, encapsulado que proporciona uno o más servicios que pueden ser solicitadas por un cliente. Los clientes solicitan un servicio invocando el método apropiado asociado con el objeto, y el objeto lleva a cabo el servicio en nombre del cliente. Los objetos proporcionan un paradigma de programación que puede conducir a importantes beneficios, entre ellos: El aumento de la modularidad Una reducción en los errores Facilidad de depuración

Servicios de gestión de objetos proporcionan formas de crear, localizar y nombrar a los objetos, y que les permite comunicarse en un entorno distribuido. El conjunto completo de servicios de objetos identificados hasta ahora se enumeran a continuación en aras de la exhaustividad. . Cuando un servicio objeto en particular es parte de una categoría de servicio de aplicación más general, se le da un puntero a la otra categoría de servicio objeto servicios incluyen: Object Request Broker (ORB) . servicios, que permiten a los objetos para hacer y recibir las solicitudes y respuestas en un entorno distribuido de forma transparente los servicios ORB incluyen:

Página 538 de 670

The Open Group Architecture Framework TOGOF 9.1   o Implementación del repositorio servicios apoyan la ubicación y la gestión de implementaciones de objetos. Los servicios se asemejan a las que proporciona el diccionario de datos / servicios de repositorio en 43.5.2 Servicios de istración de datos . o Instalación y activación de servicios proporcionan formas de distribuir, instalar, activar y mover los objetos. Esto corresponde a los Servicios de instalación de software en 43.5.12 Sistema y Servicios de gestión de red . o Interface Repository servicios apoyan el almacenamiento y gestión de la información acerca de las interfaces a los objetos. Los servicios se asemejan a las que proporciona el diccionario de datos / servicios de repositorio en 43.5.2 Servicios de istración de datos . o replicación de replicación de servicios de soporte de objetos en sistemas distribuidos, incluyendo la gestión de la coherencia entre las copias. Objeto común de servicios, que proporcionan funciones básicas para el uso y aplicación de objetos. . Estos son los servicios necesarios para construir cualquier aplicación distribuida por objeto servicios comunes incluyen: o Gestión del Cambio servicios proporcionan para identificación de la versión y la configuración de interfaces de objetos, implementaciones y casos. Esto corresponde a los servicios de istración de configuración que se describen en 43.5.12 Sistema y Servicios de gestión de red . o Colecciones servicios proporcionan operaciones sobre colecciones de objetos, como listas, árboles, pilas, o colas. Los servicios incluyen el establecimiento, la adición de objetos, o sacarlos de las colecciones, poniendo a prueba la pertenencia establecido, formando uniones e intersecciones de conjuntos, y así sucesivamente. o el control de concurrencia servicios permiten a varios clientes para coordinar su a los recursos compartidos. Sincronización como éste se proporciona normalmente con los servicios prestados en Kernel 43.5.7 servicios del sistema operativo . o Data Interchange servicios apoyan el intercambio de información visible estado entre los objetos. Dependiendo del tipo de objeto implicado, esto corresponde a una o más de los servicios prestados en 43.5.1 Data Interchange Services . o Gestión de eventos servicios proporcionan capacidades básicas para la gestión de eventos, incluyendo eventos asíncronos, evento "fan-in", la notificación de "fanout", y entrega de eventos confiable. o Externalización de servicios definen los protocolos y convenciones para la externalización y la internalización de los objetos. Medios de grabación el estado del objeto en una corriente de datos de externalización, y medios de internalización recrear un estado del objeto a partir de un flujo de datos. Este es un ejemplo de la Presentación de la Información y las funciones de distribución en 43.5.1 Servicios de datos de intercambio .

Página 539 de 670

The Open Group Architecture Framework TOGOF 9.1   o licencias de políticas de apoyo a los servicios para la concesión de licencias de objetos y medición y tarificación por el uso de objetos. Esto corresponde a los servicios de gestión de licencias en 43.5.12 Sistema y Servicios de gestión de red . o Ciclo de Vida de los servicios definen las convenciones para crear, eliminar, copiar y mover objetos. La creación de objetos se define en términos de los objetos de la fábrica, que son objetos que crean otros objetos. o Asignación de nombres a los servicios proporcionan la capacidad de unirse a un nombre a un objeto, y para localizar un objeto por su nombre. Esto es análogo al servicio Nombre Distribuida descrito en 43.5.6 Servicios de red . o de objetos persistentes servicios proporcionan interfaces comunes para retener y gestionar el estado persistente de los objetos. Objetos menudo se almacenan en un SGBDOO, describen como uno de los servicios de gestión de datos 43.5.2 . o Propiedades de los servicios de apoyo a la creación, supresión, misiones, y la protección de las propiedades dinámicas asociadas con los objetos. o Consulta de los servicios de soporte de indexación y las operaciones de consulta de las colecciones de objetos que devuelven un subconjunto de la colección. Esto es similar a la base de datos de consulta, una parte de las funciones de DBMS en Servicios de Gestión de Datos 43.5.2 . o Relación servicios permiten relaciones entre los objetos (tales como la propiedad o de contención) que se representan explícitamente como objetos. o de seguridad de control de de servicios de apoyo en los objetos y no repudio de las operaciones sobre los objetos. El control de se define como un servicio de seguridad (ver 43.5.11 Servicios de Seguridad ). No repudio, que es también un servicio de seguridad, proporciona la prueba de que una acción se llevó a cabo por un particular en un momento particular. o de puesta en marcha de servicios de apoyo automático de inicio y terminación de los servicios objeto de ORB puesta en marcha o terminación. o Tiempo de sincronización de servicios de apoyo de los relojes en un sistema distribuido. Esto es lo mismo que el servicio de hora Distribuido en 43.5.6 Servicios de red . o de comercio de servicios permiten a los clientes a localizar los objetos por los servicios de los objetos proporcionan, en lugar de por su nombre. Esto es similar a la de servicio de nombres distribuido en 43.5.6 Servicios de red . o transacciones de servicios proporcionan facilidades para agrupar operaciones en unidades atómicas, llamado "transacciones", con la certeza de que una transacción se llevará a cabo en su totalidad o en absoluto. Esto corresponde a algunos de los servicios del gestor de transacciones de Servicios de Procesamiento de Transacciones 43.5.9 .

   Página 540 de 670




Página 541 de 670




44. Integrado de Información de Referencia Infraestructura Modelo En este capítulo se describe la información integrada de referencia Infraestructura Modelo (III-RM), en términos de sus conceptos, una visión general, y la taxonomía.

44.1 Conceptos básicos Esta sección trata de los conceptos básicos de la III-RM, incluyendo antecedentes, componentes y conductores. 44.1.1 Antecedentes

Con la aparición de las tecnologías basadas en Internet en los últimos años, para muchas organizaciones el principal foco de atención, y el circuito de retorno de la inversión en la arquitectura esfuerzo, se ha desplazado desde el espacio de la plataforma de aplicaciones para el espacio de software de aplicación. (De hecho, este ha sido uno de los factores que impulsan la migración de sí TOGAF de un marco y un método para la Tecnología de la Arquitectura a uno para la arquitectura global de la empresa.) El Modelo de Referencia Técnica TOGAF (TRM) se describe en el 43. Fundación Arquitectura: Modelo de referencia técnica se centra en el espacio de la plataforma de aplicaciones. En esta sección se describe un modelo de referencia que se centra en el software de aplicación espacial, y "Sistemas Comunes de Arquitectura" en términos de Enterprise Continuum. Este es el Integrado de Información de Referencia Infraestructura Modelo (IIIRM). El III-RM es un subconjunto de la TOGAF TRM en términos de su alcance general, sino que también se expande ciertas partes de la TRM - en particular, las aplicaciones de negocio y aplicaciones de infraestructura partes - con el fin de proporcionar ayuda para hacer frente a una de las claves desafíos que enfrenta el arquitecto empresarial de hoy: la necesidad de diseñar una infraestructura de información integrada para permitir sin fronteras flujo de información. Estos conceptos se explican en detalle a continuación. Esta sección introductoria examina el concepto de flujo de información sin fronteras; ¿por qué es necesaria una infraestructura de información integrada que le permita;y cómo el IIIRM puede ayudar al arquitecto en el diseño de una infraestructura de información integrada para su empresa.

Página 542 de 670

The Open Group Architecture Framework TOGOF 9.1   44.1.2 componentes del modelo

Al igual que el TOGAF TRM, el III-RM tiene dos componentes principales: 1. Una taxonomía , que define la terminología, y proporciona una descripción coherente de los componentes y la estructura conceptual de una infraestructura de información integrada

2. Un asociado gráfico III-RM , que proporciona una representación visual de la taxonomía, y la interrelación de los componentes, como una ayuda para la comprensión

El modelo supone la existencia subyacente de una plataforma de computación y la red, como se describe en la TRM; estos no se representan en el modelo. 44.1.3 Relación con otras partes de TOGAF

La relación de la III-RM a la TRM se explica más arriba. Aunque el III-RM se pretende ser una herramienta útil en la ejecución de la Arquitectura Método de Desarrollo de TOGAF (), es importante destacar que la es de ninguna manera depende del uso de la RM-III (más de lo que es depende del uso de la TRM). Existen otras taxonomías y modelos de referencia en este espacio que se puede utilizar en conjunción con el , y de hecho pueden ser preferibles para algunas organizaciones. Drivers 44.1.4 clave de negocio y técnicos 44.1.4.1 problema de espacio: la necesidad de flujo de información sin fronteras

El problema de espacio sin fronteras de flujo de información es uno que es compartido por muchos de los de los clientes de The Open Group, y por muchas otras organizaciones similares en todo el mundo. Es esencialmente el problema de la obtención de información a las personas adecuadas en el momento adecuado de una manera segura y fiable, con el fin de apoyar las operaciones que son fundamentales para la empresa extendida. En General Electric, Jack Welch inventó el término "la Organización sin fronteras", no quiere decir que no hay límites, pero que deben hacerse permeable. La creación de estructuras organizativas que permitieron a cada departamento para operar con la máxima eficiencia fue durante mucho tiempo aceptado como el mejor enfoque para la gestión de una gran empresa. Entre otros beneficios, este enfoque fomenta el desarrollo de conocimientos especializados en el personal, que se podrían aplicar esas habilidades a aspectos específicos de una actividad general (como un proceso de fabricación), con el fin de cumplir las tareas implicadas mejor, más rápido y más barato. Página 543 de 670


A medida que cada actividad global progresó a través de la organización, que pasa de un departamento a otro (por ejemplo, desde el diseño hasta la producción a las ventas), cada departamento tomaría insumos del departamento anterior en el proceso, podrá aplicar sus propios procesos de negocio para la actividad, y enviar su salida al siguiente departamento en línea. En el mundo actual donde la velocidad, la flexibilidad y la capacidad de respuesta a los cambios del mercado marcan la diferencia entre el éxito y el fracaso, este método de trabajo ya no es apropiado. Las organizaciones han estado tratando durante algún tiempo para superar las limitaciones impuestas por las estructuras tradicionales de organización. Se han emprendido y abandonado porque eran demasiado ambiciosos, mientras que otros cuestan mucho más en tiempo y dinero de lo previsto originalmente Muchos esfuerzos de reingeniería de procesos de negocio. Sin embargo, las organizaciones de hoy en día reconocen que no necesitan abandonar la organización funcional o departamental en conjunto. Pueden permitir que las personas adecuadas se reúnan en equipos multifuncionales de modo que todas las habilidades, conocimientos y experiencia pueden ser ejercidas sobre cualquier problema específico o una oportunidad de negocio. Pero esto a su vez plantea sus propios desafíos. CIOs están bajo una enorme presión para facilitar el a la información a cada equipo multifuncional según sea necesario-, y sin embargo, las fuentes de estos datos pueden ser numerosas y los volúmenes enormes. Peor aún, los sistemas informáticos, que se han construido en un período de 20 o 30 años a un costo de miles de millones de dólares, y no están a punto de ser expulsado o al por mayor reemplazado, fueron construidos para cada departamento funcional. Así que a pesar de que puede ser posible que la gente a trabajar juntos de manera efectiva (no es un logro menor en sí mismo), los sistemas informáticos que utilizan están diseñados para soportar el pensamiento de estilo antiguo. Los sistemas de TI en lugar de hoy no permiten que la información fluya en apoyo de la organización sin fronteras. Cuando lo hacen, entonces tendremos sin fronteras Flujo de Información. 44.1.4.2 Solución Espacio: La necesidad de una infraestructura de información integrada

El Open Group Interoperable Enterprise Business Escenario 1 publicado originalmente en 2001, cristaliza esta necesidad sin fronteras Flujo de información y describe la forma en que esta necesidad impulsa el despliegue de su infraestructura de la información de los clientes de TI. En este escenario, planteamiento del problema del cliente dice que yo (como la empresa cliente) podría ganar eficiencias operativas significativas y mejorar los diferentes procesos de negocio de la empresa - tanto los procesos internos, y los que abarca las principales Página 544 de 670


interacciones con los proveedores, clientes y socios - si tan sólo pudiera dar mi personal con: Información integrada para que diferentes y potencialmente conflictivas piezas de información que no se distribuyen a través de diferentes sistemas integrado a esa información a fin de que el personal pueda acceder a toda la información que necesitan y tienen derecho a, a través de una cómoda interfaz

La infraestructura que permite a esta visión se denomina la "infraestructura de información integrada". A modo de ejemplo, un enfoque actual de la infraestructura de información integrada es proporcionar "portales empresariales" que permiten un integrado a la información de diferentes sistemas de aplicaciones, a través de una cómoda interfaz web-enabled, (uno de los segmentos de color en los extremos de toda la empresa el cilindro en la Figura 44-1 ).

Figura 44‐1: Una aproximación al flujo de información sin fronteras (Enterprise Portals)

Uno de los principales retos para el arquitecto en la empresa de hoy es trabajar, y luego comunicar a la alta dirección, como las tecnologías lejanos como los servicios web, Página 545 de 670


servicios de integración de aplicaciones, etc, se van hacia el logro de una infraestructura de información integrada, y darse cuenta de la visión sin fronteras Flujo de Información, en la empresa de que se trate. Análisis de seguimiento del Grupo Abierto del Escenario Interoperable Enterprise Business ha dado lugar al desarrollo de un modelo integrado de infraestructura de la información (el III-RM), que representa a los principales componentes necesarios para abordar el problema de espacio sin fronteras Flujo de Información, y puede ayudar al arquitecto en esta tarea. Así, el III-RM ofrece ideas relacionadas con las necesidades del cliente para sin fronteras flujo de información en entornos empresariales. El modelo también apunta a las reglas y normas para ayudar a aprovechar las soluciones y productos dentro de la cadena de valor. Las siguientes subsecciones discuten el modelo en detalle. 44.1.5 Situación de la III‐RM

El III-RM se documenta en su forma actual, y de ninguna manera considerados un artículo acabado. Sin embargo, se trata de un modelo que ha sido desarrollado y aprobado por los 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 de los clientes de The Open Grupo de ayuda en este campo. El escenario de negocios y el modelo de referencia por lo tanto representan un problema y un enfoque de solución que la pertenencia al grupo abierto en su conjunto apoya plenamente. Se espera que la publicación de la modelo como parte de TOGAF fomentará su adopción y el uso generalizado, y proporcionar un canal de comunicación mediante el cual la experiencia con el uso del modelo puede ser realimentada, puntos de mejora asimilado, y el modelo refinado y reeditado como sea necesario .

44.2 de Alto Nivel View Esta sección proporciona una vista de alto nivel de la III-RM, incluyendo derivación del modelo, gráfico de alto nivel, y los componentes. 44.2.1 Obtención de la III‐RM de la TRM

El III-RM es un modelo de las principales categorías de componentes para el desarrollo, gestión y operación de una infraestructura de información integrada. Se trata de un modelo de un conjunto de aplicaciones que se sienta encima de una plataforma de aplicaciones. Este modelo es un subconjunto de la TOGAF TRM, y utiliza una orientación ligeramente diferente. Página 546 de 670


Considere la Figura 44-2 , donde se presentan dos vistas de la TOGAF TRM. El lado izquierdo es la visión familiar de la TOGAF TRM; es una vista lateral, donde nos fijamos en el modelo como si estuviera buscando en una casa del lado, revelando el contenido de los "pisos". La vista de arriba hacia abajo en la parte derecha representa lo que se podría ver si la mirara a una casa del "techo" abajo.

Figura 44‐2: TOGAF TRM Orientación Vistas

El subconjunto de la TRM que comprende el III-RM se representa en la figura 44-3 , en el que las partes de la TRM no es relevante para la III-RM están "en gris". La figura 44-3 ilustra que la atención se centra en el software de aplicación, la plataforma de aplicaciones y cualidades subconjunto del TOGAF TRM.

Página 547 de 670


Figura 44‐3: Enfoque de la III‐RM

44.2.2 de Alto Nivel III‐RM Gráfico

El propio III-RM resultante se representa en la Figura 44-4 . Es fundamentalmente un modelo de referencia de arquitectura de aplicaciones - un modelo de componentes de aplicaciones y servicios de aplicación de software esencial para una infraestructura de información integrada. (Hay más aplicaciones de negocios y aplicaciones de infraestructura que éstas en el medio ambiente, por supuesto, pero estos son los subconjuntos relevantes para el problema de espacio sin fronteras Flujo de Información.)

Página 548 de 670


Figura 44‐4: III‐RM ‐ de Alto Nivel

Como se explicó anteriormente, el modelo supone la existencia subyacente de un cálculo y la plataforma de red, y no representa a ellos explícitamente. Aunque la computación y de la plataforma de red no se muestran, puede haber requisitos en los que se deben cumplir, además de los requisitos de los componentes de la III-RM, con el fin de abordar plenamente el problema de espacio sin fronteras Flujo de Información. 44.2.3 Componentes de Alto Nivel III‐RM

El III-RM tiene los siguientes componentes principales: Aplicaciones empresariales , designados por las cajas amarillas en el modelo de alto nivel (que corresponden al cuadro "Aplicaciones empresariales" en el gráfico TRM). Hay tres tipos de Aplicaciones de Negocio en el modelo: o Aplicaciones de intermediación , que gestionan las solicitudes de cualquier número de clientes ya través de cualquier número de aplicaciones de los proveedores de información

Página 549 de 670

The Open Group Architecture Framework TOGOF 9.1   o aplicaciones de proveedores de información , que proporcionan respuestas a las peticiones de los clientes y el rudimentario a los datos gestionados por un servidor particular o Aplicaciones de Información al Consumidor , que entregan contenido al del sistema, y proporcionan servicios para solicitar el a la información en el sistema en nombre del Aplicaciones Infraestructura , denotados por las cajas de color naranja en el modelo de alto nivel (que corresponden al cuadro "Aplicaciones de Infraestructura" en el gráfico TRM). Hay dos tipos de Aplicación Infraestructura en el modelo: o Herramientas de desarrollo , que proporcionan todo el modelado es necesario, el diseño, la construcción y las capacidades para desarrollar e implementar aplicaciones que requieren a la infraestructura de información integrada, de manera compatible con las normas de medio ambiente o Servicios de Gestión , que proporcionan todos los servicios públicos necesarios para comprender, operar, ajustar y istrar el sistema en tiempo de ejecución con el fin de satisfacer las demandas de un negocio en constante cambio, de una manera consistente con las normas de medio ambiente Una plataforma de aplicaciones , que proporciona servicios de apoyo a todas las aplicaciones mencionadas - en áreas tales como la ubicación, el directorio, el flujo de trabajo, gestión de datos, intercambio de datos, etc - y por lo tanto proporciona la capacidad de encontrar, manipular y mover la información dentro del entorno. Este conjunto de servicios constituye un subconjunto del conjunto total de los servicios de la plataforma de aplicaciones de TRM, y se representa por la capa base de color verde oscuro en el modelo de alto nivel (que corresponde a la plataforma de aplicaciones en el gráfico TRM). Las interfaces utilizadas entre los componentes. Las interfaces incluyen formatos y protocolos, interfaces de programación de aplicaciones, switches, los valores de datos, etc Interfaces entre los componentes a nivel de aplicación son de color rojo. Interfaces entre los componentes de nivel de aplicación y sus servicios de apoyo en la plataforma de aplicaciones son de color blanco (que corresponde a la caja de API en el gráfico TRM). El Cualidades backplane, denotado por la capa base de color marrón en el modelo de alto nivel (que corresponde a la placa posterior Cualidades en el gráfico TRM). El software de aplicación y la plataforma de aplicaciones deben cumplir con las políticas y los requisitos descritos por el backplane cualidades.

44.3 Taxonomía detallada En esta sección se ofrece una taxonomía detallada de la III-RM, incluyendo gráfica detallada, las categorías de servicios de plataforma, y el medio ambiente sub-entidades externas. Página 550 de 670

The Open Group Architecture Framework TOGOF 9.1   44.3.1 detallada III‐RM Gráfico

El detallado III-RM se muestra en la Figura 44-5 .

   Figura 44‐5: III‐RM ‐ Detallado

Las restantes subsecciones se expanden en el detalle taxonomía / componente se muestra en la Figura 44-5 . 44.3.2 Aplicaciones de Negocio

Hay tres tipos de aplicaciones de negocio en el modelo: Aplicaciones proveedor de información , que proporcionan respuestas a las solicitudes de los clientes y el rudimentario a los datos gestionados por un servidor particular Aplicaciones de intermediación , que gestionan las solicitudes de cualquier número de clientes hacia y a través de cualquier número de proveedores de servicios Información de los usos del consumidor , que entregan contenido al del sistema, y prestan servicios a la solicitud de a la información en el sistema en nombre del

El conjunto global de proveedor de información, de información al consumidor, y aplicaciones de corretaje crea colectivamente un entorno que proporciona un amplio Página 551 de 670


conjunto de servicios de final para acceder de forma transparente los sistemas heterogéneos, bases de datos y sistemas de archivos. 44.3.2.1 Información Aplicaciones Proveedores

En la medida en que la información de hoy puede ser considerado como "rehenes", como se muestra en la Figura 44-6 , Aplicaciones proveedor de información son las aplicaciones que "liberar" a los datos de sus silos.

Figura 44‐6: Liberate datos Silos para satisfacer las necesidades de información de los equipos de la empresa de funciones cruzadas

Aplicaciones proveedor de información a lograr esto proporcionando una interfaz abierta para una interfaz de silo potencialmente propietario, como se ilustra en la Figura 44-7 , donde los puertos en la izquierda de la información de aplicaciones de proveedores están interfaces abiertas y las interfaces entre las aplicaciones de los proveedores de información y datos de silo son interfaces propietarias.

Página 552 de 670


Figura 44‐7: Información Aplicaciones Proveedores Liberate de datos, proporcionando interfaces abiertas a los datos Silos

   44.3.2.2 Aplicaciones Corretaje

Aplicaciones de corretaje sirven peticiones individuales que requieren a múltiples fuentes de información. Una aplicación de Bolsa analiza dicha solicitud, distribuye la solicitud a múltiples fuentes de información, recoge las respuestas, y envía una única respuesta al cliente solicitante. Aplicaciones de corretaje acceder a la información del proveedor de aplicaciones que utilizan las interfaces abiertas proporcionadas por las aplicaciones de los proveedores de la información (como se describe más arriba); que integran la información de múltiples aplicaciones de los proveedores de información y transmiten la información integrada para aplicaciones de información al consumidor mediante interfaces abiertas. Aplicaciones de corretaje también permiten el a la información dentro de la empresa por los socios estratégicos.

Página 553 de 670


Figura 44‐8: Aplicaciones de corretaje integrar la información de la Información Aplicaciones Proveedores

   44.3.2.3 Información usos del consumidor

Información de los usos del consumidor facilitan información a los s en la forma en que la necesitan, cuando lo necesitan, y de una manera segura a terminar.Esto incluye el suministro de la información en el texto, video, audio, Inglés, Alemán, etc Información de los usos del consumidor se comunican con las aplicaciones de corretaje o Aplicaciones proveedor de información que utilizan las interfaces abiertas que las aplicaciones Corretaje e Información de Proveedores proporcionan. La seguridad se proporciona a través de los servidores de seguridad y / o servicios de seguridad. La figura 44-9 muestra las aplicaciones de consumidor de información con los servicios de

seguridad que aparecen como el patrón de ladrillo.

Página 554 de 670


Figura 44‐9: Información usos del consumidor se comunican mediante interfaces abiertas

   44.3.3 Aplicaciones Infraestructura

Hay dos tipos de Aplicación Infraestructura en el modelo: Herramientas de desarrollo , que proporcionan todo el modelado es necesario, el diseño, la construcción y las capacidades para desarrollar e implementar aplicaciones que requieren a la infraestructura de información integrada, de manera compatible con las normas de medio ambiente Utilidades de gestión , que proporcionan todos los servicios públicos necesarios para comprender, operar, ajustar y istrar el sistema en tiempo de ejecución con el fin de satisfacer las demandas de un negocio en constante cambio, de manera compatible con las normas de medio ambiente 44.3.3.1 Herramientas de desarrollo

El componente Herramientas de Desarrollo del modelo comprende aplicaciones que toman la forma de herramientas para el modelado, diseño y construcción de la infraestructura de información integrada. En concreto, incluye herramientas para los negocios, procesos y modelado de datos, así como las herramientas para la construcción de aplicaciones tradicionales que transforman el modelo de negocio en el software que automatiza los procesos de negocio que giran en torno a la información. Página 555 de 670


Tenga en cuenta que cada conjunto de herramientas estará conectada lógicamente a través de un directorio, lo que permite una herramienta a ser impulsado por los datos de otra. Las secciones siguientes describen los requisitos para componentes de herramientas de desarrollo. El conjunto de herramientas también incluye un repositorio.

Herramientas de Modelado de Negocios

Esta categoría cubre las herramientas para el modelado de reglas de negocio y reglas de procesos de negocio. Modelado de actividades se describe y documenta el negocio de una amplia base de conocimientos. Establece un consenso entre la dirección general de los requisitos de dirección de negocio, organización, procesos, información y el entorno actual de los negocios. Tal vez lo más importante es que esta comprensión se documenta en un formato común, orientada a los negocios que se utilizarán para la mejora posterior. Herramientas de Modelado Diseño

Esta categoría cubre las herramientas para diseñar, definir y documentar los elementos de TI más relevantes de la empresa sobre la base de las reglas de negocio y los procesos de negocio. Ejemplos de elementos a ser diseñados incluyen: conexiones entre las personas, las organizaciones, los flujos de trabajo y ordenadores; datos y modelos de objetos; traducción de datos física y las reglas de traducción; y limitaciones. Implementación y herramientas de construcción

Instrumentos de aplicación permiten el desarrollo oportuno de los reutilizables procesos, aplicaciones y servicios de aplicación. Estas herramientas incluyen navegadores inteligentes, los compiladores de lenguaje de manipulación de datos y optimizadores, compiladores de aplicaciones distribuidas y depuradores, cliente y servidor de desarrollo de herramientas heterogéneas, las herramientas de definición de políticas y herramientas de generación de scripts del flujo de trabajo. Herramientas de Modelado de Datos Herramientas de implementación

Herramientas de implementación son necesarios para mover el software implementado en el entorno de desarrollo en el entorno operativo. Bibliotecas

Página 556 de 670


Este componente incluye las bibliotecas reutilizables de software que utilizan las normas del entorno operacional. 44.3.3.2 Gestión de Servicios Públicos

Esta categoría cubre las aplicaciones que toman la forma de utilidades para las operaciones, la istración y gestión de redes, y de la gestión de los datos en función de los requisitos de disponibilidad y costo. Dichas utilidades pueden ejecutarse en una o en un entorno desatendido asistido.

Operaciones, istración y Gestión (OA & M) Utilidades

El componente de OA & M cubre servicios de gestión y istración de sistemas tradicionales que gestionan las reglas de negocio y los objetos de información.Algunos ejemplos son: utilidades para la instalación, derechos de autor y la gestión de licencias; y istración miscelánea, la configuración y las funciones de registro. Además, existen utilidades para el control de la facturación del servicio, el servicio de activación y istración de cuentas. Calidad de servicio de Utilidades

Estos incluyen utilidades de monitorización y gestión de la salud. Copia Gestión De Servicios

Utilidades de istración de copia son los que gestionan el movimiento de datos desde cualquier sistema operativo dado a los puntos de distribución necesarias en la empresa, con el fin de garantizar el máximo aprovechamiento de los datos de los sistemas operativos. También se incluyen herramientas que detectan y bandera datos de mala calidad. istración de almacenamiento Utilidades

Estos son los servicios públicos que permita la gestión de almacenamiento de datos de menor costo. Utilidades de istración de almacenamiento compatibles con la gran variedad de mecanismos de almacenamiento y están conectados a un archivo, objeto, y los sistemas de bases de datos.

Página 557 de 670

The Open Group Architecture Framework TOGOF 9.1   44.3.4 Plataforma de Aplicaciones

Todos los diferentes tipos de aplicaciones descritas anteriormente se construyen en la parte superior de los servicios prestados por la plataforma de aplicaciones. El componente de la plataforma de aplicaciones de la III-RM comprende un subconjunto de todos los servicios que se definen en el TOGAF TRM, el subconjunto que se refiere a la infraestructura de información integrada. Específicamente, comprende todos los servicios en la plataforma de aplicaciones de TRM que permiten a las aplicaciones se centran en la comprensión y tratamiento de la información requerida, en lugar de comprender la forma, formato y / o ubicación de la información. Los servicios del componente Application Platform se pueden utilizar para dar soporte a aplicaciones convencionales, así como Intermediación, información para el consumidor, y las aplicaciones de proveedor de información. Cuando se utiliza como parte de una arquitectura global de aplicación de esta forma, este enfoque permite la máxima influencia de un único entorno operativo que está diseñado para asegurar la transferencia efectiva y coherente de los datos entre los procesos, y para apoyar el desarrollo rápido y eficiente, la implementación y la gestión de de aplicaciones. El componente de la plataforma de aplicaciones comprende las siguientes categorías de servicio.

44.3.4.1 Software Engineering Services Idiomas Bibliotecas Registros 44.3.4.2 Servicios de Seguridad Autenticación, autorización y control de Single Sign-On Firma digital Firewall Encryption La detección de intrusiones Gestión de la identidad

Página 558 de 670

The Open Group Architecture Framework TOGOF 9.1   Gestión de claves 44.3.4.3 Ubicación y Servicios de Directorio

Ubicación y directorio de servicios proporcionan facilidades de para el nombre, ubicación, descripción y datos de relaciones que describe la infraestructura de información integrada. Los servicios de directorio compatibles con el despliegue y la disponibilidad de toda la empresa de un directorio de la infraestructura de información integrada. Los datos en el directorio se ponen a disposición de todos los demás componentes en el modelo de arquitectura. La figura 44-10 muestra la yuxtaposición de ubicación y servicios de directorio para los otros

componentes.

Figura 44‐10: Yuxtaposición de ubicación y servicios de directorio para otros componentes

Los servicios específicos incluyen: Directorio Registro Publicación / suscripción Descubrimiento Nombrando

Página 559 de 670

The Open Group Architecture Framework TOGOF 9.1   Hacer referencia / eliminación de referencias 44.3.4.4 Interacción Humano Servicios

Servicios de interacción humana proporcionan los medios para constantemente presentan datos al final en el formato adecuado. Comprenden servicios que contribuyan a la formulación de solicitudes de datos del cliente y permiten la visualización y presentación de los datos consultados. Los servicios específicos incluyen: Presentación Transformación Navegador Meta índices Portal y personalización 44.3.4.5 Servicios de Data Interchange

Los servicios específicos incluyen: Formato de Información Formularios Electrónicos Mensajería instantánea Aplicación de mensajería Comunicación de aplicación a aplicación Integración de aplicaciones empresariales Servicios de istración de datos 44.3.4.6

Los servicios específicos incluyen: Información y datos de Mapeo de Transformación Distribución de consultas Agregación Búsqueda

Página 560 de 670

The Open Group Architecture Framework TOGOF 9.1   Expediente

Servicios de a la información proporcionan la capacidad de una aplicación para acceder a una visión integrada de los datos, independientemente de si existen los datos en un sistema de computadora central o en un sistema distribuido. Los servicios de a la información aseguran que la integridad de datos se mantiene entre múltiples bases de datos, y también proporcionan la limpieza de datos en línea (en el que los datos se comprueba con normas de datos para cada ). Servicios de a datos proporcionan interfaces abiertas para los datos heredados, proporcionar nuevas aplicaciones de servicios de a la base de datos estándar para grandes cantidades de datos existentes, y proporcionar servicios de estándar a los nuevos tipos de datos. 44.3.4.7 Otros servicios del sistema operativo

Los servicios específicos incluyen: Intermediación Evento Workflow

Estos servicios adicionales permiten el flujo de información, como se representa en la figura 44-11 .

Página 561 de 670

The Open Group Architecture Framework TOGOF 9.1   Figura 44‐11: Workflow Services Habilitar Flujo de Información

Flujo de trabajo denota el concepto de automatización de procesos, facilitando las interacciones del y la ejecución de aplicaciones de acuerdo con un mapa de procesos. Los servicios de flujo de trabajo permiten la integración de aplicaciones empresariales, lo que resulta en aplicaciones de valor extendida. Los servicios de flujo de trabajo también se ocupan de las necesidades de la gestión de un entorno en el que los sistemas heredados son frecuentes. Los servicios de flujo de trabajo también proporcionan un medio para encapsular las aplicaciones existentes, apoyando así las necesidades del cliente para el apalancamiento de los activos existentes. 44.3.5 Cualidades

El componente de las cualidades del modelo se apoya en la calidad de los servicios de servicio, incluyendo los diversos servicios que se requieren para mantener la calidad del sistema como se especifica en los Acuerdos de Nivel de Servicio (SLA). En esto se incluyen los servicios a crear las condiciones para, y reaccionar a las peticiones de la Calidad de Service Manager.

Página 562 de 670




PARTE VII Marco de Arquitectura de Capacidad

Página 563 de 670




45. Introducción Este capítulo proporciona una introducción y una visión general de los contenidos de la parte VII: Arquitectura del marco de Capacidad .

45.1 Información general Con el fin de operar con éxito una función de la arquitectura dentro de una empresa, es necesario poner en marcha las estructuras apropiadas de organización, procesos, funciones, responsabilidades y habilidades para realizar la Capacidad de Arquitectura. Parte VII: Architecture Framework Capacidad proporciona un conjunto de materiales de referencia

para la forma de establecer una función de este tipo de arquitectura. Los lectores deben tener en cuenta que aunque esta parte contiene una serie de directrices para apoyar actividades clave, en su forma actual, el Marco de Capacidad Arquitectura no pretende ser una plantilla completa para el funcionamiento de una capacidad de arquitectura empresarial. Una estructura general para el marco de capacidades de Arquitectura se muestra en la Figura 45-1 .

Página 564 de 670


Figura 45‐1: Arquitectura Maduro Capability



45.2 Estructura de la Parte VII Parte VII: Arquitectura del marco de Capacidad está estructurado de la siguiente manera: Introducción (este capítulo) Establecer una capacidad de Arquitectura (ver 46. establecer una capacidad de Arquitectura ) Architecture Board (ver 47. Architecture Board ) Arquitectura de cumplimiento (véase 48. Arquitectura de Cumplimiento ) Contratos de Arquitectura (ver 49. Arquitectura Contratos ) Arquitectura de control (véase 50. Arquitectura de Gobierno ) Modelos de Madurez Arquitectura (ver 51. Arquitectura de Madurez Modelos ) Arquitectura Skills Framework (véase 52. Arquitectura Skills Framework )

Página 565 de 670


Página 566 de 670




46. Establecer una capacidad de Arquitectura Este capítulo proporciona directrices sobre cómo utilizar el para establecer una capacidad de Arquitectura.

46.1 Información general Como con cualquier capacidad de negocio, la creación de una capacidad de arquitectura empresarial puede ser apoyado por el Método de Desarrollo de Arquitectura TOGAF (). El uso exitoso de la proporcionará una práctica de valor añadido, y la arquitectura sostenible centrada en el cliente que permite a la empresa, ayuda a maximizar el valor de las inversiones, e identifica proactivamente las oportunidades de obtener beneficios de negocio y gestionar el riesgo. El establecimiento de un estudio de arquitectura sostenible dentro de una organización se puede lograr mediante la adhesión a la misma aproximación que se utiliza para establecer las demás capacidades - tales como la capacidad de gestión de procesos de negocio - dentro de una organización. El es un método ideal para ser utilizado al arquitecto y gobernar la aplicación de tal capacidad. La aplicación de la con el Architecture Vision específica para establecer un estudio de arquitectura en la organización iba a lograr este objetivo. Esto no debe ser visto como una fase de un proyecto de arquitectura, o de un proyecto de una sola vez, sino más bien como una práctica continua que ofrece el contexto, el ambiente y los recursos para gobernar y permitir la entrega de arquitectura para la organización. Como un proyecto de arquitectura se ejecuta dentro de este entorno que podría solicitar un cambio en la práctica de la arquitectura que daría lugar a un nuevo ciclo de la de ampliar la práctica de la arquitectura. La implementación de cualquier capacidad dentro de una organización requeriría el diseño de las cuatro arquitecturas de dominio: de negocios, datos, aplicaciones, y Tecnología. Por lo tanto, se establece la práctica de la arquitectura dentro de una organización requeriría el diseño de: La arquitectura de negocio de la práctica de la arquitectura que pondrá de relieve la gobernabilidad arquitectura, los procesos de arquitectura, arquitectura estructura organizativa, las necesidades de información de arquitectura, productos de arquitectura, etc La Arquitectura de Datos que defina la estructura de la empresa Continuum y Arquitectura Repositorio de la organización

Página 567 de 670

The Open Group Architecture Framework TOGOF 9.1   La arquitectura de aplicaciones especificando la funcionalidad y / o servicios de aplicaciones se requiere para que el estudio de arquitectura La Tecnología de la Arquitectura que describe las necesidades de infraestructura de la práctica de la arquitectura y el despliegue en apoyo de las aplicaciones de arquitectura y Empresa Continuum

Los pasos en el establecimiento de un estudio de arquitectura se explican a continuación, contra el contexto de las fases de . Por tanto, el lector debe referirse a la fase de relevante en la Parte II: Arquitectura Método de Desarrollo () , para comprender el alcance completo de cada paso. En esta sección, los aspectos fundamentales se destacarán para cada fase de que se debe considerar y son específicas para el establecimiento de un estudio de arquitectura. La intención, por lo tanto no es repetir la descripción de cada fase de , pero para guiar al lector a aplicar cada fase de en el contexto del establecimiento de una práctica de la arquitectura.

46.2 Fase A: Architecture Vision El propósito de esta fase en el contexto del establecimiento de un estudio de arquitectura es definir o revisar la visión, las partes interesadas, y los principios de la práctica de la arquitectura. El objetivo en esta fase sería en la práctica de la arquitectura en su conjunto y no en un proyecto de arquitectura en particular. Lo siguiente debe ser considerado en términos de comprensión de los pasos en el contexto del establecimiento de una práctica de la arquitectura: Establecer el Proyecto : Este paso debe centrarse en la definición de los grupos de interés en la práctica de la arquitectura. Las partes interesadas incluirían las funciones y unidades de la organización que participan en la práctica de la arquitectura, así como aquellos que se beneficiarán de las prestaciones generadas por la práctica de la arquitectura, por tanto, que se puede definir como los clientes de la práctica de la arquitectura. Identificar a los Interesados y preocupaciones, los requisitos de negocio y Architecture Vision : Este paso genera las primeras definiciones, muy de alto nivel de los entornos de referencia y objetivos, desde una perspectiva de los sistemas de información de negocios y tecnología para la práctica de la arquitectura. Identificar objetivos de negocio y los impulsores del negocio : Esto sería más relevante para la práctica de la arquitectura, que a un proyecto de arquitectura en particular. La comprensión de los objetivos de negocio y los conductores es esencial para alinear la práctica de la arquitectura para el negocio. Definir el Alcance : Definir el alcance de la práctica de la arquitectura sería un plan de proyecto de alto nivel de lo que debe ser abordado en términos de arquitectura para el próximo período. Definir restricciones : El enfoque en este paso debe estar en las limitaciones de toda la empresa que impactarían en todos los proyectos de arquitectura.

Página 568 de 670

The Open Group Architecture Framework TOGOF 9.1   Revise Arquitectura Principios, incluidos los Principios de Actuación : La intención en este paso debe ser definir los principios que regirían y orientar la gestión de la práctica de la arquitectura. Cuando los principios de arquitectura generalmente rigen las prestaciones de arquitectura, los principios de la práctica de arquitectura abordarían la organización práctica de la arquitectura, el contenido, las herramientas, y el proceso. Desarrollar el Enunciado del Trabajo de Arquitectura y Aprobación Secure : Este paso debe generar la práctica la visión y el ámbito de la arquitectura.

Otro paso que se puede considerar en esta fase es llevar a cabo una evaluación de la madurez de la arquitectura. Consulte 51. Modelos de Madurez de Arquitectura para la orientación sobre este tema.

46.3 Fase B: Arquitectura de Negocios Las áreas clave de enfoque durante esta fase de establecimiento o el perfeccionamiento de la Arquitectura Empresarial de la práctica de la arquitectura son: Una Arquitectura Ontología definir los términos y las definiciones que se utilizarán en la organización con el fin de establecer una comprensión común de estos términos arquitectónicos. El proceso de arquitectura donde el formaría la base del proceso y la necesidad de ser personalizado para satisfacer las necesidades de la organización y práctica de la arquitectura de la visión. Consulte 5.3 Adaptación de la para la orientación en el desarrollo de este proceso. Los procesos de gobernanza arquitectura requeridas deben ser incluidos en el proceso general de la arquitectura. Los puntos de vista de arquitectura y vistas que muestra todos los puntos de vista y opiniones que deben ser abordados por el estudio de arquitectura. Las prácticas de los actores identificados arquitectura guiarían el desarrollo de esta definición. Uno de los puntos de vista que deben incluirse es el punto de vista de la arquitectura de gobernanza; consulte la Parte IV , 35. Architectural Artifacts para orientarlos respecto a esta salida. La arquitectura marco descriptivo de las distintas entregas de arquitectura que se generarán por la práctica de la arquitectura, las interrelaciones y dependencias entre los entregables de arquitectura, así como las normas y directrices que rigen el diseño de estos productos entregables. Los puntos de vista y las opiniones de arquitectura definidos deben utilizarse para orientar la definición del marco de la arquitectura. Parte II: Arquitectura Método de Desarrollo () y 36. Arquitectura Entregables son referencias útiles que ayudarán a describir el marco de la arquitectura. La Planilla de Responsabilidades Arquitectura definición de las funciones en la práctica de la arquitectura y la asignación de la responsabilidad de las funciones a las prestaciones y los procesos de arquitectura. Esta matriz incluiría las estructuras necesarias arquitectura de gobernanza y roles. Parte II: Arquitectura Método de Desarrollo () , así como 47. Architecture Board , 50. Arquitectura de Gobierno , y 52 . Arquitectura Skills Framework proporcionará orientación sobre esta salida.

Página 569 de 670

The Open Group Architecture Framework TOGOF 9.1   La arquitectura de rendimiento Métrica identificación y descripción de los indicadores que se utilizarán para monitorear el desempeño de la práctica de la arquitectura en contra de su declarada práctica la visión y los objetivos de la arquitectura. El Marco de Gobierno de Arquitectura , que es un punto de vista específico del proceso de arquitectura definida y Arquitectura Planilla de Responsabilidades.

46.4 Fase C: Arquitectura de Datos La Arquitectura de Datos de la práctica de la arquitectura especificaría y gobernar la estructura de la empresa Continuum de la organización y arquitectura de repositorio. La Arquitectura de Datos debe definirse con base en el marco de la arquitectura. La Arquitectura de Datos se refiere a veces como el metamodelo de la práctica de la arquitectura.

46.5 Fase C: Arquitectura de aplicaciones La Arquitectura de la aplicación de la práctica de la arquitectura define la funcionalidad necesaria para generar, mantener, publicar, distribuir, y gobernar los entregables arquitectura como se define en el marco de la arquitectura. Un enfoque clave debe estar en los conjuntos de herramientas de modelización necesarias para modelar, pero no debería ser el único foco. Consulte 42. Herramientas para el desarrollo de la arquitectura para la orientación en la selección de un conjunto de herramientas. La publicación de los entregables de arquitectura para hacer frente a puntos de vista específicos en el marco de la arquitectura a veces requieren una funcionalidad especializada o personalizada y no debe ser descuidado.

46.6 Fase D: Architecture Tecnología La Tecnología de la Arquitectura de la práctica de la arquitectura debería definir la infraestructura de tecnología de apoyo a la práctica de la arquitectura.

46.7 Fase E: Oportunidades y Soluciones Un factor crítico a considerar durante esta fase de la planificación de la creación de la práctica de la arquitectura es el cambio organizacional que se requiere y cómo se va a lograr.

46.8 Fase F: planeamiento de migración El enfoque no debe ser sólo en los componentes de los sistemas de información de arquitectura en esta fase, sino que incluyen la arquitectura de negocio. La adopción del proceso de la arquitectura y el marco tendrá un impacto importante en el establecimiento general de la práctica de la arquitectura en la organización.

Página 570 de 670


46.9 Fase G: Gobernanza Aplicación La implementación de la Arquitectura Empresarial de la práctica de la arquitectura debe ser el foco de esta fase. Cambiar las prácticas dentro de la organización a adoptar un enfoque más estructurado y disciplinado será un reto y debe ser abordado por las técnicas de cambio de organización adecuadas.

46.10 Fase H: Gestión Arquitectura Cambio Los cambios en la arquitectura de la práctica de la arquitectura deben ser gestionados por esta fase. Estos cambios generalmente se activan durante la ejecución de proyectos de arquitectura. Un cambio típico sería el requisito para una nueva arquitectura entregable. Esto tendría un impacto en todos los ámbitos de la arquitectura de la práctica de la arquitectura.

Gestión 46.11 Requisitos La comprensión y la gestión de los requisitos para la práctica de la arquitectura es crucial. Los requisitos deben estar claramente articuladas y se alinean con la visión práctica de la arquitectura.

Página 571 de 670




47. Architecture Board Contenido del capítulo 47.1 Rol | 47.2 Responsabilidades | 47.3 Configuración de la Junta de Arquitectura | 47.4 Funcionamiento del Consejo de Arquitectura

Este capítulo proporciona directrices para el establecimiento y funcionamiento de un Consejo de Arquitectura Empresarial.

47.1 Papel Un elemento clave para una estrategia exitosa de gobernabilidad arquitectura (ver 50. Arquitectura de Gobierno ) es una Junta de Arquitectura de toda la organización para supervisar la implementación de la estrategia. Este órgano debe ser representativa de todos los actores clave en la arquitectura, y comprenderá normalmente un grupo de ejecutivos responsables de la revisión y el mantenimiento de la arquitectura general. Arquitectura Boards pueden tener, o alcance la línea de negocio global, regional. Sobre todo en las grandes empresas, Arquitectura Juntas están compuestas normalmente por representantes de la organización en un mínimo de dos niveles: Local (expertos en el dominio, la responsabilidad de línea) Mundial (la responsabilidad de toda la organización)

En tales casos, cada tabla se establecerá con identificable y articulado: Responsabilidades y capacidades de toma de decisiones Límites de mandato y autoridad

47.2 Responsabilidades La Junta de Arquitectura se hace típicamente responsable y rendir cuentas, para lograr algunos o todos de los siguientes objetivos: Proporcionar la base para todas las decisiones con respecto a las arquitecturas Coherencia entre los sub-arquitecturas El establecimiento de objetivos para la reutilización de los componentes La flexibilidad de la arquitectura de la empresa:

Página 572 de 670

The Open Group Architecture Framework TOGOF 9.1   o para satisfacer las cambiantes necesidades del negocio o Para aprovechar las nuevas tecnologías Ejecución de Arquitectura de Cumplimiento Mejorar el nivel de madurez de la arquitectura la disciplina dentro de la organización Asegurarse de que se adopte la disciplina de desarrollo basado en la arquitectura El apoyo a una capacidad de escalada visible para las decisiones fuera de los límites

Otras responsabilidades de una perspectiva operacional deben incluir: Todos los aspectos de seguimiento y control del Contrato Arquitectura Reunión sobre una base regular Asegurar la gestión y la aplicación efectiva y coherente de las arquitecturas Resolución de ambigüedades, problemas o conflictos que han sido escalados Prestar asesoramiento, orientación e información Asegurar el cumplimiento de las arquitecturas, y la concesión de las dispensas que están en consonancia con la estrategia y objetivos de la tecnología Teniendo en cuenta la política (calendario, Acuerdos de Nivel de Servicio (SLAs), etc) cambia cuando se solicitan y otorgan dispensas similares; por ejemplo, la nueva forma de requisitos de servicio Garantizar que toda la información pertinente para la aplicación del Contrato de Arquitectura se publica bajo condiciones controladas y transmitirse a las partes autorizadas La validación de los niveles de servicio reportados, ahorro de costes, etc

Desde la perspectiva de la gobernabilidad, la Junta de Arquitectura también es responsable de: La producción de materiales y actividades de gobernanza utilizable Proporcionar un mecanismo para la aceptación formal y la aprobación de la arquitectura a través del consenso y la publicación autorizada Proporcionar un mecanismo de control fundamental para asegurar la aplicación efectiva de la arquitectura Establecer y mantener el enlace entre la aplicación de la arquitectura, la estrategia de arquitectura y los objetivos plasmados en la arquitectura de la empresa, así como los objetivos estratégicos del negocio La identificación de divergencia con respecto a las actividades de la arquitectura y de planificación para la reestructuración a través de dispensaciones o actualizaciones de la política

Página 573 de 670


47.3 Configuración Up Architecture Board 47.3.1 Los disparadores

Uno o más de los siguientes sucesos desencadena normalmente el establecimiento de un Consejo de Arquitectura: Nuevo CIO Fusión o adquisición Examen de un traslado a las nuevas formas de la informática Reconocimiento de que es mal alineado al negocio El deseo de lograr una ventaja competitiva a través de la tecnología Creación de un programa de arquitectura de la empresa El cambio de negocios importante o un rápido crecimiento Requisitos para las soluciones complejas, multi-funcionales

En muchas empresas, el patrocinador ejecutivo del esfuerzo inicial de la arquitectura es el CIO (u otro alto ejecutivo). Sin embargo, para obtener un amplio apoyo de las empresas, un organismo que patrocina tiene más influencia. Este organismo patrocinador se llama aquí un Consejo de Arquitectura, pero el título no es importante.Sea cual sea el nombre, es el grupo de nivel ejecutivo responsable de la revisión y mantenimiento de la arquitectura estratégica y todos sus sub-arquitecturas. La Junta de Arquitectura es el patrocinador de la arquitectura dentro de la empresa, sino que el propio Consejo de Arquitectura necesita un patrocinador ejecutivo del más alto nivel de la corporación. Este compromiso debe abarcar el proceso de planificación y continuará en la fase de mantenimiento del proyecto de arquitectura. En muchas empresas que fracasan en un esfuerzo planificación de la arquitectura, hay una notable falta de participación ejecutiva y aliento para el proyecto. Una fuente pasa por alto con frecuencia de los de la Junta de Arquitectura es la Junta Directiva de la empresa. Estas personas siempre tienen diversos conocimientos sobre la empresa y su competencia. Debido a que tienen un impacto significativo en la visión y los objetivos de negocio, pueden tener éxito en la validación de la armonización de las estrategias de TI con los objetivos empresariales. 47.3.2 Tamaño de la Junta

El tamaño recomendado para una Junta de Arquitectura es de cuatro o cinco años (y no más de diez) permanentes. Página 574 de 670


Con el fin de mantener el Consejo de Arquitectura de un tamaño razonable, al tiempo que garantiza la representación de toda la empresa en la que con el tiempo, 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 de la Junta de Arquitectura de la búsqueda de que las limitaciones de tiempo a prevenir la participación activa a largo plazo. Sin embargo, una cierta continuidad debe existir en el Consejo de Arquitectura, para evitar que la arquitectura corporativa de la variación de un conjunto de ideas a otro. Una técnica para asegurar la rotación con continuidad es tener términos establecidos para los , y para tener los términos expiran en diferentes momentos. En el proceso de arquitectura en curso tras el esfuerzo inicial de la arquitectura, la Junta de Arquitectura se puede volver a alquilar. El patrocinador ejecutivo revisará normalmente la labor de la Junta de Arquitectura y evaluar su eficacia; si es necesario, el proceso de revisión de Arquitectura de Cumplimiento está actualizado o modificado. Estructura Junta 47.3.3

El Marco de Gobierno TOGAF Arquitectura (ver 50.2 Arquitectura Governance Framework ) proporciona un marco de organización genérica que posiciona a la Junta de Arquitectura en el marco de las estructuras de gobierno más amplios de la empresa. Esta estructura identifica los principales grupos y las responsabilidades de organización, así como la relación entre cada grupo. Se trata de una estructura de las mejores prácticas, y puede estar sujeto a cambio dependiendo de la forma de la organización y las estructuras existentes. Hay que prestar atención al tamaño de la organización, su forma, y cómo las funciones de TI se implementan. Esto proporcionará la base para diseñar la estructura Architecture Board en el contexto del entorno general de gobierno. En particular, se debe considerar que el concepto de propiedad global y la implementación local, y la integración de nuevos conceptos y tecnologías de todas las áreas de aplicación correspondientes arquitecturas. La estructura de la Junta de Arquitectura debe reflejar la forma de la organización. La estructura de gobierno de la arquitectura requerida y puede ir más allá de las estructuras genéricas descritas en el Marco de Gobierno TOGAF Arquitectura (ver 50.2 Arquitectura del marco de la gobernanza ). La organización puede necesitar para definir una combinación del proceso de gobernanza de la TI en su lugar y las estructuras y capacidades organizacionales existentes, que suelen incluir los siguientes tipos de cuerpo: Junta de gobierno Global Junta de Gobierno Local Autoridades de Diseño Grupos de trabajo

Página 575 de 670


47.4 El funcionamiento del Consejo de Arquitectura En esta sección se describe el funcionamiento de la Junta de Arquitectura de todo desde la perspectiva de gobierno. 47.4.1 general

Reuniones de Arquitectura de la Junta deben llevarse a cabo dentro de las agendas claramente identificados con los objetivos explícitos, la cobertura de contenidos y acciones definidas. En general, las reuniones de la junta estarán alineados con las mejores prácticas, tal como se da en el marco COBIT (ver 50.1.4.1 Un Controles de TI Marco - COBIT ). Estas reuniones brindarán dirección clave: Apoyo a la producción de materiales y actividades de gobernanza de calidad Proporcionar un mecanismo para la aceptación formal a través del consenso y la publicación autorizada Proporcionar un mecanismo de control fundamental de velar por la aplicación efectiva de las arquitecturas Establecer y mantener el enlace entre la aplicación de las arquitecturas y la estrategia y objetivos de la organización se indica (de negocios y de TI) La identificación de la divergencia de las actividades contractuales y de planificación para realinear con el contrato a través de dispensaciones o actualizaciones de la política

47.4.2 Preparación

Cada participante recibirá una agenda y la documentación de apoyo - por ejemplo, las solicitudes de exención, los informes de gestión del rendimiento, etc - y se espera que esté familiarizado con el contenido de cada uno. Cuando las acciones se han asignado a un individuo, es responsabilidad de la persona que informe sobre los avances en contra de estos. Cada participante debe confirmar su disponibilidad y la asistencia a la reunión de Junta de Arquitectura. 47.4.3 del orden del día

En esta sección se describe el contenido de un programa de la reunión Architecture Board. Cada tema del programa se describe en términos de sólo su contenido. Acta de la reunión anterior

Página 576 de 670


Minutos contienen los detalles de la anterior reunión Architecture Board según el protocolo estándar de la organización. Las solicitudes para el Cambio

Los artículos de este capítulo están normalmente cambian las solicitudes de modificación de las arquitecturas, principios, etc, pero también pueden incluir el control de las empresas respecto a la arquitectura de Contratos; por ejemplo, asegurarse de que el tráfico de voz a números de tarificación adicional, como informes del tiempo, se prohibió el tráfico de datos a ciertos sitios web se controla. Cualquier solicitud de cambio se realiza dentro de los niveles y parámetros definidos por el Contrato Arquitectura autoridad acordados. Dispensaciones

Una dispensación se utiliza como el mecanismo para solicitar un cambio en las arquitecturas existentes, contratos, principios, etc fuera de los parámetros normales de operación; por ejemplo, excluye la prestación del servicio a una filial, solicitud de los niveles de servicio inusuales por motivos de negocio específicas, implementar la tecnología o los productos no estándar para apoyar las iniciativas empresariales específicas. Las dispensaciones se conceden por un periodo de tiempo determinado y un conjunto de servicios identificados y los criterios operativos que deben ser ejecutadas durante la vida útil de la dispensación. Las dispensaciones no se otorgan por tiempo indefinido, pero se utilizan como un mecanismo para asegurar que los niveles de servicio y los niveles operacionales, etc se cumplen mientras que proporciona una flexibilidad de nivel en su aplicación y el tiempo. La naturaleza de duración determinada de dispensaciones asegura que son un disparador para la actividad de Cumplimiento Arquitectura. Evaluaciones de cumplimiento

El cumplimiento se evalúa a los SLA, Acuerdos de Nivel Operacional (OLA), los objetivos de costes, y refresca arquitectura requeridas. Estas evaluaciones serán revisadas y aceptadas o rechazadas en función de los criterios definidos en el Marco de Gobierno de Arquitectura. El informe de evaluación Arquitectura Cumplimiento incluirá detalles como se describe. Resolución de Disputas

Las controversias que no han sido resueltos a través de la arquitectura de cumplimiento y los procesos de dispensación se identifican aquí para más acción y se documentan a través de las evaluaciones de cumplimiento Arquitectura y documentación dispensación. Arquitectura Estrategia y Dirección de Documentación

Página 577 de 670


Este describe las estrategias de la arquitectura, la dirección y las prioridades y sólo será formulada por el Consejo de Arquitectura global. Se debe tomar la forma de documentación de arquitectura estándar. Acciones de Asignación

Se trata de un informe sobre las acciones asignadas en anteriores reuniones de la Junta de Arquitectura. Un rastreador de acción se utiliza para documentar y mantener el estado de todas las acciones asignadas durante las reuniones de la Junta de Arquitectura y debe consistir de por lo menos la siguiente información: Referencia Prioridad Descripción Acción Propietario Acción Información de la acción Fecha planteado Fecha de vencimiento Estado Tipo Fecha de Resolución Gestión de la Documentación del Contrato

Se trata de una aceptación formal de las actualizaciones y cambios a la documentación de la arquitectura para su publicación en adelante. Otros asuntos (AOB)

Descripción de las cuestiones que no están directamente cubiertos por alguno de los anteriores. Estos no pueden ser descritos en el orden del día, sino que deben ser planteadas al comienzo de la reunión. Toda la documentación necesaria se debe manejar de acuerdo toda la documentación de la gobernanza de la arquitectura. Calendario de reuniones

Toda reunión Fechas de detalle debe ser detallada y publicada.

   Página 578 de 670




4. Arquitectura Cumplimiento Contenido del capítulo 48.1 Introducción | 48.2 Terminología: El significado de la Arquitectura Cumplimiento | 48.3 Arquitectura Cumplimiento Opiniones | Proceso de Revisión de Cumplimiento 48.4 Arquitectura | Arquitectura 48.5 Revisión de Cumplimiento Listas de comprobación | Directrices 48.6 Arquitectura de Revisión de Cumplimiento

Este capítulo proporciona directrices para asegurar el cumplimiento del proyecto a la arquitectura.

48.1 Introducción Garantizar el cumplimiento de los proyectos individuales con la arquitectura de la empresa es un aspecto esencial de la gobernabilidad arquitectura (véase 50.Arquitectura de Gobierno ). Con este fin, la función de gobierno de TI dentro de una empresa normalmente se definen dos procesos complementarios: La Arquitectura función se requiere para preparar una serie de arquitecturas de Proyecto; es decir, puntos de vista específicos del proyecto de la arquitectura empresarial que ilustran cómo los impactos de arquitectura empresarial en los principales proyectos de la organización. (ver Fases de A a F) El IT Governance función será definir un proceso de revisión formal de Arquitectura de Cumplimiento (véase 48.3 Comentarios Arquitectura de cumplimiento ) para revisar el cumplimiento de los proyectos a la arquitectura de la empresa.

Además de la definición de procesos formales, el gobierno arquitectura (ver 50. Arquitectura de Gobierno ) función también puede estipular que la función de la arquitectura debe extenderse más allá de la función de la definición de la arquitectura y la selección de las normas, y participar también en el proceso de selección de la tecnología, e incluso en el comercial relaciones involucradas en la provisión de servicios y productos de las compras externas. Esto puede ayudar a minimizar la posibilidad de una mala interpretación de la arquitectura de la empresa y maximizar el valor de la negociación comercial centralizada.

48.2 Terminología: El significado de la Arquitectura de Cumplimiento Una relación clave entre la arquitectura y la implementación se encuentra en las definiciones de los términos "conformes", "conforme", etc Si bien el uso de la terminología puede diferir entre las organizaciones, los conceptos de niveles de conformidad se ilustran en la Figura 48-1 puede ser muy útil en la formulación de una estrategia de cumplimiento de TI. Página 579 de 670


Figura 48‐1: Niveles de Arquitectura Conformidad

La frase "de conformidad con" en la figura 48-1 significa: Apoya la estrategia declarada y direcciones futuras Se adhiere a los estándares establecidos (incluida la sintaxis y las reglas semánticas especificadas) Proporciona la funcionalidad declarado Se adhiere a los principios enunciados; por ejemplo: o donde sea abierto posible y adecuado o reutilización de bloques de construcción de los componentes siempre que sea posible y apropiado

Página 580 de 670


48.3 Comentarios Arquitectura Cumplimiento Una revisión de Cumplimiento La arquitectura es un examen de la conformidad de un proyecto específico en función de criterios establecidos de arquitectura, el espíritu y los objetivos de negocio. Un proceso formal para esos exámenes normalmente se forma el núcleo de una estrategia de cumplimiento de arquitectura empresarial. 48.3.1 Propósito

Los objetivos de la revisión de Cumplimiento Arquitectura incluyen algunos o todos de los siguientes: En primer lugar, detectar errores en la arquitectura temprana del proyecto, y por lo tanto reducir el costo y el riesgo de los cambios requeridos más adelante en el ciclo de vida. Esto a su vez significa que el tiempo total del proyecto se acorta, y que la empresa obtiene el beneficio línea de fondo del desarrollo de la arquitectura más rápido. Velar por la aplicación de las mejores prácticas para el trabajo de la arquitectura. Proporcionar una visión general del cumplimiento de una arquitectura de estándares de la empresa por mandato. Identificar dónde las propias normas pueden exigir modificaciones. Identificar los servicios que están actualmente específica de la aplicación, pero podrían ser incluidos como parte de la infraestructura de la empresa. Estrategias de Documentos para la colaboración, el intercambio de recursos y otras sinergias a través de múltiples equipos de arquitectura. Tome ventaja de los avances tecnológicos. Comunicar a la gestión de la situación de la disponibilidad técnica del proyecto. Identificar criterios clave para las actividades de adquisición (por ejemplo, para su inclusión en los documentos comerciales el producto RFI / RFP Off-The-Shelf (COTS)). Identificar y comunicar deficiencias arquitectónicas significativas de productos y proveedores de servicios.

Además de los objetivos generales relacionados con la garantía de calidad se ha señalado, existen motivaciones adicionales, orientación política más para la realización de Arquitectura Las revisiones de cumplimiento, que pueden ser relevantes en casos particulares: La revisión de cumplimiento La arquitectura puede ser una buena manera de decidir entre alternativas de arquitectura, ya que los tomadores de decisiones que suelen participar en la revisión pueden guiar las decisiones en términos de lo que es mejor para el negocio, en lugar de lo que es técnicamente más agradable o elegante.

Página 581 de 670

The Open Group Architecture Framework TOGOF 9.1   La salida de la revisión de Cumplimiento La arquitectura es una de las pocas entregas cuantificables para el CIO para ayudar en la toma de decisiones. Arquitectura opiniones pueden servir como una manera para que la organización Arquitectura para colaborar con los proyectos de desarrollo que de otro modo podrían avanzar sin la participación de la función de la arquitectura. Arquitectura opiniones pueden demostrar un apoyo rápido y positivo a la comunidad de negocios de la empresa: o La arquitectura de la empresa y Arquitectura Cumplimiento ayuda a asegurar la alineación de los proyectos de TI con los objetivos empresariales. o arquitectos a veces puede ser considerado como profundamente en infraestructura técnica y alejada de la actividad principal. o Desde una revisión de cumplimiento Arquitectura tiende a mirar sobre todo a las zonas de riesgo críticos de un sistema, a menudo se destacan los principales riesgos para los propietarios de los sistemas.

Si bien se requiere el cumplimiento de la arquitectura para el desarrollo y ejecución, el incumplimiento también proporciona un mecanismo para poner de relieve: Áreas que deben abordarse para el reajuste Temas para estudiar para su integración en las arquitecturas, ya que están al descubierto por los procesos de cumplimiento

Este último punto identifica el cambio continuo y la adaptabilidad de las arquitecturas de los requisitos que se puedan conducir por indisciplina, pero también permite que los cambios se registran por los cambios rápidos en movimiento en el entorno operacional. Típicamente dispensas (véase 50.1.4 IT Governance ) se utilizarán para poner de relieve estos cambios y poner en marcha un proceso para registrar, monitorear y evaluar la idoneidad de los cambios necesarios. 48.3.2 El tiempo

El momento de las actividades de cumplimiento debe ser considerado en relación con el desarrollo de las propias arquitecturas. Las revisiones de cumplimiento se llevan a cabo en los hitos o puntos de control de proyectos apropiados en el ciclo de vida del proyecto. puestos de control específicos debe incluirse la siguiente manera: El desarrollo de la propia arquitectura (cumplimiento ) La implementación de la arquitectura (s) (arquitectura cumplimiento)

Arquitectura tiempos de proyectos para las evaluaciones deben incluir: Página 582 de 670

The Open Group Architecture Framework TOGOF 9.1   Inicio del proyecto Diseño inicial Los principales cambios en el diseño Ad hoc

La revisión de cumplimiento Arquitectura normalmente está dirigida a un punto en el tiempo cuando los requerimientos del negocio y la arquitectura de la empresa son razonablemente firme, y la arquitectura del proyecto está tomando forma, mucho antes de su finalización. El objetivo es llevar a cabo la revisión lo antes posible, en una etapa en que todavía hay tiempo para corregir los errores o deficiencias importantes, con la condición obvia que no necesita haber sido algún desarrollo importante de la arquitectura del proyecto con el fin de que exista ser algo a revisar. Las entradas a la revisión de Cumplimiento Arquitectura pueden venir de otras partes del ciclo de vida del proyecto de norma, el cual puede tener un impacto en el tiempo. 48.3.3 Gobernabilidad y Escenarios de personal

En cuanto a la gobernanza y la realización del examen de cumplimiento de Arquitectura, y el personal involucrado, hay varios escenarios posibles: Para proyectos de menor escala, el proceso de revisión podría simplemente tomar la forma de una serie de preguntas que los arquitectos del proyecto o de los líderes del proyecto representan a sí mismos, utilizando las listas de verificación que aparecen a continuación, tal vez el cotejo de las respuestas en alguna forma de informe del proyecto a la gerencia. La necesidad de llevar a cabo un proceso de este tipo se incluye normalmente en las políticas generales de gobierno de TI en toda la empresa. Cuando el proyecto que se examina no ha implicado una práctica o arquitecto a tiempo completo hasta la fecha (por ejemplo, en un proyecto de nivel de aplicación), el propósito de la revisión es típicamente para hacer valer la experiencia arquitectónica de una función de la arquitectura empresarial. En tal caso, la función de la arquitectura empresarial iba a organizar, dirigir y llevar a cabo la revisión, con la participación de expertos en los sectores de negocios. En tal escenario, la revisión no es un sustituto de la participación de los arquitectos en un proyecto, pero puede ser un complemento o una guía para su participación. Es probable que sea necesaria una base de datos para manejar el volumen de datos que se producirían en el análisis de un gran sistema o conjunto de sistemas. En la mayoría de los casos, sobre todo en proyectos de mayor envergadura, la función de la arquitectura se han estado profundamente involucrado en, y tal vez conduzca, el proyecto de desarrollo que se examina. (Este es el escenario típico TOGAF.) En tales casos, la revisión será coordinado por el arquitecto de la empresa principal, que reunirá un equipo de expertos en negocios y dominio técnico para la revisión, y compilar las respuestas a las preguntas formuladas durante la la revisión en alguna forma de informe. Las preguntas suelen plantearse durante el examen por los expertos en negocios

Página 583 de 670

The Open Group Architecture Framework TOGOF 9.1   y dominio técnico. Por otra parte, la revisión podría ser dirigido por un representante de una Junta de Arquitectura o algún organismo similar en las responsabilidades de toda la empresa.

En todos los casos, el proceso de revisión de Cumplimiento Arquitectura necesita el respaldo de la alta dirección, y normalmente se encargó como parte de las políticas de gobierno corporativo de arquitectura (ver 50. Arquitectura de Gobierno ). Normalmente, la empresa CIO o empresa Architecture Board (ver 47. Arquitectura Board ) dará un mandato opiniones arquitectura para todos los proyectos, con posteriores revisiones anuales.

48.4 Proceso de Arquitectura de Revisión de Cumplimiento 48.4.1 Información general

El proceso de revisión de Arquitectura cumplimiento se ilustra en la Figura 48-2 .

Figura 48‐2: Proceso Arquitectura Revisión de Cumplimiento

48.4.2 Roles

Los papeles principales en el proceso se tabulan a continuación.

No. Papel Responsabilidades 1 Architecture Para asegurarse de que las Board arquitecturas de TI son consistentes y apoyar las necesidades generales de la

Notas Patrocinador y supervisar las actividades de arquitectura.

Página 584 de 670


2 Líder del Proyecto (o Junta del Proyecto) 3 Architecture Review Coordinador 4

5 6

7

8

empresa. Responsable de todo el proyecto.

Para istrar todo el proceso Más probabilidades de de desarrollo de la arquitectura y ser orientado a los la revisión. negocios de orientación tecnológica. Enterprise Para asegurarse de que la Un especialista en Architect arquitectura es técnicamente arquitectura de TI. Lead coherente y a prueba de futuro. Arquitecto Uno de los asistentes técnicos de la Enterprise Architect plomo. Cliente Para asegurar que los Gestiona la parte de la requerimientos del negocio están organización que va a claramente expresados y depender del éxito de la comprendidos. TI se describe en la arquitectura. Negocios Para asegurar que los procesos Sabe cómo funciona el dominio para satisfacer los requerimientos dominio del Expert del negocio se justifican y negocio; También puede ser el cliente. comprendido. Los Para garantizar que los arquitectos Los de la directores de tienen una comprensión organización del cliente proyecto suficientemente detallada de los que tienen entrada a los procesos del departamento de requerimientos del atención al cliente. Pueden negocio que la proporcionar entrada al dominio arquitectura es abordar. de expertos de negocios o para los arquitectos.

48.4.3 Pasos

Los principales pasos en el proceso se tabulan a continuación.

No. Acción 1 Solicitud arquitectura revisión

Notas Conforme a lo dispuesto por las políticas y procedimientos de gobierno de TI.

¿Quién Cualquier persona, sea o orientada a los negocios, con un interés o responsabilidad en el área de los negocios

Página 585 de 670


2 Identificar parte responsable de la organización y los directores de los proyectos correspondientes. 3 Identificar Enterprise Architect plomo y otros arquitectos. 4 Determinar el alcance de Identificar qué otras la revisión unidades de negocio / departamentos están involucrados. Comprender que el sistema se ajuste en el marco de la arquitectura corporativa. 5 Listas de verificación a Para hacer frente a los medida. requerimientos del negocio. 6 Horario Arquitectura reunión de revisión

7 Directores de proyectos Para obtener Entrevista información básica y técnica:

afectados. Architecture Review Coordinador

Architecture Review Coordinador Architecture Review Coordinador

Enterprise Architect Lead Architecture Review Coordinador con la colaboración de Enterprise Architect plomo. Lead Enterprise Architect y / o Arquitecto, líder del proyecto, y los Clientes

Para proyecto interno: en persona Para COTS: en persona o por medio de RFP

Utilice las listas de comprobación. 8 Analizar las listas de Repase con los verificación terminados estándares corporativos. Identificar y resolver

Enterprise Architect Lead

Página 586 de 670


problemas. Determinar recomendaciones. Puede incluir personal Enterprise Architect de apoyo. Lead

9 Preparar Arquitectura informe de revisión de cumplimiento 10 Hallazgos de la revisión Para Clientes Presente Para Architecture Board 11 Acepte revisión y firmar 12 Enviar el informe de evaluación / Resumen de Architecture Review Coordinador

Enterprise Architect Lead Architecture Board y el Cliente Enterprise Architect Lead

48.5 Arquitectura de Revisión de Cumplimiento listas de verificación Las siguientes listas de control de revisión proporcionan una amplia gama de preguntas típicas que se pueden utilizar en la realización de Arquitectura Las revisiones de cumplimiento, en relación con diversos aspectos de la arquitectura. La organización de las preguntas que incluye las disciplinas básicas de la ingeniería de sistemas, gestión de la información, seguridad y istración de sistemas. Las listas de control se basan en material proporcionado por un miembro de The Open Group, y son específicos para esa organización. Otras organizaciones pueden utilizar las siguientes listas de verificación con otras preguntas a la medida de sus necesidades particulares. Las listas de comprobación proporcionadas contienen demasiadas preguntas para cualquier crítica individual: Tienen el objetivo de adaptarse de forma selectiva con el proyecto de que se trate (véase 48.6 Arquitectura para la Revisión de Cumplimiento ). Las listas de verificación efectivamente utilizadas típicamente se desarrollan / seleccionados por expertos en la materia. Están destinados a ser actualizado anualmente por los grupos de interés en esas áreas. Algunas de las listas de verificación incluyen una breve descripción del principio arquitectónico que provoca la pregunta, así como una breve descripción de lo que debe buscar en la respuesta. Estas extensiones de la lista de control tienen por objeto permitir que los inteligentes re-fraseo de las preguntas, y para dar al de la lista de verificación una idea de por qué se hizo la pregunta. De vez en cuando las preguntas se pueden escribir, como en RFP, o en el trabajo con un arquitecto superior del proyecto. Más típicamente se expresan oralmente, como parte de una entrevista o sesión de trabajo con el proyecto. Página 587 de 670


Las listas de control que aquí se han diseñado para su uso en proyectos de arquitectura individuales, no para el dominio de la arquitectura de negocios o de la arquitectura a través de múltiples proyectos. (Haciendo una revisión de la arquitectura para una esfera más amplia de la actividad, a través de procesos de negocio y proyectos de sistemas múltiples, que implicaría un proceso similar, pero las categorías lista de verificación y sus contenidos serían diferentes.) 48.5.1 Sistema Operativo Hardware y lista de control 1. ¿Cuál es el enfoque del ciclo de vida del proyecto? 2. ¿En qué fase está el proyecto en su ciclo de vida? 3. ¿Qué cuestiones clave han sido identificados ni analizados que el proyecto cree que va a conducir evaluaciones de hardware y sistemas operativos para redes, servidores y dispositivos de final?

4. ¿Qué capacidades del sistema implicará gran volumen y / o transferencias de datos de alta frecuencia? 5. ¿De qué manera el impacto del diseño del sistema o implican dispositivos de final? 6. ¿Cuál es la cantidad y la distribución (regional y mundial) de uso, almacenamiento de datos y el procesamiento? 7. ¿Qué aplicaciones tienen afinidad con su proyecto por las similitudes en los datos, servicios de aplicaciones, etc? ¿Hasta qué punto está de datos affinitized con su proyecto?

8. ¿Qué opciones de hardware y sistemas operativos se han realizado antes del diseño funcional de los elementos clave del sistema? 9. Si se toman las decisiones de hardware y sistema operativo fuera del control del proyecto: o

Lo que la conciencia tiene el proyecto de la justificación de esas decisiones?

o

¿Cómo puede influir en el proyecto aquellas decisiones que el diseño del sistema se concreta?

10. Si se han elegido algunos no estándares: o

¿Cuáles son los requisitos de negocio y técnicas esenciales para no utilizar las normas corporativas?

o

¿Es compatible con un modelo de negocio?

o

Haga que los supuestos en el caso de negocios sido objeto de escrutinio?

11. ¿Cuál es su proceso de evaluación de los costes del ciclo de vida completo de hardware y sistemas operativos? 12. ¿Cómo ha sido la gestión financiera de las empresas ha dedicado a la evaluación de los costes del ciclo de vida? 13. ¿Ha realizado un análisis financiero de la empresa? Página 588 de 670

The Open Group Architecture Framework TOGOF 9.1   14. ¿Ha hecho compromisos con ningún proveedor? 15. ¿Cree usted que sus necesidades pueden ser satisfechas por un solo proveedor? 48.5.2 Servicios de Software y Middleware Checklist 1. Describir cómo se definen las condiciones de error, criados, y se propagan entre los componentes de la aplicación. 2. Describe el patrón general de cómo se definen y se disponen en varios módulos de aplicación métodos. 3. Describe el patrón general de cómo se definen y organizan en varios módulos de aplicación los parámetros del método. Son [en], [in / out], [out] parámetros especificados siempre en el mismo orden? ¿Los valores booleanos devueltos por módulos tienen un resultado consistente?

4. Describa el enfoque que se utiliza para minimizar el número de viajes de ida y vuelta entre cliente y servidor de llamadas, sobre todo para las llamadas fuera de proceso, y cuando las estructuras de datos complejas están involucrados.

5. Describir las principales estructuras de datos que se pasan entre los principales componentes del sistema. 6. Describir los principales protocolos de comunicación que se utilizan entre los principales componentes del sistema. 7. Describir las técnicas de cálculo de referencias que se utilizan entre diversos componentes del sistema. Describa cualquier arreglo de cálculo de referencias especializadas que se utilizan.

8. Describir en qué medida el sistema está diseñado con componentes con estado y sin estado. 9. Describa cómo y cuándo se guarda el estado de ambos componentes con estado y sin estado. 10. Describir el grado en que se crean los objetos, utilizado, y destruido frente reutilizados a través de la agrupación de objetos. 11. Describir la medida en que el sistema se basa en el roscado o de la sección de codificación crítico. 12. Describa el enfoque y la documentación interna que se utiliza internamente en el sistema para documentar los métodos, los métodos de argumentos, y la funcionalidad del método.

13. Describir el proceso de revisión de código que se utilizó para construir el sistema. 14. Describa la prueba de la unidad que se ha utilizado para probar los componentes del sistema. 15. Describir la pre-y post-condición de prueba que se incluye en varios módulos del sistema. 16. Describa la prueba de la afirmación que se incluye con el sistema. Página 589 de 670

The Open Group Architecture Framework TOGOF 9.1   17. ¿Los componentes son compatibles con todos los tipos de interfaces que necesitan para apoyar o son ciertas suposiciones hechas sobre qué tipos de componentes llamará a otros componentes, ya sea en términos de enlaces de lenguaje u otras formas de cálculo de referencias?

18. Describir la medida en que necesitan grandes problemas-endian o little-endian formato de datos que se manejan a través de diferentes plataformas. 19. Describa si los números o cadenas deben ser manejados de manera diferente a través de diferentes plataformas. 20. Describa si el software tiene que comprobar de punto flotante de errores de redondeo. 21. Describir cómo las funciones de fecha y hora a gestionar fechas a fin de evitar un manejo inadecuado del tiempo y el cálculo de la fecha o la pantalla. 22. Describir qué herramientas o procesos se han utilizado para probar el sistema en busca de fugas de memoria, la accesibilidad o la robustez general. 23. Describir las capas del software de servicios de sistemas. Describir el número general de los vínculos entre los principales componentes del sistema. ¿El sistema está compuesto por una gran cantidad de interfaces de punto a punto o son los mayores backbones de mensajería utilizado en su lugar?

24. Describir en qué medida los componentes del sistema están bien imprecisa o fuertemente acoplados. 25. ¿Qué requisitos necesita el sistema a partir de la infraestructura en materia de bibliotecas compartidas, soporte para protocolos de comunicación, equilibrio de carga, procesamiento de transacciones, la supervisión del sistema, los servicios de nombres u otros servicios de infraestructura?

26. Describir cómo los componentes del sistema y del sistema están diseñados para refactorización. 27. Describir cómo los componentes del sistema o del sistema dependen de la infraestructura de mensajería común frente a una estructura única de comunicación punto a punto. 48.5.3 Aplicaciones Listas de verificación 48.5.3.1 Infraestructura (Empresa Productividad) Aplicaciones

1. ¿Existe la necesidad de capacidades que no se ofrecen a través de productos de aplicación infraestructura estándar de la empresa? Por ejemplo: o

Colaboración 

Uso compartido de aplicaciones



La videoconferencia



Calendarios



Email

Página 590 de 670


Gestión de flujo de trabajo

o

Tramitación de las solicitudes de publicación / palabra 

HTML



SGML y XML



Formato de documento portátil



Elaboración de documentos (formato propietario)



Edición

o

Aplicaciones de hoja de cálculo

o

Aplicaciones de presentación

o

o



Presentaciones de negocios



Imagen



Animación



Vídeo



Sonido



CBT



Navegadores web

Aplicaciones de gestión de datos 

Interfaz de base de datos



La gestión de documentos



La gestión de datos del producto



Los almacenes de datos / mart

Aplicaciones de gestión de Programa 

Gestión de proyectos



Visibilidad Programa

2. Describir los requisitos de negocio para capacidades de aplicaciones de infraestructura de la empresa, que no son satisfechas por los productos estándar. 48.5.3.2 Aplicaciones empresariales

1. Son algunas de las capacidades requeridas proporcionado por los productos estándar que apoyan una o más aplicaciones de línea de negocio? Por ejemplo: Página 591 de 670


Aplicaciones de adquisición de negocios 

o

o

o

o

Ventas y marketing

Aplicaciones de ingeniería 

Diseño asistido por ordenador



Ingeniería asistida por ordenador



El análisis matemático y estadística

Aplicaciones de gestión de proveedores 

Gestión de la cadena de suministro



Customer Relationship Management

Aplicaciones de fabricación 

Planificación de Recursos Empresariales (ERP)



Manufacturing Execution Systems



La calidad de fabricación



Ingeniería de procesos de fabricación



Máquina y el control adaptativo

Aplicaciones de soporte al cliente 

Apoyo logístico de avión



Ingeniería de mantenimiento

o

Aplicaciones Finanzas

o

Gente aplicaciones

o

Instalaciones aplicaciones

o

Aplicaciones de sistemas de información 

Ingeniería de sistemas



Ingeniería de software



Herramientas de desarrollo Web



Entornos de desarrollo integrados



Categorías de ciclo de vida



Categorías funcionales



Categorías de productos especializados

Página 592 de 670


Fabricación asistido por ordenador

o

habilitación de e-Business

o

Ingeniería de procesos de negocios 

El control de calidad estadístico

2. Describir los requisitos del proceso de capacidades de aplicaciones de negocio que no son satisfechas por los productos estándar. Integración 48.5.3.3 Aplicación Enfoque

1. ¿Qué puntos de integración (de procesos de negocio / actividad, aplicaciones, datos, entorno de computación) son el objetivo de esta arquitectura? 2. ¿Qué técnicas de integración de aplicaciones se aplicará (objetos de negocio comunes [ORB], las definiciones de datos estándar [STEP, XML, etc], presentación de la interfaz de común / desktop)?

Información 48.5.4 Gestión de listas de verificación 48.5.4.1 Valores de datos

1. ¿Cuáles son los procesos que estandarizan la gestión y uso de los datos? 2. ¿Qué procesos de negocio apoya la entrada y la validación de los datos? Uso de los datos ? 3. ¿Qué acciones de negocio corresponden a la creación y modificación de los datos? 4. ¿Qué acciones de negocio corresponden a la supresión de los datos y se lo considera parte de un registro de negocios? 5. ¿Cuáles son los requisitos de calidad de los datos requeridos por el de negocios? 6. ¿Qué procesos existen para apoyar la integridad referencial de los datos y / o normalización? 48.5.4.2 Definición de Datos

1. ¿Cuáles son el modelo de datos, definiciones de datos, la estructura, y las opciones de alojamiento de aplicaciones compradas (COTS)? 2. ¿Cuáles son las normas para la definición y el mantenimiento de los requisitos de datos y diseños para todos los componentes del sistema de información? 3. Lo repositorio compartible se utiliza para capturar el contenido del modelo y la información de apoyo para los datos? 4. ¿Cuál es la definición del modelo de datos físicos (derivados de modelos de datos lógicos) que se utiliza para diseñar la base de datos? Página 593 de 670

The Open Group Architecture Framework TOGOF 9.1   5. ¿Qué herramientas de desarrollo y software de gestión de datos han sido seleccionados? 6. Lo que los propietarios de los datos se han identificado como responsable de las definiciones comunes de datos, eliminando la redundancia no planificada, con información constantemente confiable, oportuna y precisa, y la protección de datos por el mal uso y la destrucción? 48.5.4.3 Seguridad / Protección

1. ¿Cuáles son la entidad de datos y atributos reglas de que protegen los datos de alteraciones no intencionales y no autorizados, divulgación y distribución? 2. ¿Cuáles son los mecanismos de protección de datos para proteger los datos contra el externo no autorizado? 3. ¿Cuáles son los mecanismos de protección de datos para controlar el a los datos de fuentes externas que tienen residencia temporal interna dentro de la empresa? 48.5.4.4 Hosting, Tipos de datos, y recursos compartidos

1. ¿Qué es la disciplina de la gestión de datos única de autoridad-como una fuente lógica con reglas definidas para la actualización de datos físicas que residen en diferentes plataformas?

2. ¿Qué es la disciplina de la gestión de datos replicados, que se deriva de los datos de autoridad única-operacionales? 3. ¿Qué servidor de nivel de datos se ha identificado para el almacenamiento de los datos operativos de alto o crítico medianas? 4. ¿Qué servidor de nivel de datos se ha identificado para el almacenamiento de tipo C datos operativos? 5. ¿Qué servidor de nivel de datos se ha identificado para el almacenamiento de datos de apoyo a las decisiones contenidas en un almacén de datos? 6. ¿Qué Database Management Systems (DBMS) han puesto en marcha? 48.5.4.5 Servicios Comunes

1. ¿Cuáles son los servicios normalizados distribuidos de gestión de datos (por ejemplo, validación, controles de coherencia, las modificaciones de datos, cifrado y gestión de transacciones) y de dónde residen? 48.5.4.6 Método de

1. ¿Cuáles son los requisitos de a los datos de archivo estándar, el mensaje y la gestión de datos? 2. ¿Cuáles son los requisitos de para los datos de apoyo a las decisiones? Página 594 de 670

The Open Group Architecture Framework TOGOF 9.1   3. ¿Cuáles son el almacenamiento de datos y las ubicaciones de lógica de aplicación? 4. ¿Qué lenguaje de consulta se está utilizando? 48.5.5 Lista de Verificación de Seguridad 1. Conciencia de Seguridad : ¿Se ha asegurado que las políticas y directrices a las que usted está diseñando seguridad corporativa son las últimas versiones? ¿Ha leído usted de ellos? ¿Es usted consciente de todos los procesos de cumplimiento de seguridad informática y la aceptación del riesgo pertinentes? (Entrevistador debe enumerar todas las políticas y directrices pertinentes.)

2. Identificación / Autenticación : Diagrama de flujo del proceso de cómo se identifica a un para la aplicación y cómo la aplicación autentica que el es quien dice ser. Proporcionar documentación de apoyo para el diagrama que explica el flujo de la interfaz de para el servidor (s) aplicación / base de datos y de vuelta al . ¿Está conforme con las políticas corporativas sobre cuentas, contraseñas, etc?

3. Autorización : Proporcionar un flujo de procesos de principio a fin que muestra cómo un solicita el a la aplicación, indicando que los controles de seguridad asociados y separación de funciones. Esto debe incluir la forma en que la solicitud sea aprobada por el titular de los datos apropiados, cómo se coloca el en el perfil de la clasificación de nivel de adecuado, ¿cómo se crea el ID de , la contraseña y el y proporcionar al . También incluye la forma en que se informa al de sus responsabilidades asociadas con el uso de la aplicación, dada una copia del contrato de , cómo cambiar la contraseña, a quién llamar para pedir ayuda, etc

4. Controles de : Documento de cómo se agregan los IDs de , contraseñas y perfiles, cambiar, quitar, y documentados. La documentación debe incluir quién es responsable de estos procesos.

5. Sensitive Information Protection : Proporcionar documentación que identifica los datos sensibles que requieren protección adicional. Identificar los propietarios de los datos responsables de estos datos y el proceso que se utiliza para proteger el almacenamiento, transmisión, impresión y distribución de estos datos. Incluya cómo se protege el campo / archivo de contraseñas. ¿Cómo se pueden prevenir los s vean la información confidencial de otra persona? ¿Existen acuerdos con terceros (socios, proveedores, contratistas, etc) sobre la salvaguardia de la información? Si es así, ¿cuáles son las obligaciones?

6. Pistas de auditoría y registros de auditoría : Identificar y cuentas de grupo de documentos requeridos por los s 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 super tipo, lo que estos privilegios son, quién tiene a estas cuentas, cómo se controla el a estas cuentas, el seguimiento, y se registra y cómo se maneja el cambio de contraseña y distribución, incluyendo cuentas del sistema operativo. También identificar los registros de auditoría, que pueden leer los registros de auditoría, que se modifican los registros de auditoría, que pueden eliminar los registros de auditoría, y cómo los registros de auditoría queda protegido y almacenado. ¿Es el ID de oscurecido en las pistas de auditoría?

7. Consideraciones de externo : ¿La aplicación puede utilizar sólo internamente? Si no es así, ¿está conforme con los requisitos de externos de las empresas? Página 595 de 670

The Open Group Architecture Framework TOGOF 9.1   Lista de control de gestión del sistema 48.5.6 1. ¿Cuál es la frecuencia de los cambios de software que debe ser distribuido? 2. ¿Qué herramientas se utilizan para la distribución de software? 3. Son varias las versiones de software y / o datos permitidos en la producción? 4. ¿Cuál es la frecuencia de copia de seguridad de los datos de y se espera el tiempo de restauración? 5. ¿Cómo están las cuentas de creadas y istradas? 6. ¿Cuál es la estrategia de gestión de licencias de sistema? 7. Se requieren herramientas de istración del sistema general ¿Qué? 8. Se requieren herramientas de istración de aplicaciones específicas Qué? 9. Se requieren herramientas de istración del servicio Lo específicos? 10. ¿Cómo están de servicio las llamadas recibidas y enviadas? 11. Describa cómo se desinstala el sistema. 12. Describa el proceso o las herramientas disponibles para comprobar que el sistema está correctamente instalado. 13. Describir las herramientas o instrumentos que están disponibles que monitorean la salud y el rendimiento del sistema. 14. Describir las herramientas o proceso en lugar de que se pueden usar para determinar dónde se ha instalado el sistema. 15. Describa qué tipo de registros de auditoría se encuentran en el lugar para capturar la historia del sistema, sobre todo después de un accidente. 16. Describir las capacidades del sistema para enviar sus propios mensajes de error para el personal de servicio. Sistema 48.5.7 Ingeniería / Arquitectura general listas de verificación 48.5.7.1 general

1. ¿Qué otras aplicaciones y / o sistemas requieren la integración con el tuyo? 2. Describir el nivel de integración y estrategia con cada uno. 3. Cómo geográficamente distribuida es la base de s? 4. ¿Cuál es la importancia estratégica de este sistema a otras comunidades de s dentro y fuera de la empresa?

Página 596 de 670

The Open Group Architecture Framework TOGOF 9.1   5. ¿Qué recursos de computación son necesarios para ofrecer un servicio de sistema para los s dentro de la empresa? Fuera de la empresa y el uso de los activos informáticos de la empresa? Fuera de la empresa y el uso de sus propios activos?

6. ¿Cómo pueden los s fuera del entorno de entrega nativa acceder a sus aplicaciones y datos? 7. ¿Cuál es la esperanza de vida de esta solicitud? 8. Describir el diseño que se adapta a los cambios en la base de s, datos almacenados y la tecnología del sistema de entrega. 9. ¿Cuál es el tamaño de la base de s y su nivel de rendimiento esperado? 10. ¿Qué rendimiento y técnicas de las pruebas de tensión se utilizan? 11. ¿Cuál es la organización general de los componentes de software y de datos? 12. ¿Qué es el servicio y la configuración del sistema en general? 13. ¿Cómo son el software y los datos configurados y asignan a la configuración del servicio y el sistema? 14. ¿Qué se necesita tecnología propietaria (hardware y software) para este sistema? 15. Describa cómo todos y cada versión del software puede ser reproducido y re-desplegarse en el tiempo. 16. Describir la actual base de s y cómo se espera que la base de cambiar en los próximos tres a cinco años. 17. Describir la distribución geográfica actual de la base de s y cómo se espera que la base de cambiar en los próximos tres a cinco años. 18. Describir la forma en que muchos s actuales o futuros deben utilizar la aplicación con carácter móvil o que necesitan para trabajar fuera de línea. 19. Describir lo que la aplicación general lo hace, los componentes principales de la aplicación, así como los principales flujos de datos. 20. Describir la instrumentación incluido en la aplicación que permite la salud y el rendimiento de la aplicación a monitorizar. 21. Describir la justificación de negocio para el sistema. 22. Describir las razones para escoger el lenguaje de desarrollo del sistema frente a otras opciones en términos de costo inicial de desarrollo en comparación con los costes de mantenimiento a largo plazo.

23. Describir el proceso de análisis de sistemas que se utilizó para llegar a la fase de la arquitectura del sistema y la selección de productos de la arquitectura del sistema. 24. Quién además del cliente original puede tener un uso para o beneficiarse del uso de este sistema? Página 597 de 670

The Open Group Architecture Framework TOGOF 9.1   25. ¿Qué porcentaje de los s utilizan el sistema en modo de exploración frente a modo de actualización? 26. ¿Cuál es la duración típica de las solicitudes que son transaccional? 27. ¿Es necesario la entrega de datos garantizada o actualización, o ¿El sistema tolera el fracaso? 28. ¿Cuáles son los requisitos de tiempo de hasta del sistema? 29. Describa en donde la arquitectura del sistema se adhiere o no se adhiere a los estándares. 30. Describir el enfoque de la planificación y el análisis de proyectos utilizado en el proyecto. 48.5.7.2 Procesadores / Servidor / Clientes

1. Describir la arquitectura de aplicaciones cliente / servidor. 2. Anotar lo pictórico para ilustrar donde se ejecuta la funcionalidad de la aplicación. 48.5.7.3 Client

1. Son funciones distintas de presentación realizadas en el dispositivo de ? 2. Describir la instalación de datos y ayuda proceso que se prestan. 3. Describa la técnica de navegación con pantalla a pantalla. 4. Describa cómo el navega entre esta y otras aplicaciones. 5. ¿Cómo es esto y otras aplicaciones en marcha del dispositivo de ? 6. ¿Existen datos entre aplicaciones y capacidades de uso compartido proceso? Si es así, describir lo que está siendo compartido y por qué técnica / tecnología. 7. Describir los volúmenes de datos que se transfieren al cliente. 8. ¿Cuáles son los requisitos adicionales para el almacenamiento de datos local para apoyar la aplicación? 9. ¿Cuáles son los requisitos adicionales de software de almacenamiento / memoria local para apoyar la aplicación? 10. ¿Existen conflictos de hardware / software conocidos o limitaciones de capacidad provocadas por otros requisitos de aplicación o situaciones que puedan afectar a los s de aplicaciones?

11. Describir cómo el look-and-feel de la capa de presentación se compara con el look-and-feel de las otras aplicaciones existentes. 12. Describir en qué medida el cliente necesita para apoyar la comunicación asincrónica y / o sincrónica. Página 598 de 670

The Open Group Architecture Framework TOGOF 9.1   13. Describir cómo se separa la capa de presentación del sistema de otras capas de cálculo o de transferencia de datos del sistema. 48.5.7.4 Application Server

1. Can / hacer la capa de presentación y niveles de aplicación se ejecutan en procesadores separados? 2. Can / hacer la capa de aplicación y la capa de a datos se ejecutan en procesadores separados? 3. ¿Puede esta aplicación puede colocar en un servidor independiente de aplicación de todas las demás aplicaciones? En caso negativo, explique las dependencias. 4. ¿Se pueden agregar fácilmente servidores de aplicaciones paralelas adicionales? Si es así, ¿cuál es el mecanismo de equilibrio de carga? 5. ¿Se ha medido la demanda de recursos generados por la aplicación y lo que es el valor? Si es así, ¿la capacidad del servidor planeado sido confirmada en los niveles de aplicación y agregados? 48.5.7.5 Data Server

1. ¿Hay otras aplicaciones que deben compartir el servidor de datos? Si es así, identificarlos y describir los datos y los requisitos de a datos. 2. ¿Se ha medido la demanda de recursos generados por la aplicación y lo que es el valor? Si es así, ¿la capacidad del servidor planeado sido confirmada en los niveles de aplicación y agregados? 48.5.7.6 COTS (en su caso)

1. Es el proveedor sustancial y estable? 2. ¿La empresa recibirá el código fuente sobre la desaparición del proveedor? 3. ¿Este software configurado para el uso de la empresa? 4. ¿Hay datos o procesos que impidan el uso de este software peculiares de A & D? o

¿Es este software disponible en la actualidad?

5. ¿Se ha utilizado / demostrado para los requisitos de volumen / disponibilidad / nivel de los servicios similares a los de la empresa? o

Describir la historia pasada financiera y la cuota de mercado del proveedor.

Ingeniería del sistema 48.5.8 / Métodos y Herramientas Lista de verificación 1. ¿Existen indicadores para la actual forma de hacer negocios? 2. El dueño del sistema ha creado criterios de evaluación que se utilizarán para orientar el proyecto? Describa cómo se utilizarán los criterios de evaluación. Página 599 de 670

The Open Group Architecture Framework TOGOF 9.1   3. ¿Se ha hecho una investigación de las arquitecturas existentes para aprovechar el trabajo ya existente? Describir el método utilizado para descubrir y entender. Se integrarán las arquitecturas? Si es así, explique el método que se utilizará.

4. Describir los métodos que se utilizarán en el proyecto: o

Para la definición de las estrategias de negocio

o

Para definir las áreas en necesidad de mejorar

o

Para definir la línea de base y de destino los procesos de negocio

o

Para la definición de los procesos de transición

o

Para la gestión del proyecto

o

Para la comunicación del equipo

o

Para la gestión del conocimiento, gestión de cambios y gestión de la configuración

o

Para el desarrollo de software

o

Para hacer referencia a las normas y declaraciones de la dirección

o

Para asegurar la calidad de los entregables

o

Para las revisiones de diseño y de la aceptación entregable

o

Para capturar las métricas

5. ¿Los métodos documentados y distribuidos a cada miembro del equipo? 6. ¿En qué medida son los del equipo estén familiarizados con estos métodos? 7. ¿Qué procesos existen para garantizar el cumplimiento de los métodos? 8. Describir la infraestructura que está en su lugar para apoyar el uso de los métodos a través de la finalización del proyecto y libera previstos. o

¿Cómo se ofrece la consulta y resolución de problemas?

o

¿Cómo se coordinó la capacitación?

o

¿Cómo son los cambios y las mejoras incorporadas y en cascada?

o

¿Cómo son las lecciones aprendidas capturados y comunicados?

9. ¿Qué herramientas se están utilizando en el proyecto? (Especificar versiones y plataformas). ¿En qué medida son los del equipo estén familiarizados con estas herramientas?

10. Describir la infraestructura que está en su lugar para apoyar el uso de las herramientas a través de la finalización del proyecto y libera anticipadas? o

¿Cómo se ofrece la consulta y resolución de problemas?

Página 600 de 670


¿Cómo se coordinó la capacitación?

o

¿Cómo son los cambios y las mejoras incorporadas y en cascada?

o

¿Cómo son las lecciones aprendidas capturados y comunicados?

11. Describa cómo el proyecto promoverá la reutilización de sus entregables y contenido entregable. 12. ¿Los diseños de la arquitectura "en vivo" después de que el proyecto se ha implementado? Describa el método que se utilizará para incorporar los cambios de nuevo en los diseños de la arquitectura.

13. Se definieron los procesos actuales? 14. Se temas documentados, valorados, y se asocian a los procesos actuales? Si no, ¿cómo sabes que está reparando algo que está roto? 15. ¿Estaban / actividades de mejora de procesos existentes o previstas identificados y asociados a los procesos actuales? Si no, ¿cómo se sabe que esta actividad no está en conflicto con o redundante a otras Declaraciones de trabajo?

16. ¿Tiene métricas actuales? ¿Tiene previsto la métrica? Si no, ¿cómo sabes que está mejorando algo? 17. ¿Qué procesos va a poner en marcha para recoger, evaluar, y las métricas de informes? 18. ¿Qué impactos tendrá el nuevo diseño de tener en los procesos existentes de negocios, las organizaciones y los sistemas de información? ¿Se han documentado y compartido con los propietarios?

48.6 Arquitectura de Cumplimiento para la Revisión 48.6.1 Adaptación de las listas de verificación Centrarse en: o zonas de alto riesgo o esperados (y emergente) diferenciadores Para cada pregunta en la lista de verificación, de entender: o La pregunta en sí misma o El principio detrás de él o Lo que debe buscar en las respuestas Pregunte expertos en el tema para sus puntos de vista Fijar las preguntas la lista de verificación para su uso Tenga en cuenta la necesidad de información a la Junta de Arquitectura

Página 601 de 670

The Open Group Architecture Framework TOGOF 9.1   48.6.2 Realización de Arquitectura revisiones de cumplimiento Comprender claramente los objetivos de quienes solicitan la revisión; y mantenerse en el camino y entregar lo que se le pide. Por ejemplo, por lo general quieren saber lo que está bien o mal con el sistema que se está con arquitectura; no lo que está bien o mal en la metodología de desarrollo utilizada, su propia estructura de gestión, etc Es fácil de conseguir fuera de la pista y discutir temas que son interesantes y tal vez valga la pena, pero no lo que se solicitó. Si usted puede arrojar luz y conocimiento sobre los enfoques técnicos, pero la discusión no es necesaria para la revisión, como voluntario para proporcionar después de la revisión. Si se hace evidente durante el debate que hay otras cuestiones que deben abordarse, que están fuera del alcance de la revisión solicitada, tocar el tema con el presidente de la reunión después. Un plan para resolver los problemas puede ser desarrollado de acuerdo con su grado de gravedad. Stay "científica". En lugar de: "Nos gusta ver grandes bases de datos hospedadas en ABC en lugar de XYZ . ", dicen cosas como: "El tiempo de inactividad asociado con XYZ entornos de bases de datos es mucho mayor que en el ABC . entornos de bases de datos tanto no recomendamos hospedaje tipo M y Nsistemas de un XYZ medio ambiente. " Haga preguntas "abiertas"; es decir, preguntas que no suponen una respuesta en particular. A menudo hay "agendas ocultas" o cuestiones controvertidas entre quienes solicitan una revisión, que probablemente no sabrá por adelantado. Un enfoque despersonaliza a los debates puede ayudar a cerrar las brechas de opinión en lugar de agravarlos. Trate a los que están siendo entrevistados con respeto. Puede que no hayan incorporado el sistema "como debe ser", pero probablemente lo hizo lo mejor que pudo, dadas las circunstancias que se colocan pulg Ayuda el ejercicio se convierta en una experiencia de aprendizaje para usted y los presentadores. Las revisiones deben incluir actividades de evaluación detalladas contra las arquitecturas y deben asegurarse de que los resultados se almacenan en la empresa Continuum.

Página 602 de 670




49. Contratos de Arquitectura Este capítulo proporciona directrices para la definición y el uso de Arquitectura Contratos.

49.1 Papel Arquitectura contratos son los acuerdos conjuntos entre los socios de desarrollo y los patrocinadores de los entregables, la calidad y la aptitud para el propósito deuna arquitectura . La implementación exitosa de estos acuerdos será entregado a través de la gobernanza arquitectura eficaz (véase 50. Arquitectura de Gobierno ).Mediante la implementación de un enfoque regido a la gestión de los contratos, lo siguiente será garantizada: Un sistema de monitoreo continuo para comprobar la integridad, los cambios, la toma de decisiones, y la auditoría de todas las actividades relacionadas con la Arquitectura dentro de la organización La adhesión a los principios, las normas y los requisitos de las arquitecturas existentes o en desarrollo Identificación de los riesgos en todos los aspectos del desarrollo y la implementación de la arquitectura (s) que cubre el desarrollo interno contra las normas aceptadas, políticas, tecnologías y productos, así como los aspectos operativos de las arquitecturas de tal manera que la organización pueda continuar sus actividades dentro de un entorno resistente Un conjunto de procesos y prácticas que garanticen la rendición de cuentas, la responsabilidad y la disciplina en relación con el desarrollo y el uso de todos los artefactos arquitectónicos Una comprensión formal de la organización de gobierno responsable del contrato, su nivel de autoridad, y el ámbito de la arquitectura bajo el gobierno de este órgano

El Contrato Arquitectura tradicional es un acuerdo entre el patrocinador y la función de la arquitectura o IS departamento. Sin embargo, cada vez más servicios están siendo proporcionados por los integradores de sistemas, proveedores de aplicaciones y los proveedores de servicios, coordinados a través de la función de la arquitectura o IS departamento. Por tanto, existe una necesidad de un Contrato de Arquitectura de establecer acuerdos conjuntos entre todas las partes involucradas en el desarrollo de la arquitectura y el parto. Arquitectura contratos pueden ocurrir en diferentes etapas del Método de Desarrollo de Arquitectura (); por ejemplo:

Página 603 de 670

The Open Group Architecture Framework TOGOF 9.1   La Declaración de Arquitectura de Trabajo creado en la Fase A de la parte II: Arquitectura Método de Desarrollo () es efectivamente un contrato de Arquitectura entre la organización de la arquitectura y el patrocinador de la arquitectura de la empresa (o la función de gobierno de TI). El desarrollo de uno o más dominios de la arquitectura (de negocios, datos, aplicaciones, tecnología), y en algunos casos, la supervisión de la arquitectura general de la empresa, puede contratar a los integradores de sistemas, proveedores de aplicaciones, y / o proveedores de servicios. Cada uno de estos acuerdos normalmente se regirá por un contrato de Arquitectura que define las prestaciones, la calidad y la aptitud para el propósito de la arquitectura desarrollada, y los procesos por los que los socios en el desarrollo de la arquitectura van a trabajar juntos. Al inicio de la fase G (Gobernanza de Implementación), entre la función de la arquitectura y la función de responsable de la aplicación de la arquitectura de la empresa se define en las fases anteriores de . Normalmente, este será o bien la función de desarrollo de sistemas en la empresa, o de un importante contratista a quien se contrata la obra. o ¿Qué se está "implementada" en la Fase G del es la arquitectura general de la empresa. En general, abarca la infraestructura de tecnología (de la Fase D), y también aquellas aplicaciones empresariales y capacidades de gestión de datos que se han definido en la arquitectura de aplicaciones y arquitectura de datos (a partir de la fase C), ya sea porque son de toda la empresa en el ámbito de aplicación, o porque son estratégicos en términos de negocio, y por lo tanto de importancia y visibilidad en toda la empresa. Sin embargo, normalmente no incluyen aplicaciones de negocio no estratégicas, que las unidades de negocio serán posteriormente desplegar en la parte superior de la infraestructura de la tecnología que se implementa como parte de la arquitectura de la empresa. o En las implementaciones de gran escala, bien puede ser uno de licitación Arquitectura por el equipo de implementación de un programa de proyectos de implementación. Cuando la arquitectura de la empresa ha puesto en práctica (al final de la fase G), un Contrato de Arquitectura normalmente se elaborará entre la función architecting ( o la función de gobierno de TI, que subsume la función architecting) y los s de negocios que posteriormente se construye y la implementación de sistemas de aplicaciones en el entorno con arquitectura.

Es importante tener en cuenta en todos los casos en que el objetivo final no es sólo una empresa de arquitectura, sino una arquitectura empresarial dinámico; es decir, aquella que permite la evolución flexibles en respuesta a los cambios en los conductores de tecnología y negocios, sin restricciones innecesarias. El Contrato de Arquitectura es crucial para permitir una dinámica arquitectura de la empresa y es clave para que rige la aplicación. Los contenidos típicos de estas tres clases de Arquitectura Contrato se explican a continuación.

49.2 Contenido Página 604 de 670

The Open Group Architecture Framework TOGOF 9.1   49.2.1 Declaración de Arquitectura de Trabajo

La Declaración de Arquitectura Trabajo se crea como un entregable de la fase A, y es efectivamente un contrato de Arquitectura entre la organización de la arquitectura y el patrocinador de la arquitectura de la empresa (o la función de gobierno de TI, en nombre de la empresa). Los contenidos típicos de una Declaración de Trabajo de Arquitectura son los definidos en la Parte IV , 36.2.20 Declaración de Arquitectura de Trabajo . 49.2.2 Contrato entre Arquitectura y Socios de Desarrollo

Esta es una declaración de intención firmada en el diseño y el desarrollo de la arquitectura de la empresa, o de una parte significativa de la misma, de las organizaciones asociadas, incluyendo integradores de sistemas, proveedores de aplicaciones y proveedores de servicios. Cada vez más el desarrollo de uno o más dominios de la arquitectura (de negocios, datos, aplicaciones, tecnología) puede ser subcontratada, con la función de la arquitectura de la empresa que proporciona la supervisión de la arquitectura general de la empresa, y la coordinación y el control del esfuerzo general. En algunos casos, incluso esta función de supervisión puede ser contratado, aunque la mayoría de las empresas prefieren mantener que la responsabilidad principal en la casa. Cualesquiera que sean los detalles de los acuerdos de contratación externa, los propios arreglos normalmente se rigen por un contrato de Arquitectura que define las prestaciones, la calidad y la aptitud para el propósito de la arquitectura desarrollada, y los procesos por los que los socios en el desarrollo de la arquitectura trabajarán juntos. Contenido típico de un diseño y desarrollo de contratos de Arquitectura son: Introducción y antecedentes La naturaleza del acuerdo Alcance de la arquitectura Arquitectura y estratégicos principios y los requisitos Los requisitos de conformidad Proceso y las funciones de desarrollo y gestión de la Arquitectura Medidas arquitectura objetivo Fases definidas de entregables Plan de trabajo conjunto priorizado

Página 605 de 670

The Open Group Architecture Framework TOGOF 9.1   Ventana de tiempo (s) Arquitectura de entrega y de negocios métricas

La plantilla para este contrato normalmente se define como parte de la Fase Preliminar de la , si no es que ya existe, y el contrato específico se definirá en la fase adecuada de la , en función de la obra en particular que se está subcontratado. 49.2.3 Función Contrato entre la arquitectura y los s de Negocio

Esta es una declaración firmada de la intención de cumplir con la arquitectura de la empresa, expedida por los s de negocio de la empresa. Cuando la arquitectura de la empresa ha puesto en práctica (al final de la Fase F), un Contrato de Arquitectura normalmente se elaborará entre la función architecting ( o la función de gobierno de TI, que subsume la función architecting) y los s de negocios que posteriormente se construye y la implementación de sistemas de aplicaciones en el entorno con arquitectura. Los contenidos típicos de la arquitectura de licitación de un negocio de los s son: Introducción y antecedentes La naturaleza del acuerdo Alcance Requisitos estratégicos Entregables Arquitectura que cumplan con los requisitos de negocio Los requisitos de conformidad Arquitectura adoptantes Ventana de tiempo Arquitectura métricas de negocio Arquitectura de servicios (que incluye el contrato de nivel de servicio (SLA))

Este contrato también se utiliza para istrar los cambios en la arquitectura de la empresa en la Fase H.

49.3 Relación con la arquitectura de la gobernanza El documento de la Arquitectura Contrato produce en Fase G de las figuras lugar destacado en el ámbito de la gobernanza arquitectura, como se explica en la Parte VII , 50. Arquitectura de Gobierno .

Página 606 de 670


En el contexto de la gobernanza arquitectura, el Contrato de Arquitectura se utiliza a menudo como un medio para impulsar el cambio de la arquitectura. Con el fin de garantizar que el Contrato Arquitectura es eficaz y eficiente, puede ser necesario introducir en la fase G, los siguientes aspectos de la normativa de gobierno: Procesos simples Autoridad centrado en las personas Comunicación fuerte Las respuestas oportunas y un proceso de escalada efectiva Apoyo a las estructuras organizativas El seguimiento del estado de implementación de la arquitectura

Página 607 de 670




50. Arquitectura de Gobierno Este capítulo proporciona un marco y directrices para la gobernanza de la arquitectura.

50.1 Introducción En esta sección se describe la naturaleza de la gobernanza, y los niveles de gobernanza. 50.1.1 Niveles de Gobierno dentro de la empresa

Gobernabilidad Arquitectura es la práctica y la orientación en la que las arquitecturas empresariales y otras arquitecturas son gestionados y controlados a nivel de toda la empresa. Gobernabilidad Arquitectura típicamente no funciona de manera aislada, sino dentro de una jerarquía de las estructuras de gobierno, que, sobre todo en la empresa más grande, pueden incluir todos los siguientes dominios distintos con sus propias disciplinas y procesos: El gobierno corporativo Gobernabilidad Tecnología Gobierno de TI Gobernabilidad Arquitectura

Cada uno de estos dominios de gobierno puede existir en diversos niveles geográficos mundial, regional y local - dentro de la empresa en general. El gobierno corporativo es, pues, un tema muy amplio, más allá del alcance de un marco de arquitectura de la empresa, tales como TOGAF. Este y otros apartados se centran en la gobernanza de arquitectura; pero ellos lo describen en el contexto de la gobernabilidad en toda la empresa, debido a la jerarquía de las estructuras de gobierno en el que por lo general opera, como se explicó anteriormente. En particular, esta sección y las siguientes tienen por objeto: Proporcionar una visión general de la naturaleza de la gobernanza como una disciplina por derecho propio Describir el contexto de la gobernanza en la que el gobierno arquitectura típicamente funciona dentro de la empresa

Página 608 de 670

The Open Group Architecture Framework TOGOF 9.1   Describir un marco de gobernanza de Arquitectura que se pueden adaptar y aplicar en la práctica, tanto para la arquitectura de la empresa y de otras formas de la arquitectura de TI

50.1.2 Naturaleza de la Gobernabilidad 50.1.2.1 Gobernabilidad: una perspectiva genérica

La gobernanza es esencial en asegurar que el negocio se lleva a cabo correctamente. Es menos sobre el control manifiesto y el cumplimiento estricto de las normas, y más acerca de la orientación y eficaz y la utilización equitativa de los recursos para asegurar la sostenibilidad de los objetivos estratégicos de la organización. A continuación se describen los principios básicos de la gestión empresarial, identificados por la Organización para la Cooperación y el Desarrollo Económicos (OCDE): Se centra en los derechos, las funciones y el tratamiento equitativo de los accionistas Comunicación y transparencia y las responsabilidades de la junta Asegura: o Sonido orientación estratégica de la organización o La vigilancia eficaz de la gestión de la junta o la rendición de cuentas Junta para la empresa y para los accionistas Las responsabilidades de la Junta: o revisión y dirección de la estrategia corporativa o Configuración y supervisión del cumplimiento de los objetivos de desempeño de la gerencia

Apoyando esto, la OCDE considera una visión tradicional de la gobernanza como: "... el sistema por el cual las corporaciones de negocios son dirigidas y controladas La estructura de gobierno corporativo especifica la distribución de derechos y responsabilidades entre los diferentes participantes en la empresa - tales como el tablero. , gerentes, accionistas y otras partes interesadas - y detalla las normas y procedimientos para la toma de decisiones en asuntos corporativos Al hacer esto, sino que también proporciona la estructura a través del cual se los objetivos de la empresa. establecen, y los medios para alcanzar dichos objetivos y la supervisión del rendimiento "[OCDE (1999)]. 50.1.2.2 Características de Gobernabilidad

Las siguientes características han sido adaptados de Gobierno Corporativo (Naidoo, 2002) y se coloca aquí para poner de relieve el valor y la necesidad de una gobernanza como un enfoque que se adoptará dentro de las organizaciones y sus relaciones con todas las partes involucradas: Página 609 de 670

The Open Group Architecture Framework TOGOF 9.1   Disciplina Todas las partes interesadas tendrán un compromiso de cumplir con los procedimientos, los procesos y las estructuras de autoridad establecidos por la organización. Transparencia Todas las acciones implementadas y su apoyo a las decisiones estarán disponibles para su inspección por las partes de la organización y los proveedores autorizados. Independencia Todos los procesos, toma de decisiones y los mecanismos utilizados se establecerán con el fin de minimizar o evitar potenciales conflictos de interés. Responsabilidad Grupos identificables dentro de la organización - por ejemplo, las juntas de gobierno que toman las acciones o tomar decisiones - están autorizados y responsables de sus actos. Responsabilidad Se requiere que cada parte contratada para actuar con responsabilidad para la organización y sus grupos de interés. Justicia Todas las decisiones tomadas, los procesos utilizados y su aplicación no se les permitirá crear una ventaja injusta a ningún partido en particular.

Gobernanza 50.1.3 Tecnología

Controla la gobernanza Tecnología cómo una organización utiliza la tecnología en la investigación, desarrollo y producción de sus productos y servicios. A pesar de que puede incluir las actividades de gobierno de TI, a menudo tiene un alcance más amplio. Gobierno La tecnología es una capacidad clave, requisitos y recursos para la mayoría de las organizaciones debido a la omnipresencia de la tecnología en todo el espectro de la organización. Estudios recientes han demostrado que muchas organizaciones tienen un saldo a favor de los intangibles más que tangibles que requieren gestión. Dado que la mayoría de estos intangibles son activos informativos y digitales, es evidente que las empresas son cada vez más dependientes de la TI, y la gobernabilidad de TI - El gobierno de TI - por lo tanto, se está convirtiendo en una parte aún más importante de la gestión de la tecnología. Estas tendencias también destacan las dependencias de las empresas no sólo en la información en sí, sino también los procesos, sistemas y estructuras que crean, ofrecen y consumen. A medida que el cambio hacia el aumento de valor a través de intangibles Página 610 de 670


aumenta en muchos sectores de la industria, por lo que la gestión del riesgo debe ser considerado como la clave para la comprensión y la moderación de los nuevos desafíos, amenazas y oportunidades. No sólo son organizaciones que dependen cada vez más de la información para sus operaciones y la rentabilidad, sino también su reputación, la marca, y en última instancia, sus valores también dependen de la misma información y la tecnología de apoyo. 50.1.4 Gobierno de TI

Gobierno de TI proporciona el marco y la estructura que une los recursos de TI y la información a los objetivos y estrategias de la empresa. Por otra parte, el gobierno de TI institucionaliza las mejores prácticas para la planificación, adquisición, implementación y monitoreo de desempeño de TI, para asegurarse de que los activos de TI de la empresa apoyan sus objetivos de negocio. En los últimos años, el gobierno de TI se ha convertido en parte integral de la gobernanza efectiva de la empresa moderna. Las empresas son cada vez más dependientes de TI para apoyar las funciones críticas del negocio y los procesos; y para ganar con éxito la ventaja competitiva, las empresas necesitan para gestionar eficazmente la tecnología compleja que es un fenómeno generalizado en toda la organización, con el fin de responder de manera rápida y segura a las necesidades empresariales. Además, los entornos normativos de todo el mundo están exigiendo cada vez más estricto control de la empresa sobre la información, impulsada por el aumento de los informes de los desastres del sistema de información y el fraude electrónico. La gestión de los riesgos relacionados con las TI es ahora ampliamente aceptada como una parte clave de la gobernanza empresarial. De ello se desprende que una estrategia de gobierno de TI, y una organización adecuada para la implementación de la estrategia, deben ser establecidas con el apoyo de la alta dirección, aclarando que es dueño de los recursos de TI de la empresa, y, en particular, que tiene la responsabilidad última de su integración en toda la empresa . 50.1.4.1 Un Controles de TI Marco - COBIT

Al igual que con el gobierno corporativo, gobierno de TI es un tema muy amplio, más allá del alcance de un marco de arquitectura de la empresa, tales como TOGAF. Una buena fuente de información detallada sobre el gobierno de TI es el marco COBIT (Objetivos de Control para la Información y Tecnologías Relacionadas). Este es un estándar abierto para el control de TI, desarrollado y promovido por el Instituto de Gobierno de TI, y publicado por la Information Systems Audit y Control Foundation (ISACF). Controles de COBIT pueden proporcionar una ayuda útil a la ejecución de una estrategia de cumplimiento. Un mapeo integral entre TOGAF y COBIT está disponible que guía al practicante en la Página 611 de 670


aplicación de la gobernanza arquitectura alineado con el gobierno de TI: Mapeo de TOGAF 8.1Con . COBIT 4.0, por el IT Governance Institute (ITGI) 1 50.1.5 Arquitectura de Gobierno: Visión general 50.1.5.1 arquitectura de gobernanza Características

Gobernabilidad Arquitectura es la práctica y la orientación en la que las arquitecturas empresariales y otras arquitecturas son gestionados y controlados a nivel de toda la empresa. Incluye lo siguiente: La implementación de un sistema de controles sobre la creación y el seguimiento de todos los componentes y actividades de arquitectura, para garantizar la efectiva introducción, implantación y evolución de arquitecturas dentro de la organización La implementación de un sistema para garantizar el cumplimiento de las normas internas y externas y las obligaciones reglamentarias El establecimiento de procesos de apoyo a la gestión eficaz de los procesos anteriores dentro de los parámetros acordados El desarrollo de prácticas que garanticen la rendición de cuentas a una comunidad claramente identificadas las partes interesadas, tanto dentro como fuera de la organización 50.1.5.2 Arquitectura gobernanza como una responsabilidad del nivel de dirección

Como se mencionó anteriormente, el gobierno de TI se ha convertido recientemente en una responsabilidad bordo como parte de la gobernanza empresarial en general. El gobierno de las arquitecturas de una organización es un factor clave en la vinculación de TI / negocio eficaz, y por lo tanto es cada vez más una tecla de responsabilidad a nivel de placa en su propio derecho. Esta sección tiene como objetivo proporcionar el impulso para la apertura de TI y la gestión de arquitectura para que las responsabilidades empresariales asociados con las actividades de la arquitectura y los artefactos pueden ser dilucidados y gestionados. 50.1.5.3 TOGAF y Arquitectura de Gobierno

Fase G del TOGAF (véase parte II , 15 Fase G:. Gobernanza Aplicación ) está dedicado a la gobernanza de ejecución, que se ocupa de la realización de la arquitectura a través de los proyectos de cambio. Gobernabilidad implementación es sólo un aspecto de la gobernanza arquitectura, que abarca la gestión y el control de todos los aspectos del desarrollo y la evolución de las arquitecturas empresariales y otras arquitecturas dentro de la empresa. Gobernabilidad Arquitectura necesita ser apoyado por un marco de gobernanza Arquitectura (descrito en 50.2 Arquitectura Governance Framework ), que ayuda a identificar los procesos efectivos para que las responsabilidades empresariales asociados a la Página 612 de 670


gobernabilidad arquitectura pueden ser dilucidados, comunicadas, y gestionadas con eficacia.

50.2 Arquitectura del marco de la gobernanza En esta sección se describe un marco conceptual y organizativo para la gobernanza de la arquitectura. Como se ha explicado anteriormente, la fase G del TOGAF (ver Parte II , 15. Fase G: Gobernanza Aplicación ) está dedicado a la gobernanza de ejecución, que se ocupa de la realización de la arquitectura a través de los proyectos de cambio. Gobernabilidad implementación es sólo un aspecto de la gobernanza arquitectura, que abarca la gestión y el control de todos los aspectos del desarrollo y la evolución de las arquitecturas empresariales y otras arquitecturas dentro de la empresa. Gobernabilidad Arquitectura necesita ser apoyado por un marco de gobernanza Arquitectura, se describe a continuación. El marco del gobierno de describir es un marco genérico que se puede adaptar al entorno de gobernanza existente de una empresa. Se tiene la intención de ayudar en la identificación de procesos eficaces y de organización de estructuras, de modo que las responsabilidades empresariales asociados a la gobernabilidad arquitectura pueden ser dilucidados, comunicadas, y gestionadas con eficacia. 50.2.1 Arquitectura del marco de gobernanza ‐ Estructura conceptual 50.2.1.1 Conceptos clave

Conceptualmente, la gobernabilidad arquitectura es un enfoque, una serie de procesos, una orientación cultural, y un conjunto de responsabilidades de propiedad que garanticen la integridad y la eficacia de las arquitecturas de la organización. Los conceptos clave se ilustran en la Figura 50-1 .

Página 613 de 670


Figura 50‐1: Arquitectura Governance Framework ‐ Estructura conceptual

La división del proceso, el contenido y el contexto son clave para el apoyo de la iniciativa de gobierno arquitectura, por lo que permite la introducción de nuevo material de gobierno (legal, reglamentaria, basada en estándares, o legislativo) sin afectar indebidamente los procesos. Este enfoque de contenido agnóstico asegura que el marco es flexible. Los procesos suelen ser independiente del contenido y poner en práctica un enfoque de mejores prácticas probadas de la gobernanza activa. El Marco de Gobierno La arquitectura es parte integral de la empresa Continuum, y gestiona todo el contenido relevante, tanto para la propia arquitectura y para los procesos de gobernanza de la arquitectura. 50.2.1.2 Procesos Clave arquitectura de la gobernanza

Se requieren procesos de gobierno para identificar, gestionar, auditar y difundir toda la información relacionada con la gestión de la arquitectura, los contratos y la ejecución. Estos procesos de gestión servirá para asegurarse de que todos los artefactos de la arquitectura y de los contratos, los principios y los acuerdos de nivel operativo son monitoreados en forma permanente con capacidad de auditoría clara de todas las decisiones tomadas. Página 614 de 670

The Open Group Architecture Framework TOGOF 9.1   Gestión de Políticas y Take-On

Todas las modificaciones de arquitectura, los contratos y la información de apoyo deben estar bajo el gobierno a través de un proceso formal para registrar, validar, ratificar, istrar y publicar contenido nuevo o actualizado. Estos mecanismos servirán para garantizar la integración ordenada con contenido de gobierno existente de tal manera que todas las partes relevantes, documentos, contratos y la información de apoyo son istrados y auditados. Conformidad

Las evaluaciones del cumplimiento contra los Acuerdos de Nivel de Servicio (SLAs), Acuerdos de Nivel Operacional (OLA), las normas y los requisitos reglamentarios se llevarán a cabo de manera continua para garantizar la estabilidad, la conformidad y supervisión del rendimiento. Estas evaluaciones serán revisadas y aceptadas o rechazadas en función de los criterios definidos en el marco de gobernanza. Dispensa

Una evaluación de la conformidad puede rechazarse cuando la materia (diseño, funcionamiento, nivel de servicio o la tecnología) no son compatibles. En este caso, el tema puede: 1. Ser ajustado o reajustado a fin de satisfacer los requisitos de cumplimiento 2. Solicite una dispensación

En caso de rechazo de una Evaluación de Cumplimiento, una ruta alternativa para el cumplimiento de la conformidad provisional se proporciona a través de las dispensaciones. Éstos se conceden por un periodo de tiempo determinado y un conjunto de servicios identificados y criterios operacionales que deben ser ejecutadas durante la vida útil de la dispensación. Las dispensaciones no se otorgan por tiempo indefinido, pero se utilizan como un mecanismo para asegurar que los niveles de servicio y los niveles operativos se cumplen mientras que proporciona un nivel de flexibilidad en su aplicación y el tiempo. La naturaleza de duración determinada de dispensaciones asegura que son un disparador importante en el ciclo de cumplimiento. Control y seguimiento

Se requiere una gestión de rendimiento para asegurar que tanto los elementos operativos y de servicios se gestionan en contra de un conjunto acordado de criterios.Esto incluirá la vigilancia contra los acuerdos de servicio y de nivel operativo, los comentarios para el ajuste y presentación de informes. Información de gestión interna se considerará en Gestión Ambiental . Página 615 de 670

The Open Group Architecture Framework TOGOF 9.1   Control para Empresas

Control para Empresas se relaciona con los procesos alegadas para garantizar el cumplimiento de las políticas comerciales de la organización. Gestión Ambiental

Esto identifica todos los servicios necesarios para asegurar que el medio ambiente basada en un repositorio que sustenta el marco de gobierno es eficaz y eficiente.Esto incluye la gestión física y lógica repositorio, , comunicación, formación y acreditación de todos los s. Todos los artefactos arquitectura, contratos de servicio, contratos, e información de apoyo deben estar bajo el gobierno a través de un proceso formal para registrar, validar, ratificar, istrar y publicar contenido nuevo o actualizado. Estos mecanismos servirán para garantizar la integración ordenada con contenido de gobierno existente de tal manera que todas las partes relevantes, documentos, contratos y la información de apoyo son istrados y auditados. El ambiente de gobernabilidad tendrá una serie de procesos istrativos definidos con el fin de efectuar un servicio gestionado y entorno del proceso. Estos procesos incluyen la gestión de s, SLA internos (definidos con el fin de controlar sus propios procesos), y la información de gestión de informes. 50.2.2 Arquitectura del marco de gobernanza ‐ Estructura Organizacional 50.2.2.1 Información general

Gobernabilidad Arquitectura es la práctica y la orientación en la que las arquitecturas empresariales y otras arquitecturas son gestionados y controlados. Con el fin de garantizar que este control es eficaz dentro de la organización, es necesario contar con las estructuras organizativas correctas establecidas para apoyar todas las actividades de gobierno. Una estructura de gobierno arquitectura para la aplicación efectiva del enfoque descrito en esta sección incluirá típicamente los siguientes niveles, que pueden en la práctica implican una combinación de procesos de TI existentes de gobierno, las estructuras organizativas y capacidades. Ellos suelen incluir lo siguiente: Junta de gobierno Global Junta de Gobierno Local Autoridades de Diseño Grupos de trabajo

Página 616 de 670


La organización arquitectura se ilustra en la Figura 50-2 se destacan los principales elementos estructurales necesarios para una iniciativa de gobierno arquitectura. Si bien cada empresa tendrá diferentes necesidades, se espera que los fundamentos del diseño de la organización se muestra en la Figura 50-2 se aplicarán y aplicables en una amplia variedad de tipos de organización.

Figura 50‐2: Arquitectura Governance Framework ‐ Estructura Organizacional 50.2.2.2 Áreas Clave Figura 50-2 identifica tres áreas clave de la gestión de la arquitectura: Desarrollar,

implementar y desplegar. Cada uno de ellos es la responsabilidad de uno o varios grupos dentro de la organización, mientras que la empresa Continuum se muestra para apoyar todas las actividades y los artefactos asociados a la gobernanza de las arquitecturas en todo su ciclo de vida. Los Desarrollar responsabilidades, procesos y estructuras suelen estar vinculadas a la TOGAF y su uso, mientras que las responsabilidades Implementar, procesos y estructuras generalmente están vinculados a la fase G (véase la Parte II , 15 Fase G:. Gobernanza Aplicación ). Página 617 de 670


Como se mencionó anteriormente, el Marco de Gobierno La arquitectura es parte integral de la empresa Continuum, y gestiona todo el contenido relevante, tanto a los propios como a los procesos de gobernanza configuraciones configuración. 50.2.2.3 Beneficios operacionales

Como se ilustra en la Figura 50-2 , la gobernanza de las arquitecturas de la organización no sólo proporciona el control directo y la orientación de su desarrollo y aplicación, pero también se extiende a las operaciones de las arquitecturas implementadas. Se han encontrado los siguientes beneficios que se derivan a través de la continua gobierno de arquitecturas: Enlaces procesos de TI, los recursos y la información a las estrategias y objetivos de la organización Se integra e institucionaliza las mejores prácticas de Alinea con los marcos de la industria tales como COBIT (planificación y organización, adquisición e implementación, entrega y apoyo, y el seguimiento del desempeño de TI) Permite a la organización a sacar el máximo provecho de sus activos de información, de infraestructura y de hardware y software Protege los activos digitales subyacentes de la organización Soporta requisitos de prácticas de regulación y mejores como la auditabilidad, la seguridad, la responsabilidad y la rendición de cuentas Promueve la gestión del riesgo visible

Estos beneficios se posicionan Governance Framework TOGAF Arquitectura como un enfoque, una serie de procesos, una orientación cultural, y un conjunto de propiedad de responsabilidades, que juntos asegurar la integridad y la eficacia de las arquitecturas de la organización.

50.3 Arquitectura de Gobierno en la Práctica Esta sección proporciona directrices prácticas para la aplicación eficaz de gobernanza de la arquitectura. Factores claves de éxito ‐ 50.3.1 Arquitectura de Gobierno

Es importante tener en cuenta lo siguiente para asegurar un enfoque exitoso para el gobierno arquitectura, y para la gestión eficaz del Contrato de Arquitectura:

Página 618 de 670

The Open Group Architecture Framework TOGOF 9.1   Mejores prácticas para la presentación, la adopción, la reutilización, la notificación y el retiro de las políticas de arquitectura, procedimientos, funciones, competencias, estructuras organizativas, y servicios de apoyo Responsabilidades y estructuras de apoyo a los procesos de gobernanza de arquitectura y requisitos de información de la Organización Integración de las herramientas y procesos para facilitar la asimilación de los procesos, tanto de procedimiento y culturalmente Criterios para el control de los procesos de gobierno arquitectura, dispensas, evaluaciones de cumplimiento, SLAs y OLAs Requisitos internos y externos para la eficacia, eficiencia, confidencialidad, integridad, disponibilidad, cumplimiento y confiabilidad de toda la información relacionada con la arquitectura de gobernanza-, los servicios y los procesos

50.3.2 Elementos de una Estrategia de Gobernabilidad Efectiva Arquitectura 50.3.2.1 Arquitectura Gobernabilidad y Política Corporativa

Una arquitectura empresarial impuesta sin el apoyo político adecuado está condenada al fracaso. Para tener éxito, la arquitectura de la empresa debe reflejar las necesidades de la organización. Los arquitectos de la empresa, si no están implicados en el desarrollo de la estrategia de negocio, por lo menos deben tener una comprensión fundamental de la misma y de los problemas de negocio imperantes que enfrenta la organización. Incluso puede ser necesario para que puedan participar en el proceso de implementación del sistema y de poseer en última instancia, las decisiones de inversión y selección de productos derivados de la aplicación de la Tecnología de la Arquitectura. Hay tres elementos importantes de la estrategia de gobierno de la arquitectura que se refieren en particular a la aceptación y el éxito de la arquitectura dentro de la empresa. Mientras relevantes y aplicables en su propio derecho, aparte de su papel en el gobierno, y por lo tanto, describe por separado, sino que también de una parte integral del cualquier estrategia de gobierno arquitectura eficaz. Una Junta de Arquitectura de toda la Organización (véase 47. Architecture Board ) se debe establecer con el respaldo de la alta dirección para supervisar la aplicación de la estrategia de gobierno de TI. Un completo conjunto de principios de la arquitectura (véase 23. Principios de Arquitectura debe establecerse), para orientar, informar y apoyar la forma en que una organización se marca sobre el cumplimiento de su misión a través de la utilización de las TI. Una Cumplimiento Arquitectura (ver . 48 Arquitectura Cumplimiento ) estrategia debe ser adoptada - medidas específicas (algo más que una declaración de política) para garantizar el cumplimiento de la arquitectura, incluyendo las evaluaciones de impacto de proyectos, un proceso de revisión de Cumplimiento Arquitectura formal, y, posiblemente, incluso mediante la integración del equipo de arquitectura de la contratación del producto.

Página 619 de 670




Página 620 de 670




51. Arquitectura de Madurez Modelos Este capítulo proporciona técnicas para evaluar y cuantificar la madurez de una organización en la arquitectura de la empresa.

51.1 Información general Organizaciones que pueden gestionar el cambio con eficacia son generalmente más éxito que las que no pueden. Muchas organizaciones saben que necesitan para mejorar sus procesos con el fin de gestionar con éxito el cambio, pero no saben cómo. Tales organizaciones típicamente gastan muy poco en la mejora de procesos, porque no están seguros de cómo proceder mejor; o gastar mucho, en una serie de esfuerzos paralelos y desenfocadas, con poco o ningún resultado. Modelos de Madurez de Capacidad (CMM) abordan este problema al proporcionar un método eficaz y probado para una organización para ganar poco a poco el control y la mejora de sus procesos de cambio. Estos modelos proporcionan los siguientes beneficios: Describen las prácticas que cualquier organización debe llevar a cabo con el fin de mejorar sus procesos. Proporcionan un criterio para medir periódicamente la mejora. Constituyen un marco probado en el que la gestión de los esfuerzos de mejora. Organizan las diversas prácticas en niveles, cada nivel que representa una mayor capacidad para controlar y gestionar el entorno de desarrollo.

Una evaluación de las prácticas de la organización contra el modelo - llamado una "evaluación" - determina el nivel en el que se encuentra la organización en la actualidad. Indica la capacidad de la organización para ejecutar en la zona de que se trate, y las prácticas en las que la organización necesita para centrarse con el fin de ver la mejora más grande y el más alto retorno de la inversión. Los beneficios de MMCs para efectivamente esfuerzo directo están bien documentados.

51.2 Antecedentes El Instituto de Ingeniería de Software (SEI) - www.sei.cmu.edu operado por la Universidad Carnegie Mellon - desarrolló el CMM originales (Capability Maturity Model) para el Software (SWCMM) a principios de 1990, que sigue siendo ampliamente utilizado hoy. Esta CMM proporciona un marco para desarrollar modelos de madurez en una amplia gama de disciplinas. Página 621 de 670


El creciente interés en la aplicación de estas técnicas a otros campos ha dado lugar a una serie de herramientas de la plantilla que evalúan: El estado de los procesos de arquitectura La arquitectura Buy-in de la organización tanto a

Los principales temas abordados en estos modelos incluyen: Implementación de procesos y de auditoría Las mediciones de calidad Gente competencias Gestión de las inversiones

Implican el uso de una multiplicidad de modelos, y se centran en particular en la medición de los beneficios del negocio y retorno de la inversión. Un tema estrechamente relacionado es el Skills Framework Architecture (ver 52. Arquitectura Skills Framework ), que se puede utilizar para planificar las habilidades objetivo y capacidades requeridas por una organización para desarrollar y utilizar la arquitectura empresarial con éxito, y para determinar las necesidades de capacitación y desarrollo de individuos.

51.3 Marco de EE.UU. Departamento de Comercio ACMM 51.3.1 Información general

Como un ejemplo de la tendencia hacia un mayor interés en la aplicación de técnicas de CMM para la arquitectura empresarial, ahora se espera que todas las agencias federales de Estados Unidos para proporcionar modelos de madurez y clasificaciones como parte de sus requisitos de gestión de inversiones y de auditoría de TI. En particular, el Departamento de Comercio de EE.UU. (DoC) ha desarrollado una arquitectura empresarial Capability Maturity Model (ACMM ) 1 para ayudar en la realización de evaluaciones internas. ACMM versión 1.2 se publicó en diciembre de 2007. El ACMM proporciona un marco que representa los componentes clave de un proceso de arquitectura de la empresa productiva. El objetivo es mejorar las probabilidades generales para el éxito de la arquitectura empresarial mediante la identificación de las áreas débiles y proporcionar un camino evolutivo definido a mejorar el proceso global de la arquitectura. El ACMM se compone de tres secciones: 1. El modelo de madurez de la arquitectura empresarial Página 622 de 670

The Open Group Architecture Framework TOGOF 9.1   2. Características de arquitectura empresarial de los procesos de las unidades operativas en los diferentes niveles de madurez 3. El CMM scorecard arquitectura empresarial

Las dos primeras secciones se explica la arquitectura de los niveles de madurez de la capacidad y la arquitectura elemento personal empresa correspondiente y las características de cada nivel de madurez para ser utilizados como medidas en el proceso de evaluación. En la tercera sección se utiliza para obtener el nivel de madurez de capacidades Arquitectura que debe ser reportada a la Información Oficial Jefe Departamento de Comercio (CIO). 51.3.2 Elementos del ACMM

La Declaración ACMM consta de seis niveles de madurez y nueve elementos de la arquitectura. Los seis niveles son: 0 Ninguno 1 Inicial 2 En desarrollo 3 Definido 4 Gestionado 5 Medido

Los nueve elementos de la arquitectura de la empresa son los siguientes: 1. Proceso de Arquitectura 2. El desarrollo de la Arquitectura 3. Vinculación de negocios 4. Implicación personal directivo superior Página 623 de 670

The Open Group Architecture Framework TOGOF 9.1   5. Participación unidad de funcionamiento 6. Comunicación Arquitectura 7. Seguridad de TI 8. Gobernabilidad Arquitectura 9. Inversión en TI y la estrategia de adquisición

Dos métodos complementarios se utilizan en el ACMM para calcular una calificación de madurez. El primer método se obtiene una media de nivel de madurez de arquitectura empresarial ponderado. El segundo método muestra el porcentaje alcanzado en cada nivel de madurez para los nueve elementos de la arquitectura. 51.3.3 Ejemplo: Arquitectura Empresarial niveles de madurez de procesos

El siguiente ejemplo muestra las características detalladas de los niveles de madurez de arquitectura empresarial que se aplican a cada uno de los nueve elementos. Por ejemplo, el Nivel 3: Definido, el punto número 8 (gobernanza explícito documentado de la mayoría de las inversiones en TI), muestra el estado del Nivel de Madurez 3 por elemento 8 (Arquitectura de Gobierno). Nivel 0: Ninguno

Ningún programa de arquitectura de la empresa. No arquitectura empresarial que hablar. Nivel 1: Inicial

Informal proceso de arquitectura de la empresa en marcha. 1. Los procesos son ad hoc y localizada. Algunos procesos de arquitectura empresarial se definen. No hay proceso de la arquitectura unificada a través de tecnologías o procesos de negocio. El éxito depende de los esfuerzos individuales.

2. Procesos de arquitectura de la empresa, la documentación y las normas son establecidas por una variedad de especiales medios y son localizados o informal. 3. Minimal, vinculación o implícita de las estrategias de negocio o controladores de negocio. 4. Conocimiento limitado equipo de gestión o la participación en el proceso de la arquitectura. 5. Limited funcionamiento de la unidad de aceptación del proceso de arquitectura de la empresa. 6. La última versión de la documentación de la arquitectura empresarial de la unidad de mando está en la web. Existe poca comunicación sobre el proceso de arquitectura de la empresa y las mejoras posibles procesos.

Página 624 de 670

The Open Group Architecture Framework TOGOF 9.1   7. Consideraciones de seguridad de TI son ad hoc y localizada. 8. No gobernabilidad explícita de las normas arquitectónicas. 9. Poca o ninguna participación de personal de planificación y adquisiciones estratégicas en el proceso de arquitectura de la empresa. Poca o ninguna adherencia a los estándares existentes. Nivel 2: En desarrollo

Proceso de arquitectura de la empresa se encuentra en desarrollo. 1. Proceso básico de arquitectura empresarial se documenta sobre la base de la OMB Circular A-130 y el Departamento de Comercio de Arquitectura Empresarial de Orientación. El proceso de la arquitectura se ha desarrollado funciones y responsabilidades claras.

2. La visión de TI, los principios, los vínculos comerciales, de línea de base y Arquitectura objetivo se identifican. Existen normas Arquitectura, pero no necesariamente vinculados a Target Arquitectura. Modelo Referencia técnica (TRM) y el marco de las Normas perfil establecido.

3. Vinculación explícita con las estrategias de negocio. 4. Conciencia de Gestión de la arquitectura esfuerzo. 5. Asignación de responsabilidades y se está trabajando. 6. El Departamento de Comercio y de la unidad de funcionamiento las páginas web de arquitectura empresarial se actualizan periódicamente y se utilizan para documentar la arquitectura entregables.

7. Arquitectura de seguridad de TI ha definido roles y responsabilidades claras. 8. Gobernanza de unos estándares arquitectónicos y algunos adherencia al existente Perfil Normas. 9. Poco o ningún gobierno formal de la inversión en TI y la estrategia de adquisición. Equipo de operación demuestra la adhesión a alguna existente Perfil Normas. Nivel 3: Definido

Arquitectura empresarial Definido incluyendo procedimientos escritos detallados y TRM. 1. La arquitectura está bien definida y comunicada al personal de TI y la gestión empresarial con el equipo de operación responsabilidades de TI. El proceso se siguió en gran medida.

2. Se han completado el análisis de brechas y el Plan de Migración. TRM desarrollado plenamente y Normas perfil. IT objetivos y métodos se identifican. 3. Arquitectura empresarial está integrada con la planificación del capital y el control de las inversiones. Página 625 de 670

The Open Group Architecture Framework TOGOF 9.1   4. Equipo Directivo al tanto y apoya el proceso de arquitectura de toda la empresa. istración apoya activamente las normas arquitectónicas.

5. La mayoría de los elementos de la unidad de operación muestran aceptación o están participando activamente en el proceso de arquitectura de la empresa. 6. Arquitectura documentos actualizados regularmente en la empresa doc Página web arquitectura. 7. Arquitectura de seguridad de TI Normas perfil está totalmente desarrollado y se integra con la arquitectura empresarial. 8. Gobernabilidad explícita documentada de la mayoría de las inversiones en TI. 9. Existe una estrategia de adquisición de TI e incluye medidas de cumplimiento de la arquitectura de TI de la empresa. Beneficios económicos son considerados en la identificación de proyectos. Nivel 4: Gestionado

Gestionado y el proceso de arquitectura de la empresa medido. 1. Proceso de arquitectura de la empresa forma parte de la cultura. Las métricas de calidad asociados con el proceso de la arquitectura son capturados. 2. Documentación de la arquitectura Enterprise se actualiza en un ciclo regular para reflejar la arquitectura de la empresa actualizada. Arquitecturas de negocios, datos, aplicaciones y tecnología definida por el apropiado de jure y de facto normas.

3. La planificación de capital y control de las inversiones se ajustan en base a los comentarios recibidos y las lecciones aprendidas de la arquitectura empresarial actualizado. periódica nuevo examen de los impulsores del negocio.

4. Equipo de alta gerencia que participan directamente en el proceso de revisión de la arquitectura. 5. La unidad operativa entera acepta y participa activamente en el proceso de arquitectura de la empresa. 6. Arquitectura documentos se actualizan regularmente, y frecuentemente crítica para los últimos desarrollos de arquitectura / standards. 7. Métricas de desempeño asociados a la arquitectura de seguridad de TI son capturados. 8. Gobernabilidad explícita de todas las inversiones de TI. Los procesos formales para la gestión de las varianzas retroalimentan arquitectura empresarial. 9. Todas las adquisiciones y compras de TI planificadas son guiados y regidos por la arquitectura de la empresa. Nivel 5: Optimización

Página 626 de 670


Mejora continua del proceso de arquitectura de la empresa. 1. Concertada los esfuerzos para optimizar y mejorar continuamente el proceso arquitectura. 2. Un proceso de las normas y renuncias se utiliza para mejorar el proceso de desarrollo de la arquitectura. 3. Métricas de procesos Arquitectura se utilizan para optimizar e impulsar los vínculos comerciales. Negocios involucrado en las mejoras continuas de los procesos de la arquitectura empresarial.

4. Participación alta dirección en la optimización de mejoras en los procesos de desarrollo de la arquitectura y la gobernabilidad. 5. Comentarios sobre el proceso de la arquitectura de todos los elementos de la unidad de servicio se utiliza para impulsar mejoras en los procesos de la arquitectura. 6. Arquitectura documentos son utilizados por todos los que toma las decisiones en la organización para cada decisión de negocios relacionados con las TI. 7. La retroalimentación de TI arquitectura de seguridad métricas se utilizan para impulsar mejoras en los procesos de la arquitectura. 8. Gobernabilidad explícita de todas las inversiones de TI. Un proceso de las normas y renuncias se utiliza para hacer las mejoras de gobierno en procesos. 9. Sin inversión en TI no planificado o de la actividad de adquisición.

51.4 Modelos de Madurez de Capacidad de Integración (CMMI) 51.4.1 Introducción

Los modelos de capacidad que el SEI está actualmente involucrado en el desarrollo, expansión, o el mantenimiento son las siguientes: CMMI (Capability Maturity Model Integration) IPD-CMM (Desarrollo de Productos Integrada Capability Maturity Model) P-CMM (People Capability Maturity Model) SA-CMM (Software Acquisition Capability Maturity Model) SE-CMM (Ingeniería de Sistemas Capability Maturity Model) SW-CMM (Capability Maturity Model de Software)

Como se explica en este capítulo, en los últimos años la industria ha experimentado un crecimiento significativo en el área de modelos de madurez. La multiplicidad de modelos disponibles ha llevado a sus propios problemas, en cuanto a la forma de integrar todos los Página 627 de 670


diferentes modelos para producir una métrica con significado para la madurez del proceso global. En respuesta a esta necesidad, el SEI ha desarrollado un marco llamado Capability Maturity Model Integration (CMMI), para proporcionar un medio de gestionar la complejidad. Según el SEI, el uso de los modelos CMMI mejora en las mejores prácticas de los modelos anteriores en muchos aspectos importantes, en particular las organizaciones que permitan a: Vincular de forma más explícita las actividades de gestión y de ingeniería a los objetivos de negocio Ampliar el alcance y la visibilidad de las actividades del ciclo de vida del producto y de ingeniería para asegurar que el producto o servicio cumple con las expectativas del cliente Incorporar las lecciones aprendidas de otras áreas de las mejores prácticas (por ejemplo, medición, gestión de riesgos y la gestión de proveedores) Implementar prácticas de alta madurez más robustas Dirección funciones organizativas adicionales críticos para sus productos y servicios Más cumplir plenamente con las normas pertinentes de la ISO

CMMI se está adoptando en todo el mundo. 51.4.2 Método SCAMPI

El CMMI Método de evaluación estándar para la Mejora de Procesos (SCAMPI) es el método de evaluación asociada con CMMI. El método de evaluación SCAMPI se utiliza para identificar las fortalezas, debilidades, y valoraciones en relación con los modelos de referencia CMMI. Incorpora las mejores prácticas encontradas con éxito en la comunidad de evaluación, y se basa en las características de varios métodos de evaluación legado. Es aplicable a una amplia gama de modos de uso de evaluación, incluyendo tanto la mejora de procesos internos y externos determinaciones de capacidad. El documento de definición del método SCAMPI 2 se describen los requisitos, las actividades y las prácticas relacionadas con cada uno de los procesos que componen el método SCAMPI.

51.5 Conclusiones En esta sección se ha tratado de introducir en TOGAF el tema de los métodos y técnicas basadas en CMM para su uso en relación con la arquitectura empresarial. Los beneficios de usar MMCs están bien documentados. Las futuras versiones de TOGAF pueden incluir un modelo de madurez para medir la adopción de sí TOGAF. Página 628 de 670




52. Arquitectura Skills Framework En este capítulo se proporciona un conjunto de funciones, la habilidad y la experiencia de las normas para el trabajo de arquitectura de empresa del personal de la empresa.

52.1 Introducción . Habilidades marcos proporcionan una vista de los niveles de competencia requeridos para funciones específicas Definen: Los roles dentro de un área de trabajo Las habilidades que requiere cada función La profundidad de los conocimientos necesarios para cumplir la función con éxito

Son relativamente comunes para la definición de las competencias necesarias para una empresa de consultoría y / o cesión de gestión de proyectos, para entregar un proyecto específico o paquete de trabajo. También son muy utilizados por las agencias de contratación y de búsqueda para que coincida con los candidatos y los roles. Su valor se deriva de su capacidad para proporcionar un medio para identificar rápidamente partidos de habilidad y lagunas. Aplicado con éxito, pueden asegurar que los candidatos son aptos para los puestos de trabajo que tengan asignadas. Su valor en el contexto de la arquitectura de la empresa se debe a la inmadurez de la disciplina de arquitectura empresarial, y los problemas que surgen de esto.

52.2 Necesidad de un Marco de Arquitectura Empresarial Habilidades 52.2.1 Definitoria Rigor

"Arquitectura Empresarial" y "EA" son ampliamente utilizados pero hoy mal definidos los términos de la industria. Se utilizan para denotar una variedad de prácticas y habilidades aplicadas en una amplia variedad de dominios de arquitectura. Hay una necesidad de una mejor clasificación para permitir una comprensión más implícita de qué tipo de arquitectura / arquitecto que se está describiendo. Esta falta de uniformidad conduce a dificultades para las organizaciones que buscan contratar o asignar / promoción de personal para cubrir puestos en el campo de la arquitectura. Debido a los diferentes usos de los términos, a menudo la incomprensión y la Página 629 de 670


falta de comunicación entre los que buscan reclutar a favor, y los que tratan de llenar, los diferentes roles del arquitecto. 52.2.2 Bases de la Práctica de la Arquitectura Interior

A pesar de la falta de una terminología uniforme, habilidades de arquitectura están en el incremento de la demanda, ya que la disciplina de la arquitectura ganancias cada vez más atención en la industria. Muchas empresas han establecido, o están considerando la creación, una práctica de la arquitectura empresarial, como medio de fomentar el desarrollo de las habilidades y experiencia necesarias entre el personal de la casa para llevar a cabo las diferentes tareas requeridas por la arquitectura de la empresa. Una práctica de la arquitectura empresarial es un programa formal de desarrollo y certificación, mediante el cual una entidad reconoce formalmente la competencia de sus arquitectos en ejercicio, como se demuestra por su trabajo. Ese programa es esencial para asegurar la alineación de las capacidades del personal y la experiencia con las tareas de arquitectura que la empresa desee realizar. También se requiere que las definiciones de funciones y de competencias en el que un programa de este tipo tiene que basarse, por tanto el reclutamiento y las organizaciones que suministran, en los casos en que el personal externo ha sido contratada para realizar el trabajo de arquitectura (por ejemplo, como parte de un compromiso de consultoría). Una práctica de arquitectura de la empresa es difícil y costoso establecer. Normalmente se construye en torno a un proceso de revisión por pares, y consiste en el tiempo y el talento del liderazgo técnico estratégico de una empresa. Normalmente se trata de establecimiento de un comité de revisión de pares, y la documentación del proceso, y de los requisitos para la certificación interna. El tiempo también se exigió a los aspirantes a prepararse para la revisión por pares, mediante la creación de un portafolio de su trabajo para demostrar sus habilidades, experiencias y contribuciones a la profesión. El TOGAF Arquitectura Skills Framework intenta abordar esta necesidad proporcionando definiciones de las habilidades de la arquitectura y los niveles de competencia necesarios de personal, internos o externos, que vaya a realizar las diversas funciones Architecting definidos en el Marco TOGAF. Debido a la complejidad, el tiempo y costo, muchas empresas no cuentan con un programa interno de certificación de arquitecto de la empresa, prefiriendo en lugar de simplemente entrevistar y contratar a personal de la arquitectura en un ad hoc base. Existen riesgos graves asociados con este enfoque: La comunicación entre las organizaciones de reclutamiento, consultoras y agencias de empleo es muy difícil.

Página 630 de 670

The Open Group Architecture Framework TOGOF 9.1   El tiempo es perdido entrevistar al personal que puedan haber aplicado de buena fe, pero aún carecen de los conocimientos y / o experiencia requeridas por el empleador. El personal que son capaces de llenar papeles arquitectura puede ser pasado por alto, o no puede identificarse con las vacantes publicadas y por lo tanto ni siquiera aplicar. Hay mayor riesgo de personal inadecuados ser empleado o contratado, a través de la culpa de nadie, ya pesar de todos los involucrados que actúan de buena fe.Esto a su vez puede: o Aumentar los gastos de personal, a través de la necesidad de volver a contratar o reasignar personal o afectar negativamente el tiempo, costo y calidad de los sistemas de TI operacionales y los proyectos que les ofrecen

52,3 Goles / Justificación 52.3.1 Certificación de Enterprise Architects

El propósito principal de un establecimiento de un programa interno de certificación de arquitecto de la empresa de la empresa es doble: 1. Reconocer formalmente a la habilidad de sus arquitectos en ejercicio, como parte de la tarea de establecer y mantener una organización architecting profesional 2. Para asegurar la alineación de las capacidades del personal necesario y la experiencia con las tareas de arquitectura que la empresa desea realizar, si éstos se van a realizar internamente a la empresa o en el exterior; por ejemplo, como parte de un compromiso de consultoría

52.3.2 Beneficios específicos

Los beneficios específicos previstos por el uso del TOGAF Arquitectura Skills Framework incluyen: Reducción del tiempo, el costo y el riesgo en la formación, la contratación y la gestión de profesionales de la arquitectura, tanto internos como externos: o la comunicación entre las organizaciones de reclutamiento Simplifica, consultoras y agencias de empleo o Evita perder tiempo entrevistando a personal que puedan haber aplicado de buena fe, pero aún carecen de los conocimientos y / o experiencia requeridas por el empleador

Página 631 de 670

The Open Group Architecture Framework TOGOF 9.1   o personal evita que son capaces de llenar papeles Arquitectura ser pasado por alto, o no se identifican con las vacantes publicadas y por lo tanto ni siquiera aplicando Tiempo y costo para establecer una práctica de la arquitectura interna reducida: o Muchas empresas no tienen una práctica de la arquitectura interna debido a la complejidad de instalar uno, prefiriendo en lugar de simplemente entrevistar y contratar a personal de la arquitectura en un ad hoc base. o Al proporcionar definiciones de las habilidades de la arquitectura y los niveles de competencia requeridos del personal que vaya a realizar las diversas funciones definidas dentro de la arquitectura de TOGAF, el Skills Framework Architecture reduce enormemente el tiempo, el costo y el riesgo de la creación de una práctica por primera vez, y evita "llantas de re-inventar". o Las empresas que ya tienen una práctica de la arquitectura interna son capaces de establecer normas para toda la empresa, pero aún así experimentar dificultades como se indica más arriba en la contratación de personal o consultores atractivas, de fuentes externas, debido a la falta de uniformidad entre las distintas empresas. Al alinear su marco de competencias existente con las definiciones aceptadas en la industria proporcionados por The Open Group, una empresa puede simplificar en gran medida estos problemas. Reducción del tiempo y el costo de implementar un estudio de arquitectura ayuda a reducir el tiempo, costo y riesgo de desarrollo global de la solución: o Las empresas que no tienen una práctica de la arquitectura interna corren el riesgo de personal inadecuados está empleada o contratada, a través de la culpa de nadie, ya pesar de todos los involucrados que actúan de buena fe. El tiempo y costo resultantes penas superan con creces el tiempo y el costo de tener un estudio de arquitectura interior:  Los gastos de personal se incrementan, a través de la necesidad ocasional de volver a contratar o reasignar personal.  Aún más importante es el impacto adverso sobre el tiempo, costo y calidad de los sistemas de TI operacionales y los proyectos para lanzarlas, como resultado de malas asignaciones del personal.

52.4 Arquitectura Empresarial de rol y Habilidad Categorías 52.4.1 Información general

En esta sección se describe el papel de un arquitecto de la empresa, las habilidades fundamentales que se requieren, y algunas disciplinas posibles en que un arquitecto de la empresa puede especializarse.

Página 632 de 670


TOGAF ofrece una empresa de arquitectura, y por lo tanto requiere de los negocios y los profesionales capacitados de TI para desarrollar la arquitectura de la empresa. El TOGAF Arquitectura Skills Framework proporciona una vista de los niveles de competencia para las funciones específicas dentro del equipo de arquitectura de la empresa. El marco define: Los roles dentro de un área de trabajo de arquitectura empresarial Las habilidades requeridas por esos roles La profundidad de los conocimientos necesarios para cumplir cada función con éxito

El valor está en que proporciona un medio rápido para la identificación de las habilidades y las lagunas. Aplicado con éxito, el marco puede ser utilizado como una medida para: El desarrollo del personal Asegurar que la persona correcta hace el trabajo adecuado

52.4.2 Roles TOGAF

Un equipo típico de la arquitectura de emprender el desarrollo de una empresa de arquitectura como se describe en TOGAF comprendería las siguientes funciones: Los de la Junta de Arquitectura Arquitectura Patrocinador Arquitectura del Arquitectos para: o Enterprise Architecture (que para el propósito de las tablas que se muestran a continuación se puede considerar como un superconjunto de negocios, datos, aplicaciones, y Arquitectura de Tecnología) o Arquitectura de Negocios o Arquitectura de Datos o Arquitectura de aplicaciones o Tecnología de la Arquitectura Programa y / o Jefes de Proyecto Diseñador de TI Y muchos otros ...

Página 633 de 670


Las siguientes tablas muestran, para cada uno de estos roles, las habilidades requeridas y el nivel deseable de competencia en cada habilidad. De todas las funciones enumeradas anteriormente, el que necesita un análisis particularmente detallado y definición es, por supuesto, el papel central del arquitecto de la empresa. Como se explicó anteriormente, "Arquitectura Empresarial" y "EA" son términos que son muy utilizados pero muy mal definidos en la industria hoy en día, lo que denota una gran variedad de prácticas y habilidades aplicadas en una amplia variedad de dominios de la arquitectura. A menudo hay confusión entre el papel de un arquitecto y la de un diseñador o constructor. Muchas de las habilidades requeridas por un arquitecto de la empresa también son requeridos por el diseñador, que ofrece las soluciones. Aunque sus habilidades son complementarias, las de la diseñadora son principalmente la tecnología enfocada y traducen la arquitectura en componentes entregables. El inciso final por debajo, por tanto, explora en detalle las características genéricas del papel de arquitecto de la empresa, así como los requisitos de habilidades clave, cualquiera que sea el dominio particular arquitectura (Arquitectura Empresarial, Arquitectura de Negocios, Arquitectura de datos, arquitectura de aplicaciones, Arquitectura de Tecnología, etc.) 52.4.3 Categorías de Habilidades

El conjunto de habilidades del equipo TOGAF deberá incluir las siguientes categorías principales de capacidades: Competencias Genéricas : - que comprende típicamente de liderazgo, trabajo en equipo, habilidades interpersonales, etc Habilidades de Negocios y Métodos : - que típicamente comprenden casos de negocio, procesos de negocio, planificación estratégica, etc Arquitectura Empresarial Habilidades : - que típicamente comprende modelado, diseño de bloques de construcción, aplicaciones y diseño de papel, integración de sistemas, etc Programa o Proyecto de Habilidades Directivas : - que típicamente comprende la gestión del cambio empresarial, métodos y herramientas de gestión de proyectos, etc IT Generales Conocimiento Habilidades : - que típicamente comprende aplicaciones de corretaje, gestión de activos, planificación de la migración, SLAs, etc Técnicas Habilidades de TI : - que típicamente comprende la ingeniería de software, seguridad, intercambio de datos, gestión de datos, etc Entorno legal : - que típicamente comprende las leyes de protección de datos, derecho contractual, derecho de contratación, fraude, etc

Las tablas siguientes ilustran cada una de estas categorías de habilidades. Página 634 de 670


Las siguientes tablas muestran, para cada una de estas habilidades, los papeles en los que sean pertinentes y del nivel deseable de competencia en cada habilidad. 52.4.4 Niveles de Competencia

El TOGAF Arquitectura Skills Framework identifica cuatro niveles de conocimiento o habilidad en cualquier área:

52.5

Arquitectura Empresarial de rol y Habilidad Definiciones

52.5.1 Competencias Genéricas

52.5.2 Negocio Habilidades y Métodos

Página 635 de 670

The Open Group Architecture Framework TOGOF 9.1      52.5.3 Arquitectura Empresarial Habilidades

   52.5.4 Programa o Habilidades de Gestión de Proyectos



Página 636 de 670

The Open Group Architecture Framework TOGOF 9.1   52.5.5 TI Habilidades Conocimientos generales

52.5.6 Técnicas Habilidades de TI

52.5.7 Entorno Legal

Página 637 de 670


52.6 Rol genérico y Habilidades de la EA De todas las funciones enumeradas anteriormente, el que necesita un análisis particularmente detallado y definición es, por supuesto, el papel central del arquitecto de la empresa. Como se explicó anteriormente, "Arquitectura Empresarial" y "EA" son términos que son muy utilizados pero muy mal definidos en la industria hoy en día, lo que denota una gran variedad de prácticas y habilidades aplicadas en una amplia variedad de dominios de la arquitectura. Por tanto, esta sección explora en detalle las características genéricas del papel de arquitecto de la empresa, y algunos de los requisitos de habilidades clave, cualquiera que sea el dominio particular arquitectura (Arquitectura Empresarial, Arquitectura de Negocios, Arquitectura de datos, arquitectura de aplicaciones, Arquitectura de Tecnología, etc.) 52.6.1 Rol Genérico

Arquitectos empresariales son visionarios, entrenadores, jefes de equipo, de empresa a técnico enlaces, informáticos y expertos de la industria. La siguiente es una descripción de trabajo efectiva para un arquitecto de la empresa: "El arquitecto tiene la responsabilidad de asegurar la integridad (aptitud para el propósito) de la arquitectura, en términos de abordar adecuadamente todos los intereses pertinentes de las partes interesadas, y la integridad de la arquitectura, en cuanto a la conexión de todos los diferentes puntos de vista para entre ellos, la conciliación de forma satisfactoria las preocupaciones conflictivas de los diferentes grupos de interés, y que muestra las compensaciones hechas en hacerlo (como entre la seguridad y el rendimiento, por ejemplo).

La elección de qué puntos de vista particulares de arquitectura para desarrollar es una de las decisiones clave que la empresa arquitecto tiene que hacer. La elección tiene que ser limitada por consideraciones de orden práctico, y por el principio de la aptitud para el propósito (es decir, la arquitectura debe ser desarrollado sólo hasta el punto en el que es apto para el propósito, y no reiteró el infinito como un ejercicio académico). " El papel de la empresa arquitecto es más parecido al de un planificador de la ciudad que la de un arquitecto del edificio, y el producto de la empresa arquitecto se caracteriza mejor como una comunidad planificada (en oposición a una expansión urbana sin restricciones), y no como un edificio bien diseñado o un conjunto de edificios. Un arquitecto de la empresa no crea la visión técnica de la empresa, pero tiene relaciones profesionales con los ejecutivos de la empresa para reunir y articular la visión técnica, y Página 638 de 670


para elaborar el plan estratégico para darse cuenta. Este plan siempre está relacionada con los planes de negocio de la empresa, y las decisiones de diseño son trazables al plan de negocios. El plan estratégico de la empresa arquitecto está ligada al proceso de gobernanza arquitectura (ver 50. Arquitectura de Gobierno ) para la empresa, por lo que las decisiones de diseño no sean eludidas por conveniencia táctica. El arquitecto de la empresa produce documentación de las decisiones de diseño para los equipos de desarrollo de aplicaciones o equipos de aplicación de productos para su ejecución. Un arquitecto está involucrado en todo el proceso; empezando con el trabajo con el cliente para entender las necesidades reales, en oposición a sus deseos, y a continuación, durante todo el proceso de traducir esas necesidades en capacidades verificadas para satisfacer las necesidades. Además, el arquitecto puede presentar diferentes modelos para el cliente que se comunican cómo pueden cumplirse esas necesidades, y por lo tanto es un participante esencial en el proceso de venta consultiva. Sin embargo, el arquitecto no es el constructor, y deberá permanecer en un nivel de abstracción necesario para garantizar que no se interpongan en el camino de la aplicación práctica. El siguiente extracto de El Arte de Sistemas Architecting ilustra esta idea: "Es la responsabilidad del arquitecto de conocer y concentrarse en los pocos detalles e interfaces críticos que realmente importan, y no sobrecargarse con el resto."

El enfoque del arquitecto es en la comprensión de lo que se necesita para satisfacer al cliente, donde el valor cualitativo se utiliza más de las medidas cuantitativas. El arquitecto utiliza más habilidades inductivas que las habilidades deductivas de la constructora. Las ofertas de arquitecto más con las directrices, en lugar de las normas que los constructores utilizan como una necesidad. También debe quedar claro que el papel de un arquitecto puede ser realizado por un ingeniero. Un objetivo de este documento es describir el papel - lo que debe hacerse, sin importar el que la ejecuta. Por lo tanto, el papel del arquitecto se puede resumir como a: Conocer e interpretar los requisitos : investigar para obtener información, escuchar a la información, influir en las personas, facilitar la creación de consenso, sintetizar y traducir las ideas en acciones concretas requisitos, articular esas ideas a los demás. Identificar el uso o propósito, las limitaciones, riesgos, etc El arquitecto participa en el descubrimiento y la documentación de los escenarios de negocio de los clientes que están impulsando la

Página 639 de 670

The Open Group Architecture Framework TOGOF 9.1   solución. El arquitecto es el responsable de los requisitos de la comprensión y el entendimiento de que los requisitos encarna en la especificación de la arquitectura. Crear un modelo de utilidad : tomar los requisitos y desarrollar modelos bien formulados de los componentes de la solución, aumentando los modelos según sea necesario para adaptarse a todas las circunstancias. Mostrar múltiples puntos de vista a través de los modelos para comunicar las ideas de manera efectiva. El arquitecto es responsable de la integridad de la arquitectura global y el mantenimiento de la visión de la oferta desde una perspectiva arquitectónica. El arquitecto también garantiza oportunidades de apalancamiento se identifican, utilizando bloques de construcción, y es un enlace entre los grupos funcionales (sobre todo de desarrollo y comercialización) para garantizar que las oportunidades de apalancamiento se realicen. El arquitecto proporciona y mantiene estos modelos como un marco para entender el dominio (s) del trabajo de desarrollo, guiando a lo que debe hacerse dentro de la organización o fuera de la organización. El arquitecto debe representar la opinión de la organización de la arquitectura mediante la comprensión de todos los componentes necesarios del negocio. Validar, refinar y expandir el modelo : verificar las hipótesis, traer expertos en la materia, etc con el fin de mejorar el modelo y definir con mayor precisión, añadiendo nuevas ideas necesarias para que el resultado sea más flexible y más estrechamente ligado a la corriente y requisitos previstos. El arquitecto, además, debe evaluar el valor de los desarrollos de soluciones de mejora que emanan del trabajo de campo y de incorporarlos en los modelos de arquitectura, según corresponda. Gestione la arquitectura : un seguimiento continuo de los modelos y actualizarlos si es necesario para mostrar los cambios, adiciones y alteraciones.Representar a la arquitectura y problemas durante el desarrollo y toma los puntos del programa. El arquitecto es un "agente de cambio", lo que supone que la necesidad de la puesta en práctica de la arquitectura. A través de este ciclo de desarrollo, el arquitecto promueve continuamente la puesta en común de los clientes, la arquitectura y la información técnica entre las organizaciones.

52.6.2 Caracterización en términos de la Empresa Continuum

Bajo ciertas circunstancias, la complejidad de una solución puede requerir arquitectos adicionales para apoyar el esfuerzo de la arquitectura. Las diferentes categorías de arquitectos se describen a continuación, pero como son arquitectos, todos ellos realizan las tareas descritas anteriormente. Cualquier combinación de empresas, soluciones empresariales y soluciones de arquitectos puede ser utilizada, como un equipo. En estos casos, cada miembro puede tener un enfoque específico, si las funciones y responsabilidades que no son específicas, dentro de las fases del proceso de desarrollo. En los casos en que sea necesario un equipo de arquitectos, un arquitecto de la empresa principal debe ser asignado para gestionar y dirigir a los del equipo. El Enterprise Architect tiene la responsabilidad para el diseño arquitectónico y la documentación en un paisaje y técnico nivel del modelo de referencia. El Enterprise Architect a menudo conduce a un grupo de los Arquitectos del segmento y / o arquitectos de soluciones relacionadas con un programa determinado. El enfoque de la EA está en funciones de negocios a nivel de empresa necesarios.

Página 640 de 670

The Open Group Architecture Framework TOGOF 9.1   El Arquitecto segmento tiene la responsabilidad para el diseño arquitectónico y la documentación de los problemas o las organizaciones empresariales específicas. Un Arquitecto Segmento re-utiliza la salida de todos los otros arquitectos, uniéndose a las soluciones técnicas detalladas en el paisaje arquitectónico general. El enfoque del Arquitecto segmento está en las soluciones de negocio a nivel de empresa en un determinado dominio, tales como finanzas, recursos humanos, ventas, etc El arquitecto de la solución tiene la responsabilidad para el diseño arquitectónico y la documentación en un sistema o subsistema, como la gestión o la seguridad. Un arquitecto de la solución puede blindar el Enterprise Architect / Segmento de los detalles innecesarios de los sistemas, productos y / o tecnologías.El enfoque del arquitecto de soluciones en las soluciones de tecnología de sistema; Por ejemplo, un componente de una solución tal como el almacenamiento de datos de la empresa.

52.6.3 Características clave de un Enterprise Architect 52.6.3.1 habilidades y experiencia en la producción de diseños

Un arquitecto de la empresa deben ser competentes en las técnicas que intervienen en la producción de diseños de sistemas complejos, incluidos los requisitos de descubrimiento y el análisis, la formulación de solución contexto, la identificación de alternativas de solución y su evaluación, selección de tecnología, y la configuración de diseño. 52.6.3.2 Amplia Manga Técnica, con la profundidad técnica en uno o unos pocos Disciplinas

Un arquitecto de la empresa debe poseer una extensa amplitud técnica a través de la experiencia en la industria de TI. Esta amplitud debe ser en áreas de desarrollo y despliegue de aplicaciones, y en las áreas de creación y mantenimiento de la infraestructura para apoyar el entorno de aplicaciones complejas. Entornos de TI actuales son heterogéneos por naturaleza, y el arquitecto de la empresa con experiencia tendrán habilidades a través de múltiples plataformas, incluyendo los sistemas distribuidos y entornos de mainframe tradicionales. Arquitectos empresariales tendrán, como resultado de su carrera, las habilidades en al menos una disciplina que se considera que está en el nivel de un experto en la materia. 52.6.3.3 Método Enfoque determinado de Ejecución

Los arquitectos de la empresa se acercan a su trabajo a través del uso constante de los métodos de diseño reconocidas, como la Arquitectura Método de Desarrollo TOGAF (). Los arquitectos de la empresa deben tener conocimiento de trabajo de más de un método de diseño y ser confortables partes Implementación de métodos apropiados para la situación en la que están trabajando trabajando. Esto debe considerarse en el cuerpo de trabajo de diseño de la empresa arquitecto ha producido a través de uso exitoso repetida de más de un método de diseño. La habilidad en el uso la metodología está en saber qué partes de los métodos a utilizar en una situación dada, y qué métodos no utilizar. 52.6.3.4 Completa Experiencia del Alcance del Proyecto

Página 641 de 670


Mientras los arquitectos empresariales son responsables del diseño y de la mano-off del proyecto a los ejecutores, es vital que tengan experiencia en todos los aspectos de un proyecto, desde el diseño hasta el desarrollo, prueba, implementación y producción. Este ámbito de aplicación de la experiencia servirá para mantener los arquitectos empresariales basadas en la noción de la aptitud para el propósito y el carácter práctico de la implementación del sistema. El impacto de la experiencia completa del alcance del proyecto debe liderar el arquitecto empresarial para tomar mejores decisiones de diseño, e informar mejor a los intercambios realizados en esas decisiones. 52.6.3.5 Liderazgo

Comunicación y trabajo en equipo son clave para el papel exitoso de la empresa arquitecto. La mezcla de buena habilidad técnica y la capacidad de conducir son cruciales para el trabajo. El arquitecto de la empresa debe ser visto como un líder en la empresa mediante la organización de TI, los clientes que sirven, y la gestión. 52.6.3.6 Habilidades Personales y Profesionales

El arquitecto de la empresa debe tener las comunicaciones sólidas y habilidades de relación. Una de las principales tareas de la empresa arquitecto es comunicar información técnica compleja para todos los interesados del proyecto, incluidos los que no tienen una formación técnica. También se requiere que la negociación fuerte y habilidades de resolución de problemas. El arquitecto de la empresa debe trabajar con el equipo de gestión del proyecto para tomar decisiones de manera oportuna para mantener los proyectos en marcha.

52.6.3.7 habilidades y experiencia en una o más industrias

La habilidad de la Industria y la experiencia harán que la tarea de reunir los requisitos y decidir las prioridades más fácil y efectivo para la EA. Los arquitectos de la empresa deben entender los procesos de negocio de la empresa en la que trabajan, y cómo esos procesos trabajan con otras empresas de pares en la industria.También debe ser capaz de detectar las principales tendencias y procesos viciados correctas, dando a la organización de TI la capacidad de dirigir la empresa, no sólo responder a las solicitudes. La misión de la empresa es arquitecto liderazgo técnico estratégico.

52.7 Conclusiones El TOGAF Arquitectura Skills Framework proporciona una evaluación de las habilidades necesarias para ofrecer una exitosa arquitectura empresarial.

Página 642 de 670


Se espera que la prestación de este Skills Framework Architecture le ayudará a reducir el tiempo, costo y riesgo involucrado en la formación, la contratación y la gestión de profesionales de la arquitectura de TI, y al mismo tiempo permitir y animar a más organizaciones para instituir una estructura de funcionamiento interno de TI , es de esperar en base a (o por lo menos apalancamiento) la función y las definiciones de habilidad siempre.

L

Página 643 de 670




Apéndices

Página 644 de 670




A. Glosario de Definiciones complementarias Este apéndice contiene definiciones adicionales para complementar las definiciones contenidas en el 3. Definiciones .

A.1 de control de (AC) Un servicio de seguridad que garantiza que sólo los s con los derechos correctos puede acceder a determinados dispositivos, aplicaciones o datos.

A.2 Ada Un lenguaje de programación de alto nivel desarrollado por el Departamento de Defensa de EE.UU. ( DoD ) y ampliamente utilizado en los países del Departamento de Defensa y de la OTAN. Se utiliza para el procesamiento en tiempo real, es de naturaleza modular, e incluye características orientadas a objetos.

Componente de aplicación A.3 Una encapsulación de funcionalidad de la aplicación alineado con estructura de ejecución. Por ejemplo, una aplicación de procesamiento de solicitud de compra. Ver también A.50 Lógico componente de aplicación y A.63 Física componente de aplicación .

Software de Aplicación A.4 Entidades de software que tienen un fin comercial específico.

A.5 Disponibilidad En el contexto de los sistemas de TI, la probabilidad de que las capacidades funcionales del sistema están listos para su uso por un en cualquier momento, en donde se considera todos los tiempos, incluyendo operaciones, reparación, istración y tiempo de logística. La disponibilidad se define además por categoría sistema tanto para las operaciones de rutina y prioritarios.

Procesamiento por lotes A.6

Página 645 de 670


Procesamiento de los datos o la realización de trabajos acumulados con antelación, de tal manera que cada acumulación así formado se procesa o se lleva a cabo en la misma computadora funcione.

A.7 Business System Hardware, software, declaraciones de políticas, procesos, actividades, normas, y las personas que en conjunto implementan una función de negocios.

Catálogo A.8 Una lista estructurada de los productos arquitectónicos de un tipo similar, que se utiliza como referencia. Por ejemplo, a las normas de tecnología catálogo o un portafolio de aplicaciones.

A.9 Cliente Un componente de la aplicación que solicita los servicios de un servidor.

A.10 COBIT Es el acrónimo de Objetivos de Control para la Información y Tecnologías Relacionadas, creado por la Asociación de Sistemas de Información de Auditoría y Control (ISACA) y el IT Governance Institute (ITGI), que proporciona un conjunto de mejores prácticas recomendadas para la gestión / istración de los sistemas de información y tecnología .

A.11 Red de Comunicaciones Un conjunto de productos, conceptos y servicios que permiten la conexión de los sistemas informáticos con el fin de transmitir datos y otras formas (por ejemplo, voz y video) entre los sistemas.

A.12 Comunicaciones Nodo Un nodo que es ya sea interna a la red de comunicaciones (por ejemplo, enrutadores, puentes, o repetidores) o situado entre el dispositivo final y la red de comunicaciones para operar como una puerta de enlace.

Sistema A.13 Comunicaciones Un conjunto de activos (medios de transmisión, los nodos de conmutación, interfaces y dispositivos de control) que establecerá vínculos entre s y dispositivos. Página 646 de 670


A.14 de aplicaciones compuestas Un componente de aplicación que se crea mediante la composición de otras aplicaciones atómicas o compuestos.

A.15 Configuration Management Una disciplina aplicando dirección técnica y istrativa y la vigilancia de: Identificar y documentar las características funcionales y físicas de un elemento de configuración Los cambios de control a esas características Registrar y comunicar los cambios en el procesamiento y el estado de aplicación

Además, la gestión de la configuración de la arquitectura de la práctica de la empresa (de propiedad intelectual) los activos y líneas de base y el control de cambio a lo largo de esos activos.

A.16 Servicio de conectividad Un área de servicio de la entidad ambiente externo del modelo de referencia técnica (TRM) que proporciona conectividad de extremo a extremo para las comunicaciones a través de tres niveles de transporte (global, regional y local). Proporciona servicios generales y específicos de la aplicación a finales de plataforma dispositivos.

Contrato A.17 Un acuerdo entre un consumidor de servicios y un proveedor de servicios que establece los parámetros funcionales y no funcionales para la interacción.

Control A.18 Un paso de toma de decisiones con el acompañamiento de la lógica de decisión utilizado para determinar el enfoque de ejecución de un proceso o para asegurar que un proceso cumple con los criterios de gobierno. Por ejemplo, un control de cierre de sesión en el proceso de tramitación de solicitud de compra que comprueba si el valor total de la solicitud está dentro de los límites de sesión fuera de la solicitante, o si necesita una escalada a la autoridad superior.

A.19 CxO El oficial en jefe dentro de una función particular de la empresa; por ejemplo, el Director Ejecutivo, Director Financiero, Director de Información, Director de Tecnología. Página 647 de 670


Diccionario de datos A.20 Un tipo especializado de base de datos que contiene metadatos; un repositorio de información que describe las características de los datos que se utilizan para diseñar, monitorear, documentar, proteger y controlar los datos en los sistemas de información y bases de datos; un sistema de aplicación de apoyo a la definición y gestión de metadatos de la base de datos.

Elemento de datos A.21 Una unidad básica de información que tiene un significado y que puede tener subcategorías (elementos de datos) de las unidades y valores distintos.

A.22 Entity Data Una encapsulación de datos que es reconocido por un experto de dominio de negocios como una cosa. entidades de datos lógicos se puede atar a las aplicaciones, repositorios y servicios y puede ser estructurada de acuerdo a consideraciones de implementación.

A.23 de datos de servicio de intercambio Un servicio de la entidad de plataforma del modelo de referencia técnica (TRM) que proporciona apoyo especializado para el intercambio de datos entre aplicaciones en el mismo o en diferentes plataformas.

A.24 Servicio de Gestión de Datos Un servicio de la entidad de plataforma del modelo de referencia técnica (TRM) que brinda apoyo a la gestión, el almacenamiento, el y la manipulación de los datos en una base de datos.

Base de datos A.25 Una colección estructurada u organizada de entidades de datos, la cual se puede acceder por un ordenador.

A.26 Sistema de Gestión de Base de Datos Un programa de aplicación de ordenador que tenga o manipula la base de datos.

Servicio de directorio A.27

Página 648 de 670


Un componente de tecnología que ofrece servicios de localización que se encuentran la ubicación de un servicio, o la ubicación de los datos, o la traducción de un nombre común en una dirección específica de la red. Es análogo a los libros de teléfono y se puede implementar en esquemas centralizados o distribuidos.

Base de datos distribuida A.28 1. Una base de datos que no se almacena en una ubicación central, pero se dispersa a través de una red de ordenadores interconectados. 2. Una base de datos bajo el control total de un sistema de gestión de base de datos central (DBMS), pero cuyos dispositivos de almacenamiento no están adscritos a un mismo procesador.

3. Una base de datos que se encuentra físicamente en dos o más lugares distintos.

A.29 Conductor Una condición externa o interna que motiva a la organización a definir sus metas. Un ejemplo de un controlador externo es un cambio en la normativa que regula el cumplimiento o que, por ejemplo, requieren cambios en la forma en que una organización opera; es decir, la Ley Sarbanes-Oxley en los EE.UU..

A.30 para el final Persona que, en última instancia utiliza la aplicación informática o salida.

Planificación de recursos empresariales A.31 (PIR) Una suite completa de aplicaciones integradas que soportan las principales funciones de apoyo empresarial de una organización; por ejemplo, Financiera (AP / AR / GL), recursos humanos, nómina, inventario, procesamiento de pedidos y facturación, Compras, Logística, Producción, etc

A.32 Evento Un cambio de estado de la organización que desencadena eventos de procesamiento puede provenir de dentro o fuera de la organización y puede ser resuelto dentro o fuera de la organización.

A.33 Interfaz Ambiente Externo (EEI) La interfaz que soporta la transferencia de información entre la plataforma de aplicación y el ambiente externo. Página 649 de 670


A.34 FORTRAN Es el acrónimo de traductor fórmula, que es un lenguaje de programación de alto nivel utilizado ampliamente en aplicaciones científicas y de ingeniería.

A.35 Descomposición Funcional Una jerarquía de las funciones de una empresa u organización.

A.36 Meta Una declaración de alto nivel de la intención o la dirección de una organización. Normalmente se utiliza para medir el éxito de una organización.

Directriz A.37 Un documento de arquitectura que ofrece orientación sobre el mejor modo de llevar a cabo actividades de diseño o de implementación.

A.38 Hardware La infraestructura física necesaria para ejecutar el software; por ejemplo, servidores, estaciones de trabajo, equipos de red, etc

A.39 Interfaz Hombre-Computadora (HCI) Hardware y software que permite el intercambio de información entre el y el ordenador.

A.40 Información del dominio Agrupación de la información (o entidades de datos) mediante una serie de criterios tales como la clasificación de seguridad, propiedad, ubicación, etc En el contexto de la seguridad, los dominios de información se definen como un conjunto de s, sus objetos de información, y una política de seguridad.

Sistema de Información A.41 (IS) La porción de la computadora (o IT) basado en un sistema de negocio.

Servicio de Sistema de Información A.42

Página 650 de 670


Los elementos automáticos de un servicio empresarial. Hay un servicio de sistema de información pueden ofrecer o apoyar la totalidad o parte de uno o varios servicios de oficina.

Interacción A.43 Una relación entre los bloques de construcción de arquitectura (es decir, servicios o componentes) que encarna la comunicación o utilización.

A.44 Modelo de Interacción Una vista arquitectónico, catálogo, o una matriz que muestra un tipo particular de interacción. Por ejemplo, un diagrama que muestra la integración de aplicaciones.

A.45 Interface Interconexión e interrelaciones entre, por ejemplo, personas, sistemas, dispositivos, aplicaciones o el y una aplicación o dispositivo.

A.46 ITIL Es el acrónimo de Information Technology Infrastructure Library, que proporciona un conjunto de mejores prácticas recomendadas para la gestión / istración de los sistemas de información y tecnología.

A.47 indicador clave de rendimiento (KPI) Una forma de cuantificar el desempeño del negocio o proyecto.

A.48 Ciclo de Vida El período de tiempo que comienza cuando un sistema está concebido y termina cuando el sistema ya no está disponible para su uso.

A.49 Ubicación Un lugar donde la actividad empresarial se lleva a cabo y se puede descomponer jerárquicamente.

Componente de aplicación A.50 Lógico

Página 651 de 670


Una encapsulación de funcionalidad de la aplicación que es independiente de una implementación particular. Por ejemplo, la clasificación de todas las aplicaciones de procesamiento de solicitud de compra implementados en una empresa.

Componente de datos A.51 Lógico Una zona de frontera que encapsula las entidades de datos relacionados para formar una ubicación lógica que se celebrará. Por ejemplo, la información de aprovisionamiento externo.

A.52 Lógico Componente Tecnología Una encapsulación de la infraestructura de tecnología que es independiente de un producto en particular. Una clase de producto de tecnología. Por ejemplo, el software de gestión de la cadena de suministro, como parte de un sistema de planificación de recursos empresariales (ERP) suite o una solicitud de compra Commercial Off-The-Shelf (COTS) servicios de empresa de procesamiento.

A.53 istración de Programas Exitosos (MSP) Una metodología de mejores prácticas para la gestión del programa, desarrollado por la Oficina del Reino Unido de Comercio Gubernamental (OGC).

Matrix A.54 Un formato para mostrar la relación entre dos (o más) elementos arquitectónicos en un formato de cuadrícula.

A.55 Medida Un indicador o factor que se puede controlar, por lo general en forma permanente, para determinar el éxito o el alineamiento con los objetivos y metas.

A.56 Metaview A MetaView actúa como un patrón o plantilla de la vista, desde el que desarrollar puntos de vista individuales. A MetaView establece los propósitos y audiencias para una vista, las formas en que se documenta la vista (por ejemplo, para el modelado visual), y las formas en las que se utiliza (por ejemplo, para el análisis). Ver también 3.76 Punto de vista en 3. Definiciones .

A.57 Servicio Multimedia Página 652 de 670


Un servicio del modelo de referencia técnica (TRM) que proporciona la capacidad para manipular y istrar los productos de información que consta de texto, gráficos, imágenes, vídeo y audio.

A.58 Especificaciones Abiertas Especificaciones públicas que son mantenidos por un proceso de consenso abierto y público para dar cabida a las nuevas tecnologías a través del tiempo y que son consistentes con las normas internacionales.

A.59 Sistema Abierto Un sistema que implementa las especificaciones abiertas suficientes para interfaces, servicios y formatos de apoyo que permitan la aplicación de software diseñada correctamente: Para ser portado con cambios mínimos a través de una amplia gama de sistemas Para interoperar con otras aplicaciones en sistemas locales y remotos Para interactuar con los s en un estilo que facilita la portabilidad de

Gobernanza Operacional A.60 Gobernabilidad Operacional analiza el desempeño operacional de los sistemas frente a los niveles contratados rendimiento, la definición de los niveles de rendimiento operativo y la implementación de sistemas que garanticen el funcionamiento eficaz de los sistemas. Ver también 3.39 Gobernanza en 3. Definiciones .

A.61 Servicio del Sistema Operativo Un servicio básico de la entidad plataforma de aplicación del Modelo de Referencia Técnica (TRM) que se necesita para operar y istrar la plataforma de aplicaciones y proporcionar una interfaz entre el software de aplicación y la plataforma (por ejemplo, gestión de archivos, entrada / salida, colas de impresión ).

Servicios A.62 Packaged Servicios que se adquieren en el mercado de un Comercial Off-The-Shelf (COTS) de los proveedores, en lugar de ser construido a través del código de construcción.

A.63 Física componente de aplicación Página 653 de 670


Una aplicación, módulo de aplicación, servicios de aplicaciones, u otro componente de despliegue de la funcionalidad. Por ejemplo, una instancia de una Commercial Off-TheShelf (COTS) Planificación de recursos empresariales (ERP) de alimentación configurado y desplegado la aplicación de gestión de la cadena.

A.64 Componente Físico de Datos Una zona de frontera que encapsula las entidades de datos relacionados para formar un lugar físico que se celebrará. Por ejemplo, un objeto de negocio de la orden de compra, que comprende encabezado de la orden de compra y nodos de objetos de negocios artículo.

A.65 Tecnología Componente Físico Un producto de infraestructura de tecnología o la tecnología instancia de producto infraestructura. Por ejemplo, un determinado modelo de una solución comercial Off-TheShelf (COTS), o de una marca específica y la versión del servidor.

A.66 Portabilidad 1. La facilidad con la que un sistema, componente, datos, o el pueden ser transferidos de un hardware o entorno de software a otro. 2. Una métrica de calidad que se puede utilizar para medir el esfuerzo relativo para transportar el software para su uso en otro entorno o para convertir de software para su uso en otro entorno operativo, la configuración de hardware, o entorno de sistema de software.

A.67 Portafolio El conjunto completo de las actividades de cambio o sistemas que existen dentro de la organización o parte de la organización. Por ejemplo, la cartera de aplicaciones y la cartera de proyectos.

A.68 PRINCE2 Es el acrónimo de proyectos en ambientes controlados, que es un método de gestión de proyectos estándar.

Proceso A.69 Un proceso representa una secuencia de actividades que en conjunto logran un resultado determinado, puede descomponerse en sub-procesos, y puede mostrar el funcionamiento de una función o servicio (en el siguiente nivel de detalle). Los procesos también pueden ser utilizados para conectar o componer organizaciones, funciones, servicios y procesos. Página 654 de 670


A.70 Producto La salida generada por el negocio. El producto de negocios de la ejecución de un proceso.

A.71 Perfil Un conjunto de una o más normas básicas y, en su caso, la identificación de las anteriores clases, subconjuntos, opciones y parámetros de esas normas básicas, necesarias para el cumplimiento de una función determinada.

A.72 Profiling La identificación de las normas y características de un sistema en particular.

Programa A.73 Un conjunto coordinado de proyectos de cambio que ofrecen el beneficio empresarial a la organización.

A.74 Proyecto Un proyecto de cambio único, que ofrece el beneficio empresarial a la organización.

Gestión de Riesgos A.75 La gestión de los riesgos y problemas que pueden amenazar el éxito de la estructura de funcionamiento de la empresa y su capacidad de cumplir es la visión, metas y objetivos, y, sobre todo, de su prestación de servicios. Nota: La gestión de riesgos se describe en la Parte III , 31. Gestión de Riesgos .

A.76 Escalabilidad La capacidad de usar el mismo software de aplicación en muchas clases diferentes de plataformas de hardware / software de PC para-super computadoras (extiende el concepto de portabilidad). La capacidad de crecer para dar cabida a mayores cargas de trabajo.

A.77 Seguridad Servicios que protegen los datos, garantizando su confidencialidad, disponibilidad e integridad. Página 655 de 670


A.78 Servidor Un componente de aplicación que responde a las peticiones de un cliente.

Servicio A.79 Una representación lógica de una actividad de negocio repetible que tiene un resultado específico. Un servicio es autónomo, puede estar compuesto por otros servicios, y es un "recuadro negro" a sus consumidores. Algunos ejemplos son "verificación de crédito del cliente", "proporcionar datos meteorológicos", y "consolidar los informes de perforación".

A.80 Servicio Calidad Una configuración preestablecida de atributos no funcionales que pueden ser asignadas a un servicio o contrato de servicio.

A.81 INTELIGENTE Es el acrónimo de específicos, medibles, alcanzables, realistas y de duración determinada, que es un enfoque para asegurar que las metas y objetivos se establecen de manera que se puede lograr y medir.

Gestión de Proveedores A.82 La gestión de los proveedores de productos y servicios para la práctica de la arquitectura de la empresa de común acuerdo con las actividades de adquisición de empresas más grandes.

Sistema A.83 Una colección de componentes organizados para cumplir una función específica o un conjunto de funciones (fuente: ISO / IEC 42010:2007).

Sistema A.84 y el Servicio de Gestión de Red Un servicio de la entidad de plataforma de aplicación del Modelo de Referencia Técnica (TRM), que proporciona la istración del sistema de información global cruzada categoría. Estos servicios incluyen la gestión de la información, los procesadores, redes, configuraciones, contabilidad y rendimiento.

A.85 Sistema Stakeholder Un individuo, equipo u organización (o clases de los mismos) con intereses en, o preocupaciones con respecto a un sistema (fuente: ISO / IEC 42010:2007). Página 656 de 670


A.86 Tecnología Componente Una encapsulación de infraestructura tecnológica que representa una clase de producto de la tecnología o producto de tecnología específica.

A.87 Período de tiempo El plazo durante el cual el impacto potencial se va a medir.

A.88 Transacción La interacción entre un y un ordenador en el que el introduce una orden para recibir un resultado específico de la computadora.

Transacción Secuencia A.89 Orden de las operaciones necesarias para lograr los resultados deseados.

A.90 Use-Case Una vista de la organización, aplicación o funcionalidad del producto que ilustra las capacidades en contexto con el de esa capacidad.

A.91 1. Cualquier persona, organización o unidad funcional que utiliza los servicios de un sistema de procesamiento de información. 2. En un lenguaje de esquema conceptual, cualquier persona o cualquier cosa que puede emitir o recibir órdenes y mensajes hacia o desde el sistema de información.

A.92 Servicio Interfaz de Un servicio de la entidad de plataforma de aplicación del Modelo de Referencia Técnica (TRM) que soporta la interacción directa hombre-máquina mediante el control del medio ambiente en el que los s interactúan con las aplicaciones.

Página 657 de 670




B. Abreviaturas ABB Arquitectura Bloque de construcción Corriente alterna Control de ACL Lista de Control de ACMM Arquitectura Capability Maturity Model ACSE Elemento de servicio de control de asociación Arquitectura Método de Desarrollo ANSI American National Standards Institute API Interface Application Platform ARTES Asociación de Estándares de Tecnología Retail BMM Motivación Modelo de Negocio BPM Gestión de Procesos de Negocio BPMN Business Process Modeling Notation

Página 658 de 670

The Open Group Architecture Framework TOGOF 9.1   BTEP El Programa Canadiense Enablement Transformación Empresas Gobierno CAB Comité de Cambios CCITT Comité Consultivo sobre Telégrafos y Teléfonos, ahora conocido como la Unión Internacional de Telecomunicaciones (UIT) CI Elementos de Configuración CIPR Proceso Central de Información CM Gestión de la Configuración CMIP Protocolo de Información de Gestión Común CMIS Gestión de la Información del Servicio Común CMM Modelos de Madurez de Capacidad CMMI Capability Maturity Model Integration CN Red de Comunicaciones COBIT Objetivos de Control para la Información y Tecnologías Relacionadas CODASYL Conferencia sobre Sistemas de Datos de Idiomas CORBA

Página 659 de 670

The Open Group Architecture Framework TOGOF 9.1   Common Object Request Broker Architecture COTS Aplicaciones Comercial Off-The-Shelf CRM Customer Relationship Management CRUD Crear / Leer / Actualizar / Eliminar CSF Factor Clave de Éxito DAI Data Access Interface DBA Database DBMS Sistema de Gestión de Base de Datos DCE Distributed Computing Environment DDL Data Definition Language DISA Departamento de Defensa de la Agencia de Sistemas de Información de EE.UU. DMF Utilidad de gestión de datos DML Manipulación de datos Idioma DMTF Distributed Management Task Force

Página 660 de 670

The Open Group Architecture Framework TOGOF 9.1   DNS Sistema de nombres de dominio DdC Departamento de Comercio de EE.UU. DoD Departamento de Defensa de EE.UU. DoDAF Departamento de Defensa de Arquitectura de Marco DRDA Distributed Relational Database Architecture EA Arquitectura Empresarial EAI Integración de Aplicaciones Empresariales EDI Intercambio Electrónico de Datos EEI Interfaz Ambiente Externo ERP Planificación de Recursos Empresariales ES Fin del sistema ESB Enterprise Service Bus ETL Extraer, Transformar, Cargar FEAF

Página 661 de 670

The Open Group Architecture Framework TOGOF 9.1   Federal Enterprise Architecture Framework FICO Fair Isaac Corporation FORTRAN Traductor FORmula FTE Equivalente a Tiempo Completo GOTS Gobierno aplicaciones Off-The-Shelf GUI Interfaz gráfica de HIPAA Ley de Responsabilidad de Seguro de Salud de Portabilidad y ICAM Fabricación Asistida por Ordenador Integrado ICD Documento de Control de Interfaz ICOM Entradas, salidas, controles y mecanismos / Recursos IDEF Ayudado Integrated Computer Manufacturing (ICAM) Definición IDL Interfaz de lenguaje de descripción IEC Comisión Electrotécnica Internacional IEEE Instituto de Ingenieros Eléctricos y Electrónicos

Página 662 de 670

The Open Group Architecture Framework TOGOF 9.1   III Infraestructura de Información Integrado III-RM Integrado de Información Infraestructura Modelo de Referencia IMS Sistema de Gestión de la Información ISA Information Systems Architecture ISACA Sistemas de Información Asociación de Auditoría y Control de ISACF Sistemas de Información de Auditoría y Control Foundation ISAM Indexado Método de secuencial ISO Organización Internacional de Normalización Informática Tecnología de la Información ITGI IT Governance Institute ITIL Information Technology Infrastructure Library ITPMF IT Management Facility Portafolio UIT Unión Internacional de Telecomunicaciones JMS

Página 663 de 670

The Open Group Architecture Framework TOGOF 9.1   Java Message Service JVM Java Virtual Machine KPI Indicador clave de rendimiento LAN Red de Área Local LCS Sistema de Comunicación Local LIPR Proceso de Información Local LSE Red local de abonado MAN Red de área metropolitana MDA Model Driven Architecture MIB Bases de Información de Gestión MIS Sistemas de Información Gerencial MLS Multi-Nivel de Seguridad MTA Agente de transferencia de mensajes NASCIO Oficiales de la Asociación Nacional de Estado Jefe de Información

Página 664 de 670

The Open Group Architecture Framework TOGOF 9.1   NIST Instituto Nacional de Estándares y Tecnología OAG Abra Aplicaciones Group OAGIS Abra Aplicaciones Grupo de Integración de Especificaciones ODBC Open Database Connectivity OCDE Organización para la Cooperación y el Desarrollo OGC Oficina de Comercio Gubernamental del Reino Unido OLA Acuerdo de Nivel Operacional OMB Oficina de istración y Presupuesto OMG Object Management Group OODBMS Sistema de gestión de base de datos orientada a objetos ORB Object Request Broker OS Sistema Operativo OSE Abrir entorno del sistema OSI

Página 665 de 670

The Open Group Architecture Framework TOGOF 9.1   Interconexión de sistemas abiertos OSOA Arquitectura orientada a servicios P-CMM Gente Capability Maturity Model PDA Asistente Digital Personal PDF Formato de Documento Portátil PEX Extensión PHIGS al sistema X Window PHIGS Sistema Gráfico Interactivo jerárquica del programador PMI Iniciativa de Gestión de Proyectos PMBOK Proyecto Organismo de Gestión del Conocimiento PRINCE Proyectos en ambientes controlados QoS Calidad de servicio RACI Responsable, Responsable, Consultado, Informado RAS Servicios de remoto RDA base de datos remota

Página 666 de 670

The Open Group Architecture Framework TOGOF 9.1   RDBMS Relational Database Management System REA Recursos-Event-Agent RFC Solicitud para el Cambio RFI Solicitud de Información RFP Solicitud de Propuesta RFQ Solicitud de Cotización RM Modelo de Referencia RM-ODP Modelo de referencia ISO para el Procesamiento distribuido abierto RPC Llamada a procedimiento remoto RS Relay System SA-CMM Software de Adquisición de Capability Maturity Model SBB Solución Módulo SCAMPI Estándar CMMI método de valoración para la Mejora de Procesos SDO

Página 667 de 670

The Open Group Architecture Framework TOGOF 9.1   Service Data Objects SEI Instituto de Ingeniería de Software SGML Standard Generalized Markup Language SIB Normas de Información de Base SCA Service Component Architecture SCAMPI CMMI método de valoración para la Mejora de Procesos SLA Acuerdo de Nivel de Servicio SMAP Proceso de solicitud de Gestión de la Seguridad INTELIGENTE Específicos, medibles, alcanzables, realistas y de duración determinada SMTP Simple Mail Transfer Protocol SNA Arquitectura de red de Sistema SNMP Simple Network Management Protocol SOA Arquitectura Orientada a Servicios SPEM Processing Software Engineering Metamodel

Página 668 de 670

The Open Group Architecture Framework TOGOF 9.1   SQL Structured Query Language PASO Estándar para el intercambio de datos y el modelo del producto SWG Grupo de Trabajo Especial SysML Sistemas Modeling Language TADG Tesoro Arquitectura Orientación Desarrollo TAFIM Marco de Arquitectura Técnica para la Gestión de la Información T / IP / Protocolo de Internet Transmission Control Protocol TISAF Sistema de Información de Hacienda Architecture Framework TRM Referencia técnica del Modelo TFA Transparente de a archivos TLSP Protocolo de seguridad de nivel de transporte TMF TeleManagement Forum TP Procesamiento de transacciones UML

Página 669 de 670

The Open Group Architecture Framework TOGOF 9.1   Unified Modeling Language UN / CEFACT Centro de las Naciones Unidas para la Facilitación del Comercio y las Transacciones Electrónicas UN / EDIFACT Naciones Unidas / Intercambio Electrónico de Datos para la istración, Comercio y Transporte WAN Red de Área Amplia WSDL Web Services Description Language XML Extensible Markup Language XSD Definición de esquemas XML

Página 670 de 670

Togaf 91es 373f4f

Overview 26281t

More details 6y5l6z

Related Documents 3h463d

Togaf 91es 373f4f

Togaf 173m59

Togaf 173m59

Togaf Ebook 625h43

Togaf 9 Notes 6p516f

Togaf In Pictures 673k3d

More Documents from "Luis Carlos Guevara Villalobos" 5c5h5z

Tipos De Centro De Computo 6y4145

4p345f

Togaf 91es 373f4f

Origen Del Constitucionalismo 2j5k2p

Dofa De Kfc 1h1e1o

Cultivo De De Ramio 1u3z5b