1. Parte I: Introducción
1.1. Introducción
1.1.1. Qué es TOGAF
1.1.1.1. Un framework de arquitectura
1.1.1.2. Una herramienta para producción, uso y mantenimiento de arquitecturas empresariales
1.1.1.3. Basado en un proceso iterativo
1.1.1.4. Soportado por mejores prácticas y por un conjunto de activos reusables
1.1.1.5. Desarrollado por The Open Group Forum en 1995
1.1.1.6. Basado en TAFIM (Technical Architecture Framework for Information Management)
1.1.1.7. Su core se centra en el método ADM (Architecture Development Method)
1.1.2. Estructura del Documento de TOGAF
1.1.2.1. Parte I: Introducción
1.1.2.1.1. Introducción a alto nivel de los conceptos claves de AE y en particular del enfoque de TOGAF. Contiene las definiciones de los términos que se usan a lo largo de la documentación
1.1.2.2. Parte II: Método de Desarrollo de la Arquitectura (ADM: Architecture Development Method)
1.1.2.2.1. Esta parte es el core de TOGAF. Allí se describe el método a través de un enfoque paso a paso para desarrollar una AE.
1.1.2.3. Parte III: Directrices (lineamientos) y Técnicas de ADM
1.1.2.3.1. Esta parte contiene un conjunto de directrices o lineamientos disponibles para aplicar en ADM.
1.1.2.4. Parte IV: Framework de Contenido de Arquitectura
1.1.2.4.1. Esta parte describe el framework de contenido, incluyendo un meta modelo estructurado para artefactos arquitectónicos, el uso y re-uso de los Architecture Building Blocks (ABBs), y una visión general de los entregables de arquitectura típicos.
1.1.2.5. Parte V: Enterprise Continiuum y Herramientas
1.1.2.5.1. Presenta la taxonomía apropiada y las herramientas para categorizar y almacenar las salidas o entregables de arquitectura en una empresa.
1.1.2.6. Parte VI: Modelos de Referencia
1.1.2.6.1. Provee dos modelos de referencia: TRM (TOGAF Technical Reference Model). III-RM (Integrated Information Infraestructure Reference Model).
1.1.2.7. Parte VII: Framework de Capacidades de Arquitectura
1.1.2.7.1. Presenta la organización, los procesos, las habilidades, los roles y las responsabilidades requeridas para establecer y operar la práctica de arquitectura en una empresa.
1.1.3. Definición de: Empresa
1.1.3.1. Un grupo de organizaciones que tienen un conjunto de metas comunes
1.1.3.2. En el contexto de AE puede ser usado para denotar: La empresa en su totalidad o un dominio específico dentro de la empresa
1.1.4. Definición de: Arquitectura
1.1.4.1. Según ISO/IEC 42010:2007
1.1.4.1.1. Organización fundamental de un sistema, compuesta por sus componentes, sus relaciones y su ambiente, así como los principios que gobiernan su diseño y evolución
1.1.4.2. Según TOGAF
1.1.4.2.1. Descripción formal de un sistema, o plan detallado del sistema a nivel de componentes que guían su implementación
1.1.4.2.2. Estructura de componentes, las relaciones entre ellos, y los principios y lineamientos que gobiernan su diseño y evolución en el tiempo
1.1.5. Definición de: AE
1.1.5.1. Organización lógica de los procesos de negocio y la infraestructura de tecnología que refleja los requerimientos de integración y la estandarización del modelo operativo de la organización
1.1.5.2. Diseño conceptual que define la estructura y la operación de una organización
1.1.5.3. Porqué se necesita la AE
1.1.5.3.1. Porque direcciona la necesidad de administrar efectivamente la información, entregando un contexto estratégico para la evolución de los sistemas de información en respuesta a las constantes necesidades cambiantes del negocio
1.1.5.4. Ventajas de una buena AE
1.1.5.4.1. Operación de TI más eficiente
1.1.5.4.2. Mejor retorno de la inversión
1.1.5.4.3. Adquisición más económica, más rápida y más simple
1.1.6. Definición de Framework de Arquitectura
1.1.6.1. Herramienta para desarrollar gran variedad de arquitecturas Describe un método para diseñar un sistema de información Muestra cómo los elementos de un sistema de información se adaptan o relacionan entre ellos Contiene un conjunto de herramientas y provee un vocabulario común
1.1.6.2. porqué necesito un framework de AE
1.1.6.2.1. Acelera y simplifica el desarrollo de arquitectura
1.1.6.2.2. Asegura la cobertura completa de la solución
1.1.6.2.3. Garantiza el crecimiento futuro ante las necesidades del negocio
1.1.7. TOGAF como Framework Apto de AE
1.1.8. Habilitadores Normativos para Adopción de una AE
1.1.8.1. The Clinger-Cohen Act
1.1.8.1.1. Obliga el uso de una AE formal para los procesos de todas las agencias federales
1.1.8.2. The Sarbanes-Oxley Act
1.1.8.2.1. Bajo esta ley, las compañías deben proveer declaraciones de control interno, incluyendo documentación y procedimientos de control relacionados con TI
1.1.8.3. EU Directives on the Award of Public Contracts
1.1.8.3.1. Los proveedores que se encuentran involucrados en contratos públicos, deben mostrar el uso de una AE formal
1.2. Conceptos Core
1.2.1. Tipos de Arquitectura de TOGAF
1.2.1.1. Arquitectura de Negocio
1.2.1.2. Arquitectura de Datos
1.2.1.3. Arquitectura de Aplicaciones
1.2.1.4. Arquitectura Tecnológica
1.2.2. Método de Desarrollo de la Arquitectura - ADM
1.2.2.1. Describe el proceso que permite definir la AE de una organización.
1.2.2.2. Es el principal componente de TOGAF.
1.2.2.3. Provee directrices para los arquitectos.
1.2.2.4. Provee una serie de fases para el dllo de la arquitectura.
1.2.2.5. Provee una plantilla general para las actividades de dllo de la arquitectura.
1.2.2.6. Para cada fase se describen los objetivos, las entradas, los pasos, las salidas.
1.2.2.7. Define los entregables
1.2.3. Fases de ADM
1.2.3.1. Preliminar
1.2.3.1.1. Definición del framework
1.2.3.1.2. Definición de los principios de la Arquitectura
1.2.3.2. A. Visión
1.2.3.2.1. Definición del alcance
1.2.3.2.2. Identificar los interesados
1.2.3.2.3. Crear la visión de la Arquitectura
1.2.3.2.4. Obtener la aprobación
1.2.3.3. B. Arquitectura de Negocio
1.2.3.3.1. Desarrollo de una Arquitectura de Negocio que soporte la visión del negocio
1.2.3.4. C. Arquitectura de Sistemas de Información
1.2.3.4.1. Incluye arquitectura de datos y arquitectura de aplicaciones para un proyecto de Arquitectura
1.2.3.5. D. Arquitectura Tecnológica
1.2.3.5.1. Describe el desarrollo de la Arquitectura Técnica
1.2.3.6. E. Oportunidades y soluciones
1.2.3.6.1. Planear la implementación e identificar los medios de entrega de los productos de la Arquitectura definida en fases previas
1.2.3.7. F. Planeación de la migración
1.2.3.7.1. Definición de la transición de la Arquitectura (implementación y el plan de migración)
1.2.3.8. G. Gobierno de la implementación
1.2.3.8.1. Vigilancia de la Arquitectura en la implementación
1.2.3.9. H. Gestión del cambio de la Arquitectura
1.2.3.9.1. Establecer procedimientos para gestionar el cambio de la nueva Arquitectura
1.2.4. Entregables - Artefactos - Building Blocks
1.2.4.1. El Architecture content framework usa 3 categorías para describir los resultados de la arquitectura:
1.2.4.1.1. Entregable
1.2.4.1.2. Artefacto
1.2.4.1.3. Building Block
1.2.4.2. Relación entre entregables, artefactos y building blocks
1.2.5. Enterprise Continuum
1.2.5.1. Provee un modelo para estructurar un repositorio virtual
1.2.5.2. Provee métodos para clasificar la arquitectura y sus artefactos
1.2.5.3. Muestra la evolución de los artefactos y su re-uso
1.2.5.4. Es una vista del repositorio de arquitectura que muestra la evolución de la arquitectura
1.2.6. Repositorio de Arquitectura
1.2.6.1. Usado para almacenar diferentes clases de resultados arquitectónicos en diferentes niveles de abstracción y que son creados por ADM.
1.2.6.1.1. Metamodelo de Arquitectura
1.2.6.1.2. Ecosistema de la Arquitectura
1.2.6.1.3. Biblioteca de Referencia
1.2.6.1.4. Información base de estándares
1.2.6.1.5. Log de Gobierno
1.2.6.1.6. Capacidad de la Arquitectura
1.2.7. Establecimiento y mantenimiento de una capacidad de la Arquitectura Empresarial
1.2.7.1. TOGAF provee un modelo de capacidades de la Arquitectura que es un conjunto de material de referencia y guías para establecer una función de la Arquitectura o capacidad dentro de la Organización. Un resumen del contenido del modelo es el siguiente:
1.2.7.1.1. Establecer una capacidad de la Arquitectura
1.2.7.1.2. Comité de Arquitectura
1.2.7.1.3. Cumplimiento de la Arquitectura
1.2.7.1.4. Contratos de la Arquitectura
1.2.7.1.5. Gobierno de la Arquitectura
1.2.7.1.6. Modelo de Maduración de la Arquitectura
1.2.7.1.7. Modelo para las habilidades de la Arquitectura
1.2.7.2. Framework de Capacidad de Arquitectura
1.2.8. Establecimiento de una Capacidad de Arquitectura Operacional
1.2.8.1. La práctica de una AE debe ejecutarse como cualquier unidad operacional dentro de una empresa, es decir, como un negocio.
1.2.8.2. La práctica de una AE debe establecer capacidades en las siguientes áreas:
1.2.8.2.1. Administración Financiera
1.2.8.2.2. Administración del desempeño
1.2.8.2.3. Administración del servicio
1.2.8.2.4. Administración del Riesgo
1.2.8.2.5. Administración de Recursos
1.2.8.2.6. Comunicación y gestión de interesados
1.2.8.2.7. Administración de Calidad
1.2.8.2.8. Administración del abastecimiento
1.2.8.2.9. Administración de la configuración
1.2.8.3. Beneficios de un Gobierno de la Arquitectura
1.2.8.3.1. Asigna responsabilidades
1.2.8.3.2. Administración del control del riesgo
1.2.8.3.3. Proteger los activos existentes a través del mayor reuso de componentes
1.2.8.3.4. Proactividad en el control, monitoreo y mecanismos de administración
1.2.8.3.5. Creación de valor a través de la medición y retroalimentación
1.2.8.3.6. El proceso de toma de decisiones tiene visibilidad
1.2.8.3.7. Mayor valor para los interesados
1.2.9. Usando TOGAF con otros frameworks
1.2.9.1. TOGAF es un modelo que ofrece de forma general un conjunto de entregables y un método para producirlos. Sin embargo, estos entregables pueden ser reemplazados o extendidos por un modelo especifico definido por otro modelo que tenga relevancia para la organización.
1.2.9.2. Una de las ventajas de TOGAF es que puede ser usado en combinación con otros modelos de Arquitectura del mercado ya que ofrece un modelo agnóstico que se ajusta a cualquier modelo en uso, lo que permite que se puedan integrar los métodos de TOGAF con otros modelos como COBIT, ITIL, CMMI, PMBOK, etc
1.2.9.3. De igual forma, TOGAF complementa los otros modelos verticales y de industria.
1.3. Definiciones y Abreviaciones
2. Parte VI: Modelos de Referencia
3. Parte VII: Framework de Capacidad de Arquitectura
4. Parte II: ADM
4.1. Introducción a ADM
4.1.1. Qué es ADM
4.1.1.1. Es un método para obtener Arquitecturas Empresariales que son especificas para la organización
4.1.1.2. Está especialmente diseñado para responder a los requerimientos del negocio
4.1.1.3. Describe un modo confiable y probado para desarrollar y utilizar una Arquitectura Empresarial
4.1.1.4. Describe un método para desarrollar arquitecturas de diferentes niveles (negocio, aplicaciones, datos y tecnología) que permiten al arquitecto asegurar que un conjunto complejo de requerimientos sean abordados adecuadamente
4.1.2. Fases de ADM
4.1.3. Control de Versiones para Documentos
4.1.3.1. El control de versiones de salida se gestiona a través de la versión en números
4.1.3.2. Una versión o convención de numeración se utiliza dentro ADM para ilustrar la evolución de definiciones de Arquitectura de referencia y de destino
4.1.4. Niveles de Iteraciones
4.1.4.1. Ciclos alrededor de ADM: ADM se presenta en manera circular indicando que la finalización de una fase de trabajo de arquitectura alimenta directamente las fases subsecuentes en la arquitectura.
4.1.4.2. Iteración entre fases: TOGAF describe el concepto de iteración a través de las fases (por ejemplo, volviendo a la Arquitectura de Negocio posteriormente a la finalización de la Arquitectura tecnológica)
4.1.4.3. Ciclo alrededor de una fase individual: TOGAF apoya la ejecución repetida de las actividades dentro de una fase individual de ADM como una técnica para elaborar contenido arquitectónico
4.1.5. Relación con el Enterprise Continuum y el repositorio de arquitectura
4.1.5.1. En la ejecución de ADM repetidamente en el tiempo, el arquitecto gradualmente adiciona más y más contenido al repositorio Arquitectura de la organización
4.1.5.2. El enterprise continuum provee un framework y un contexto para soportar el apalacamiento de activos relevantes en la ejecución de ADM
4.1.6. ADM y el Foundation Architecture
4.1.6.1. ADM es util para poblar el foundation architecture de una empresa
4.1.6.2. Los requerimientos de negocio de una empresa pueden ser usados para identificar las definiciones y selecciones necesarias en el foundation architecture
4.1.7. Adaptando ADM
4.1.7.1. Pueden haber razones para adaptar a ADM a las necesidades de la empresa:
4.1.7.1.1. Una consideración importante es que el orden de las fases de ADM, hasta cierto punto depende de la madurez de la disciplina de la arquitectura empresarial dentro del que se trate
4.1.7.1.2. El orden de las fases puede ser definido también por los principios de negocio y la arquitectura de una empresa
4.1.7.1.3. Una empresa puede desear usar o adaptar ADM en conjunción con otro marco de arquitectura empresarial que cuenta con un conjunto definido de prestaciones específicas de un sector en particular vertical: Gobierno, Defensa, e-Business, Telecomunicaciones, etc.
4.1.7.1.4. El ADM es uno de los muchos procesos corporativos que componen el modelo de gobierno corporativo de la empresa. El ADM es complementario y de apoyo, otros procesos estándar de gestión de programas
4.1.7.1.5. ADM está siendo obligatorio para su uso por el contratista principal en una situación de outsourcing, y debe adaptarse para lograr un compromiso adecuado entre las prácticas existentes del contratista y las necesidades de la empresa contratante.
4.1.7.1.6. La empresa es una pequeña y/o mediana empresa, y desea utilizar el "cut-down" versión del ADM que está más en sintonía con el nivel reducido de los recursos y la complejidad del sistema típico de este entorno
4.1.7.1.7. La empresa es muy grande y compleja, Compuesta por muchas “empresas” independientes, aunque interrelacionadas dentro de un marco general de colaboración empresarial, la arquitectura y el método debe adaptarse a reconocer esto.
4.1.8. Alcance de una Arquitectura
4.1.8.1. Hay cuatro dimensiones que son usadas para definir y limitar el alcance de una arquitectura:
4.1.8.1.1. Amplitud
4.1.8.1.2. Nivel de Detalle o Alcance Vertical
4.1.8.1.3. Periodo de tiempo
4.1.8.1.4. Dominios de la arquitectura
4.2. Fase Preliminar
4.2.1. Objetivos
4.2.1.1. Determinar la Capacidad de Arquitectura deseada por la organización
4.2.1.1.1. Examinar el contexto organizacional para llevar a cabo la AE
4.2.1.1.2. Identificar y determinar el alcance de los elementos en las organizaciones empresariales que serán afectados por la Capacidad Arquitectónica
4.2.1.1.3. Identificar los marcos de referencia establecidos, los métodos y los procesos que se entrecruzan con la Capacidad Arquitectónica
4.2.1.1.4. Establecer el objetivo de Madurez de las Capacidades
4.2.1.2. Establecer las Capacidades Arquitectónicas
4.2.1.2.1. Definir y establecer el Modelo Organizacional para la AE
4.2.1.2.2. Definir y establecer el proceso detallado y los recursos para el Gobierno de la Arquitectura
4.2.1.2.3. Seleccionar e implementar herramientas que apoyan la capacidad de arquitectura
4.2.1.2.4. Definir los Principios de Arquitectura
4.2.2. Enfoque
4.2.3. Entradas
4.2.3.1. Material Externo para la Empresa
4.2.3.1.1. TOGAF
4.2.3.1.2. Otros frameworks de arquitectura si son requeridos
4.2.3.2. No arquitectónicas
4.2.3.2.1. Estrategias del consejo organizacional, planes de negocio; estrategia de negocio; estrategia de TI; principios de negocio, objetivos de negocio y motivaciones de negocio
4.2.3.2.2. Los principales frameworks que operan en el negocio
4.2.3.2.3. Marcos de Referencia de gobierno y legales
4.2.3.2.4. Capacidades Arquitectónicas
4.2.3.2.5. Acuerdos de asociación y contratos
4.2.3.3. Arquitectónicas
4.2.3.3.1. Modelo organizacional de Arquitectura Empresarial existente.
4.2.3.3.2. Marco de Referencia de Arquitectura existente, si lo hay, incluyendo: • Método de arquitectura • Contenidos de arquitectura • Herramientas configuradas e implementadas • Principios de Arquitectura • Repositorio de Arquitectura
4.2.4. Pasos
4.2.4.1. Determinar las organizaciones de la empresa que serán impactadas.
4.2.4.2. Confi rmar los Marcos de Referencia de Gobierno y de soporte adicional
4.2.4.3. Definir y establecer el equipo de AE y su organización
4.2.4.4. Identificar y establecer los Principios de Arquitectura
4.2.4.5. Adaptar TOGAF y, si es necesario, otros Marcos de Referencia de Arquitectura seleccionados
4.2.4.6. Implementar herramientas de arquitectura
4.2.5. Salidas
4.2.5.1. Modelo Organizacional para la AE
4.2.5.2. Marco de Referencia de Arquitectura adaptado incluyendo los principios de arquitectura
4.2.5.3. Repositorio de Arquitectura inicial
4.2.5.4. Reafirmación o referencia de los principios de negocio, objetivos de negocio y motivaciones de negocio
4.2.5.5. Solicitud para el Trabajo de Arquitectura
4.2.5.6. Marco de referencia de gobierno de arquitectura
4.3. Fase A: Visión de la Arquitectura
4.4. Fase B: Arquitectura de Negocio
4.5. Fase C: Arquitecturas de Sistemas de Información
4.6. Fase D: Arquitectura Tecnológica
4.7. Fase E: Oportunidades y Soluciones
4.8. Fase f: Planeación de la Migración
4.9. Fase G: Gobierno de Implementación
4.10. Fase H: Gestión de Cambios de la Arquitectura
5. Parte III: Lineamientos y Técnicas
5.1. Lineamientos
5.1.1. Documentan como adaptar el proceso ADM
5.1.2. Lineamientos Incluidos en TOGAF
5.1.2.1. Aplicación de Iteraciones en ADM
5.1.2.2. Aplicación de ADM en diferentes niveles de la Empresa
5.1.2.3. Consideraciones de Seguridad durante diferentes fases de ADM
5.1.2.4. Uso de TOGAF para definir y gobernar SOAs
5.2. Técnicas
5.2.1. Soportan tareas específicas dentro de ADM
5.2.2. Dentro de las Técnicas se tienen:
5.2.2.1. Principios de Arquitectura
5.2.2.1.1. Definición
5.2.2.1.2. 3 Niveles
5.2.2.2. Gestión de los Interesados
5.2.2.3. Patrones de Arquitectura
5.2.2.4. Escenarios de Negocio
5.2.2.5. Análisis de Brechas
5.2.2.6. Planeación de Migración
5.2.2.7. Requerimientos de Interoperabilidad
5.2.2.8. Valoración de Preparación de la Transformación del Negocio
5.2.2.9. Gestión de Riesgo
5.2.2.10. Planeación Basada en Capacidades