Universidad Venezolana de los Hidrocarburos

Maestría en Gestión de Datos en

Exploración y Producción de Hidrocarburos

ARQUITECTURA EMPRESARIAL

Integrantes:

Mendoza, José.

Marín, Marifrancis.

Zambrano, Jorge.

San Tomé, Octubre de 2018

CONTENIDO

1. Fase preliminar

2. Fase A: Visión y soporte de la implementación

3. Fase B: Arquitectura de negocio

4. Fase C: Arquitectura de sistemas de información (datos y aplicaciones)

5. Fase D: Arquitectura tecnológica

6. Preguntas tipo de examen de certificación

7. Descripción de Proyectos.
MARCO TEORICO

1. Fase Preliminar.

La fase preliminar de la arquitectura empresarial prepara a una organización para

emprender proyectos de esta índole de manera exitosa.

Esta fase describe las actividades de preparación e iniciación necesarias para crear una
capacidad de arquitectura creando la capacidad de arquitectura y definiendo los
principales elementos relacionados con metodología, personas, herramientas, etc.
Pasos de la fase preliminar.

1. Alcance de la
organización empresarial
afectada

2. Confirmar la
6. Implementar gobernanza y los marcos
herramientas de de apoyo
arquitectura

3. Definir y establecer
5. Adapte TOGAF y, en su equipo y organización de
caso, otros marcos de arquitectura empresarial.
arquitectura seleccionados

4. Identificar y establecer
principios de arquitectura

Para determinar las capacidades arquitectónicas deseadas por la Organización se debe

emplear como información de entrada revisión los siguientes aspectos:

- Examinar el contexto organizacional para llevar acabo AE.

- Identificar y determinar el alcance de los elementos en la organización de empresa
que será afectadas por la capacidad arquitectónica
- Identificar los marcos referenciales establecidos, los métodos y los procesos que
se entrecruzan con la capacidad arquitectónica.
Capacidades críticas para mantener conectados el negocio y la TI

El Marco de Capacidad de Arquitectura: una definición estructurada de las estructuras,

procesos, roles, responsabilidades y habilidades de la organización para realizar la
capacidad de arquitectura.

Una manera de representar la capacidad de arquitectura de una organización es la

siguiente:

Arquitectura de gobierno - procesos

Tableros de Arquitectura

• Esta junta debe ser representativa de todas las partes interesadas clave en la
arquitectura, y típicamente comprenderá un grupo de ejecutivos responsables de la
revisión y el mantenimiento de la arquitectura general
• Los tableros de arquitectura generalmente incluyen representantes de la
organización en un mínimo de dos niveles: local (expertos de dominio,
responsabilidad de línea) y global (responsabilidad de toda la organización)
• El tamaño recomendado para una Junta de Arquitectura es de cuatro o cinco (y no
más de diez) miembros permanentes.
• La membresía de la Junta de Arquitectura puede ser rotada Responsable y
responsable de proporcionar la base para toda toma de decisiones con respecto a
las arquitecturas

Contratos de Arquitectura

• Los contratos de arquitectura son los acuerdos conjuntos entre socios de

desarrollo y patrocinadores sobre los entregables, la calidad y la aptitud para el
propósito de una arquitectura.
• Un enfoque controlado de la gestión de contratos garantiza un sistema de
monitoreo continuo para verificar la integridad, los cambios, la toma de decisiones
 y la auditoría de todas las actividades relacionadas con la arquitectura dentro de
la organización.
• Contenido típico de: (1) contrato entre el diseño de la arquitectura y los socios de
desarrollo, (2) contrato entre la función de arquitectura y los usuarios comerciales

Establecer una capacidad de arquitectura

• Como con cualquier capacidad de negocios, el establecimiento de una capacidad

de arquitectura empresarial puede ser soportado por el ADM
• La aplicación del ADM con la Visión de Arquitectura específica para establecer
una práctica de arquitectura dentro de la organización lograría este objetivo

Salidas de la Fase Preliminar

Modelo organizativo para la arquitectura empresarial (alcance de las organizaciones

impactadas, evaluación de madurez, brechas y enfoque de resolución, roles y
responsabilidades para el (los) equipo (s) de arquitectura, restricciones en el trabajo de
arquitectura, requisitos de presupuesto, gobierno y estrategia de apoyo)

