Parte 03 - Arquitectura Tecnológica Empresarial

INGENIERIA
INFORMATICA
ARQUITECTURA EMPRESARIAL
INGENIERIA
INFORMATICA SITUACION ACTUAL
CAMBIOS CADA VEZ MAS RAPIDOS

• CAMBIO TECNOLÓGICO
• NUEVOS PRODUCTOS Y NECESIDADES
MERCADOS MAS COMPETITIVOS Y DIFERENCIADOS

• Necesidad de ser diferente
• Necesidad de ser mas eficientes
• Muchos participantes
ECONOMIA DE LA DEMANDA (DESDE LA OFERTA)
2
INGENIERIA
INFORMATICA SITUACION ACTUAL
LAS EMPRESAS SON SISTEMAS COMPLEJOS

• Recursos
• Personas
• Tecnologías
• Estrategias
• Metas y Objetivos
• Riesgos
3
INGENIERIA
INFORMATICA Concepto de Arquitectura (Empresarial)
Proviene del Griego

• ARCH: Que tiene el mando
• TEKTON: Constructor o Carpintero
Refleja la necesidad de dirigir la forma en que se construye la empresa

• Organiza trabaja y evoluciona
La empresa esta compuesta de

• Misión
• Visión
• Objetivos
• Procesos
• Tecnología
Es decir debemos ver la empresa en forma Holística
4
INGENIERIA
INFORMATICA Propósito Arquitectura (Empresarial)
Describir
• Los aspectos que conforman la empresa y la relación entre estos
Alinear
• Desde la estrategia a lo operacional
• Desde lo que valora el cliente hacia el producto que ofrezco
Optimizar
• Forma de trabajo y productos que entrego
Anticipar
• Riesgos e impactos de cambio
5
INGENIERIA
INFORMATICA Perspectivas de la AE(Empresarial)
Se puede representar
• Comportamiento y funcionamiento
• Estructura y datos
Y desde distintos Ángulos

• Gerencial, estratégico, metas, visión
• Táctico, funcional, de procesos
• Operacional, tecnológico
• Otros
6
INGENIERIA
INFORMATICA Perspectivas de la AE(Empresarial)
Visión Tradicional Visión Arquitectónica

• Jerárquica • Matricial
• Estratégico • Sistémica
• Táctico • Transversal
• Operacional
• Áreas funcionales
• Finanzas
• Operaciones
• Ventas
• Etc.
7
INGENIERIA
INFORMATICA ARQUITECTURA EMPRESARIAL
Introducción a TOGAF
TOGAF es un marco de referencia de arquitectura.

En términos simples, TOGAF es una herramienta para asistir en la aceptación, creación, uso, y mantenimiento de arquitecturas.
Está basado en un modelo iterativo de procesos apoyado por las mejores prácticas y un conjunto reutilizable de activos
arquitectónicos existentes.
TOGAF es desarrollado y mantenido por el Foro de Arquitectura de The Open Group.
La primera versión de TOGAF, desarrollada en 1995, se basó en el Marco de Referencia de Arquitectura Técnica para la Gestión
de la Información del Ministerio de Defensa Estadounidense (TAFIM por sus siglas en inglés).
8
INGENIERIA
¿Qué es Arquitectura en el Contexto de TOGAF?

ISO/IEC 42010:20072 define “arquitectura” como:
“La organización fundamental de un sistema, compuesta por sus componentes, las relaciones entre
ellos y su entorno, así como los principios que gobiernan su diseño y evolución.”
TOGAF adopta y amplía esta definición. En TOGAF, “arquitectura” tiene dos significados según el contexto:
1.Una descripción formal de un sistema, o un plano detallado del sistema al nivel de sus componentes para
orientar su implementación
2.La estructura de componentes, sus interrelaciones, y los principios y guías que gobiernan su diseño y
evolución a través del tiempo
¿Qué clases de Arquitectura cubre TOGAF?

TOGAF cubre el desarrollo de cuatro tipos relacionados de arquitectura. Estos cuatro tipos de arquitectura
son comúnmente aceptados como
9
INGENIERIA
Tipo de Arquitectura Descripción

Arquitectura de Negocio La estrategia de negocio, gobierno, organización y procesos clave de la
organización.
Arquitectura de Datos La estructura de datos lógicos y físicos que posee una organización y sus
recursos de gestión de datos.
Arquitectura de Un plano (blueprint en inglés) de las aplicaciones individuales a implementar,
Aplicación sus interacciones y sus relaciones con los procesos de negocio principales de
la organización.
Arquitectura Las capacidades de software y hardware que se requieren para apoyar la
Tecnológica implementación de servicios de negocio, datos y aplicación. Esto incluye
infraestructura de IT, capa de mediación (middleware en ingles), redes,
comunicaciones, procesamiento y estándares.
10
INGENIERIA
INFORMATICA ¿Qué contiene TOGAF?
TOGAF refleja la estructura y el contenido de la Capacidad Arquitectónica dentro de una empresa.

• El Método de Desarrollo de la Arquitectura (ADM por sus siglas en inglés) es central en TOGAF.
• La Capacidad Arquitectónica opera el método.
• El método es apoyado por varias guías y técnicas.
• Esto produce contenido para ser almacenado en el repositorio ,
• Que se clasifica según el Continuum Empresarial
11
INGENIERIA
INFORMATICA Introducción
12
INGENIERIA
1. Método de Desarrollo de la Arquitectura (ADM por sus siglas en inglés)

El ADM describe cómo obtener una Arquitectura Empresarial que sea específica para la organización y para
responder a los requerimientos del negocio. El ADM es el componente principal de TOGAF y proporciona
dirección a los arquitectos en varios niveles:
• Proporciona varias fases de desarrollo de arquitectura (Arquitectura de Negocio, Arquitecturas de
Sistemas de Información, Arquitectura Tecnológica) en un ciclo, que sirve como una plantilla general
de procesos para la actividad de desarrollo de la arquitectura.
• Proporciona una narrativa de cada fase de la arquitectura, describiendo la fase en términos de
objetivos, enfoque, entradas, pasos a seguir, y salidas. Las secciones de entradas y salidas proporcionan
una definición de la estructura del contenido de arquitectura y entregables.
• Proporciona resúmenes multi-fase que abordan también la Gestión de Requerimientos.
2. Guías y Técnicas del ADM
Proporciona varias guías y técnicas para apoyar la aplicación del ADM. Las guías abordan la adaptación del ADM para su
utilización en varios escenarios de uso, incluyendo diferentes estilos de procesos y también arquitecturas especializadas
(como la de seguridad). Las técnicas apoyan tareas específicas dentro del ADM (como la definición de principios,
escenarios de negocio, objetivos de negocio, análisis de brechas, planificación de la migración, gestión del riesgo, etc.).
13
INGENIERIA
3. Marco de Referencia del Contenido Arquitectónico

El Marco de Referencia del Contenido Arquitectónico proporciona un modelo detallado de productos de trabajo
arquitectónicos, incluyendo entregables, artefactos dentro de los entregables, y los Bloques de Construcción de la
Arquitectura (ABBs por sus siglas en inglés) que los entregables representan.
4. El Continuum de Empresa
Proporciona un modelo para estructurar un repositorio virtual así como también métodos para clasificar artefactos de
arquitectura y de solución, mostrando cómo los diferentes tipos de artefactos evolucionan, y cómo se pueden
aprovechar y reutilizarse. El Continuum de Empresa se basa en arquitecturas y soluciones (modelos, patrones,
descripciones de arquitectura, etc.) que existen dentro de la empresa y en la industria en general, y que la empresa ha
coleccionado para uso en el desarrollo de sus arquitecturas.
5. Modelos de Referencia de TOGAF
TOGAF proporciona dos modelos de referencia para su posible inclusión en el Continuum de Empresa de la
organización, el Modelo de Referencia Técnico (TRM por sus siglas en inglés) de TOGAF, y el Modelo de Referencia para
la Infraestructura de la Información Integrada (III-RM por sus siglas en inglés).
6. El Marco de Referencia de la Capacidad Arquitectónica
El Marco de Referencia de la Capacidad Arquitectónica es un conjunto de recursos, guías, plantillas, información
general, etc. proporcionada para ayudar al arquitecto a establecer una práctica de arquitectura dentro de una
organización.
14
INGENIERIA
INFORMATICA El Método de Desarrollo de la Arquitectura
¿Qué es el ADM?
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, aplicaciones, datos, tecnología) que
permiten al arquitecto asegurar que un conjunto complejo de requerimientos se aborden adecuadamente
• Un conjunto de guías y técnicas para el desarrollo de arquitectura
¿Cuáles son las Fases del ADM?
El ADM consiste en varias Fases que se desplazan cíclicamente a través de una serie de Dominios de Arquitectura y
permiten al arquitecto asegurar que un conjunto complejo de requerimientos se aborden adecuadamente. La
estructura básica del ADM se muestra en la Figura siguiente.
15
INGENIERIA
INFORMATICA
Desafíos de la AE TOGAF Método de

