• Author / Uploaded
• Yhenger Astocahuana

Citation preview

2.1 ¿Qué es TOGAF? TOGAF es un marco de arquitectura. TOGAF proporciona los métodos y herramientas para asistir en la aceptación, producción, uso y mantenimiento de una arquitectura empresarial. Se basa en un modelo de proceso iterativo respaldado por las mejores prácticas y un conjunto reutilizable de activos de arquitectura existentes.

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 adopta pero no se adhiere estrictamente a la terminología ISO / IEC 42010: 2007. En TOGAF, "arquitectura" tiene dos significados según el contexto: 1. Una descripción formal de un sistema, o un plan detallado del sistema a nivel de componentes para guiar su implementación 2. La estructura de los componentes, sus interrelaciones y los principios y directrices que rigen su diseño y evolución a lo largo del tiempo. TOGAF considera a la empresa como un sistema y se esfuerza por lograr un equilibrio entre la promoción de los conceptos y la terminología de ISO / IEC 42010: 2007, asegurando que el uso de los términos definidos por ISO / IEC 42010: 2007 sea consistente con la norma y reteniendo otros Terminología aceptada que es familiar para la mayoría de los lectores de TOGAF. Para obtener más información sobre la terminología, consulte 3. Definiciones y la Parte IV , 35. Artefactos arquitectónicos .

2.3 ¿Con qué tipo de arquitectura trata TOGAF? Hay cuatro dominios de arquitectura que se aceptan comúnmente como subconjuntos de una arquitectura empresarial general, todos los cuales TOGAF está diseñado para admitir:    

La arquitectura empresarial define la estrategia empresarial, la gobernanza, la organización y los procesos empresariales clave. La arquitectura de datos describe la estructura de los recursos de datos lógicos y físicos de una organización y los recursos de administración de datos. La arquitectura de la aplicación proporciona un modelo para las aplicaciones individuales que se implementarán, sus interacciones y sus relaciones con los procesos comerciales centrales de la organización. La arquitectura tecnológica describe las capacidades lógicas de software y hardware que se requieren para admitir la implementación de servicios de negocios, datos y aplicaciones. Esto incluye infraestructura de TI, middleware, redes, comunicaciones, procesamiento, estándares, etc.

2.4 Método de desarrollo de la arquitectura El método de desarrollo de arquitectura TOGAF (ADM) proporciona un proceso probado y repetible para desarrollar arquitecturas. El ADM incluye el establecimiento de un marco de arquitectura, el desarrollo del contenido de la arquitectura, la transición y el gobierno de la realización de arquitecturas. Todas estas actividades se llevan a cabo dentro de un ciclo iterativo de definición y realización continuas de la arquitectura que permite a las organizaciones transformar sus empresas de manera controlada en respuesta a los objetivos y oportunidades comerciales.

Las fases dentro del ADM son las siguientes:  

       

La fase preliminar describe las actividades de preparación e iniciación necesarias para crear una capacidad de arquitectura, incluida la personalización de TOGAF y la definición de los principios de arquitectura. Fase A: Visión de la arquitectura describe la fase inicial de un ciclo de desarrollo de la arquitectura. Incluye información sobre la definición del alcance de la iniciativa de desarrollo de la arquitectura, la identificación de las partes interesadas, la creación de la Visión de la Arquitectura y la obtención de la aprobación para continuar con el desarrollo de la arquitectura. Fase B: Arquitectura empresarial describe el desarrollo de una arquitectura empresarial para respaldar la Visión de Arquitectura acordada. Fase C: Arquitecturas de sistemas de información describe el desarrollo de arquitecturas de sistemas de información para respaldar la Visión de Arquitectura acordada. Fase D: Arquitectura tecnológica describe el desarrollo de la arquitectura tecnológica para respaldar la Visión de Arquitectura acordada. 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 entrega para la arquitectura definida en las fases anteriores. Fase F: la planificación de la migración aborda cómo pasar de la línea de base a las arquitecturas de destino al finalizar un plan detallado de implementación y migración. Fase G: La gobernanza de la implementación proporciona una supervisión arquitectónica de la implementación. Fase H: La administración de cambios de la arquitectura establece procedimientos para administrar los cambios en la nueva arquitectura. La gestión de requisitos examina el proceso de administración de los requisitos de arquitectura en todo el ADM.

2.5 Entregables, artefactos y bloques de construcción Los arquitectos que ejecutan el ADM producirán una serie de resultados como resultado de sus esfuerzos, tales como flujos de procesos, requisitos arquitectónicos, planes de proyectos, evaluaciones de cumplimiento de proyectos, etc. El Marco de Contenido de Arquitectura TOGAF (ver Parte IV , 33. Introducción ) proporciona una Modelo estructural para el contenido arquitectónico que permite que los principales productos de trabajo se definan, estructuren y presenten de manera consistente. Architecture Content Framework utiliza las siguientes tres categorías para describir el tipo de producto de trabajo arquitectónico dentro del contexto de uso: 





Un entregable es un producto de trabajo que se especifica por contrato y, a su vez, es revisado, acordado y firmado formalmente por las partes interesadas. Los entregables representan el resultado de los proyectos y los entregables que se encuentran en forma de documentación normalmente se archivarán al finalizar un proyecto, o se convertirán en un Repositorio de Arquitectura como modelo de referencia, estándar o instantánea del Paisaje de Arquitectura en un momento dado. Un artefacto es un producto de trabajo arquitectónico que describe un aspecto de la arquitectura. Los artefactos generalmente se clasifican como catálogos (listas de cosas), matrices (que muestran relaciones entre cosas) y diagramas (imágenes de cosas). Los ejemplos incluyen un catálogo de requisitos, una matriz de interacción empresarial y un diagrama de casos de uso. Un entregable arquitectónico puede contener muchos artefactos y los artefactos formarán el contenido del Repositorio de Arquitectura. Un bloque de construcción representa un componente (potencialmente reutilizable) de la capacidad empresarial, de TI o de arquitectura que se puede combinar con otros bloques de construcción para ofrecer arquitecturas y soluciones.

Los bloques de construcción se pueden definir en varios niveles de detalle, según la etapa de desarrollo de la arquitectura que se haya alcanzado. Por ejemplo, en una etapa temprana, un bloque de construcción puede consistir simplemente en un nombre o una descripción de esquema. Más adelante, un bloque de construcción puede descomponerse en múltiples bloques de construcción de soporte y puede ir acompañado de una especificación completa. Los bloques de construcción pueden relacionarse con "arquitecturas" o "soluciones". o

o

Los bloques de construcción de arquitectura (ABB) generalmente describen la capacidad requerida y dan forma a la especificación de los bloques de construcción de solución (SBB). Por ejemplo, puede requerirse una capacidad de servicio al cliente dentro de una empresa, respaldada por muchos SBB, como procesos, datos y software de aplicación. Los bloques de creación de soluciones (SBB) representan componentes que se utilizarán para implementar la capacidad requerida. Por ejemplo, una red es un bloque de construcción que puede describirse a través de artefactos complementarios y luego ponerse en uso para realizar soluciones para la empresa.

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