Marco de arquitectura a medida (método de arquitectura a medida, contenido de

arquitectura a medida (entregables y artefactos), principios de arquitectura, herramientas
configuradas y desplegadas.

Repositorio inicial de arquitectura

Actualización o referencia a los principios comerciales, los objetivos comerciales y los

impulsores comerciales.

Marco de gobierno de la arquitectura:

Gobierno

Capacidad: una habilidad que posee una organización.

Capacidad de arquitectura: capacidad de gestionar y controlar arquitecturas.
El gobierno de la arquitectura es la práctica y la orientación mediante la cual se gestionan
y controlan las arquitecturas empresariales y otras arquitecturas.
El Marco de Capacidad de Arquitectura: una definición estructurada de las estructuras,
procesos, roles, responsabilidades y habilidades de la organización para realizar la
capacidad de arquitectura
Características del Gobierno.

Disciplina: todas las partes involucradas tendrán el compromiso de cumplir con los
procedimientos, procesos y estructuras de autoridad establecidos.

Transparencia: todas las acciones implementadas y su apoyo a las decisiones estarán

disponibles para inspección

Independencia: todos los procesos, la toma de decisiones y el mecanismo utilizado se

establecerán para minimizar o evitar posibles conflictos de intereses.

Responsabilidad: los grupos identificables dentro de la organización (que toman acciones

o toman decisiones) están autorizados y son responsables de sus acciones.

Responsabilidad: cada parte contratada debe actuar de manera responsable ante la

organización y sus partes interesadas.

Justicia: no se permitirá que todas las decisiones tomadas, los procesos utilizados y su
implementación creen una ventaja injusta para ninguna parte en particular.

Niveles de Gobierno

Gobierno corporativo

Gobierno de la tecnología

Gobierno de TI

Gobernanza de la arquitectura

Solicitud de trabajo de arquitectura (opcional):

Es un documento que se envía desde la organización patrocinadora a la organización de

arquitectura para activar el inicio de un ciclo de desarrollo de la arquitectura.
Patrocinadores de organizaciones

Declaración de la misión de la organización

Objetivos de negocio (y cambios)

Planes estratégicos del negocio.

Límites de tiempo

Cambios en el entorno empresarial.

Limitaciones organizativas

Información presupuestaria, restricciones financieras.

Restricciones externas, restricciones empresariales.

Descripción del sistema de negocio actual

Arquitectura actual / descripción del sistema informático

Descripción de la organización en desarrollo

Descripción de los recursos disponibles para la organización en desarrollo.

2. 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 arquitectura aprobada.

Objetivos:

Desarrollar una visión de aspiraciones de alto nivel de las capacidades y el valor

comercial que se entregará como resultado de la arquitectura empresarial propuesta
(proyecto) (de dónde se parte y qué se pretende lograr). Al final se busca obtener la
aprobación del proyecto, que incluye un plan de comunicaciones.

Obtenga la aprobación para una declaración de trabajo de arquitectura que defina un

programa de trabajos para desarrollar e implementar la arquitectura descrita en la visión
de la arquitectura.
Entradas:

Solicitud de trabajo de arquitectura

Principios de negocios, objetivos de negocios y conductores de negocios

Modelo organizacional para la arquitectura empresarial

Marco referencial de Arquitectura adaptado, incluyendo adaptación del método de

arquitectura, contenido de arquitectura, principios de arquitectura, herramientas
configuradas e implementadas.

Reposorio de arquitectura llenado con la documentación de la arquitectura existente

(descripción del marco referencia, descripción de la líneas Base, etc...)

Fase Visión de Arquitectura – aproximación:

Proporciona al patrocinador una herramienta clave para vender los beneficios de la

capacidad propuesta a las partes interesadas y los tomadores de decisiones dentro de
la empresa.
Visión de la arquitectura describe cómo la nueva capacidad cumplirá con los objetivos
comerciales y los objetivos estratégicos y abordará las inquietudes de los interesados
cuando se implemente.
Proporciona una descripción de primer nivel y alto nivel de las arquitecturas de línea de
base y objetivo, que abarca los dominios de negocios, datos, aplicaciones y tecnología.
Los escenarios comerciales son una técnica apropiada y útil para descubrir y documentar
los requisitos comerciales
Fase Visión de Arquitectura – 11 pasos:
Fase Visión de Arquitectura – Salidas:

Declaración aprobada de trabajo de arquitectura

Declaraciones refinadas de principios de negocios, objetivos de negocios y
conductores de negocios.
Principios de la arquitectura
Evaluación de la capacidad Marco de arquitectura a medida
Visión de la arquitectura (descripción del problema, objetivo de la Declaración del
trabajo de arquitectura, vista de resumen, escenario de negocios (opcional),
requisito clave refinado de los interesados de alto nivel) Borrador de documento
de definición de arquitectura (línea base + arquitectura de destino versión 0.1)
Plan de comunicaciones
Contenido adicional poblando el Repositorio de Arquitectura

¿Qué contiene la Declaración de arquitectura de trabajo?

Título
Solicitud de proyectos de arquitectura y antecedentes.
Descripción y alcance del proyecto de arquitectura.
Visión general de la visión de la arquitectura Procedimientos específicos de
cambio de ámbito.
Roles, responsabilidades y entregables
Criterios y procedimientos de aceptación.
Plan de proyecto de arquitectura y calendario. Aprobaciones

¿Qué abarca el desarrollo de la Visión de Arquitectura?

 Descripción del problema:

Las partes interesadas y sus inquietudes.
Lista de temas / escenarios a tratar
 Objetivo de la Declaración de Obra de Arquitectura.

 Vistas de resumen y la versión 0.1 de las arquitecturas de negocios,

aplicaciones, datos y tecnología.

 Requisitos mapeados

 Referencia al borrador de documento de definición de arquitectura

Proyecto documento de definición de arquitectura

 • Arquitectura de negocio de línea base, Versión 0.1
• Arquitectura de tecnología de línea base, versión 0.1
• Arquitectura de datos de línea base, versión 0.1
• Arquitectura de aplicación de línea base, versión 0.1
• Arquitectura de negocio de destino, versión 0.1
• Arquitectura de la tecnología de destino, versión 0.1
• Arquitectura de datos de destino, versión 0.1
Arquitectura de la aplicación de destino, versión 0.1

Salidas:

- Declaración de Trabajo de arquitectura aprobada.

- Declaración refinada de principios de negocio, objetivos y motivación o
conductores de negocio.
- Principios de Arquitectura.
- Evaluación de Capacidades.
- Marco referencial de arquitectura adaptado o a medida.
- Visión de la arquitectura, Incluyendo;
o Requerimientos claves refinados y de alto nivel de los interesados (versión
preliminar del documento de definición de arquitectura, si está dentro del
alcance).
o Arquitectura de negocios de la líneas de base (Alto nivel)
o Arquitectura de la línea de base (de alto nivel).
o Arquitectura de datos de la línea de base.
o Arquitectura de aplicación
o Arquitectura tecnológica
o Arquitectura de negocio destino.
o Arquitectura de datos de destino
o Tecnológica de destino
o Plan de comunicación
- Contenido adicional agregado al repositorio de arquitectura

3. Fase B: Arquitectura de 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.

Entradas:

- Petición de Trabajo de Arquitectura

- Principios de negocio, objetivos de negocio, y motivaciones de negocio.
- Evaluación de capacidades
- Plan de comunicaciones
- Modelo Organizacional de Arquitectura Empresarial
- Marco de Referencia de Arquitectura adaptado.
- Declaración de Trabajo de Arquitectura aprobada.
- Principios de Arquitectura, incluyendo.
- principios de negocio, cuando ya existan
- Continuum de Empresa
- Repositorio de Arquitectura
- Visión de la Arquitectura, incluyendo:
• Requerimientos clave refinados y de alto nivel de los interesados
- Versión preliminar del Documento de Definición de la Arquitectura, incluyendo:
• Arquitectura de Negocio de la Línea de Base (de alto nivel)
• Arquitectura de Datos de la Línea de Base (de alto nivel)
• Arquitectura de Aplicación de la
- Línea de Base (de alto nivel)
• Arquitectura Tecnológica de la Línea de Base (de alto nivel)
• Arquitectura de Negocio de Destino (de alto nivel)
• Arquitectura de Datos de Destino (de alto nivel)
• Arquitectura de Aplicación de
- Destino (de alto nivel)
• Arquitectura Tecnológica de
- Destino (de alto nivel)

Salidas:

- Declaración de Trabajo de Arquitectura, actualizada si fuera necesario.

- Principios de negocios validados, objetivos de negocio y motivaciones de negocio.
 - Principios de arquitectura de negocio bien elaborados
- Versión preliminar del Documento de Definición de Arquitectura conteniendo
actualizaciones de contenido:
• Arquitectura de Negocio de la Línea de Base (detallada), si fuera apropiado
• Arquitectura de Negocio de Destino (detallada)
• Vistas correspondiente a Puntos de Vista seleccionados que responden a las
preocupaciones clave de los interesados
- Especificación preliminar de Requerimientos de Arquitectura incluyendo
actualizaciones de contenido:
• Resultados del Análisis de Brechas
• Requerimientos técnicos
• Requerimientos de Negocio actualizados con los Componentes de Arquitectura
de Negocio del Plan de Itinerario de Arquitectura.

4. 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:

4.1 Arquitectura de Datos

4.2 Arquitectura de Aplicación

4.1 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.
Entradas:
- Petición de Trabajo de Arquitectura
- Evaluación de Capacidades Plan de comunicaciones Modelo Organizacional de
Arquitectura Empresarial
- Marco de Referencia de Arquitectura adaptado
 - Principios de Datos
- Declaración de Trabajo de Arquitectura
- Visión de la Arquitectura Repositorio de Arquitectura Versión preliminar del
Documento de Definición de la Arquitectura, conteniendo:
• Arquitectura de Negocio de la Línea de Base (de alto nivel)
• Arquitectura de Negocio de Destino (de alto nivel)
• Arquitectura de Datos de la Línea de Base (de alto nivel)
• Arquitectura de Datos de Destino (de alto nivel)
• Arquitectura de Aplicación de la Línea de Base (de alto nivel)
• Arquitectura de Aplicación de Destino (de alto nivel)
• Arquitectura Tecnológica de la Línea de Base (de alto nivel)
• Arquitectura Tecnológica de Destino (de alto nivel) Especificación preliminar de
Requerimientos de Arquitectura, incluyendo:
• Resultados del Análisis de Brechas
• Requerimientos técnicos relevantes Componentes de la Arquitectura de
Negocio que son parte del Plan de Itinerario de Arquitectura

4.2 Arquitectura de Aplicación.

Objetivos:
- Desarrollar una Arquitectura de Aplicación de Destino que sea funcional a la
Arquitectura de Negocio y a la Visión de la Arquitectura, y que responda a la vez
a la Petición de Trabajo de Arquitectura y a las preocupaciones de los interesados.
- Identificar componentes candidatos del Plan de Itinerario de Arquitectura
basándose en las brechas identificadas entre la Arquitectura de Aplicación de la
Línea de Base y la Arquitectura de Aplicación de Destino.

Entradas:

- Petición de Trabajo de Arquitectura

- Evaluación de Capacidades
- Plan de comunicaciones
- Modelo Organizacional de Arquitectura Empresarial
- Marco de Referencia de Arquitectura adaptado
- Principios de Aplicación
- Declaración de Trabajo de Arquitectura
- Visión de la Arquitectura
- Repositorio de Arquitectura
- Documento preliminar de Definición de
- Arquitectura, conteniendo:
• Arquitectura de Negocio de la Línea de Base (de alto nivel)
• Arquitectura de Negocio de Destino (de alto nivel)
• Arquitectura de Datos de la Línea de Base (detallada o de alto nivel)
• Arquitectura de Datos de Destino (detallada o de alto nivel)
• Arquitectura de Aplicación de la Línea de Base (de alto nivel).
• Arquitectura de Aplicación de Destino (de alto nivel)
• Arquitectura Tecnológica de la Línea de Base (de alto nivel)
• Arquitectura Tecnológica de Destino (de alto nivel)

- Especificación preliminar de los Requerimientos de Arquitectura, incluyendo:

• Resultados del Análisis de Brechas
• Requerimientos técnicos relevantes

- Componentes de Arquitectura de Negocio y de Arquitectura de Datos en el Plan

de Itinerario de Arquitectura

Salidas:

- Declaración de Trabajo de Arquitectura, actualizado si fuera necesario

- Principios de Aplicación validados o nuevos principios de Aplicación
- Documento preliminar de Definición de Arquitectura, conteniendo actualizaciones
de contenido:
• Arquitectura de Aplicación de la Línea de Base
• Arquitectura de Aplicación de Destino
• Vistas de Arquitectura de Aplicación correspondientes a Puntos de Vista
seleccionados que responden a las preocupaciones clave de los interesados.
Especificación preliminar de Requerimientos de Arquitectura incluyendo
actualizaciones de contenido:
• Resultados del Análisis de Brechas
• Requerimientos de interoperabilidad de Aplicación.

5 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.

Transición Arquitectura

Una descripción formal de un estado de la arquitectura en un punto de vista

arquitectónico significativa en el tiempo. Uno o más arquitecturas de transición puede ser
usado para describir la progresión en el tiempo desde la línea base hasta la arquitectura
destino.

Enfoque

Arquitectura Repositorio
Como parte de la fase D, el equipo de arquitectura tendrá que considerar qué recursos
están disponibles Arquitectura Tecnología relevantes en la arquitectura de repositorio.

En particular:

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

de servicios de TI
 TOGAF Modelo Referencia técnica (TRM)
 Modelos tecnológicos genéricos relacionados con la industria del sector "vertical"
de la organización.

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.

Entradas:

- Petición de Trabajo de Arquitectura

- Evaluación de Capacidades
- Plan de comunicaciones
- Modelo Organizacional de Arquitectura Empresarial
- Marco de Referencia de Arquitectura adaptado
- Principios de Tecnología
- Declaración de Trabajo de Arquitectura
- Visión de la Arquitectura
- Repositorio de Arquitectura
- Documento preliminar de Definición de Arquitectura, conteniendo:
• Arquitectura de Negocio de la Línea de Base (detallada)
• Arquitectura de Negocio de Destino (detallada)
• Arquitectura de Datos de la Línea de Base (detallada)
• Arquitectura de Datos de Destino (detallada)
• Arquitectura de Aplicación de la Línea de Base (detallada)
• Arquitectura de Aplicación de Destino (detallada)
• Arquitectura Tecnológica de la Línea de Base (de alto nivel)
• Arquitectura Tecnológica de Destino (de alto nivel)
- Especificación preliminar de Requerimientos de Arquitectura, incluyendo:
• Resultados del Análisis de Brechas
• Requerimientos técnicos relevantes
 • Componentes de Arquitectura de Negocio y de Arquitectura de Datos en el Plan
de Itinerario de Arquitectura.

Salidas:

- Declaración de Trabajo de Arquitectura, actualizado si fuera necesario

- Principios de Tecnología validados o nuevos principios de Tecnología (si se
generaron aquí)
- Versión preliminar del Documento de Definición de Arquitectura, conteniendo
actualizaciones de contenido:
• Arquitectura Tecnológica de la Línea de Base
• Arquitectura Tecnológica de Destino
• Vistas de Arquitectura Tecnológica correspondientes a Puntos de Vista que han
sido seleccionados para responder a las preocupaciones clave de los interesados
- Especificación preliminar de los Requerimientos de Arquitectura, incluyendo
actualizaciones de contenido:
• Resultados del Análisis de Brechas
• Requerimientos resultantes de las Fases B y C
• Requerimientos de Tecnología actualizados.

- Componentes de Arquitectura Tecnológica del Plan de Itinerario de Arquitectura.

Pasos

El nivel de detalle abordado en la Fase D dependerá del alcance y los objetivos del
esfuerzo global de la arquitectura.

Bloques de construcción nueva tecnología que se introducen como parte de este

esfuerzo tendrá que ser definido en detalle durante la Fase D. existente bloques de
construcción de tecnología para ser admitidos en el entorno de destino pueden tener
que redefinirse en la Fase D para garantizar la interoperabilidad y adaptarse a sus
fines dentro de esta arquitectura tecnología específica.

El orden de los pasos en la Fase D, así como el momento en que se inician

formalmente y completaron deben adaptarse a la situación en cuestión de acuerdo
con el gobierno arquitectura establecida. En particular, determinar si en esta
situación, es conveniente llevar a cabo Descripción de línea de base o desarrollo
Arquitectura objetivo primero,

Todas las actividades que se han iniciado en estos pasos deben estar cerradas
durante el finalizar el paso Arquitectura. La documentación generada a partir de estas
medidas debe ser publicada oficialmente en la Arquitectura paso Crear definición de
documento
Los pasos en la Fase D son como sigue:

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

Desarrollar Línea de Base Tecnológica Arquitectura Descripción

Desarrollar Tecnología Target Arquitectura Descripción

Realizar el Análisis de brechas o Gap

Definir candidatos Componentes Hoja de Ruta

Resolver Impactos a través de la arquitectura del paisaje

Conducta Stakeholder Formal Comentario

Finalizar la Arquitectura Tecnología

Crear Arquitectura Definición de documento.

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

Revisar y validar el conjunto de principios tecnológicos. Normalmente, éstas formarán

parte de un conjunto global de principios de arquitectura. Lineamientos para elaborar
y aplicar los principios y un conjunto de muestras de los principios de la tecnología

Seleccionar los recursos pertinentes Arquitectura Tecnología (modelos de referencia,

patrones, etc) de la arquitectura de repositorio sobre la base de los impulsores del
negocio, las partes interesadas y sus preocupaciones.

Seleccione los puntos de vista pertinentes arquitectura tecnológica que permitan al

arquitecto para demostrar cómo se están abordando las preocupaciones de los
interesados en la arquitectura de la tecnología.

Identificar las herramientas y las técnicas que se utilizarán para la captura, modelado
y análisis, en asociación con los puntos de vista seleccionados apropiados.
Dependiendo del grado de sofisticación requerido, éstos pueden comprender
documentos y hojas de cálculo simples, o herramientas de modelado más
sofisticadas y técnicas.
 Determinar Proceso general Modeling

Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto
de vista específico necesario, utilizando la herramienta o método seleccionado.
Asegúrese de que todas las preocupaciones de los interesados están cubiertos. Si
no es así, crear nuevos modelos para hacer frente a ellos, o aumentar los modelos
existentes (véase más arriba).

El proceso para desarrollar una arquitectura de tecnología incorpora los siguientes

pasos:

Definir una taxonomía de los servicios de la plataforma y componentes tecnológicos

Lógicas (incluidas las normas).

Identificar lugares pertinentes en que se despliega la tecnología.

Llevar a cabo un inventario físico de la tecnología desplegada y abstracto hasta

encajar en la taxonomía.

Mira las aplicaciones y de negocios requisitos para la tecnología.

¿Es la tecnología en el lugar apto para el propósito de cumplir con los nuevos requisitos

(es decir, no se cumplen los requisitos funcionales y no funcionales)?

o Refinar la taxonomía
o Selección de productos (incluidos los productos dependientes).

Determinación de la configuración de la tecnología seleccionada

Determinar el impacto:

o Dimensionamiento y cálculo de costos

o La planificación de capacidad

o Impactos Instalación / gobernanza / migración.

En las primeras fases de la ADM, ciertas decisiones que se toman en torno a la

granularidad de servicio y los límites del servicio tendrán implicaciones en el componente
de la tecnología y el servicio de la plataforma. Las áreas en las que pueden verse
afectadas la Arquitectura Tecnología, Incluirán lo siguiente:

 Performance: La granularidad del servicio tendrá un impacto en los requisitos

de servicio de la plataforma. Servicios de grano grueso contienen varias
unidades de funcionalidad potencialmente con diferentes requisitos no
funcionales, por lo que el rendimiento de plataforma debe ser considerado.
Además, los servicios de granularidad gruesa a veces puede contener más
información de la que realmente se requiere por el sistema solicitante.
 Capacidad de mantenimiento: Si granularidad servicio es demasiado gruesa,
entonces la introducción de cambios en los que el servicio se hace difícil y
afecta el mantenimiento del servicio y de la plataforma en la que se entrega.
 Localización y Latencia: Servicios pueden interactuar entre sí a través de
enlaces a distancia y la comunicación entre los servicios tendrán latencia en-
construido. Dibujo límites de los servicios y el establecimiento de la
granularidad de servicio debe considerar el impacto de plataforma / ubicación
de estas comunicaciones entre los distintos servicios.
 Disponibilidad: invocación Servicio está sujeto a la red y / o deficiencia en el
servicio. Así que la alta disponibilidad de comunicación es una consideración
importante en la descomposición de servicio y la definición de un servicio
granular Los procesos de selección del producto pueden ocurrir dentro de la
fase de Arquitectura Tecnológica donde se reutilizan los productos existentes,
se está agregando capacidad incremental o de las decisiones de selección de
productos son un obstáculo durante la iniciación del proyecto.
Cuando la selección de productos se aparta de las normas existentes, implica un
esfuerzo significativo, o tiene impacto amplio, esta actividad debe ser marcado como una
oportunidad y se dirigió a través de las Oportunidades y fase de solución.

Identificar Catálogos requeridos de Tecnología Building Blocks

Los catálogos son los inventarios de los principales activos de la empresa. Los
catálogos son de naturaleza jerárquica y capturan una descomposición de una
entidad metamodelo y descomposiciones en todas las entidades del modelo
relacionado (por ejemplo, servicio de plataforma -> componente de tecnología lógica
->] componente de tecnología física).