desarrollo Arquitectura
SOA TIPCO Arquitectura del

software multicapa
16
INGENIERIA
INFORMATICA Fases AMD
17
INGENIERIA
INFORMATICA
El ADM se aplica iterativamente durante todo el proceso, entre las diferentes Fases, y dentro de ellas.
Durante todo el ciclo del ADM se debe realizar una validación frecuente de los resultados respecto a los
requerimientos originales, tanto aquellos del ciclo completo del DM como los de la Fase particular del proceso. Esta
validación debe reconsiderar el alcance, los detalles, el plan y los hitos. Cada Fase debe considerar los activos
producidos a partir de las iteraciones anteriores del proceso y los activos externos de mercado, así como otros marcos
de referencia o modelos.
El ADM apoya el concepto de iteración en tres niveles:

• Ciclo alrededor del ADM: El ADM se presenta de manera circular indicando que la finalización de una Fase de trabajo
en la arquitectura alimenta directamente las Fases subsecuentes de trabajo en la arquitectura.
• Iteración entre Fases: TOGAF describe el concepto de la iteración a través de Fases (por ejemplo, volviendo a la
Arquitectura de Negocio posteriormente a la finalización de la Arquitectura Tecnológica).
• Ciclo alrededor de una Fase individual: TOGAF apoya la ejecución repetida de las actividades dentro de una Fase
individual del ADM como una técnica para elaborar contenido arquitectónico.
18
INGENIERIA
INFORMATICA
19
INGENIERIA
INFORMATICA
20
INGENIERIA
INFORMATICA
21
INGENIERIA
INFORMATICA Fase Preliminar
La Fase Preliminar prepara a una organización para emprender proyectos de Arquitectura