Figura 2-1: Relaciones entre entregables, artefactos y bloques de construcción Por ejemplo, un documento de definición de arquitectura es un entregable que documenta una descripción de arquitectura. Este documento contendrá una serie de artefactos complementarios que son vistas de los bloques de construcción relevantes para la arquitectura. Por ejemplo, se puede crear un diagrama de flujo de proceso (un artefacto) para describir el proceso de manejo de llamadas de destino (un componente). Este artefacto también puede describir otros componentes básicos, como los actores involucrados en el proceso (por ejemplo, un Representante de Servicios al Cliente). En la Figura 2-2 se ilustra un ejemplo de las relaciones entre entregables, artefactos y bloques de construcción .

Figura 2-2: Ejemplo - Documento de definición de arquitectura

2.6 Continuo empresarial TOGAF incluye el concepto de Enterprise Continuum, que establece el contexto más amplio para un arquitecto y explica cómo las soluciones genéricas pueden aprovecharse y especializarse para cumplir con los requisitos de una organización individual. Enterprise Continuum es una vista del Repositorio de Arquitectura que proporciona métodos para clasificar los artefactos de la arquitectura y las soluciones a medida que evolucionan desde arquitecturas de base genéricas a arquitecturas específicas de la organización. Enterprise Continuum comprende dos conceptos complementarios: Architecture Continuum y Solutions Continuum. En la Figura 2-3 se muestra una descripción general de la estructura y el contexto de Enterprise Continuum .

Figura 2-3: Enterprise Continuum

2.7 Repositorio de Arquitectura Apoyo a Enterprise Continuum es el concepto de un Repositorio de Arquitectura que se puede usar para almacenar diferentes clases de resultados arquitectónicos en diferentes niveles de abstracción, creados por el ADM. De esta manera, TOGAF facilita la comprensión y la cooperación entre las partes interesadas y los profesionales a diferentes niveles. A través de Enterprise Continuum y Architecture Repository, se anima a los arquitectos a aprovechar todos los demás recursos y recursos de arquitectura relevantes en el desarrollo de una arquitectura específica de la organización. En este contexto, se puede considerar que el TOGAF ADM describe un ciclo de vida del proceso que opera en múltiples niveles dentro de la organización, operando dentro de un marco de gobierno holístico y produciendo resultados alineados que residen en un repositorio de arquitectura. Enterprise Continuum proporciona un contexto valioso para comprender los modelos arquitectónicos: muestra los bloques de construcción y sus relaciones entre sí, y las limitaciones y requisitos de un ciclo de desarrollo de la arquitectura. La estructura del repositorio de arquitectura TOGAF se muestra en la Figura 2-4 .

Figura 2-4: Estructura del repositorio de arquitectura TOGAF Los componentes principales dentro de un repositorio de arquitectura son los siguientes:   



 

El metamodelo de la arquitectura describe la aplicación adaptada a la organización de un marco de arquitectura, incluido un metamodelo para el contenido de la arquitectura. La Capacidad de Arquitectura define los parámetros, estructuras y procesos que soportan la gobernabilidad del Repositorio de Arquitectura. El paisaje arquitectónico es la representación arquitectónica de los activos desplegados dentro de la empresa operativa en un momento determinado en el tiempo. Es probable que el paisaje exista en múltiples niveles de abstracción para adaptarse a diferentes objetivos de arquitectura. La Base de información de estándares (SIB) captura los estándares que deben cumplir las nuevas arquitecturas, que pueden incluir estándares de la industria, productos y servicios seleccionados de proveedores o servicios compartidos ya implementados dentro de la organización. La Biblioteca de referencia proporciona pautas, plantillas, patrones y otras formas de material de referencia que pueden aprovecharse para acelerar la creación de nuevas arquitecturas para la empresa. El registro de gobierno proporciona un registro de la actividad de gobierno en toda la empresa.

2.8 Establecimiento y mantenimiento de una capacidad de arquitectura empresarial Para llevar a cabo una actividad arquitectónica eficaz dentro de una empresa, es necesario establecer una capacidad empresarial adecuada para la arquitectura, a través de las estructuras de la organización, roles, responsabilidades, habilidades y procesos. En la Figura 25 se muestra una descripción general de la capacidad de la arquitectura TOGAF .

Figura 2-5: Descripción general de la capacidad de la arquitectura TOGAF

2.9 Estableciendo la capacidad de la arquitectura como una entidad operativa A menos que las capacidades de la arquitectura se configuren para soportar únicamente los programas de entrega de cambios, se reconoce cada vez más que una práctica exitosa de arquitectura empresarial debe estar sobre una base operativa firme. En efecto, una práctica de arquitectura empresarial debe ejecutarse como cualquier otra unidad operativa dentro de un negocio; Es decir, debe ser tratado como un negocio. Para este fin, y más allá de los procesos centrales definidos dentro del ADM, una práctica de arquitectura empresarial debe establecer capacidades en las siguientes áreas:          

Gestión financiera Gestión del rendimiento (véase 3.52 Gestión del rendimiento ) Gestión De Servicios Gestión de riesgos (véase A.75 Gestión de riesgos ) Administracion de recursos Gestión de comunicaciones y partes interesadas (véase 3.29 Gestión de comunicaciones y partes interesadas ) Gestión de la calidad Gestión de proveedores (ver A.82 Gestión de proveedores ) Gestión de la configuración (véase A.15 Gestión de la configuración ) Gestión del medio ambiente

Un elemento central de la noción de operar una arquitectura en curso es la ejecución de un gobierno bien definido y efectivo, mediante el cual toda actividad arquitectónicamente significativa se controla y alinea dentro de un marco único.

A medida que la gobernanza se ha convertido en un requisito cada vez más visible para la gestión organizativa, la inclusión de la gobernanza dentro de TOGAF alinea el marco con las mejores prácticas comerciales actuales y también garantiza un nivel de visibilidad, orientación y control que respaldará todos los requisitos y obligaciones de las partes interesadas de la arquitectura. Los beneficios del gobierno de la arquitectura incluyen:       





Mayor transparencia en la rendición de cuentas y delegación informada de autoridad. Gestión controlada de riesgos. Protección de la base de activos existente mediante la maximización de la reutilización de los componentes arquitectónicos existentes Control proactivo, monitoreo y mecanismos de gestión. Proceso, concepto y reutilización de componentes en todas las unidades de negocio organizativas Creación de valor a través del monitoreo, medición, evaluación y retroalimentación. Mayor visibilidad que respalda los procesos internos y los requisitos de las partes externas; en particular, la mayor visibilidad de la toma de decisiones en los niveles más bajos garantiza la supervisión a un nivel apropiado dentro de la empresa de las decisiones que pueden tener consecuencias estratégicas de gran alcance para la organización Mayor valor para el accionista; en particular, la arquitectura empresarial representa cada vez más la propiedad intelectual principal de la empresa: los estudios han demostrado una correlación entre el aumento del valor de los accionistas y las empresas bien gobernadas Se integra con los procesos y metodologías existentes y complementa la funcionalidad al agregar capacidades de control

En la Parte VII , 45. Introducción , se proporciona información más detallada sobre el establecimiento de una capacidad de arquitectura empresarial .

2.10 Usando TOGAF con otros frameworks Dos de los elementos clave de cualquier marco de arquitectura empresarial son:  

Una definición de los entregables que la actividad de arquitectura debe producir. Una descripción del método por el cual esto debería hacerse.

