GUÍA

Informática
Modalidad Abierta y a Distancia
Gestión de Tecnologías de Información

Guía Didáctica
4 créditos
Ciclo Titulación
9 Informática
La Universidad Católica de Loja
Área Técnica
Departamento de Ciencias de la Computación y Electrónica
Sección Ingeniería del Software y Gestión de Tecnologías de la
Información
Gestión de Tecnologías de
Información
Texto-guía
4 créditos
Titulación Ciclo
Informática IX
Autores:
Armando Augusto Cabrera Silva
Pablo Alejandro Quezada Sarmiento
Asesoría virtual:
www.utpl.edu.ec
GESTIÓN DE TECNOLOGÍAS DE INFORMACIÓN
Texto-guía
Armando Augusto Cabrera Silva
Pablo Alejandro Quezada Sarmiento
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

CC Ecuador 3.0 By NC ND
Maquetación y Diseño digital

EDILOJA Cía. Ltda.
Telefax: 593-7-2611418
San Cayetano Alto s/n
www.ediloja.com.ec
edilojainfo@ediloja.com.ec
Loja-Ecuador
Primera edición
ISBN físico -978-9942-08-523-8
ISBN digital -978-9942-04-425-9
Esta versión impresa y digital ha sido acreditada bajo la licencia Creative Commons Ecuador 3.0 de reconocimiento -no comercial- sin obras derivadas;
la cual permite copiar, distribuir y comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice con fines comerciales ni se
realicen obras derivadas. http://www.creativecommons.org/licences/by-nc-nd/3.0/ec/
16 de Enero, 2014
2. Índice
2. Índice ............................................................................................................................................................ 4
3. Introducción............................................................................................................................................. 6
4. Bibliografía .............................................................................................................................................. 8
4.1. Básica .......................................................................................................................................... 8

4.2. Complementaria ..................................................................................................................... 8
5. Orientaciones generales para el estudio............................................................................. 10
6. Proceso de enseñanza-aprendizaje para el logro de competencias ................ 12
PRIMER BIMESTRE
6.1. Competencias genéricas ....................................................................................................... 12

6.2. Planificación para el trabajo del alumno ........................................................................ 12
6.3. Sistema de evaluación de la asignatura (primero y segundo bimestre) .............. 15
6.4. Orientaciones específicas para el aprendizaje por competencias ........................... 16
UNIDAD 1. GESTIÓN DE TECNOLOGÍAS DE INFORMACIÓN, ARQUITECTURA EMPRESARIAL

(AE), ESTRUCTURA Y CULTURA EMPRESARIAL ............................................................................... 16
1.1. Introducción a Gestión de Tecnologías de Información (GTI). .................................. 16

1.2. Visión general de la Arquitectura Empresarial .............................................................. 17
1.3. Federal Enterprise Architecture .......................................................................................... 19
1.4. Zachman Framework ............................................................................................................. 19
1.5. TOGAF.......................................................................................................................................... 20
1.6. ¿Qué es la arquitectura de la empresa? ........................................................................... 22
1.7. El enfoque ................................................................................................................................. 26
1.8. Las actividades arquitectónicas ......................................................................................... 27
1.9. La Arquitectura Empresarial como un Programa de Gestión.................................... 28
1.10. La arquitectura como un método de análisis y diseño ............................................... 30
1.11. El Repositorio de AE ............................................................................................................... 37
Autoevaluación 1 ................................................................................................................................ 38
UNIDAD 2. IMPLEMENTACIÓN DE LA METODOLOGÍA ARQUITECTÓNICA.................................. 40
2.1. Metodología de Implementación ...................................................................................... 41

Autoevaluación 2 ................................................................................................................................ 49
UNIDAD 3. COMPONENTES Y ARTEFACTOS ARQUITECTÓNICOS .................................................. 51
3.1. Componentes arquitectónicos: Nivel Objetivos e Iniciativas .................................... 53

3.2. Plan de Comercio /Gobierno Electrónico ......................................................................... 56
3.3. Componentes Arquitectónicos: Nivel de Productos y Servicios ............................... 57
3.4. Componentes Arquitectónicos: Nivel de Datos e Información ................................. 58
3.5. Componentes Arquitectónicos: Nivel de sistemas y aplicaciones ........................... 60
3.6. Componentes Arquitectónicos: Nivel Redes e Infraestructura ................................. 64
Autoevaluación 3 ................................................................................................................................ 68
SEGUNDO BIMESTRE
6.5. Planificación para el trabajo del alumno. ....................................................................... 70

6.6. Orientaciones específicas para el aprendizaje por competencias ........................... 73
UNIDAD 4. DESARROLLO DE LA VISTA ARQUITECTÓNICA ACTUAL............................................. 73
4.1. Componentes arquitectónicos: en el Nivel de Objetivos e Iniciativas

estratégicas ............................................................................................................................... 74
4.2. Metas estratégicas .................................................................................................................. 75
4.3. Medidas de Desempeño ....................................................................................................... 75
4.4. Componentes Arquitectónicos: Nivel de Productos y Servicios ............................... 76
4.5. Planes de Gestión del Proyecto .......................................................................................... 78
4.6. Componentes Arquitectónicos: Nivel de Datos e Información ................................. 80
4.7. Componentes Arquitectónicos: Nivel de sistemas y aplicaciones ........................... 84
4.8. Componentes Arquitectónicos: Nivel Redes e Infraestructura ................................. 87
Autoevaluación 4 ................................................................................................................................ 90
UNIDAD 5. DESARROLLO DE LA VISTA ARQUITECTÓNICA FUTURA ............................................ 92
5.1. El desarrollo de escenarios CONOPS .................................................................................. 93

5.2. Actualización de las vistas arquitectónicas futuras - Control de Versión .............. 96
5.3. Artefactos arquitectónicos del Nivel Estratégico de AE – Vista de Futuro............ 96
5.4. Artefactos arquitectónicos del Nivel de Negocios - Vista de Futuro ....................... 98
5.5. Artefactos arquitectónicos en el nivel de Información – Vista Futura .................. 99
5.6. Artefactos arquitectónicos en el Nivel Sistemas / Servicios - Vista de Futuro..... 101
5.7. Artefactos arquitectónicos en el Nivel de Infraestructura. Vista Futura................ 102
Autoevaluación 5 ................................................................................................................................ 104
UNIDAD 6. DESARROLLO DE UN PLAN DE GESTIÓN DE ARQUITECTURA EMPRESARIAL ....... 106
6.1. Gestión del Programa Arquitectónico .............................................................................. 106

6.2. Resumen de la arquitectura actual ................................................................................... 109
6.3. Resumen de la Arquitectura Futura .................................................................................. 113
6.4. Glosario y Referencias ........................................................................................................... 116
Autoevaluación 6 ................................................................................................................................ 117
7. Solucionario ............................................................................................................................................. 119
8. Anexos.......................................................................................................................................................... 125
Texto-guía: Gestión de Tecnologías de Información PRELIMINARES
3. Introducción
El componente educativo de Gestión de Tecnologías de Información es un componente troncal que se

imparte en el noveno ciclo en la titulación de Ingeniería en Informática del Departamento de Ciencias
de la Computación y Electrónica, y tiene una valoración de 4 créditos académicos.
A lo largo del sus estudios ha tenido la oportunidad de estudiar varios componentes educativos de
la línea de Gestión de TI, donde básicamente desarrolló competencias para identificar y describir
requerimientos empresariales para gestionar los recursos de TI y organizar las actividades sin seguir un
enfoque arquitectónico, sin embargo este aprendizaje aunque es muy importante, resulta insuficiente
para llevar un proyecto en la vida profesional, lo que falta es cómo gestionar proyectos de transformación
empresarial a través de un plan de implementación que considere el levantamiento del estado actual de
funcionamiento y su proyección hacia estado futuro deseado tomando en consideración la alineación
estrategia del negocio y las tecnología de apoyo; el aporte de otras asignaturas como Ingeniería de
Software arquitectura de aplicaciones, gestión de proyectos y varias de la línea de programación
configuran junto con la presente asignatura un conjunto de competencias profesionales de gran valía
en el ámbito laboral.
El componente educativo se encuentra dividida en dos bimestres con tres unidades cada uno. En la
Unidad 1, se realiza un revisión del enfoque de la Arquitectura Empresarial en donde se analizan los
principales marcos arquitectónicos y se hace una introducción a la gestión empresarial a través de marco
de trabajo EA3 mediante la descripción de sus diferentes componentes, a más de un caso de estudio para
fundamentar la temática.
En la Unidad 2 se describe el proceso de implementación de la metodología arquitectónica, que es un

procedimiento detallado para el establecimiento, mantenimiento y utilización del marco arquitectónico
y el enfoque de la documentación. Identificar el enfoque metodológico es el primer paso para coordinar
la estrategia de documentación. El valor que tiene la adopción de la metodología es reducir el riesgo de
crear un programa y/o documentación inefectiva.
La Unidad 3 define y describe los componentes y artefactos que usted deberá tomar en cuenta en
la implementación de un programa de arquitectura empresarial. Los componentes arquitectónicos
son elementos reemplazables dentro del marco, los mismos que van y vienen con los cambios en la
estrategia, servicios de negocio y nuevos diseños para los recursos relacionados con los flujos de
información, aplicaciones, redes y otras infraestructuras. Se proporcionan descripciones (ejemplo) de
los componentes, en cada nivel de la estructura arquitectónica.
En el segundo bimestre iniciamos con la unidad 4 que cubre el desarrollo de la Vista Arquitectónica
Actual, en el contexto de un marco de documentación y una metodología de implementación. La vista
arquitectónica actual es importante para una empresa ya que en estas se establecen o comprueban qué
recursos (incluyendo TI) se utilizan en las líneas de negocio para apoyar la consecución de los objetivos
estratégicos.
En esta unidad trataremos el desarrollo de las vistas arquitectónicas futuras, en el contexto de un marco
de documentación y una metodología de implementación. Las Vistas Futuras son importantes para la
empresa, debido a que capturan uno o más posibles escenarios operativos del negocio y la tecnología,
que apoyan a la planificación y la toma de decisiones.
6 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

Culminamos con la Unidad 6, que describe el desarrollo de un Plan de Gestión Arquitectónico, que es el
documento que le ayudará a describir cómo la empresa se encargará de la transición de sus procesos y
recursos actuales y que se necesitarán en el futuro.
Finalmente, le deseamos el mejor de los éxitos en el desarrollo de la presente asignatura y le recordamos

que no está solo en su estudio, que puede contar con su tutor y le invitamos a aprovechar la mayor
cantidad de materiales disponibles e incluso los recursos en línea.

4. Bibliografía
4.1. Básica
• Cabrera, A & Quezada, P; (2013 Julio). Gestión de Tecnologías de la Información. Loja: Ecuador:
EdiLoja.
El texto guía lo orientará al estudio de los temas propuestos en primer y segundo bimestre. El
texto guía es la principal herramienta de estudio para poder llevar el componente educativo con
éxito, ya que en ella encontrará los temas a estudiar así como casos prácticos a resolver.
4.2. Complementaria
• Scott; A. & Bernard (2012). “An Introduction to Enterprise Architecture”, Third Edition, Author House,
Formato Kindle.
El presente texto es la base para el estudio de la temática de Arquitectura Empresarial, en el

mismo se presenta las diferentes conceptualizaciones como casos prácticos de la Arquitectura
Empresarial y su incidencia en la Gestión de Tecnologías de la Información.
• Bon, J. (2008). “Fundamentos De La Gestión De Servicios De TI Basada En ITIL V3”. Editorial Van Haren
Publishing; Holanda.
Este libro es la base para el estudio de la temática de Gestión de Tecnologías de la Información

donde se presente los conceptos básicos sobre dicha temática así como ejemplos prácticos
para que le profesional en formación de la titulación de Informática pueda gestionar TI tanto en
empresas públicas y privadas.
• Landa, R. (2012): “Administración de Tecnologías de Información”. Departamento: Ciencias

Computacionales Universidad de Monterrey, [En línea] México Disponible en: http://ocw.udem.
edu.mx/cursos-de-profesional/administracion-de-tecnologias-de- informacion/index_modulos.
html/[Consulta 01-10-2012]
Este curso OWC pretende apoyar a los participantes presentando el impacto de los sistemas de
información dentro de los negocios, lo anterior basado en los conceptos teóricos fundamentales
de este tema; así como dar pautas y lineamientos aplicables a la gestión de dichas tecnologías
para lograr que proporcionen una ventaja competitiva a la empresa.
Direcciones Electrónicas
• Biden;J. (2012). “Federal Enterprise Architecture”. Recuperado de www.whitehouse.gov/omb/e-gov/

fea Federal Enterprise Architecture
• Brown ;A. (2013). “Enterprise Architecture”. Recuperado de www.opengroup.org
• Nunn; S.(2012). “National Institutes of Health”. Recuperado de https://enterprisearchitecture.nih.

gov

• Scoot; J. (2012).Human Service. Recuperado de http://www.hhs.gov/ocio/ea/index.html - U.S.

Department of Health & Human Services
• Zachman; J. (2012).” Enterprise Arquitecture Framework”. Recuperado de www.zachman.com

5. Orientaciones generales para el estudio
Para el estudio del presente componente educativo usted señor estudiante contará con las siguientes
herramientas básicas:
EL Texto-guía.- Le orientará sobre cómo y qué temas estudiar, además contiene ejercicios de
autoevaluación que le permitirán medir su grado de comprensión y la necesidad de tutoría por parte
del docente.
Para el caso del preente componente educativo se ha elaborado un Texto Guía que lo que pretende
es, que en un solo documento se sinteticen las actividades de una guía didáctica con las utilidades del
texto base, en párrafos anteriores se indicó que debido a que la mayoría de la bibliografía referente a
Arquitectura Empresarial está en Inglés se optó por elaborar un texto guía.
Entorno Virtual de Aprendizaje.- Donde podrá interactuar con sus profesores a través de una orientación
del trabajo semanal, uso de mensajería electrónica para resolver inquietudes, foros, desarrollo de
ejercicios prácticos, publicación de recursos, todo este trabajo tendrá una valoración de 2 puntos.
La Tutoría personal.- Es un tiempo semanal que como profesores dedicamos para atender las inquietudes
en relación a los contenidos o desarrollo de trabajos, para ello se publicará un horario en el cual podrán
asistir personalmente o contactarse vía telefónica.
Los trabajos a distancia.- Son actividades teóricas y prácticas que acompañan a la guía didáctica estas
le permiten aplicar y reforzar los conocimientos adquiridos mediante su desarrollo, y debe enviarlos a
su profesor. La entrega de estos trabajos con su respectiva carátula es obligatoria y no recuperable, lo
cual significa que si no entrega alguno de los mismos no tendrá opción a la evaluación presencial, su
valoración es de 4 puntos que sumados a la calificación de participación en el EVA totalizan 6 puntos.
En cuanto a la forma de trabajo le pedimos siga algunos lineamientos que le ayudarán a aprovechar su
tiempo y lograr mejores resultados para ello se recomienda:
El tiempo que dedique a la lectura y desarrollo de los ejercicios es fundamental, por lo tanto deberá
dedicar al menos 8 horas semanales. Puede apoyarse con técnicas como subrayadas, cuadros sinópticos
y sobre todo mapas conceptuales.
Recuerde que cuenta con su profesor tutor para la comprensión de los temas, entonces la comunicación
con el mismo será fundamental, para lo cual debe familiarizarse con las formas de comunicación que
tiene, ya sea por teléfono (consultar horario de tutoría), email, chat, y otras herramientas tecnológicas.
Recuerde además que existe una variada información en el internet, bibliotecas digitales y también la
documentación que su profesor le acerca a través del EVA.
En el texto guía encontrará la planificación del trabajo con las actividades sugeridas para cada unidad,
distribuidas en el tiempo, por lo tanto trate de cumplir con estas según se lo indica.
Las autoevaluaciones que se presentan al final de cada unidad así como las que constan en el texto básico
le ayudarán a comprender de mejor manera cada uno de los temas por lo que su realización es de suma
importancia para afianzar el proceso de enseñanza aprendizaje. Una vez resueltas las autoevaluaciones
de la guía didáctica puede comparar sus respuestas con el solucionario al final de la guía. En caso que su
resultado no sea satisfactorio le sugerimos volver a revisar los temas y acudir a su tutor para aclarar sus
dudas.

Como ayudas, a lo largo del presente documento encontrará los siguientes focalizadores:
Focalizador Propósito
Importancia de la temática.
Definiciones a considerar.
Actividad propuesta.
Estrategias de evaluación
El sistema de estudios de la Modalidad Abierta y a Distancia de la Universidad Técnica Particular de

Loja contempla los siguientes parámetros de evaluación, con la particularidad de que en la carrera de
Ingeniería en Informática se incluye de manera obligatoria la participación en el EVA.
La asignatura se encuentra dividida en dos bimestres, cada uno de los cuales se califica sobre 20 puntos,
en caso de que en algún estudiante no obtenga una nota mínima de 14 puntos, deberá presentarse a un
examen supletorio calificado sobre 20 que reemplaza la nota bimestral correspondiente. Los estudiantes
aprueban cuando han logrado un mínimo de 28 puntos.
En el presente cuadro constan los parámetros y puntajes que se tomarán en cuenta en el primer y
segundo bimestre.
Instrumento Puntaje
Trabajo a distancia:
• Objetiva 2 puntos
• Ensayo 2 puntos
• Interacción EVA 2 puntos
Evaluación presencial 14 puntos
TOTAL 20 PUNTOS

6. Proceso de enseñanza-aprendizaje para el logro de competencias
12
PRIMER BIMESTRE
6.1. Competencias genéricas
• Trabajo en equipo II: Contribuye en la consolidación y desarrollo del equipo, favoreciendo la comunicación, el reparto equilibrado de tareas, el
clima interno y la cohesión.

Texto-guía: Gestión de Tecnologías de Información
6.2. Planificación para el trabajo del alumno
Contenidos
Competencias Competencias específicas Actividades de Indicadores de Tiempo de
específicas de Titulación del componente educativo aprendizaje aprendizaje dedicación
Unidades
Buscar y seleccionar Maneja conocimientos Unidad 1: Gestión de Tecnologías de Información, Estudio autónomo de la Identifica el ámbito Semana 1 y 2
información, explorar sólidos sobre Arquitectura Arquitectura Empresarial (AE), Estructura y cultura unidad 1. de la arquitectura 8 horas de
métodos que permitan Empresarial (AE), incluyendo empresarial para

Empresarial. Desarrollo de actividades autoestudio
enfocar problemas terminología, métodos y recomendadas en el asegurarse de que
1.1. Introducción a Gestión de Tecnologías de 8 horas de
relacionados a ciencias tendencias de la industria y texto guía. esté alineada con la
Información (GTI) interacción
de la computación. la investigación. estrategia
Inicio del desarrollo de
1.2. Visión general de la Arquitectura Empresarial empresarial.
Evaluación a Distancia.
1.3. Federal Enterprise Architecture
Revisión de recurso web.
1.4. Zachman Framework
1.5. TOGAF
1.6. ¿Qué es la arquitectura de la empresa?
1.7. El enfoque.
1.8. Las actividades arquitectónicas.
PRIMER BIMESTRE
1.9. La Arquitectura Empresarial como un Programa

de Gestión.
Contenidos
13
Unidades
1.9.1. Alineación Estratégica.

1.9.2. Políticas Estandarizadas
1.10. La arquitectura como un método de análisis y
diseño.
1.10.1. Elemento de análisis y de diseño # 1: El
Marco.
1.10.2. Elemento de análisis y de diseño # 2:
Componentes arquitectónicos
Arquitectura actual

Arquitectura Futura
1.10.5. Elemento de Análisis y Diseño # 5: Plan de

Gestión Arquitectónica.
1.10.6. Elemento de Análisis y Diseño # 5: Hilos
1.11. Repositorio de AE.
Autoevaluación 1
Elaborar soluciones Unidad 2: Implementación de la Metodología Lectura de la unidad 2 del Identifica los Semana 3 y 4
alternativas de TIC para la Arquitectónica. texto guía. obstáculos, 8 horas de
mejora de procesos Revisión de recursos oportunidades y autoestudio
2.1. Metodología de Implementación.

empresariales. OCW referente a la riesgos para la
Autoevaluación 2 8 horas de
temática. implementación de
interacción
un programa de
Desarrollo de preguntas y
arquitectura
ejercicios unidad 2.
empresarial y los
medios para
superarlos.
PRIMER BIMESTRE
Contenidos
14
Unidades
Unidad 3: Componentes y Artefactos Arquitectónicos. Lectura de la unidad 3 del Semana 5 y 6

3.1. Plan estratégico. texto guía Reconoce la 8 horas de
Desarrollo de preguntas y necesidad de autoestudio
3.1.1. Análisis FODA
ejercicios unidad 3. implementar un 8 horas de
3.1.2. Concepto de Escenarios de Operaciones programa de
Revisión de recursos interacción
3.1.3. Estrategia Competitiva OCW referente a la arquitectura
temática. empresarial en una
3.2. Plan de Comercio /Gobierno Electrónico.
organización
3.3. Componentes Arquitectónicos: Nivel de existente y las formas
Productos y Servicios de crear una
3.4. Servicios del negocio. propuesta para esta
iniciativa.
3.4.1. Almacenes de Conocimiento (Data
Warehouse – Data Marts)

3.5. Componentes Arquitectónicos: Nivel de sistemas

y aplicaciones
3.5.1. Planificación de recursos empresariales
(ERP Solutions)
3.6. Componentes Arquitectónicos: Nivel Redes e
Infraestructura
3.6.1. Redes de datos
3.6.2. Redes de Telecomunicaciones

3.6.3. Redes de Video.
3.6.4. Redes Móviles
3.6.5. Redes troncales de transmisión
3.6.6. Vistas de gestión de los artefactos
arquitectónicos
Autoevaluación 3
Revisión de contenidos Semana 7 y 8

como preparación para la 8 horas de
evaluación presencial autoestudio
8 horas de
interacción
PRIMER BIMESTRE
Texto-guía: Gestión de Tecnologías de Información PRIMER BIMESTRE
6.3. Sistema de evaluación de la asignatura (primero y segundo bimestre)
Formas de evaluación 2. Heteroevaluación

Evaluación Evaluación a
1. Autoevaluación *
presencial distancia **
3. Coevaluación
Interacción en el EVA
Parte de ensayo
Prueba objetiva
Parte objetiva
Competencia: criterio
Comportamiento ético x x x x x x
Cumplimiento, puntualidad,
Actitudes
x x x x x
responsabilidad
Esfuerzo e interés en los trabajos x x x x x x
Respeto a las personas y a las
x
normas de comunicación
Creatividad e iniciativa x x x x x x
Habilidades
Contribución en el trabajo
x x
colaborativo y de equipo
Presentación, orden y ortografía x x x
Emite juicios de valor
x x x
argumentadamente
Dominio del contenido x x x x
Conocimientos
Investigación (cita fuentes de

x x
consulta)
Aporta con criterios y soluciones x x x
Análisis y profundidad en el
x x x x
desarrollo de temas
Máximo 1 punto
PORCENTAJE 10% 20% 30% 70%

Estrategia de
aprendizaje
presenciales y en el
evaluación a
(completa la
distancia)
Puntaje 2 4 6 14
Actividades
EVA
TOTAL 20 puntos
Para aprobar la asignatura se requiere obtener un puntaje mínimo de 28/40 puntos, que equivale al 70%.
* Son estrategias de aprendizaje, no tienen calificación; pero debe responderlas con el fin de autocomprobar su
proceso de aprendizaje.
** Recuerde que la evaluación a distancia consta de dos partes: una objetiva y otra de ensayo, debe desarrollarla
y entregarla en su respectivo centro universitario.
Señor estudiante:
Tenga presente que la finalidad de la valoración cualitativa es

principalmente formativa.

6.4. Orientaciones específicas para el aprendizaje por competencias
UNIDAD 1. GESTIÓN DE TECNOLOGÍAS DE INFORMACIÓN, ARQUITECTURA

EMPRESARIAL (AE), ESTRUCTURA Y CULTURA EMPRESARIAL
Estimado estudiante:
En la presente unidad iniciaremos el estudio de la Gestión de Tecnologías de Información y su enfoque

desde el punto de vista de la Arquitectura de Empresarial por ello lo invitamos a revisar cada una de las
temáticas planteadas.
La unidad 1 le ofrece una visión general de la disciplina de la Arquitectura Empresarial (AE). El concepto
principal que estudiaremos es que la AE es una actividad empresarial estratégica que apoya la gestión
de la planificación y la toma de decisiones, proporcionando vistas coordinadas de toda una empresa.
Estas vistas abarcan la estrategia, el negocio y la tecnología, que es diferente a los enfoques centrados en
la tecnología, sistemas o procesos. La implementación de la AE involucra a elementos básicos como los
programas de gestión, y los métodos de documentación basados en un marco de trabajo (framework).
En caso de tener alguna duda e inquietud será un gusto poderlos atender por medio de los diferentes
recursos que le oferta el EVA y recurso adicionales que permitan una interacción adecuada.
Iniciaremos nuestro estudio con la Introducción a la Gestión de Tecnologías de información donde

daremos una visión global de dicha temática.
La presente unidad pretende que usted:
• Entienda el propósito de la Gestión de tecnologías de la Información.

• Conozca los elementos de un programa de gestión de AE.
• Conozca los elementos de un método de documentación de AE.
• Entienda las diferencias con otros enfoques de análisis / planificación.
1.1. Introducción a Gestión de Tecnologías de Información (GTI).
Bon, J. (2008), considera que las tecnologías de la información son un factor de vital importancia en
la transformación de la nueva economía global y en los rápidos cambios que están tomando lugar
en la sociedad. En las últimas décadas, las nuevas herramientas tecnológicas de la información y la
comunicación han producido un cambio profundo en la manera en que los individuos se comunican
e interactúan en el ámbito de los negocios, y han provocado cambios significativos en la industria, la
agricultura, la medicina, el comercio, la ingeniería y otros campos.
Uno de los factores competitivos claves en los últimos años ha sido, sin duda, la aplicación estratégica
de las tecnologías de información y de comunicaciones en alineación con los objetivos estratégicos
del negocio. Si bien estas inversiones han estado focalizadas en la automatización, en el escenario
competitivo actual surge la necesidad de operar de maneras más dinámica, utilizar nuevos modelos de
negocio que exigen inversiones en tecnologías y aplicaciones cada vez más flexibles e integradas como
factor de supervivencia. En la Figura 1.1 muestra un esquema que relaciona algunos conductores con la
estrategia de gestión de TI.

Figura 1.1: Gestión Empresarial de TI, tomado de: OVUM Informed Business Technology Decisions – Disponible en www.ovum.com
Un aspecto estratégico en las organizaciones es la Gestión de Información. En efecto, la manera en que

se gestiona la materialización, operación y continuidad de los servicios tecnológicos requeridos por la
organización ya no son una ventaja competitiva, sino un factor que al no estar alineado a las necesidades
de la empresa, constituirá una desventaja relevante.
Una vez comprendida la temática continuemos.
1.2. Visión general de la Arquitectura Empresarial
En el presente apartado nos enfocaremos a comprender el propósito, fases y componentes de un

programa de Arquitectura Empresarial, por ello lo invitamos a revisar las temática propuesta.
A continuación le detallamos algunos conceptos así como los objetivos de aprendizaje del presente
apartado.
Empresa
Una organización o sub-actividad cuyos límites están definidos por objetivos,
procesos y recursos comunes. Esto incluye a organizaciones enteras del sector público,
privado o sin ánimo de lucro; parte(s) de una organización como unidades de negocio,
programas y sistemas, o parte(s) de múltiples organizaciones como consorcios y
cadenas de suministro.
Arquitectura Empresarial
El análisis y documentación de una empresa en su estado actual y futuro desde de
una estrategia integrada, de negocios y perspectiva tecnológica.
Para abordar el tema es importante comprender que la AE es una práctica de gestión tecnológica que
se dedica a mejorar el rendimiento de las empresas, y que a su vez, les permite verse a sí mismas en
términos de una visión global e integrada desde la dirección estratégica, las prácticas comerciales, los
flujos de información y los recursos tecnológicos.
Usted puede gestionar la transición arquitectónica desde un estado operativo actual a un futuro
mediante el desarrollo de las vistas actuales y futuras de estos estados de manera integrada, y que son
soportados por los objetivos estratégicos de la organización.

Para aclarar el contexto arquitectónico lo invitamos a revisar la siguiente analogía a la arquitectura

tradicional:
Tome como referencia la construcción de una casa de una habitación en donde usted sabe que sin la existencia
de planos vamos a obtener un mal resultado. Esto es análogo al desarrollo de las organizaciones, unidades de
negocio, programas y sistemas, que sin un esquema arquitectónico de referencia pueden incurrir en la
duplicación e ineficiencia de los recursos, y sobre todo la falta de agilidad.
Destacar que el uso estratégico de los recursos es cada vez más importante y usted deberá comprender
que el éxito de las empresas tanto de sector público, como privado y sin fines de lucro, involucra a
múltiples participantes internos y externos (es decir, las cadenas de suministro). Por esta razón obtener
el máximo provecho de la tecnología y de los recursos humanos exige a la empresa pensar en términos
de soluciones globales para la misma, más que en soluciones individuales para sus sistemas y programas.
(Figura 1.1). Para hacer esto, usted requerirá conocer un nuevo enfoque para la planificación y desarrollo
de sistemas, un enfoque arquitectónico que involucra integrar al negocio con la tecnología, es por esto
que en el presente texto guía le proponemos a la Arquitectura Empresarial como una estrategia para
solucionar los problemas descritos anteriormente.
La palabra “empresa” implica una visión estratégica de alto nivel de toda la entidad,
mientras que la palabra “arquitectura” implica un marco estructurado para el análisis, la
planificación y el desarrollo de todos los recursos de la entidad.
Veamos lo que propone el EABok (Enterprise Architecture Body of Knowledge) en lo referente a la

Arquitectura Empresarial (ver Figura 1.2) como enfoque de transformación organizacional que toma
como base los cuatro elementos fundamentales que se administran dentro de una organización
(negocio, información, aplicaciones y tecnología), en el cual inicialmente se identifica el estado actual de
la organización y a través de un proceso de transición se llega al estado futuro o deseado, recuerde que
para esta materia hemos tomado como base el marco Cube EA3 para arquitectura empresarial:
Figura 1.2: Elementos de la Arquitectura Empresarial, tomada de: EABok 2004

Ahora destacaremos a los principales marcos de arquitectura empresarial con la finalidad de contextualizar
a la misma desde diferentes perspectivas:
1.3. Federal Enterprise Architecture
Es el marco de arquitectura empresarial adoptado por las agencias federales de los Estados Unidos, que
ayuda a las mismas a eliminar el desperdicio y la duplicación de actividades, incrementar los servicios
compartidos, cerrar brechas de rendimiento y promover alineamiento entre el gobierno, la industria y
los ciudadanos.
El FEA es un marco común que provee los principios y estándares para conocer como las arquitecturas
de negocio, información y de tecnología deben ser desarrolladas a través del Gobierno Federal de EEUU
de tal manera que puedan ser utilizados consistentemente en varios niveles de alcance dentro y entre
las agencias gubernamentales, así como con stakeholders externos. La Figura 1.3, muestra la estructura
del marco, usted se dará cuenta que se utilizan los mismos niveles del marco EA3.
Figura 1.3: Federal Enterprise Architecture tomada de: http://www.whitehouse.gov/sites/default/files/omb/assets/egov_

docs/common_approach_to_federal_ea.pdf
1.4. Zachman Framework
Proporciona la arquitectura para la infraestructura de la información de una organización, el marco

contiene seis filas y seis columnas que componen treinta y seis celdas o aspectos distintos. No hay
dirección establecida en la secuencia o proceso para la aplicación de la arquitectura. El objetivo es
asegurarse de que todos los aspectos de una empresa estén cubiertos y además muestra las relaciones
que asegurarán un sistema completo sin importar el orden en el cual se establecen.

Figura 1.4: Zachman Enterprise Architecture Framework tomada de: http:ww.zachman.com/
1.5. TOGAF
The Open Group Framework, provee los métodos y herramientas para asistir en la aceptación, producción,
uso y mantenimiento de la arquitectura empresarial. Está basado en un proceso iterativo que soporta
las mejores prácticas y un conjunto de activos arquitectónicos reutilizables existentes. Existen cuatro
campos de arquitectura que son comúnmente aceptados como subconjuntos de una arquitectura
global de la empresa, TOGAF está diseñado para apoyar:
• La arquitectura de negocios define la estrategia de negocio, la gestión, la organización y los

procesos clave del negocio.
• La arquitectura de datos describe la estructura de los activos de datos lógicos y físicos de la

organización y los recursos de gestión lo mismos.
• La arquitectura de aplicaciones proporciona un modelo para los sistemas individuales de

aplicaciones que se implementarán, sus interacciones y su relación con los procesos de negocio
de la organización.
• La arquitectura de tecnología describe las capacidades de software y hardware que se requieren

para apoyar el despliegue del negocio, datos y servicios de aplicación. Esto incluye la infraestructura
de TI, middleware, redes, comunicaciones, procesamiento, normas, etc.

Además TOGAF produce un número determinado de salidas como resultado de su aplicación, estos
pueden ser flujos de proceso, requerimientos arquitectónicos, planes de proyecto, evaluaciones de
cumplimiento, etc. Para esto define el Framework Arquitectónico de Contenidos (TOGAF Architecture
Content Framework) que provee un modelo estructurado de contenidos que permite a los productos de
trabajo ser consistentemente definidos, estructurados y presentados. El Framework Arquitectónico de
Contenidos usa las siguientes tres categorías para describir el tipo de producto arquitectónico dentro
del contexto de uso:
• Entregables.
• Artefactos.
• Bloque de construcciones (Building Blocks).
El método utilizado para implementar la arquitectura empresarial a través de TOGAF es el Método de

Descripción Arquitectónica ADM por sus siglas en inglés en la figura 1.5 se describe la misma.
Figura 1.5: TOGAF – Metodología de Descripción Arquitectónica tomada de: http://www.opengroup.org/togaf/
Actividad Propuesta
Consulte otras metodologías de Descripción Arquitectónica que se provean
en el mercado y realice un análisis comparativo de sus actividades y fases.
Una vez que hemos revisado los principales marcos de trabajo arquitectónico vamos a centrar nuestra
atención en el marco EA3 para el desarrollo del curso, indicando que se ha tomado como referencia el


mismo debido a que maneja un esquema
información-aplicaciones-tecnología) quedeserán
contenidos sencillo
la base que facilita
de cualquier el entendimiento
marco de la
de arquitectura
práctica arquitectónica dentro de las empresas. Como verá en la figura 1.6, que es la propuesta que hace
empresarial.
el marco EA3, existen cuatro áreas fundamentales (negocio-información-aplicaciones-tecnología) que
serán la base de cualquier marco de arquitectura empresarial.
Iniciativa
Estrateg.
1 Iniciativa
Estrategica
Sistemas de 2
ALINEAMIENTO NEGOCIO & TECNOLOGÍA

TI Redes
de Estrategia Proceso 1
Video
Iniciativa
Negocio
Estrategica Proceso 2
1
AE = E + N + T
Proceso 1 Proceso 3
Redes
de
Datos Dicc. Objetos
de Datos
Información
Reutil.
Flujos de Dicc.
Proceso 2 Datos de Datos
Aplicaciones
Servicios Web
Sistemas
Iniciativa Servicios Web
Estrategica
2
Sistemas Aplicaciones
Redes
de Voz
Objetos
Reutil. Redes
Flujos de
Datos de
Video Redes
Redes Redes
de
de Voz
Datos
Figura 1.6: Influencia de la Arquitectura Empresarial, tomada de: Scott A. Bernard 2012
En lo que respecta a los

Figura recursos,
1.6: uno
Influencia de de los mayores
la Arquitectura desafíos
Empresarial, tomadaque usted
de: Scott visualizará,
A. Bernard 2012 es que muchas
empresas siguen enfrentando problemas en la identificación de una iniciativa estratégica a través de los
componentes
En lo que de negocio
respecta a yloslosrecursos,
componentes uno de tecnológicos.
los mayores Gran parte de
desafíos este
que reto es
usted que históricamente
visualizará, es que
la tecnología, y las tecnologías de la información (TI) en particular, no han sido vistas como un activo
muchas empresas siguen enfrentando problemas en la identificación de una iniciativa estratégica
estratégico, debido a que las actividades de planificación a menudo se centran en el desarrollo de
a travéstecnológicas
soluciones de los componentes de negocio
individuales y los componentes
para satisfacer necesidadestecnológicos.
particulares Gran parte de este reto
de la organización.
es que históricamente la tecnología, y las tecnologías de la información (TI) en particular, no han
sido vistas como un activo estratégico, debido a que las actividades de planificación a menudo se
centran en el desarrollo de soluciones
“Los activos estratégicos tecnológicas individuales
son aquellos que paraventaja
brindan una satisfacer necesidades
competitiva a las
organizaciones” Kaplan-Norton
particulares de la organización.
“Los activos estratégicos son aquellos que brindan una ventaja competitiva a
1.6. ¿Qué es la arquitectura de la empresa?
las organizaciones” Kaplan-Norton
Según la ISO/IEC 42010:2007 “arquitectura” se define como:
“La organización fundamental de un sistema, encarnada en sus componentes, sus relaciones con otros y
su entorno, y los principios que gobiernan/rigen su diseño y evolución”
1.6 ¿Qué es la arquitectura de la empresa?
Tomando como referencia esta definición, las diferentes estrategias para abordar a la arquitectura
empresarial plantean sus propias definiciones:
Según la ISO/IEC 42010:2007 “arquitectura” se define como:
“La organización fundamental de un sistema, encarnada en sus componentes, sus relaciones con
otros y su entorno, y los principios que gobiernan/rigen su diseño y evolución”
28


La arquitectura empresarial es el Mapa que proporciona un entendimiento común de

la organización y se usa para alinear la estrategia y os requerimientos tácticos.
Object Management Group, Business Working Group
La descripción formal de un sistema, o un plan detallado del sistema a nivel de
componentes para guiar su aplicación.
La estructura de componentes, sus inter-relaciones, y los principios y directrices que
gobiernan su diseño y evaluación a lo largo del tiempo.
TOGAF-The Open Group Framework
“El proceso de traducir la visión y la estrategia de negocio de la empresa en un cambio
efectivo mediante la creación, la comunicación y la mejora de los requisitos
fundamentales, principios y modelos que describen el estado futuro de la empresa y
permitir su evolución. El alcance de la EA incluye no sólo los procesos de negocio, sino
también las personas, la información y la tecnología de la empresa y sus relaciones
entre sí y con el ambiente externo”
Gartner
Ahora tome como referencia la siguiente ecuación en donde se describe el objetivo de la arquitectura
empresarial, la misma le ayudará a diferenciar a ésta y a otros tipos de estrategias para la planificación
de TI.
AE = E + N + T
Arquitectura Empresarial = Estrategia + Negocio + Tecnología
“La AE está dirigida por los objetivos y requerimientos estratégicos del negocio.”
Los requerimientos arquitectónicos que se deben satisfacer, vienen dados por los objetivos estratégicos
del negocio y siempre en segundo lugar por los de TI. La estrategia arquitectónica puede resumirse
en una hoja de ruta, y en un documento conceptual que describe las principales características y
funcionalidades de la arquitectura alineadas con el negocio. Como pasos siguientes, deberá elegir la
tecnología (arquitectura técnica) que mejor encaje con la estrategia arquitectónica definida. El framework
de desarrollo y operaciones de TI son el marco metodológico de la arquitectura técnica, las que son
utilizadas para el desarrollo de aplicaciones y servicios, dotando de estandarización, productividad y
mejores prácticas a las soluciones de negocio. [Microsoft (2009), “Microsoft Application Architecture
Guide” (Documento disponible en línea en http://www.codeplex.com/AppArchGuide)
La arquitectura de una empresa es una colección de modelos e información, la creación de una

arquitectura para toda una empresa se logrará a través de un proceso estandarizado que se mantiene
a través de un programa de gestión en curso. La AE provee una estrategia y un enfoque de negocio
orientado a las políticas, la planificación, la toma de decisiones y el desarrollo de recursos que sean
útiles para los ejecutivos, gerentes de área y para el personal de apoyo. Para ser eficaz, un programa
arquitectónico debe ser parte de un grupo de prácticas de gestión que forman una estructura de gestión
integrada, como lo muestra la Figura 1.7 de la siguiente página.
Una arquitectura de empresa debe ser una referencia para los estándares de procesos/recursos, y el
proveedor de los diseños de los estados futuros de funcionamiento. Por tanto, la arquitectura de empresa

deberá incluir la totalidad de elementos y aspectos organizacionales. Tener una única fuente de referencia
es esencial para evitar el desperdicio y la duplicación de funciones y esfuerzo en organizaciones grandes
y complejas. También resuelve la “batalla de las mejores prácticas” y la competencia entre los dominios
sub-arquitectónicos que pueden ser problemáticos para las organizaciones que están tratando de
convertirse en eficientes.
Desarrollar una arquitectura de empresa, utilizando los métodos de arquitectónicos

descritos en este texto guía se convertirá en una tarea única y valiosa para las
organizaciones, ya que la AE es holística y sirve como un paraguas o “meta-contexto”
para la gestión y el desarrollo de mejores prácticas tecnológicas.
Figura 1.7: Principales áreas de control integrado de la Arquitectura como Meta Disciplina, tomada de: Scott A. Bernard 2012.
La AE también crea vistas abstractas, y modelos de análisis que le ayudarán a modelar la vista actual y
futura de la empresa, permitiendo la mejora en la planificación y en la toma de decisiones. La AE va más
allá de la planificación tecnológica, mediante la inclusión de la planificación estratégica como principal
impulsor de la empresa y la planificación comercial como la fuente de la mayoría de los programas y
requerimientos de recursos.
Todavía hay un lugar para la planificación de la tecnología, que consiste, en que usted tiene que tomar
en cuenta el diseño de sistemas, aplicaciones, redes, centros de llamadas, y otros recursos (
Ej: edificios, bienes de capital) para cumplir con los requerimientos del negocio, que son el corazón de las
actividades y metas estratégicas de la empresa, la Figura 1.8 descrita en la siguiente página, presenta un
meta-modelo arquitectónico obtenido como resultado de un proceso de planificación tecnológica. En
cuanto a establecer las mejores prácticas las organizaciones del sector público y privado se enfrentan a

menudo con las decisiones acerca de qué prácticas adoptar y también que practicas perseguir: calidad,
agilidad, eficiencia, gestión del riesgo y adopción de nuevas tecnologías.
Figura 1.8. La Arquitectura Empresarial como Meta-Modelo tomada : Scott A. Bernard 2012.

Existen docenas de mejores prácticas, y la mayoría de ellas fueron creadas de manera aislada en relación
con las otras buenas prácticas. El autor del texto base llamó a esto la “Batalla de las mejores prácticas”
estas crean un dilema costoso para las organizaciones, pues usted debe decidir cuáles adoptar. Debido
a que los métodos de implementación y mantenimiento de muchas de las mejores prácticas son muy
costosos en recursos, y el alcance no es del todo incluido, la organización se enfrenta al reto de decidir
qué adoptar, cómo hacerlo, lo que se superpone, las contradicciones y las brechas que se producen.
La arquitectura de una organización en todas sus dimensiones, se convierte en la disciplina de más alto
nivel y la referencia autorizada para estándares y prácticas. Se trata de una enorme y única contribución,
porque cuando la AE se utiliza de esta manera, el dilema desaparece y las organizaciones pueden utilizar
el marco para tomar decisiones racionales sobre las mejores prácticas que deben adoptarse, lo que
va a cubrir, y cómo pueden relacionarse entre sí. La Figura 1.9 ilustra cómo la AE sirve en el contexto
organizativo para la adopción y uso de las mejores prácticas.
Figura 1.9: Arquitectura Empresarial como una Meta Disciplina, tomada de: Scott A. Bernard 2012
1.7. El enfoque
Para que usted pueda considerar a un enfoque arquitectónico completo, deberá aplicar los seis elementos
básicos que se muestran en la Figura 1.10 que deben estar presentes y trabajarse sinérgicamente.
Figura 1.10: Elementos fundamentales de un enfoque de Arquitectura Empresarial, tomada de: Scott A. Bernard 2012

Gobernanza
El primer elemento clave es la “Gobernanza”, que identifica a las fases de planificación, toma de decisiones,
procesos y grupos de supervisión que determinaran cómo usted debe desarrollar y mantener la AE,
llevada a cabo como parte del gobierno global dentro de la organización.
Metodología
El segundo elemento clave es “Metodología”, que implica a las medidas concretas que debe establecer y
mantener en un programa de AE a través del método seleccionado.
Plataforma
El tercer elemento es el “marco” que identifica el alcance general de la arquitectura y el tipo y la relación
de los diversos niveles e hilos de la sub-arquitectura. Tenga presente que no todos los marcos de trabajo
permiten subdominios o son capaces de integrar la estrategia, los negocios y la planificación tecnológica.
Artefactos
El cuarto elemento central son los “artefactos”, en la que deberá identificar los tipos y métodos de
documentación que utilizará en cada área de la sub-arquitectura, incluyendo el análisis estratégico,
planes de negocios, controles internos, controles de seguridad, los modelos de flujos de trabajo, bases
de datos, sistemas y redes. Este elemento central también incluye el repositorio en línea donde se
almacenan los artefactos.
Normas
El quinto elemento central son las “Normas” en las que usted identifica los estándares de tecnología para
la empresa en cada dominio, los segmentos de negocios y componentes arquitectónicos. Esto incluye
estándares de la industria que pueden ser locales, nacionales o internacionales así como las normas
específicas de la empresa.
Mejores Prácticas.
El sexto elemento central son las “ Mejores Prácticas Asociadas”, que son formas probadas que le permitirán
ejecutar partes de la estructura general o sub-arquitecturas, en el contexto arquitectónico.
Actividad Propuesta
Profundice el entendimiento acerca de los elementos fundamentales
arquitectónicos mediante consultas adicionales.
1.8. Las actividades arquitectónicas
A la arquitectura de empresa deberá llevarla a cabo a través de un programa de gestión y un método de

análisis y diseño que es repetible en los distintos niveles del alcance. Conjuntamente los programas y
métodos arquitectónicos le proporcionaran capacidad permanente y un conjunto de vistas coordinadas,
servicios de negocios, flujos de información y utilización de recursos para la dirección estratégica

Como un programa de gestión, la el marco le propone lo siguiente:
• Alineamiento estratégico: objetivos, actividades y recursos

• Política estandarizada: la gobernanza e implementación de los recursos
• Soporte a la toma de decisiones: Control financiero y gestión de la configuración
• Supervisión de recursos: enfoque del ciclo de vida del desarrollo, - y gestión
Como un método de análisis y diseño, la AE dispone lo siguiente:
• Enfoque arquitectónico: El marco, el análisis, método de diseño y conjunto de artefactos.

• Vista Actual (as-is): Las estrategias, procesos y recursos actuales (as-is).
• Vista Futura (to-be): Las estrategias, procesos y recursos futuros (to-be).
• Plan de Gestión arquitectónico: Un plan para pasar de vista actual a la vista futura.
Una vez comprendida la temática continuemos.
1.9. La Arquitectura Empresarial como un Programa de Gestión
Ahora es importante que comprenda que la AE es un programa de gestión continua, que proporciona
un enfoque estratégico e integrado con capacidad para la planificación de recursos/toma de decisiones.
Un programa arquitectónico es parte de un proceso de gobernanza global que determina la alineación
de los recursos, las políticas normalizadas de desarrollo, la mejora al soporte de decisiones y la guía de
las actividades de desarrollo. La AE le ayudará a identificar brechas en la línea de desempeño de las
actividades comerciales/programas y las capacidades de apoyo a los servicios de TI, sistemas y redes.
1.9.1. Alineación Estratégica
La AE le apoyará en la planificación estratégica y en otros procesos de planificación, proporcionándole

las vistas macro y micro de cómo estos están siendo apalancados en el cumplimiento de los objetivos
de la empresa. Esto le ayudará a maximizar eficiencia y eficacia, que a su vez le permitirá promover
la capacidad competitiva de la empresa. Los proyectos de desarrollo dentro de la empresa deben ser
revisados para determinar si son compatibles con (y cumplir con) uno o más de los objetivos estratégicos.
Si un recurso y/o proyecto no está alineado, entonces su valor dentro de la empresa se mantendrá en
cuestión, tal y como se muestra en la Figura 1.11.
Figura 1.11: Alineación Estratégica de Capacidades y Recursos, tomada de Scott A. Bernard 2012

1.9.2. Políticas Estandarizadas
Considere que la AE soporta la implementación de una gestión estandarizada de políticas pertinentes

para el desarrollo y utilización de TI y otros recursos. Al proporcionar un enfoque holístico y jerárquico de
los recursos actuales y futuros, la AE apoya en el establecimiento de políticas para que usted:
Identifique de las necesidades estratégicas y operativas
• Determine de la alineación estratégica de las actividades y recursos

• Desarrolle los recursos y tecnología en toda la empresa
• Priorice la financiación de programas y proyectos
• Supervise la gestión de programas y proyectos
• Identifique los indicadores de desempeño de los programas y proyectos
• Identifique y aplique normas y gestión de configuración
Usted debe estar en la capacidad de identificar los documentos que describen las políticas, estos pueden
clasificarse como:
• Orientación general (por ejemplo, directivas y memorandos de alto nivel),

• Orientación específica del programa (por ejemplo, planes, manuales) y
• Guías de proceso detalladas (por ejemplo, normas de procedimientos operativos).
El uso de estas categorías jerárquicas le permitirá establecer documentos que incluyan políticas sucintas
y significativas, de tal manera que ningún documento de políticas sea extenso y por ende más fáciles
de leer y entender. También es importante que entienda que los diversos ámbitos en las políticas están
relacionados entre sí, de manera que el programa de implementación en la empresa es coordinado. Las
políticas de AE deben integrarse con otras políticas en todas las áreas de gobierno, a fin de que pueda
crear un sistema de gestión general de recursos eficaces con capacidad de vigilancia.
1.9.3. Soporte a la toma de decisiones
Como parte del equipo de implementación del programa, debe estar consciente de que la AE le ofrece
soporte a la toma de decisiones de los recursos empresariales de TI en los niveles ejecutivo, administrativo
y de personal.
• En el nivel ejecutivo, proporciona visibilidad de las grandes iniciativas de TI y apoya en la

determinación de la alineación estratégica.
• En el nivel de gestión, apoya las decisiones de diseño y gestión de la configuración, así como la
alineación de las iniciativas de TI con las normas técnicas de voz, datos, video y seguridad.
• En el nivel personal, la AE apoya las decisiones relativas a las operaciones, el mantenimiento y el

desarrollo de recursos y servicios de TI.
1.9.4. Supervisión de Recursos
La AE apoya enfoques estandarizados para la supervisión del desarrollo de las capacidades y la

optimización de los recursos de apoyo. Dependiendo del alcance de los recursos involucrados y el plazo
disponible para el desarrollo, usted podrá utilizar diversos métodos del ciclo de vida de desarrollo de
sistemas para reducir el riesgo de que el costo, horario, o los parámetros de rendimiento no puedan
ser alcanzados. La AE soporta enfoques estandarizados y probados para la gestión de proyectos que
promuevan la supervisión integral y efectiva de los programas en curso y los nuevos proyectos de

desarrollo. Por último, la AE apoya el uso de un proceso estandarizado para la selección y evaluación de
la inversión de recursos de TI y las perspectivas financieras de la empresa.
1.10. La arquitectura como un método de análisis y diseño
Como habíamos mencionado en puntos anteriores existen algunas referencias arquitectónicas, que
comenzaron a surgir a finales del 1980 en diversas literaturas académicas y de gestión, con un enfoque
inicial en arquitectura de sistemas y esquemas para organizar la información técnica. El concepto de
análisis y diseño de la arquitectura de “empresa” surgió en la década de 1990 y ha evolucionado para
incluir vistas de los objetivos estratégicos, servicios de negocios, flujos de información, sistemas y
aplicaciones, y redes e infraestructura de apoyo. Además, hay “temas” que se impregnan en todos los
niveles de la arquitectura: las normas, la seguridad, y las habilidades.
Existen seis elementos básicos que usted deberá tener en cuenta para el análisis y diseño arquitectónico
y que se mencionan a continuación en orden cronológico:
(1) un marco documentación, y (2) una metodología de implementación que apoyan la creación de la
vista (3) actual y (4) futura de la arquitectura, así como el desarrollo de (5) un Plan de Gestión de AE para
gestionar la transición desde la arquitectura actual a la futura.
También hay varias zonas comunes a todos los niveles de la estructura que se conocen como (6) “hilos”,
las mismas se muestran en la Figura 1.12.
Figura 1.12: Elementos básicos de análisis y diseño para la AE, tomada de: Scott A. Bernard 2012
1.10.1. Elemento de análisis y de diseño # 1: El Marco
El marco identifica el ámbito de aplicación de la arquitectura a ser desarrollada y establece las relaciones
entre las diferentes áreas de la misma. El alcance del marco se refleja a través de su diseño geométrico y
de las áreas que se identifican en la documentación. El marco crea un conjunto abstracto de las “vistas”
de una empresa, en base a la información recopilada y organizada de la información arquitectónica.
Un ejemplo que se utilizará en todo el texto es el marco que se ilustra en la Figura 1.13 de la siguiente
página, que tiene una forma cúbica con tres dimensiones que se relacionan con diferentes aspectos de
la modelización de la empresa. En la unidad 1 se hizo referencia a los marcos arquitectónicos mapas
importantes dentro del mercado.
Una vez que usted conozca el Cubo EA3 en donde los niveles del mismo son jerárquicos y las diferentes
sub-arquitecturas (que describen áreas funcionales distintas) pueden ser lógicamente relacionadas unas
con otras, colocando los objetivos/iniciativas estratégicas de alto nivel en la parte superior, productos/

servicios, datos del negocio (los flujos de información) en el medio, y de apoyo sistemas/aplicaciones y
tecnología, (la infraestructura) en la parte inferior.
Figura 1.13: EA3 cubo de Análisis de Framework y Diseño tomado de: Scott A. Bernard 2012
De esta manera la alineación también puede demostrarse entre la estrategia, la información y la

tecnología, que le ayudarán en la planificación y toma de decisiones.
Para reducir el riesgo, y promover métodos eficientes de aplicación gradual, el marco se divide en
segmentos de actividad distintos, denominados Líneas de Negocio (LOB). Por ejemplo, cada una de las
LOB tiene una sub-arquitectura completa que incluye todos los cinco niveles jerárquicos del marco. Las
LOB pueden por lo tanto ser arquitecturas independientes dentro de la empresa, salvo que la duplicación
de los datos, aplicaciones, y funciones de red ocurriera si cada LOB fuera verdaderamente independiente.
Una arquitectura que abarca los cinco niveles del marco y se enfoca en uno o más LOB puede ser referida
como un segmento arquitectónico en general.
Línea de Negocios
Una línea de negocio (LOB) es un área de actividad visible dentro de la empresa.
Puede tratarse de la fabricación de determinados productos, la prestación de los
servicios o funciones administrativas internas.
Segmento Arquitectónico
Una parte de la AE que documenta una o más líneas de negocio en todos los
niveles e hilos. Un segmento puede existir como una parte independiente de la
misma.
1.10.2. Elemento de análisis y de diseño # 2: Componentes arquitectónicos
Los componentes arquitectónicos son objetivos, procesos, normas y recursos intercambiables que
pueden extenderse en toda la empresa o estar contenidos dentro de una línea específica de negocio o
segmento. Ejemplos de componentes incluyen objetivos e iniciativas estratégicas, productos y servicios
empresariales; flujos de información, almacenes de conocimiento, objetos de datos, sistemas de
información, aplicaciones de software, programas de recursos empresariales, sitios web, y redes de voz,
video y datos, y la infraestructura de apoyo como edificios, salas de servidores, armarios de cableado, etc.

La Figura 1.13 en la página siguiente proporciona ejemplos de componentes arquitectónicos verticales y

transversales en cada nivel del marco, en la unidad 4 se da a conocer mayor detalles.
Componente Vertical
Un componente vertical es un objetivo, proceso, programa o recurso (equipos,
sistemas, datos, etc.) cambiante que sirve a una sola línea de negocio.
Componente Horizontal (Transversal)
Un componente horizontal o transversal es un objetivo, (proceso, programa o recurso)
cambiante que sirve a varias líneas de negocio. Los ejemplos incluyen sistemas de
soporte administrativo que sirven a toda la empresa.
Figura 1.14: Componentes de AE – Ejemplos, tomado de: Scott A. Bernard 2012
1.10.3. Elemento de análisis y de diseño # 3: Arquitectura actual
La arquitectura actual contiene los componentes arquitectónicos que existen actualmente dentro de
la empresa en cada nivel de la estructura. Esta se conoce como la vista “as-is”-”actual”. La vista actual
le servirá para crear una línea base del inventario de recursos y actividades actuales que deberán ser
documentadas de una manera consistente y conjunta con la vista futura, con la finalidad de que los
analistas puedan identificar las brechas de rendimiento entre los planes futuros y las capacidades
actuales. Tener una visión actual precisa y completa de los componentes arquitectónicos es una
referencia importante para la planificación de proyectos, gestión de activos, y decisiones de inversión. La
vista arquitectónica actual se compone de “artefactos” (documentos, diagramas, datos, hojas de cálculo,
gráficos, etc.) en cada nivel de la estructura, que deberá archivar en un repositorio en línea (on-line) para
que sean utilizados por las diversas partes interesadas.
1.10.4. Elemento de análisis y de diseño # 4: Arquitectura Futura
La arquitectura futura documenta los componentes arquitectónicos nuevos o modificados que serán
necesarios para que la empresa pueda cerrar una brecha de rendimiento existente o apoyar una nueva
iniciativa estratégica, necesidad operacional o solución tecnológica.
Como se muestra en la Figura 1.15, la arquitectura futura está dirigida tanto a nivel estratégico y táctico
de tres formas: nuevas directivas y objetivos, las prioridades cambiantes del negocio y las tecnologías
emergentes. La AE no puede reflejar estos cambios en la arquitectura futura a menos que:

• El equipo de liderazgo de la empresa proporcione cambios en la dirección y los objetivos

estratégicos;
• La línea de gerentes del negocio y de los programas realicen cambios en las prioridades y procesos
de negocio que se necesitan para lograr los nuevos objetivos;
• El personal de apoyo identifique las soluciones viables en lo que tiene que ver a la tecnología y
personal para satisfacer los nuevos requerimientos del negocio.
Figura 1.15: Conductores del cambio arquitectónico tomado de: Scott A. Bernard 2012
La arquitectura futura debe cubrir en el corto plazo los cambios planificados en los componentes
arquitectónicos (cambios tácticos en los próximos 1-2 años), así como los cambios en los componentes
que son el resultado de la aplicación de escenarios de operación a largo plazo (1-3 años). Estos escenarios
incorporan diferentes factores tanto internos como externos, y que pueden ayudar a identificar los
cambios necesarios en los procesos, los recursos o la tecnología que se traducen en supuestos futuros,
que a su vez conducen a la planificación de nuevos componentes arquitectónicos.
1.10.5. Elemento de Análisis y Diseño # 5: Plan de Gestión Arquitectónica
El Plan de Gestión le ayudará a articular el programa y el enfoque de la documentación, proporcionándole

descripciones de las vistas arquitectónicas actuales y futuras, y un plan de secuenciación para gestionar
la transición al futuro ambiente operativo tecnológico del negocio; tenga presente que el Plan de Gestión
es un documento vivo, esencial para obtener beneficios del programa de gestión. Cómo la empresa se
va a mover continuamente desde la arquitectura actual a la futura se presenta un reto significativo de
planificación y gestión, sobre todo si los recursos de TI soportan a las principales funciones de negocio
que están siendo reemplazadas o actualizadas.
En la unidad 7 se proporciona más detalle sobre el desarrollo del Plan de Gestión Arquitectónica.
1.10.6. Elemento de Análisis y Diseño # 5: Hilos
La documentación arquitectónica incluye “hilos” o actividades comunes que están presentes en todos
los niveles de la estructura. Estos hilos incluyen consideraciones de TI relacionadas con la seguridad, las
normas, y las habilidades.
Seguridad: La seguridad es más eficaz cuando forma parte integral del programa de gestión y la
metodología de documentación. Un programa integral de seguridad tiene varias esferas de actividad
tales como: información, personal, operaciones, e instalaciones. Para ser eficaz, la seguridad debe
trabajar en todos los niveles del marco y dentro de todos los componentes arquitectónicos.
Normas: Una de las funciones arquitectónicas más importantes es proporcionar las normas relacionadas
con la tecnología en todos los niveles del marco. Esta debe basarse en normas aceptadas por la industria
nacional e internacional, con el fin de promover el uso de soluciones no propietarias de los componentes

arquitectónicos. Esto a su vez mejora la integración y el soporte de los componentes, cuando sea
necesario.
Habilidades: Tal vez el mayor recurso que la empresa tiene es su personal. Por lo tanto, es importante
asegurarse de que la dotación de personal, las habilidades y las necesidades de formación sean
identificadas para cada LOB y para el soporte de las actividades y servicios en cada nivel del marco, esto
se deberá ver reflejado en las arquitecturas actuales y futuras.
Arquitectura de referencia / Segmento Arquitectónico
Una arquitectura de referencia forma parte de la AE y proporciona normas y documentación para un

tipo particular de capacidades en toda la empresa, como servicios móviles o cloud computing. Una
arquitectura segmentada es algo similar, pero por lo general se centra en una o más unidades de negocio
específicas, tales como los grupos de finanzas y contabilidad, o cómo un sistema ERP financiero y todos
sus módulos que se van a implementar (contabilidad general, cuentas por pagar, cuentas por cobrar,
nómina, beneficios, etc.)
Montaje de los elementos arquitectónicos
Mientras que los elementos básicos de análisis y diseño le proporcionan descripciones holísticas y
detalladas de la arquitectura actual y futura en todas las áreas de la estructura subyacente, es importante
también ser capaces de articular estas relaciones en los debates y presentaciones con los ejecutivos,
gerentes, personal de apoyo y otras partes interesadas. Ser capaz de comprender y relatar cómo la
arquitectura encaja en el contexto organizacional es esencial para utilizar la AE en la fase de planificación
y toma de decisiones en toda la empresa. Esta comunicación se apoya en dos recursos del programa
arquitectónico: el Plan de Gestión y el Repositorio. Como se mencionó en la sección anterior, el Plan de
Gestión es un documento vivo que se actualiza periódicamente para que sea relevante como referencia
principal para describir el estado de la arquitectura actual y futura. El repositorio es un archivo on-line de
información y documentación de los artefactos que se describen en el Plan de Gestión. El repositorio se
describe en la siguiente sección de esta unidad.
El siguiente es un ejemplo de cómo comunicar la estrategia arquitectónica con las partes interesadas.
En este ejemplo, algunas preguntas están relacionadas en cómo aplicar el marco de arquitectónico en
una empresa, estos son los tipos de preguntas que deben ser respondidas en las primeras sesiones del
programa y las reuniones de documentación con el fin de promover la comprensión de cómo el marco
y la documentación pueden reflejar el estado actual de la empresa. En el siguiente ejemplo se propone
una forma de abordar a la AE, utilizando los cinco niveles y tres hilos verticales del marco EA3. Observe
cómo las preguntas se acumulan de manera que se reflejan las relaciones jerárquicas entre los niveles
del marco.
Cada área del marco representa un área funcional de la empresa. El Marco EA3 se puede utilizar mediante
tres estrategias:
• De arriba abajo,
• De abajo hacia arriba,
• De un solo componente.
Para empezar a utilizar el marco de arriba hacia abajo, usted deberá realizar una serie de preguntas en
cada nivel con el fin de pueda determinar cómo la información acerca de la empresa se ajusta a ese nivel
de la estructura.

Las primeras preguntas que se refieren al nivel de “metas e iniciativas estratégicas del marco son:
• ¿Con qué propósito, existe la empresa (por lo general se expresa en la declaración de la misión?
• ¿En qué tipo de organización tiene la intención de convertirse la empresa (a menudo descrito en
la declaración de la visión)?
• ¿Cuáles son los principales objetivos (objetivos estratégicos) de la empresa?
• ¿Cuáles son las iniciativas estratégicas (programas en curso o nuevos proyectos) que permitirán a
la empresa lograr esos objetivos?
Por último, para este nivel,
• ¿Cuándo conocerá la empresa que se han alcanzado con éxito los objetivos estratégicos o está
haciendo progresos hacia las consecución de estos objetivos (medidas de resultado)?
Actividad Propuesta
Tome como referencia una empresa conocida y desarrolle las preguntas del
nivel “metas e iniciativas estratégicas”.
El segundo, es el nivel de negocios (Productos y Servicios): es importante que pregunte acerca de las
áreas de actividad en curso (líneas de negocio - LOB) que la empresa debe realizar para apoyar y facilitar
el cumplimiento tanto de las iniciativas estratégicas como las funciones normales, como referencia el
“mantenimiento”, entonces:
• ¿Cuáles son las actividades específicas de cada línea de negocio (servicios a empresas)?
• ¿Cuáles son los productos que se entregan en cada línea de negocio?
• ¿Cómo se mide la eficacia y la eficiencia de la línea de procesos de negocio (medidas de entrada /

salida), así como su contribución a los objetivos estratégicos (medidas de resultado)?
• ¿Alguno de estos servicios de negocio o procesos de fabricación tienen que ser rediseñados /
mejorados antes de que estos sean parte de la arquitectura futura?
• ¿Cuáles son los problemas en lo referente a la fuerza de trabajo, normas y seguridad en este nivel?
Actividad Propuesta
nivel “productos y servicios del negocio”.
En tercer lugar está el nivel de “Datos e Información”: cuando las líneas de negocio y los servicios/
productos de negocio específicos han sido identificados, es importante que pregunte cuáles son los
flujos de información que serán necesarios dentro y entre las áreas de actividad con el fin de que tengan
éxito.

• ¿Cómo pueden los flujos de información ser armonizados, estandarizados o protegidos con la
finalidad de promover intercambio eficiente, preciso y seguro?
• ¿Cómo se formatean, generan, comparten y almacenan los datos que subyacen a los flujos de
información?
• ¿Cómo los datos se convierten en información y conocimiento utilizable?
Actividad Propuesta
nivel “Datos e Información”
El cuarto es el nivel de ‘Sistemas y Aplicaciones” del marco y es importante que conozca que sistemas
de TI y de negocios se necesitan para generar, compartir y almacenar los datos, la información y los
conocimientos que necesitan los servicios de negocio.
• ¿Cómo se pueden hacer para que varios tipos de sistemas de TI, servicios, aplicaciones, bases de
datos y sitios web trabajen conjuntamente cuando sea necesario?
• ¿Cómo puede ayudar la gestión de configuración a crear un entorno operativo «rentable y

operativamente eficiente?
• ¿Cuáles son los problemas en lo referente a la fuerza de trabajo, normas y seguridad en este nivel?
Actividad Propuesta
Tome como referencia una empresa conocida y desarrolle un informe de las
preguntas del nivel “Sistemas y Aplicaciones”
EL quinto, es el nivel de la estructura de red e infraestructura, y es importante preguntar:
• ¿Qué tipo de redes de voz, datos y vídeo o de nube de computación (cloud-computing) se requiere
para alojar los sistemas/aplicaciones de TI y para transportar datos, imágenes y conversaciones
asociadas, así como también el tipo de infraestructura de apoyo a las redes (por ejemplo, edificios,
salas servidores y otros equipos)?
• ¿Cómo pueden estas redes integrarse para crear alojamiento y transporte rentable y operativamente
eficiente?
• ¿Podrán estas redes y nubes extenderse más allá de la empresa?
• ¿Cuáles son los problemas que tienen que ver con la fuerza de trabajo, las normas y la seguridad?
• ¿Cuál es el espacio físico y los requerimientos de soporte para estos recursos de infraestructura?

Actividad Propuesta
Tome como referencia una empresa conocida y desarrolle un informe de las
preguntas del nivel “Estructura de red e infraestructura”
1.11. El Repositorio de AE
Proveer fácil acceso a la documentación arquitectónica es esencial para su uso en la planificación y toma
de decisiones. Esto se puede lograr a través de la creación de un repositorio en línea (on-line) para archivar
la documentación de los componentes en las diferentes áreas del marco. El repositorio es esencialmente
un sitio web y una base de datos que almacena la información y proporciona enlaces a herramientas y
otros recursos de los programas. La Figura 1.16 le proporciona un ejemplo de cómo podría diseñar el
repositorio. Este ejemplo se llama Empresa Viva y está diseñado para respaldar la documentación que se
organiza a través de la utilización del Marco EA3.
Figura 1.16: Ejemplo del diseño del repositorio “Empresa Viva”, tomado de: Scott A. Bernard 2012
Ahora le invitamos a revisar el primer caso de estudio, en el cual se analizará la necesidad de abordar
un esquema arquitectónico empresarial en base a necesidades organizacionales específicas, en las que
se demuestra que un enfoque orientado a la mejora de sistemas nos es la mejor opción a la hora de
gestionar el cambio tecnológico empresarial
Actividad Propuesta
Revise los casos “Posible Escenario de Implementación Arquitectónica “y
“Considerando un Programa de Arquitectura Empresarial” propuestos en el
entorno virtual de aprendizaje EVA con la finalidad contextualizar el tema. Luego
asocie lo encontrado en el caso de estudio con las temáticas estudiadas en el
presente capítulo.

Autoevaluación 1
Se ha completado la Unidad 1, en la cual con toda seguridad encontró algunos

conceptos que no conocía, sin embargo es preciso realizar una autoevaluación
para determinar cuanto a logrado asimilar. Aunque el desarrollo de estas
preguntas no es obligatorio, se le recomienda resolverlas ya que es posible que
haya algunos temas que no se han comprendido a plenitud. Recuerde que al
final de la guía se han incluido las soluciones a estas autoevaluaciones sin
embargo deberá usarlas solo después de haber obtenido sus propias respuestas
para volver a revisar temas que quizá no quedaron bien comprendidos. Si tiene
alguna duda no dude en consultar con su profesor tutor.
Lea detenidamente cada una de la preguntas y seleccione la alternativa correcta según corresponda.
1. La Arquitectura Empresarial es una práctica de gestión tecnológica que ayuda a las empresas a:
a. Gestionar de manera integrada los estados actuales y futuros que son soportados por los
objetivos estratégicos de la organización.
b. Gestionar de manera integrada los estados actuales.
c. Gestionar de manera integrada los estados y futuros.
2. La mejor estrategia para obtener el máximo provecho de la tecnología y los recursos humanos
exige:
a. Pensar en soluciones parciales.

b. Pensar en soluciones globales para la empresa.
c. Pensar en soluciones individuales para sus sistemas y programas.
3. Los componentes básicos de una arquitectura empresarial son:
a. Objetivos e iniciativas estratégicas.

b. Negocio, Datos, Aplicaciones y Tecnología
c. Negocio y tecnología.
d. Una actividad de un proceso de gestión.
4. El enfoque arquitectónico utilizado por las agencias federales de los EEUU es:
a. FEAF.
b. TOGAF.
c. ZACHMAN.
5. Los activos estratégicos:
a. Permiten mejorar actividades particulares dentro de la organización.

b. Son aquellos que no son considerados dentro de la estrategia competitiva a las organizaciones.
c. Son aquellos que brindan una ventaja competitiva a las organizaciones.

6. La gobernanza como un elemento arquitectónico básico
a. Implica a las medidas concretas que se deben establecer y mantener en un programa de AE

a través del método seleccionado.
b. Identifica a las fases de planificación, toma de decisiones, procesos y grupos de supervisión
que determinaran como se debe desarrollar y mantener arquitectura.
c. Identifica los estándares de tecnología para la empresa en cada dominio, los segmentos de
negocios y componentes arquitectónicos.
7. El marco arquitectónico como un elemento de análisis y diseño
a. Ayuda a articular el programa y el enfoque de la documentación arquitectónica,

proporcionándole descripciones de las vistas arquitectónicas actuales y futuras, y un plan
de secuenciación para gestionar la transición al futuro ambiente operativo tecnológico del
negocio
b. Documenta los componentes arquitectónicos nuevos o modificados que serán necesarios
para que la empresa pueda cerrar una brecha de rendimiento existente o apoyar una nueva
iniciativa estratégica, necesidad operacional o solución tecnológica.
c. Identifica el ámbito de aplicación de la arquitectura a ser desarrollada y establece las
relaciones entre las diferentes áreas de la misma.
8. Una línea de negocios LOB:
a. Es un área de actividad visible dentro de la empresa.

b. Una parte de la AE que documenta una o más líneas de negocio en todos los niveles e hilos.
c. Partes independientes dentro del esquema organizacional.
9. Un componente arquitectónico puede:
a. Describir el comportamiento de un plan de gestión arquitectónico.

b. Estar contenido dentro de los objetivos e iniciativas estratégicas.
c. Estar contenido dentro de una línea específica de negocio o segmento arquitectónico.
10. El repositorio arquitectónico:
a. Es un archivo on-line de información y documentación de los artefactos que se describen

en cada segmento arquitectónico.
b. Es un archivo on-line de información y documentación de los artefactos que se describen
en cada línea de negocio.
c. Es un archivo on-line de información y documentación de los componentes que se describen
en el Plan de Gestión.

UNIDAD 2. IMPLEMENTACIÓN DE LA METODOLOGÍA ARQUITECTÓNICA
En esta unidad describiremos el proceso de implementación de la metodología arquitectónica, que es un

procedimiento detallado para el establecimiento, mantenimiento y utilización del marco arquitectónico
y el enfoque de la documentación. Identificar el enfoque metodológico es el primer paso para coordinar
la estrategia de documentación. El valor que tiene la adopción de la metodología es reducir el riesgo de
crear un programa y/o documentación inefectiva.
Framework AE.
Un Framework de AE es una estructura para organizar la información que define el
ámbito de la arquitectura, el programa arquitectónico que lo documentará y la
relación entre las de las distintas áreas de la arquitectura.
Metodología de AE.
La metodología de AE define como se llevará a cabo y cómo se desarrollará la
documentación a utilizar y archivar, incluyendo la selección del marco, las herramientas
de modelado, y el repositorio on-line.
• Entienda el propósito de una metodología dentro del programa de AE.

• Comprenda los pasos de una metodología de AE
• Comprenda la relación entre un Framework y una Metodología de AE.
Una metodología de AE es una descripción detallada de cómo un programa arquitectónico se va a

establecer y ejecutar, y la forma en que la documentación arquitectónica se va a desarrollar, mantener
y utilizar. La metodología que se presenta en este texto guía es lo suficientemente flexible como para
soportar el uso de algunos marcos, herramientas y repositorios arquitectónicos. La Figura 2.1 proporciona
una descripción general de los seis elementos básicos de la documentación arquitectónica que se
presentaron en la unidad 1. Esta unidad se basa en los elementos básicos, establecidos en la fase cuatro,
dentro de la “metodología de los veinte pasos para establecer el programa arquitectónico y poner en
práctica los seis elementos de la documentación.
Figura 2.1: Elementos básicos de la documentación de la AE tomado de: Scott A. Bernard 2012

Para aclarar el contexto arquitectónico lo invitamos a revisar la siguiente analogía a la arquitectura

tradicional:
La metodología de AE es como el enfoque estándar que los arquitectos siguen cuando se les enseña a diseñar
y construir una casa. Hay cosas que se deben hacer de una manera determinada para que el diseño sea exitoso
y para que el hogar se construya correctamente.
Tenga presente que el establecimiento de un programa de AE tiene muchas facetas y una de las claves
del éxito es el uso de una metodología de documentación detallada para que el programa comience y
luego pueda orientar el esfuerzo de documentación.
La metodología que se describe en este texto guía es generalizada para que pueda ser utilizada en una
amplia variedad de empresas del sector público y privado, y pueda soportar muchos tipos y marcos de
herramientas y repositorios arquitectónicos. Dependiendo del tipo de empresa en el que esté trabajando,
algunas partes de la metodología pueden ser necesarias de cambiar.
Tenga presente que es importante desarrollar una metodología, como uno de los primeros pasos para
establecer el programa, ya que obliga a la empresa a “pensar a través de las siguientes e importantes
consideraciones:
¿Qué áreas de la empresa, cubrirá la AE (Ámbito de aplicación)?
• El enfoque de gobierno (por ejemplo, centralizada o descentralizada]
• Los tipos de documentación (conocidos como artefactos) que serán necesarios para apoyar a las
empresas y la tecnología, la planificación de recursos y la toma de decisiones
• El marco documental arquitectónico que mejor soporte a las necesidades de la empresa
• Los métodos y técnicas para la recolección o el desarrollo de la documentación.
• Las herramientas de software de modelado, aplicaciones web y bases de datos que serán necesarias
para automatizar el proceso de documentación y habilitar un escenario de modelado futuros
• ¿Cuántos usuarios podrán acceder y compartir la documentación?
• ¿Con qué frecuencia se actualizará la documentación?
Cabe señalar que la revitalización de un programa arquitectónico existente implicará pasos adicionales
que varían con cada situación. La revitalización podría concentrarse en la selección de un marco y una
metodología de aplicación diferentes, y la identificación de nuevas particiones verticales y horizontales
de la empresa que serán documentados en segmentos.
A continuación se detalla una metodología de implementación arquitectónica la misma que cuenta con
20 pasos para su respectivo desarrollo.
2.1. Metodología de Implementación
Es importante que considere que para la implementación de un programa arquitectónico debe

tener definido un esquema de documentación a utilizar. En las siguientes fases se describe el diseño
arquitectónico bajo los principios arquitectónicos.

Fase I: Establecimiento del programa arquitectónico.
Las actividades de la Fase I están diseñadas para que el programa arquitectónico inicialmente arranque,
identificando actores clave, y comunicando el plan de implementación al sponsor y a otros stakeholders
para ganar aceptación y apoyo.
Estas actividades de documentación previa son importantes para garantizar que el programa tenga
metas claras, este centrado, y sea aceptado en toda la empresa.
Sponsor Ejecutivo
El ejecutivo que tiene autoridad para tomar decisiones sobre el programa de
arquitectónico y que ofrece recursos y liderazgo sénior al mismo.
Paso 1: Establezca el Programa de Gestión Arquitectónico e identifique un Arquitecto Jefe.
El patrocinador ejecutivo establece el programa y se identifica a un arquitecto en jefe para dirigir el

programa. El programa es inicialmente la puesta en marcha del proyecto (fases I-III) y luego un programa
en curso (Fase IV). El patrocinador ejecutivo debe proporcionar al arquitecto en jefe los recursos
suficientes (por ejemplo, presupuesto, personal, hardware, software, e instalaciones) y la autoridad
para poder establecer correctamente el programa. El arquitecto en jefe debe ser responsable de los
recursos y del programa. Una de las primeras acciones del arquitecto en jefe debe ser el establecimiento
de un equipo que se componga de arquitectos formados en AE y representantes de diversos grupos de
interesados.
Paso 2: Establezca una metodología de implementación arquitectónica.
El segundo paso en la metodología es para el arquitecto en jefe y el equipo de AE para identificar todos
los pasos de la metodología que la empresa necesita para crear un programa eficaz. La metodología
que se discute en esta unidad se puede utilizar tal como se presenta o puede ser modificada para
satisfacer las necesidades particulares de la empresa. Otras metodologías del sector público y privado
pueden ser utilizadas. Lo importante a recordar en el inicio de una estrategia arquitectónica es tener una
metodología detallada que le guiará en la implementación del programa y las actividades posteriores de
documentación, así como reducir el riesgo de que el programa pierda el enfoque, eficacia y valor.
Paso 3: Establezca la gobernanza y la vinculación con los procesos de gestión.
El tercer paso es para el patrocinador ejecutivo y el Arquitecto en jefe para co-desarrollar el enfoque
de gobierno arquitectónico, que habilite políticas, planes, y toma de decisiones efectivas dentro del
programa de gestión. Este enfoque de gobierno deberá incluir enlaces a otros procesos de gestión
para la planificación estratégica, planificación de capital, gestión de proyectos, seguridad y el plan de
capacitación para los recursos.
Gobernanza de TI.
Implica el alineamiento de las Tecnologías de la información y la comunicación (TI)
con la estrategia del negocio. Hereda las metas y la estrategia a todos los departamentos
de la empresa, y propicia el mejor uso de la tecnología y de sus estructuras
organizativas para alcanzarlas.

Paso 4: Desarrolle un Plan de Comunicación para ganar interesados.
El siguiente paso es desarrollar un Plan de Comunicación que articule la metodología de documentación

y un calendario para las actividades de la Fase II y III. El Plan de Comunicación arquitectónico debe ser
escrito en un lenguaje sencillo para ganar la atención de los interesados técnicos, ejecutivos, gerentes de
línea de negocio, personal de apoyo y otros, potenciales usuarios de la documentación arquitectónica.
El Plan de Comunicación debe incluir una síntesis del propósito y la visión arquitectónica, ejemplos de
cómo la arquitectura aportará valor a la empresa, donde estará disponible la documentación para su
acceso, un resumen de la metodología utilizada, así como los principios generales que serán utilizados
para su desarrollo.
Fase II: Marco de documentación arquitectónica y selección de herramientas.
Las Actividades de la Fase II se producen cuando el conjunto inicial de documentación se desarrolla. Esto
comienza con la selección de un marco de documentación arquitectónico que identifique el ámbito
de la arquitectura, oriente las técnicas para el modelado de las vistas actuales, desarrolle los escenarios
futuros y el modelado asociado, y establezca un repositorio en línea en el que se archivarán todos los
artefactos de la documentación.
Artefacto arquitectónico
Es un producto de documentación, como un documento de texto, especificación del
sistema, información de interfaz de la aplicación, diagramas, hojas de cálculo,
diapositivas, briefings o videoclip.
Paso 5: Seleccione un marco de documentación de la AE.
El primer paso de la Fase II consiste en la selección de un marco documentación arquitectónica por el

arquitecto en jefe, con la participación del equipo de AE y los interesados. El marco debe identificar las
áreas de la empresa que el enfoque arquitectónico cubrirá, y cómo estas se relacionan. Por ejemplo, el
marco EA3 identifica cinco áreas funcionales y tres áreas de procesos que deberá documentar, organizar
diferentes tipos de componentes y, a continuación, orientar los componentes en las líneas de negocio.
Estas relaciones son importantes en la transición de cómo la empresa utiliza procesos y recursos en el
logro de sus objetivos.
Paso 6: Identifique las Líneas de Negocio - Los cortes transversales y el orden de documentación.
Es importante que considere que el segundo paso de la Fase II de la implementación de un modelo

arquitectónico consiste en la identificación de las líneas verticales del negocio (también conocidos como
segmentos) y las iniciativas transversales horizontales dentro de la empresa las mismas que pueden ser
diseñadas por separado y cuando son combinadas representarán a la AE la empresa.
Las iniciativas transversales son aquellas actividades horizontales que funcionan en un “entorno operativo
común” a través de varios LOB (Line Of Businness). Ejemplos de cortes transversales horizontales
incluyen servicios web, almacenes de conocimiento, infraestructura de red, soluciones de seguridad,
módulos ERP y sistemas de back office “, las aplicaciones (por ejemplo, correo electrónico, seguimiento
de documentos, finanzas y contabilidad, recursos humanos).

Paso 7: Identifique los componentes arquitectónicos a ser documentados.
En este paso identifique los componentes arquitectónicos que tendrán que estar documentados en
cada área funcional de la estructura. Por ejemplo, el marco EA3 tiene seis áreas funcionales (estrategia,
negocio, información, servicios, redes e hilos verticales). Cada una de estas áreas representa un conjunto
distinto de actividades que se extienden en toda la empresa, están representados por los componentes
arquitectónicos. Cada componente arquitectónico está documentado mediante métodos de recolección
de información y técnicas de modelización que son apropiados para el tipo de cosas que están contenidas
en los mismos.
Para cada uno de los niveles del marco existen componentes que deben ser documentados, a
continuación detallamos algunos ejemplos:
• En el nivel estratégico los objetivos estratégicos de la empresa, las actividades y las medidas de
resultado son los principales elementos.
• En el nivel empresarial, la línea de servicios del negocio y las medidas asociadas.
• En el nivel de información, los flujos de información, bases de datos, almacenes de conocimientos

y estándares de datos.
• En el nivel de servicios y aplicaciones, los diversos servicios web, servicios de ofimática y software
aplicaciones.
• En el nivel de infraestructura tecnológica las redes de voz, video y datos, así como a plantas de
cableado e instalaciones de equipos asociados.
• Para los hilos verticales, información de seguridad, estándares de información y los recursos son
asociados en cada una de las cinco áreas funcionales.
Paso 8: Seleccione métodos apropiados de documentación para el framework.
En este paso seleccione los métodos que se utilizan para reunir y desarrollar los artefactos arquitectónicos
dentro de la documentación. Por ejemplo, los siguientes son los métodos de modelado en las seis áreas
funcionales de la estructura del cubo EA3.
Plan Estratégico, Escenarios, Balanced Scorecard Nivel de actividad:

Nivel Estratégico:
IDEF-o diagramas, diagramas de flujo, Diagrama de carreteras
Nivel de información: Los modelos de datos, diagramas de objetos, diccionario de datos
Nivel de servicios: Diagramas de sistemas, modelos de servicios web, API´s
Nivel de tecnología: Voz / Datos / Vídeo / Documentos Diagramas de Red
Hilos verticales: Diagramas de seguridad, estándares, habilidades de la fuerza laboral
Es importante que elija técnicas de documentación que proporcionen la información necesaria para la
planificación de recursos y la toma de decisiones. Por lo tanto, el arquitecto en jefe debe consultar con
las partes interesadas y el equipo de AE los métodos para el desarrollo de artefactos y la información será
recopilada.
Paso 9: Seleccione las aplicaciones/herramientas de software para apoyar la automatización de la

documentación arquitectónica.
Una vez que conozca las áreas funcionales, los niveles de la estructura y los tipos de componentes
arquitectónicos, podrá establecer la documentación y artefactos del programa. Sin hacer los pasos 7 y

8, sería difícil para el arquitecto en jefe y el equipo de AE conocer las técnicas de modelado específicas
que tendrán que soportar. Por ejemplo, si los métodos orientados a objetos se están utilizando para
desarrollar artefactos en el nivel de información del framework, entonces una herramienta de modelado
a utilizar es el Lenguaje de Modelado Unificado (UML).
Paso 10: Seleccione y establezca un repositorio AE en línea para la documentación.
Este es el último paso en la fase, para que el Arquitecto en Jefe y el equipo de AE seleccionen una
aplicación de software para el repositorio y para la base de datos.
El repositorio debe estar alojado en la red de área local de la empresa por seguridad y por facilidad
de acceso a la documentación. El repositorio es un directorio dentro de una base de datos donde se
archivará toda la documentación arquitectónica. Uno de los métodos para promover la facilidad de uso
es el de establecer un sitio web que es la “puerta de entrada” para todas las actividades del programa
y documentación arquitectónica. Diseñe esta página para promover una visión clara del alcance de la
documentación que estará disponible.
Actividad Propuesta
Busque en Internet, herramientas que le permitan implementar un repositorio
de Arquitectura Empresarial. Luego asocie lo encontrado en el caso de estudio
con las temáticas estudiadas en el presente capítulo
Fase III: La documentación arquitectónica.
En la fase 3 usted deberá analizar y documentar la estrategia actual, el negocio, la información, los
servicios y la infraestructura de la empresa. También deberá desarrollar los artefactos que reflejen los
cambios en los recursos en el corto plazo y el desarrollo de un conjunto de escenarios de futuro a largo
plazo para identificar los posibles cursos de acción y los cambios de los recursos que serán necesarios
en respuesta a diferentes influencias internas y externas. Las actividades de esta fase de la metodología
de documentación concluyen con la elaboración de un Plan de Gestión arquitectónica que resume las
vistas actuales y futuras de la arquitectura y ofrece un plan de transición y secuencia de los cambios a
corto y a largo plazo.
Paso 11: Evalúe el negocio existente y la documentación de la tecnología para su uso en la AE.
El primer paso de la Fase III es el comienzo de las actividades reales de documentación. Las actividades
precedentes establecen lo que debe ser documentado, cómo se documentará, y que hará la
documentación. La visión actual de los componentes es lo que ahora usted está documentando a
través de la identificación de los componentes de AE que se encuentran en cada nivel de la estructura y
luego utilice los artefactos existentes y nuevos para documentar los componentes arquitectónicos que
actualmente existen. En muchos sentidos, usted debe tomar esta actividad como un inventario de los
componentes (objetivos estratégicos, servicios de negocios, medidas, datos, servicios y recursos de TI)
existentes en la empresa y mapear los mismos con la documentación existente.
Paso 12: Documente las vistas actuales de los componentes arquitectónicos existentes en todos los
ámbitos del marco.
En el segundo paso de la Fase III desarrolle nuevos artefactos para completar la documentación de todos
los componentes ya existentes.

Es importante que considere que los métodos de documentación y herramientas que identificó en
el paso 8 debe utilizarlos para recopilar y estandarizar los artefactos existentes, así como desarrollar
los nuevos. Estos artefactos están organizados por niveles dentro del framework y se almacenan en el
repositorio que estableció en el paso 10.
Paso 13: Desarrolle varios escenarios operativos para el negocio y la tecnología
Antes de desarrollar las vistas futuras de los componentes arquitectónicos, es útil que obtenga una
comprensión de alto nivel de las posibles alternativas futuras que la empresa podría tomar, dependiendo
de cómo responde a influencias internas y externas. Desarrolle tres o más escenarios que deberían
desarrollarse de manera óptima con la AE y los stakeholders de las líneas de negocio para reflejar lo que
puede ocurrir si:
(1) el statu quo se mantiene,
(2) se encuentra un ambiente operativo óptimo del negocio / tecnología, y
(3) una alta amenaza y situación de supervivencia.
Existen algunas salidas beneficiosas provenientes del desarrollo de los escenarios. En primer lugar, la
empresa está más preparada y organizada para manejar situaciones futuras y planificar los recursos
necesarios. En segundo lugar, una serie de supuestos de planificación se identifican en cada escenario que
revela cuáles son las prioridades de la empresa si un escenario ocurriera. En tercer lugar, la planificación
de las futuras capacidades es más coordinada, en lugar de simplemente reunir entradas independientes
Paso 14: Identifique las suposiciones de planificación para cada escenario futuro.
Describa cada escenario futuro en forma de narración, es decir un posible entorno operativo del negocio/
tecnología que la empresa puede perseguir. En este paso, los elementos clave de cada escenario futuro
se analizan para revelar qué cosas son importantes para la empresa y qué cambios tienen que ocurrir
para que el escenario se convierta en realidad. Para los propósitos de la AE, estos elementos se convierten
en los principales supuestos de planificación que pueden ser agrupados para representar los cambios
en cada una de las áreas funcionales de la estructura. Uno de los beneficios de contar con el escenario y
los supuestos de planificación es que se han desarrollado con las partes interesadas del negocio, lo que
ayudará a que los cambios se implementen en el futuro.
Paso 15: Use escenarios, programas y actualizaciones al cronograma para gestionar la documentación
de los componentes arquitectónicos en todas las áreas del marco arquitectónico.
Este paso deberá documentar los cambios en los componentes arquitectónicos en el corto plazo
(1-2 años) y a largo plazo de 3-5 años. Estos cambios deben derivarse de la entrada, por el equipo de
liderazgo (CXOs) a través de escenarios operativos y asunciones en la planificación y de los directores
de los programas y proyectos que saben cuáles son los requisitos futuros del negocio, así como las
implementaciones planificadas, actualizaciones y jubilaciones del sistema. Al hacerlo de esta manera, los
cambios son más coordinados y alineados con la dirección estratégica de la empresa. Las futuras vistas de
los componentes de AE deben ser desarrolladas utilizando los mismos artefactos de la documentación
y técnicas de modelado que se utilizan para desarrollar la vista actual. Esto ayuda a identificar más
claramente cuáles son los cambios en cada uno de los niveles funcionales del marco de AE, que ayudan
en la planificación y toma de decisiones.

Paso 16: Desarrolle el Plan de Gestión arquitectónico para secuenciar los cambios planificados en la AE.
El paso final en la Fase III es el desarrollo es el Plan de Gestión arquitectónico que le servirá para articular
la forma en la que fue desarrollada la AE y proporcionar un resumen de los de las vistas actuales y futuras.
El Plan también le proporcionará un sub-plan de transición y secuenciación para los cambios a corto
plazo, que pueden estar ya en el escenario de pre-implementación del proyecto. Además, un sub-plan
de secuenciación de largo alcance será provisto para que cubra los posibles cambios asociados con los
escenarios futuros. En la unidad 7 se proporciona más detalles sobre el desarrollo de Plan de Gestión de
AE.
Fase IV: Uso y Mantenimiento de la información arquitectónica
La Fase IV es un conjunto continuo de actividades que promueven el uso de la información por todos los
interesados, y se establece un ciclo anual para las actualizaciones. Aquí es donde usted observará el valor
real del programa de AE, como la planificación y toma de decisiones que soporta a toda empresa. Este
valor se mantiene a través de actualizaciones periódicas de las vistas actuales y futuras de la arquitectura.
Paso 17: Use la información para la planificación de recursos / toma de decisiones.
Tras la finalización de la Fase III, las vistas actuales y futuras de la arquitectura se almacenan en el
repositorio AE y están listas para ser utilizados por la empresa para apoyar el proceso de planificación
y toma de decisiones. Estos artefactos almacenados se convierten en un punto de información de
referencia que puede utilizar en una amplia variedad de actividades de ejecución, gestión y actividades
del personal. Cuando se hace esto, un mayor nivel de comprensión de las capacidades y brechas de
rendimiento se desarrollan entre un grupo más amplio dentro de la empresa.
Además, al contar con la documentación arquitectónica en un repositorio on-line, usted podrá referir a la
misma en las reuniones ejecutivas de revisión de estado, lo que permitirá reducir el tiempo para transmitir
una idea, aumentar la comprensión, y reducir los errores de interpretación entre los participantes de la
reunión.
El tiempo para transmitir las ideas se reduce significativamente cuando los diagramas y los textos se
muestran a todo el mundo en la reunión. Esto puede estimular más discusiones productivas e informar
las decisiones.
Paso 18: Actualice regularmente las vistas actuales y futuras de los componentes arquitectónicos.
La información en el repositorio será valiosa para la planificación y la toma de decisiones solamente

cuando esta sea exhaustiva y precisa. Por lo tanto, es importante que actualice con regularidad las vistas
actuales y futuras de los componentes arquitectónicos en todas las áreas del framework. Además, será
útil para los usuarios de esta información si las actualizaciones se realizan de acuerdo a una planificación
regular, tal vez dos veces al año.
También, es importante que mantenga el control de versiones entre las actualizaciones, de modo que
todos los usuarios de del repositorio conozcan que se están llevando a cabo las tareas de planificación y
toma de decisiones sobre la base de las actividades de la misma información. Dado que lo que se prevé
en las vistas futuras de AE eventualmente se conviertan en la arquitectura actual (por lo menos parte de
ella), debe reconocer que las actualizaciones son actividades en curso que no cesan.
Por otra parte debe considerar que los planes arquitectónicos futuros continuarán a medida que la
organización crezca y cambie. Si esto ocurre, las transiciones en los programas de AE deberán centrarse
en el establecimiento de la AE para el mantenimiento de la misma y proyectándola a la misma.

Paso 19: Mantenga el repositorio y las capacidades de modelado.
El Arquitecto en Jefe y el equipo de AE deben asegurarse de que el repositorio y soporte de aplicaciones/

herramientas se mantengan al día en términos de concesión de licencias y funcionalidad. Deberá revisar
anualmente los requisitos para el archivo y el modelado y los nuevos productos deben ser revisados
regularmente para asegurar que el equipo de AE tenga la capacidad adecuada de soporte a aplicaciones.
El equipo debe estar en la búsqueda de nuevas mejoras en la funcionalidad de la herramienta para que
estas puedan ser aplicadas en beneficio de la empresa. El costo para la compra de software y renovación
de licencias debe ser parte del presupuesto anual del programa AE.
Paso 20: Versione las actualizaciones anuales del Plan de Gestión de AE.
El arquitecto en jefe tiene que informar periódicamente a las partes interesadas sobre el estado de avance
del programa. Esto se hace a través de la emisión anual de un Plan de Manejo en el que se describan
los cambios que se hicieron tanto a la vista actual como futura en el último año. La comunicación debe
proporcionar un plan de transición y secuenciación de los cambios previstos para el año que viene.
Actividad Propuesta
Revise el caso “La Importancia de la Metodología “propuesto en el entorno
virtual de aprendizaje EVA con la finalidad contextualizar el tema. Luego asocie
lo encontrado en el caso de estudio con las temáticas estudiadas en el presente
capítulo
Resumiendo.
En esta unidad estudió una metodología integral para la implementación de un programa arquitectónico
y las actividades de documentación asociadas. Las cuatro fases y veinte pasos de la metodología se
generalizan para que puedan ser utilizados en muchos tipos de empresas tanto del sector público y
privado.
Las actividades de la Fase I le serán útiles para establecer el programa de AE, identificar un arquitecto
jefe para dirigir el programa, crear una capacidad de gobierno para ejecutar el programa de forma que
se integre con otros procesos de gestión de TI, y emitir un Plan de Comunicación para ganar el apoyo
de los interesados. Las actividades de la Fase II, servirán para seleccionar un marco de AE en el que se
defina el alcance de la arquitectura, los componentes de AE que conformarán la arquitectura en cada
área funcional, y el software de aplicaciones / herramientas para automatizar la documentación de los
componentes, en la fase III es donde la documentación de los puntos de vista actuales y futuros de la
arquitectura se producen, así como el desarrollo de un Plan de Gestión de AE para describir la transición
de la arquitectura en el tiempo. Las actividades de la fase final (Fase IV) son usadas a través de la empresa
para apoyar la planificación y la toma de decisiones y las actualizaciones periódicas que se realizan para
mantener la relevancia de la AE.

Autoevaluación 2

1. La metodología arquitectónica:
a. Es una estructura para organizar la información que define el ámbito de la arquitectura.

b. Define como se llevará a cabo y cómo se desarrollará la documentación a utilizar y archivar,
incluyendo la selección del marco, las herramientas de modelado, y el repositorio on-line.
c. Los paso para obtener la vista arquitectónica actual.
2. El plan de comunicación arquitectónico:
a. Debe incluir una síntesis del propósito y la visión arquitectónica, donde estará disponible
la documentación para su acceso, un resumen de la metodología utilizada, así como los
principios generales que serán utilizados para su desarrollo.
b. Identifica a los grupos de interés a los que se comunicará el arranque del programa
arquitectónico.
c. Identifica las áreas de la empresa que el enfoque arquitectónico cubrirá, y cómo aquellas
áreas se relacionan.
3. Un artefacto arquitectónico:
a. Son actividades de negocios y tecnología, programas y proyectos que permiten el logro de

los objetivos estratégicos
b. Es un producto de documentación como un documento de texto, especificación del sistema,
información de interfaz de la aplicación, diagramas, hojas de cálculo, etc.
c. Una actividad del proceso de gestión arquitectónica.
4. El primer paso dentro de la metodología de implementación de un programa arquitectónico

implica:
a. Establecer el Programa de Gestión Arquitectónico e identificar a Arquitecto en Jefe.

b. El establecimiento de la metodología de implementación arquitectónica.
c. El desarrollo de plan de comunicación para ganar interesados.

5. Las iniciativas transversales:
a. Identifican las áreas de la empresa que el enfoque arquitectónico cubrirá, y cómo estas se
relacionan.
b. Son también conocidas como segmentos
c. Son actividades horizontales que funcionan en un ambiente operativo común a través de
varias LOB.
6. Una vez que conozca las áreas funcionales, los niveles de la estructura y los tipos de componentes
arquitectónicos:
a. Podrá establecer la documentación y artefactos del programa

b. Podrá identificar las líneas de negocio.
c. Podrá definir la metodología de implementación.
7. En el nivel estratégico, los componentes a ser documentados son:
a. La línea de servicios del negocio y las medidas asociadas

b. Los objetivos estratégicos, las actividades y las medidas de resultado.
c. Los flujos de información, bases de datos, almacenes de conocimientos y estándares de
datos.
8. Los escenarios operativos futuros:
a. Proporcionan un sub-plan de transición y secuenciación para los cambios a corto plazo, que
pueden estar ya en el escenario de pre-implementación del proyecto.
b. promueven el uso de la información por todos los interesados, y se establece un ciclo anual
para las actualizaciones.
c. Permite una comprensión de alto nivel de las posibles alternativas futuras que la empresa
podría tomar, dependiendo de cómo responde a influencias internas y externas.
9. Antes de establecer el programa arquitectónicos se debe:
a. Establecer la metodología de desarrollo

b. Identificar las líneas de negocio
c. Identificar los artefactos y componentes.
10. En las actividades de Fase II de la metodología de implementación.
a. Se selecciona el marco de documentación arquitectónica.

b. Se desarrolla el enfoque de gobierno arquitectónico, que habilita políticas, planes, y el
proceso toma de decisiones efectivas dentro del programa de gestión
c. Se promueve el uso de la información por todos los interesados, y se establece un ciclo
anual para las actualizaciones.

UNIDAD 3. COMPONENTES Y ARTEFACTOS ARQUITECTÓNICOS
En la presente unidad se define y describe los componentes y artefactos que usted deberá tomar
en cuenta en la implementación de un programa de arquitectura empresarial. Los componentes
arquitectónicos son elementos reemplazables dentro del marco, los mismos que van y vienen con los
cambios en la estrategia, servicios de negocio y nuevos diseños para los recursos relacionados con
los flujos de información, aplicaciones, redes y otras infraestructuras. Se proporcionan descripciones
(ejemplo) de los componentes, en cada nivel de la estructura arquitectónica.
Componente.
Recursos “plug-and-play” intercambiables que proporcionan capacidades en cada
nivel de la estructura. Algunos ejemplos que podemos citar son los objetivos e
iniciativas estratégicas, los servicios empresariales, flujos de información y objetos
de datos; sistemas de información, servicios web y aplicaciones de software; redes
de voz / datos / vídeo / móvil, plantas de cable, equipos y edificios.
Artefacto.
Un artefacto arquitectónico es un producto de documentación, como un
documento de texto, diagramas, hojas de cálculo, diapositivas informativas o
videoclips. Los artefactos documentan a los componentes de manera consistente
a través de toda la arquitectura.
La presente unidad le permitirá a usted:
• Entender el papel que cumplen los componentes en un marco arquitectónico.

• Entender cómo los artefactos describen a los componentes arquitectónicos.
• Ver ejemplos de componentes y artefactos dentro de un marco de AE.
• Entender como las vistas de gestión ejecutiva ayudan a comprender a los componentes
arquitectónicos.
Si bien un marco de AE le proporciona una estructura general para el modelado de negocios y un entorno
operativo para la tecnología, los componentes arquitectónicos son los elementos de trabajo en cada
nivel de la estructura. En otras palabras estos componentes son considerados “bloques de construcción”
(Building blocks) que crean piezas individuales con capacidades globales dentro del funcionamiento de
TI. Los artefactos describen a los componentes arquitectónicos.
Para aclarar el contexto arquitectónico lo invitamos a revisar la siguiente analogía de la arquitectura

empresarial con respecto a la arquitectura tradicional.
Los componentes arquitectónicos son como las habitaciones de una casa. Las habitaciones pueden ser
agregadas, remodeladas o removidas. Los productos de la documentación arquitectónica son la descripción
de las habitaciones, y pueden incluir declaraciones, relatos, imágenes y/o videos.
Es importante que tome en consideración, que los componentes arquitectónicos son elementos
activos dentro del ambiente operativo de negocios y de tecnología de la empresa; estos incluyen
los objetivos e iniciativas estratégicas relacionadas con TI, las cadenas de suministro, los sistemas de
información, aplicaciones de software, almacenes de conocimiento, bases de datos, sitios web, redes
de voz, datos,vídeo y sistemas de seguridad. Estos componentes deben funcionar juntos para crear un
entorno operativo robusto y transparente de TI que apoye eficazmente a las necesidades de negocio

de la empresa. La disponibilidad, fiabilidad, seguridad, escalabilidad y rentabilidad son áreas clave

de medición del desempeño para el entorno operativo de TI en general. Estas áreas se aplican a cada
componente, junto con medidas para la integración y la reutilización.
Ahora en cuanto a los artefactos arquitectónicos, estos son el tipo de documentos que describen a los
componentes, en los que se incluyen informes, diagramas, tablas, hojas de cálculo, archivos de vídeo y
otros tipos de información registrada. Podemos distinguir artefactos de nivel alto, medio y bajo:
• Los artefactos de alto nivel suelen ser documentos de texto o diagramas que describen las
estrategias generales, programas y resultados deseados.
• Los artefactos de nivel medio son documentos, diagramas, tablas, hojas de cálculo, e informes que
describen los procesos organizacionales, proyectos en marcha, cadenas de suministro, sistemas
grandes, flujos de información, redes y sitios web.
• Los artefactos de bajo nivel describen aplicaciones específicas, diccionarios de datos, normas
técnicas, interfaces, componentes de red, y armarios de cableado.
Cuando estos artefactos se armonizan a través de una taxonomía arquitectónica, se generan nuevas y
más útiles vistas del funcionamiento de los componentes. Este es uno valores más importantes de la AE
en el proceso de documentación, la creación de una capacidad jerárquica de las vistas de la empresa que
pueden examinarse desde varias perspectivas.
Por ejemplo, tome en cuenta que mediante el reconocimiento de los componentes

que son los bloques de construcción de un marco de AE, y debido a que la mayoría de
hardware y software es propietario (frente a la costumbre de ser desarrollado in-
house), el escenario está listo para un enfoque “plug-and-play” para soporte de TI, que
debe reflejarse en todos los niveles del marco de AE, la Figura 3.1 le proporciona
ejemplos de los componentes y artefactos en todos los niveles del Marco.
Figura 3.1: Componentes de AE y Artefactos tomado de Scott A. Bernard 2012
En la siguiente sección se detallan los componentes y artefactos arquitectónicos que forman parte
de cada uno de los niveles del marco, es importante que ponga mucha atención a la descripción de

los mismos pues son la base para el levantamiento de las vistas actuales y futuras de la arquitectura
organizacional, adicionalmente indicar que para cada artefacto se hace una referencia al ANEXO 2 donde
encontrara un descripción detallada del mismo.
3.1. Componentes arquitectónicos: Nivel Objetivos e Iniciativas
Componentes AE:
• Plan Estratégico
• Plan de Comercio/Gobierno electrónico
Artefactos:
• Plan Estratégico (S-1 Ver - Anexo pág.: 129 )
• Análisis FODA (S-2 Ver - Anexo pág:130)
• Concepto del escenario de operaciones (S-3 Ver - Anexo pág.: 131)
• Concepto de diagrama de Operaciones (S-4 Ver - Anexo pág:132)
• Balanced Scorecard (S-5 - Ver - Anexo pág: 133)
3.1.1. Plan estratégico
La planificación estratégica produce una vista de alto nivel de la dirección que la empresa establece para
sí misma. Esta dirección es más articulada en escenarios, estrategias, metas e iniciativas de largo plazo,
que sirven de base para la planificación táctica de corto plazo (operativos) la misma que se actualizan
anualmente. Los planes estratégicos en entornos dinámicos y/o altamente competitivos deben buscar
de tres a cinco años en el futuro y actualizarse anualmente. Los planes estratégicos para las empresas en
entornos más estables deben mirar de cinco o diez años en el futuro, y actualizarse cada tres años.
Un Plan Estratégico es un artefacto compuesto que debe guiar la dirección de la empresa durante un
período de 3 a 5 años en el futuro, proporcionando los elementos que se mencionan más adelante, cada
uno de los cuales son artefactos arquitectónicos primitivos (básicos).
3.1.2. Análisis FODA
Una de las primeras actividades que debe considerar en el desarrollo de plan estratégico organizacional
es el análisis FODA. En este análisis deberá enfocar los factores internos y externos para determinar
las áreas en que la empresa debe centrarse para aumentar su capacidad de supervivencia y éxito, así
como las áreas que la empresa debe evitar o disminuir su exposición. Los resultados del análisis FODA
resumirán en el plan estratégico, el mismo que debe archivarlo en el repositorio de AE como un artefacto
primitivo por separado (S-2). La Figura 4.2 es un ejemplo de la forma de presentar los resultados de un
análisis FODA.


Factores Externos Fortalezas Internas (F) Debilidades Internas (D)

F1: Comunidad de usuarios D1: Políticas /Regulaciones
Factores Internos F2: Relaciones D2: Governanza
F3: Liderazgo D3: Habilidades Sistemas de TI
F4: Tecnología In_house D4: Arquitectura Empresarial
F5: Arquitectura Legada D5: Habilidades Sistemas de TI
F6: Presupuesto Capacitación D6: Baja Usabilidad/
F7: Cultura Implementación
Oportunidades Externas
01. Contratos
FO DO
02. Gobierno
F5/O3: Portales Web Legados D4/O3: Implementar AE
03. Nueva Tecnología
F1/O3: Seguridad
04. Asociaciones
Amenazas Externas
A1: Financiamiento
FA DA
A2. Conductores del Mercado
F1/A2: Obtención
A3. Avance de la Tecnología
requrimientos D4/A1: Financiamiento
A4. Ratios de adopción de TI
F6/A5: Entrenamiento en TI
F1/D5: Concientización
procesos de TI
Figura 3.2: Ejemplo de análisis de tabla Resumen FODA tomado de: Scott A. Bernard 2012
Figura 3.2: Ejemplo de análisis de tabla Resumen FODA tomado de: Scott A. Bernard 2012
3.1.3. Concepto de Escenarios de Operaciones
3.1.3 Concepto de Escenarios de Operaciones
Las empresas
pueden encontrar útil desarrollar el concepto detallado de operaciones (CONOPS) de los
escenarios actuales
Las empresas pueden y futuros que abarcan
encontrar varios años
útil desarrollar de funcionamiento
el concepto de operaciones
detallado de una actividad(CONOPS)
que tiene en
cuenta las diferentes combinaciones de los factores internos y externos que se identificaron en el análisis
de los escenarios actuales y futuros que abarcan varios años de funcionamiento de una actividad
FODA. De este modo, la empresa puede evaluar los supuestos de planificación y los resultados esperados
que escenario
en cada tiene en cuenta
y evaluar lasel diferentes combinaciones
mérito relativo de seguir
y el peligro de los factores internos
un curso y externos
de acción particular.que se
Además,
la empresa
identificaronpuedeenrefinar y mantener
el análisis FODA.un Dearchivo permanente
este modo, de información
la empresa en varios
puede evaluar los de los escenarios
supuestos de
másplanificación
plausibles con y loselresultados
fin de ser esperados
capaz de agrupar
en cadauna serie dey estrategias
escenario y objetivos
evaluar el mérito adecuados
relativo para
y el peligro
competir con éxito.
de seguir un curso de acción particular. Además, la empresa puede refinar y mantener un archivo
permanentededeescenarios
El desarrollo informaciónpuede
en varios
ser de los escenariosvalioso
especialmente más plausibles
para lascon el fin deen
empresas serentornos
capaz de de
funcionamiento altamente
agrupar una serie dinámico
de estrategias y turbulento.
y objetivos Un resumen
adecuados de los
para competir conescenarios
éxito. y supuestos de
planificación (formato de la matriz) se incluye en el Plan Estratégico, mientras que la versión completa
de los escenarios es un artefacto “primitivo” (S-3).
El desarrollo de escenarios puede ser especialmente valioso para las empresas en entornos de
En la Unidad 6 se proporcionara
funcionamiento más detalles
altamente dinámico sobre elUn
y turbulento. desarrollo
resumendedeescenarios futurosy de
los escenarios AE.
supuestos de
planificación (formato de la matriz) se incluye en el Plan Estratégico, mientras que la versión
completa de los escenarios es un artefacto "primitivo" (S-3). En la Unidad 6 se proporcionara más
detalles sobre el desarrollo de escenarios futuros de AE.
72


Figura 3.3: Preguntas que dirigen el desarrollo de un ConOps, tomado de: Desarrollo de un concepto de operaciones, http://
www.meted.ucar.edu/communities/hazwarnsys/ffewsrg_es/FF_EWS.Cap.9.pdf
3.1.4. Estrategia Competitiva
En esta área del Plan Estratégico identifique cómo la empresa va a lograr el éxito en base a la dirección
estratégica establecida. Esto lo debe realizar en dos niveles: en primer lugar, una estrategia general
en relación con el crecimiento, y en segundo lugar, una estrategia más específica relacionadas con la
competencia y/o diferenciación. En primer lugar, a nivel general, la empresa establece la intención de
crecer, reducir o estabilizar. Si se trata de una estrategia de cambio para recuperar el terreno perdido,
una estrategia de crecimiento para entrar en nuevos mercados la prestación de nuevos servicios, o una
estrategia de estabilización para absorber y consolidar el crecimiento o la reducción reciente, la estrategia
competitiva debe, ante todo, ser lo suficientemente flexible como para asegurar la supervivencia en
frente a los acontecimientos internos y externos no deseados, y luego promover el éxito en las metas en
que la empresa decida actuar durante el período del Plan Estratégico.
En segundo lugar, la estrategia competitiva se detalla en un comunicado sobre la diferenciación y la

entrega del producto y/o servicio. Esta área identifica uno o más métodos que la empresa va a seguir
para lograr el éxito en lo que produce. Los ejemplos incluyen la entrega de productos de alta calidad, del
precio más bajo, tener más opciones y seguridad, ser los primeros en el mercado, dominar la cuota de
mercado, y la adquisición de competencias.
Estas declaraciones involucran información sensible, que la empresa puede que desee mantener en un
anexo por separado en el Plan Estratégico.
Las metas estratégicas.
Son aquellos objetivos que, cuando se alcanzan conjuntamente, garantizan la supervivencia y la

consecución del éxito, tal como se define en las medidas de resultado y las métricas de rendimiento que
la empresa desarrolla por sí mismo. Las metas estratégicas también sirven para dividir lógicamente las
actividades empresariales en áreas que tendrán un impacto significativo y valorado en la empresa en
base a los que el Plan Estratégico establece.

Iniciativas Estratégicas
Son actividades que se encuentran dirigidas y apoyadas por los objetivos estratégicos. No todas las
actividades de una empresa son de carácter estratégico, ya que algunas actividades son funciones
de apoyo (es decir, nómina, contabilidad, gestión de infraestructura de TI y recursos humanos). Las
iniciativas que son de carácter estratégico incluyen programas en curso y proyectos específicos que
cumplen uno o más objetivos estratégicos. Una de las preguntas que a menudo se hacen los ejecutivos
en relación a decisiones de financiación, es la de, si existe un valor estratégico en el resultado previsto (s).
Las inversiones que tienen una vinculación con los objetivos estratégicos se dice que están “alineadas”.
Resultados de las mediciones
Mediante la identificación de los objetivos y las iniciativas que se pueden medir, la empresa será capaz
de gestionar estas actividades. Las medidas son los componentes más detallados en nivel estratégico
del marco de AE, y se encuentran en cada uno de los otros niveles.
Es importante entender la diferencia entre las medidas de “resultados” y las medidas de “salida”.
Medidas por resultados
• Las medidas de resultado identifican los avances logrados en pos de un nuevo estado final, tales
como una mejor calidad de los productos, el aumento de la satisfacción del cliente, o de procesos
más eficientes.
• Las medidas de resultado a menudo tienen tanto, elementos cualitativos y cuantitativos, mientras
que las medidas de salida suelen ser cuantitativas.
Medidas por salidas
• Las medidas de salida proporcionan datos sobre las actividades y los productos que se producen,
como la cantidad de autos se producen en un día, el número de nuevos clientes que se ganan o se
pierden cada mes, o hasta qué punto una actividad reúne una lista de control de calidad.
• Las medidas de salida son importantes para indicar el progreso de un área, son resultados que se
correlacionan con el logro de metas y el progreso estratégico de la empresa. A continuación se
presentan ejemplos de resultados y mediciones de producción.
m Medida de Resultado # 1: Mejorar el entorno de seguridad de la fábrica por la reducción de

las lesiones en un 5 por ciento en un año.
m Medida Salida # 1-1: Aumentar el número de inspecciones de seguridad en un 10 por ciento.
m Medida Salida # 1-2: Requiere 100 por ciento de uso de cascos de seguridad y gafas.
m Medida Salida # 1-3: Exigir la finalización de accidentes dentro de las 24 horas.
3.2. Plan de Comercio /Gobierno Electrónico
Un Plan de Comercio/Gobierno Electrónico a menudo es necesario en una empresa, adicional al plan

estratégico general. Esto se debe a que el Plan Estratégico por lo general no se lo trata de manera
suficientemente detallada para identificar las diversas iniciativas relacionadas con TI, que pueden
permitir que muchos de los objetivos estratégicos de una empresa sean abordados. Esto se dice en
reconocimiento a que muchas empresas se están convirtiendo en empresas “centradas en la información”,

ya que dependen de la información y de los recursos de TI para llevar a cabo y con éxito sus negocios
clave, (manufactura, servicios, investigación, recursos financieros, recursos humanos funciones de
oficina, etc.).
El Plan Comercio/Gobierno Electrónico no es más que un plan táctico debido a la naturaleza dinámica
de los recursos de TI y los procesos que los soportan. El Plan de Comercio/Gobierno Electrónico debe
ofrecer programas específicos, de resultados y rendimiento de la información en un plazo de dos o tres
años. Más allá de unos tres años, es difícil predecir con exactitud lo que las nuevas capacidades de TI
serán capaces de proporcionar. El Plan de Comercio/Gobierno Electrónico debe actualizarse cada 1-2
años.
3.3. Componentes Arquitectónicos: Nivel de Productos y Servicios
Componentes:
• Servicios del negocio

• Productos del negocio
• Planificación y Control de Inversiones de Capital de TI
Artefactos:
• Plan de negocios (B-1 Ver - Anexo pág:134)

• Diagrama de conectividad de nodos (B-2 Ver - Anexo pág:135)
• Diagramas de Proceso (B-3 Ver - Anexo pág:136)
• Diagrama de procesos de negocio(B-4 Ver - Anexo pág:137)
• Matriz de actividad/productos (B-5 Ver - Anexo pág:138 )
• Casos de uso y diagramas narrativos (B-6 Ver - Anexo pág:139 )
• Caso de Negocio de Inversiones (B-7 Ver - Anexo pág:140)
Es fundamental que identifique que los principales procesos de negocio y de soporte son documentados
en el nivel del Negocio del marco. Los componentes de AE a este nivel incluyen la documentación de
procesos de negocio y la cartera de planificación de capital de TI, la misma que proporciona los casos de
negocio por cada inversión en TI que cumpla los umbrales financieros y operativos. Las relaciones entre
los participantes en las actividades de gobierno electrónico E-Commerce se refieren a menudo como “B”
para los negocios, “G” para el gobierno, y “C” para los ciudadanos, lo que resulta en siglas como B2B para
negocio-a-negocio y G2C de gobierno a los ciudadanos.
3.3.1. Servicios del negocio
Son aquellas actividades empresariales que contribuyen directamente al logro de la misión. Esto puede
ser en forma de iniciativas estratégicas para el desarrollo de servicios nuevos o mejorados, servicios o
artefactos, actividades en curso de fabricación, prestación de servicios públicos y “back office”, finanzas,
contabilidad, administración y funciones de recursos humanos. La documentación de los procesos de
negocio incluye diagramas de flujo y técnicas de modelado en donde se detallan las entradas, salidas,
recursos habilitantes y controles de una actividad empresarial. También incluye la documentación de
las actividades que rediseñan completamente un proceso organizacional (llamado Reingeniería de
Procesos-BPR), y las actividades que proporcionan ajustes menores a un proceso (llamado Business
Process Improvement-BPI).

Sistemas Back-Office
Unback office(trastienda de la oficina) es la parte de lasempresasdonde se realizan las
tareas destinadas a gestionar a las mismas y con las cuales el cliente no necesita
contacto directo.
3.3.2. Productos del negocio
Son bienes tangibles e intangibles que la empresa produce en el ejercicio de las actividades y objetivos
estratégicos. Algunos ejemplos son los artículos manufacturados, los instrumentos financieros, vehículos,
estructuras, el capital intelectual, arte, música y eventos especiales.
La documentación de los productos de negocio es importante para una empresa, ya que recoge y protege
el capital intelectual, patentes, marcas comerciales y derechos de autor. Además, esta documentación es
útil en las actividades de BPR y BPI. Los artefactos de AE que los productos empresariales contienen es
información confidencial que debe ser protegida cuando se archiva en el repositorio de AE.
3.3.3. Planificación y Control de Inversiones de Capital
Es necesario destacar que los recursos son limitados en la mayoría de las empresas, por lo que, el valor
de hacer una importante inversión en TI debe ser mostrada a fin de identificar los costos, los beneficios y
la tasa de rendimiento del capital. Un “caso de negocio” para cualquier inversión es un formato estándar
para el desarrollo y la presentación de los diferentes aspectos en cuanto a alternativas, costos y beneficios,
para que los ejecutivos se interesen. Un caso de negocio debe incluir:
• Declaración de Requisitos:
• Análisis de Alternativas
• Análisis Costo-Beneficio
• Cálculo del Valor Actual Neto
• Cálculo Retorno de la Inversión
El proceso de Planificación y Control de Inversiones de Capital TI (CPIC) se convertirá en una actividad

clave de gestión y que usted deberá tener muy en cuenta para diseñar, planificar, seleccionar, controlar
y evaluar las grandes inversiones de la empresa en TI. El proceso CPIC trabaja en conjunto con el Plan de
Gestión de AE para mover una empresa desde la actual arquitectura a la futura de forma permanente.
Considere el uso de planes estandarizados de gestión de proyectos de TI que le ayuden a que el proceso
de CPIC sea más eficiente y más útil para los administradores de proyectos
3.4. Componentes Arquitectónicos: Nivel de Datos e Información
Componentes:
• Almacenes Conocimiento
• Sistemas de Información
• Bases de datos
Artefactos:
• Plan de Gestión del Conocimiento (D-1 Ver - Anexo pág: 141)

• Matriz de Intercambio de Información (D-2 Ver - Anexo pág:142)

• Diagrama de transición de estados (D-3 Ver - Anexo pág:143)
• Diagrama de secuencia (D-4 Ver - Anexo pág: 144)
• Modelo lógico de datos (D-5 Ver - Anexo pág: 145)
• Modelo físico de datos (D-6 Ver - Anexo pág:146)
• Actividad / Entidad (CRUD) (D-7 Ver - Anexo pág: 147)
• Diccionario / Librería de objetos de datos (D-8 Ver - Anexo pág:148 )
Los componentes arquitectónicos en este nivel incluyen documentación sobre el diseño, el

funcionamiento y la gestión de sistemas de información, bases de datos, almacenes de conocimiento
(Knowledge Warehouse), y almacenes de datos (Data Marts). También incluyen documentación detallada
sobre la estructura y la lógica de procesamiento de datos en los que la empresa está interesada.
3.4.1. Almacenes de Conocimiento (Data Warehouse – Data Marts)
Evolucionaron a partir de grandes bases de datos centrales que sirvieron a múltiples aplicaciones y
grupos de usuarios a través de múltiples sistemas y redes. Un almacén de conocimiento es un repositorio
específico para los datos y la información de las distintas actividades y procesos de la empresa. Cuantos
más tipos de datos e información se encuentren en el almacén de conocimiento, estos serán mejor
valorados para actividades de análisis que van más allá de simples consultas y generación de informes;
permiten Minería de Datos en todos los niveles de la empresa para buscar patrones o nueva información.
Esto ayuda a construir nuevos puntos de vista de las actividades de la empresa.
Por lo general, los usuarios interactúan con el almacén de conocimiento a través de una interfaz del portal
que permite el acceso personalizado a diversos elementos tales como bases de datos, presentaciones y
datos, audio y archivos de vídeo. Un almacén de conocimiento puede ser desarrollado para uso específico
o se puede encontrar en el mercado un producto adaptable.
Figura 3.4: Arquitectura Data Warehouse – Data Mart, tomado de: Introduction to Data Warehousing and Business
Intelligence, disponible en http://docs.oracle.com/cd/B28359_01/server.111/b28318/bus_intl.htm#i32143
3.4.2. Sistemas de Información
La información se presenta en tres formas: datos, información y conocimiento. Agregación, significado y

contexto son lo que diferencia cada una de estas formas.
Ahora veamos las siguientes definiciones:

Datos:
Hechos crudos sobre personas, lugares, eventos, y cosas que son importantes en una
organización.
Información:
Los datos que han sido procesados o reorganizados de forma significativa para
alguien. La información se forma a partir de combinaciones de datos que se espera
que tengan significado para el receptor.
Conocimiento:
Los datos y la información que se refina sobre la base de los hechos, verdades,
creencias, juicios, experiencias y conocimientos del receptor. Lo ideal sería que la
información conduzca a la sabiduría. Los sistemas de información se componen de
hardware y software que trabajan juntos para recopilar y difundir datos de manera
eficiente, así como para permitir el desarrollo y análisis de información. Los sistemas
de información sirven para muchas líneas de negocio en las empresas, incluido el
apoyo administrativo y financiero, la fabricación, la comercialización y las ventas, la
regulación gubernamental, los servicios públicos y los sistemas de defensa.
Los sistemas de información fueron originalmente diseñados para soportar una
necesidad particular de una empresa y conectarse a una sola base de datos. Dado que
las empresas desarrollan más aplicaciones para los sistemas de información, una
mayor eficiencia se logra cuando varios sistemas de información comparten una base
de datos
3.4.3. Bases de datos
Son aplicaciones de software que están diseñadas para soportar el almacenamiento, recuperación,
actualización y eliminación de elementos de datos y/u objetos de datos. Los elementos de datos son
los hechos y valores fundamentales que se almacenan en bases de datos. Los elementos de datos, su
identificación y atributos característicos son generalmente almacenados en bases de datos relacionales
que constan de tablas de datos que están relacionadas lógicamente para crear una capacidad de
consulta rápida, eficiente y flexible. Los objetos de datos son “bloques” discretos de código que
contienen información de atributos acerca de un elemento de datos, así como comportamientos que
crean una capacidad, para interactuar entre sí y de diferentes maneras, dependiendo del tipo de evento
desencadenante.
3.5. Componentes Arquitectónicos: Nivel de sistemas y aplicaciones
Componentes:
• Aplicaciones de software
• Servicios Web (Web Services)
• Bus de Servicios y Middleware
• Planificación de recursos empresariales (Soluciones ERP)
• Sistemas operativos
Artefactos:
• Diagrama Interfaces sistema (SA-1 Ver - Anexo pág:149 )

• Diagrama de comunicación del sistema (SA-2 Ver - Anexo pág:150)
• Matriz de Interfaces del Sistema (SA-3 Ver - Anexo pág:151)
• Diagrama de flujo datos del sistema (SA-4 Ver - Anexo pág:152)

• Matriz de Sistemas/Operaciones (SA-5 Ver - Anexo pág:153)

• Matriz de Sistemas de Intercambio de Datos (SA-6 Ver - Anexo pág:154)
• Matriz de Rendimiento del sistema (SA-7 Ver - Anexo pág:155)
• Diagrama de la evolución del sistema (SA-8 Ver - Anexo pág:156)
• Diagrama de la aplicación Web (SA-9 Ver - Anexo pág:157)
Los sistemas y las aplicaciones que su empresa utilice para apoyar a los servicios empresariales,
procesos de entrega de productos, y flujos de información están documentados en el nivel “Sistemas
y Aplicaciones” del marco. Uno de los propósitos de la AE es mejorar la integración y la eficiencia de los
sistemas de soporte y aplicaciones de software en toda la empresa. La duplicación de funciones y la falta
de interoperabilidad pueden abordarse mediante el establecimiento de normas técnicas y de producto
para el software.
3.5.1. Aplicaciones de software
Son programas de software que proporcionan capacidad funcional para el “front-office” de los
sistemas de TI (por ejemplo, la fabricación, las ventas, los servicios públicos, la logística y almacenes de
conocimiento) o sistemas informáticos “back-office” (por ejemplo, los sistemas financieros, sistemas de
recursos humanos, el correo electrónico, y los productos de automatización de oficina, procesadores de
texto, hojas de cálculo, herramientas de creación de diagramas, editores de fotografía, y los navegadores
web). Las empresas a menudo poseen una gran variedad de aplicaciones de diferentes proveedores lo
cual limita la capacidad para funcionar juntos. La selección de las solicitudes de un número controlado
de proveedores que se adhieran a normas ampliamente aceptadas, es un método que se puede utilizar
para promover la interoperabilidad de las aplicaciones de software.
Sistemas Front-Office
Es el conjunto de las estructuras de una organización que gestionan la interacción
con el cliente, es el lugar donde el cliente entra en contacto con la empresa. Puede
ampliar sus conocimientos en la siguiente dirección electrónica.
http://www.hbs.com.py/index.php?option=com_content&view=category&id=36&la
yout=blog&Itemid=59
3.5.2. Servicios Web (Web Services)
Al igual que en las tendencias, en la AE se está haciendo hincapié en el uso de aplicaciones de software
plug-and-play ampliando de manera significativa y acelerada el concepto de usar servicios de TI basados
en la web. Los estándares abiertos basados en servicios web están reemplazando a las aplicaciones de
software que tienen alojamiento y requisitos de acceso único.
Mediante el uso de los protocolos TCP, IP, SOAP y UDDI para la gestión de servicios web y los formatos
aceptados internacionalmente para la recuperación/intercambio de información, (por ejemplo, HTTP,
HTML, J2EE y XML), se crea un entorno de alojamiento y operación común para la web de servicios como
lo muestra la Figura 4.5. Un servicio web se define como cualquier recurso de TI (por ejemplo, aplicación,
programa, base de datos, o el portal de información) que funciona a través de una interfaz gráfica de
usuario (GUI), como un navegador web. Los servicios web incluyen correo electrónico, aplicaciones ERP,
sitios, sistemas de comercio electrónico, almacenes de conocimientos y prácticamente cualquier parte
frontal o función de back-office que es basado en la web, y que opera dentro de la empresa utilizando el
protocolo TCP a través de redes internas compatibles basadas en IP (Intranets). La Arquitectura Orientada
Servicios (SOA) es el concepto relacionado que se centra en los servicios web.

Figura 3.5 Patrón arquitectónico – Web Services, tomado de: Web ServicesPattern Disponible en https://
enterprisearchitecture.nih.gov/Pages/WebServicesArchitecturePattern.aspx
Arquitectura Orientada a Servicios (SOA)

Es un estilo arquitectónico de TI que soporta la transformación de su empresa
mediante un conjunto de servicios vinculados o tareas empresariales repetibles a las
cuales se puede acceder en una red cuando sea necesario. Puede ampliar sus
conocimientos en la siguiente dirección electrónica:
http://www.ibm.com/developerworks/ssa/webservices/newto/
3.5.3. Bus de Servicios / Middleware
El Bus de Servicios Empresariales (ESB-SOA) configura un entorno operativo común para los sistemas,
aplicaciones y servicios web de la empresa, se caracteriza por los protocolos no patentados y estándares
abiertos y middleware para el intercambio de datos, interfaces de software / hardware.
El ESB es independiente de la plataforma y permite a cualquier sistema y/o servicio interoperar con
cualquier otro sistema/servicio que este lógica y físicamente vinculado al Bus como lo muestra la Figura
3.6. SOA promueve el apoyo de las funciones de negocio a través del uso de servicios reutilizables,
compartidos, que cada vez están basados en web. Los enfoques SOA que utilizan esta capacidad son la
“Red Empresarial Virtual”, y para el ESB una plataforma de aplicaciones de red.
Middleware es un programa de software que une otras aplicaciones en conjunto, ya, que de otro modo no
serían capaces de intercambiar datos e información. Los ejemplos incluyen la integración de aplicaciones
legadas y bases de datos de a aquellas que están basadas en la web, o para permitir el intercambio de
datos entre objetos de diferentes proveedores que pueden tener diferentes interfaces de programación
de aplicaciones (API) que incorporan estándares como el Simple Object Access Protocolo (SOAP) o la
Transferencia de Estado Representacional (REST).

Figura 3.6: Ejemplo de alto nivel de la conectividad provista por un ESB (Bus de Servicios Empresariales) tomado de:
Introduction to the Microsoft ESB Guídense, disponible en http://msdn.microsoft.com/en-us/library/ff648282.aspx
3.5.4. Planificación de recursos empresariales (ERP Solutions)
Son comercializadas por vendedores como una manera de aumentar la interoperabilidad de las
aplicaciones y reducir la duplicación de funciones. A menudo se basa en “módulos”; los ERPs son
esencialmente un conjunto de aplicaciones que ofrece el mismo proveedor y que están diseñados para
trabajar juntos, con la finalidad de generar capacidad en toda la empresa. Las soluciones ERP existen para
finanzas, marketing, recursos humanos, nómina y contabilidad, y gestión de la cadena de suministro,
todos los cuales se pueden interconectar para crear un ambiente relativamente integrado para compartir
información. Mientras los ERPs logran algunos de los objetivos de la AE, no llegan a proporcionar la
planificación integral, documentación y soporte para toma de decisiones que la AE tiene la intención de
desarrollar y mantener.
Además, los ERPs normalmente no son capaces de soportar todos los requerimientos de las aplicaciones
de la empresa (es decir, la ofimática, las finanzas y la contabilidad, soporte de línea de producto, toma
de decisiones ejecutivas, e-mail, etc.). Esta amplia cobertura aún incompleta de requisitos de los
componentes de la aplicación es uno los problemas de los sistemas ERP que el programa de AE puede
resolver mediante el establecimiento de normas para la integración de los módulos del ERP con otras
aplicaciones.
Sistemas Operativos
Son aplicaciones que permiten a las computadoras proporcionar una red básica y
funciones de procesamiento. Las diferencias en los sistemas operativos son una gran
parte de lo que distingue a los diseños de mainframes centralizados de los nuevos
diseños de cliente-servidor descentralizados.
Las empresas más grandes pueden operar las computadoras que utilizan diferentes tipos de sistemas
operativos, lo que puede dificultar la interoperabilidad de los recursos del componente. Los Proveedores

comerciales tradicionalmente han producido sistemas operativos propietarios que están diseñados para
limitar la integración de sus propios productos, sin embargo, la proliferación de diseños de las redes
cliente-servidor y la aparición de Internet ha obligado a los proveedores a ofrecer sistemas operativos
que son cada vez más interoperables.
3.6. Componentes Arquitectónicos: Nivel Redes e Infraestructura
Componentes:
• Redes de datos
• Redes de Telecomunicaciones
• Redes de Video
• Redes Móviles
• Soluciones de Seguridad
• Edificios y salas de servidores
• Equipos
Artefactos:
• Diagrama de Conectividad Red (NI-1 Ver - Anexo pág:158 )

• Inventario de red (NI-2 Ver - Anexo pág:159 )
• Inventario de Bienes de Capital (NI-3 Ver - Anexo pág:160)
• Planos de construcción (NI-4 Ver - Anexo pág:161)
• Diagrama del centro de redes (NI-5 Ver - Anexo pág:162)
• Diagrama de la Planta de Cableado (NI-6 Ver - Anexo pág:163)
• Diagrama de elevación de Racks (NI-7 Ver - Anexo pág: 164)
Tenga presente que la perfecta integración de los recursos de voz, datos, video y transporte (cable /
Wireless) es una de las claves para crear una infraestructura de TI operacionalmente efectiva y rentable.
3.6.1. Redes de datos
Están diseñadas para el transporte de datos e información en formato digital codificado entre varios
equipos que soportan almacenamiento, recuperación, actualización y procesamiento para los usuarios
finales. Estas redes tienen un diseño lógico que identifica cómo los datos y la información fluyen entre
sistemas, aplicaciones, bases de datos y sitios web. La red también tiene un diseño físico que consiste en
una transmisión de datos “Backbone”, un entorno de alojamiento de información, y puntos de interfaz
externos (a menos que sea un sistema autónomo). La columna vertebral de la red a menudo consiste
en routers, switches, hubs, equipos de seguridad, unidades de respaldo de energía, racks de equipos y
cables adquiridos comercialmente.
3.6.2. Redes de Telecomunicaciones
Son diseñadas para transportar señales de voz en forma codificada (ondas analógicas o flujos de electrones
/ fotones digitales) entre los usuarios finales. Estas redes también tienen un diseño lógico que identifica
cómo se transportan las señales de voz entre los componentes de la red y un diseño físico que identifica
el tipo de equipo que participa en la señal procesamiento y transmisión. Esto incluye el hardware,
software, armarios de cables, nodos inalámbricos de celulares, repetidores de microondas, y satélites de
retransmisión. Estos son conocidos como sistemas de “Intercambio de negocios Pública” (PBX) que están

disponibles comercialmente por medio de vendedores. Los sistemas de telecomunicaciones que son
regionales, nacionales o internacionales en la naturaleza, a menudo implican subredes múltiples que
interactúan en numerosos puntos para aumentar la cobertura, el enrutamiento y la fiabilidad. Debido
a la presencia ubicua de las redes de telecomunicaciones, el rápido desarrollo de Internet sobre una
base global ha sido posible en gran parte debido a la conversión de la capacidad de transmisión de voz
para la transmisión dedicada de datos, así como la adición de cantidades significativas de proveedores
comerciales existentes y nuevos.
3.6.3. Redes de Video
Están diseñadas para el transporte de señales de imagen de vídeo en forma codificada (ondas analógicas
o flujos de electrones / fotones digitales) entre los centros de producción y sitios de observación. Al igual
que los otros tipos de redes, las redes de video tienen diseños lógicos para mostrar el flujo de señales
de imagen y los diseños físicos para identificar la producción, transmisión y el equipo de recepción. Las
normas nacionales e internacionales han surgido para promover la transmisión y recepción de señales
de vídeo a nivel mundial. Las redes de video pueden ser tan pequeños como aplicaciones informáticas
basadas en “punto a punto” o equipamiento de video teleconferencia WTC) que operan dentro de una
empresa o entre varios usuarios, o tan grandes como una cadena de televisión regional, nacional o
internacional.
Al igual que con las redes de voz, la codificación digital de señales de vídeo es compatible con la co-
transmisión de esta información en la misma red troncal que transporta voz y datos. Esta perfecta
integración de las capacidades de transmisión de voz, datos y vídeo aporta nuevas capacidades para el
intercambio de información dentro y entre las empresas.
3.6.4. Redes Móviles
Se centran específicamente en la prestación de conectividad para los usuarios que utilizan dispositivos
compactos que permiten conexiones remotas de voz y datos desde fuera de la misma. Esto incluye el uso
de teléfonos celulares, ordenadores portátiles, tabletas, y asistentes digitales personales. La conectividad
para redes móviles (también llamada inalámbrica) desde una distancia de hasta 50 millas se puede lograr
a través de conexiones de radio frecuencia (RF) inalámbrica entre redes de telecomunicaciones, torres de
transmisión celular y repetidores como se muestra en la Figura 3.7 de la siguiente página.
La conectividad entre los dispositivos móviles se puede lograr a través de comunicaciones por infrarrojos
de hasta 100 pies o por conexiones RF de baja potencia que ofrecen las tecnologías tales como Bluetooth
TM.
3.6.5. Redes troncales de transmisión
La capacidad de transmisión de una red de información (voz, datos o video) tiene su fundamento en la
conectividad entre los equipos de la red. Esta conectividad se puede proporcionar a través de diversos
medios, incluyendo cables (cobre o fibra de vidrio), células inalámbricas (ondas de radio de corto
alcance), torres de transmisión (microondas mediano alcance), enlaces y/o satélites (enlaces ascendentes
y enlaces descendentes de VHF, UHF, o las ondas de radio EHF). Estos “Backbone” de interconexión son
los que permiten que electrones y/o fotones fluyan en una corriente súper rápida en código binario (on
u off ) o en ondas analógicas que se traducen en datos, señales de voz, y/o señales de vídeo. Las mejoras
en el hardware, software y los medios de comunicación por cable han permitido la transmisión casi
instantánea de millones de elementos binarios llamados bits (un elemento binario) y bytes (un grupo de
8 elementos binarios).

Figura 3.7: Arquitectura de Redes Móviles para Internet, tomado de: Cisco Mobile Wireless Home Agent Release 5. Disponible
en http://www.cisco.com/en/US/prod/collateral/wireless/wirelssw/ps5940/data_sheet_c78-534715.html
La capacidad de transmitir miles de millones de bits y bytes de información digital ha permitido el

desarrollo de aplicaciones y bases de datos sofisticadas que aportan nuevas capacidades de comunicación
para personas y empresas, de manera robusta, que incluye información en forma de datos, imágenes y
sonido.
3.6.6. Vistas de gestión de los artefactos arquitectónicos
Las vistas de gestión arquitectónica son gráficos compuestos de alto nivel que representan varios
aspectos de los componentes arquitectónicos de la organización. Sin las vistas de administración, los
artefactos básicos (primitivos) pueden transformarse principalmente en modelos técnicos que no
generan interés en los patrocinadores ejecutivos y usuarios, por lo tanto, el programa de AE se puede
poner en riesgo. El propósito de las vistas de administración es reducir este riesgo a través de:
• Obtener y mantener a los patrocinadores ejecutivos y recursos

• Comunicar vistas arquitectónicas de alto nivel para la gestión.
• Listado actividades arquitectónicas de la empresa que están documentadas
Las vistas de gestión pueden ayudar a distintos tipos de usuarios a comprender y compartir los
artefactos arquitectónicos. Por ejemplo, los miembros del equipo de AE que están modelando datos en
varios sistemas de información, pueden desarrollar una visión de gestión para mostrar cómo se utiliza la
información de los sistemas entre distintas LOB’s, y al hacerlo, obtener el apoyo de los directivos en cada
áreas de negocio. Además, las vistas de gestión pueden ayudar a traducir los artefactos AE que están en
el modelado técnico o en formatos de análisis que son más fáciles de entender para los que no están
entrenados en esta metodología documentación.

Resumiendo.
En esta unidad se describe la función de los componentes y artefactos dentro de un marco de AE.
Usando la estructura del cubo EA3 como ejemplo, los componentes arquitectónicos fueron descritos
como elementos reemplazables dentro del marco de trabajo que van y vienen con los cambios en la
estrategia, servicios de oficina y los nuevos diseños de los recursos de TI relacionados con los flujos de
información, las aplicaciones y la infraestructura tecnológica. Se describieron los tipos de componentes
arquitectónicos que existen en cada nivel de la estructura.
En las unidades 5 y 6 se nos enfocaremos en las vistas actuales y futuras de los artefactos que describen
los componentes arquitectónicos en todos los niveles de la estructura.

Autoevaluación 3

1. Los componentes arquitectónicos:
a. Recursos “plug-and-play” intercambiables que proporcionan capacidades en cada nivel de

la estructura.
b. Son elementos pasivos dentro del ambiente operativo de negocios y tecnología de la
empresa.
c. Recursos estáticos que proporcionan capacidades en cada nivel de la estructura.
2. Los artefactos que describen aplicaciones específicas, diccionarios de datos, normas técnicas,
interfaces componentes de red, etc. se denominan:
a. Artefactos de alto nivel.

b. Artefactos de bajo nivel.
c. Artefacto de nivel medio
3. El plan estratégico dentro de la arquitectura se considera:
a. Un componente.
b. Un segmento.
c. Un artefacto.
4. Las metas estratégicas dentro de la arquitectura empresarial:
a. Son aquellos objetivos que, cuando se alcanzan conjuntamente, garantizan la supervivencia

y la consecución del éxito, tal como se define en las medidas de resultado y las métricas de
rendimiento que la empresa desarrolla por sí mismo.
b. Son actividades que se encuentran dirigidas y apoyadas por los objetivos estratégicos.
c. Son actividades genéricas de cada segmento arquitectónico.

5. El Plan de Comercio Electrónico/Gobierno Electrónico:
a. Es un plan adicional al plan estratégico general que ofrece programas específicos de

resultados y rendimientos de la información.
b. Forma parte del plan estratégico general de la organización.
c. Se define por cada segmento arquitectónico.
6. Los servicios del negocio
a. Son bienes tangibles e intangibles que la empresa produce en el ejercicio de las actividades
y objetivos estratégicos.
b. Son aquellas actividades empresariales que contribuyen directamente al logro de la misión
c. Son parte de lasempresasdonde se realizan las tareas destinadas a gestionar la propia
empresa y con las cuales el cliente no necesita contacto directo.
7. La arquitectura orientada a servicios:
a. Es un estilo arquitectónico de TI que soporta la transformación de la empresa mediante un

conjunto de servicios vinculados o tareas empresariales.
b. Es cualquier recurso de TI que funciona a través de una interfaz gráfica de usuario (GUI),
c. Configura un entorno operativo común para los sistemas, aplicaciones y servicios web de
la empresa.
8. El valor la planificación estratégica es más visible:
a. En el producto
b. En la arquitectura.
c. En el proceso
9. La actualización del Plan de Comercio Electrónico/Gobierno Electrónico debe realizarse:
a. Cada 5 años (Largo Plazo)

b. Cada uno o dos años (Corto Plazo)
c. Cada 3 años (Mediano Plazo)
10. La medidas de resultado:
a. Identifican los avances logrados en pos de un nuevo estado final

b. Proporcionan datos sobre las actividades y los productos que se producen.
c. Detallan los avances de cada fase.

70
SEGUNDO BIMESTRE
6.5. Planificación para el trabajo del alumno.
Competencias específicas Contenidos

Competencias Actividades de
del componente Indicadores de aprendizaje Tiempo de dedicación
específicas de Titulación aprendizaje
educativo Unidades
Buscar y seleccionar Maneja conocimientos Unidad 4: Desarrollo de la vista Estudio autónomo de la Reconoce la necesidad de Semana 9 y 10
información, explorar sólidos sobre Arquitectura arquitectónica actual. unidad 4. implementar un programa 8 horas de autoestudio
métodos que permitan Empresarial (AE), Desarrollo de actividades de arquitectura empresarial
4.1. Componentes arquitectónicos: en 8 horas de interacción
enfocar problemas incluyendo terminología, recomendadas en el texto en una organización
el Nivel de Objetivos e Iniciativas

relacionados a ciencias métodos y tendencias de la guía. existente y las formas de
de la computación. industria y la investigación. estratégicas crear una propuesta para

Desarrollo de la
4.2. Metas estratégicas. esta iniciativa.
Evaluación a Distancia.
4.3. Medidas de Desempeño Identifica los obstáculos,
4.4. Componentes Arquitectónicos: Nivel oportunidades y riesgos para
la implementación de un
de Productos y Servicios
programa de arquitectura
4.5. Planes de Gestión del Proyecto empresarial y los medios
4.5.1. Estructura de datos y diagramas para superarlos.
de flujo de datos

4.5.2. Diccionarios de datos /
bibliotecas de objetos
4.6. Componentes Arquitectónicos: Nivel
de sistemas y aplicaciones
4.7. Componentes Arquitectónicos: Nivel
Redes e Infraestructura
SEGUNDO BIMESTRE
71
educativo Unidades
Elaborar soluciones Unidad 5: Desarrollo de la Vista Estudio autónomo de la Reconoce la necesidad de Semana 11 y12
alternativas de TIC para la Arquitectónica Futura unidad 5. implementar un programa 8 horas de autoestudio
mejora de procesos Revisión de temas en de arquitectura empresarial
5.1. El desarrollo de escenarios CONOPS. 8 horas de interacción
empresariales. recursos OCW. en una organización
5.2. Actualización de las vistas existente y las formas de
arquitectónicas futuras - Control de Resolución de Foros.
crear una propuesta para
Versión. esta iniciativa.
5.3. Artefactos arquitectónicos del Nivel
Estratégico de AE – Vista de Futuro.
Escenarios Estratégicos
5.4. Artefactos arquitectónicos del Nivel de
Negocios - Vista de Futuro
Proceso de Documentación.

Casos de Negocio.
5.5. Artefactos arquitectónicos en el nivel
de Información – Vista Futura
5.5.1. Modelos de datos.
5.5.2. Datos orientados a objetos.
5.5.3. Diccionarios de datos /
bibliotecas de objetos.
Interfaz de Programación de

Aplicaciones.
Diagramas para Interfaces de
Programación de Aplicaciones.
Autoevaluación 5
Unidad 6: Desarrollo de un Plan de Gestión

de Arquitectura Empresarial
6.1. Gestión del Programa Arquitectónico
6.1.1. Gobernanza y Principios.
6.1.2. Soporte a la Estrategia de
Negocios.
6.1.3. Roles y Responsabilidades AE.
SEGUNDO BIMESTRE
6.1.4. Presupuesto del Programa.

72
educativo Unidades
6.1.5. Establecimiento de Medidas de Estudio autónomo de la Identifica los obstáculos, Semana 13 y 14

Desempeño del Programa. unidad 6. oportunidades y riesgos para 8 horas de autoestudio
Revisión de lecturas la implementación de un
6.2. Resumen de la arquitectura actual 8 horas de interacción
sugeridas. programa de arquitectura
6.2.1. Objetivos e iniciativas empresarial y los medios
estratégicas. Completar
para superarlos.
autoevaluaciones.
6.2.2. Servicios empresariales y flujos
de información.
6.2.3. Sistemas y aplicaciones.
6.2.4. Infraestructura tecnológica.
6.2.5. Seguridad de TI.
6.2.6. Normas Arquitectónicas.

6.2.7. Requerimientos de mano de
obra cualificada.
6.3. Resumen de la Arquitectura Futura
6.3.1. Escenarios Futuros de
funcionamiento.
6.3.2. Supuestos de planificación.
6.3.3. Actualización de las vistas
arquitectónicas actuales y
futuras.

6.3.4. Plan de Secuenciación.
6.3.5. Gestión de la Configuración
Arquitectónica.
6.4. Glosario y Referencias
Autoevaluación 6
Revisión de contenidos Semana 15 y 16

como preparación para la 8 horas de autoestudio
evaluación presencial.
8 horas de interacción
SEGUNDO BIMESTRE
Texto-guía: Gestión de Tecnologías de Información SEGUNDO BIMESTRE
6.6. Orientaciones específicas para el aprendizaje por competencias
UNIDAD 4. DESARROLLO DE LA VISTA ARQUITECTÓNICA ACTUAL
La unidad 4 cubre el desarrollo de la vista arquitectónica actual, en el contexto de un marco de

documentación y una metodología de implementación. La arquitectura actual es en realidad una
colección de artefactos que documentan a los componentes arquitectónicos existentes en toda la
empresa. La vista arquitectónica actual es importante para una empresa en la que se establecen o
comprueban qué recursos (incluyendo TI) se utilizan en las líneas de negocio para apoyar la consecución
de los objetivos estratégicos. Esto se convierte en una línea base de referencia al igual que un inventario
en el que se apoya la planificación y toma de decisiones respecto a la arquitectura futura.
La presente unidad le permitirá a usted:
• Comprender cómo las vistas actuales se relacionan con la metodología de implementación de

arquitectónica.
• Comprender cómo las vistas futuras se relacionan con el marco de documentación arquitectónica
actuales.
• Ver ejemplos de vistas actuales de los componentes y artefactos arquitectónicos.
La vista arquitectónica actual pretende mostrar los recursos de TI que están actualmente activos en el
entorno operativo de la empresa. Esto también se conoce la vista “as-is”.
Dependiendo de la cantidad de planificación previa, estos recursos pueden o no estar alineados con
los objetivos estratégicos y servicios de negocio de la empresa. Si se ha producido una planificación
arquitectónica incipiente, entonces una cantidad significativa de duplicidad de funciones se puede
presentar. Como se muestra en la Figura 4.1, las vistas arquitectónicas actuales proveen documentación
de los objetivos estratégicos, servicios de negocios, flujos de información, sistemas/servicios de TI y la
infraestructura tecnológica existentes, así como las áreas de seguridad, normas y planificación de la
fuerza de trabajo.
Figura 4.1. “Arquitectura Concúrrete –Arquitectura Futura” tomado de: Scott A. Bernard 2012

La documentación arquitectónica actual es importante para una empresa, ya que proporciona una línea
base de referencia de información/artefactos para la planificación y la toma de decisiones. Además, una
vez completada la documentación de los componentes arquitectónicos actuales en todos los niveles de
la estructura, emerge una visión que revela asociaciones, dependencias, y brechas de rendimiento entre
los requisitos de negocio y las capacidades actuales de la empresa.

Tener la vista arquitectónica actual completa es como tener un juego completo de planos para una casa
ya existente. Proporciona una fuente de referencia autorizada para la planificación futura y la toma de
decisiones, así como un archivo histórico que se requiere para fines de auditoria o investigación.
4.1. Componentes arquitectónicos: en el Nivel de Objetivos e Iniciativas estratégicas
Componentes:
• Planificación estratégica
• E-Commerce o el Plan de Gobierno Electrónico
Artefactos:
• Plan Estratégico (S-1)

• Análisis FODA (S-2)
• Concepto del escenario de operaciones (S-3)
• Concepto de diagrama de Operaciones (S-4)
• Balanced Scorecard “(S-5)
La planificación estratégica produce una vista de alto nivel del estilo de dirección que la empresa
establece para sí misma. Esto está documentado en el Plan estratégico general y en los planes comercio
electrónico/gobierno electrónico en los que se describe el papel de las TI con mayor detalle. La dirección
estratégica de la empresa es más articulada en los artefactos arquitectónicos que incluyen escenarios de
largo alcance, objetivos e iniciativas que sirven como línea base para identificar tácticas a corto plazo que
se publican cada dos o tres años. La vista actual de artefactos en el nivel estratégico debe actualizarse
sólo cuando los cambios en el Plan Estratégico y / o Plan de Comercio/Gobierno electrónico se publican
oficialmente. Esto preserva la naturaleza de los artefactos en este nivel y representa lo que se aprobó en
la actualidad como la política emitida desde el liderazgo ejecutivo. Estos artefactos incluyen:
Artefactos del Nivel Estratégico: Escenario estratégico actual
Algunas empresas optan por desarrollar y mantener los escenarios futuros de cómo el sistema operativo
de negocios y tecnología podría funcionar bajo diferentes conjuntos de influencias internas y externas.
En la vista arquitectónica actual, el artefacto relacionado con la planificación de escenarios es el

escenario que se ha convertido en el contexto de la planificación actual de la empresa, y que contiene
las suposiciones actuales de planificación. En otras palabras, de los escenarios futuros que se desarrollan
periódicamente a través del proceso de planificación estratégica, eventualmente se elige uno que
representa lo que la empresa va a hacer. Cuando se implementa, el escenario futuro seleccionado se
convierte en el escenario de operación actual. Comparar periódicamente el escenario estratégico actual

para varios escenarios posibles que se mantienen en la visión arquitectónica futura puede ser una
actividad valiosa de planificación estratégica.
4.2. Metas estratégicas
Todas las metas estratégicas actuales de la empresa son los artefactos que debe documentar en la
vista arquitectónica actual. De particular interés los objetivos estratégicos relacionados con las TI, que
son aquellos que se basan en algún elemento de TI para ayudar a mover a la empresa en la dirección
estratégica que se describe en cada uno de los escenarios. Estos objetivos relacionados con TI deben
estar completamente documentados en términos de iniciativas y medidas de resultado. Estas metas
deben cumplir varios criterios para ser de valor estratégico: (1) lograr que algún elemento del propósito
de la empresa, (2) se traduzca en un resultado dentro de un escenario que es perceptible y mensurable,
(3) no reducir la flexibilidad de la empresa en la medida que otros escenarios no puedan ser perseguidos
y / o se transformen en amenazas para la supervivencia de las empresas, (4) contar con el apoyo de la
empresa para su implementación.
Ahora ponga atención a los siguientes ejemplos que proveen referencias a elementos de TI:
• Mejorar la disponibilidad global de comunicaciones, calidad y costo. (El elemento es la

infraestructura de voz, datos y video.)
• Mejorar la calidad y la disponibilidad del producto. (El elemento de TI son los datos de fabricación
de productos, control de calidad, los niveles de inventario, etc.).Iniciativas Estratégicas
Cada objetivo estratégico que la empresa identifique se persigue mediante iniciativas estratégicas
que incluyen actividades tales como fusiones y adquisiciones, proyectos de investigación y desarrollo,
implementación de sistemas o proyectos de integración, rediseño y mejora de procesos, nuevas
entradas en el mercado, la consolidación de productos, alianzas empresariales y mejoras en el servicio
a los clientes internos y externos. Es de especial importancia que el logro de las iniciativas estratégicas
sea medible, por lo que la empresa puede gestionar los recursos asignados a esta iniciativa y saber si el
éxito se ha logrado.
El apoyo ejecutivo, los recursos suficientes y las capacidades de gestión de programas son necesarios
para una iniciativa de éxito. Las Iniciativas estratégicas relacionadas con TI son aquellas que se relacionan
con los objetivos estratégicos, de manera que mejoren los flujos de información, mejora/integración
los sistemas de apoyo, servicios y/o aplicaciones, y la optimización de la infraestructura de red. A
continuación le presentamos un ejemplo de las iniciativas estratégicas que están vinculados con los
objetivos estratégicos:
Objetivo estratégico 1: Mejorar la información de marketing y ventas.

Iniciativa Estratégica # 1-1: Comience con ventas de mercado de datos dentro de los seis meses.
Iniciativa Estratégica # 1-2: Consolidar los sistemas de comercialización dentro de dos años.
Iniciativa Estratégica # 1-3: Incremento de clientes en un ocho por ciento en un año.
4.3. Medidas de Desempeño
Cada objetivo estratégico debe constar de un formulario que incluya un resultado medible y significativo.
Cada iniciativa estratégica de apoyo debe incluir resultados medibles y significativos y mediciones de
la producción. Las medidas de resultados describen el estado futuro deseado. Las medidas de salida
describen los niveles en los que las actividades/productos contribuyen a la consecución de un resultado.

Ejemplo Medida de Resultado: “Mejorar la competitividad y no ser inferior al tercer puesto en la cuota
de mercado nacional en todas las líneas de productos en un año.”
Ejemplo Medida de salida: “Aumentar la disponibilidad de los productos en los puntos de venta en un
diez por ciento en seis meses.”
4.4. Componentes Arquitectónicos: Nivel de Productos y Servicios
Componentes:
• Cadenas de Suministro
• Procesos de Negocio
• Planificación y Control de Inversiones de Capital de TI
Artefactos:
• Plan de negocios (B-1)

• Diagrama de conectividad de nodos (B-2)
• Diagramas de Proceso (B-3) Modelo de procesos/servicios de negocio(B-4)
• Matriz de procesos/productos (B-5)
• Casos de uso y diagramas narrativos (B-7)
• Caso de Negocio de Inversiones (B-8)
Documentación de Procesos

El método para modelar los procesos de negocio se conoce como Definición de la integración para
la modelización de las funciones (IDEF- Integration Definition for Function Modeling) desarrollado
insumos, controles, salidas y mecanismos (ICOM) para mostrar las partes de una actividad dentro
a mediados de la década de 1970 para el modelado de proyectos militares complejos, IDEF0 utiliza
de unacontroles,
insumos, empresa,salidas
tal como se ilustra en (ICOM)
y mecanismos la Figura 4.2.mostrar las partes de una actividad dentro de una
para
empresa, tal como se ilustra en la Figura 4.2.
Controles
Entradas Actividad Salidas

Mecanismos
Figura 4.2: IDEF-0 Actividad Modeling,” tomado de: Scott A. Bernard 2012.
Entradas: Artículos que4.2:

Figura inician/activan la actividad
IDEF-0 Actividad Modeling,” y se transforman,
tomado de: Scott A. consumen o se convierten en parte.
Bernard 2012.
Controles: Orientar o regular la actividad, por lo general indica cuándo/cómo se llevará a cabo un proceso.
Entradas:
Resultados LosArtículos
resultadosque inician/activan
producidos la actividad
por la actividad; la razónypor
sela cual
transforman, consumen
se llevó a cabo o se
el proceso.
Mecanismos: Sistemas, personas
convierten y equipos utilizados para realizar la actividad.
en parte.
Controles: Orientar o regular la actividad, por lo general indica cuándo/cómo se llevará a
cabo un proceso.
76 UNIVERSIDADLos
Resultados
TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja
resultados producidos por la actividad; la razón por la cual se llevó a cabo el
proceso.
El modelado a través de IDEF-0 es una actividad adecuada para la documentación de procesos de

negocio, ya que proporciona dos puntos de vista, el contexto de alto nivel y las vistas más detalladas
de cada paso de la actividad en un formato que se puede descomponer aún más e interrelacionarlos
con otros procesos para mostrar sus vínculos.El modelado IDEF-0 es útil para mostrar los vínculos entre
los pasos de un proceso así como las influencias externas e internas, pero no indica una secuencia de
tiempo particular para el conjunto global de las actividades.
Otro método para mostrar los procesos de negocio es una “notación de carril” diagrama que muestra las
actividades en filas horizontales, con el fin de identificar las áreas de responsabilidad de esas actividades.
La figura 4.3 es un ejemplo de un diagrama de carril.
Figura 4.3: Ejemplo “Swim Lane” Diagrama de un proceso,” tomado de: Scott A. Bernard 2012.
En este ejemplo de un diagrama, se muestran las distintas partes interesadas en la Planificación y Control
de Inversiones de Capital de TI, el mismo que ocurre durante la fase de planificación.
Un tercer método para mostrar los procesos de negocio es un diagrama de flujo tradicional que incluye
eventos, puntos de decisión, la secuencia de flujos de las actividades y los puntos de decisión en un
proceso de negocio. La figura 4.4 de la siguiente página le proporciona un ejemplo de un diagrama de
flujo de un proceso de negocio sencillo.
El inconveniente con los diagramas de flujo, en comparación con los modelos IDEF es que los controles
de regulación de las entradas/salidas no se muestran, ni son los mecanismos que son necesarios para
realizar la actividad.
El inconveniente de los diagramas de flujo, en comparación con los diagramas de carril es que las
funciones específicas de los distintos participantes en el proceso no son identificables

Figura 4.4: Diagrama de Flujo de Procesos de Negocio”, tomado de: Scott A. Bernard 2012.
Es importante para una empresa mantener las descripciones y modelos de todos sus servicios clave del
negocio clave. Esto no sólo ayuda en las actividades de reingeniería y mejora, sino también apoya el
diseño y el trabajo de análisis relacionados con la reingeniería / actividades de mejora de procesos de
negocio, así como el desarrollo de las vistas arquitectónicas futuras.
4.5. Planes de Gestión del Proyecto
El Plan de Gestión del Proyecto (PMP - Project Management Plan), es un formato de documento estándar
utilizado por los jefes, los patrocinadores y el equipo del proyecto para mejorar la conceptualización,
documentación, seguimiento, supervisión y ejecución de las tareas del proyecto en toda la empresa. El PMP
se debe utilizar en los nuevos sistemas de TI, aplicaciones, base de datos, o proyectos de infraestructura,
así como en los esfuerzos de actualización de las mismas áreas. Mediante el establecimiento de la
documentación del proyecto en cada área de la PMP, los directores de proyectos tendrán mejor control
sobre costes, plazos y objetivos de rendimiento, y es más probable que añada valor a la empresa por
estar en alineación con la dirección, la política de inversión estratégica de los recursos de TI resultante y
la arquitectura.
El PMP debe adaptarse para identificar si el negocio necesita ser abordado por el proyecto y cómo se
llevará a cabo el mismo. La cantidad de información y el nivel de detalle incluido en las secciones del PMP
deben ser determinados por las características del programa, tales como el tamaño y la complejidad,
de la empresa. Es importante incluir documentos de apoyo en las secciones correspondientes de PMP,
como el Plan Estratégico de TI, una estructura de desglose de trabajo (WBS), documentación de casos de
negocio, Modelo de referencia de Normas Técnicas, planes de formación y planes de prueba.
El PMP documenta el concepto de gestión global y el enfoque utilizado para lograr los objetivos del
programa. El director del proyecto prepara y emite el PMP durante la fase de planificación. El PMP es el
vínculo común entre el director del proyecto y todos los demás involucrados en el mismo. El director de
proyecto utiliza el PMP para programar y dirigir todo el proceso de desarrollo del sistema, mientras que
los niveles más altos de autoridad utilizan el PMP como base para la planificación de actividades. Muchos
de los participantes pueden ver un proyecto a través de un PMP. El PMP debe actualizarse en cada etapa
del proyecto, como requisito previo para pasar a la siguiente fase en el ciclo de vida del proyecto.

• Resumen Ejecutivo
• Requisitos del proyecto
• Alineación estratégica
• Alineación Arquitectónica
• Caso de Negocio
• Controles del proyecto
• Enterprise Project
• Seguridad y privacidad
• Apéndices
Casos de Negocio
Un caso de negocio permite realizar el análisis de las necesidades y el valor de hacer una inversión en
particular. En el contexto arquitectónico, el desarrollo de un caso de negocio para inversiones en TI
ayuda a asegurar que se genere el máximo valor a partir de nuevos proyectos de desarrollo, así como
de las operaciones y actividades de mantenimiento. Además, el desarrollo de rutinas y la revisión de
casos de negocios para las inversiones de TI ayudan a promover la alineación estratégica y alineación
arquitectónica de tal manera que los componentes y productos arquitectónicos están más integrados.
Existen seis áreas que debe considerar en un modelo de negocio de inversión: (1) la declaración de la
obligación, (2) el análisis de las alternativas, (3) el análisis de costo-beneficio, (4) el análisis de riesgos, (5)
el cálculo del retorno de la inversión “ROI” y (6) la selección de una alternativa con las observaciones y
recomendaciones sobre la aplicación.
Identificar la necesidad.- En esta parte del modelo de negocio se establece con claridad y de manera
sucinta lo que el requisito de negocio es, y se debe evitar hacer cualquier recomendación sobre las
soluciones, incluida la tecnología. Esta parte del caso de negocios debe describir la situación actual y la
necesidad que no se está cumpliendo (una brecha en el rendimiento).
Análisis de Alternativas.- Este análisis considera varias alternativas (preferiblemente tres o más) a
cumplir para un requisito de negocio. El requerimiento puede ser la actualización de un componente
arquitectónico existente, el desarrollo de un nuevo componente, o para la prestación de servicios
de apoyo, tales como mesa de ayuda o las funciones de administración de sistemas. Las alternativas
pueden diferir en el proceso recomendado, solución técnica, tipo de personal a emplear, facilidades
a ser utilizadas, etc. Las alternativas elegidas deben representar el alcance completo de opciones que
podrían ser utilizadas para cumplir con el requisito. Una de las alternativas puede ser el “status quo”, que
recomienda no hacer nada diferente de lo que es la situación actual.
Análisis Costo-Beneficio.- Este análisis identifica y compara los costos y beneficios de cada alternativa
para cumplir con un requisito de TI. Los costos incluyen el total de los gastos directos e indirectos en
los que se incurren. Los beneficios incluyen aquellos que son tangibles (medibles) e intangibles (No
directamente medibles).Los beneficios deben superar los costes de una alternativa a ser viable y que
debería añadir un valor significativo a la empresa.
Análisis de riesgos.- Este análisis identifica el riesgo de cada alternativa. El riesgo es la identificación de
las fuentes de incertidumbre en un proyecto y obstáculos para el éxito del mismo. Las áreas de riesgo
para los proyectos de TI incluyen; ser el primer adoptante de una nueva tecnología, las reducciones
presupuestarias, la pérdida de personal clave, las pruebas o capacitación insuficiente y retrasos en el
programa. La mitigación del riesgo es el término comúnmente utilizado para referirse a la estrategia
identificada para reducir la probabilidad de que se produzca un riesgo en particular. Las estrategias de

mitigación de riesgos deberán reducir la incertidumbre, evitar obstáculos para el éxito, o proporcionar
respuestas para superar los obstáculos que puedan producirse. Un ejemplo de esto es haber entrenado
al personal de respaldo para los puestos clave, o el uso de productos de estándares abiertos para evitar
la dependencia de un solo proveedor.
Retorno de la inversión.- El cálculo «ROI» se hace para cada alternativa y se calcula dividiendo el
total de los beneficios cuantificados (en dólares) de los costes totales cuantificados (en dólares).Es el
porcentaje de retorno sobre el capital invertido inicialmente. Para cálculos de múltiples años, el retorno
de la inversión debe ser descontado usando el método del Valor Actual Neto (VAN).El VAN descuenta
los futuros niveles de financiación con el fin de tener en cuenta la inflación y otros costos en aumento
durante el ciclo de vida de la alternativa (por ejemplo, un factor de descuento del 3% se aplica cada año).
El ROI se calcula como un porcentaje, dividiendo los beneficios cuantificados en dólares por los costos
cuantificados en dólares durante el ciclo de vida total de la alternativa. El retorno de la inversión es
uno de los factores que los ejecutivos utilizan para determinar el mérito de invertir en un proyecto
propuesto y también para comparar ese mérito a otras inversiones / proyectos que no se puede hacer si
esa alternativa en particular se lleva a cabo (costo de oportunidad). Las empresas a menudo establecen
un nivel mínimo aceptable de retorno de la inversión con el fin de reforzar la evaluación del “costo de
oportunidad” de la inversión, que considera si la cantidad equivalente al costo de la inversión sería mejor
gastado en otra inversión. Algunas inversiones de TI pueden producir muy altos niveles de retorno de
la inversión si se logran ahorros significativos en los costes de personal y/o tiempos dentro del ciclo de
vida del proyecto.
Visite el sitio
en
http://www.ibm.com/developerworks/ssa/rational/library/edge/09/mar09/ el
encontrará el artículo “Calculando el ROI para la mejora del proceso”, revise
detalladamente el mismo con la finalidad de mejorar el entendimiento sobre el
tema.
Selección de Alternativas: Esta declaración documenta la selección de la mejor alternativa en base a

todos los aspectos del caso de negocio. Esto incluye los tipos de costos, tipos de beneficios, la estrategia
de reducción del riesgo, y el ROI. La justificación para la selección de una alternativa y rechazo de otras,
también debe ser documentada para futuras consultas.
4.6. Componentes Arquitectónicos: Nivel de Datos e Información
Componentes:
• Bases de datos
Artefactos:
• Plan de Gestión del Conocimiento (D-1)

• Matriz de Intercambio de Información (D-2)
• Diagrama de transición de estados (D-3)
• Diagrama de secuencia (D-4)
• Modelo lógico de datos (D-5)

• Modelo físico de datos (D-6)

• Actividad / Entidad (CRUD) (CRUD) (D-7)
• Diccionario / Librería de objetos de datos (D-8)
Documentar flujos de información permiten el desarrollo de modelos que muestran la estructura y los
flujos de datos en los servicios de negocio de la empresa y el apoyo a los sistemas / servicios de TI.Los
datos pueden ser modelados y analizados utilizando métodos tradicionales y/o orientados a objetos,
dependiendo de cómo se haya previsto la documentación resultante para ser utilizado.
Por ejemplo, si el uso previsto es con bases de datos relacionales y/o lenguajes de programación de
tercera generación (es decir, C, FORTRAN o COBOL), o mediante el uso de los métodos tradicionales (es
decir, diagramas entidad relación y diagramas de flujo de datos).
4.6.1. Estructura de datos y diagramas de flujo de datos
Modelado de la estructura de la información: el enfoque “tradicional” para el desarrollo de sistemas de

información se basa en la técnica de modelado llamada Diagramación Entidad Relación (ERD). Los
ERD son utilizados por los analistas y programadores de sistemas de TI para identificar las entidades
de datos que la empresa requiere sean capturados por los sistemas de TI, así como en las entidades
externas que interactúan con un sistema. Los ERD’s también proporcionan descripciones de entidades
de datos, atributos, relaciones, y las reglas para la frecuencia de esas relaciones. Lo que se pretende con
esa arquitectura es ofrecer una visión de todos los recursos de TI de la empresa, es importante resaltar
que los ERD’s muestran no sólo lo que está en cada sistema, sino también cómo la interfaz de un sistema
con los demás. Los ERD’s no se descomponen por sí, pero pueden servir para mostrar varios sistemas,
o parte de sistemas complejos grandes. En la Figura 4.5 se muestra un ejemplo de un diagrama de ERD
para un sistema de rastreo de bienes raíces.
Figura 4.5: Ejemplo de diagrama entidad-relación,” tomado de: Scott A. Bernard 2012.
Modelado de flujos de información. Los flujos de datos e información se documentan mediante

métodos tradicionales y orientados a objetos, dependiendo de cómo se intenta usar la documentación
resultante. El método tradicional de documentar los flujos de datos se desarrolló en la década de 1970
y se centra en la utilización de diagramas de flujo de datos (DFD). Los DFD’s deben reflejar los procesos

que transforman los datos dentro de un sistema de información. La transformación puede implicar la
creación, actualización, supresión, o la lectura de los datos. Una matriz entidad/actividad puede ayudar a
los analistas y programadores a pasar de un ERD a un DFDs en la medida que se diseñe cómo funcionará
un sistema de información en apoyo de las necesidades de la empresa. El DFD se puede descomponer a
partir de un nivel de contexto muy alto, a un nivel de proceso de base, a varios sub-niveles que examinan
cada proceso en mayor detalle. Figura 4.6 es un ejemplo de un DFD de alto nivel para un sistema de
seguimiento de mantenimiento de carreteras.
Figura 4.6: Ejemplo de Diagrama de flujo,” tomado de: Scott A. Bernard 2012.
Los enfoques orientados a objetos (OO) para el modelado de la estructura de datos y procesos fueron
desarrollados a mediados de la década de 1980 por Ivar Jacobson, Grady Booch y James Rumbaugh. Sus
esfuerzos combinados producen lo que hoy se conoce como el Lenguaje de Modelado Unificado (UML).
Los objetos son secuencias específicas de código en lenguajes de programación de cuarta generación,
que representan algo en el dominio de los requisitos de negocio con el que un sistema de TI debe crear,
utilizar o interactuar. Los objetos son como las entidades que tienen un nombre y atributos, y se ligan a
otros objetos de acuerdo con las reglas de frecuencia. Se podría decir que los objetos saben cosas acerca
de sí mismos. Los objetos son diferentes a las entidades debido a que el código para objetos también
contiene comportamientos (también conocidos como métodos), los cuales son accionados por eventos
que también se identifican en el código, se podría decir que los objetos también “saben cómo hacer las
cosas. “Más allá de saber cosas acerca de sí mismos y saber cómo hacer las cosas, hay tres características
que definen a un objeto: el polimorfismo, la herencia y encapsulación:
• Polimorfismo: comportamientos de varios objetos invocados mediante la activación de eventos.

• Herencia: Atributos que llevan más entre los padres y los objetos secundarios.
• Encapsulación: código oculto que protege los atributos y comportamiento de los objetos.
El concepto de objetos permite a los analistas y programadores adoptar un enfoque más intuitivo para el
diseño de sistemas de información, aplicaciones, bases de datos y sitios web. También, porque los objetos
son secuencias específicas de código que se pueden reutilizar, lo que ahorra tiempo de programación
y aumenta la calidad y el rendimiento. Por ejemplo, un objeto “factura” desarrollado para un sistema
de ventas podría ser reutilizado en varias líneas de negocio en una empresa que tiene varias líneas
de productos y procedimientos de facturación. La funcionalidad básica del objeto factura es a la vez

protegida y hereda en todos los sistemas, con funciones personalizadas adicionales y comportamientos
que se agregan a medida que se necesitan.
Las actividades de análisis y diseño orientados a objetos comienzan con la documentación de los
requerimientos del negocio en la forma de un caso de uso narrativa. Cuatro tipos básicos de diagramas
se utilizan para describir el caso de uso, cada uno de los cuales es un artefacto arquitectónico que se
debe mantener en el nivel de información de la estructura: (1) Diagrama de casos de uso, (2) Diagrama
de Clases / Objetos (3) Diagramas de Secuencia, y (4) Diagramas de transición de estados. Los diagramas
de casos de uso muestran una visión estática (Snapshot) del conjunto de actividades (casos de uso)
y los actores en un sistema de información, y cómo estos intercambian información. Los diagramas
de Clases/Objetos muestran una visión estática de las cosas que interactúan en cada caso de uso en
el sistema de información, y cómo los comportamientos del objeto realizarán esas interacciones. Los
diagramas de secuencia muestran cómo grupos de objetos exhiben comportamientos en respuesta a
un evento específico llamado disparador. Tenga en cuenta que el mismo objeto puede exhibir diferentes
comportamientos en respuesta a eventos diferentes. El diagrama de transición de estados muestra el
ciclo de vida de un objeto en particular, en términos de cómo los eventos desencadenantes pueden
invocar comportamientos diferentes.
4.6.2. Diccionarios de datos / bibliotecas de objetos
Los diccionarios de datos son depósitos de las entidades de datos y atributos que la empresa recoge y
almacena en bases de datos. Las normas para el formato de los datos se documentan en el diccionario
de datos, así como las dependencias y las normas para las relaciones y dependencias entre entidades de
datos que se identifican en los diagramas entidad relación.
Las bibliotecas de objetos son depósitos de objetos reutilizables.Desde un punto de vista técnico,
son las piezas discretas de código de programación las que en realidad forman un objeto, y que están
siendo almacenados en la biblioteca de objetos como una unidad reutilizable completa. Los lenguajes
de programación orientados a objetos (es decir, JAVA, ADA, Smalltalk, C + +) desarrollan segmentos de
código que son distintos en su identidad y función, y que son reutilizables en el sentido que cada objeto
se puede integrar en otras aplicaciones con un poco de personalización. Los desarrolladores de software
comerciales crean cada vez más aplicaciones que utilizan un enfoque orientado a objetos para que puedan
mantener la aplicación de manera más eficiente mediante el ajuste o la adición/eliminación de objetos
individuales.Los vendedores también están cada vez más vendiendo aplicaciones orientadas a objetos
que son comunes a los servicios financieros, manufactura y aplicaciones administrativas. Los objetos
comerciales y aquellos que son personalizados por la empresa deben ser archivados en la biblioteca de
objetos. Otros productos desarrollados en plataformas diferentes (lenguajes de programación) también
deben ser incluidos en la biblioteca de objetos. Estos incluyen artefactos arquitectónicos como páginas
web y componentes de servicios Web que se desarrollan en lenguajes orientados a objetos y que se
guardan en formatos compatibles como HTML, XML, XHTML J2EE y ebXML.
Visite el sitio
http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/materiales-
de-clase-1/is1-t02-trans.pdf en el encontrará el recurso educativo abierto- OCW
“Lenguaje de Modelado Unificado”, revise detalladamente el mismo con la
finalidad de mejorar el entendimiento sobre el tema.

4.7. Componentes Arquitectónicos: Nivel de sistemas y aplicaciones
Componentes:
• Servicios Web
• Planificación de recursos empresariales (Soluciones ERP)
• Sistemas operativos
Artefactos:
• Diagrama de Interfaces de sistemas (SA-1)

• Diagrama de comunicación del sistema (SA-2)
• Matriz de Interfaces del Sistema (SA-3)
• Diagrama de flujo datos del sistema (SA-4)
• Matriz de Sistemas/Operaciones (SA-5)
• Matriz de Sistemas de Intercambio de Datos (SA-6)
• Matriz de Rendimiento del sistema (SA-7)
• Diagrama de la evolución del sistema (SA-8)
• Diagrama de la aplicación Web (SA-9)
La vista actual de los sistemas y aplicaciones de TI obtenerse para mostrar una imagen precisa de las
aplicaciones de software, servicios de oficina front-office /back-office, y los sistemas que la empresa
tiene actualmente en su entorno operativo de TI. Muchos de estos recursos de TI se han desarrollado
de manera independiente, la vista actual completa del nivel de soporte de aplicaciones del marco
puede mostrar (1) la falta de integración en áreas con requisitos para el intercambio de información,
(2) la duplicación de funciones, (3) poca o mucha diversidad de proveedores, y/o (4) que no se están
cumpliendo los requerimientos del negocio.
Artefactos Arquitectónicos: Nivel de Sistemas y Aplicaciones
Los diferentes tipos de aplicaciones de software que una empresa utiliza para apoyar sus actividades
como la ofimática y otras funciones a menudo varían en su diseño, lenguaje de programación, puntos
de interfaz, y proveedores de código. A veces es útil desarrollar una visión gráfica de estas aplicaciones
de soporte para mostrar lo que está presente, y los tipos generales de las funciones que se admiten.
La figura 4.7 es un ejemplo del tipo de diagrama que muestra una visión general de la actual “suite” de
sistemas, aplicaciones y protocolos de red de apoyo de la empresa.

de las funciones que se admiten. La figura 4.7 es un ejemplo del tipo de diagrama que muestra una
visión general de la actual "suite" de sistemas, aplicaciones y protocolos de red de apoyo de la
empresa.
Servicio Servicio Servicio

Portal Web
Comercio Cadena de Gobierno Servicios Web
Público
Electrónico Proveedores Electrónico
Módulo de Aplicación de Aplicación
Aplicaciones
Recursos Edición de Seguimiento de Sistemas/ Aplicaciones
Gráficas ERP
Humanos Fotos Documentos
Aplicación de Mineria Aplicación de

Aplicaciones CASE
de Datos Planificación
Sistemas/ Aplicaciones de
Aplicaciones de Aplicaciones de Aplicación de Negocio
Aplicaciones Back-‐Office y
Seguimiento de Seguimiento de Seguimiento
Gráficas Herramientas Ofimáticas
Proyectos Proyectos Documental
Suite de Aplicaciones

Navegadores Web Base de Datos
Ofimáticas
Sistema Operativo
Sistema Operativos S.O Administrador de
Servidor Base de
PC Archivos Sistemas Operativos
Datos
Equipos de Escritorio &
Sistema Operativos Sistema Operativo Servidores
Sistema Operativo
Servidor de Firewall de
Servidor Web
Impresiones Seguridad
Asynchonous
Frame Relay Protocolos de Red
Ethernet Transfer Mode TCP/IP
& VPN (Voz, video, datos)
(ATM)
Figura 4.7: Vista general de Sistemas y Aplicaciones,” tomado de: Scott A. Bernard 2012
Figura 4.7: Vista general de sistemas y aplicaciones,” tomado de: Scott A. Bernard 2012
Descripciones y vistas adicionales se pueden enfocar en tipos específicos de aplicaciones de soporte
para mostrar funciones e interfaces específicas. Como se indica en la Figura 4.8, puede ser beneficioso
112
mostrar
una “jerarquía” de aplicaciones en la que los sistemas operativos son la base, las aplicaciones
ofimáticas y de negocios están en medio y las aplicaciones web son en la parte superior.
Una interfaz de programación de aplicaciones (API) es una serie de funciones que utilizan aplicaciones
de software para que otras aplicaciones y sistemas operativos lleven a cabo acciones de apoyo. En
otras palabras, la API define cómo las aplicaciones interactúan a nivel de Sistemas/Servicios del marco
arquitectónico. Por ejemplo, una API para un programa puede ser utilizada para abrir las ventanas,
archivos y cuadros de mensajes y realizar tareas más complicadas, simplemente corriendo una sola
instrucción. Las descripciones API deben describir tanto la función interna y la conectividad externa de
modo que se crea una imagen de las actividades e interrelaciones.
Diagrama de Interfaces de Sistemas
Los sistemas de TI son colecciones aplicaciones, bases de datos, sistemas operativos y hardware que
satisfacen las necesidades específicas de tecnología o de negocios de la empresa.Estos sistemas son cada
vez más necesarios para crear una interfaz directa e indirecta con otros sistemas de TI para permitir el
intercambio de información en toda la empresa. El uso de estándares internacionales no-propietarios de
la industria para soluciones de software y hardware permiten habilitar a estas interfaces. Los diagramas
de interfaz del sistema (también llamados diagramas de conectividad de nodo) son descripciones físicas
y lógicas de cómo y dónde se producen estas interfaces. Se requiere documentación adicional sobre el
tipo de apoyo a las normas y protocolos para completar la documentación del sistema y las interfaces
de servicios.
Como se describe en la Unidad 6, se utiliza un enfoque de arquitectura orientada a servicios (SOA)

para describir y documentar los sistemas de TI y servicios de Internet en el nivel Sistemas / Servicios, y
puede ser considerada como una sub-arquitectura de la marco del marco arquitectónico.Los servicios
Web se basan en el protocolo de intercambio de información de TCP / IP (HTTP) y en formatos de

estándares abiertos de información, tales como HTML, XML y J2EE (. NET es un protocolo propietario de
propiedad de Microsoft ®).Los servicios Web son por lo tanto, independientes de la plataforma, y pueden
intercambiar información con otros servicios web en un entorno operativo común, que se conoce como
la Plataforma de Aplicaciones de Red (NAP-por sus siglas en inglés), o un Bus de Servicios Empresariales
(ESB-Enterprise Services Bus).
Las interfaces de servicios Web dentro del NAP / ESB se definen por dos de los principales estándares de
la industria, siendo el primero Simple Object Access Protocol (SOAP), que es un formato de mensajería
XML extensible y el Consorcio World Wide Web (W’3C) que se adoptó como norma internacional.
Otro estándar es la transferencia de estado de representación (REST) o interfaz “RESTful”, que promueve la
comunicación entre las aplicaciones ESB que se detectan mediante la transferencia de una representación
de ese recurso en un formato que coincide con un tipo de datos estándar que se determina de forma
dinámica para adaptarse a las capacidades del remitente y el destinatario.
UDDI (Universal Description, Discovery and Integration) es un formato estándar y un procedimiento

para registrar y detectar servicios web. UDDI es un “meta-servicio” web que funciona como un registro
mediante el uso de mensajes SOAP para encontrar servicios web. El registro UDDI organiza la información
de servicios web en cuatro categorías: entidad de negocio, servicios a empresas, plantilla vinculante, y el
tipo de servicio. Además, el Lenguaje de Descripción de Servicios Web (WSDL-Web Services Description
Language) se utiliza para describir el servicio web encontrado por el registro UDDI. La Figura 4.8 muestra
una vista general de los servicios web y los roles SOAP, el Registro UDDI y WSDL.
Figura 4.8: Vista general de Servicios Web, tomado de: Scott A. Bernard 2012.
Normas Técnicas. Las aplicaciones de TI deben ser seleccionadas sobre la base de normas técnicas
y protocolos de la industria nacionales o internacionales que no tienen sesgo hacia proveedores o
productos específicos. Las normas para API’s, funcionalidades del servicio, y la integralidad de software /
hardware deben documentarse para ayudar en la toma de decisiones respecto a la selección de nuevas
aplicaciones y la operación y mantenimiento de las aplicaciones existentes. Las descripciones de servicios
web WSDL y la documentación de la interfaz del bus de servicios Web NAP son algunos de los objetos
adicionales que deben ser recogidos.

4.8. Componentes Arquitectónicos: Nivel Redes e Infraestructura
Componentes:
• Redes de datos
• Redes de Video Networks
• Redes Móviles
• Edificios y salas de servidores
• Equipos
Artefactos:
• Diagrama de Conectividad Red (NI-1)

• Inventario de red (NI-2)
• Inventario de Bienes de Capital (NI-3)
• Planos de construcción (NI-4)
• Diagrama del centro de redes (NI-5)
• Diagrama de la Planta de Cableado (NI-6)
• Diagrama de elevación de Bastidores (NI-7)
Documentación de la red
En nivel de la infraestructura de redes del marco, los routers del Backbone / switches / hubs, salas de
máquinas, salas de cableado y las plantas de cables deben ser descritos en detalle utilizando tanto
documentos de texto y diagramas que muestren su diseño lógico y físico. Cada una de las redes de voz,
datos y vídeo debe documentarse de forma que el análisis y la toma de decisiones con respecto a la
operación y mantenimiento sea soportada. Figura 4.9 en la página siguiente proporciona un ejemplo de
este tipo de documentación.
Figura 4.9: Ejemplo de red Diseño de Normas Técnicas Diagrama,” tomado de: Scott A. Bernard 2012.

Las normas técnicas para las redes de voz, datos y vídeo deben ser identificadas para proporcionar una
referencia para el análisis y soporte de los recursos de infraestructura actuales, así como la planificación
de los recursos futuros. Las normas de organismos nacionales e internacionales deben utilizarse para
fomentar la selección proveedores de productos que mejor se integren con otros productos existentes
y planificados a futuro. Las normas técnicas de red también son provistas en forma de políticas,
especificaciones técnicas y procedimientos operativos estándar.
Documentación de Seguridad
Cada red, servicios en la nube (cloud computing), y sistemas de TI que se apoyan en el Backbone
tecnológico deben ser probados y certificados por las vulnerabilidades de seguridad. Esto se hace para
que se mantenga un nivel efectivo de apoyo a las empresas, y que una solución global de seguridad de
TI sea establecida para las aplicaciones hospedadas, servicios, bases de datos y sitios web. Los artefactos
arquitectónicos relacionados incluyen el desarrollo de planes de seguridad del sistema / red, informes
de las pruebas de vulnerabilidad, recuperación de desastres y continuidad de los planes de operación, y
la certificación y los resultados del examen de acreditación.
Configuración de solicitudes de cambio
Debe describir un método estándar para solicitar cambios en los artefactos arquitectónicos, de modo que
el control de configuración sobre las vistas actuales y futuras arquitectónicas pueda ser mantenido. El uso
de un formulario de Solicitud de Cambio arquitectónico (EACR-Enterprise Architecture Change Request)
es una manera de tener un formato normalizado y un proceso de actualización de la documentación
de Rehacer de la EACR una plantilla electrónica ayudará a promover el uso de la misma por todos los
interesados, así como el archivo en la base de datos del repositorio de los EACRS pendientes y aprobado.
Inventarios de Hardware / Software
Una de las funciones de la AE es proporcionar un repositorio de inventarios periódicos del software y

de los activos de hardware de la empresa. El mantenimiento de un inventario de estos recursos de TI
ayudará a determinar si los niveles de inversión son necesarios para las operaciones, el mantenimiento y
la formación, así como para proyectos de sustitución y actualización tecnológica. El uso de sistemas de
inventario automatizados y etiquetas de código de barras ayudarán a mantener un inventario preciso de
los recursos en el entorno operativo de TI.
Resumiendo la unidad.
En la presente unidad se proporcionaron descripciones y ejemplos de artefactos arquitectónicos que

documentan el estado actual de los componentes en todos los niveles del marco. La colección de
artefactos actuales representa la vista “as-is” de la arquitectura. Esto es importante para la empresa, ya
que constituye un inventario integrado de información de referencia para la planificación de recursos y
la toma de decisiones.
Las vistas actuales de los componentes arquitectónicos también muestran cómo se alinean con eficacia
los objetivos estratégicos, servicios de oficina y recursos tecnológicos, y las brechas de rendimiento
también pueden ser reveladas. En la unidad 5 se discutirá el desarrollo las vistas arquitectónicas futuras,
y en la unidad 6 se describe el concepto de un Plan de Gestión de AE que sirve para gestionar la transición
en curso entre los estados actuales/futuras de la arquitectura de la empresa.

Actividad Propuesta
Revise el caso “Desarrollando las Vistas Arquitectónicas Actuales y Futuras”
propuesto en el entorno virtual de aprendizaje EVA con la finalidad contextualizar
el tema.

Autoevaluación 4

conceptos conocidos, sin embargo es preciso realizar una autoevaluación para
determinar cuanto a logrado asimilar. Aunque el desarrollo de estas preguntas
no es obligatorio, se le recomienda resolverlas ya que es posible que haya
algunos temas que no se han comprendido a plenitud. Recuerde que al final de
la guía se han incluido las soluciones a estas autoevaluaciones sin embargo
deberá usarlas solo después de haber obtenido sus propias respuestas para
volver a revisar temas que quizá no quedaron bien comprendidos
1. El desarrollo de la vista arquitectónica actual permite:
a. Pretende mostrar las metas e iniciativas estratégicas actuales que están ejecutándose
actualmente en el entorno operativo de la empresa.
b. Pretende mostrar los recursos de TI que están actualmente activos en el entorno operativo
de la empresa.
c. La disponibilidad de recursos humanos y tecnológicos.
2. Una línea base arquitectónica:
a. Proporciona el análisis de brechas de la información/artefactos para la planificación y la

toma de decisiones.
b. Es un conjunto de normas y políticas para la gestión de la empresa.
c. Proporciona una referencia de información/artefactos para la planificación y la toma de
decisiones.
3. A la arquitectura actual se la conoce como:
a. Vista arquitectónica “To be”.

b. Vista arquitectónica “As-is”.
c. Arquitectura de gestión inicial.
4. La vista actual de artefactos en el nivel estratégico debe actualizarse:
a. Cuando los cambios en el Plan Estratégico y / o Plan de E-Commerce/E-Government son

identificados.
b. Cuando los cambios ingresan al plan de gestión configuración arquitectónica.
c. Cuando los cambios en el Plan Estratégico y / o Plan de E-Commerce/E-Government se
publican oficialmente.
5. El método IDEF es un método para:
a. Identificar metas e incitativas estratégicas.

b. Modelar procesos de negocio
c. Identificar los entregables y los criterios de éxito del programa.

6. El plan de gestión del proyecto se utiliza para :
a. Tener un mejor control sobre costes, plazos y objetivos de rendimiento.

b. Describir el alcance del proyecto.
c. Identificar las brechas de rendimiento de las vistas arquitectónicas actuales y futuras.
7. Un caso de negocio:
a. Evita que el proyecto tenga menos funcionalidades de las esperadas.

b. Permite al arquitecto en jefe definir con claridad el alcance del programa.
c. Ayuda a asegurar que se genere el máximo valor a partir de nuevos proyectos de desarrollo,
así como de las operaciones y actividades de mantenimiento.
8. Los ERD son utilizados por los analistas y programadores para:
a. Identificar las entidades de datos que la empresa requiere sean capturados por los sistemas
de TI.
b. Identificar los objetos que la empresa requiere sean capturados por los sistemas de TI.
c. Identificar los roles y responsabilidades dentro de las actividades de recolección de
información.
9. Los sistemas de TI:
a. Son depósitos de las entidades de datos y atributos que la empresa recoge y almacena en
bases de datos.
b. Son colecciones de aplicaciones, bases de datos, sistemas operativos y hardware que
satisfacen necesidades específicas de tecnología o de negocios de la organización
c. Son especificaciones técnicas que permiten el normar desempeño de las actividades de la
organización.
10. La vista arquitectónica actual de sistemas y aplicaciones de TI debe obtenerse para:
a. Mostrar una imagen precisa de las aplicaciones de software, servicios de oficina front-office/
back-office, y los sistemas que la empresa tiene actualmente en su entorno operativo de TI.
b. Mostrar la relación entre los objetivos e iniciativas estratégicas del negocio y la vista
arquitectónica futura.
c. Mostrar la interrelación entre sistemas de TI.

UNIDAD 5. DESARROLLO DE LA VISTA ARQUITECTÓNICA FUTURA
En esta unidad trataremos el desarrollo de las vistas arquitectónicas futuras, en el contexto de un marco
de documentación y una metodología de implementación. Las vistas futuras son importantes para la
empresa, debido a que capturan uno o más posibles escenarios operativos del negocio y la tecnología,
que apoyan a la planificación y la toma de decisiones. Estos escenarios operativos futuros se basan
en suposiciones de capacidad y estrategias para un desempeño exitoso en respuesta a las influencias
internas y externas. La creación de los artefactos de la vista futura se logra mediante el uso de los
supuestos planificados en los escenarios y la misma documentación y técnicas de modelado que se
utilizaron para desarrollar los artefactos de vista actual. Esto permite a los artefactos de la vista futura
estar directamente relacionados con los artefactos de la vista actual en cada nivel de la estructura, de
modo que los cambios potenciales y planificados resultan evidentes, y varios tipos o combinaciones de
cambios pueden ser de modo guiado.
• Comprenda cómo las vistas futuras se relacionan con el marco de documentación AE.
• Comprenda cómo las vistas futuras se relacionan con la metodología de implementación

arquitectónica.
• Comprenda cómo la planificación de escenarios ayudan al desarrollo de las vistas futuras.
Tenga presente que la vista arquitectónica futura documenta los recursos de TI que estarán activos en
el entorno operativo por muchos años en el futuro. Esto también se conoce como la vista futura “to-be”,
a diferencia de la “as-is” actual” que documentan los recursos actuales de TI que se describieron en la
unidad 4.
Dependiendo del alcance de la planificación que se ha producido con anterioridad en la empresa, el

futuro de los recursos de TI puede que no estén alineados con los objetivos y servicios estratégicos de la
empresa. Si la planificación ha sido insuficiente, entonces se puede presentar duplicación de funciones
y vista futura debe mostrar cómo tal duplicación será eliminada.

Contar con una vista a futuro de la AE, es como tener un juego completo de planos para la modificación
de una vivienda existente. Proporciona una referencia autorizada por el arquitecto y el dueño de casa
para discutir los cambios en el hogar.
Como se muestra en la Figura 5.1, la vista arquitectónica futura provee a la empresa la documentación
de los cambios identificados en cuanto a los objetivos estratégicos, servicios de negocios, flujos de
información, solicitudes de apoyo y recursos de red.

Figura 5.1. “Arquitectura Concúrrete –Arquitectura Futura” tomado de: Scott A. Bernard 2012.
En el desarrollo de la vista futura de la AE es importante para una empresa porque es

compatible con la planificación de recursos y la toma de decisiones. Además, al completar
la documentación futura de AE en todos los niveles del marco de trabajo, emerge una
visión futura de la empresa, la misma que revela cambios en las prioridades, procesos y
recursos.
En el desarrollo arquitectura futura, cada nivel de la estructura se documenta con artefactos para
mostrar los componentes que han sido aprobados para su aplicación, o están en las etapas de idea
del proyecto. Los cambios potenciales dirigidos a los componentes arquitectónicos actuales incluyen
objetivos e iniciativas estratégicas, servicios de negocios, flujos de información, sistemas, aplicaciones
y redes de apoyo nuevas o actualizadas. Las iniciativas que se encuentran en las primeras etapas se
pueden dejar fuera de la vista de futuro hasta que tengan un fuerte apoyo de los patrocinadores. Esto
evitará abarrotar la vista arquitectónica futura AE iniciativas y novedades que tienen pocas posibilidades
de ser implementadas, y que con el tiempo irán en detrimento de la percepción del valor que entrega la
AE como una referencia autorizada para la planificación y toma de decisiones. Las iniciativas candidatas
son mejor documentadas en una sección especial del Plan de Gestión Arquitectónica.
5.1. El desarrollo de escenarios CONOPS
Como se revisó en apartados anteriores los Escenarios de Concepto de Operaciones (CONOPS) se han
utilizado como una herramienta de planificación militar durante milenios, y como se ha destacado, la
capacidad de prever varios cursos posibles de acción es clave para ganar en muchos tipos de juegos
recreativos.
Utilizando el ajedrez como ejemplo, podemos anticipar cómo un oponente puede

reaccionar a sus movimientos, este es uno de los primeros pasos que forma a un
maestro de ajedrez. Para contar con los mejores niveles de juego debemos ser capaces
de pensar a través de varios escenarios alternativos de movimientos y contra-
movimientos que crean un equilibrio dinámico entre actuar y reaccionar.
Del mismo modo, en una empresa usted debe supervisar continuamente el entorno de funcionamiento
interno y externo y hacer movimientos tácticos y estratégicos a fin de evitar situaciones catastróficas y al
mismo tiempo aprovechar las oportunidades para maximizar el éxito de la misión. Las grandes empresas

del sector público y privado han utilizado escenarios futuros para un determinado número de años para
apoyar su planificación, podemos mencionar en este caso a Royal Dutch Shell y el Banco Mundial, a nivel
país aún no se ha encontrado una iniciativa de este tipo.
El papel que pueden jugar los escenarios futuros en el desarrollo de la vista arquitectónica futura implica
que usted identifique una gama de opciones de funcionamiento y los supuestos de planificación de la
empresa. El desarrollo de varios escenarios que reflejan una variedad de entornos operativos buenos
y malos ayuda a la empresa a pensar a través de sus respuestas probables (movimientos defensivos)
e iniciativas (movimientos ofensivos) de anticipación. También le ayudaran a identificar los recursos
y capacidades que se necesitarán para esas respuestas / iniciativas. Los escenarios CONOPS pueden
ser bastante detallados, y se usan para documentar tanto el entorno operativo actual, y un número
de posibles entornos operativos futuros. Las empresas deben identificar una serie de factores internos
y externos del Análisis FODA para decidir qué escenarios futuros CONOPS documentar. EL hecho que
usted cuente con un número de escenarios futuros es útil para la empresa, ya que es imposible predecir
qué factores internos o externos entran en juego ya sea para crear un entorno de trabajo hostil o útil.
Uno de los formatos más eficaces para el desarrollo de una versión abreviada de un escenario CONOPS,
este tipo de escenarios tiene la forma de un cuento que se narra a través de los ojos de un personaje
central que está implicado en los acontecimientos futuros que revelan los factores internos y externos
de la empresa y el entorno operativo de la tecnología de la época. Estos controladores son entonces
relacionados con supuestos de planificación específicos en tres áreas de cambio: procesos, personas
y tecnología. Establece que las historias son fáciles de recordar y pone de relieve que la hipótesis de
planificación, revela los recursos y capacidades que se necesitarán si ese escenario se implementa.
La necesidad de la empresa para conocer con detalle los planes estratégicos no puede ser sustituido
por escenarios, más bien, los escenarios pueden servir para resumir y dar energía a la esencia de varios
cursos de acción que se pide en el plan estratégico, y hacerlos más relevantes.
A continuación detallamos un escenario de planificación en el que se describen algunos supuesto de

planificación:
Supuestos de planificación
1. Nuevo sistema de Vídeo teleconferencia.

2. Roll-outs de productos en las conferencias nacionales.
3. Necesidad de mantener discusiones detalladas de los productos a corto plazo, a nivel mundial.
4. Disponibilidad de trabajo 24 × 7.
5. Incremento de los desplazamientos y el teletrabajo.
6. Seguimiento de los informes de los gobiernos para anticiparse a las necesidades del producto.
7. Los cambios demográficos de la población, impulsados por el desarrollo de nuevos productos.
8. Mayor costo beneficio de la iluminación con energía solar.
9. Incorporación continúa de características adicionales del producto para expandir la base de
clientes.
10. El consumo mundial de PDA´s para la comunicación entre empleados.
11. Integración de las ventas, marketing e información de producción.
12. Citas sobre la marcha con clientes.

Actividad Propuesta
Revise el caso de estudio “Haciendo una Venta en 2008 – Desafíos Futuros para
DMC“en esta lectura encontró temas de interés que fundamenta los escenarios
futuros de planificación arquitectónica.
Haciendo una venta en 2008
Desafíos Futuros para la DMC
Jeff Lander, Vicepresidente de Ventas Industriales en Danforth Manufacturing Company (DMC) acababa
de terminar una presentación en la Conferencia Nacional de Seguridad Vial 2008 junto con Richard
Danforth, CEO de DMC, Jeff salía de la sala principal de conferencias, cuando Andrea Newman, Director
de Seguridad y Transporte del Estado de Tennessee, le preguntó si podían hablar por unos minutos acerca
de la nueva línea de las carreteras asistidas por energía solar que acababa de dar en una presentación.
“Gracias por tomarse un minuto para hablar, Jeff.Quiero comentarle de una situación que tenemos en
Tennessee y ver si su nueva línea de productos nos puede ayudar “, dijo Andrea, “ No hay problema,
gracias por preguntar “, dijo Jeff.Andrea sacó un documento en su tableta y dijo: “Jeff, este es un informe
que muestra un incremento en el número de accidentes graves en las zonas rurales de Tennessee
que involucran vehículos de pasajeros, equipo agrícola y camiones comerciales.Lo hemos atribuido al
crecimiento de las comunidades suburbanas más lejanas más aún en el campo, que luego dependerán
de caminos rurales de dos carriles para los desplazamientos hacia la cuidad, entonces usted tendrá una
receta para el desastre cuando por estas transiten tractores y camiones lentos, junto con los coches
que tienen prisa a todas horas para llegar a algún lugar, ““¿No es este problema que se observa en otros
lugares del país?”preguntó Jeff.“Sí, y uno de los factores que contribuyen a la alta incidencia de accidentes
nocturnos es la falta de una buena iluminación en las carreteras. Pienso que la iluminación solar para
carreteras desarrollada por ustedes puede ayudarnos a proporcionar más tiempo de visibilidad nocturna
en las carreteras rurales de alto riesgo sin tener que invertir en una infraestructura de apoyo eléctrico”.
Jeff pensó un momento antes de responder.“Usted sabe, la nueva línea de luces de carretera tiene
opciones para incorporar cajas de llamada de emergencia 911 y Sistema de Posicionamiento Global
(GPS) que se puede conectar tanto a nivel estatal como local en primer lugar. Andrea asintió con la
cabeza y dijo: “Sí, no creo que una mejor iluminación va a resolver todo el problema, pero va a ayudar
a la gente, y las otras opciones pueden mejorar los tiempos de respuesta de accidentes, que también
salvan vidas.¿Cuál es el precio de estas unidades? “Jeff sacó su Asistente Personal Digital (PDA) I/O de
su bolsillo y se conectó a la base de datos de comercialización y ventas de DMC a través del satélite
Internet link. Andrea, estas unidades cuestan 11.300 dólares cada uno, incluyendo el GPS y funciones
911.”Andrea tomó notas y respondió: “Si puedo conseguir el permiso para llevar a cabo una prueba piloto
en un par de meses usted nos puede proporcionar las luces?”Jeff le preguntó “¿Cuántos kilómetros de
carretera?”“Cerca de cuatro kilómetros en el área particular ‘dijo Andrea.“Ok, la densidad sugiere para
la nueva unidad es de 18 por milla, por lo que serían 72 unidades totales.Te puedo dar un descuento
del 10% por ser uno de los primeros compradores por lo que el total serían 732.240 dólares.Déjame ver
el tiempo de envío.Jeff envió un e-mail de alta prioridad a Bob Green, Vicepresidente de Manufactura.
Bob estaba en la fábrica cuando recibió el correo electrónico de Jeff y previa comprobación del Sistema
de Programación de producción DMC, respondió dos minutos después, indicando que una orden
especial por 72 unidades podría ser completada y enviada en 35 días después que se recibe el pedido.
Jim transmitió esta información a Andrea, quien dijo: “Wow, eso fue rápido.Tengo toda la información
que necesito para proponer el proyecto piloto.Me pondré en contacto con usted en la próxima semana.
Gracias.

Una vez que ha leído con atención el caso de estudio, destaque las
principales ideas y asócielas con los componentes arquitectónicos de la
vista arquitectónica futura
5.2. Actualización de las vistas arquitectónicas futuras - Control de Versión
En algún momento, los nuevos componentes y artefactos en la vista arquitectónica de futuro se

implementarán y por lo tanto deben ser documentados como parte de la visión actual de la misma. Los
cambios que se presenten representan un reto en cuanto a la mejor manera de mostrar en cualquier
momento que es lo actual y que está planificado. Tal vez la forma más simple y efectiva de abordar esto
es “congelar” las vistas arquitectónicas actuales y futuras en períodos regulares (por ejemplo, dos veces
al año), esto con la finalidad de promover la claridad y apoya el control de versiones Utilizando este
ejemplo, los cambios en la las vistas actuales y futuras se recogen durante cuatro o cinco meses y luego
se publican en los seis meses siguientes como una nueva versión arquitectónica de la empresa.
Los Stakeholders de la AE esperan las nuevas versiones y saben que puede confiar en la información
que no cambiará en el repositorio para los próximos meses. Versiones especiales se pueden hacer si se
produce un cambio importante en la mitad del período que normalmente es estático. Sin este tipo de
control de versiones, el repositorio de AE se convertiría un lugar de libre acceso en donde nadie está
seguro de cuándo y dónde aparecerán los cambios, y esto redundará en detrimento de la percepción del
valor de la información arquitectónica.
Los siguientes son ejemplos de cómo los nuevos artefactos arquitectónicos así como los actualizados
se documentan en la visión de futuro de los componentes relacionados con todos los niveles del Marco.
5.3. Artefactos arquitectónicos del Nivel Estratégico de AE – Vista de Futuro
Componentes AE:
• Plan Estratégico
• Plan de Comercio/Gobierno electrónico
Artefactos AE:
• Plan Estratégico (Sl)

• Análisis FODA (S-2)
• Concepto del escenario de operaciones (S-3)
• Concepto de Diagrama de Operaciones (S-4)
• Balanced Scorecard (S-5)
Los componentes y artefactos arquitectónicos en el nivel estratégico del Marco EA3

sirven para articular la dirección general y las prioridades que la empresa debe cumplir
junto con los objetivos, iniciativas y medidas que definen el éxito.

El Plan de Negocios/Gobierno electrónico luego sirve para proporcionar descripciones más detalladas
de cómo las iniciativas de TI apoyará al Plan Estratégico de la empresa, con un enfoque en los objetivos
estratégicos y los servicios clave del negocio. Los planes actualizados se publicarán continuamente para
reflejar los cambios en la dirección y las prioridades que la empresa tiene la intención de adoptar. La
visión de futuro de estos planes puede servir como documentos de proyectos en el que los cambios
potenciales que tienen patrocinio ejecutivo se registran hasta la publicación oficial de los nuevos planes.
La visión de futuro de estos componentes debe ligarse a la visión de futuro de todos los artefactos
relacionados con la AE, como los objetivos estratégicos, los escenarios, las iniciativas y medidas de
desempeño.
Escenarios Estratégicos
Los escenarios estratégicos pueden ser añadidos o borrados de la vista futura del Plan Estratégico en
respuesta a cambios en el entorno operativo interno y externo.
Promover la comparación y el análisis de los posibles escenarios futuros que deberían documentarse
de la misma manera, en que el escenario actual está documentado: como una narrativa integrada y un
conjunto de supuestos de planificación de alto nivel sobre las prioridades de la empresa, el rendimiento,
recursos y los riesgos.
Objetivos Estratégicos
Mientras que la visión actual de TI relacionada con los objetivos estratégicos representan a los artefactos
arquitectónicos de alto nivel que se documentan en el Plan Estratégico de la empresa, la visión de
futuro de estos artefactos en cambio representan cambios en los objetivos o metas que aún no están
formalmente aprobadas y publicadas como parte del Plan. Los nuevos objetivos estratégicos también
sirven para dirigir el desarrollo de escenarios operativos futuros, que deben captar las prioridades y la
dirección de esas nuevas metas.
Iniciativas Estratégicas
La visión actual de TI relacionada con las iniciativas estratégicas sirve para crear conciencia y aprecio por
el papel que TI desempeña en apoyo a los principales procesos administrativos y de negocio a través de
la empresa. También soporta la planificación de recursos de alto nivel, también conocida como procesos
de planificación de capital y control de las inversiones (CPIC). La visión de futuro de TI relacionada con
las iniciativas estratégicas pretende mostrar los cambios que se están planificando para las iniciativas
existentes, así como las nuevas iniciativas que se presentarán en los próximos años. Esto es especialmente
valioso para las empresas que tienen procesos estructurados de planificación y presupuesto.
Medidas de Desempeño:
Los cambios en las iniciativas y objetivos estratégicos en las vistas futuras requerirán salidas nuevas o
modificadas y medidas de éxito.
Actividad Propuesta
Describa algunos objetivos y escenarios estratégicos para una empresa en
particular. Si tiene alguna inquietud no dude en consultar con su profesor tutor.

5.4. Artefactos arquitectónicos del Nivel de Negocios - Vista de Futuro
Componentes:
• Cadenas de Suministro
• Portafolio de planificación de capital de TI.
Artefactos:
• Plan de negocios (B-1)

• Diagrama de conectividad del nodo (B-2)
• Diagrama de proceso (B-3)
• Procesos de Negocio / Modelos de servicios (B-4)
• Matriz Proceso/Producto del negocio (B-5)
• Casos de uso y diagramas narrativos (B-7)
• Inversión Caso de Negocios (B-8)
Las empresas cambian continuamente sus servicios en respuesta a una serie de factores que influyen en las
necesidades del cliente, incluyendo nuevas y diferentes estrategias competitivas, las nuevas tecnologías
y los cambios en la disponibilidad de recursos. Estos factores (también conocidos como controladores)
están documentados tanto en el nivel estratégico y de negocio del Marco. La documentación de los
conductores en el nivel estratégico se centra a menudo en aquellos factores que se originan en un entorno
operativo externo, mientras que la documentación de los conductores del Nivel de negocios a menudo
se centra en los factores que se originan en el entorno de funcionamiento interno. Los componentes
arquitectónicos a nivel empresarial se pueden extender más allá del entorno de funcionamiento
interno (es decir, cadenas de suministro con proveedores externos), pero son fundamentalmente los
procesos de gestión internos. Las vistas futuras de los artefactos arquitectónicos relacionados, reflejan
principalmente los cambios aprobados a estos servicios de negocio y a las actividades asociadas a la
implementación
Hay cuatro tipos generales de cambios en los servicios de negocio que se presentan:
1. La introducción de un proceso totalmente nuevo,

2. La eliminación de un proceso existente,
3. La reingeniería de un proceso existente, y
4. Mejoras mínimas de un proceso existente.
La gestión eficaz en el ámbito empresarial requiere que estos cambios se coordinen para que el
rendimiento de la empresa no disminuya.
Por lo tanto, los exámenes a los servicios empresariales existentes deben realizarse periódicamente por
los administradores de las líneas de negocio para identificar a aquellos que puedan estar obsoletos,
duplicados o con un valor añadido insuficiente para el logro de los objetivos estratégicos.
Las decisiones resultantes de eliminar o cambiar los procesos existentes, o añadir nuevos procesos, son
los que se documentan en la visión de futuro del Nivel de Negocios en lo que tiene que ver a componentes
y artefactos.

Proceso de Documentación.
Al igual que el enfoque de documentar las vistas futuras en nivel estratégico del marco, sólo los cambios
potenciales a los servicios empresariales que tienen patrocinio ejecutivo deben ser documentados en el
nivel empresarial. Así se mantiene el valor de la visión de futuro y se promueve el uso de esta información
para la planificación y toma de decisiones.
Documentar los cambios aprobados en los servicios de negocio ayuda a mantener la “alineación hacia
arriba”, en el marco con los objetivos estratégicos e iniciativas. Asimismo, promueve la “alineación hacia
abajo” para asegurar que los componentes y artefactos en los tres niveles más bajos están correctamente
ajustados para soportar mejor los cambios en los procesos previstos. La empresa debe ser coherente en
como los procesos de negocio actual y futuro están documentados (por ejemplo, los modelos IDEF-O,
diagramas de carreteras y / o diagramas de flujo), de modo que el análisis y la planificación sea soportada
de mejor manera.
El Plan de Gestión de Proyectos (PGP) es un documento vivo que promueve enfoques

probados y estandarizados para la implementación o actualización de los recursos de TI.
La visión actual del Plan de Gestión de Proyectos se desarrolla en la fase de planificación
de requisitos del ciclo de vida del proyecto, con las actualizaciones con las que se
realizan los cambios en los requisitos, soluciones, o recursos.
La visión futura del PGP puede no ser necesaria en ciertos enfoques del desarrollo de componentes
arquitectónicos, también conocido como Análisis de Sistemas y Métodos de Diseño (SADMS) que
promueven el desarrollo de todas las capacidades del sistema en un esfuerzo (por ejemplo, “cascada”
o “desarrollo rápido de aplicaciones “métodos). Sin embargo, los enfoques SADM que promueven el
desarrollo incremental (por fases) o evolutivo (espiral) de componentes pueden beneficiarse de tener
una visión futura del PGP para mostrar la implementación de los módulos del sistema que se prevén en
un futuro. La implementación gradual de los grandes proyectos de ERP con varios módulos podría ser un
ejemplo en donde tener tanto una visión actual y futura del PGP sería beneficiosa. El PGP se mantiene a
través de todo el ciclo de vida de sistemas.
Casos de Negocio.
El caso de negocio de inversiones es la parte del PGP que documenta el valor de la inversión para la
empresa. El caso de negocio es único, ya que se vincula directamente al presupuesto de la empresa y al
proceso de planificación financiera, y por lo general requiere una revisión al año. La aprobación inicial
de los casos de negocio en la identificación de los beneficios que superan los costos (tanto cuantitativos
como cualitativos). La aprobación también se centra en la determinación de la tasa de retorno sobre el
capital invertido (ROI) cumple con los objetivos mesurables establecidos por la empresa, de tal manera
que otro uso de esos fondos no se justifica (costo de oportunidad). El caso de negocio debe entonces
ser revisado anualmente para determinar si se generarán los beneficios suficientes para que amerite la
inversión continua. Si no es así, la inversión debe ser cancelada o modificada de tal manera que el valor
actual sea suficiente.
5.5. Artefactos arquitectónicos en el nivel de Información – Vista Futura
Componentes:
• Bases de datos

Artefactos:
• Plan de Gestión del Conocimiento (Dl)

• Matriz de intercambio de información (D-2)
• Diagrama de transición de estados (D-3)
• Diagrama de secuencia (D-4)
• Modelo lógico de datos (D-5)
• Modelo Físico de Datos (D-6)
• Matriz Entidad Relación (CRUD) Matrix (D-7)
• Diccionario de datos / biblioteca de objetos (D-8)
Las vistas futuras de los componentes y artefactos arquitectónicos en el nivel de información Marco
Reflejan los cambios que se anticipan en la colección de flujos de información que se necesitan para
apoyar cambios en los servicios de negocio (alineación hacia arriba) o los cambios que se anticipan a los
Sistemas / Servicios o el nivel de Infraestructura Tecnológica del Framework.
5.5.1. Modelos de datos
Las vistas tradicionales de los modelos de datos que muestran la estructura (Diagramas Entidad-Relación) y
el proceso (Diagramas de Flujo de Datos) puede ser desarrollados para mostrar los cambios en el futuro,
ya sea como documentos separados o mediante el uso de notación especial que puede ser integrada en
la visión actual (por ejemplo, la uso de líneas discontinuas y símbolos para mostrar las entidades de datos,
flujos futuros, tiendas). Cualquiera que sea el enfoque que se adopte, la idea importante es proporcionar
una vista de futuro de la estructura de datos y procesos de una manera que es directamente comparable
a la vista actual de modo que las zonas de cambio se pueden identificar fácilmente.
Otro artefacto “tradicional” de modelado de datos que amerita el desarrollo de una visión de futuro
es la Matriz de Actividad/Entidad (también llamado matriz CRUD). Esta matriz mapea las actividades
que se producen en los límites del sistema de TI para las entidades de datos que se ven afectadas Esta
mapeo permite al analista de datos y arquitecto de la empresa ver dónde y cómo los datos se crean, leen,
actualizan o se eliminan (CRUD). Se debe identificar quien en la empresa es responsable (propietario)
de la actividad, el propietario lógico de los datos y también los procesos que transforman los datos. La
visión actual de la matriz CRUD y el conocimiento de los cambios futuros en los servicios empresariales
permite el desarrollo de una vista de futuro de la matriz CRUD, que identifica cambios potenciales en
la propiedad de los datos y que pueden dar lugar a discusiones sobre los cambios en los estándares
de datos y formatos. Las actividades de consolidación, actualización o reemplazo del sistema de TI que
buscan mejorar la eficiencia en el manejo de datos o incrementar el costo-efectividad del nuevo sistema
se beneficiarán de un análisis detallado de los puntos de vista actuales y futuras de la matriz CRUD.
5.5.2. Datos orientados a objetos
Las vistas de futuro Orientadas a Objetos (OO) de las actividades del sistema (Casos de Uso), los datos de
proceso / estructura (clases y diagramas de objetos), la transformación de datos (diagramas de estado
de transición), y los flujos de información (diagramas de secuencia) debe ser desarrollados de la misma
manera que fueron desarrollados los artefactos de la visita arquitectónica actual para que se pueda
realizar una fácil identificación de los cambios.
Una de las razones más poderosas para adoptar un enfoque 00 dirigido al modelado de datos y al
análisis de sistema de TI es que los objetos se puedan modificar con un mínimo de esfuerzo para reflejar
los cambios en los requisitos o utilizarlos en diferentes escenarios. La reutilización de objetos reduce el
costo de los proyectos de actualización de sistemas y permite el uso de aplicaciones modulares basadas

en objetos (por ejemplo, las aplicaciones Java). El desarrollo de las vistas futuras implica conocer cómo
la información en forma de objetos será almacenada y como esta ayudará a analistas, programadores
y arquitectos a producir mejores modelos de datos lógicos y físicos que promueve la interoperabilidad
de aplicaciones y soporten los componentes arquitectónicos plug and play, que se basan en estándares
abiertos o en una línea de producto de un proveedor en particular.
5.5.3. Diccionarios de datos / bibliotecas de objetos
Los diccionarios de datos proporcionan taxonomías y formatos estándar para las entidades de datos que
se utilizan en los diversos sistemas empresariales de TI. Los diccionarios de datos no almacenan datos
reales, solamente proporcionan una lista de entidades, atributos, formatos de datos y estándares. Estas
normas ayudan a promover la interoperabilidad de los sistemas y la consolidación de las bases de datos.
En la visión de futuro de un diccionario de datos mostraría los cambios en los estándares y formatos
de los datos y que se prevé que se necesitan como resultado de los cambios realizados al sistema de
aplicación de base de datos.
Las Bibliotecas de objetos son similares en concepto, excepto que estas almacenan tanto los formatos /
normas y los módulos actuales de código que constituyen un objeto. Dado que una de las características
básicas de los objetos es la encapsulación (protección contra la alteración de partes de código) la
biblioteca de objetos puede almacenar objetos distintos al igual que un una estantería de libros Varias
versiones de un objeto pueden ser almacenadas por separado para su uso en diferentes sistemas y
aplicaciones (por ejemplo, un objeto factura que ofrece diferentes tipos de facturas a la medida para
diferentes líneas de productos).
5.6. Artefactos arquitectónicos en el Nivel Sistemas / Servicios - Vista de Futuro
Componentes:
• Servicios Web
• Planificación de recursos empresariales (ERP)
• Sistemas Operativos
Artefactos:
• Diagrama de Interfaces del sistema(AS-I)

• Diagrama comunicación del sistema (SA-2)
• Matriz de Interfaz del sistema (SA-3)
• Diagrama de flujo datos del sistema (SA-4)
• Matriz Operaciones del Sistema (SA-5)
• Sistemas de Intercambio de Datos Matrix (SA-6)
• Matriz de rendimiento del sistema (SA-7)
• Diagrama de evolución del sistema (SA-B)
• Diagrama de aplicaciones Web (SA-9)
El nivel de sistemas / servicios del marco EA3 se organiza en torno a componentes integrados “plug-and-
play” basados en estándares abiertos, y los objetos reutilizables de código que son la base de un enfoque
basado en componentes y orientada a servicios, como se promueve en el marco EA3. Varios artefactos se

utilizan para documentar los componentes futuros a nivel de Sistemas / Servicios, incluyendo el código
del programa y la documentación técnica de las versiones y actualizaciones; diagramas de interfaz, y las
normas técnicas.
5.6.1. Interfaz de Programación de Aplicaciones
La descripción de las interfaces de programación de aplicaciones en la vista de futuro proporciona una

visión de lo que va a cambiar a partir de lo que está actualmente en funcionamiento, así como las nuevas
capacidades funcionales que tendrán que ser integradas. Las interfaces de programación de aplicaciones
(API) son una característica de la mayoría de los programas comerciales de software y es donde los
puntos de interfaz diseñados en el código de programación se encuentran. Las API´s definen el grado
de interoperabilidad y puede incluir estándares abiertos para lograr máxima integración con una amplia
gama de otros productos. Por el contrario, las API puede ser propietario y limitar la interoperabilidad de
los productos de un proveedor específico (por ejemplo, las interfaces entre los módulos de un producto
ERP). Los artefactos AE en este nivel son la descripción técnica de las API y la lista de las normas API.
5.6.2. Diagramas para Interfaces de Programación de Aplicaciones
Los diagramas de interfaz en la vista de futuro muestran los cambios en el sistema actual, los servicios y los
puntos de interfaz de la aplicación. En las API´s es en donde se producen los intercambios de información
y se infiere la conectividad que se muestra con más detalle en el nivel de infraestructura de tecnología
de la AE. Los diagramas de interfaz son también importantes para mostrar cómo componentes de las
aplicaciones interactúan en el entorno operativo de la empresa, incluido el modo en que los servicios
web intercambian información a través de los servicios de la Plataforma NAP Web Service. En el caso de
que estas aplicaciones sean productos comerciales de diferentes proveedores, estas interfaces pueden
identificar dónde la compatibilidad debe estar presente y, como tal, ayudar a establecer las necesidades
futuras de integración.
5.6.3. Normas de documentación técnica
En las vista futuras, se muestran las normas de documentación técnica en base a los estándares
internacionales, nacionales, locales y de la industria que cambian a servicios comerciales y de desarrollo
a la medida; esto incluye las API´s y otros requisitos de interoperabilidad y rendimiento; las descripciones
WSDL (Web Service Description Languaje), y los registros de servicios web
5.7. Artefactos arquitectónicos en el Nivel de Infraestructura. Vista Futura
Componentes:
• Redes de Datos
• Redes de video
Artefactos:
• Diagrama de conectividad de red (NI-I)

• Inventario de red (NI-2)
• Inventario de equipamiento (NI-3)
• Planos de construcción (NI-4)
• Diagrama de centros de red (NI-5)

• Diagramo de la Planta de Cableado (NI-6)

• Diagrama de distribución de Racks (NI-7)
En el nivel de infraestructura tecnológica del marco arquitectónico se documentan componentes tales

como las redes de voz, datos y vídeo, así como las soluciones de seguridad empresariales. Uno de los
objetivos de la AE es promover la integración de estas redes en un solo Backbone tecnológico, la vista
futura de los artefactos de AE a este nivel documenta los cambios en esta infraestructura.
Documentación de Redes
La documentación de redes empresariales de TI en la vista futura muestra los cambios en la infraestructura

de los componentes de voz, datos y video. Las redes empresariales LAN, WAN, y otras redes se presentan
principalmente en los diagramas y documentos de especificaciones técnicas. Estos artefactos de AE
deben enfocarse en los cambios en el cableado, Wireless, armarios de cableado de telefonía y de datos,
hardware y software de red, servidores, computadoras de escritorio y portátiles, periféricos, y los recursos
de acceso remoto.
Normas Técnicas.
La documentación de estándares técnicos de la red de TI en la vista futura muestra los cambios en las
normas nacionales, internacionales y comerciales que se utilizan para guiar los cambios en el Backbone
tecnológico de la empresa. Esto incluye cambios en las normas que figuran en los modelos de redes,
incluyendo el modelo OSI y el modelo TCP / IP. También incluye estándares para telefonía, comunicaciones
inalámbricas y de video conferencia a distancia.
Seguridad en la documentación.
Las vistas futuras de documentación muestran los cambios esperados en los estándares de seguridad,
planes, pruebas y certificación de cada sistema de TI y el componente de red arquitectónica, así como la
documentación relacionada con la seguridad para las aplicaciones y bases de datos.
La gestión del cambio.
La visión de futuro consta de un archivo de solicitudes de cambio (EACRs) aprobadas y aún por ejecutar.
Estos documentos EACRs documentan el impacto técnico y operativo de los cambios en los componentes
en todos los niveles de la AE. Consulte la Unidad 6 para obtener más información sobre EACRs.
Hardware / Software
El artefacto arquitectura en esta área de la vista de futuro es una lista que documenta los cambios previstos
en la cantidad y tipo de productos de hardware y software y que se utilizaran en los componentes de AE
a través de cada uno de los niveles del marco de AE.
En esta unidad se proporcionan ejemplos de artefactos que documentan las vistas futuras de los
componentes arquitectónicos en todos los niveles del Marco. El uso de escenarios futuros es una forma
de identificar posibles entornos operativos y supuestos de planificación en los que deben basarse las
vistas arquitectónicas futuras. Las mismas técnicas de documentación se deben utilizar en el desarrollo
tanto de las vistas actuales como futuras de los componentes arquitectónicos, para que los cambios
sean más fáciles de destacar y comparar. En la unida 6 se describe el propósito y la composición de un
Plan de Gestión, que proporciona una descripción de la transición en curso entre vistas arquitectónicas
actuales y futuras de la AE.

Autoevaluación 5

alguna inquietud no dude en contactar con su profesor tutor.
1. La vista arquitectónica futura provee la documentación:
a. Del desempeño actual de los sistemas de TI.

b. De los cambios identificados en cuanto a los objetivos estratégicos, servicios de negocios,
flujos de información, solicitudes de apoyo y recursos de red.
c. Para la revisión de la operación de los procesos organizacionales
2. Los cambios potenciales dirigidos a los componentes arquitectónicos actuales incluyen a:
a. Los objetivos e iniciativas estratégicas, servicios de negocios, flujos de información, sistemas,

aplicaciones y redes de apoyo nuevas o actualizadas.
b. Los artefactos que documentan a los componentes arquitectónicos existentes en toda la
empresa.
c. Un conjunto de entregables que se han establecido para completar una parte o la totalidad
del programa.
3. Los cambios en la las vistas actuales y futuras:
a. Se recogen durante cuatro o cinco meses y luego se publican inmediatamente como una
nueva versión arquitectónica de la empresa.
b. Se recogen y actualizan en periodos cortos de implementación
c. Se recogen durante cuatro o cinco meses y luego se publican en los seis meses siguientes
como una nueva versión arquitectónica de la empresa.
4. El uso de escenarios futuros es una forma de:
a. Identificar posibles entornos operativos y supuestos e planificación en los que deben

basarse las vistas arquitectónicas futuras.
b. Identificar entornos operativos y supuestos e planificación definitivos en los que deben
basarse las vistas arquitectónica futuras.
c. Describir el proceso de transición del estado actual al futuro.

5. Las API’s :
a. Definen el grado de interacción entre los diferentes objetos de la arquitectura.

b. Definen el grado de interoperabilidad, así como así como las nuevas capacidades funcionales
que tendrán que ser integradas a la vista arquitectónica futura.
c. Definen como se integraran los sistemas de TI al contexto arquitectónico de la organización.
6. Las ECAR´s documentan:
a. Las solicitudes de cambio de cada nivel operativo de la AE.

b. El impacto técnico y operativo de los cambios en los componentes en ciertos niveles
específicos de la AE.
c. El impacto técnico y operativo de los cambios en los componentes en todos los niveles de
la AE.
7. Los escenarios estratégicos pueden ser añadidos o borrados de la vista futura del Plan Estratégico
en respuesta a:
a. Cambios en los objetivos e iniciativas estratégicas.

b. Cambios en el entorno operativo interno y externo.
c. Cambios en los componentes arquitectónicos.

UNIDAD 6. DESARROLLO DE UN PLAN DE GESTIÓN DE ARQUITECTURA EMPRESARIAL
La unidad 6 describe el desarrollo del Plan de Gestión arquitectónico, que es el documento que le
ayudará a describir cómo la empresa se encargará de la transición de sus procesos y recursos actuales y
que se necesitarán en el futuro. Esta transición del estado arquitectónico actual al futuro es una actividad
continua de cómo los nuevos recursos son implementados, y se convierten en parte de la arquitectura
actual. También se discute el propósito de la gestión de la configuración y el control de versiones, junto
con la necesidad de proporcionar una secuencia para proyectos de implementación.
• Comprenda los efectos de un Plan de Gestión.

• Describa un ejemplo de formato para un plan de gestión de arquitectónica.
• Comprenda los tipos de contenidos que van en un Plan de Gestión.
• Entienda el propósito de los resúmenes de la arquitectura actual y futura.
El Plan de Gestión documenta las brechas de desempeño, la necesidad de recursos, las soluciones
planeadas, un plan de secuenciación, y un resumen de la arquitectura actual y futura. El Plan también
describe el proceso de gobierno arquitectónico, la metodología de implementación y el marco de
documentación. Se trata de un documento vivo que se actualiza a intervalos regulares (por ejemplo,
anualmente) para proporcionar un control de versión clara de los cambios en la visión actual y futura de
los componentes y artefactos arquitectónicos de todo el marco. El Plan de Gestión debe archivarse en
el repositorio de AE para apoyar el acceso fácil a la información y promover la vinculación de la AE con
otros procesos de gestión de TI.
La arquitectura empresarial está en continua transición una vez que los proyectos de implementación y
actualización se han completado. Las grandes y medianas empresas a menudo tienen muchos proyectos
de TI en marcha en un momento dado, lo que requiere un nivel general de coordinación, priorización y
supervisión. Como se muestra en la Figura 6.1, el Plan de Gestión ofrece esta coordinación y soporte para
los cambios las vistas arquitectónicas actuales y futuras en las empresas.

El Plan de Gestión es como el plan del arquitecto del proyecto, que resume el trabajo y muestra el diseño,
el enfoque, el calendario y la secuencia de los trabajos para la remodelación de una casa.
La transición arquitectónica y la gestión que existe plan de gestión, tiene varias secciones como se
muestra a continuación:
Plan de Gestión Arquitectónica: Parte 1.
6.1. Gestión del Programa Arquitectónico
La Arquitectura Empresarial se plantea como un programa de gestión y apoyo al desarrollo de políticas,

el proceso de toma de decisiones y el uso eficaz / eficiente de los recursos. La sección de Gestión de
Programas AE documenta las actividades relacionadas con la administración arquitectónica como un
programa en curso.

6.1.1. Gobernanza y Principios
En esta sección se documenta la forma en que las políticas y la toma de decisiones se producirán dentro
del programa. También es donde los principios subyacentes del programa son articulados. La gobernanza
arquitectónica es quizás mejor descrita a través de una narrativa que ofrece el programa a través de
políticas arquitectónicas y un diagrama de flujo que muestra cómo y cuándo se toman las decisiones sobre
cuestiones arquitectónicas, como las propuestas de inversión en TI, revisión de proyectos, aprobación
de documentos, y la adopción de normas/exenciones. Los principios arquitectónicos articulan los
valores de la empresa y su relación con la AE. Estos principios luego guían el establecimiento y gestión
del programa. Algunos ejemplos de principios arquitectónicos son (1) el grado en que la empresa
promueve el intercambio abierto de información, (2) un énfasis en la participación de los interesados, (3)
el reconocimiento de que es normalmente un medio y no un fin en sí mismo, (4) el énfasis en el uso de
productos comerciales que se basan en estándares abiertos, y (5) el reconocimiento de que la AE agrega
valor en la planificación, la toma de decisiones y la comunicación.
6.1.2. Soporte a la Estrategia de Negocios
En esta sección se pone de relieve que uno de los principales objetivos del programa es apoyar y
mejorar la planificación estratégica y de negocios de la empresa, así como identificar las brechas de
desempeño que los componentes de arquitectónicos pueden ayudar a cerrar. Al mostrar cómo se
están utilizando los componentes arquitectónicos, y a través de la identificación de nuevos procesos
y tecnologías útiles en cada nivel de la estructura, se pueden producir mejoras en el rendimiento que
se reflejará en la vista arquitectónica futura. Para que los componentes arquitectónicos puedan ser
vistos como activos estratégicos y considerarse como parte del proceso de planificación estratégica, los
ejecutivos del negocio deben valorar la importancia del programa tomando en cuenta de los resultados
que son importantes para ellos. Por tanto, es importante mostrar la vinculación del programa para el
cumplimiento de los objetivos estratégicos de la empresa, así como mostrar con claridad cómo los
componentes arquitectónicos apoyan la línea de las actividades empresariales.
6.1.3. Roles y Responsabilidades AE
En esta sección se documenta el papel que las partes interesadas juegan en el programa, y cuáles
son las responsabilidades asociadas con los mismos. La Figura 6.1. muestra algunos de los roles y
responsabilidades que manejan dentro de un programa:
POSICIÓN DENTRO DEL EQUIPO DE

ROL EN EL EQUIPO DE AE RESPONSABILIDAD
AE
Ejecutor del proyecto
Provee recursos
Patrocinador Liderazgo Ejecutivo.
Ayuda a resolver problemas de
alto nivel.
Facilitar el establecimiento de las
Liderazgo ejecutivo y toma de operaciones en curso del
Jefe de la oficina de Información (CIO)
decisiones. programa. Liderar la resolución
de problemas de alto nivel.
Gestiona el programa y el
proceso de documentación.
Selecciona e implementa la
metodología arquitectónica y de
Jefe de Arquitectura Manejo del Programa de AE.
documentación. Identifica los
estándares y gestiona los sub-
procesos de gestión de la
configuración.

POSICIÓN DENTRO DEL EQUIPO DE

ROL EN EL EQUIPO DE AE RESPONSABILIDAD
AE
Participa en la toma de
decisiones del ´programa.
Identificación de
Administrador de Líneas de Negocios Promueve la identificación de
Requerimientos.
soluciones de TI relacionadas
con cada LOB.
Colabora en la identificación de
soluciones de TI relacionadas
Resolver problemas de
Arquitecto de Soluciones con problemas dentro de cada
arquitectura.
LOB. Apoya el proceso de
documentación
Provee análisis técnico y soporte
al diseño para la selección e
implementación de
componentes. Garantiza que los
Arquitecto de Sistemas Análisis y Diseño. sistemas de TI cumplen con
requerimientos de integración e
interoperabilidad. Apoya al
proceso de documentación
arquitectónica.
Provee análisis técnico y soporte
al diseño para la selección e
implementación de bases de
datos. Garantiza que las bases de
Arquitecto de Datos Análisis y Diseño. datos cumplen con
requerimientos de integración e
interoperabilidad. Apoya al
proceso de documentación
arquitectónica.
Mantenimiento del software de
Experto en Herramientas de Soporte en aplicaciones y base aplicación.
Arquitectura Empresarial de datos. Mantenimiento del repositorio
de información.
Identificar requerimientos de
usuario-final para los
Verificador de Requerimientos Control de Calidad. componentes arquitectónicos.
Proveer retroalimentación sobre
la efectividad de las soluciones,
Mantenimiento de los sitios web,
contenido asociado. Asiste en
Administrador Web Soporte - aplicativos web. actividades de diseño y
documentación de
componentes arquitectónicos.
Documenta y verifica los
requerimientos de usuario final
de cada LOB. Asiste en
Analista de Investigación. Analista de Requerimientos.
actividades de diseño y
documentación de
Figura 6.1. “Roles y Responsabilidades de AE” tomado de: Scott A. Bernard 2012.
6.1.4. Presupuesto del Programa
Esta sección documente el presupuesto del programa por año fiscal y por el ciclo de vida total, por lo que
se identifica el Costo Total de Propiedad (TCO). Mientras el programa está en curso, se recomienda que

el periodo de vida útil sea de cinco años para tener el tiempo suficiente para calcular el TCO. En general,
los gastos que se incluyen son los costos de puesta en marcha y operación del programa, los salarios y
facilidades de trabajo para el equipo de AE, la documentación inicial, las actualizaciones periódicas a la
AE, el desarrollo del Plan de Gestión, soporte o compra de herramientas, y el desarrollo y mantenimiento
del repositorio. La estimación inicial de estos costos representa la “línea de base” para la financiación del
programas arquitectónico. El control del gasto durante el ciclo de vida debe ser monitoreado en contra
de esta línea de base para promover la gestión eficaz del programa. Si se producen cambios en el alcance
del programa, se debe también hacer el cambio correspondiente en la línea de base de financiación.
6.1.5. Establecimiento de Medidas de Desempeño del Programa
Esta sección documenta cómo se medirá la eficacia y eficiencia del programa. Como se ha descrito en
los capítulos anteriores, existen dos tipos de medidas: resultados y productos. Las medidas de resultado
identifican los avances logrados en establecimiento de un nuevo estado final, tales como: la mejor
integración de los componentes arquitectónicos, incrementar de la satisfacción del usuario final de
aplicaciones, o lograr la mayor eficacia en la toma de decisiones en la inversión de recursos de TI. Las
medidas de salida proporcionan datos sobre las actividades y cosas, como el número de bases de datos
existentes, cuántos e-mail se envían cada día, o como un proyecto de TI está cumpliendo con la línea base
relacionada con costo / horario / rendimiento. Las medidas de resultado a menudo tienen elementos
tanto cuantitativos como cualitativos, mientras que las medidas de salida suelen ser de naturaleza
cuantitativa. Si bien las medidas de salida son importantes para indicar el progreso de un área, es el
logro de los resultados que se correlacionan con la consecución de objetivos, lo más importante para
una empresa. Es importante ser capaz de medir el logro de los resultados, por lo que los efectos positivos
(valor agregado) del programa pueden ser identificados. A continuación se proporcionan ejemplos de
los resultados y de las medidas de salida del programa.
Reducir el promedio de costos en la planificación de proyectos de TI dentro

Medida Resultado # 1:
de un año
Medida Salida # 1-1: Número de proyectos de TI previsto un año.
Medida Salida # 1-2: Costo promedio de planificación de proyectos de IT antes de tres años.
Cantidad promedia de cambios en el alcance del proyecto antes de tres
Medida Salida # 1-3:
años.
Medida Salida # 1-4: Coste medio de planificación de proyectos de TI.
Medida Salida # 1-5: Promedio anual de cambios en el alcance del proyecto.
6.2. Resumen de la arquitectura actual
Uno de los objetivos del Plan de Gestión es mostrar una visión general de la relación entre los
componentes arquitectónicos actuales y de los productos en cada nivel del Marco. De esta manera, el
papel actual de las TI dentro de la empresa se comprenderá mejor y se puede analizar desde cualquier
perspectiva, de arriba hacia abajo, o de abajo hacia arriba. El objetivo de esta parte del Plan no es duplicar
la extensa documentación descrita en las unidades 4 y 5, pero si ofrecer una visión integrada de cómo los
componentes y artefactos trabajan en apoyo de unos a otros.
6.2.1. Objetivos e iniciativas estratégicas
Esta sección identifica cómo el programa y los componentes arquitectónicos específicos apoyan
la consecución de los objetivos e iniciativas estratégicas de la empresa. Esta sección se basa en las

observaciones formuladas en el Plan Estratégico, y se incluye para mostrar más claramente qué
componentes iniciativas estratégicas están involucradas en cada meta por área. Una descripción general
de cómo los componentes de TI soportan cada objetivo iniciativa a nivel Marco arquitectónico se ofrece
a continuación, La Figura 9-4 le proporciona un formato ejemplo para un artefacto que mapea los
componentes arquitectónicos contra las metas e iniciativas estratégicas.
Tabla 6. : Asignación de componentes Metas / Iniciativas Estratégicas
Nuevo sitio web de servicios; Base

Nuevo sitio web de Servicio al
de Datos de Servicios, Partes y
Cliente
Ser el #1 en Servicio a productos Productos, PC’s y Laptops y Ventas
Actualización de la Base de Datos Bases de Datos de: Servicios,
de Servicios clientes y Ventas.
Controladores Robóticos,
Nuevas características de
Incrementar Seguridad Cronograma de Producción, Base
seguridad en la Línea de Montaje
de Datos de Seguridad.
6.2.2. Servicios empresariales y flujos de información
En esta sección se identifique y enfatice el rol de soporte que juega la AE en el análisis y la mejora de
procesos de negocio, así como la identificación y optimización de los flujos de información dentro y
entre estos procesos. También reafirma el principio de que los componentes arquitectónicos son un
medio para habilitar servicios empresariales eficaces, y que no debe ser adquirido a menos que haya un
fuerte caso de negocio que apoye la inversión. Dentro de este apartado, deben figurar las principales
LOB de la empresa, junto con los servicios clave del negocio y los flujos de información asociados en
cada LOB. Una descripción general de cómo los componentes de TI apoyan a cada proceso de negocio
clave en el nivel de los servicios de negocios del marco arquitectónico se ofrece a continuación
Diagramas detallados de flujos de información y de estructura de datos son también utilizados por
varios tipos de artefactos que pueblan el nivel de Flujo de Información de del marco arquitectónico (por
ejemplo, Diagramas Entidad Relación, diagramas de flujo de datos y diagramas orientados a objetos).
Como se muestra en la Figura 6.2 un formato de tabla puede ser eficaz en la creación de un artefacto que
mapee las relaciones entre las LOB, los servicios clave de negocios, flujos de información y el apoyo a los
Componentes
Línea de Negocio Procesos Clave Flujos de Información Arquitectónicos de
Soporte
Controladores robóticos,
Comercialización y
cronograma de
Marketing ventas diarias datos
aplicaciones, base datos
ingresados al Data Mart.
de inventarios
Recepción y
Portal de proveedores,
procesamiento de
Facturación Base de Datos de
Ventas pedidos de los clientes.
Inventario de partes.
Facturación a clientes
Base de Datos para
Registro y pago de
seguimiento de la fuerza
comisiones de ventas, en
Comisiones de ventas. Módulo ERP
conjunto con la base de
para rol de pagos y Base
pago de sueldos.
de Datos

Componentes
Línea de Negocio Procesos Clave Flujos de Información Arquitectónicos de
Soporte
Sitio Web de Ventas;
Seguimiento de
Bases de Datos de
manufactura de
Producción Ventas & Inventario,
productos y niveles de
Laptops, Extranets de
inventario
Acceso Remoto
Recepción y
procesamiento de Base de Datos de
Manufactura Proveedor de partes
pedidos de los clientes. Clientes y ventas
Facturación a clientes
Base de Datos para
Registro y pago de
seguimiento de la fuerza
comisiones de ventas, en
Comisiones de ventas. Módulo ERP
conjunto con la base de
para rol de pagos y Base
pago de sueldos.
de Datos.
Datos del registro de
horas trabajadas, salarios
e información de pagos Módulos ERP y Base de
Rol de Pagos
mensual y resúmenes Datos para Rol de Pagos.
Mensual/Trimestral/
Anual
Gestión Integrada de
datos para Contabilidad Módulo ERP de
General, Fondos de contabilidad, Base de
Contabilidad
Capital de Trabajo, Datos de Clientes, Base
Cuentas por Pagar, de Datos de Ventas.
Administración Cuentas por Cobrar.
Participación de
beneficios por parte de
Módulo ERP de Recursos
Recursos Humanos los empleados e
Humanos y beneficios.
información de
reclamos.
Transmisión y archivo de
Procesador de textos,
correos, documentación
Automatización de hojas de cálculo,
y gestión de archivos,
oficinas creación de páginas web
impresiones, copias y
y presentación.
transmisión de faxes.
Figura 6.2: Asignación de Componentes Arquitectónicos, Líneas de negocio y flujos de información” tomado de: Scott A.
Bernard 2012
6.2.3. Sistemas y aplicaciones
Esta sección identifique cómo los actuales componentes y artefactos arquitectónicos del nivel sistemas
y aplicaciones apoyan los flujos de información que se requieren para las LOB en toda la empresa. La
discusión debe resumir si el desarrollo de sistemas de TI y servicios de front/back office proporcionan
la funcionalidad que la empresa necesita para las operaciones y automatización de oficinas de cada
LOB. Esto puede variar desde soluciones a gran escala, a aplicaciones comerciales y bases de datos, o a
desarrollados de sitios web personalizados. Los comentarios deben centrarse en el grado de integración,
escalabilidad potencial, la satisfacción del usuario, y la confianza en las soluciones propietarias.

6.2.4. Infraestructura tecnológica
En esta sección se analiza los componentes arquitectónicos de voz, datos y video así como los artefactos
que conforman el nivel de infraestructura de tecnología del marco arquitectónico. La discusión debe
centrarse en lo bien que estas redes internas y externas, sistemas y plantas de cableado se integran
para crear una infraestructura “sin fisuras”. Comentar también en como la actual infraestructura maneja
el transporte de voz, datos, video e información móvil, en términos de fiabilidad, escalabilidad y
rentabilidad.
6.2.5. Seguridad de TI
En esta sección se analiza el enfoque general de seguridad de TI en todos los niveles del marco AE. La
seguridad de TI debe ser parte de cualquier objetivo e iniciativa estratégica que depende de la precisión,
y de la información debidamente autenticada. Se proporcionan descripciones de alto nivel sobre cómo
la seguridad es construida dentro de los servicios empresariales y el control de los flujos de información,
así como el diseño y operación de sistemas, servicios y redes. La Información específica de seguridad,
no debe formar parte del Plan de Gestión, ya que podría revelar los puntos vulnerables. Este tipo de
información se debe documentar en un plan separado de Seguridad de TI que sólo ciertas personas en
la empresa tienen acceso.
6.2.6. Normas Arquitectónicas
La sección de normas documenta el Modelo de Referencia de Normas Técnicas (TSRM - Technical

Standards Reference Model), que establece las normas arquitectónicas para voz, datos, video y seguridad
informática que se utilizarán durante el desarrollo del componente arquitectónico. El TSRM también
puede proporcionar una lista de vendedores y productos preferidos cumplan con las normas técnicas
que la empresa adopte. Las Normas arquitectónicas son un elemento clave del proceso de gestión de la
configuración (CM) y provienen de internacional, nacional, local, gobierno, industria y empresariales. Las
Normas seleccionadas deben incluir estándares para tecnologías de voz, datos y vídeo de los principales
organismos de normalización de todo el mundo, incluyendo el Instituto de Ingenieros Eléctricos
y Electrónicos (IEEE), el Instituto Nacional de Ciencia y Tecnología (NIST), la Empresa Internacional
de Normalización (ISO), el Comité Europeo de Normalización (CEN) y los modelos de referencia de
Arquitectura Empresarial Federal.
Un ejemplo del formato para un TSRM se proporciona en la Figura 9-6.
Estándares Estándares
ISO/CEN IEEE NIST Productos
Áreas Locales
VOZ
VIDEO
DATOS
SEGURIDAD
Figura 6.3: Ejemplo de Normas Técnicas Modelo de Referencia ” tomado de: Scott A. Bernard 2012
Los siguientes son ejemplos de normas internacionales para Arquitectura Empresarial:
• ISO 14258 (1998): Conceptos y Normas para Modelos de empresa.

• ISO 15704 (2000): Requisitos de referencias para arquitecturas y metodologías empresariales.

Metodologías.
• CEN ENV 40003 (1991): Marco arquitectónico de modelado sistemas.

• CEN ENV 12204 (1996): Las construcciones de modelado Enterprise.
6.2.7. Requerimientos de mano de obra cualificada
En esta sección se describe el enfoque para la planificación y formación de la fuerza laboral de TI que la
empresa utiliza en la gestión del capital humano. Las personas a menudo son el recurso más valioso de
una empresa tiene, y los planes de la fuerza laboral de TI deben detallar los requisitos de capacitación
para el soporte a las operaciones de componente arquitectónicos y nuevos proyectos de desarrollo en
todos los niveles de la estructura.
6.3. Resumen de la Arquitectura Futura
6.3.1. Escenarios Futuros de funcionamiento
En esta sección, los escenarios futuros de operación se presentan junto con una descripción narrativa
de sus efectos y el espectro del ambiente operativo a los que responden dichos escenarios. Por ejemplo,
tome en consideración los tres escenarios siguientes que se presentan de una manera narrativa que
explica lo que ellos representan:
• Escenario 1: Mantener el statu quo.

• Escenario 2: Una estrategia comercial agresiva en un ambiente de buen mercado.
• Escenario 3: Una estrategia comercial defensiva durante un mercado a la baja.
Cada escenario tiene supuestos de planificación en los que se destacan los cambios que tendrán que
producirse en los procesos, personas y tecnología. Por último, en esta sección, se proporciona una
descripción del curso de acción seleccionado para la empresa (por ejemplo, el Escenario Futuro que se
llevará a cabo debido a que un buen ambiente de negocios se prevé para los próximos años).
6.3.2. Supuestos de planificación
Los supuestos de planificación mediante escenarios se discuten en términos de lo que significan en

base a las prioridades de la empresa para la implementación de la arquitectura futura. Estos supuestos
identifican nuevas capacidades y los recursos que serán necesarios para que la empresa tenga éxito en
cada escenario. Esta sección se centra en el escenario seleccionado y las hipótesis de planificación que
subyacen a ese curso de acción.
Continuando con el ejemplo anterior, si el escenario futuro 2 se persigue, a continuación, puede ser
necesario construir una nueva capacidad de producción con el apoyo de varios sistemas de comercio
electrónico. Los supuestos de planificación que fueron identificados en el Escenario Futuro 2 se convierten
en las guías para las decisiones acerca de cómo cambiar la arquitectura actual, y que necesitan ser
descritas.
6.3.3. Actualización de las vistas arquitectónicas actuales y futuras
La documentación de los cambios planificados en los procesos y los recursos es lo que crea las vistas
arquitectónicas futuras en todos los niveles de la estructura. Utilizando el marco EA3 como ejemplo,
estos cambios deberá llevarlos a cabo de forma “Top-Down”, para preservar el énfasis en la estrategia de

negocios, y para mantener la lógica de las relaciones de la documentación. Por lo tanto, estos cambios
comenzarían con los objetivos e iniciativas estratégicas de la empresa.
Los cambios en el plan estratégico de la empresa realícelos periódicamente o en respuesta a un

nuevo conductor tecnológico de negocio interno o externo. La mayoría de los planes estratégicos
están destinados a durar varios años, conjuntamente los objetivos e iniciativas asociadas, y medidas
que cambian de muy poco. Los cambios en este nivel del marco pueden ser mínimos si existe tiempo
para actualizar el plan estratégico. Los objetivos, iniciativas y medidas deben ser considerados como
componentes arquitectónicos intercambiables. Esto significa que una meta o medida se pueden agregar,
retirar o modificar sin anular la totalidad del plan estratégico.
Se utiliza un enfoque similar para revisar y actualizar los servicios de negocio de la empresa en el segundo
nivel del Marco. Es importante asegurar que la visión actual de los servicios de negocio está completa y
poder mostrar cómo estos apoyan la consecución de los objetivos estratégicos actuales. Los cambios en
los servicios de negocios se pueden hacer teniendo en cuenta los cambios en los objetivos e iniciativas
estratégicas, y las medidas que pueden ser planificadas y documentadas en el nivel superior del marco
Cube EA3. Además, la documentación en el nivel de Proceso de Negocios del Marco debe mostrar la
planificación futura de los procesos más eficaces y rentables, y técnicamente integrados.
En el tercer nivel del marco arquitectónico, el desarrollo de la vista futura le permitirá realizar una
planificación proactiva para mejorar el intercambio de información dentro de la empresa y promover
el establecimiento de normas para entidades/objetos de datos de uso común que promuevan la
interoperabilidad del componente. La planificación en este nivel del marco arquitectónico considera
en primer lugar las necesidades relacionadas con la información del nivel de servicios de negocio. Una
vez que estos se identifican, los flujos de información transversales entre los procesos, así como las
corrientes dentro de los procesos individuales se documentan usando cualquier metodología se ha haya
seleccionado para el uso del Marco(tanto los métodos estructurados tradicionales o métodos orientados
a objetos).
Documentar los cambios en el flujo de información dentro y entre los servicios de negocio (y los nuevos
estándares de datos) permitirá a los planificadores seleccionar los componentes arquitectónicos del marco
que mejor soporten los flujos de información y estándares de datos. Un punto central de la discusión
en esta sección es identificar las brechas de rendimiento actuales que existen en los niveles superiores
del Marco EA3 y asignarlos a los componentes y productos arquitectónicos actuales. La visión de futuro
del nivel de Sistemas / Servicios del marco EA3 debe mostrar que componentes arquitectónicos se van a
cambiar y en qué plazo de tiempo (véase el Plan de secuenciación). Los componentes arquitectónicos en
el cuarto nivel del marco deben ser incrementalmente seleccionados por su interoperabilidad, así como
por su rendimiento y escalabilidad.
En nivel de infraestructura de tecnología del marco, los cambios futuros reflejarán a los componentes
arquitectónicos (hardware y software) que proporcionarán una capacidad más robusta, fiable y segura y
de transportar voz, datos y video. La Interoperabilidad, la rentabilidad y estándares abiertos son factores
adicionales a considerar.
6.3.4. Plan de Secuenciación
La sección del Plan de Secuenciación del Plan de Gestión documenta las tareas, hitos y cronograma para
la aplicación de nuevos componentes y artefactos arquitectónicos. Las grandes y medianas empresas
tienen a menudo nuevos desarrollos, actualizaciones, bajas, o proyectos de migración en un momento
dado y estos requieren coordinación para establecer la secuencia óptima de actividades para su ejecución.
A veces hay dependencias entre los proyectos que también requieren una secuencia apropiada. Por
ejemplo, una mejora de la capacidad de la infraestructura de datos puede ser necesaria antes de que

sistemas adicionales y / o bases de datos se pueden alojar de manera efectiva para que el rendimiento
máximo se pueda alcanzar. Otro ejemplo común es la consolidación de los componentes arquitectónicos
(recursos de TI, tales como sistemas, aplicaciones y bases de datos) para mejorar el rendimiento y
la eficacia general de costos. La Figura 6.4 en la página siguiente es un ejemplo de un diagrama de
secuencia que muestra las actividades de consolidación de los componentes arquitectónicos.
Figura 6.4: Ejemplo de Diagrama de Secuencia basado en AE tomado de: Scott A. Bernard 2012
6.3.5. Gestión de la Configuración Arquitectónica
La sección de Gestión de la Configuración (CM) del Plan de Gestión sirve de apoyo a los sub-procesos por
cuales se gestionan los cambios y se aplican las normas TSRM. Los cambios incluyen agregar, actualizar, o
la baja de los componentes o artefactos arquitectónicos.CM garantiza que (1) un proceso estandarizado
se utilice en la revisión de los cambios propuestos, (2) las normas técnicas para voz, datos y vídeo que
se siguen o se dejan sin efecto, (3) hay un proceso de exención documentado, (4) la exención tiene
un tiempo límite específico, (5) existe la aplicación para el control de versiones en la documentación
arquitectónica. El proceso de CM debe ser supervisado por el arquitecto en jefe, y con el apoyo del
grupo de trabajo de AE que incluye a las partes interesadas de toda la empresa. El proceso de CM trabaja
a través de la presentación de una forma para la revisión y aprobación / rechazo de una solicitud de
cambio arquitectónico (EACR) o por cualquier parte interesada, como se muestra en la Figura 6.5 en la
página siguiente.

Figura 6.5: Ejemplo de Formulario de Solicitud de Cambio de AE tomado de: Scott A. Bernard 2012
6.4. Glosario y Referencias
Esta parte del Plan de Gestión es donde se ofrece un glosario de términos arquitectónicos junto con una
lista de acrónimos. También debe haber una lista bibliográfica de libros de referencia y artículos que
pudieran proporcionar antecedentes adicionales o que ayuden a la comprensión del lector del Plan de
Gestión de AE. Debido a que la AE es todavía un área emergente de la práctica profesional, la Lista de
Acrónimos y Glosario son útiles en la creación de un conjunto común de términos y definiciones para su
uso en toda la empresa.
En esta unidad se proporciona una descripción de la finalidad, formato y contenido de un Plan de

Gestión arquitectónica. Este Plan describe el proceso de gestión arquitectónica, la metodología de
implementación y el marco de documentación, así como los resúmenes de las vistas arquitectónicas
actuales y futuras. Se trata de un documento vivo que se actualiza de forma regular para proporcionar
un control de versión clara de los cambios en la vista actual y futura de los componentes y artefactos
arquitectónicos en cada nivel de la estructura. El Plan de Gestión debe ser archivado en el repositorio
para apoyar el fácil acceso a la información y promover la vinculación del programa a otros procesos de
gestión de TI.

Autoevaluación 6

alguna inquietud no dude en contactar con su profesor tutor.
1. El plan de gestión documenta:
a. Las brechas de desempeño, la necesidad de recursos, las soluciones planeadas, el plan de

secuenciación, y un resumen de la arquitectura actual y futura
b. El estado de las vistas arquitectónicas actuales y futuras y sus necesidades.
c. Promueve enfoques probados y estandarizados para la implementación o actualización de
los recursos de TI.
2. El objetivo del plan de gestión arquitectónica es :
a. Documenta la forma en que las políticas y el proceso de toma de decisiones se producirán

dentro del programa.
b. Apoyar y mejorar la planificación estratégica y de negocios de la empresa, así como
identificar las brechas de desempeño que los componentes de arquitectónicos pueden
ayudar a cerrar.
c. La mejor forma de mostrar los cambios esperados en los estándares de seguridad, planes,
pruebas y certificación de cada sistema de TI.
3. Se consideran medidas de resultado:
a. El número de bases de datos existentes, cuántos e-mail se envían cada día, o como
un proyecto de TI está cumpliendo con la línea base relacionada con costo / horario /
rendimiento
b. La mejor integración de los componentes arquitectónicos, el incremento de la satisfacción
del usuario final de aplicaciones, o lograr la mayor eficacia en la toma de decisiones en la
inversión de recursos de TI. La organización de un proyecto en general debe corresponder
con los siguientes grupos de procesos:
c. Los indicadores de gestión arquitectónica.

4. La seguridad de TI:
a. Se debe documentar en un plan separado de Seguridad de TI que sólo ciertas personas en

la empresa tienen acceso.
b. Se debe documentar dentro del plan de gestión arquitectónica.
c. Se debe documentar tanto en el plan de gestión arquitectónica con en el plan de Seguridad
de TI.
5. Dentro del plan de gestión arquitectónica los escenarios futuros de funcionamiento describen:
a. El modelo de datos.
b. Los cambios que tendrán que producirse en los objetivos e iniciativas estratégicas.
c. Los cambios que tendrán que producirse en los procesos, personas y tecnología.
6. El plan de secuenciación:
a. Evita que el programa tenga menos funcionalidades de las esperadas.

b. Documenta las tareas, hitos y cronograma para la aplicación de nuevos componentes y
artefactos.
c. Permite al arquitecto en jefe controlar el alcance, costo, tiempo y calidad de acuerdo a una
línea base establecida.
7. El proceso que sirve de apoyo a los sub-procesos por cuales se gestionan los cambios y se aplican
las normas TSRM se denomina:
a. Plan de Gestión del cambio.

b. Requerimientos de cambio.
c. Plan de Gestión de la Configuración.
8. La matriz de interfaces del sistema:
a. Es un componente
b. Un artefacto.
c. Un modelo.
9. La matriz CRUD en la vista arquitectónica de futuro:
a. Identifica cambios potenciales en la propiedad de los datos.

b. Proporciona una taxonomía y formatos estándar para las entidades de datos que se utilizan
en los diversos sistemas empresariales de TI.
c. Describe como se crean los objetos de datos.
10. En el nivel de infraestructura tecnológica del marco arquitectónico se documentan componentes

tales como:
a. Redes de voz, datos y vídeo.

b. Diagrama de conectividad de red.
c. Aplicaciones de software, Servicios Web, Bus de Servicios y Middleware.

Texto-guía: Gestión de Tecnologías de Información SOLUCIONARIO
7. Solucionario
PRIMER BIMESTRE
Autoevaluación 1
Pregunta Respuesta
1. a
2. c
3. b
4. a
5. c
6. b
7. c
8. a
9. c
10. c

Autoevaluación 2
Pregunta Respuesta
1. b
2. a
3. b
4. a
5. c
6. a
7. b
8. c
9. a
10. a

Autoevaluación 3
Pregunta Respuesta
1. a
2. b
3. c
4. a
5. a
6. b
7. a
8. c
9. b
10. a

SEGUNDO BIMESTRE
Autoevaluación 4
Pregunta Respuesta
1. b
2. c
3. b
4. c
5. b
6. a
7. c
8. a
9. b
10. a

Autoevaluación 5
Pregunta Respuesta
1. b
2. a
3. c
4. a
5. b
6. c
7. b

Autoevaluación 6
Pregunta Respuesta
1. a
2. b
3. b
4. a
5. c
6. b
7. c
8. b
9. a
10. a

Texto-guía: Gestión de Tecnologías de Información ANEXOS
8. Anexos
DICTIONARY
TH ESA UR US
El presente material ha sido reproducido con fines netamente didácticos,

cuyo objetivo es brindar al estudiante mayores elementos de juicio para la
comprensión de la materia, por lo tanto no tiene fin comercial.
Glosario de Términos.
Enfoque sistemático que organiza y orienta el diseño, el análisis, la planificación

Arquitectura.
y las actividades de documentación.
El análisis y la documentación de una empresa en su estado actual y futuro de
Arquitectura Empresarial.
una estrategia integrada, el negocio y la perspectiva tecnológica.
Una parte de la AE en general que los documentos de una o varias líneas de
Arquitectura segmentada.
negocio, incluyendo todos los niveles e hilos.
Un artefacto AE es un producto de documentación, como un documento de
Artefacto.
texto, diagramas, hojas de cálculo, diapositivas informativas o un clip de video.
Una colección de información descriptiva y analítica sobre la inversión en
Business Case.
recursos (s) y / o capacidades.
El conocimiento consiste en datos o informaciones que se han organizado y se
procesa para transmitir conocimiento, la experiencia, el aprendizaje acumulado
y la experiencia en su aplicación a un problema actual o actividad. Los datos
Conocimiento.
que se procesan para extraer implicaciones críticas y reflejan la experiencia
pasada y experiencia facilitarán al destinatario, con conocimiento de la
organización, que tiene un valor potencial muy alto.
Componentes de AE son aquellos recursos plug-and-play que proporcionan
capacidades en cada nivel de la estructura. Algunos ejemplos son los objetivos
Componente Arquitectónico. estratégicos, medidas, servicios empresariales; flujos de información y objetos
de datos, sistemas de información, servicios web y aplicaciones de software,
redes de voz, datos, vídeo y plantas asociadas de cable.
Componente de la AE que sirve varias líneas de negocio. Los ejemplos incluyen
Componente Transversal. sistemas de correo electrónico que sirven a toda la empresa y los sistemas
financieros que sirvan varias líneas de negocio.
Las creencias, costumbres, valores, estructura, reglas normativas, y los rasgos
Cultura. materiales de una organización social. La cultura es evidente en muchos
aspectos de cómo funciona una organización.
Los elementos de datos se refieren a una descripción elemental de las cosas,
eventos, actividades y transacciones que se registran, clasifican y almacenan,
pero no está organizado para transmitir un significado concreto. Los elementos
Datos.
de datos pueden ser alfabéticas numéricos, figuras, sonidos o imágenes. Una
base de datos se compone de elementos de datos almacenados organizados
para su recuperación.
El proceso de establecimiento de expectativas y la participación de los
interesados en la forma de un proceso o actividad será cambiado, de modo que
Gestión del Cambio.
las partes interesadas tienen un cierto control sobre el cambio y por lo tanto
pueden ser más receptivos a los cambios.
Un conjunto de políticas, procedimientos de toma de decisiones y los procesos
Gobernabilidad. de gestión que trabajan en conjunto para permitir la planificación y supervisión
de las actividades y recursos.
Todo el que esté o vaya a verse afectado por un programa, actividad o recurso.
Grupo de Interés. Los interesados en el programa de AE incluyen patrocinadores, arquitectos,
administradores de programas, los usuarios y personal de apoyo.

La información son datos que se han organizado de manera que tengan

Información. significado y valor para el receptor. El receptor interpreta el significado y saca
conclusiones e implicaciones.
El proceso de gestión y toma de decisiones relacionadas con la planificación,
selección, control y evaluación de las inversiones en recursos, incluidos los
Planificación del Capital. componentes de AE, como los sistemas, redes, depósitos de conocimiento y
servicios de apoyo para la empresa.
El ejecutivo que tiene autoridad para tomar decisiones sobre el programa de AE

Patrocinador Ejecutivo.
y que proporciona recursos y las cúpulas directivas para el programa.
Un esfuerzo continuo que gestiona los procesos existentes, recursos, o supervisa
Programa.
el desarrollo de nuevos procesos o recursos a través de proyectos.
El marco de AE es una estructura para organizar la información que define el
Marco. ámbito de la arquitectura - lo que el programa de AE documentará y la relación
de los distintos ámbitos de la arquitectura.
La metodología de AE define como documentación de la AE se desarrollará,
Metodología. archivar y utilizar, incluyendo la selección de un marco, las herramientas de
modelado, y el repositorio on-line.
Misión. Una descripción breve de por qué existe la empresa.
Un esfuerzo temporal emprendido para crear un producto único, servicio o
Proyecto.
resultado.
Tipo de recurso que apoya la creación, análisis, compartir, archivar datos e
Tecnología de la Información.
información de una empresa.

Artefacto
Nivel Nombre del Artefacto
ID #
S-1 Plan estratégico
S-2 Análisis FODA
Metas e Iniciativas Estratégicas S-3 Concepto del Escenario de Operaciones
S-4 Concepto del Diagrama de Operaciones
S-5 Balanced Scorecard
B-1 Plan de Negocios
B-2 Diagrama de Conectividad de Nodos
B-3 Diagrama de Procesos
Servicios y Productos del
B-4 Procesos de Negocio/Modelo de Servicios
Negocio
B-5 Procesos de Negocio/Matriz de Servicios
B-6
B-7 Caso de Negocio de Inversiones
D-1 Plan de Gestión del Conocimiento
D-2 Matriz de Intercambio de Información
D-3 Diagrama de Transición de Objetos
D-4 Diagrama de Secuencia de Objetos
Datos e Información
D-5 Modelo Lógico de Datos
D-6 Modelo Físico de Datos
D-7 Matriz Actividad/Entidad CRUD
D-8 Diccionario de Datos / Biblioteca de Objetos
SA-1 Diagrama de Interfaz de Sistemas
SA -2 Descripción de la comunicación de sistemas
SA -3 Matriz de Interfaces de Sistemas
SA -4 Diagrama de flujo de datos del sistema
Sistemas y Aplicaciones SA -5 Matriz de sistemas/operaciones
SA -6 Matriz de intercambio de datos del sistema
SA -7 Matriz de rendimiento del sistema
SA -8 Diagrama de Evolución del Sistema
SA -9 Diagrama de Aplicaciones Web
NI-1 Diagrama de Conectividad de Redes
NI -2 Inventario de redes
NI -3 Inventario de Equipos
Redes & Infraestructura NI -4 Plano de Construcción
NI -5 Diagrama Central de Redes
NI -6 Diagrama Planta de Cableado
NI -7 Diagrama de Distribución de Racks
SP-1 Plan de Seguridad y Privacidad
SP-2 Descripción de soluciones de seguridad
Seguridad SP-3 Documento de acreditación de sistemas
SP-4 Plan de Continuidad de Operaciones
SP-5 Procedimientos para recuperación de desastres

Artefacto
Nivel Nombre del Artefacto
ID #
ST-1 Perfil técnico de normas
Normas
ST-2 Prospectiva Tecnológica
W-1 Plan de la fuerza de trabajo
Habilidades del Personal W-2 Organigrama
W-3 Perfil de conocimiento y habilidades.

Área Arquitectónico Artefacto
S-1: Plan Estratégico

El plan estratégico es un documento de políticas y planificación de
alto nivel que una empresa utiliza para documentar su dirección,
estrategia competitiva, metas más importantes y los programas y
proyectos habilitantes (iniciativas estratégicas). El plan estratégico
usualmente cubre un periodo de 3-5 años.
Un Plan Estratégico es un artefacto arquitectónico compuesto que debe guiar la dirección de la empresa durante
un período de 3-5 años en el futuro, proporcionando los siguientes elementos, cada uno de los cuales son
artefactos arquitectónicos primitivos. Las versiones completas de los artefactos primitivos abreviados son
objetos separados.
• Proporcionar una declaración de la misión y la visión que capta sucintamente propósito y dirección de la
empresa.
• Desarrollar una declaración de la dirección estratégica que se ajuste al propósito de la empresa, que asegure
la supervivencia, permita la flexibilidad y promueva su éxito competitivo. Esta declaración es una descripción
detallada del lugar donde la empresa tiene la intención de ir.
• Resumir los resultados de un análisis FODA que se basa en la declaración de la dirección estratégica en la que
se identifican las fortalezas, debilidades, oportunidades, y amenazas de la empresa. Ver artefacto S-2.
• Resumir la situación y supuestos de planificación de algunos CONOPS (Concepto de Escenarios de
Operaciones) que apoyan la dirección estratégica de la empresa. Este resumen debe incluir un escenario
actual que describe a un alto nivel de la coordinación de las actividades en curso en cada línea de negocio,
así como varios escenarios futura que representan diferentes combinaciones de factores internos y externos
identificados a través del análisis FODA. Ver artefacto S-3.
• Desarrollar un diagrama de concepto de operaciones que, en una sola imagen capture la esencia y los
participantes en el escenario de funcionamiento actual. Ver artefacto S-4.
• Desarrollar una Estrategia Competitiva General de la empresa que incorpore los escenarios CONOPS actuales
y futuros dirección estratégica de una manera que y abordar factores internos / externos, tales como la
cultura, línea de los requerimientos del negocio, condiciones de mercado, estrategias de la competencia y el
riesgo.
• Identificar metas estratégicas que permitirán el logro de la estrategia competitiva, y especifique a los
patrocinadores ejecutivos que son responsables del logro de cada objetivo.
• Identificar iniciativas estratégicas y a los patrocinadores de recursos para las iniciativas, que son los programas
en curso o proyectos de desarrollo que lograrán cada Objetivo Estratégico.
• Resuma las medidas de resultado para cada objetivo e iniciativa estratégica, con el Balanced Scorecard ™ o un
enfoque similar. Ver artefacto S-5.



Área Arquitectónico Artefacto FODA
S-2: Análisis
El análisis de Fortalezas. Debilidades, Oportunidades y

S-2: Análisis FODA
Amenazas, da una mirada holística de la empresa
Elidentificando
análisis de Fortalezas. Debilidades,
los factores internos yOportunidades
externos que ycuando
Amenazas,
son
da una mirada holística de la empresa identificando los factores
mapeados pueden revelar áreas de mejora.
internos y externos que cuando son mapeados pueden revelar
áreas de mejora.
Una de las primeras actividades que la empresa realiza para desarrollar un plan estratégico es el
análisis
Una de primeras
de las Fortalezas. Debilidades,
actividades que laOportunidades
empresa realiza y Amenazas. Esteun
para desarrollar análisis mira los factores
plan estratégico internos
es el análisis de
y externos para determinar qué áreas de la empresa deben enfocarse en incrementar su
Fortalezas. Debilidades, Oportunidades y Amenazas. Este análisis mira los factores internos y externos para supervivencia
y éxito, asíqué
determinar como
áreaslas
deáreas que la
la empresa empresa
deben debe
enfocarse enevitar o disminuir
incrementar su exposición.
su supervivencia Los
y éxito, así resultados del
como las áreas
que la empresa debe evitar o disminuir su exposición. Los resultados del análisis FODA se deben resumir en ela
análisis FODA se deben resumir en el plan estratégico a través de la matriz que se ilustra
continuación.
plan estratégicoEste análisis
a través de debe ser que
la matriz archivado en ael continuación.
se ilustra repositorio deEste
AE análisis
como un artefacto
debe primitivo
ser archivado enpor
el
separado (S-2). El siguiente es un ejemplo de la forma en que se resume un análisis FODA
repositorio de AE como un artefacto primitivo por separado (S-2). El siguiente es un ejemplo de la forma en que
se resume un análisis FODA
Factores Externos Fortalezas Internas (F) Debilidades Internas (D)

F1: Comunidad de usuarios D1: Políticas /Regulaciones
Factores Internos F2: Relaciones D2: Governanza
F3: Liderazgo D3: Habilidades Sistemas de TI
F4: Tecnología In_house D4: Arquitectura Empresarial
F5: Arquitectura Legada D5: Habilidades Sistemas de TI
F6: Presupuesto Capacitación D6: Baja Usabilidad/
F7: Cultura Implementación
Oportunidades Externas
01. Contratos
FO DO
02. Gobierno
F5/O3: Portales Web Legados D4/O3: Implementar AE
03. Nueva Tecnología
F1/O3: Seguridad
04. Asociaciones
Amenazas Externas
A1: Financiamiento
FA DA
A2. Conductores del Mercado
F1/A2: Obtención
A3. Avance de la Tecnología
requrimientos D4/A1: Financiamiento
A4. Ratios de adopción de TI
F6/A5: Entrenamiento en TI
F1/D5: Concientización
procesos de TI
El análisis FODA es también usado para ayudar a los arquitectos empresariales y planificadores estratégicos a
desarrollar los escenarios de Concepto de Operaciones (CONOPS) que detallen los ambientes operativos actuales
El análisis FODA es también usado para ayudar a los arquitectos empresariales y planificadores
y futuros.
estratégicos a desarrollar los escenarios de Concepto de Operaciones (CONOPS) que detallen los
ambientes operativos actuales y futuros.
167


S-3 Escenarios CONOPS

Un Concepto de escenarios de operaciones es un documento narrativo que
describe cómo opera actualmente la empresa u operará por algunos años en el
futuro dados ciertos factores internos y externos identificados en el análisis FODA.
El escenario es desarrollado con asunciones de planificación.
Ejemplo
Asunciones de Planificación Jeff Linder, Vicepresidente de Ventas Industriales en Danforth Manufacturing
Company (DMC) acababa de terminar una presentación en la Conferencia Nacional de
1. Capacidad de Video Seguridad Vial 2008 junto con Richard Danforth, CEO de DMC, Jeff salía de la sala
Teleconferencia principal de conferencias, cuando Andrea Newman, Director de Seguridad y
2. Exposición de Productos Transporte del Estado de Tennessee, le preguntó si podían hablar por unos minutos
en conferencias acerca de la nueva línea de las carreteras asistidas por energía solar que acababa de
Nacionales dar en una presentación.
3. Necesidad de mantener “Gracias por tomarse un minuto para hablar, Jeff.Quiero comentarle de una situación
discusiones detalladas que tenemos en Tennessee y ver si su nueva línea de productos nos puede ayudar “,
de los productos a corto dijo Andrea, “ No hay problema, gracias por preguntar “, dijo Jeff.Andrea sacó un
plazo, a nivel mundial. documento en su tableta y dijo: “Jeff, este es un informe que muestra un incremento
4. Disponibilidad de en el número de accidentes graves en las zonas rurales de Tennessee que involucran
trabajo 24x7 vehículos de pasajeros, equipo agrícola y camiones comerciales.Lo hemos atribuido al
crecimiento de las comunidades suburbanas más lejanas más aún en el campo, que
5. Incrementar las luego dependerán de caminos rurales de dos carriles para los desplazamientos hacia
comunicaciones en áreas la cuidad, entonces usted tendrá una receta para el desastre cuando por estas transiten
suburbanas. tractores y camiones lentos, junto con los coches que tienen prisa a todas horas para
6. Obtener informes para llegar a algún lugar, ““¿No es este problema que se observa en otros lugares del
anticipar las necesidades país?”preguntó Jeff.“Sí, y uno de los factores que contribuyen a la alta incidencia de
del producto. accidentes nocturnos es la falta de una buena iluminación en las carreteras. Pienso
que la iluminación solar para carreteras desarrollada por ustedes puede ayudarnos a
7. Los cambios
proporcionar más tiempo de visibilidad nocturna en las carreteras rurales de alto
demográficos de la riesgo sin tener que invertir en una infraestructura de apoyo eléctrico”.
población, impulsan el
desarrollo de nuevos Jeff pensó un momento antes de responder.“Usted sabe, la nueva línea de luces de
productos. carretera tiene opciones para incorporar cajas de llamada de emergencia 911 y
Sistema de Posicionamiento Global (GPS) que se puede conectar tanto a nivel estatal
8. Incremento de costes y
como local en primer lugar. Andrea asintió con la cabeza y dijo: “Sí, no creo que una
beneficios de la mejor iluminación va a resolver todo el problema, pero va a ayudar a la gente, y las
iluminación solar. otras opciones pueden mejorar los tiempos de respuesta de accidentes, que también
9. Incluir características salvan vidas.¿Cuál es el precio de estas unidades? “Jeff sacó su Asistente Personal Digital
adicionales al producto (PDA) I/O de su bolsillo y se conectó a la base de datos de comercialización y ventas de
para atraer clientes. DMC a través del satélite Internet link. Andrea, estas unidades cuestan 11.300 dólares
10. Uso global de PDA´s para cada uno, incluyendo el GPS y funciones 911.”Andrea tomó notas y respondió: “¿Si
comunicación entre puedo conseguir el permiso para llevar a cabo una prueba piloto en un par de meses
usted nos puede proporcionar las luces?”Jeff le preguntó “¿Cuántos kilómetros de
empleados.
carretera?”“Cerca de cuatro kilómetros en el área particular ‘dijo Andrea.“Ok, la
11. Integrar información de densidad sugiere para la nueva unidad es de 18 por milla, por lo que serían 72 unidades
ventas, marketing y totales.Te puedo dar un descuento del 10% por ser uno de los primeros compradores
producción. por lo que el total serían 732.240 dólares.Déjame ver el tiempo de envío.Jeff envió un
12. Citas con clientes e-mail de alta prioridad a Bob Green, Vicepresidente de Manufactura.Bob estaba en la
importantes sobre la fábrica cuando recibió el correo electrónico de Jeff y previa comprobación del Sistema
marcha. de Programación de producción DMC, respondió dos minutos después, indicando
que una orden especial por 72 unidades podría ser completada y enviada en 35 días
después que se recibe el pedido. Jim transmitió esta información a Andrea, quien dijo:
“Wow, eso fue rápido.Tengo toda la información que necesito para proponer el
proyecto piloto.Me pondré en contacto con usted en la próxima semana.Gracias.”

S-4: Diagrama de Concepto de Operaciones

Un diagrama de concepto de operaciones (CONOPS) es una representación
gráfica de alto nivel de cómo se ejecutan las funciones de la empresa ya sea en
general o en un área de interés en particular.
El siguiente diagrama CONOPS muestra como un sistema ficticio de alto nivel llamado “Sistema de Alertas para
Huracanes” llevaría a cabo su misión principal proporcionando supervigilancia controlada del tiempo con
capacidad de reporte basado en los recursos de la tierra, mar, aire y los recursos basados en el espacio.


Área Arquitectónico
Artefacto
S-5: Balanced Scorecard
S-5: Balanced Scorecard
El Balanced Scorecard va más allá de las mediciones
El Balanced Scorecard va más allá de las mediciones financieras de
financieras de éxito para una empresa y establecer las metas y
éxito para una empresa y establecer las metas y medidas en cuatro
medidas
áreas en Cliente,
claves: cuatro áreas claves:
Finanzas, Cliente,
Procesos deFinanzas,
negocio Procesos
Internos y
de negocioy Internos
Aprendizaje y Aprendizaje y Crecimiento.
Crecimiento.
Descripción
Descripción

El Balanced Scorecard sugiere que las
El Balanced Scorecard sugiere Financiero
personas deben ver a la empresa desde
"Para tener éxito
cuatro
que lasperspectivas
personas (no solover
deben desde
a lala financieramente, ¿cómo
perspectiva económica) y deben debemos presentarnos ante
empresa desde cuatro nuestros accionistas?"
desarrollar métricas, recolección de
datos y análisis de
perspectivas (nola empresa relativo
solo desde la a
cada una de estas perspectivas como se Clientes Procesos de Negocio Internos
perspectiva económica) y deben
muestra en la figura de la derecha.
"Para alcanzar nuestra visión, Visión "Para satisfacer a nuestros
desarrollar métricas, recolección ¿cómo debemos presentarnos accionistas&clientes qué
El Balanced Scorecard es un sistema ante nuestros clientes?"
y
´procesos de negocio deben
Estrategia
gestión
de datosy evaluación
y análisis quede lahabilita
empresaa la sobresalir?"
empresa a clarificar su visón y estrategia
relativo a cada una de estas
y a que esta sea puesta en acción. El
Scorecard
perspectivas provee
como retroalimentación
se muestra en
Aprendizaje y Crecimientro
alrededor tanto de los procesos de
la figura de la derecha.
negocio internos así como salidas "Para alcanzar nuestra visión,
¿cómo vamos a mantener
externas con la finalidad de mejorar nuestra capacidad de cambiar y
continuamente el rendimiento y los mejorar?"
El Balanced Scorecard es un
resultados estratégicos. Cuando se
despliega completamente,
sistema gestión el Balanced
y evaluación que
Scorecard transforma la planificación
habilita a la empresa a clarificar
estratégica desde un ejercicio académico
dentro
su visóndely centro neurálgico
estrategia y a quedeesta
una
empresa
sea puesta en acción. El
Scorecard provee
retroalimentación alrededor tanto
de los procesos de negocio
internos así como salidas externas
con la finalidad de mejorar
continuamente el rendimiento y los
resultados estratégicos. Cuando
se despliega completamente, el
Balanced Scorecard transforma la
planificación estratégica desde un
ejercicio académico dentro del
centro neurálgico de una empresa
170


B-1: Plan de Negocios

El plan de negocio provee una descripción de alto nivel de las
principales líneas y funciones de negocio y la estrategia financiera
que permitirá llevar a cabo las iniciativas y metas estratégicas.
Los siguientes ítems a menudo se encuentran en el plan de negocio:

1. Descripción el negocio
2. Perfil del equipo ejecutivo
3. Relación entre las Actividades del negocio y las metas estratégicas
4. Estructura organizacional
5. Perspectivas del mercado y estrategia competitiva
6. Ciclos de negocio
7. Resumen de capitalización
8. Estrategia financiera
9. Resumen del estado financiero actual
10. Asociaciones y alianzas de negocio

B-2: Diagrama de conectividad de nodos

El diagrama de conectividad de nodos indica los nodos
operacionales, actividades realizadas por cada nodo y el
intercambio de información. EL propósito de este diagrama es
mostrar en un alto nivel cuales son los grupos operativos en la
empresa (líneas de negocio) y como comparten información.

B-3: Diagramas de carril de procesos

Este diagrama muestra que stakeholders (aquellos con interés
personal en la empresa) están involucrados con los procesos de la
línea de negocios. El diagrama utiliza este formato para organizar a
las partes interesadas por columna, entonces se produce una
superposición de actividades con la simbología del diagrama de
flujo


B-4: Diagrama de procesos de negocio
Un diagrama de procesos de negocio muestra una estructura
detallada
B-4: de de
Diagrama unaprocesos
actividad, incluyendo cada en la actividad
de negocio
que se relaciona con otras. Este diagrama sigue la técnica
Un diagrama de procesos de negocio muestra una estructura
de modelado
detallada de unaIDEF-0 para
actividad, mostrar cada
incluyendo que en
entradas, controles,
la actividad que se
salidas y mecanismos son para cada paso en el proceso
relaciona con otras. Este diagrama sigue la técnica de modelado
IDEF-0 para mostrar que entradas, controles, salidas y mecanismos
son para cada paso en el proceso

Controles
Entradas Actividad Salidas

Mecanismos
Entradas.- Ítems que inician/disparan la actividad y son transformados, consumidos o forman parte de.
Controles.- Guían y regulan la actividad, usualmente indican cuando/cómo un proceso será realizado
Entradas: Ítems que inician/disparan la actividad y son transformados, consumidos o forman
Salidas.- parte
Los resultados
de. producidos por la actividad, la razón por la que un proceso es realizado.
Controles: Guían
Mecanismos.- Sistemas, personas,y regulan la actividad,
y equipamiento usualmente
usado para realizarindican cuando/cómo un proceso será
la actividad.
realizado
IDEF-0 esSalidas:
una actividad
Los de modeladoproducidos
resultados que es adecuada
por lapara documentar
actividad, procesos
la razón por dela negocio
que un en los que es
proceso se
provee vistas tanto de alto nivel como de contexto, y vistas más detalladas de cada paso de la actividad en un
realizado.
formato Mecanismos:
que puede ser Sistemas,
descompuesto e interrelacionado
personas, y equipamientoconusado
otros para
procesos conlalaactividad.
realizar finalidad de mostrar
interconexiones. Este tipo de diagrama es usado para mostrar conexiones entre los pasos y las influencias
internas/externas.
IDEF-0 es una actividad de modelado que es adecuada para documentar procesos de negocio
en los que se provee vistas tanto de alto nivel como de contexto, y vistas más detalladas de
cada paso de la actividad en un formato que puede ser descompuesto e interrelacionado con
otros procesos con la finalidad de mostrar interconexiones. Este tipo de diagrama es usado
para mostrar conexiones entre los pasos y las influencias internas/externas.
174


B-5: Matriz Actividad/Producto

La matriz Actividad & Producto mapea el ciclo de vida de los
productos que producen ingresos para las diferentes líneas de
negocio en toda la empresa. La matriz destaca a quien pertenecen
los procesos y productos de negocios, así como la extensión de las
cadenas de suministro.
La matriz Actividad/Producto mapea el ciclo de vida de los ingresos por producto que cada empresa
El ciclo de vida del producto ilustrado en este ejemplo tiene cinco pasos secuenciales (investigación y desarrollo,
manufactura, almacenamiento, ventas/distribución y servicios) y dos funciones administrativas paralelas
(financiera y legal). El ciclo de vida del producto es diferente dentro de algunas empresas, por lo que se pueden
hacer ajustes a la matriz B-5.

Área Arquitectónica Artefacto
B-6: Diagramas & Casos Uso

La narración de casos de uso sigue el formato del Lenguaje de
Modelado Unificado (UML) para identificar los requerimientos el
negocio, su contexto, stakeholders (actores), y reglas de negocio
para su interacción con sistemas y aplicaciones que son
identificadas con soluciones tecnológicas que requieren desarrollo.
Ejemplo

B-7: Caso de Negocio de Inversiones

Un caso de negocio de inversiones utiliza un formato estándar que
describe el valor, riesgo y el retorno de inversión realizado en
tecnología y otros recursos. El caso de negocio también contiene
un análisis de alternativas, programa de seguimiento de métricas,
información arquitectónica e información de seguridad.
Ejemplo
1. Nuevo Requerimiento. Un nuevo requerimiento de recursos o soporte es identificado para una línea de
negocios (LOB), los mismos son puesto en consideración de los equipos de AE y Planificación de Capital
para evaluación.
2. Validar soluciones existentes: Los equipos de AE y de Planificación de Capital determinan que un
componente arquitectónico no cumple con los requerimientos.
3. Caso de negocio para nuevas soluciones
a. Necesidad del negocio: describe el requerimiento en términos del análisis GAP en el rendimiento
operativo o administrativo que representa a cada LOB dentro de la empresa
b. Impacto si no es resuelto: Describe el impacto en la empresa si el GAP en el rendimiento no es resuelto,
incluyendo el impacto estratégico, de negocio y de tecnología
c. Análisis de alternativas: Identificar tres o más alternativas de soluciones viables.
d. Análisis Costo beneficio: Cuantificar los costos directos e indirectos y los beneficios cada alternativa
sobre la base del ciclo de vid, incluidos los elementos cualitativos.
e. Retorno de Inversión: Hacer el cálculo del ROI por cada alternativa seleccionada.
f. Ajuste del Valor Presente Neto: Hacer ajustes al NPV por cada calculo ROI tener en cuenta los aumentos
de costos anticipados durante todo el ciclo de vida de la inversión
4. Evaluación del caso de negocio. Las alternativas para el caso de negocio son evaluadas por el Grupo de
Trabajo Arquitectónico (AWG-Architecture Working Group) para asegurar la exactitud del análisis, y el
alineamiento con cada nivel del marco arquitectónico. El Grupo de Trabajo de Planificación de Capital
(CPWG) entonces revisa el caso de negocio asegurar la exactitud del análisis financiero. Una recomendación
coordinada es realizada por el Board de Planificación de Capital (CPN – Capital Planning Board) en cuanto a
si el caso de negocio debe ser aprobado o rechazado
5. Aprobación del caso de negocio. EL CPB revisa y aprueba/desaprueba el caso de negocio en el contexto
del portafolio general de inversiones de la empresa usando criterios para identificar el valor desde un
perspectiva estratégica, de negocios y de tecnológica.
6. Implementación. Si el caso de negocio es seleccionado (aprobado) por el CPB, la solución propuesta se
transforma en un proyecto de implementación que es gestionado por la línea de negocio que hace de
sponsor.

D-1: Plan de Gestión del Conocimiento

El Plan de Gestión de Conocimiento (KMP) provee una descripción
detallada de como el conocimiento, información, y datos son
compartidos a través de la empresa. El plan incluye descripciones y
diagramas de información compartidos entre sistemas,
aplicaciones, almacenes de conocimiento y bases de datos.
Ejemplo
Plan de Contenidos
• El enfoque de gestionar datos, información y conocimiento a través de la empresa.
• Como los datos y el intercambio de información apoyan al Plan de Negocio
• Los datos y las estrategias de intercambio de información para cada línea de negocio
• Los datos y las estrategias de intercambio de información con asociados externos y clientes.
• Que tipos de datos en la empresa requieren extra-protección
• El ciclo de vida de los datos e información que es clave para éxito de la empresa (creación de datos,
intercambio, actualización, almacenamiento, recuperación y eliminación)
Ejemplo Diagrama de Gestión del Conocimiento.

D-2: Matriz de Intercambio de Información

La Matriz de Intercambio de Información describe atributos
relevantes del intercambio de datos entre sistemas. Estos atributos
incluyen tamaño, especificación lógica de la información.
Ejemplo
El intercambio de información expresa las relaciones a través de cuatro importantes aspectos de la arquitectura
(información, actividades, localidades y tiempo) con un enfoque en aspectos específicos del flujo de información.
El intercambio de información identifica que nodos de negocio intercambian (qué) información durante la
ejecución de actividades en respuesta a dichos eventos. Información adicional de quien está ejecutando la
actividad puede ser agregada si es necesario para análisis de seguridad. La información detallada en la Matriz de
Intercambio de Información puede ser difícil de recolectar, necesaria para entender completamente el flujo de
información en la empresa y los aspectos de seguridad.
La matriz también identifica los eventos que disparan el intercambio de información. (Ej: establecer la
programación o los requerimientos ciudadanos).

D-3: Diagrama de transición de estados de Objetos

Un Diagrama de transición de estados de objetos usa la notación del
Lenguaje de Modelado Unificado para mostrar como es el ciclo de
vida de un objeto de datos específico. Este diagrama muestra los
cambios en los atributos, enlaces y/o comportamiento(s) de un
objeto como resultado de un evento del sistema interno o externo
que dispara los cambios en el estado
Ejemplo

D-4: Diagrama de seguimiento de sucesos de Objetos

El diagrama de seguimiento de objetos permite el
seguimiento de acciones en el conjunto de escenarios e
hilos operacionales. Cada modelo puede enfocarse en una
secuencia crítica de eventos y una descripción de este
escenario puede acompañar el modelo.
Ejemplo

D-5: Diagrama de seguimiento de sucesos de Objetos

El diagrama de seguimiento de objetos permite el
seguimiento de acciones en el conjunto de escenarios e
hilos operacionales. Cada modelo puede enfocarse en una
secuencia crítica de eventos y una descripción de este
escenario puede acompañar el modelo.
Ejemplo

D-6: Modelo Físico de Datos

El modelo físico de datos es usado para describir como la
información representada en el Modelo Lógico de Datos es
actualmente implementada en el sistema de información.
Ejemplo
El Modelo Físico de Datos (PDM-Physical Data El modelo Físico de Datos Provee
Model) es un modelo compuesto cuyos
Formato de los Mensajes
componentes pueden variar grandemente, como
lo muestra la plantilla adjunta. Para algunos • Estándares de Referencia
propósitos un diagrama entidad/relación del
• Tipo(s) de mensajes
diseño físico de la base de datos será suficiente. El
Lenguaje de Definición de Datos puede también Estructura del Archivo
ser usado en casos donde bases de datos
• Estándares de referencia
compartidas son usadas para integrar sistemas.
Referencias a formatos estándares de datos (que • Descripción de registros y archivos
identifican los tipos de mensajes y opciones a ser
• Mapeo desde el Modelo
usadas) pueden ser suficientes Descripciones de
formatos de archivo pueden usarse cuando un Esquema Físico
archivo de paso es el modo utilizado para
intercambiar información
Los sistemas interoperables pueden usar una
variedad de técnicas para el intercambio de datos
y entonces tener distintas particiones en el PDM
con cada partición usando una forma diferente.

D-7: Matriz Actividad/Entidad

La matriz Actividad/Entidad es desarrollada con la finalidad
mapear que entidades de datos son afectadas por las
actividades de la línea de negocios. Toma el nombre de
matriz CRUD debido a que identifica los tipos básicos
transformaciones que son realizadas en los datos (crear,
leer, actualizar, eliminar) a través de los procesos de
negocios.
Ejemplo

D-8: Diccionario de Datos

El diccionario de datos provee un listado comprensivo de
las entidades de datos que son recolectados y mantenidos
por la empresa, incluidas las normas para los atributos de
los campos, claves y relaciones. El Diccionario de Datos
también incluye una biblioteca de Objetos de Datos
reusables que usan métodos UML.
Ejemplo

SA-1: Diagrama de Interfaces del Sistema

El Diagrama de Interfaces del Sistema muestra las interfaces
físicas y/o lógicas entre los sistemas de información,
producción, etc., donde la información y/o otros recursos
son intercambiados.
Ejemplo

SA-2: Descripción de Comunicaciones del Sistema

El artefacto S-2 complementa al diagrama de Interfaces del
Sistema proveyendo una descripción de como los datos se
comunican entre sistemas a través de la empresa e incluye
detalles sobre los vínculos, path, redes y medios de
comunicación.
Ejemplo

SA-3: Matriz e Interfaces del Sistema

La matriz de interfaces del sistema muestra la naturaleza y
estado de las interfaces físicas y lógicas entre los sistemas de
información a través de la empresa.
Ejemplo
1. Provee detalles de las características de las interfaces del artefacto SA-1
• Permite una rápida revisión
• Habilita una rápida evaluación del rehúso potencial o redundancias
2. Herramienta útil para gestionar la evolución del sistema, infraestructura, inserción de tecnología,
actualizaciones funcionales, etc.
3. Las características de la interfaces que pueden ser capturadas incluyen:
• Estado (existente, planeado, potencial, desactivado), propósito, nivel de clasificación, interfaces claves.

SA-4: Diagrama de Flujo de Datos del Sistema

El diagrama de flujo de datos del sistema en mejor conocida
como Diagrama de Flujo de Datos, el mismo muestra los
procesos dentro de un sistema que intercambia datos, y
como este intercambio ocurre. El artefacto SA-4
complementa al artefacto B-4 Diagrama de Procesos de
Negocio, y puede ser descompuesto para mostrar detalles
adicionales.
Ejemplo
1. Captura y describe las funciones del sistema y los flujos de datos entre estos.
2. Documenta las jerarquías funcionales del sistema.
3. El principal propósito es :
• Desarrollar una clara descripción de los flujos necesarios del sistema, entradas y salidas para cada
sistema.
• Asegurar que la conectividad funcional está completa

SA-5: Matriz Sistemas/Operaciones

La matriz de Sistemas/Operaciones relaciona las actividades
operacionales a las funciones del sistema entre las líneas de
negocio a través de la empresa.
Ejemplo
1. Relaciona actividades operacionales con las funciones del sistema
2. Identifica la transformación de una necesidad operacional dentro de una actividad realizada por el sistema
3. Apoya la toma de decisiones tomando las siguientes acciones:
• Identifica de posibilidad de extender lossistemas y las oportunidades de automatización
• Identifica sistemas y funciones redundantes
• Analiza brechas de rendimiento
• Identifica oportunidades de inversión

SA-6: Matriz de Intercambio de Datos del Sistema

La Matriz de Intercambio de Datos del sistema utiliza el
formato de tabla para mostrar que sistemas intercambian
tipos particulares de datos dentro o entre las líneas de
negocio a través de la empresa.
Ejemplo
La Matriz de Intercambio de Datos del Sistema, describe en formato tabular, el intercambio de datos entre los
sistemas de un nodo de sistemas o a través de nodos de sistemas. El enfoque de una Matriz de Intercambio de
Datos se centra en como el intercambio de datos es actualmente (o será) implementado, en sistemas específicos
que cubren características tales como datos y protocolos específicos o formatos. Estos aspectos de intercambio,
aunque difíciles de documentar, son críticos para entender el potencial de los gastos generales y las restricciones
de seguridad introducidas por los aspectos físicos de la aplicación. La matriz se relaciona y crece a partir de la
Matriz de Intercambio de Información. Es decir, la parte automatizada de cada intercambio de información está
asociada con la interfaz del sistema que transporta los datos del sistema correspondientes en la Descripción de
Interfaces del Sistema. Las características del negocio para el intercambio de información son reemplazadas con
las características del sistema de intercambio de información correspondiente.

SA-7: Matriz de Rendimiento del Sistema

La matriz lista las métricas que son importantes con respecto
a la fiabilidad, disponibilidad y facilidad de mantenimiento.
Ejemplo
1. Especifica las características cuantitativas del sistema:
• Hardware/software
• Interfaces
• Componentes de comunicación
2. Identificas los parámetros tanto actuales como futuros
3. Incluyes todas las características técnicas de rendimiento, por ejemplo
• Tiempo promedio entre fallos
• Velocidad de reinicio
• Tiempo de inicialización del sistema
• Velocidad de transferencia de información

SA-8: Diagrama de Evolución de Sistemas

El diagrama muestra la evolución de un sistema incluida la
relación y el tiempo de instalaciones consolidadas,
actualizaciones y retiros, a veces muestra en el contexto de
cambios con otros sistemas, aplicaciones, sitos web y bases
de datos.
Ejemplo

SA-9: Diagrama de Aplicaciones Web

El diagrama muestra las relaciones lógicas entre servicios de
información basados en web, en este caso mostrando un
diagrama detallado de servicios que interactúan a través de
protocolos e interfaces estándares que promueven la
independencia de la plataforma en el intercambio de datos.
Ejemplo

NI-1: Diagrama de Conectividad de Redes

El diagrama muestra las conexiones físicas entre las redes de
voz, video y datos incluyendo WAN´s y LAN´s también
llamadas “Extranets” e “Intranets”
Ejemplo

NI-2: Inventario de red

El inventario lista todo el hardware y software de las redes
de voz, datos y video a través de la empresa. Esta lista puede
incluir códigos de barra y otros identificadores únicos.
Ejemplo

NI-3: Inventario de equipos

El inventario lista todo el hardware y software de las redes
de voz, datos y video a través de la empresa. Esta lista puede
incluir códigos de barra y otros identificadores únicos.
Ejemplo

NI-4: Planos de Construcción

Este artefacto es un conjunto completo de planos
electrónicos para todas las construcciones a través de la
empresa. Los planos ayudan en la planificación y toma de
decisiones respecto a la ubicación de puestos de trabajo,
facilidades de producción, almacenes de datos, redes y otras
funciones del negocio
Ejemplo

NI-5: Diagrama Central de Redes

Este este es uno de los artefactos mapas importantes del
centro de redes. Este diagrama puede ser parte del conjunto
de planos presentados en el artefacto NI-4 y es mantenido
electrónicamente para soportar los numerosos cambios en
el centro de redes y en la sala de servidores.
Ejemplo

NI-6: Diagrama Planta de Cableado

Este artefacto muestra la conectividad física de las redes de
voz, datos y video a través de la empresa y de proveedores
globales. El diagrama puede mostrar los tipos de cables
(fibra, CAT-6, etc.) y el ancho de banda (T-1, OC3, etc.) de
cada cable que corre entre los centros de redes, salas de
servidores, armarios de cableado y conexiones externas
Ejemplo

NI-7: Diagrama de Distribución de Racks

Este diagrama proporciona una vista frontal y posterior de
cada uno de los racks de equipos de tecnología de
información que van a un centro de redes, salas de
servidores y / o en el armario de cableado. Este diagrama
soporta los diagramas NI-5 y NI-6 y es mantenido
electrónicamente para soportar los numerosos cambios
que se esperan a través de un determinado número de
años.
Ejemplo

SP-1: Plan de Seguridad

Este plan provee tanto una descripción de alto nivel como
detallada del programa de seguridad que está en vigor a
través de la empresa. Este incluye elementos y
procedimientos físicos, de datos, de personal y seguridad
operacional.
Ejemplo
1. Introducción
• Purpose of the IT Security Program
• Principles of IT Security
• Critical Success Factors
• Intended Outcomes
• Performance Measures
2. Políticas
• Guía ejecutiva
• Guía técnica
• Ley y reglamento de políticas aplicables
3. Requisitos de Información
• Roles y responsabilidades de Programa de Seguridad de TI
• Planificación e Hitos del Programa de Seguridad de TI
• Reporte de Incidentes de Seguridad de TI
4. Concepto de Operaciones
• IT Security Threat Summary
• IT Security Risk Mitigation
• Integration with Enterprise Architecture
• Component/System Security Plans
5. Elementos de seguridad del programa
• Seguridad de la Información
• Seguridad del Personal
• Seguridad Operacional
• Seguridad Física
6. Procedimientos y Estándares Operativos
• Pruebas y Evaluación
• Evaluación del Riesgo
• Certificación y Acreditación
• Recuperación del Desastre/Continuidad de Operaciones
• Registros de protección y archivo
• Privacidad de Datos

SP-2: Descripción de Soluciones de Seguridad

Este artefacto provee una vista de alto ni el de como la
seguridad es provista para diferentes recursos a través
de la empresa. Estas soluciones cubren 4 dimensiones
de seguridad: física, de datos, de personal y
operaciones y puede incluir diagramas y matrices
Ejemplo
Seguridad Operacional Seguridad de Datos
En el área de seguridad operacional, el Programa de En el área de seguridad de la información, el Programa
Seguridad debe promover el desarrollo de de Seguridad debe promover diseños preocupados
procedimientos operativos estándar (SOP´s) para todos por la seguridad, la garantía del contenido de la
los componentes arquitectónicos (AE) que den soporte información, autenticación de origen y control de
a cada línea de negocio. Los SOP también se deben acceso de datos. La evaluación de los tipos de datos
desarrollar para la recuperación cortes o desastres que se manejan para los problemas de protección de
naturales, y para permitir la continuidad de las privacidad también se debe hacer (por ejemplo, datos
operaciones, ya sea que toda o parte de la de la empresa de crédito de los clientes o los números de seguro
se inhabilite. social del empleado
Seguridad del Personal Seguridad Física

En el ámbito de la seguridad personal, el Programa de Los elementos de seguridad física que deben ser
Seguridad debe promover la autenticación de usuarios capturados en la AE incluyen la protección de las
y la conciencia de seguridad de TI, en el nuevo usuario a instalaciones que apoyan el procesamiento de TI,
través de formación recurrente. Las insignias, la control de acceso a los equipos informáticos, redes y
biometría, las tarjetas de banda magnética, cerraduras salas de telecomunicaciones, así como la protección
de cifrado, y otros métodos de personal y soluciones de contra incendios, almacenamiento de medios y
seguridad física combinadas deben aplicarse. sistemas de recuperación de desastres.

SP-3: Documento de Acreditación de Sistemas

Este artefacto utiliza un formato estándar para evaluar es
estatus de seguridad de los sistema de información a través
de la empresa. Existe un número de partes para la
acreditación de un sistema de seguridad que son ilustradas
en el ejemplo.
Ejemplo
1. Plan de seguridad del sistema.- Esta primera sección del documento de acreditación del sistema proporciona
una visión general del contexto de negocios en el que funciona el sistema de información, establece el estado
de seguridad actual del sistema (última acreditación), y resume el contenido y la búsqueda de otros
documentos de acreditación.
2. Evaluación de riesgos del sistema.- En esta sección del documento se utiliza un formato normalizado para
que aparezcan las zonas de riesgo del sistema de información en las cuatro principales áreas de seguridad
que se tratan en artefacto SP-2; físicas, de datos operativas y de personal. Asigna un nivel de riesgo en función
del contexto de negocios para las operaciones del sistema las operaciones y el tipo de datos del sistema que
se va a proteger. Proporciona estrategias de remediación de riesgos de seguridad (como evitar un riesgo de
seguridad, o tratar con él si se produce un problema) para cada área de riesgo que se identifica.
3. Prueba del Sistema y Evaluación.- También se llamada “prueba de penetración. La sección Prueba y
Evaluación del Sistema (ST & E) del documento, presenta los resultados de una prueba en vivo que intenta
entrar en el sistema a través de procedimientos de inicio de sesión normal en los, así como los intentos de
sobrecargar el sistema (denegación de servicio), o infectar el sistema con un virus activo, gusano, u otro tipo
de elemento problemático que reduce o elimina la funcionalidad de sistema de información.
4. Plan de Remediación.- Esta sección del documento contiene el estado de las acciones correctivas adoptadas
para solucionar todos los riesgos de seguridad encontrados durante la evaluación del riesgo.
5. Aprobación para operar.- Esta sección del documento es la aprobación formal (firmado) para operar el
sistema de información que es proporcionada por la persona designada por la empresa (por lo general el
director de información o el Administrador de seguridad de TI).

SP-4: Plan de Continuidad de Operaciones

El Plan de Continuidad de Operaciones (COOP) utiliza un
formato estándar para describir donde la empresa o parte
de la empresa puede ser reubicado si el lugar de operación
normal no puede ser ocupado por un período prolongado
(más de unos pocos días), debido a un evento natural o
artificial.
Ejemplo
INICIO Y ADMINISTRACIÓN DEL PROYECTO
Estos criterios permiten establecer la necesidad de la Administración de Continuidad de Negocios de los procesos o funciones,
incluyendo la capacidad de recuperación, objetivos de recuperación, planes de continuidad del negocio y de manejo de crisis,
incluyendo el apoyo de la Dirección y organizar y manejar el desarrollo de la función o proceso, ya sea en colaboración con, o
como un componente clave de una iniciativa integrada de manejo de riesgos.
EVALUACIÓN Y ANÁLISIS DE RIESGO
La evaluación y análisis del riesgo permitirá determinar los eventos y los factores externos que pueden afectar en forma adversa
a la empresa y sus instalaciones con una interrupción o un desastre, el daño que dichos eventos pueden causar y los controles
necesarios para prevenir o minimizar los efectos de pérdidas potenciales. Proporcionar un análisis de costo beneficio para
justificar la inversión en controles para mitigar los riegos.
ANÁLISIS DE IMPACTO AL NEGOCIO
Analizar e identificare los impactos que resultan de escenarios de interrupciones y desastres que puedan afectar a la empresa y
las técnicas que puedan utilizarse para cuantificar y cualificar dichos impactos ha permitido a la empresa el establecer las
operaciones críticas, sus prioridades de recuperación y sus interdependencias, de tal manera que puedan establecerse los
Objetivos de Tiempo de Recuperación (RTOs).
DESARROLLO DE ESTRATEGIAS BC/DR
Determinar y guiar en la selección de alternativas de estrategias de recuperación del negocio para la recuperación del negocio
y tecnologías de información dentro del objetivo de tiempo de recuperación, mientras que se mantienen las funciones críticas
de la compañía.
PREPARACIÓN Y RESPUESTA DE EMERGENCIA
Desarrollar e implementar procedimientos para respuesta y estabilización de la situación después de un incidente o evento,
incluyendo el establecimiento y manejo del Centro de Operaciones de Emergencia a ser usado como un centro de comando
durante una emergencia.
DESARROLLO E IMPLEMENTACIÓN
Se deberá diseñar, desarrollar e implementar planes de Continuidad y Gestión de Crisis que cumplan con la recuperación de las
actividades del negocio dentro de un marco de tiempo aceptable.
CONCIENTIZACIÓN Y CAPACITACIÓN
Preparar un programa para crear conciencia corporativa y mejorar las habilidades requeridas para desarrollar, implementar,
mantener y ejecutar el Plan para la continuidad del negocio.
MANTENIMIENTO Y ACTUALIZACIÓN DE PLANES
Se ha planificado y coordinado ejercicios de los planes además de evaluar y documentar los resultados.
Desarrollar procesos para mantener actualizada la capacidad de recuperación y la documentación de los planes según la
dirección estratégica de la organización. Igualmente se ha verificado que los planes son efectivos al compararlos contra un
estándar adecuado, y reporta los resultados de manera clara y concisa.
COMUNICACIÓN DE CRISIS
Desarrollar, coordinar, evaluar y probar planes para comunicarse con involucrados internos (empleados, gerentes, etc.)
involucrados externos (clientes, accionistas, proveedores, etc.) y los medios de comunicación (prensa, radio, televisión, Internet)
COORDINACIÓN CON AUTORIDADES EXTERNAS
Se han establecido los procedimientos necesarios para coordinar las actividades de respuesta, continuidad y restauración con
las agencias externas (locales, estatales, nacionales, respuesta de emergencia, defensa, etc.) mientras se asegura el cumplimiento
con estatutos y regulaciones aplicables.
Ver Norma BS 25999
Ver Norma ISO 22399

SP-5: Plan de Recuperación de Desastres

El plan de recuperación de desastres es una matriz de
evaluación y un conjunto de procedimientos para manejar
las interrupciones en varias capacidades del negocio y/o
tecnología, que no requieren que la empresa reubique sus
operaciones. Las interrupciones pueden ser causadas por
eventos naturales y artificiales (ej.: fuego, inundaciones,
interrupciones de energía)
Ejemplo
La activación del Plan de recuperación de desastres puede que tenga que llevarse a cabo en medio de una
catástrofe natural o de origen humano que hace claridad, brevedad, integridad y flexibilidad (copias de seguridad)
para el éxito. Los siguientes son algunos de los elementos recomendados en el Plan de Recuperación de Desastres:
1. Activación de la recuperación de desastres.- Condiciones para la activación del COOP.
2. Roles y Responsabilidades de recuperación.- Una matriz de los rolos y responsabilidades (por posición) del
personal de toda la empresa que están involucrados en la activación del COOP. Los alternantes se
proporcionan para cada posición.
3. Impacto de desastres y evaluación de la recuperación.- Una matriz estándar para evaluar el tipo y la
duración de la interrupción, así como los sistemas y funciones en toda la empresa que se ven afectados.
Dependiendo del tipo de corte de luz y el período previsto de interrupción (minutos, horas, días), el
procedimiento de recuperación puede variar.
4. Procedimientos de recuperación.- Los procedimientos que se utilizan para restaurar las funciones de la
empresa y / o del sistema que han sido interrumpidos. Algunos ejemplos son:
• Cortes eléctricos.
• Interrupción aire acondicionado/calefacción.
• Daños en la edificación (fuego, inundación, terremotos).
• Infección viral en los sistemas de información.
• Perdida de comunicación de datos internos y externos.
• Perdida de comunicación telefónica interna y externa.

ST-1: Perfil de Estándares Tecnológicos

El perfil de estándares tecnológicos es una lista de servicios
de negocio y tecnologías asociadas que son aceptadas por
la empresa como estándares primarios o secundarios.
Mayor detalle puede ser agregado a determinados tipos de
estándares (ej.: datos, telecomunicaciones) y distribuidores
de productos.
Ejemplo

ST-2: Prospectiva Tecnológica

La prospectiva tecnológica soporta y se relaciona con el
artefacto ST-1. Este artefacto documenta los cambios
esperados en cualquiera de los estándares listados en el
artefacto ST-1, donde aparecen los cambios futuros que
está sucediendo o va a suceder.
Ejemplo
• Captura los cambios esperados en tecnología relacionado con estándares y convenciones.
• Identifica estándares críticos de tecnología, su fragilidad e impacto de los cambios en la arquitectura.
• Contiene predicciones específicas acerca de la disponibilidad de estándares emergentes, y relacionados con
elementos específicos del framework en cuanto a sistemas/aplicaciones.

W-1: Plan de Recursos

El plan de recursos provee una descripción de alto nivel de
como el capital humano es gestionado a través de la
empresa. El plan de recursos incluye estrategias para para
la contratación, retención y desarrollo profesional en los
niveles ejecutivo, administrativo y de personal de la
empresa. .
Ejemplo
Esquema del plan laboral
Resumen de la Estrategia de Gestión del Capital Humano
ü Requerimientos del Negocio
ü Competencias de nivel ejecutivo y los Planes de Desarrollo Profesional
ü Gestión del Nivel de Competencias y Planes de Desarrollo Profesional
• Línea de Negocio A
• Línea de Negocios B
• línea de negocio C
• línea de negocio D
ü Competencias Nivel Personal y Planes de Desarrollo Profesional
• Línea de Negocio A
• Línea de Negocios B
• Línea de negocio C
• Línea de negocio D
ü Proceso de Revisión de Rendimiento
ü Programa de Beneficios
ü Programa entrenamiento y tutelaje

W-2: Organigrama
El organigrama muestra como las posiciones y el personal
está organizado en diagramas jerárquicos o en un esquema
matricial. El organigrama muestra las líneas de autoridad,
relaciones de trabajo, así como los propietarios de los
recursos, productos y procesos.
Ejemplo

W-3: Perfil de Conocimiento Recursos

Provee un inventario detallado de lo que una persona debe
saber y poder hacer en una determinada posición dentro
de la empresa. El ejemplo provisto es una Lista de
“Conocimientos, destrezas y habilidades” para arquitectos
empresariales desarrollado por Carnegie Mellon Architetcts
en 204y actualizado en 2012.
Ejemplo
AACS-PAQS/jclg/2018-08-26/174
pdf interactivo/gjmp/2018-08-22/175

ISBN-10: 9942-04-425-6

GUÍA

Cargado por

Copyright:

Formatos disponibles

GUÍA

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

GUÍA

Cargado por

Copyright:

Formatos disponibles

Informática

Modalidad Abierta y a Distancia

Gestión de Tecnologías de Información

La Universidad Católica de Loja

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

Maquetación y Diseño digital

4.1. Básica .......................................................................................................................................... 8

6. Proceso de enseñanza-aprendizaje para el logro de competencias ................ 12

6.1. Competencias genéricas ....................................................................................................... 12

UNIDAD 1. GESTIÓN DE TECNOLOGÍAS DE INFORMACIÓN, ARQUITECTURA EMPRESARIAL

1.1. Introducción a Gestión de Tecnologías de Información (GTI). .................................. 16

UNIDAD 2. IMPLEMENTACIÓN DE LA METODOLOGÍA ARQUITECTÓNICA.................................. 40

2.1. Metodología de Implementación ...................................................................................... 41

UNIDAD 3. COMPONENTES Y ARTEFACTOS ARQUITECTÓNICOS .................................................. 51

3.1. Componentes arquitectónicos: Nivel Objetivos e Iniciativas .................................... 53

6.5. Planificación para el trabajo del alumno. ....................................................................... 70

UNIDAD 4. DESARROLLO DE LA VISTA ARQUITECTÓNICA ACTUAL............................................. 73

4.1. Componentes arquitectónicos: en el Nivel de Objetivos e Iniciativas

UNIDAD 5. DESARROLLO DE LA VISTA ARQUITECTÓNICA FUTURA ............................................ 92

5.1. El desarrollo de escenarios CONOPS .................................................................................. 93

UNIDAD 6. DESARROLLO DE UN PLAN DE GESTIÓN DE ARQUITECTURA EMPRESARIAL ....... 106

6.1. Gestión del Programa Arquitectónico .............................................................................. 106

El componente educativo de Gestión de Tecnologías de Información es un componente troncal que se

En la Unidad 2 se describe el proceso de implementación de la metodología arquitectónica, que es un

6 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

Finalmente, le deseamos el mejor de los éxitos en el desarrollo de la presente asignatura y le recordamos

7 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

El presente texto es la base para el estudio de la temática de Arquitectura Empresarial, en el

Este libro es la base para el estudio de la temática de Gestión de Tecnologías de la Información

• Landa, R. (2012): “Administración de Tecnologías de Información”. Departamento: Ciencias

• Biden;J. (2012). “Federal Enterprise Architecture”. Recuperado de www.whitehouse.gov/omb/e-gov/

• Brown ;A. (2013). “Enterprise Architecture”. Recuperado de www.opengroup.org

• Nunn; S.(2012). “National Institutes of Health”. Recuperado de https://enterprisearchitecture.nih.

8 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

• Scoot; J. (2012).Human Service. Recuperado de http://www.hhs.gov/ocio/ea/index.html - U.S.

• Zachman; J. (2012).” Enterprise Arquitecture Framework”. Recuperado de www.zachman.com

9 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

5. Orientaciones generales para el estudio

10 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

El sistema de estudios de la Modalidad Abierta y a Distancia de la Universidad Técnica Particular de

11 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

6.1. Competencias genéricas

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

6.2. Planificación para el trabajo del alumno

La Universidad Católica de Loja

1.9. La Arquitectura Empresarial como un Programa

1.9.1. Alineación Estratégica.

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

1.10.5. Elemento de Análisis y Diseño # 5: Plan de

La Universidad Católica de Loja

Unidad 3: Componentes y Artefactos Arquitectónicos. Lectura de la unidad 3 del Semana 5 y 6

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

3.5. Componentes Arquitectónicos: Nivel de sistemas

La Universidad Católica de Loja

Revisión de contenidos Semana 7 y 8

6.3. Sistema de evaluación de la asignatura (primero y segundo bimestre)

Formas de evaluación 2. Heteroevaluación

Investigación (cita fuentes de

PORCENTAJE 10% 20% 30% 70%

Tenga presente que la finalidad de la valoración cualitativa es