Empresarial de manera exitosa.
Objetivos Pasos
Determinar las Capacidades Arquitectónicas deseadas por la organización: • Determinar las organizaciones de la empresa que serán impactadas.
• Examinar el contexto organizacional para llevar a cabo Arquitectura • Confirmar los Marcos de Referencia de Gobierno y de soporte
Empresarial adicional.
• Identificar y determinar el alcance de los elementos en las organizaciones • Definir y establecer el equipo de Arquitectura Empresarial y su
de la empresa que serán afectadas por la Capacidad Arquitectónica organización.
• Identificar los marcos de referencia establecidos, los métodos y los • Identificar y establecer los Principios de Arquitectura.
procesos que se entrecruzan con la Capacidad Arquitectónica • Adaptar TOGAF y, si es necesario, otros Marcos de Referencia de
• Establecer el objetivo de Madurez de las Capacidades Arquitectura seleccionados.
• Establecer las Capacidades Arquitectónicas: • Implementar herramientas de arquitectura.
• Definir y establecer el Modelo Organizacional de Arquitectura
Empresarial
• Definir y establecer el proceso detallado y los recursos para el
Gobierno de la Arquitectura
• Seleccionar y poner en práctica las herramientas que apoyan la
actividad de arquitectura
• Definir los Principios de Arquitectura
22
INGENIERIA
INFORMATICA
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 Pasos
• Desarrollar una visión de alto nivel de las • Establecer el proyecto de arquitectura.
Capacidades y valor de negocio que se • Identificar a los interesados, las preocupaciones y los requerimientos de negocio.
desean obtener como resultado de la • Confirmar y elaborar objetivos de negocio, motivaciones de negocio y limitaciones.
Arquitectura Empresarial propuesta.
• Evaluar las capacidades del negocio.
• Obtener la aprobación de la Declaración
• Evaluar la preparación para la transformación del negocio.
del Trabajo de Arquitectura que define un
• Definir el alcance.
programa de trabajo para desarrollar e
• Confirmar y elaborar Principios de Arquitectura, incluyendo Principios de Negocio.
implementar la arquitectura descrita en la
• Desarrollar la Visión de la Arquitectura.
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.
23
INGENIERIA
INFORMATICA Fase B: Arquitectura de Negocio
Objetivos Pasos
• Desarrollar la Arquitectura de Negocio de Destino describiendo • Seleccionar modelos de referencia, Puntos de Vista y herramientas.
cómo la empresa tiene que operar para alcanzar los objetivos • Desarrollar la descripción de la Arquitectura de Negocio de la Línea de Base.
de negocio, responder a las motivaciones estratégicas • Desarrollar la descripción de la Arquitectura de Negocio de Destino.
definidas en la Visión de la Arquitectura y responder a la • Realizar un Análisis de Brechas.
Petición de Trabajo de Arquitectura y las preocupaciones de los
• Definir los componentes candidatos del Plan de Itinerario.
interesados
• Identificar componentes candidatos para el Plan de Itinerario • Resolver los impactos al Panorama de Arquitectura.
de Arquitectura basándose en las brechas identificadas entre • Conducir una revisión formal con los interesados.
la Arquitectura de Negocio de la Línea de Base y la • Finalizar la Arquitectura de Negocio.
Arquitectura de Negocio de Destino • Crear el Documento de Definición de Arquitectura.
24
INGENIERIA
INFORMATICA 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
Objetivos Pasos
• Desarrollar una Arquitectura de Datos de Destino que sea • Seleccionar modelos de referencia,
funcional a la Arquitectura de Negocio y a la Visión de • Puntos de Vista y herramientas Desarrollar la descripción de la
Arquitectura, y que responda a la vez a la Petición de Trabajo Arquitectura de Datos de la Línea de Base
de Arquitectura y a las preocupaciones de los interesados
• Desarrollar la descripción de la Arquitectura de Datos de
• Identificar los componentes candidatos que podrían
Destino
conformar el Plan de Itinerario de Arquitectura basándose en
• Realizar un Análisis de Brechas
las brechas identificadas entre la Arquitectura de Datos de la
• Definir los componentes candidatos que conforman el Plan de
Línea de Base y la Arquitectura de Datos de Destino
Itinerario
• Resolver los impactos al Panorama de Arquitectura
• Conducir una revisión formal con los interesados
• Finalizar la Arquitectura de Datos
• Crear el Documento de Definición de Arquitectura
25
INGENIERIA
INFORMATICA Arquitectura de Aplicación
Objetivos Pasos
• Desarrollar una Arquitectura de Aplicación de Destino que sea • Seleccionar modelos de referencia, Puntos de Vista y
funcional a la Arquitectura de Negocio y a la Visión de la herramientas
Arquitectura, y que responda a la vez a la Petición de Trabajo de • Desarrollar la descripción de la Arquitectura de Aplicación de
Arquitectura y a las preocupaciones de los interesados. la Línea de Base
• Identificar componentes candidatos del Plan de Itinerario de • Desarrollar la descripción de la Arquitectura de Aplicación
Arquitectura basándose en las brechas identificadas entre la de Destino
Arquitectura de Aplicación de la Línea de Base y la
• Realizar el Análisis de Brechas
Arquitectura de Aplicación de Destino
• Definir los componentes candidatos que conforman el
Plan de Itinerario
• Resolver los impactos al Panorama de Arquitectura
• Finalizar la Arquitectura de Aplicación
• Crear el Documento de Definición de Arquitectura
26
INGENIERIA
INFORMATICA
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 Pasos
• Desarrollar la Arquitectura Tecnológica de Destino de tal manera • Seleccionar modelos de referencia, Puntos de Vista y
que permita que los componentes lógicos y físicos de datos y herramientas
aplicaciones, así como aquellos de la Visión de la Arquitectura, • Desarrollar la descripción de la Arquitectura Tecnológica de la
correspondan a la Petición de Trabajo de Arquitectura y respondan Línea de Base
a las preocupaciones de los interesados. • Desarrollar la descripción de la Arquitectura Tecnológica
• Identificar los componentes candidatos del Plan de Itinerario de de Destino
Arquitectura basándose en las brechas identificadas entre la • Realizar el Análisis de Brechas Definir los componentes
Arquitectura Tecnológica de la Línea de Base y la Arquitectura candidatos del Plan de Itinerario
Tecnológica de Destino • Resolver los impactos en el Panorama de Arquitectura
• Finalizar la Arquitectura Tecnológica Crear el Documento
de Definición de Arquitectura
27
INGENIERIA
INFORMATICA 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 Pasos
• Generar la versión inicial y completa del Plan de • Determinar o confirmar atributos claves para el cambio empresarial
Itinerario de Arquitectura, basándose en el Análisis de • Determinar limitaciones del negocio para la implementación
Brechas y en los componentes candidatos del Plan de • Examinar y consolidar resultados de los Análisis de Brechas realizados
Itinerario de Arquitectura resultantes de las Fases B, C y
en las Fases B a D
D
• Examinar los requerimientos consolidados entre funciones de negocio
• Determinar si un enfoque incremental es requerido,
relacionadas
y si fuera así, identificar las Arquitecturas de
• Consolidar y reconciliar los requerimientos de interoperabilidad Refinar
Transición que proporcionarán valor continuo de
y validar dependencias
negocio
• Confirmar el Grado de Preparación y riesgos para la transformación
del negocio.
• Formular la estrategia de Implementación y Migración
• Identificar y agrupar los paquetes de trabajo principales
• Identificar las Arquitecturas de Transición
• Crear el Plan de Itinerario de Arquitectura y el Plan de
Implementación y Migración.
28
INGENIERIA
INFORMATICA
29
INGENIERIA
INFORMATICA 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 Pasos
• Finalizar el Plan de Itinerario de Arquitectura y el Plan de • Confirmar las interacciones del Plan de Implementación y
Implementación y Migración que lo apoya. Migración con el Marco de Referencia de Gestión de la empresa.
• Asegurar que el Plan de Implementación y Migración se • Asignar el valor de negocio a cada paquete de trabajo
alinee al enfoque de la empresa para la gestión e • Estimar las necesidades de recursos, los tiempos del proyecto y
Implementación de cambios en la cartera general de cambios la disponibilidad/medio de entrega
empresariales. • Priorizar los proyectos de migración a través de la realización de
• Asegurar que el valor de negocio y los costos de los paquetes una evaluación de costo/beneficio y validación de riesgos
de trabajo y Arquitecturas de Transición sean bien entendidos • Confirmar el Plan de Itinerario de Arquitectura y actualizar el
por los interesados. Documento de Definición de Arquitectura
• Completar el plan de Implementación y Migración
• Completar el ciclo de desarrollo y documentar las lecciones
aprendidas
30
INGENIERIA
INFORMATICA
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 Pasos
• Asegurar la conformidad con la Arquitectura de • Confirmar el alcance y las prioridades para la implementación con la
Destino a través de los proyectos de dirección de desarrollo de la empresa.
implementación. • Identificar los recursos y habilidades requeridos para la implementación
• Realizar las funciones de Gobierno de • Guiar el desarrollo de la implementación de las soluciones
Arquitectura apropiadas para la solución y para • Realizar revisiones de conformidad de Arquitectura Empresarial
toda Solicitud de Cambio de la Arquitectura • Poner en práctica la operación de negocio y TI Realizar la revisión
impulsada por la implementación posterior a la implementación y cerrar la implementación
31
INGENIERIA
INFORMATICA
La Fase H asegura que los cambios en la arquitectura se gestionen de una manera controlada.
Objetivos Pasos
• Asegurar que el ciclo de vida de la arquitectura se mantenga • Establecer el proceso de realización del valor
• Asegurar la ejecución del Marco de Referencia de Gobierno de • Implementar las herramientas de supervisión
Arquitectura • Gestionar los riesgos
• Asegurar que la Capacidad Arquitectónica Empresarial • Proporcionar un análisis de la gestión de cambios de
cumplen con los requerimientos actuales arquitectura
• Desarrollar los requerimientos de cambio para cumplir con
los objetivos de rendimiento
• Gestionar el proceso de gobierno
• Activar el proceso de implementación de cambios
32
INGENIERIA
INFORMATICA Gestión de Requerimientos
El proceso de Gestión de Requerimientos de Arquitectura se aplica a todas las Fases del ciclo del ADM. El proceso de Gestión de
Requerimientos es un proceso dinámico que aborda la identificación de los requerimientos de la empresa, almacenándolos, y luego
gestionándolos al ingreso y egreso de las Fases relevantes del ADM. Como se muestra en la Figura 2, este proceso es fundamental para
conducir el proceso del ADM.
La capacidad para hacer frente a los cambios de requerimientos es crucial para el proceso del ADM, dado que la arquitectura, por su
propia naturaleza, aborda la incertidumbre y el cambio, tendiendo un puente entre las aspiraciones de los interesados y lo que se puede
entregar como una solución práctica.
Objetivos Pasos
• Asegurar que el proceso de gestión • Identificar/documentar los requerimientos
de requerimientos sea mantenido y • Establecer los requerimientos de la Línea de Base
operado en todas las Fases • Supervisar los requerimientos de la Línea de Base
relevantes del ADM.
• Identificar cambios en los requerimientos; quitar, añadir, modificar y reexaminar
• Gestionar los requerimientos de
prioridades
arquitectura identificados durante
• Identificar cambios en los requerimientos y registrar las prioridades; identificar y resolver
toda la ejecución del ciclo del ADM
conflictos; generar declaraciones de impacto de requerimientos
o en una de sus Fases.
• Evaluar el impacto de los cambios en los requerimientos en las Fases actuales y
• Asegurar que los requerimientos
previas del ADM
de arquitectura relevantes estén
• Implementar los requerimientos que provienen de la Fase H
disponibles para el uso en cada
• Actualizar el repositorio de requerimientos
Fase cuando éstas se ejecutan.
• Implementar los cambios requeridos en la Fase actual
• Evaluar y revisar los Análisis
33 de Brechas de las Fases anteriores
INGENIERIA
INFORMATICA Determinación del alcance de la Actividad de Arquitectura
El ADM define una secuencia recomendada para las varias Fases y pasos implicados en el desarrollo de una Arquitectura Empresarial para
toda una organización, pero el ADM no puede determinar el alcance: este debe ser determinado por la propia organización.
Hay muchos motivos que limitan (o restringen) el alcance de la actividad de arquitectura a realizar, la mayor parte de los cuales están
relacionados con límites en:
• La autoridad organizativa del equipo que produce la arquitectura
• Los objetivos y preocupaciones de los interesados que deben resolverse dentro de la arquitectura
• La disponibilidad en términos de personas, finanzas y otros recursos
El alcance elegido para la actividad de arquitectura debe idealmente permitir que el trabajo de todos los arquitectos dentro de la empresa
sea gobernado e integrado con eficacia. Esto requiere un conjunto bien alineado de “particiones de la arquitectura” que aseguren que los
arquitectos no trabajen en actividades duplicadas o contradictorias. También requiere la definición de reutilización y de conformidad entre
particiones de la arquitectura. La división de la empresa y de sus actividades relacionadas con la arquitectura se aborda en TOGAF.
La Tabla 4 muestra las cuatro dimensiones en las cuales el alcance se puede definir y limitar.
34
INGENIERIA
INFORMATICA
Dimensión Consideraciones
Amplitud ¿Cuál es la extensión total de la empresa, y con qué parte de esa
extensión debería tratar el esfuerzo de arquitectura?
Muchas empresas son muy grandes y se componen efectivamente de una federación de unidades organizativas que
se podrían considerar como empresas en sí.
La empresa moderna se extiende cada vez más allá de sus límites tradicionales, y adopta una combinación difusa de
empresa tradicional de negocio combinada con sus proveedores, clientes y asociados.
Profundidad ¿Qué nivel de detalle debería alcanzar el esfuerzo de