Con algunas excepciones, la mayoría de los marcos de arquitectura empresarial se centran en el primero de ellos, el conjunto específico de entregables, y guardan silencio sobre los métodos que se utilizarán para generarlos (intencionalmente, en algunos casos). Debido a que TOGAF es un marco genérico y está pensado para ser utilizado en una amplia variedad de entornos, proporciona un marco de contenido flexible y extensible que apuntala un conjunto de entregables genéricos de arquitectura. Como resultado, TOGAF se puede utilizar por derecho propio, con los entregables genéricos que describe; o de lo contrario, estos entregables pueden ser reemplazados o extendidos por un conjunto más específico, definido en cualquier otro marco que el arquitecto considere relevante. En todos los casos, se espera que el arquitecto se adapte y se base en el marco de TOGAF para definir un método personalizado que se integre en los procesos y las estructuras de organización de la empresa. Esta adaptación de la arquitectura 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, como ITIL, CMMI, COBIT, PRINCE2, PMBOK y MSP. Las pautas para adaptar el ADM TOGAF de tal manera se dan en la Parte II , 5.3 Adaptación del ADM .

Como marco genérico y método para la arquitectura empresarial, TOGAF proporciona la capacidad y el entorno de colaboración para integrarse con otros marcos. Las organizaciones pueden utilizar completamente los dominios comerciales verticales, las áreas de tecnología horizontal (como la seguridad o la capacidad de administración) o las áreas de aplicación (como el comercio electrónico) para producir un marco de arquitectura empresarial competitivo que maximice sus oportunidades de negocios. volver al inicio de la página

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 proporcionar un enfoque para el análisis que se ocupa de un nivel de detalle o abstracción consistente y común. La abstracción en este sentido se usa normalmente en la arquitectura para permitir que se logre un nivel consistente de definición y comprensión en cada área de la arquitectura con el fin de apoyar la comunicación efectiva y la toma de decisiones. Es especialmente útil cuando se trata de arquitecturas grandes y complejas, ya que permite identificar problemas relevantes antes de intentar más detalles.

3.2 actor Una persona, organización o sistema que tiene un rol que inicia o interactúa con actividades; por ejemplo, un representante de ventas que viaja para visitar a los clientes. Los actores pueden ser internos o externos a una organización. En la industria automotriz, un fabricante de equipo original sería considerado un actor por un concesionario automotriz que interactúa con sus actividades de cadena de suministro.

3.3 Aplicación Un sistema de TI implementado y operativo que soporta funciones y servicios comerciales; por ejemplo, una nómina. Las aplicaciones utilizan datos y están respaldadas por múltiples componentes tecnológicos, pero son diferentes de los componentes tecnológicos que admiten la aplicación.

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

3.5 Plataforma de aplicaciones La colección de componentes tecnológicos de hardware y software que proporcionan los servicios utilizados para soportar aplicaciones.

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

3.7 Estilo arquitectónico

La combinación de características distintivas en las que se realiza o 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 guiar su implementació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 a lo largo del tiempo.

3.9 Arquitectura Building Block (ABB) Un componente del modelo de arquitectura que describe un aspecto único del modelo general. Véase también 3.21 Building Block .

3.10 Arquitectura continua Una parte de la empresa continua. Un repositorio de elementos arquitectónicos con creciente detalle y especialización. Este Continuum comienza con definiciones fundamentales como modelos de referencia, estrategias básicas y bloques de construcción básicos. Desde allí se extiende a las arquitecturas industriales y hasta la arquitectura específica de una organización. Véase también 3.35 Enterprise Continuum .

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

3.12 Dominio de la arquitectura La zona arquitectónica considerada. Hay cuatro dominios de arquitectura dentro de TOGAF: negocios, datos, aplicaciones y tecnología.

3.13 Marco de Arquitectura Una estructura conceptual utilizada para desarrollar, implementar y sostener una arquitectura.

3.14 Gobierno de la arquitectura La práctica y orientación mediante la cual las arquitecturas empresariales y otras arquitecturas se administran y controlan a nivel de toda la empresa. Se ocupa de los procesos de cambio (diseño de gobierno) y la operación de los sistemas de productos (gobierno de funcionamiento). Ver también 3.39 Gobernanza .

3.15 Arquitectura del paisaje La representación arquitectónica de los activos en uso, o planificados, por la empresa en puntos específicos en el tiempo.

3.16 Principios de Arquitectura Una declaración de intenciones cualitativa que debe cumplir la arquitectura. Tiene al menos una justificación de apoyo y una medida de importancia. Nota: Un conjunto de muestra de Principios de Arquitectura se define en la Parte III , 23. Principios de Arquitectura .

3.17 Visión de la arquitectura Una descripción breve de la arquitectura de destino que describe su valor comercial y los cambios en la empresa que resultarán de su implementación exitosa. Sirve como una visión aspiracional y un límite para el desarrollo detallado de la arquitectura. Nota: La fase A (Visión de la arquitectura) se describe en la Parte II , 7. Fase A: Visión de la arquitectura .

3.18 Artefacto Un producto de obra arquitectónica que describe un aspecto de la arquitectura. Véase también 3.21 Building Block .

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

3.20 Flujo de información sin límites 1. Una marca registrada de The Open Group. 2. Una representación abreviada de "acceso a información integrada para respaldar las mejoras de los procesos de negocios" que representa un estado deseado de la infraestructura de una empresa específica para las necesidades comerciales de la organización. Una infraestructura que proporciona flujo de información sin límites tiene componentes estándar abiertos que proporcionan servicios en la empresa extendida de un cliente que:  

Combina múltiples fuentes de información Ofrezca la información de forma segura en cualquier momento y en cualquier lugar, en el contexto adecuado para las personas o los sistemas que utilizan esa información.

Nota: La necesidad de flujo de información sin límites se describe en la Parte VI , 44. Modelo de referencia de infraestructura de información integrada .

3.21 Bloque de construcción

Representa un componente (potencialmente reutilizable) de la capacidad empresarial, de TI o arquitectónica que se puede combinar con otros componentes básicos para ofrecer arquitecturas y soluciones. Los bloques de construcción se pueden definir en varios niveles de detalle, según la etapa de desarrollo de la arquitectura que se haya alcanzado. Por ejemplo, en una etapa temprana, un bloque de construcción puede consistir simplemente en un nombre o una descripción de esquema. Más adelante, un bloque de construcción puede descomponerse en múltiples bloques de construcción de soporte y puede ir acompañado de una especificación completa. Los bloques de construcción pueden relacionarse con "arquitecturas" o "soluciones". Ver también 3.18 Artefacto . Nota: Los bloques de construcción se describen en la Parte IV , 37. Bloques de construcción .

3.22 Arquitectura empresarial Una descripción de la estructura e interacción entre la estrategia de negocios, la organización, las funciones, los procesos de negocios y las necesidades de información. Nota: Arquitectura de negocios se describe en la Parte II , 8. Fase B: Arquitectura de negocios .

3.23 Función de negocios Ofrece capacidades comerciales estrechamente alineadas con una organización, pero no necesariamente están explícitamente gobernadas por la organización.

3.24 Gobernanza Empresarial Preocupado por garantizar que los procesos y políticas comerciales (y su funcionamiento) entreguen los resultados comerciales y se adhieran a las regulaciones comerciales pertinentes.

3.25 Servicio de Negocios Admite las capacidades empresariales a través de una interfaz explícitamente definida y se rige explícitamente por una organización.