Catálogos constituyen la materia prima para el desarrollo de matrices y diagramas, y

también actúan como un recurso clave para la gestión de la cartera de negocios y
capacidad de TI.

La arquitectura de tecnología debe crear catálogos de tecnología de la siguiente

manera:
 Sobre la base de los catálogos existentes en tecnología y análisis de las solicitudes
realizadas en la fase de Arquitectura de la aplicación, se recoge una lista de los
productos en uso.
 Si los requisitos identificados en la arquitectura de la aplicación no se cumplen por
los productos existentes, ampliar la lista de productos por los productos que examinan
disponibles en el mercado que proporcionan la funcionalidad y cumplir con los
estándares requeridos.
 Clasifica los productos contra el TOGAF TRM en su caso, la extensión del modelo
según sea necesario para ajustarse a la clasificación de los productos de la tecnología
en uso.
 Si los estándares de tecnología están actualmente en vigor, se aplican estos para el
 catálogo de componentes de tecnología para obtener una visión de línea de base del
cumplimiento de los estándares tecnológicos.
Los siguientes catálogos deben ser considerados para el desarrollo dentro de una
Arquitectura de Tecnología:

 Los estándares tecnológicos.

 Cartera de Tecnología.
 La estructura de catálogos se basa en los atributos de las entidades metamodelo.