arquitectura? ¿Cuánta arquitectura es “suficiente”? ¿Cuál es la demarcación apropiada entre el esfuerzo de
arquitectura y otras actividades relacionadas (diseño de sistema, ingeniería de sistema, desarrollo de sistema)?
Periodo de ¿Cuál es el periodo de tiempo que se necesita para expresar la Visión de la Arquitectura, y tiene sentido (en términos
tiempo de factibilidad y recursos) tratar la descripción detallada de la arquitectura dentro del mismo periodo? ¿Si la respuesta
es no, cuántas Arquitecturas de Transición deben definirse, y cuáles son sus períodos de tiempo?
Dominios de Una descripción de la Arquitectura Empresarial completa debe contener los cuatro Dominios de Arquitectura (Negocio,
Arquitectura Datos, Aplicación, Tecnología), pero la realidad de las limitaciones de recursos y tiempo a menudo significa que no hay
tiempo suficiente, financiación o recursos para construir una descripción de arquitectura con un enfoque descendente
(“Top-Down” en inglés), que incluya los cuatro Dominios de Arquitectura, aun cuando el alcance escogido dentro de la
empresa sea menor que el alcance total de la empresa completa.
35
INGENIERIA
INFORMATICA Servicios TI
•Proceso de adquisición y desarrollo de servicios.

•Proceso de configuración y gestión de servicios.
•Proceso de documentación.
•Proceso de dimensionamiento o sizing de la infraestructura.
•Proceso de gestión de la calidad, según modelo de calidad adoptado por TIC.
•Proceso de capacitación técnica del RRHH.
•Proceso de mejoramiento continuo.
36
INGENIERIA
INFORMATICA Benchmarking
El benchmarking es una técnica o herramienta de gestión que consiste en tomar como referencia aspectos de
nuestra competencia, y adaptarlos a nuestro negocio.
Para hacer uso del benchmarking, en primer lugar debemos estudiar a nuestros competidores (especialmente a los principales
o a los líderes), recopilar toda información relevante sobre ellos, analizarla, e identificar o destacar los aspectos o estrategias
que estén usando o aplicando y que mejores resultados les estén dando.
Paso seguido, procedemos a tomar como referencia dichos aspectos o estrategias, y los adaptamos a nuestro negocio,
agregándole nuestras mejoras y nuestra creatividad.
Por ejemplo, podemos tomar como referencias sus productos, sus servicios, sus procesos de trabajo, sus políticas, sus
estrategias comerciales, sus canales publicitarios, sus puntos de ventas, sus promociones, sus métodos de ventas,
etc. Normalmente es concebible esta técnica de la administración cuando nuestra competencia de cierto modo es
inalcanzable o difícil de hacerle la competencia, no es ser conformista si no que la realidad nos la pone difícil y por ello nos
vemos en la necesidad de adaptarnos a un sistema similar al de nuestra competencia.
37
INGENIERIA
PRIMERA ETAPA: PLANTEMIENTO DEL PROYECTO DE BENCHMARKING :

Algunas personas creen que no se trata de otra cosa que de aplicar el sentido común a una rigurosa secuencia de hechos. En
gran parte, están en lo cierto. Sin embargo, la secuencia de hechos en la etapa de planeamiento es introspectiva, y por lo tanto
requiere un gran esfuerzo para lograr objetividad. La consecuencia de estos hechos es lo que permite a una compañía evaluar
una dirección para la subsiguiente orientación en el exterior
38
INGENIERIA
SEGUNDA ETAPA:RECOPILACIÓN DE LOS DATOS NECESARIOS
La secuencia en la fase de recopilación de datos está más orientada al exterior. El desarrollo de un cuestionario preliminar
proporciona un puente a esta segunda etapa en el proceso de benchmarking. Dicho cuestionario sirve como una herramienta
que organiza a los criterios del equipo acerca de la búsqueda de datos. Esto se logra al orientar las respuestas de los
participantes de la encuesta hacia temas específicos, utilizando una referencia común. Así, esta herramienta proporciona una
base de comparación para la selección entre las diferentes compañías. La segunda etapa del modelo de benchmarking que se
concentra en la recolección de datos incluye tres fases:
39
INGENIERIA
TERCERA ETAPA: ANÁLISIS DE LOS DATOS SOBRE LAS BRECHAS Y LOS «FACILITADORES» DE LA PERFORMANCE:
La etapa de análisis en el proceso de benchmarking consiste en cinco fases: análisis de los datos, presentación de los datos,
análisis de las causas fundamentales, proyección de los resultados e identificación de los «facilitadores». La meta de esta etapa
es identificar los facilitadores del proceso que resulten adaptables y que son candidatos para la implantación.
40
INGENIERIA
CUARTA ETAPA: MEJORAMIENTO A TRAVÉS DE LA ADAPTACIÓN DE LOS FACILITADORES DEL PROCESO :
La etapa final en el proceso de benchmarking proporciona el curso de acción que define al benchmarking como un proceso de
administración de cambio estratégico. El propósito de esta etapa es introducir mejoramientos seleccionados dentro de la
organización, aplicando el conocimiento aprendido durante el estudio de benchmarking.
41
INGENIERIA
APLICACIÓN DEL BENCHMARKING
Muchas organizaciones usan las técnicas de Benchmarking cuando quieren implementar un cambio radical en un determinado
proceso altamente ligado a la consecución de estándares de calidad y mejores prácticas estimadas a escala global. Esto, sumado al
ritmo de las innovaciones y mejoras permanentes en los procesos tecnológicos y de servicios, condiciona que el Benchmarking se
constituya en una práctica de permanente evolución y alcances inacabados.
El Benchmarking tiene sentido si se encamina a la identificación, aprendizaje, adaptación e incorporación de las mejores prácticas
disponibles. Por tanto, podemos deducir que la utilización de la técnica del Benchmarking es adecuada cuando se trate de las
siguientes situaciones:
• Cuando tenemos la necesidad de mejorar la satisfacción de nuestros clientes a través de la mejora de determinados procesos
clave, sean de producción técnica o de atención al cliente.
• Cuando queremos o necesitamos competir a un nivel de mucha mayor exigencia en materia de calidad y/o servicio.
• Cuando nuestro nivel de madurez organizativa, estandarización de procesos y calidad técnica percibida de nuestros servicios nos
obliga a competir a escala internacional.
• Cuando el desarrollo de nuestra planificación estratégica nos obliga a establecer estándares de servicio y calidad muy superiores
a la media del mercado.
• Cuando buscamos establecer mejores prácticas en determinados procesos claves que permitan alcanzar una productividad y
rentabilidad superior.
42
INGENIERIA
• Cuando buscamos establecer mejores prácticas en determinados procesos claves que permitan alcanzar una productividad y
rentabilidad superior.
• Cuando necesitamos estar permanente informados sobre el nivel competitivo global en materia de determinado proceso o
practica de nuestro sector industrial.
• Cuando requerimos general un alto valor competitivo que rompa el estándar habitual de nuestro sector industrial.
• Cuando necesitamos obtener información de alto valor estratégico de otros competidores del mercado a nivel global para avanzar
con rapidez en un proceso de mejora y/u obtención de resultados.
• Cuando requerimos incorporar un nuevo desarrollo tecnológico emergente que de alto valor a la calidad técnica de nuestros
productos y/o servicios.
• Cuando la gestión de la organización está orientada hacia el cambio y apuesta por el desarrollo de una estrategia orientada a la
excelencia.
• Cuando la organización está ya inmersa en la innovación e implementación de ajustes a sus procesos de producción o de
servicio.
• Cuando la dinámica de la industria (sector) está cambiando a un ritmo acelerado y estos cambios afectan a la productividad y
resultados de la organización.
• Cuando se requiere un cambio importante en procesos clave, productos o servicios que permitan alcanzar y sobrepasar las
expectativas de los consumidores.
43
INGENIERIA
VENTAJAS DEL BENCHMARKING