3.26 Capacidad Una habilidad que posee una organización, persona o sistema. Las capacidades generalmente se expresan 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 lograrlos. Por ejemplo, marketing, contacto con el cliente o telemarketing saliente.

3.27 Arquitectura de la capacidad Una descripción altamente detallada del enfoque arquitectónico para realizar una solución particular o un aspecto de la solución.

3.28 Incremento de capacidad

Una parte discreta de una arquitectura de capacidad que ofrece un valor específico. Cuando todos los incrementos se han completado, la capacidad se ha realizado.

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

3.30 Preocupaciones Los intereses clave que son de crucial importancia para las partes interesadas en un sistema y determinan la aceptabilidad del sistema. Las inquietudes pueden referirse a cualquier aspecto del funcionamiento, desarrollo u operación del sistema, incluidas consideraciones como el rendimiento, la confiabilidad, la seguridad, la distribución y la capacidad de evolución. Ver también 3.68 Stakeholder .

3.31 Restricción Un factor externo que impide que una organización siga enfoques particulares para cumplir sus objetivos. Por ejemplo, los datos de los clientes no están armonizados dentro de la organización, a nivel 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 e interacción de los principales tipos y fuentes de datos de la empresa, activos de datos lógicos, activos de datos físicos y recursos de administración de datos. Nota: La arquitectura de datos se describe en la Parte II , 10. Fase C: Arquitecturas de sistemas de información - Arquitectura de datos .

3,33 entregables Un producto de trabajo arquitectónico que se especifica por contrato y, a su vez, es revisado, acordado y firmado formalmente por los interesados. Los entregables representan el resultado de los proyectos y los entregables que se encuentran en forma de documentación normalmente se archivarán al finalizar un proyecto, o se convertirán en un Repositorio de Arquitectura como modelo de referencia, estándar o instantánea del Paisaje de Arquitectura en un momento dado.

3.34 Empresa El nivel más alto (típicamente) de descripción de una organización y generalmente cubre todas las misiones y funciones. Una empresa suele abarcar varias organizaciones.

3.35 Enterprise Continuum

Un mecanismo de categorización útil para clasificar artefactos de arquitectura y soluciones, tanto internos como externos al Repositorio de Arquitectura, a medida que evolucionan desde arquitecturas de base genéricas a arquitecturas específicas de la organización. Véase también 3.10 Architecture Continuum y 3.67 Solutions Continuum .

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

Marco 3.37 Una estructura para el contenido o proceso que se puede utilizar como una herramienta para estructurar el pensamiento, garantizando la coherencia y la integridad.

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

3.39 Gobernanza La disciplina de monitorear, administrar y dirigir un negocio (o entorno IS / IT) para entregar el resultado de negocio requerido. Véase también 3.14 Arquitectura de gobierno , 3.24 Gobierno de negocios y A.60 Gobierno operativo en A. Glosario de definiciones complementarias .

3.40 Información Cualquier comunicación o representación de hechos, datos u opiniones, en cualquier medio o forma, incluidas las formas textuales, numéricas, gráficas, cartográficas, narrativas o audiovisuales.

3.41 Tecnología de la información (TI) 1. La gestión del ciclo de vida de la información y la tecnología relacionada utilizada por una organización. 2. Un término general que incluye todas o algunas de las áreas temáticas relacionadas con la industria de la computación, tales como Continuidad de negocios, Interfaz de TI para negocios, Modelado y administración de procesos de negocios, Comunicación, Cumplimiento y legislación, Computadoras, Administración de contenido, Hardware, Administración de información, Internet , Offshoring, Networking, 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 generales para describir esta misma colección. 3. Un término comúnmente asignado a un departamento dentro de una organización encargada de aprovisionar algunos o todos los dominios descritos en (2) arriba. 4. Los nombres alternativos comúnmente adoptados incluyen Servicios de Información, Gestión de la Información, y otros.

3.42 interoperabilidad 1. La posibilidad de compartir información y servicios. 2. La capacidad de dos o más sistemas o componentes para intercambiar y utilizar información. 3. La capacidad de los sistemas para proporcionar y recibir servicios de otros sistemas y utilizar los servicios intercambiados para permitirles operar juntos de manera efectiva.

3,43 lógico Una definición de la arquitectura independiente de la implementación, que a menudo agrupa entidades físicas relacionadas de acuerdo con su propósito y estructura. Por ejemplo, los productos de múltiples proveedores de software de infraestructura pueden agruparse lógicamente como plataformas de servidor de aplicaciones Java.

3,44 metadatos Datos sobre datos, de cualquier tipo, en cualquier medio, que describan las características de una entidad.

3,45 metamodelo Un modelo que describe cómo y con qué se describirá la arquitectura de manera estructurada.

3.46 Método Un enfoque definido y repetible para abordar un tipo particular de problema. Ver también 3.47 Metodología .

3.47 Metodologia Una serie de pasos definidos y repetibles para abordar un tipo particular de problema, que generalmente se centra en un proceso definido, pero también puede incluir la definición de contenido. Véase también el método 3.46 .

Modelo 3,48 Una representación de un tema de interés. Un modelo proporciona una representación a menor escala, simplificada y / o abstracta del tema. Un modelo se construye como un "medio para un fin". En el contexto de la arquitectura empresarial, el tema es una parte o parte de la empresa y el fin es la capacidad de construir "puntos de vista" que aborden las inquietudes de partes interesadas particulares; Es decir, sus "puntos de vista" en relación con el tema. Vea también 3.68 Stakeholder , 3.75 View y 3.76 Viewpoint .

3.49 modelado Una técnica a través de la construcción de modelos que permite que un sujeto se represente en una forma que permita el razonamiento, la comprensión y la claridad con respecto a la esencia del tema.

3.50 objetivo Un hito limitado en el tiempo para una organización utilizado para demostrar el progreso hacia una meta; por ejemplo, "Aumentar la utilización de la capacidad en un 30% para fines de 2009 para respaldar el aumento planificado de la participación de mercado".

3.51 patrones Una técnica para poner los bloques de construcción en contexto; por ejemplo, para describir una solución reutilizable a un problema. Los bloques de construcción son lo que usa: los patrones pueden decirle cómo los usa, cuándo, por qué y qué compensaciones debe hacer al hacerlo. Véase también 3.21 Building Block .

3.52 Gestión del rendimiento El monitoreo, control y reporte del desempeño de la práctica de arquitectura empresarial. También preocupado por la mejora continua.

3.53 fisico Una descripción de una entidad del mundo real. Los elementos físicos en una arquitectura empresarial aún pueden estar considerablemente abstraídos de la arquitectura de la solución, el diseño o las vistas de implementación.

Plataforma 3.54 Una combinación de productos y componentes de infraestructura tecnológica que proporciona los requisitos previos para hospedar el software de la aplicación.

Servicio de plataforma 3.55 Una capacidad técnica requerida para proporcionar una infraestructura habilitadora que admita la entrega de aplicaciones.

Principio 3.56 Ver 3.16 Principios de Arquitectura .

3.57 Modelo de referencia (RM) Un modelo de referencia es un marco abstracto para comprender las relaciones significativas entre las entidades de [un] entorno y para el desarrollo de estándares o especificaciones coherentes que respalden ese entorno. Un modelo de referencia se basa en un pequeño número de conceptos unificadores y se puede utilizar como base para la educación y para explicar los estándares a un no especialista. Un modelo de referencia no está directamente vinculado a ningún estándar, tecnología u otros detalles de implementación concretos, pero sí busca proporcionar una semántica común que se pueda usar sin ambigüedades en diferentes implementaciones y entre ellas. Nota: La fuente de esta definición es OASIS; consulte www.oasisopen.org/committees/tc_home.php?wg_abbrev=soa-rm .