7. Preguntas tipo de examen de certificación

TOGAF 9 Fundamentos es una certificación que está enfocada en aquellos

profesionales de TI que tienen conocimiento o están interesados en profundizarlos en
el campo de la Arquitectura Empresarial. La certificación está orientada a
profesionales que desarrollan sus actividades relacionadas a la gestión y planificación
estratégica de TI, por tanto, es una certificación más enfocada en la Gestión de TI
que en conocimientos técnicos específicos.

Procedimiento a seguir:

1. Pre-requisitos
No existen pre-requisitos para dar el examen TOGAF 9 Fundamentos (Examen 1).

2. El Examen
Consta de 40 preguntas de selección múltiple que se debe completar en 60 minutos.
Deberás calificar al menos 55% (24 preguntas o más) para obtener la certificación.
Los exámenes se pueden programar a través de Prometric.

3. Material
Es importante resaltar que tienes dos formas de comenzar tu preparación: la primera,
tomar un curso en alguna institución acreditada en tu País o tomar un curso online; la
segunda opción, es la auto-preparación con materiales de la web o de la página oficial
de Open Group.
Si tomas la segunda opción, puedes encontrar toda la información necesaria para el
examen. Pero también puedes comprar el material TOGAF® 9 Certification Self Study
Pack, 3rd edn.
Cuando compras este material. La ventaja es que te dan las guías de estudio en
formato PDF para las dos certificaciones, materiales adicionales, resúmenes, y lo más
importante, preguntas tipo examen por cada capítulo, dos Exámenes de simulación y
preguntas adicionales como Bonus.

