4.

Estructura de la Documentación de TOGAF

¿Qué contiene TOGAF?
Para cumplir de forma más efectiva y eficiente con los objetivos del negocio, TOGAF nos propone un proceso continuo
de evolución y mejora de la arquitectura de empresa.

Este proceso está documentado en 7 libros que describen las estructuras lógicas en las que se basa el marco de trabajo.

4.1 Parte I: Introducción o Preliminar

Objetivos:

• Prepara a una organización para emprender proyectos de Arquitectura Empresarial de manera exitosa.

• Determinar las Capacidades Arquitectónicas deseadas por la organización:

• Examinar el contexto organizacional para llevar a cabo Arquitectura Empresarial

• Identificar y determinar el alcance de los elementos en las organizaciones de la empresa que serán afectadas por
la Capacidad Arquitectónica

• Identificar los marcos de referencia establecidos, los métodos y los procesos que se entrecruzan con la Capacidad
Arquitectónica.
4.2 Parte II: Método de desarrollo de la arquitectura (ADM por sus siglas en inglés)
El ADM es el resultado de las contribuciones de numerosos profesionales de la arquitectura y constituye el núcleo de
TOGAF. Es un método para obtener Arquitecturas Empresariales que son específicas para la organización, y está
especialmente diseñado para responder a los requerimientos del negocio.

El ADM describe:

• Un modo confiable y probado para desarrollar y utilizar una Arquitectura Empresarial

• Un método para desarrollar arquitecturas en diferentes niveles (negocio, datos, aplicaciones, tecnología) que
permiten al arquitecto asegurar que un conjunto complejo de requerimientos se aborde adecuadamente

• Un conjunto de guías y técnicas para el desarrollo de arquitectura

Las fases descritas en el ADM son las siguientes:

TOGAF – Fase A Visión de la Arquitectura

La Fase A aborda el establecimiento del proyecto e inicia una iteración del ciclo de desarrollo de la arquitectura,
estableciendo el alcance, limitaciones y expectativas de la iteración. Se ejecuta con el objetivo de validar el contexto del
negocio y producir una Declaración de Trabajo de Arquitectura aprobada.

Objetivos:

• Desarrollar una visión de alto nivel de las Capacidades y valor de negocio que se desean obtener como resultado
de la Arquitectura Empresarial propuesta.
 • Obtener la aprobación de la Declaración del Trabajo de Arquitectura que define un programa de trabajo para
desarrollar e implementar la arquitectura descrita en la Visión de la Arquitectura.

• Definir las propuestas de valor de la Arquitectura de Destino e Indicadores Clave de Desempeño (KPI – Key
Performance Indicators, en inglés)

• Identificar los riesgos de la transformación del negocio y las actividades de mitigación

• Desarrollar la Declaración de Trabajo de Arquitectura; asegurar su aprobación.

TOGAF – Fase B Arquitectura del negocio

La Fase B aborda el desarrollo de una Arquitectura de Negocio que apoye la Visión de la Arquitectura acordada.

Objetivos:

• Desarrollar la Arquitectura de Negocio de Destino describiendo cómo la empresa tiene que operar para alcanzar
los objetivos de negocio, responder a las motivaciones estratégicas definidas en la Visión de la Arquitectura y
responder a la Petición de Trabajo de Arquitectura y las preocupaciones de los interesados

• Identificar componentes candidatos para el Plan de Itinerario de Arquitectura basándose en las brechas
identificadas entre la Arquitectura de Negocio de la Línea de Base y la Arquitectura de Negocio de Destino.

TOGAF – Fase C Arquitecturas de sistemas de información

La Fase C aborda la documentación de la organización fundamental de los sistemas de TI de una empresa, representada
por los principales tipos de sistemas de información y aplicaciones que los utilizan. En esta Fase hay dos pasos que se
pueden desarrollar secuencialmente o simultáneamente:
 • Arquitectura de Datos

• Arquitectura de Aplicación

Arquitectura de Datos:

Objetivos:

• Desarrollar una Arquitectura de Datos de Destino que sea funcional a la Arquitectura de Negocio y a la Visión de
Arquitectura, y que responda a la vez a la Petición de Trabajo de Arquitectura y a las preocupaciones de los
interesados