Repositorio 3.58 Un sistema que gestiona todos los datos de una empresa, incluidos los modelos de datos y procesos y otra información empresarial. Por lo tanto, los datos en un repositorio son mucho más extensos que los de un diccionario de datos, que generalmente define solo los datos que forman una base de datos.

Requisito 3.59 Una declaración de necesidad que debe cumplir una arquitectura o paquete de trabajo en particular.

3.60 Hoja de ruta Un plan abstracto para el cambio de negocios o tecnología, que generalmente opera en múltiples disciplinas durante varios años. Normalmente se utiliza en las frases Technology Roadmap, Architecture Roadmap, etc.

3.61 papel 1. La función usual o esperada 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 roles. 2. La parte que un individuo juega en una organización y la contribución que hacen a través de la aplicación de sus habilidades, conocimientos, experiencia y habilidades. Ver también 3.2 Actor .

3.62 Arquitectura de segmentos Una descripción detallada y formal de las áreas dentro de una empresa, utilizada a nivel de programa o cartera para organizar y alinear la actividad de cambio. Ver también 3.70 Arquitectura estratégica .

3.63 Orientación al servicio Una forma de pensar en términos de servicios y desarrollo basado en servicios y los resultados de los servicios. Ver también 3.64 Arquitectura Orientada a Servicios (SOA) .

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

Se basa en el diseño de los servicios, que reflejan las actividades comerciales del mundo real, y comprende los procesos empresariales de la empresa (o entre empresas). La representación de servicio utiliza descripciones de negocios para proporcionar contexto (es decir, proceso de negocio, objetivo, regla, política, interfaz de servicio y componente de servicio) e implementa servicios utilizando la orquestación de servicios.

   

Establece requisitos únicos en la infraestructura: se recomienda que las implementaciones utilicen estándares abiertos para lograr la interoperabilidad y la transparencia de la ubicación. Las implementaciones son específicas del entorno; están restringidas o habilitadas por el contexto y se deben describir dentro de ese contexto. Requiere una sólida gobernanza de la representación e implementación del servicio. Requiere una "Prueba de fuego", que determina un "buen servicio".

Ver también 3.7 Estilo arquitectónico y 3.63 Orientación al servicio .

3.65 Arquitectura de la solución Una descripción de una operación o actividad comercial discreta y enfocada y cómo IS / IT apoya esa operación. Una arquitectura de solución generalmente se aplica a un solo proyecto o lanzamiento de proyecto, asistiendo en la traducción de los requisitos en una visión de la solución, especificaciones de alto nivel para el negocio y / o el sistema de TI, y una cartera de tareas de implementación.

Bloque de construcción de la solución 3.66 (SBB) Una solución candidata que se ajusta a la especificación de un bloque de construcción de arquitectura (ABB).

3.67 Soluciones Continuum Una parte de la empresa continua. Un repositorio de soluciones reutilizables para futuros esfuerzos de implementación. Contiene implementaciones de las definiciones correspondientes en el Continuum de Arquitectura. Véase también 3.35 Enterprise Continuum y 3.10 Architecture Continuum .

3.68 partes interesadas Un individuo, equipo u organización (o clases del mismo) con intereses o preocupaciones relacionadas con el resultado de la arquitectura. Diferentes partes interesadas con diferentes roles tendrán diferentes preocupaciones. Consulte también A.85 Partes interesadas del sistema en A. Glosario de definiciones suplementarias .

3.69 Base de Información de Normas (SIB) Una base de datos de estándares que se puede usar para definir los servicios particulares y otros componentes de una arquitectura específica de la organización. Nota: La Base de información de estándares se describe en la Parte V , 41.4 Base de información de estándares .

3.70 Arquitectura estratégica Una descripción formal resumida de la empresa, que proporciona un marco organizativo para la actividad operativa y de cambio, y una visión a largo plazo a nivel ejecutivo para establecer la dirección.

3.71 Arquitectura de destino La descripción de un estado futuro de la arquitectura que se está desarrollando para una organización. Puede haber varios estados futuros desarrollados como una hoja de ruta para mostrar la evolución de la arquitectura a un estado objetivo.

3.72 Taxonomía de vistas de arquitectura La colección organizada de todas las vistas pertinentes a una arquitectura.

3.73 Arquitectura de la tecnología Una descripción de la estructura e interacción de los servicios de la plataforma, y los componentes de tecnología lógica y física. Nota: La arquitectura tecnológica se describe en la Parte II , 12. Fase D: Arquitectura tecnológica .

3.74 Arquitectura de transición Una descripción formal de un estado de la arquitectura en un momento arquitectónico significativo. Se pueden usar una o más arquitecturas de transición para describir la progresión en el tiempo desde la línea de base hasta la arquitectura de destino. Nota: La arquitectura de transición se describe en la Parte IV , 36.2.3 Documento de definición de arquitectura .

3.75 Ver La representación de un conjunto relacionado de preocupaciones. Una vista es lo que se ve desde un punto de vista. Una vista de arquitectura puede estar representada por un modelo para demostrar a las partes interesadas sus áreas de interés en la arquitectura. Una vista no tiene que ser de naturaleza visual o gráfica. Ver también 3.68 Stakeholder y 3.76 Viewpoint .

3.76 punto de vista Una definición de la perspectiva desde la cual se toma una vista. Es una especificación de los convenios para construir y usar una vista (a menudo por medio de un esquema o plantilla apropiados). Una vista es lo que ves; un punto de vista es desde donde miras: el punto de vista o perspectiva que determina lo que ves. Ver también A.56 Metaview en A. Glosario de definiciones suplementarias .

3.77 paquete de trabajo Un conjunto de acciones identificadas para lograr uno o más objetivos para el negocio. Un paquete de trabajo puede ser parte de un proyecto, un proyecto completo o un programa. volver al inicio de la página

Navegación

El conjunto de documentos TOGAF está diseñado para su uso con marcos. Para navegar por el documento:  

En el marco principal de Contenidos en el margen izquierdo de la página, haga clic en el hipervínculo correspondiente para cargar la Lista de Contenidos para esa Parte del documento TOGAF o vaya directamente a un capítulo dentro del documento. Dentro de un capítulo, puede seleccionar Anterior y Siguiente en la parte superior e inferior de la página para pasar al capítulo anterior o al siguiente, o seleccionar Inicio para volver a la página de bienvenida.

4.1 ¿Qué hay de nuevo en TOGAF 9? Esta sección proporciona una descripción general de las principales funciones nuevas dentro de TOGAF 9. Estructura modular

Uno de los objetivos del desarrollo de TOGAF 9 ha sido garantizar que el contenido de la especificación esté estructurado de manera modular. La estructura modular de siete partes de TOGAF permite que los conceptos en cada parte se desarrollen con impactos limitados en otras partes. El contenido que estaba contenido en TOGAF 8.1.1 Resource Base se ha clasificado y movido a partes que tienen un propósito definido (a diferencia de los "recursos" genéricos). La estructura modular en TOGAF está diseñada para soportar una mayor facilidad de uso, ya que cada parte tiene un propósito definido y se puede leer de forma aislada como un conjunto independiente de pautas. También se espera que la estructura modular admita la adopción incremental de la especificación TOGAF. Finalmente, la estructura modular es compatible con una administración de versiones más sofisticada de la especificación TOGAF. En el futuro, las piezas individuales pueden evolucionar a diferentes velocidades y la estructura de especificación actual está diseñada para permitir que se realicen cambios en un área con impactos limitados en toda la especificación. Marco de contenido