4. Modo y tiempo de preparación

Con 3 semanas de preparación y un promedio de 4 horas diarias siguiendo esta
secuencia:

4.1. Leer completamente el documento Guía de estudio TOGAF 9 Fundamentos.

Pero lo más importante, anotar un resumen en una hoja excel o en un papel TODOS
los puntos clave en cada capítulo de la guía a manera de memoria para repasarlo
después (este punto es muy importante, tómalo muy en cuenta).

4.2. Repasar el resumen que has realizado con los puntos más importantes y volver
a la guía cuantas veces sea necesario para enriquecer tu resumen lo más posible.
Pero no olvides que es un resumen así que solo debe contener lo puntos clave.

4.3. Dar el test de simulación #1 de openrach. Este simulador es muy importante,

sin embargo el nivel de dificultad es ligeramente superior al del examen real.

4.4. Repasar los puntos de tu resumen y complementar con los siguientes

documentos:

TOGAF 9.1 ADM Overview Reference card (pdf)

TOGAF 9.1 Phase Reference cards (pdf)
TOGAF 9.1 ADM Steps Overview Reference card (pdf)

Estos documentos te darán más información que será más fácil de procesar en
este punto.

4.5. Intentar con estos mockups que me parecieron muy buenos.

http://www.techbolo.com/togaf (5 exámenes muy importantes que debes
resolverlos y analizar tus errores para repasarlos en la guía y anotarlos en tu
resumen). Además, completar los otros dos exámenes de openrach.
4.6. Resolver al detalle los exámenes del material oficial. 1.- Examen simulador y
2.- el Examen Bonus.
4.7. Si obtienes un puntaje de al menos 75% en estos últimos exámenes, no vas a
tener problemas en el examen real.
 5. Programación del Examen