• Identificar los componentes candidatos que podrían conformar el Plan de Itinerario de Arquitectura basándose en
las brechas identificadas entre la Arquitectura de Datos de la Línea de Base y la Arquitectura de Datos de Destino.

TOGAF – Fase D Arquitectura Tecnológica

La Fase D aborda la documentación de la organización esencial de sistemas de TI, representada en hardware, software
y tecnología de comunicaciones.

Objetivos:

• Desarrollar la Arquitectura Tecnológica de Destino de tal manera que permita que los componentes lógicos y
físicos de datos y aplicaciones, así como aquellos de la Visión de la Arquitectura, correspondan a la Petición de
Trabajo de Arquitectura y respondan a las preocupaciones de los interesados
 • Identificar los componentes candidatos del Plan de Itinerario de Arquitectura basándose en las brechas
identificadas entre la Arquitectura Tecnológica de la Línea de Base y la Arquitectura Tecnológica de Destino.

TOGAF – Fase E Oportunidades y Soluciones

La Fase E es la primera Fase que directamente se refiere a la implementación. Describe el proceso de identificación de
los medios de entrega (proyectos, programas o carteras) que proporcionan la Arquitectura de Destino identificada en las
Fases anteriores.

Objetivos:

• Generar la versión inicial y completa del Plan de Itinerario de Arquitectura, basándose en el Análisis de Brechas
y en los componentes candidatos del Plan de Itinerario de Arquitectura resultantes de las Fases B, C y D

• Determinar si un enfoque incremental es requerido, y si fuera así, identificar las Arquitecturas de Transición que
proporcionarán valor continuo de negocio.

TOGAF – Fase F Planificación de la Migración

La Fase F aborda la planificación de la migración; es decir, cómo moverse desde la Arquitectura de la Línea de Base a
la Arquitectura de Destino finalizando un Plan de Implementación y Migración en detalle.

Objetivos:

• Finalizar el Plan de Itinerario de Arquitectura y el Plan de Implementación y Migración que lo apoya.

• Asegurar que el Plan de Implementación y Migración se alinee al enfoque de la empresa para la gestión e
implementación de cambios en la cartera general de cambios empresariales.
 • Asegurar que el valor de negocio y los costos de los paquetes de trabajo y Arquitecturas de Transición sean bien
entendidos por los interesados.

TOGAF – Fase G Gobierno de la Implementación

La Fase G define cómo la arquitectura delimita los proyectos de implementación, la supervisa al mismo tiempo que se la
construye, y produce un Contrato de Arquitectura firmado.

Objetivos:

• Asegurar la conformidad con la Arquitectura de Destino a través de los proyectos de implementación.

• Realizar las funciones de Gobierno de Arquitectura apropiadas para la solución y para toda Solicitud de Cambio
de la Arquitectura impulsada por la implementación

TOGAF – Fase H Gestión de Cambios de la Arquitectura

La Fase H asegura que los cambios en la arquitectura se gestionen de una manera controlada

Objetivos:

• Asegurar que el ciclo de vida de la arquitectura se mantenga

• Asegurar la ejecución del Marco de Referencia de Gobierno de Arquitectura Asegurar que la Capacidad
Arquitectónica Empresarial cumplen con los requerimientos actuales
4.3 Parte III: Directrices y técnicas para la aplicación de TOGAF y ADM

Provee una colección de Guías y Técnicas para aplicar durante las fases ADM TOGAF.

Son las guías y técnicas que soportan la aplicación de ADM. Esta guía se puede adaptar a diferentes escenarios, por
estilo de proceso (p.e. iterativo) o para una arquitectura especifica (p.e. seguridad). Las técnicas soportan tareas
específicas dentro de ADM tales como:

Principios de arquitectura:

Los principios de Arquitectura definen las normas y directrices generales para el uso y el despliegue de todos los servicios
y activos de TI en toda la organización. Permite ocupar los diversos elementos de la empresa para la toma de decisiones
de TI. Cada principio debe estar relacionado e integrado a los objetivos del negocio.