Una adición significativa de nuevo contenido a la especificación TOGAF es el marco de contenido. El marco de contenido TOGAF proporciona un modelo detallado de los productos de trabajo arquitectónico, incluidos los entregables, los artefactos dentro de los productos entregables, y los bloques arquitectónicos que los artefactos representan. La intención de incluir un marco de contenido dentro de TOGAF es lograr una mayor coherencia en los resultados que se crean al seguir un Método de Desarrollo de Arquitectura (ADM). El beneficio de incluir un marco de contenido se aplica a varios niveles. En primer lugar, dentro de una sola iniciativa de desarrollo de arquitectura, el marco de contenido proporciona una lista de verificación completa de los resultados de la arquitectura que podrían crearse y, en consecuencia, reducir el riesgo de brechas dentro del conjunto final de la arquitectura. El segundo beneficio principal de la inclusión de un marco de contenido se aplica cuando se intenta integrar productos de trabajo de arquitectura en una empresa. El marco de contenido está diseñado para ser adaptado y luego adoptado por una empresa con el fin de exigir conceptos, términos y resultados arquitectónicos estándar. Si todas las iniciativas de arquitectura utilizan los mismos modelos para el contenido, sus resultados se pueden combinar mucho más fácilmente que en situaciones en las que cada arquitecto utiliza un enfoque completamente diferente.

Finalmente, un beneficio sustancial de la inclusión de un marco de contenido dentro de TOGAF es que proporciona (por primera vez) un estándar abierto detallado sobre cómo deben describirse las arquitecturas. La existencia de este estándar permite a los proveedores de herramientas, proveedores de productos y proveedores de servicios adoptar formas de trabajo coherentes, lo que a su vez dará como resultado una mayor coherencia entre las herramientas de arquitectura, una mejor interoperabilidad de las herramientas, arquitecturas de referencia más consistentes y una mejor comparabilidad entre las arquitecturas de referencia relacionadas. . Orientación ampliada sobre la adopción de TOGAF dentro de una empresa

Dentro de las organizaciones más grandes, la práctica de la arquitectura empresarial requiere un número de individuos y equipos que trabajan juntos en muchas arquitecturas. Aunque cada arquitectura abordará un problema específico, en una situación ideal, las arquitecturas pueden considerarse como un grupo para desarrollar una visión global integrada de cómo está cambiando la empresa. Esta versión de TOGAF presenta un conjunto extendido de conceptos y pautas para respaldar el establecimiento de una jerarquía integrada de arquitecturas desarrolladas por equipos que operan dentro de un modelo de gobierno arquitectónico general. En particular, se introducen los siguientes conceptos: 

 

Partición : para desarrollar arquitecturas que tengan niveles manejables de costo y complejidad, es necesario dividir la empresa en arquitecturas específicas. TOGAF discute el concepto de partición y proporciona una variedad de técnicas y consideraciones sobre cómo particionar las diversas arquitecturas dentro de una empresa. Repositorio de arquitectura : TOGAF proporciona un modelo de información lógica para un repositorio de arquitectura, que se puede utilizar como un almacén integrado para todas las salidas creadas al ejecutar el ADM. Marco de capacidades : esta versión de TOGAF proporciona una definición más estructurada de la organización, habilidades, roles y responsabilidades necesarias para operar una capacidad de arquitectura empresarial efectiva. Los nuevos materiales TOGAF también brindan orientación sobre un proceso que se puede seguir para identificar y establecer una Capacidad de Arquitectura apropiada.

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

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

Los diversos usos de la iteración que son posibles dentro del ADM y cuándo se debe aplicar cada técnica. Los vínculos entre TOGAF ADM y Service Oriented Architecture (SOA) Las consideraciones específicas requeridas para abordar la arquitectura de seguridad dentro del ADM Los diversos tipos de desarrollo de arquitectura requeridos dentro de una empresa y cómo estos se relacionan entre sí.

Detalle ADM adicional

Esta versión de la especificación TOGAF incluye información más detallada que respalda la ejecución del ADM. Las áreas particulares de mejora son: 

La Fase Preliminar, que presenta una guía extendida sobre el establecimiento de un marco de arquitectura empresarial y la planificación para el desarrollo de la arquitectura. La Fase Preliminar extendida también proporciona indicadores para la



definición de un modelo de gobierno para la realización de beneficios de arquitectura y también analiza el vínculo entre TOGAF y otros marcos de gestión. La fase de Oportunidades y Soluciones y la fase de Planificación de la Migración, que presenta un método más detallado y sólido para definir y planificar la transformación de la empresa, basada en los principios de la planificación basada en la capacidad.

4.1.1 Cambios aplicados en esta edición Esta edición de TOGAF 9 incluye un conjunto de actualizaciones de mantenimiento basadas en los comentarios recibidos en la publicación de 2009. Un documento detallado por separado de los cambios está disponible como Corrigendum Técnico No. 1 de TOGAF 9 (Documento U112). A continuación se incluye una lista de resumen de los cambios:     

          



Las definiciones de los términos donde el uso por TOGAF no se distingue de la definición del diccionario común se han eliminado. El uso de los términos "aplicación" frente a "sistema" se ha revisado y hecho coherente. Las descripciones de las fases E y F se han modificado para que coincidan con el nivel de detalle en otras fases. Los usos de la terminología para la Arquitectura de transición / Hoja de ruta / Estrategia de implementación se han aclarado y hecho coherentes. Los conceptos de niveles / iteraciones / particiones han sido aclarados y hechos consistentes. Esto incluye una reorganización del material en la Parte III , 19. Aplicación de la iteración al ADM y 20. Aplicación del ADM en el panorama de la arquitectura , y la Parte V , 40. Partición de la arquitectura . Las secciones de "Objetivos" de las fases se han modificado para centrarse en objetivos reales en lugar de técnicas o una lista de pasos. Los posibles artefactos (puntos de vista) para cada fase ahora se enumeran en la descripción de esa fase, no solo en la Parte IV , 35. Artefactos arquitectónicos . Los términos "artefacto" frente a "punto de vista" se han aclarado y hecho coherentes. Esto incluye una reestructuración de la Parte IV , 35. Artefactos arquitectónicos . El capítulo de SOA ( Parte III , 22. Uso de TOGAF para definir y gobernar SOA ) se ha actualizado para describir la última salida del Grupo de trabajo de SOA. Se ha agregado texto introductorio adicional sobre estilos arquitectónicos en la Parte III , 18. Introducción . Se han realizado cambios menores en el capítulo de Arquitectura de seguridad ( Parte III , 21. Arquitectura de seguridad y el ADM ) para mantener la coherencia con el ADM. Se han hecho correcciones a los diagramas de metamodelo. Se han aplicado correcciones a aspectos del metamodelo. El ejemplo de Building Blocks ha sido eliminado. El modelo de categorización de documentos ha sido eliminado. El texto duplicado en varios lugares se ha reemplazado con una referencia apropiada: o El Análisis de Brechas en las Fases B, C y D ahora hace referencia a la Parte III , 27. Análisis de Brechas . o La Gestión de requisitos en varias fases ahora hace referencia a la Parte II , 17.2.2 Desarrollo de requisitos en la fase de Gestión de requisitos. Algunos de los artefactos han sido renombrados para reflejar mejor su uso: o Sistema / Matriz de datos se convierte en Aplicación / Matriz de datos. o El diagrama de clase se ha reemplazado con el diagrama de datos conceptuales y el diagrama de datos lógicos o La matriz de sistema / organización se convierte en matriz de aplicación / organización o La matriz de rol / sistema se convierte en matriz de rol / aplicación o La matriz de sistema / función se convierte en matriz de aplicación / función o El diagrama de proceso / realización del sistema se convierte en el diagrama de proceso / realización de la aplicación o El diagrama de casos de uso del sistema se convierte en un diagrama de casos de uso de aplicaciones