• Identificar oportunidades de innovación a través del descubrimiento de nuevas tecnologías, ya aplicadas en su propio sector
o diferentes.
• Identificar aquellos procesos en los que existan diferencias significativas respecto al mejor del sector”, utilizándolo como
estímulo para el cambio y como instrumento de seguimiento de las mejores producidas.
• Conocer la posición relativa frente a empresas del propio sector o de otros, evitando el estancamiento y ofreciendo
diferentes alternativas.
• Conocer con suficiente anterioridad nuevas tendencias y direcciones estratégicas y, en función de estas, gestionar
adecuadamente el cambio.
• Detectar cambios y tendencias en los mercados.
• Seguimiento a relaciones y desarrollo de planes de colaboración.
DESVENTAJAS DEL BENCHMARKING
• Está de moda la aplicación del benchmarking. Esto puede crear expectativas en el personal, sin que la dirección se sienta
comprometida con los resultados.
• Puede ser necesario impartir nociones de ética y cuestiones legales que rodean al intercambio de información de trabajo
entre organizaciones, especialmente competidores.
• El benchmarking cuenta con la confianza de la compañía. Esta es la mayor resistencia a comparar de forma eficaz los
procesos de los competidores, debido a que la mayor parte de la información es confidencial
44
INGENIERIA
INFORMATICA Gestión de los niveles de servicio
El objetivo fundamental de la Gestión de los Niveles de Servicio es tratar de acotar con el cliente un marco de referencia en el que
se pueda llevar a cabo un Servicio TI con la mayor calidad posible a un coste aceptable.
- Catálogo de Servicios
- Requisitos de Nivel de Servicio (SLR Service Level Requirements)
- Acuerdo de Nivel de Servicio (SLA Service Level Agreement)
- Plan de Calidad del Servicio (SQP Service Quality Plan)
Ciclo de Gestión del Nivel de Servicio
45
INGENIERIA
Planificación
El objetivo de la planificación de un Servicio es orientarlo hacia cómo poner en marcha las actuaciones necesarias que permitan
ofrecer a nuestros clientes un servicio acorde a sus necesidades. El proceso de Planificación debe encargarse por tanto de
conocer cuáles son éstas, cómo ofrecerlas, qué capacidades tenemos, qué nivel de servicio ofrecer y cómo gestionarlas.
Todas estas cuestiones, como buena práctica en gestión, han de estar documentadas de manera que queden registrados,
utilizarse como guías y controlarse como monitorización (o medición) de cumplimiento.
Algunos de estos documentos serán de uso interno y otros serán utilizados como base de desarrollo y negociación con los
clientes.
Dentro de la Planificación por tanto sólo se utilizan una serie de documentos que se encuadran dentro de este proceso. Estos
documentos son los siguientes:
- Catálogo de Servicios
- Requisitos de Nivel de Servicio (SLR Service Level Requirements)
- Hojas de Especificación del Servicio (Specsheet)
- Plan de Calidad del Servicio (SQP Service Quality Plan)
46
INGENIERIA
Catálogo de Servicios
Documento que ha de derivar (en ciertos aspectos) de la identificación de nuestra Cartera de Servicios TI.
El objetivo de este documento es describir con mucho detalle los servicios que la empresa ofrece, con la tecnicidad suficiente y
el de manera comprensible para que el cliente pueda comprender y discernir si sus necesidades pueden ser suplidas por la
organización.
Es una herramienta que deriva de la Estrategia Empresarial, pues es un instrumento de comunicación muy potente si está bien
realizado, orientado y presentado a un posible cliente potencial (diana o general).
Por regla general un cliente no comprenderá cómo aplicar los servicios que la Organización ofrece así que es muy importante
que este documento sea un elemento sólido a la hora de comenzar cualquier tipo de negociación con el cliente ya que debe
delimitar los compromisos hasta los que la organización está dispuesta a llegar.
47
INGENIERIA
SLR o Requisitos de Nivel de Servicio
Se trata de un documento que recoge las necesidades del cliente, detallándose en la medida de lo posible para que se puedan
desarrollar los siguientes documentos que actuarán como guías que describirán las soluciones que la Empresa ofrece.
Suele realizarse tras el contacto con el cliente, que debe haber conocido nuestros servicios previamente a través de nuestro
Catálogo de Servicios. Es por eso que este elemento incorporará los resultados de las negociaciones mantenidas de cara a
describir los siguientes conceptos:
• La funcionalidad y características del servicio.

• El nivel de calidad del servicio.
• La interacción del servicio con su infraestructura TI.
• La planificación de la implantación del servicio.
• La disponibilidad del servicio.
• La continuidad del servicio.
• La integración del servicio con otros servicios del cliente.
• La escalabilidad del servicio.
48
INGENIERIA
Plan de Calidad del Servicio o Service Quality Plan (SQP)
Un Plan de Calidad es un documento asociado a una serie de procesos cuyo objetivo es regir las actuaciones que se llevarán a
cabo para el desarrollo del servicio al cliente. Es por tanto un documento de régimen interno.
Para definir los niveles de calidad que se quieren ofrecer, estos han de estar acordes a las necesidades del cliente. Así se
determinará en el documento:
1. Una planificación con objetivos para cada servicio.

2. Una estimación de recursos necesarios.
3. Unos Indicadores clave de rendimiento asociados a objetivos.
4. Una documentación que permita evaluar a los proveedores y controlar su rendimiento.
Este será el documento que debe conseguir una perfecta cohesión entre los recursos (personales y tecnológicos) disponibles y la
ejecución o desarrollo del servicio y sus operaciones, de manera que en un plazo estimado se cumplan los objetivos planificados
y se pueda suministrar perfectamente el servicio al cliente.
49
INGENIERIA
Realización
Desarrollo, implementación o realización. Diferentes términos que definen un objetivo que no es otro que el trabajo necesario
para la puesta en marcha del Servicio para el cliente basado en la documentación realizada en la planificación anterior.
Para comenzar a implementar el servicio, es necesario que se haya acordado formalmente con el cliente la planificación previa.
El desarrollo posterior vendrá avalado por tanto por unas decisiones que soporten todas las actuaciones que han de llevarse a
cabo, validadas por el cliente, elemento no excluyente para que la nueva documentación también tenga que ser acordada y
validada por este.
La documentación que servirá de guía para este proceso es la siguiente:
1. Acuerdo de Nivel de Servicio (Service Level Agreement – SLAs)

2. Acuerdos de Nivel de Operación (Operation Level Agreement – OLAs)
3. Contratos de Soporte (Underpinning Contract - UCs)
50
INGENIERIA
Verificación Validación
Seguimiento o monitorización. El objetivo que persigue la monitorización de las actuaciones es mantener o mejorar el nivel de
calidad del Servicio ofertado mediante la medición de indicadores de rendimiento.
La manera de realizar el seguimiento de los procesos viene reflejada previamente por la documentación generada,
principalmente con el SQP, aunque también de los SLRs y OLAs ya que no sólo hay que medir aspectos técnicos, sino también de
satisfacción de los usuarios, rendimiento de los procesos, así como optimización de estos y por tanto su rentabilidad. La gestión
de incidencias, capacidad, disponibilidad, problemas y preguntas más frecuentes realizadas en el Centro de Servicios – “Service
Desk” (aspectos aún no desarrollados en el Manual) serán claves para establecer unos indicadores de rendimiento que faciliten
una monitorización adecuada a cada tipo de Servicio TI ofrecido.
La monitorización se refleja en informes. Estos informes serán los que han de transformar los datos en información disponible
para la correcta gestión y toma de decisiones en el Servicio. Los informes de rendimiento deben cubrir por tanto aspectos clave
tales como:
- Incidencias/problemas detectados: cumplimiento de los SLAs.