Debes programar con tiempo el examen para conseguir una hora adecuada. El costo
del examen es en $. Pero obtienes un descuento si aplicas por los exámenes 1 y 2 a
la vez.

6. Consideraciones finales

El examen es en inglés así que toda tu preparación deberá ser en este idioma. No
existe traducción al idioma español como en otras certificaciones (PMP por ejemplo).

Tips: Si escoges la opción "ENGLISH AS A SECOND LANGUAGE" te darán un

tiempo adicional, así que puedes utilizar este recurso para tener tiempo de repasar
tus preguntas durante el examen.

Preguntas:

1) ¿Bajo qué circunstancias es necesario optar por TOGAF?

a) La necesidad de organizar el proceso de desarrollo empresarial

b) Lograr los objetivos comerciales

c) Establecer un enlace entre Negocio y TI en las empresas

d) Al descubrir oportunidades de negocio o de TI

e) La mala gestión en proyectos software.

2) ¿Cuál no es una misión de The Open Group?

a) Trabajar con los clientes para abordar los requisitos actuales.

b) Fomentar la adquisición de productos certificados.

c) Proveer estándares para la infraestructura de la informática.

d) Trabajar con proveedores, consorcios y organismos de estándares para facilitar la

interoperabilidad.

e) Administrar TOGAF
3) ¿Qué nos permite el uso de una arquitectura empresarial?