o





   

Matriz de Sistema / Tecnología se convierte en matriz de Aplicación / Tecnología La descripción de los Principios de Arquitectura ahora los divide en dos tipos solamente: Empresa y Arquitectura, mientras que antes mencionaban los Principios de TI por separado. Los Principios de TI ahora son vistos como parte de los Principios de Empresa. El Mapa de partes interesadas incluido en el capítulo Gestión de partes interesadas ( Parte III , 24. Gestión de partes interesadas ) ahora se menciona explícitamente como un ejemplo, la tabla se ha resaltado para referirse a Preocupaciones de partes interesadas, y se ha actualizado la lista de artefactos para cada parte interesada. El capítulo de Escenarios de negocios ( Parte III , 26. Escenarios de negocios y metas de negocios ) ha sido renombrado a Escenarios de negocios y Objetivos de negocios para reflejar mejor el contenido del capítulo. La relación del repositorio de Enterprise con el repositorio de arquitectura se aclara en la Parte V , 41. Repositorio de arquitectura . Los Criterios de evaluación y las Directrices se han eliminado de la Parte V , 42. Herramientas para el desarrollo de la arquitectura . El capítulo sobre los modelos de madurez de la arquitectura ( Parte VII , 51. Modelos de madurez de la arquitectura ) se ha revisado editorialmente para garantizar su coherencia y claridad.

4.2 Los beneficios de TOGAF 9 TOGAF 9 proporciona un amplio conjunto de revisiones a 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 admiten una 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 considerar un aspecto específico de la Capacidad de Arquitectura. En todas las áreas, la especificación busca agregar detalles y claridad por encima y más allá de las versiones anteriores de TOGAF. Más enfoque en el cambio empresarial holístico

TOGAF tiene una sólida historia en arquitectura de TI, considerando las formas en que TI puede apoyar el cambio empresarial. Sin embargo, a medida que TOGAF ha crecido en profundidad y madurez, se ha convertido en un marco para gestionar todo el espectro de cambios necesarios para transformar una empresa hacia un modelo operativo objetivo. TOGAF 9 continúa esta evolución e incorpora una perspectiva más amplia de cambio que permite que la arquitectura empresarial se utilice para especificar la transformación en los dominios de negocios, datos, aplicaciones y tecnología. Más consistencia de salida

Las versiones anteriores de TOGAF se enfocaron en proporcionar un proceso consistente para desarrollar arquitecturas. TOGAF 9 incluye una consideración muy mejorada de los productos de trabajo arquitectónico para garantizar que se utilice un proceso consistente para producir resultados consistentes. Architecture Content Framework proporciona un modelo detallado de los resultados que creará el ADM. Además, las secciones Continuo empresarial, Partición de arquitectura y Repositorio de arquitectura proporcionan una guía detallada sobre cómo los entregables arquitectónicos se pueden controlar, controlar e integrar.

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 proporciona una descripción para explicar dónde se puede encontrar el contenido de TOGAF 8 dentro de la especificación actual. Parte I: Introducción

La parte de Introducción de la especificació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 a TOGAF 9 refleja el contenido de TOGAF 9 en lugar del contenido de TOGAF 8.1.1, y también cuenta con una serie de mejoras para mejorar la accesibilidad. Parte II: Método de desarrollo de la arquitectura.

La esencia de TOGAF 8.1.1 ADM se ha conservado en TOGAF 9. Parte II: Método de desarrollo de arquitectura (ADM) dentro de TOGAF 9 se estructura de forma similar a la Parte II del documento TOGAF 8.1.1. Las entradas y salidas de la fase TOGAF ADM (Capítulo 16 de TOGAF 8.1.1) se han trasladado de la sección ADM de TOGAF 8.1.1 a la Parte IV: Marco de Contenido de Arquitectura de TOGAF 9. TOGAF 9 ADM presenta contenido adicional en la mayoría de las fases de ADM, que en su mayor parte agrega más detalles y aclaraciones al mismo enfoque que se describió en TOGAF 8.1.1. Parte III: Enterprise Continuum

El TOGAF 8.1.1 Enterprise Continuum ha experimentado un cambio sustancial. El concepto Enterprise Continuum se conserva en la Parte V: Enterprise Continuum & Tools . El Modelo de referencia técnica de TOGAF y el Modelo de referencia de infraestructura de información integrada se extraen y se colocan en la Parte VI: Modelos de referencia de TOGAF en TOGAF 9. TOGAF 9 agrega nuevos materiales que describen un enfoque de la partición de la arquitectura y también proporciona un modelo estructurado de un repositorio de arquitectura. Estos conceptos respaldan y explican la intención original de Enterprise Continuum. TOGAF 9 elimina la Base de información de estándares de la especificación TOGAF. Sin embargo, un ejemplo de SIB permanece en el sitio web de The Open Group ( www.opengroup.org ). El concepto de una Base de información de estándares es importante dentro de TOGAF, pero la amplitud y la velocidad de cambio de los estándares arquitectónicos relevantes hacen que no sea práctico mantener una colección actual y relevante de estándares dentro de una especificación como TOGAF. Parte IV: Base de recursos

La Base de recursos no está incluida en esta versión de TOGAF. Algunos elementos de la Base de recursos han quedado en desuso de la especificación TOGAF, pero aún estarán disponibles en forma de Libro Blanco. Otros elementos de la Base de recursos se han movido a otras áreas de la especificación. La siguiente tabla ilustra dónde se puede ubicar el contenido de la Base de recursos TOGAF 8.1.1.

F 8.1.1 Recurso

a

Ubicación actual Movido a la Parte VII: Marco de capacidad de arquitectura Movido a la Parte VII: Marco de capacidad de arquitectura Movido a la Parte VII: Marco de capacidad de arquitectura Movido a la Parte VII: Marco de capacidad de arquitectura

tectura

Movido a la Parte VII: Marco de capacidad de arquitectura Pasado a la Parte III: Directrices y técnicas de ADM Pasado a la Parte III: Directrices y técnicas de ADM Movido a la Parte VII: Marco de capacidad de arquitectura Elementos retenidos dentro de la Parte IV: Marco de Contenido de Arquitectura Elementos retenidos dentro de la Parte IV: Marco de Contenido de Arquitectura Elementos retenidos dentro de la Parte IV: Marco de Contenido de Arquitectura Pasado a la Parte III: Directrices y técnicas de ADM Remoto. Los estudios de caso estarán disponibles en el sitio web de The Open Group. Movido a la Parte I: Introducción Remoto. Este material estará disponible en el sitio web de The Open Group como un Libro Blanco. Trasladado a la Parte V: Enterprise Continuum & Tools Remoto. Este material estará disponible en el sitio web de The Open Group como un Libro Blanco.