Los principios de Arquitectura se desarrollan normalmente por los arquitectos organizacionales, en conjunto con partes
interesadas (stakeholders), y son aprobados en las juntas de Arquitectura.

Los principios de Arquitectura deben estar claramente trazados y articulados para guiar la toma de decisiones. Cada
principio de la Arquitectura debe estar relacionado e integrado a los objetivos del negocio.

http://ecorfan.org/handbooks/Ciencias-TI-T_I/IBERO-Handbook_MR_1-43-52.pdf

Gestión de los interesados:

La gestión de los grupos de interés es el eje central de cualquier estrategia de Responsabilidad social Empresarial (RSE),
Aunque tradicionalmente estas relaciones se han enfrentado desde la gestión del riesgo, donde primaba la comunicación
unidireccional frente al dialogo, las organizaciones están comprobando las ventajas de alinear su estrategia con las
expectativas de la sociedad.
Así, cada vez son más las empresas que entienden esta apertura al diálogo como una oportunidad de innovación ya no
sólo para anticipar riesgos sino también para generar nuevos productos y servicios o adaptarlos contribuyendo así a una
respuesta rápida y bien enfocada a las necesidades de los consumidores y por tanto más competitiva.
http://www.minetad.gob.es/Publicaciones/Publicacionesperiodicas/EconomiaIndustrial/RevistaEconomiaIndustrial/381/Germ%C3%A1n%20Granda%20Revilla.pdf

Escenarios de negocio:

Escenarios de negocios son una técnica apropiada y útil para descubrir y documentar los requerimientos del negocio, y
para articular una visión arquitectura que responda a esas necesidades. Escenarios de negocios también puede ser
usado a niveles más detallados de la arquitectura de trabajo (por ejemplo, en la Fase B. Este paso genera la primera
definición, de muy alto nivel, de los entornos de línea de base y el objetivo, a partir de un negocio, sistemas de información
y punto de vista tecnológico, como se describe en las Salidas.
http://www.ucipfg.com/Repositorio/MATI/MATI-04/BLOQUE-ACADEMICO/Unidad-2/lecturas/Resumen-1-Fase-A.pdf

Bloques de construcción:

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.

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.
 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.
https://es.scribd.com/doc/220173478/Togaf-91ES

Análisis de brechas:

El análisis de brechas es una herramienta de análisis para comparar el estado y desempeño real de una organización,
estado o situación en un momento dado, respecto a uno o más puntos de referencia seleccionados de orden local,
regional, nacional y/o internacional.
https://calidadgestion.wordpress.com/tag/analisis-de-brechas/

Gestión de riesgos:

La Gestión de Riesgos es el proceso de identificar, analizar y responder a factores de riesgo a lo largo de la vida de un
proyecto y en beneficio de sus objetivos. La gestión de riesgos adecuada implica el control de posibles eventos futuros.
Además, es proactiva, en lugar de reactiva.
https://gerens.pe/blog/gestion-riesgo-que-por-que-como/
4.4 Parte IV: Marco de referencia del contenido arquitectónico

Provee el modelo y un resumen de los productos típicos del trabajo arquitectónico, incluyendo entregables, artefactos y
Bloques de Construcción Arquitectónicos.

Algunos elementos por considerar son:

Categorías de productos del trabajo arquitectónico:

El Marco de referencia del Contenido Arquitectónico usa las tres Categorías siguientes:

Un Entregable es un producto de trabajo formal que se especifica contractualmente, y que normalmente se examinará,
se acordará y se firmará pos sus interesados. Los entregables a menudo representan el resultado de proyectos.

Un Artefacto es un producto de trabajo Arquitectónico que describe un aspecto de la arquitectura. Los Artefactos
generalmente se clasifican en catálogos (listas de elementos), matrices (mostrando las relaciones entre elementos), y
diagramas (imágenes de los elementos). Ejemplos de Artefactos son un catálogo de requerimientos, una matriz de
interacciones de negocio y un diagrama de caso 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 negocio, TI o capacidad

arquitectónica que se puede combinar con otros bloques de Construcción para entregar arquitecturas y soluciones.
https://books.google.com.mx/books?id=6elEBAAAQBAJ&pg=PA126&lpg=PA126&dq=productos+del+trabajo+arquitect%C3%B3nico&source=bl&ots=hY9f_Iqxn0&sig=EedieI76KTeAuXsrSuY_NaB_yzQ&hl
=es&sa=X&ved=0ahUKEwiZitSs88faAhUPzFMKHYE7DJIQ6AEISTAD#v=onepage&q=productos%20del%20trabajo%20arquitect%C3%B3nico&f=false
Meta modelo del contenido:

El meta modelo proporciona metodología y directrices para establecer una buena AE. Posee diferentes capas para su
mayor y mejor aplicación en las organizaciones. A continuación, se mencionarán algunas:

• Arquitectura de principios (preliminar, visión)

• Arquitectura de requerimientos

• Arquitectura del negocio (procesos del negocio, sistemas administración, organización)

• Arquitectura de aplicaciones (servicios)

• Arquitectura de datos (datos e información)

• Arquitectura tecnológica (hw, sw, redes)

https://chae201411700810326.wordpress.com/2014/07/11/meta-modelo-togaf/

Entidades del meta modelo:

• Actor: Una persona, organización o un sistema que tiene el rol que inicia o interactúa con las actividades.

• Componente de aplicación: Encapsulación de la aplicación de la funcionalidad alineada con las

implementación de la estructura.

• Supuestos: Datos que no están dictaminados pero luego se tienen en cuenta.

• Control: Nos garantiza que nosotros hagamos un adecuado cierre del alcance de una meta, Orientado a
procesos, nos garantiza el rumbo.

• Entidad de datos: Impulsa a que la organización logre sus objetivos.

• Driver: Condición externa o interna.

• Evento: Son cosas disparados por alguna circunstancia.

• Función: En un término genérico que se puede trabajar a nivel organizacional o a nivel más detallado.

• Brecha: Salto a superar, baches que se presentan.

• Metas: Garantiza si la organización está cumpliendo con los objetivos, se trata de cruzar el quehacer de la
organización con las metas propias a lograr.

• Servicio de sistemas de información: Automatización de los servicios del negocio a través de mecanismos de
Sistemas de información.

• Locación: Criticas para entender y diseñar las arquitecturas organizacionales, hay que ser coherente desde l
punto de vista de un esquema de ubicaciones, para alinear la arquitectura de sistemas.

• Componentes de aplicación lógica: Son concepciones meramente vistas desde la parte de aplicaciones.

• Componentes de datos lógicos: Son concepciones meramente vistas desde la parte de datos.

• Métricas: Son indicadores, nos sirven para hacerle seguimiento a lo que se hace en la organización.

• Objetivos: Es una meta, tiene delimitadores de tiempo.

• Unidad Organizacional: Unidad auto contenida de recursos con metas, objetivos y métricas. Podemos
establecer una cantidad de resultados específicos de los objetivos organizacionales.

• Componentes de aplicaciones físicas: Son concepciones meramente vistas desde la parte física, visto desde
el componente de la funcionalidad.
 • Plataforma de servicio: Capacidad técnica que requiere proveer disponibilidad en las infraestructura que ayuda
con las aplicaciones.

• Principios: Sentencia cualitativa que busca logros particulares en la arquitectura u organización como tal.

• Procesos: En un flujo de actividades que se realizan dentro de la organización. Los procesos se ven como algo
dinámico.

• Producto: Es el resultado de un proceso, función, etc.

• Requerimientos: Sentencia cuantitativa del negocio que necesita ser una forma particular en la arquitectura.

• Rol: Función que cumple un actor, puede cumplir una o más funciones. Lo que hace que un actor se comporte
es el rol que cumple en la organización como tal.

• Servicio: Elemento que provee una funcionalidad especifica que responde a los requerimientos de los actores.

• Calidad de servicio: Componentes no funcionales que se le asignan a los servicios.

• Componente tecnológico: Encapsulación de la infraestructura tecnológica utilizada en la organización.

• Paquete de trabajo: Es un conjunto de acciones a realizar por el paquete de trabajo.

https://chae201411700811025.wordpress.com/2014/06/19/entidades-contenidas-en-el-metamodelo/
4.5 Parte V: Continuum de la Empresa

Provee un modelo para estructurar un repositorio virtual. Provee métodos para la clasificar los artefactos de la solución
y de la arquitectura, mostrando como los diferentes artefactos se relacionan y como pueden ser reusados. Se basa en
los modelos y arquitecturas existentes (patrones, modelos, descripciones arquitectónicas, etc.) dentro de la empresa o
en la industria, las cuales se pueden almacenar para el desarrollo de la arquitectura.

El Continuum Empresarial puede ser interpretado como un "repositorio virtual" de todos los artefactos arquitectónicos
disponibles en una organización. Incluye modelos arquitectónicos, patrones de arquitectura, descripciones
arquitectónicas, entre otros. Estos artefactos pueden existir específicamente al interior de la empresa, o en general en
la industria de Tecnologías de Información.

El Continuum Empresarial consiste tanto del Continuum Arquitectónico como del Continuum de Soluciones.

Continuum Arquitectónico:

El Continuum Empresarial puede ser interpretado como un “repositorio virtual” de todos los artefactos arquitectónicos
disponibles en una organización. Incluye modelos arquitectónicos, patrones de arquitectura, descripciones
arquitectónicas, entre otros. Estos artefactos pueden existir específicamente al interior de la empresa, o en general en
la industria de Tecnologías de Información.

Continuum de Soluciones:

El Continuum Empresarial consiste tanto del Continuum Arquitectónico como del Continuum de Soluciones. Continuum
Arquitectónico especifica la estructura de los artefactos arquitectónicos reutilizables, incluyendo reglas, representaciones
y relaciones de los sistemas de información disponibles en la organización. Continuum de Soluciones describe la
implementación del Continuum Arquitectónico mediante la definición de bloques constitutivos de solución (solution
building blocks, en inglés).
https://chae20141700821717.wordpress.com/2014/07/13/continuum-empresarial/
4.6 Parte VI. Modelos de Referencia TOGAF

Presenta una serie de Modelos de Referencia como son:

• El Modelo de referencia técnica (TRM).

• El Modelo de referencia para la infraestructura de información integrada (III-RM).

• Evaluación de los modelos de referencia TOGAF en su organización.

Modelo de Referencia Técnica:

El Modelo de referencia técnica (TRM) de FEA proporciona una base para describir los estándares, especificaciones y
tecnologías que dan soporte a la entrega, intercambio y construcción seguros de componentes de negocio (o servicio) y
soluciones e-Gov. El TRM de FEA unifica los TRM de agencias existentes y la guía de Gobierno electrónico (e-Gov)
proporcionando una base para avanzar la reutilización de tecnología y servicios de componentes desde una perspectiva
gubernamental.
https://www.ibm.com/support/knowledgecenter/es/SS6RBX_11.4.3/com.ibm.sa.irma.doc/topics/c_Under_Tech_Ref_Mdl_TRM.html

Modelo de Referencia para la Infraestructura de Información Integrada:

La IIIRM:

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 uno de los claves desafíos que enfrenta el arquitecto de la empresa hoy en día: la necesidad
de diseñar una infraestructura de información integrada para permitir el flujo de información sin fronteras.

El Modelo de Referencia Técnica TOGAF (TRM) se describe en la Fundación Arquitectura: Modelo de referencia técnica
se centra en el espacio de la plataforma de aplicaciones, y es lo que los términos de Enterprise Continuum una
"arquitectura de la Fundación".

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.- Una gráfica asociada III-RM, lo que proporciona una representación visual de la taxonomía y la interrelación
de los componentes, como una ayuda para la comprensión.
https://prezi.com/yctmkkzvm_k2/iiirm-y-adm/

4.7 Parte VII. Marco de referencia de la capacidad arquitectónica

Aborda en detalle los procesos, las habilidades, roles y responsabilidades requeridas para establecer y operar la práctica
de arquitectura en una organización.

Es el conjunto de recursos, guías, plantillas, antecedentes, etc., que son provistos para ayudar al arquitecto a establecer
una práctica arquitectónica dentro de una organización.