- Quejas y reclamaciones de los usuarios.
- Disponibilidad del servicio.
- Tiempos de respuesta.
- Baremos de Capacidad.
- Control de los Proveedores Externos: cumplimiento de los OLAs.
51
INGENIERIA
Mejora
Revisión o mejora. El objetivo de este proceso es mantener la revisión constante de la calidad del Servicio.
Todo proceso de mejora continua ha de tener un marco de referencia. En este caso se trata de realizar una revisión constante de
todos los procesos llevados a cabo desde la firma del Acuerdo de Nivel de Servicio (SLA) e incluso el Catálogo de Servicio, ya que
este ha podido quedar obsoleto durante el transcurso de la ejecución de este Servicio.
El proceso de revisión del Servicio se implementa sobre un documento, que ha de reunir, tras el análisis de los datos de los
indicadores, todas las actuaciones a realizar para mejorar el servicio ofrecido al cliente. Este documento es el Programa de
Mejora del Servicio.
Este documento ha de reunir todos los datos posibles sobre el proceso de prestación del Servicio, de manera que se analicen
desde aspectos puramente tecnológicos a los propios de los recursos humanos, la infraestructura TI puesta en servicio, los
proveedores, las incidencias y la satisfacción del cliente, serían sólo algunos ejemplos.
52
INGENIERIA
INFORMATICA Gestión de la capacidad
El objetivo de La gestión de la capacidad es procurar que el servicio disponga la capacidad de recursos (almacenamiento,
rendimiento y eficiencia) necesaria y en el momento en el que se demande. Además debe velar para que esta gestión proporcione
una contención del gasto por ineficiencias en la capacidad y sobre todo que esta capacidad esté alineada tanto con los requisitos
actuales y futuros del cliente, como con la estrategia de la organización).
Para que se cumpla este objetivo la Gestión de la Capacidad debe velar por:
- Monitorizar el Rendimiento de la Infraestructura.

- Controlar y analizar el Alcance de la Infraestructura actual, para determinar qué soporte puede ofrecer a nuevos servicios o
modificaciones de software.
- Modelado o simulación para la determinación de los requisitos y necesidades de capacidad.
- Planificar a través de un Plan de Capacidad las condiciones futuras.
Sin una gestión de la capacidad correctamente puesta en marcha, pueden realizarse compras indebidas, que conlleven un gasto
mayor del necesario; puede ocurrir una sobreestimación del alcance de la infraestructura actual, por lo que el Servicio puede
verse afectado, y por tanto ocurrir un incumplimiento de contrato.
53
INGENIERIA
INFORMATICA Gestión de la capacidad
Los beneficios de disponer de una Gestión de la Capacidad para la organización serán, entre otros, los siguientes:
- Reducir riesgos de disminución de la calidad del servicio gracias a un control de los recursos y un seguimiento del
rendimiento.
- Eficacia en la respuesta y flexibilidad para responder a nuevas necesidades.
- Reducción de costes y control del gasto.
Planificación
INFORMACIÓN DE ENTRADA AL PROCESO

Estratégica
INFORMACIÓN DE SALIDA DEL PROCESO

(Organización, Infraestructura, Servicio)
- Planes de Empresa/Requisitos del de la
Plan de
GESTIÓN DE LA CAPACIDAD
Capacidad
Organización
Negocio
- Expansión de la Organización Informes de
- Programas de Cambios Vigilancia Informes de
Previsión de
-
Tecnológica
Planes Financieros Gastos y
- Presupuestos Costes
Requisitos del (Gestión
Cliente Financiera)
Informes de Informes de
Incidencias Rendimiento
- Tendencia del mercado más comunes
- Tendencia de la Organización
- Previsión de Las Líneas de Negocio
- Tipo de Organización futura
- Tamaño
- Volumen de capacidad / volumen de negocio
- Requisitos 54
INGENIERIA
INFORMATICA Gestión de la Continuidad
El objetivo de la Gestión de la Continuidad es garantizar que la infraestructura y los servicios más importantes de la
Organización puedan superar la ocurrencia de un desastre en el menor tiempo posible, restaurando la normalidad.
Un desastre puede ser natural (terremotos, inundaciones, tormentas, etc.), provocado por el ser humano (incendios,
inundaciones, etc.) o informáticos (virus, ataques globales, hackers, etc.).
El proceso de Gestión de la Continuidad se despliega sobre dos formas de actuar:
- La preventiva: se trata de procedimientos que tratan de impedir la ocurrencia de desastres (normalmente informáticos o
humanos).
- La activa: es la que pone en marcha el servicio tras la ocurrencia de un desastre.
Para disponer de este tipo de actuaciones, previamente la Organización debe poner en marcha un proceso de Gestión de la
Continuidad que contemple al menos las siguientes actividades:
55
INGENIERIA
INFORMATICA
- No hay que confundir Gestión de la Continuidad

del Servicio con Gestión de Continuidad del
Negocio (Business Continuity Management), ya
que esta segunda engloba a la primera. La Gestión
de la Continuidad del Servicio debe estar
integrada y ser coherente con la Estrategia de
Continuidad del Negocio, y así, este alcance, debe
reflejarse en su política.
- La definición del alcance para la política es un

aspecto importante ya que desde ahí se
construirán los futuros cambios, la formación de
las personas implicadas en la continuidad, los
recursos necesarios y la financiación derivada a la
Gestión de la Continuidad.
- La política será el reflejo de estas decisiones que

habrá de hacerse pública dentro de la
organización.
56
INGENIERIA
INFORMATICA
- Es necesario determinar cuánto costaría a la empresa la

interrupción de algún servicio. Distinguir qué tipos de
servicios son de más valor para la Organización es una
buena práctica a tener en
- cuenta de manera que se pueda determinar los
presupuestos dedicados a prevención y restauración.
- Para definir el servicio y las acciones a llevar a cabo se
debería evaluar:
• Pérdida de imagen de la empresa por
interrupción
• Cuota de mercado
• Rentabilidad por interrupción del servicio
• Compromisos del SLA
• Tiempo de Recuperación
• Dificultad de Recuperación
• Coste de Recuperación
• Etc.
57
INGENIERIA
INFORMATICA
- De cara a una correcta evaluación del impacto del negocio

y de una rápida restauración de los servicios, es necesario
realizar una identificación de los activos más importantes
de los servicios definidos anteriormente como de más
valor para la Organización.
- Esta identificación debe ir encaminada a definir recursos,
componentes, personas, software, localización, etcétera,
de estos servicios, pormenorizando por tanto en el futuro
sobre qué y dónde actuar de cara a optimizar los
esfuerzos.
58
INGENIERIA
INFORMATICA
- El objetivo de la Evaluación de Riesgos es determinar a

qué tipo de riesgos están expuestos los servicios.
- Para detectarlos es necesario conocer muy
profundamente el Servicio, para lo que la información de
entrada de la identificación previa de activos es muy
importante. Así mismo, un análisis de estos activos,
conociendo sus amenazas y vulnerabilidades posibles (y
potenciales) dará fuerza a esta evaluación para comenzar
a plantear medidas que aseguren la Continuidad del
Servicio. Estas medidas pueden ser de prevención y de
recuperación, y serán adoptadas según la posibilidad que
se estime tienen de ocurrir desastres o la potencialidad de
riesgos, unida a su coste en esfuerzo y económico.
59
INGENIERIA
INFORMATICA
- A partir de la evaluación de riesgos se han de establecer las

Estrategias de Prevención o de Recuperación. La suma de ambas
será la Estrategia de Continuidad de los Servicios de la
Organización.
- El equilibrio de ambas se dirime por cuestiones financieras. Los
planes de Prevención suelen ser más caros que los de
Recuperación, por lo que según la Evaluación de Riesgos y la
Gestión Financiera la Organización se decantará por cómo
Gestionar la Continuidad de sus Servicios.
- Planes de Prevención:
- Los planes de prevención se relacionan con otros aspectos de
gestión de la organización, como la Gestión de la Continuidad
del Negocio y la Gestión de la Seguridad. En ambos casos las
medidas que se toman son comunes con la Gestión de la
Continuidad del Servicio.
- Las acciones a llevar a cabo para plantear un Plan de Prevención
se derivan del refuerzo de los aspectos que impiden el acceso a
la infraestructura.
- Planes de Recuperación:
- Dependiendo del nivel de importancia del Servicio (de cara al
cliente) a recuperar y de su importancia económica para la
Organización, se pueden establecer diferentes soluciones que
tienen también un coste creciente, ya que requieren
mantenimiento de infraestructuras de replicación continua,
alojamientos en otros lugares, equipos de mantenimiento y
otros servicios contratados.
60
INGENIERIA
INFORMATICA
- El despliegue de la estrategia requiere hacer llegar a toda