tectura ectura

empresarial

o de la arquitectura

4.4 Mapeo de la estructura TOGAF 9 a TOGAF 8.1.1 La siguiente tabla ilustra dónde los capítulos de TOGAF 9 se asignan a los de TOGAF 8.1.1:

Capítulo de TOGAF 9

Derivación de TOGAF 8.1.1

ón

nto e desarrollo de la arquitectura.

a arquitectura a empresarial as de sistemas de información a de datos a de la aplicación a tecnológica des y Soluciones n de la migración za de la implementación l cambio de arquitectura os de arquitectura ADM es y técnicas de ADM

a través del paisaje arquitectónico. a diferentes niveles empresariales uridad y el ADM ra definir y gobernar SOAs ectura esados ctura ocios ciencias cación de la migración operabilidad eparación para la transformación del negocio

a en la capacidad contenido de arquitectura

ntenido ónicos uitectura

Material revisado; basado en el capitulo 1 Nuevo capitulo Material derivado del Capítulo 36, reelaborado en definiciones formales y secciones de abr Nuevo capitulo Material revisado; basado en el capitulo 3 Material revisado; basado en el capitulo 4 Material revisado; basado en el capitulo 5 Material revisado; basado en el capitulo 6 Material revisado; basado en el capitulo 7 Material revisado; basado en el capitulo 8 Material revisado; basado en el capitulo 9 Material revisado; basado en el capitulo 10 Material revisado; basado en el capitulo 11 Material revisado; basado en el capitulo 12 Material revisado; basado en el capitulo 13 Material revisado; basado en el capitulo 14 No hay cambio material; mapas al Capítulo 15 Nuevo capitulo Nuevo capitulo Nuevo capitulo Nuevo capitulo; derivado del Libro Blanco de Seguridad (W055) Nuevo capitulo No hay cambio material; mapas al Capítulo 29 Nuevo capitulo No hay cambio material; mapas al Capítulo 28 No hay cambio material; mapas al Capítulo 34 Nuevo capitulo; derivado del análisis de brechas Nuevo capitulo Nuevo capitulo Nuevo capitulo Nuevo capitulo Nuevo capitulo Nuevo capitulo Nuevo capitulo Derivado del Capítulo 31, más material nuevo. Revisado; fue el capitulo 16

cción e Continuum & Tools

itectura uitectura el desarrollo de la arquitectura de referencia TOGAF undación: cia Técnica .

Revisado del capitulo 32 Nuevo capitulo Derivado de los capítulos 17 y 18 con revisiones sustanciales. Nuevo capitulo Nuevo capitulo Derivado del Capítulo 38, con las pautas de evaluación eliminadas. No hay cambio material; mapas a los capítulos 19 y 20 No hay cambio material; mapas al Capítulo 22

ia de infraestructura de información integrada e capacidad de arquitectura

acidad de arquitectura ra mplimiento ectura arquitectura ez de arquitectura es de arquitectura ones suplementarias

Nuevo capitulo Nuevo capitulo Cambio mínimo; mapas al Capítulo 23 Cambio mínimo; mapas al Capítulo 24 Cambio mínimo; mapas al Capítulo 25 Cambio mínimo, mapas al Capítulo 26 Cambio mínimo; mapas al Capítulo 27 Algunos cambios cosméticos; mapas al Capítulo 30 Derivado del Capítulo 36 Derivado del Capítulo 36

4.5 Utilizando TOGAF 4.5.1 Condiciones de uso La documentación de TOGAF está disponible gratuitamente para verla en línea sin una licencia. Alternativamente, el conjunto completo de documentación de TOGAF se puede descargar y almacenar bajo licencia, como se explica en el sitio web de información de TOGAF. En cualquier caso, la documentación TOGAF puede ser utilizada libremente por cualquier organización que lo desee para desarrollar una arquitectura para su uso dentro de esa organización. Ninguna parte del mismo puede reproducirse, almacenarse en un sistema de recuperación, o transmitirse, de ninguna forma o por ningún medio, electrónico, mecánico, fotocopiado, grabación o cualquier otro, para cualquier otro propósito, incluyendo, pero no a modo de limitación, cualquier utilizar para fines comerciales, sin el permiso previo de los propietarios de derechos de autor.

4.5.2 ¿Cuánto cuesta TOGAF? Open Group funciona como un consorcio sin fines de lucro comprometido a brindar una mayor eficiencia comercial al reunir a compradores y proveedores de sistemas de información para reducir las barreras de integración de nuevas tecnologías en toda la empresa. Su objetivo es realizar la visión del flujo de información sin límites. TOGAF es una parte clave de su estrategia para lograr este objetivo, y The Open Group desea que TOGAF sea asumido y utilizado en proyectos de arquitectura práctica, y la experiencia de su uso se retroalimente para ayudar a mejorarlo. Por lo tanto, Open Group publica TOGAF en su servidor web público, y permite y fomenta su reproducción y uso gratuito por parte de cualquier organización que desee utilizarlo internamente para desarrollar una arquitectura empresarial. (Sin embargo, existen restricciones a su explotación comercial; consulte 4.5.1 Condiciones de uso ).

4.5.3 Descargas Las descargas de la documentación de TOGAF, incluido un archivo PDF imprimible, están disponibles bajo licencia del sitio web de información de TOGAF (consulte www.opengroup.org/architecture/togaf ). La licencia es gratuita para cualquier organización que desee utilizar TOGAF por completo con fines internos (por ejemplo, para desarrollar una arquitectura empresarial para su uso dentro de esa organización).

4.6 ¿Por qué unirse al grupo abierto? Las organizaciones que desean reducir el tiempo, el costo y el riesgo de implementar soluciones de múltiples proveedores que se integren dentro y entre las empresas necesitan a The Open Group como su socio clave. The Open Group reúne a los compradores y proveedores de sistemas de información de todo el mundo y les permite trabajar juntos, tanto para garantizar que las soluciones de TI satisfacen las necesidades de los clientes como para facilitar la integración de la TI en toda la empresa. TOGAF es un habilitador clave en esta tarea. Sí, TOGAF está disponible gratuitamente. Pero, ¿cuánto gastará en desarrollar o actualizar su arquitectura empresarial utilizando TOGAF? ¿Y cuánto gastará en compras basadas en esa arquitectura? El precio de la membresía de The Open Group es insignificante en comparación con estos montos. Además de los beneficios generales de la membresía, como miembro de The Open Group, será elegible para participar en el Open Group Architecture Forum, que es el programa de desarrollo en el que se desarrolla TOGAF y en el que los usuarios de TOGAF se reúnen para intercambiar información. y retroalimentación. Los miembros del Foro de Arquitectura ganan:  



Acceso inmediato a los frutos del programa de trabajo actual de TOGAF (no disponible públicamente hasta la publicación de la próxima edición del documento de TOGAF): en efecto, la información más reciente sobre TOGAF 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 arquitectos que utilizan TOGAF en importantes proyectos de desarrollo de arquitectura en todo el mundo. Revisión por pares de material de estudio de caso de arquitectura específica