a) Considerar todos y cada uno de los elementos que conforman la empresa.

b) Permite evaluar las fortalezas

c) Permite evaluar debilidades

d) Permite trazar estrategias de transformación

e) Todas las anteriores

4) En TOGAF 9, y en comparación de TOGAF 8, cuál de las siguientes no es una nueva

característica desarrollada.

a) Repositorio de arquitectura y Enterprise Continuum.

b) Eliminación de diferencias innecesarias, y muchos más ejemplos y plantillas.

c) Lenguaje de descripción de bloques de construcción.

d) Planificación basada en la capacidad empresarial.

e) Orientación sobre cómo usar TOGAF para desarrollar arquitecturas de seguridad y

SOA.

5) No pertenece a TOGAF

a) Metodología de arquitectura empresarial

b) Ofrece varios modelos para el desarrollo de software / hardware.

c) Está dirigido a reducir los errores, mantener los plazos, mantenerse dentro del
presupuesto.

d) Ayuda a organizar el proceso de desarrollo a través de un enfoque sistemático.

e) Ayuda a definir los objetivos comerciales y los alinea con los objetivos de la
arquitectura en torno al desarrollo de software empresarial.

6) No es visión general de TOGAF

a) Asegurarse de que todos hablen el mismo idioma.

b) La estandarización de métodos abiertos para la arquitectura empresarial.

c) Ahorro de tiempo y dinero, y utilizar los recursos de manera más efectiva.

d) Gratuidad para que las organizaciones utilicen TOGAF internamente, pero no

con fines comerciales.

e) Lograr un rendimiento de la inversión demostrable

7) En qué fase del ciclo ADM se examina el contexto general para aplicar una arquitectura
empresarial

a) Fase Preliminar

b) Fase B: Arquitectura de Negocio

c) Fase C: Arquitecturas de Sistemas de Información.