la organización, que tenga implicación con el servicio, la
documentación e información definida en los Planes de
Prevención y Recuperación, detallada en los siguientes
procesos:
- Plan de Respuesta ante Emergencias
- Plan de Recuperación
- Plan de Evaluación
61
INGENIERIA
INFORMATICA
- El objetivo de la mejora del proceso es mantener viva dentro de la

Organización (y más concretamente en las personas de las que
depende este proceso) la Gestión de la Continuidad del Servicio.
- La mejora continua, como en otros procesos ITIL se realiza a través
de dos fases principales:
- Formación: una formación continua en Continuidad es una
formación en nuevos riesgos, nuevas soluciones, vigilancia
tecnológica aplicable, gestión de conflictos, gestión del
tiempo, etc. Es un aspecto totalmente diferenciador de este
proceso.
Una vez el personal encargado dispone de las herramientas
necesarias debe formar al personal no encargado de la
Infraestructura e incluso al que no tiene conocimientos o
relación con los aspectos informáticos del Servicio para
garantizar la preparación durante los procesos de
Recuperación.
- Seguimiento: informes de seguimiento que arrojen
información de consecución de objetivos.
- Auditorías: al igual que en la Gestión de la Seguridad, las
auditorías, tanto internas como externas aportan algo más de
confiabilidad al Proceso definido.
62
INGENIERIA
INFORMATICA Construir, adquirir e implementar : Gestionar los programas
Descripción
Gestionar todos los programas del portafolio de inversión, de conformidad con la estrategia de la empresa y de forma coordinada,
según un enfoque de gestión de programas estándar. Iniciar, planificar, controlar y ejecutar programas, y monitorizar el valor esperado
del programa.
Propósito
Obtener el valor de negocio deseado y reducir el riesgo de retrasos, costes y erosión de valor inesperados. Para ello, mejorar las
comunicaciones y la participación del negocio y usuarios finales, garantizar el valor y la calidad de los entregables del programa y
realizar un seguimiento de los proyectos dentro de los programas, y maximizar la contribución del programa al portafolio de
inversiones.
Práctica Descripción
Mantener un enfoque Mantener un enfoque estándar para la gestión de programas que permita la revisión del gobierno y la
estándar en la gestión de gestión, la toma de decisiones y las actividades de gestión de la entrega. Estas actividades deben
programas. centrarse de consistentemente en el valor y los objetivos de la empresa (es decir, los requisitos, riesgo,
costes, calendario y objetivos de calidad).
Iniciar un programa. Iniciar un programa para confirmar los beneficios esperados y obtener autorización para proceder. Esto
incluye acordar el patrocinio, confirmar el mandato del programa mediante la aprobación del caso de
negocio conceptual, asignar un equipo de dirección o un comité , cuyas tareas sean elaborar un resumen
del programa, revisar y actualizar el caso de negocio, desarrollar un plan de consecución de beneficios y
obtener la aprobación de los patrocinadores antes de proceder.
63
INGENIERIA
Gestionar el compromiso de Gestionar el compromiso de las partes interesadas para asegurar un intercambio activo de información
las partes interesadas. precisa, consistente y oportuna para todas las partes interesadas relevantes. Esto incluye planificar,
identificar e involucrar a las partes interesadas y gestionar sus expectativa s.
Desarrollar y mantener el Formular un programa para sentar las bases iniciales. Posicionarlo para la ejecución exitosa mediante la
plan del programa. formalización del alcance del trabajo y la identificación de los entregables que satisfarán las metas y
producirán valor.
Mantener y actualizar el plan del programa y el caso de negocio durante todo el ciclo de vida económico
completo del mismo, para asegurar su alineación con los objetivos estratégicos, reflejar el estado actual y
el conocimiento adquirido hasta la fecha.
Lanzar y ejecutar el Poner en marcha el programa para adquirir y dirigir los recursos necesarios y así lograr las metas y
programa. beneficios del programa tal y como está definido en el plan. De acuerdo con los criterios de revisión de
cambios de fase (stage-gate) o publicación, prepararse para la iteración de cambio de fase o revisiones
de la publicación a fin de informar sobre el avance y tener el caso para financiar hasta la siguiente revisión
de cambio de fase o publicación.
Monitorizar, controlar y Monitorizar y controlar el rendimiento en comparación con el plan durante todo el ciclo de vida económico
reportar sobre los resultados de la inversión, cubriendo la entrega de soluciones a nivel del programa y el valor/resultado a nivel de la
del programa. empresa. Reportar el rendimiento al comité de dirección del programa y a los patrocinadores
Gestionar la calidad del Preparar y ejecutar un plan de gestión de la calidad, procesos y prácticas, alineado con el sistema de
programa. gestión de calidad (SGC). Describe el enfoque de calidad hacia el programa y cómo se implementará.
Todas las partes afectadas deberían revisar y aceptar formalmente el plan e incorporarlo al plan de
programa integrado.
64
INGENIERIA
Gestionar el riesgo del Eliminar o minimizar el riesgo específico asociado a los programas mediante un proceso sistemático de
programa. planificación, identificación, análisis, respuesta, monitorización y control de las áreas o eventos que,
potencialmente, pueden ocasionar un cambio no deseado. Definir y registrar cualquier riesgo al que se
enfrenta la gestión del programa.
Cerrar un programa. Retirar el programa del portafolio de inversiones activas cuando exista el acuerdo de que se ha alcanzado
el valor deseado o cuando esté claro que no se alcanzará dentro de los criterios de valor establecidos
para el programa
65
INGENIERIA
INFORMATICA Construir, adquirir e implementar : Gestionar PROYECTOS
Descripción
Gestionar todos los proyectos que se inician en la empresa, alineados con la estrategia de la empresa y de forma coordinada, con
base en una estrategia de gestión de proyectos estándar. Iniciar, planificar, controlar y ejecutar proyectos, y concluir con una revisión
post-implementación.
Propósito
Lograr los resultados definidos en el proyecto y reducir el riesgo de retrasos inesperados, costes y erosión del valor mediante la
mejora de las comunicaciones y la participación del negocio y de los usuarios finales. Garantizar el valor y la calidad de los
entregables del proyecto y maximizar su contribución a los programas definidos y al portafolio de inversiones.
Mantener un enfoque Mantener una estrategia estándar para la gestión de proyectos que permita la revisión del gobierno y
estándar en la gestión de gestión, la toma de decisiones y las actividades de gestión de entrega. Estas actividades deberían
proyectos. centrarse consistentemente en el valor y los objetivos del negocio (es decir, los requisitos, riesgo, costes,
calendario y objetivos de calidad).
Establecer e iniciar un Definir y documentar la naturaleza y alcance del proyecto con el objetivo de confirmar y desarrollar un
proyecto entendimiento común del alcance del proyecto entre las partes interesadas. Los patrocinadores del
proyecto deben aprobar formalmente la definición.
66
INGENIERIA
Gestionar la participación de Gestionar la participación de las partes interesadas para asegurar un intercambio activo de información
las partes interesadas precisa, consistente y oportuna que llegue a todas las partes interesadas relevantes. Esto incluye
planificar, identificar e involucrar a las partes interesadas y gestionar sus expectativas.
Desarrollar y mantener el Establecer y mantener un plan de proyecto formal, integrado y aprobado (que cubra los recursos del
plan del proyecto. negocio y de TI) para guiar la ejecución y el control del proyecto durante su ciclo de vida. El alcance de los
proyectos debe definirse claramente y vincularse al desarrollo o mejora de las capacidades del negocio.
Gestionar la calidad del Preparar y ejecutar un plan de gestión de la calidad, procesos y prácticas, alineadas con el sistema de
proyecto gestión de calidad (SGC). Describir el enfoque de calidad del proyecto y cómo se implementará. El plan
debería evaluarse y aceptarse formalmente por todas las partes afectadas e incorporarse al plan
integrado del proyecto.
Gestionar el riesgo del Eliminar o minimizar el riesgo específico asociado a los proyectos mediante un proceso sistemático de
proyecto. planificación, identificación, análisis, respuesta, monitorización y control de las áreas o eventos que,
potencialmente, pueden ocasionar un cambio no deseado. Definir y registrar cualquier riesgo al que se
enfrenta la gestión del proyecto
Supervisar y controlar los Medir el rendimiento del proyecto en comparación con los criterios clave, como son el calendario, la
proyectos. calidad, los costes y el riesgo. Identificar cualquier desviación de los objetivos esperados. Evaluar el
impacto de las desviaciones en el proyecto y en el programa general e informar los resultados a las partes
interesadas.
67
INGENIERIA
Gestionar los recursos del Gestionar los paquetes de trabajos asociados al proyecto mediante el establecimiento de requisitos
proyecto y los paquetes de formales para autorizarlos y aceptarlos y, asignar y coordinar los recursos de negocio y de TI apropiados.
trabajo.
Cerrar un proyecto o Al final de cada proyecto, liberación o iteración, requerir a las partes interesadas del proyecto para que
iteración. determinen si el mismo ha dado los resultados previstos en cuanto a las capacidades y ha contribuido
como se esperaba a los beneficios del programa. Identificar y comunicar las actividades pendientes
necesarias para lograr los resultados planeados del proyecto y/o los beneficios del programa.
Identificar y documentar las lecciones aprendidas para futuros proyectos, liberaciones iteraciones y
programas.
68
INGENIERIA
INFORMATICA Dominios
El MAE está compuesto por siete dominios que las entidades deben considerar para realizar los ejercicios de AE completos para alinear las
necesidades del negocio con el uso adecuado de las TIC, aquellas entidades que por el tiempo o por los recursos de los que dispone no tiene la
capacidad de abordar los siete dominios de forma completa, deben considerar acotar el alcance de cada dominio disminuyendo el nivel de
profundidad vertical, el nivel de detalle con el que abordan cada dominio y el alcance horizontal, es decir, la cantidad de procesos y áreas que van a
ser impactadas en cada ejercicio de Arquitectura Empresarial.
Los dominios del MAE son: Dominio de Planeación de la Arquitectura, Dominio de Arquitectura Misional, Dominio de Arquitectura de Información,
Dominio de Arquitectura de Sistemas de Información, Dominio de Infraestructura Tecnológica, Dominio de Arquitectura de Seguridad y Dominio de
Uso y Apropiación de la Arquitectura. En la siguiente imagen se pueden observar todos los dominios del MAE.
69
INGENIERIA
INFORMATICA Dominios Dominio de planeación de la arquitectura
- Contiene los elementos para orientar a las entidades
en la planeación, estructuración y priorización de los Dominio de Arquitectura Misional
Dominio de uso y apropiación de la ejercicios de arquitectura empresarial a partir de las Contiene los elementos para orientar a las entidades en la
arquitectura necesidades de los interesados. definición de la arquitectura misional o de negocio a partir
El dominio de uso y apropiación de la de la documentación del modelo de intención y elmodelo
arquitectura contiene los elementos operativo de la entidad e identificación.
para orientar a las entidades a
gestionar la gestión del cambio y de los Dominio de arquitectura de seguridad
grupos de interés, para desarrollar una El dominio de arquitectura de seguridad tiene como los
cultura o comportamientos culturales elementos para orientar a las entidades en la
que faciliten la adopción y uso de las identificación y diseño de los controles necesarios para
arquitecturas objetivo definidas asi asegurar la protección de la información en la
como en la construcción de la arquitectura misional, arquitectura de información, la
capacidad de arquitectura empresarial arquitectura de sistemas de información y la arquitectura
en la entidad, lo que es esencial para de infraestructura tecnológica.
garantizar el resultado de la
implementación del modelo de
arquitectura empresarial.
Dominio de Arquitectura de Sistemas de Información
Dominio de arquitectura de infraestructura tecnológica Contiene los elementos para orientar a las entidades en la
Contiene los elementos para orientar a las entidades en la definición de la arquitectura de aplicaciones que define
Dominio de arquitectura de información los componentes de los sistemas, las interacciones entre
descripción de la arquitectura de infraestructura de TI la
Contiene los elementos para orientar a las entidades en la estos y la relación con las arquitecturas misional, de
cual define todos los elementos de infraestructura de TI
definición de la arquitectura de información que define la información y de infraestructura de TI..
que soportan la operación de la institución, entre algunos
estructura con la cual está representada y almacenada la
de los elementos de esta arquitectura se encuentran la
información y los datos de una organización, lo mismo
plataforma hardware, las interfaces de comunicación
que los servicios y los flujos de información que soportan
entre los elementos de infraestrcutura y los servicios de
los procesos de la entidad de la arquitectura misional.
nube entre otros. 70
INGENIERIA
INFORMATICA Dominios
71
INGENIERIA
INFORMATICA
72

Parte 03 - Arquitectura Tecnológica Empresarial

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Parte 03 - Arquitectura Tecnológica Empresarial

Cargado por

Copyright:

Formatos disponibles

INGENIERIA

CAMBIOS CADA VEZ MAS RAPIDOS

MERCADOS MAS COMPETITIVOS Y DIFERENCIADOS

ECONOMIA DE LA DEMANDA (DESDE LA OFERTA)

LAS EMPRESAS SON SISTEMAS COMPLEJOS

Proviene del Griego

Refleja la necesidad de dirigir la forma en que se construye la empresa

La empresa esta compuesta de

Es decir debemos ver la empresa en forma Holística

Y desde distintos Ángulos

Visión Tradicional Visión Arquitectónica

TOGAF es un marco de referencia de arquitectura.

¿Qué es Arquitectura en el Contexto de TOGAF?

¿Qué clases de Arquitectura cubre TOGAF?

Tipo de Arquitectura Descripción

TOGAF refleja la estructura y el contenido de la Capacidad Arquitectónica dentro de una empresa.

1. Método de Desarrollo de la Arquitectura (ADM por sus siglas en inglés)

3. Marco de Referencia del Contenido Arquitectónico

Desafíos de la AE TOGAF Método de

SOA TIPCO Arquitectura del

El ADM apoya el concepto de iteración en tres niveles:

La Fase Preliminar prepara a una organización para emprender proyectos de Arquitectura

Profundidad ¿Qué nivel de detalle debería alcanzar el esfuerzo de

•Proceso de adquisición y desarrollo de servicios.

PRIMERA ETAPA: PLANTEMIENTO DEL PROYECTO DE BENCHMARKING :

SEGUNDA ETAPA:RECOPILACIÓN DE LOS DATOS NECESARIOS

CUARTA ETAPA: MEJORAMIENTO A TRAVÉS DE LA ADAPTACIÓN DE LOS FACILITADORES DEL PROCESO :

APLICACIÓN DEL BENCHMARKING

VENTAJAS DEL BENCHMARKING

Ciclo de Gestión del Nivel de Servicio

SLR o Requisitos de Nivel de Servicio

• La funcionalidad y características del servicio.

Plan de Calidad del Servicio o Service Quality Plan (SQP)

1. Una planificación con objetivos para cada servicio.

La documentación que servirá de guía para este proceso es la siguiente:

1. Acuerdo de Nivel de Servicio (Service Level Agreement – SLAs)

- Incidencias/problemas detectados: cumplimiento de los SLAs.

- Monitorizar el Rendimiento de la Infraestructura.

INFORMACIÓN DE ENTRADA AL PROCESO

INFORMACIÓN DE SALIDA DEL PROCESO

El proceso de Gestión de la Continuidad se despliega sobre dos formas de actuar:

- No hay que confundir Gestión de la Continuidad

- La definición del alcance para la política es un

- La política será el reflejo de estas decisiones que

- Es necesario determinar cuánto costaría a la empresa la

- De cara a una correcta evaluación del impacto del negocio

- El objetivo de la Evaluación de Riesgos es determinar a

- A partir de la evaluación de riesgos se han de establecer las

- El despliegue de la estrategia requiere hacer llegar a toda

- El objetivo de la mejora del proceso es mantener viva dentro de la

También podría gustarte