Vargas Na Ula Francisco Oswaldo

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
ÁREA TÉCNICA
TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y

COMPUTACIÓN
Definición de marco de referencia de Arquitectura empresarial para

PYMEs. -Iteraciones de capacidad y desarrollo arquitectónico ADM
TOGAF-.
TRABAJO DE TITULACIÓN.
AUTOR: Vargas Naula, Francisco Oswaldo.
DIRECTOR: Cabrera Silva, Armando Augusto, Mg.
LOJA - ECUADOR
2017
Esta versión digital, ha sido acreditada bajo la licencia Creative Commons 4.0, CC BY-NY-
SA: Reconocimiento-No comercial-Compartir igual; la cual permite copiar, distribuir y
comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice con
fines comerciales y se permiten obras derivadas, siempre que mantenga la misma licencia al
ser divulgada. http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es
Septiembre, 2017
APROBACIÓN DEL DIRECTOR DEL TRABAJO DE TITULACIÓN
Magister.
Armando Augusto Cabrera Silva.
DOCENTE DE LA TITULACIÓN
De mi consideración:
El presente trabajo de titulación: “Definición de marco de referencia de Arquitectura

empresarial para PYMEs. -Iteraciones de capacidad y desarrollo arquitectónico ADM
TOGAF-” realizado por Vargas Naula Francisco Oswaldo, ha sido orientado y revisado
durante su ejecución, por cuanto se aprueba la presentación del mismo.
Loja, Enero de 2017.
f) ........................................
ii
DECLARACIÓN DE AUTORÍA Y CESIÓN DE DERECHOS
Yo, Vargas Naula Francisco Oswaldo, declaro ser autor del presente trabajo de titulación:
“Definición de marco de referencia de Arquitectura empresarial para PYMEs. -Iteraciones de
Capacidad y Desarrollo arquitectónico ADM TOGAF-”, de la Titulación de Sistemas
Informáticos y Computación, siendo Cabrera Silva Armando Augusto, director del presente
trabajo; y eximo expresamente a la Universidad Técnica Particular de Loja y a sus
representantes legales de posibles reclamos o acciones legales. Además certifico que las
ideas, conceptos, procedimientos y resultados vertidos en el presente trabajo investigativo,
son de mi exclusiva responsabilidad.
Adicionalmente, declaro conocer y aceptar la disposición del Art. 88 del Estatuto Orgánico
de la Universidad Técnica Particular de Loja que en su parte pertinente textualmente dice:
“Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones,
trabajos científicos o técnicos y tesis de grado que se realicen a través, o con el apoyo
financiero, académico o institucional (operativo) de la Universidad”.
f. ..............................................
Autor: Vargas Naula Francisco Oswaldo.
Cédula: 1104805617.
iii
DEDICATORIA
El presente trabajo se lo dedico a los tres pilares que permitieron la concepción de esta
obra: mi maestro por excelencia, mis maestros de vida y mis maestros de instrucción
profesional.
Las sagradas escrituras mencionan que “todas las cosas son posibles para el que cree”
(Marcos 9:23). Sin embargo, con el transcurrir del tiempo me doy cuenta que no basta con
creer, sino que se debe trabajar arduamente por la realización de nuestros sueños. Por esta
razón, dirijo mi agradecimiento a Dios, por significar luz en mi camino y constituirse en la
fortaleza con la que afronto cada uno de mis días.
De manera similar, este trabajo de titulación está dedicado a mi familia, para quienes
encuentro insuficientes las palabras de agradecimiento por el cariño y apoyo que he
encontrado en ellos. Todas las situaciones difíciles que hemos superado, han permitido que
encuentre el verdadero valor del esfuerzo y trabajo en equipo. Confío plenamente que éste
será el primero de los tantos éxitos que podré disfrutar en familia.
Por último, hago mención de aquellas personas que supieron compartir sus conocimientos y
experiencias conmigo, quienes lograron despertar en mí el espíritu investigativo, ético y
crítico que caracteriza a un buen profesional. Gracias a su comprensión y paciencia, hoy veo
reflejado en este trabajo, el producto compartido de la constancia y dedicación a lo largo de
todos estos años.
iv
AGRADECIMIENTO
Además de las personas mencionadas anteriormente, quiero entregar mi más sincero y

profundo agradecimiento a mis amigos, compañeros y a todas aquellas personas que
directa o indirectamente me brindaron su incondicional apoyo durante este periodo de
formación universitaria.
De igual forma, agradezco a dos personas cuya colaboración ha sido fundamental para el
desarrollo del presente trabajo: Katherine, compañera de equipo de trabajo, y Mg. Armando
Cabrera, director del trabajo de titulación. A ellos, les doy las gracias por la paciencia y todas
las experiencias compartidas en este tiempo.
Faltarán palabras de gratitud para Allison, quien a lo largo de este trabajo me supo brindar
incondicionalmente su confianza, apoyo y amor. Ella es y será en mi vida, una de mis
mayores bendiciones.
v
ÍNDICE DE CONTENIDOS
APROBACIÓN DEL DIRECTOR DEL TRABAJO DE TITULACIÓN........................................ii

DECLARACIÓN DE AUTORÍA Y CESIÓN DE DERECHOS...................................................iii
DEDICATORIA....................................................................................................................... iv
AGRADECIMIENTO................................................................................................................v
ÍNDICE DE CONTENIDOS.....................................................................................................vi
ÍNDICE DE FIGURAS........................................................................................................... xiii
ÍNDICE DE TABLAS............................................................................................................xvii
RESUMEN.............................................................................................................................. 1
ABSTRACT............................................................................................................................. 2
INTRODUCCIÓN.................................................................................................................... 3
OBJETIVOS............................................................................................................................ 5
Objetivo general.................................................................................................................5
Objetivos específicos..........................................................................................................5
CAPÍTULO 1: EMPRESA........................................................................................................6
1.1 Metodología de investigación......................................................................................7
1.1.1 Enfoque metodológico..........................................................................................7
1.1.2 Método de investigación.......................................................................................7
1.1.3 Fases de la investigación.....................................................................................7
1.2 Definición de empresa.................................................................................................9
1.3 Funciones de la empresa.............................................................................................9
1.4 Clasificación de las empresas...................................................................................10
1.4.1 De acuerdo a su tamaño o magnitud.................................................................10
1.4.2 De acuerdo a la actividad que desarrollan..........................................................11
1.4.3 De acuerdo al origen del capital.........................................................................11
1.4.4 De acuerdo a la forma de organización del capital.............................................11
1.5 PYMEs en el Ecuador................................................................................................12
1.5.1 Definición de PYMEs..........................................................................................12
1.5.2 Situación actual de las PYMEs en el Ecuador....................................................12
1.5.3 Fortalezas de las PYMEs...................................................................................15
1.5.4 Debilidades de las PYMEs.................................................................................15
1.5.5 Aspectos legales de PYMEs...............................................................................15
vi
1.5.6 Órganos de regulación de PYMEs.....................................................................16
1.5.6.1 Superintendencia de compañías................................................................16
1.5.6.2 Cámaras de la industria y producción.........................................................16
1.5.6.3 Código orgánico de la producción...............................................................16
1.5.6.4 Ley de Compañías......................................................................................16
1.5.6.5 Código de comercio....................................................................................17
1.5.7 PYMEs en la zona de planificación 7.................................................................17
1.6 Percepción de TIC's en las PYMEs...........................................................................19
1.6.1 Introducción........................................................................................................19
1.6.1.1 Adopción de TIC's en las PYMEs...............................................................20
1.6.2 Incorporación de las TIC's en el sector productivo.............................................21
1.6.3 Situación actual de las TIC's en las PYMEs de nuestro país..............................22
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL.................................................................28
2.1 Conceptos previos.....................................................................................................29
2.1.1 Dimensionamiento.............................................................................................29
2.1.2 Transformación empresarial...............................................................................30
2.1.2.1 Marcos de referencia para transformación de empresas............................31
2.1.2.1.1 Marco de transformación de Venkatraman..........................................32
2.1.2.1.2 Business transformation management methodology...........................33
2.1.2.1.3 Marco de transformación de negocios electrónicos en PYMEs...........35
2.1.2.1.4 Business transformation enablement program....................................36
2.2 Arquitectura empresarial............................................................................................37
2.2.1 Definición de arquitectura empresarial...............................................................38
2.2.2 Perspectivas de arquitectura empresarial..........................................................39
2.2.3 Marcos de referencia de arquitectura empresarial.............................................40
2.2.3.1 Evolución de los marcos de referencia arquitectónicos..............................41
2.2.3.2 Clasificación de los marcos de referencia arquitectónicos..........................42
2.2.3.2.1 Marcos de referencia propietarios.......................................................43
2.2.3.2.1.1 Gartner........................................................................................43
2.2.3.2.1.2 IBM EAF......................................................................................45
2.2.3.2.1.3 ORACLE EAF..............................................................................47
2.2.3.2.1.4 SAP EAF.....................................................................................48
2.2.3.2.2 Marcos de referencia semi - propietarios............................................49
2.2.3.2.2.1 EA 3 Cube...................................................................................50
2.2.3.2.2.2 Zachman.....................................................................................52
vii
2.2.3.2.3 Marcos de referencia abiertos.............................................................54
2.2.3.2.3.1 TOGAF.........................................................................................54
2.2.3.2.4 Marcos de referencia gubernamentales..............................................56
2.2.3.2.4.1 DoDAF.........................................................................................56
2.2.3.2.4.2 FEAF............................................................................................57
2.2.3.3 Evaluación de los marcos de referencia arquitectónicos............................59
2.2.4 Enfoque ágil.......................................................................................................61
2.2.4.1 Concepto de ágil.........................................................................................61
2.2.4.2 Manifiesto ágil.............................................................................................62
2.2.4.3 Arquitecturas empresariales ágiles.............................................................63
2.2.4.4 Técnicas ágiles...........................................................................................66
2.2.4.4.1 Kanban................................................................................................66
CAPÍTULO 3: CONCEPTUALIZACIÓN DE TOGAF..............................................................68
3.1 Conceptos básicos....................................................................................................69
3.1.1 Historia de TOGAF.............................................................................................69
3.1.2 ¿Qué es TOGAF?..............................................................................................69
3.1.3 Dimensiones de TOGAF.....................................................................................70
3.1.4 Aplicabilidad de TOGAF......................................................................................70
3.2 Método de desarrollo arquitectónico..........................................................................71
3.2.1 Definición........................................................................................................... 71
3.2.2 Puntos claves.....................................................................................................72
3.2.3 Iteraciones..........................................................................................................72
3.2.4 Iteración de capacidad arquitectónica................................................................73
3.2.4.1 Fase preliminar...........................................................................................73
3.2.4.2 Fase A: Visión arquitectónica......................................................................74
3.2.5 Iteración de desarrollo arquitectónico.................................................................76
3.2.5.1 Fase B: Arquitectura de negocio.................................................................76
3.2.5.2 Fase C: Arquitectura de sistemas de información.......................................78
3.2.5.2.1 Arquitectura de datos..........................................................................79
3.2.5.2.2 Arquitectura de aplicaciones...............................................................80
3.2.5.3 Fase D: Arquitectura tecnológica................................................................82
3.2.6 Iteración de transición arquitectónica.................................................................84
3.2.7 Iteración de gobernanza arquitectónica..............................................................84
3.2.8 Gestión de requerimientos.................................................................................85
3.3 Guías y técnicas del método de desarrollo arquitectónico.........................................85
viii
3.4 Marco del contenido arquitectónico...........................................................................87
3.4.1 Artefactos........................................................................................................... 87
3.4.2 Entregables........................................................................................................88
3.4.3 Bloques de construcción....................................................................................88
3.4.4 Metamodelo de contenidos................................................................................88
3.5 Continuum empresarial..............................................................................................90
3.6 Vistas, puntos de vista e interesados.........................................................................91
3.6.1 Vista................................................................................................................... 91
3.6.2 Punto de vista....................................................................................................91
3.6.3 Interesados........................................................................................................91
3.7 Marco de la capacidad arquitectónica........................................................................91
3.8 Modelos de referencia...............................................................................................92
3.8.1 Modelo de referencia técnico.............................................................................92
3.8.1.1 Componentes del modelo de referencia técnico.........................................93
3.8.2 Modelo de referencia de la infraestructura integrada de información.................93
3.8.2.1 Componentes del modelo de referencia III.................................................94
CAPÍTULO 4: PROPUESTA..................................................................................................95
4.1 Introducción............................................................................................................... 96
4.2 Criterios para la adaptación del marco de referencia arquitectónico..........................96
4.2.1 Características de las pequeñas y medianas empresas....................................96
4.2.2 Recomendaciones de The Open Group para la adaptación de TOGAF.............97
4.2.3 Características del marco de referencia orientado a PYMEs.............................98
4.3 Marco arquitectónico propuesto...............................................................................100
4.3.1 Iteración de capacidad arquitectónica..............................................................102
4.3.1.1 Fase preliminar.........................................................................................103
4.3.1.1.1 Objetivos...........................................................................................104
4.3.1.1.2 Pasos................................................................................................106
4.3.1.1.3 Productos arquitectónicos..................................................................111
4.3.1.1.3.1 Artefactos...................................................................................112
4.3.1.1.3.2 Entregables................................................................................112
4.3.1.1.4 Herramientas adicionales..................................................................119
4.3.1.2 Fase A: Visión arquitectónica....................................................................121
4.3.1.2.1 Objetivos...........................................................................................122
4.3.1.2.2 Pasos................................................................................................123
4.3.1.2.3 Productos arquitectónicos.................................................................128
ix
4.3.1.2.3.1 Artefactos...................................................................................128
4.3.1.2.3.2 Entregables...............................................................................129
4.3.2 Iteración de desarrollo arquitectónico...............................................................139
4.3.2.1 Modelo genérico para las fases B, C y D..................................................141
4.3.2.1.1 Objetivos...........................................................................................141
4.3.2.1.2 Pasos................................................................................................142
4.3.2.1.3 Productos arquitectónicos.................................................................146
4.3.2.1.3.1 Artefactos...................................................................................146
4.3.2.1.3.2 Entregables...............................................................................146
CAPÍTULO 5: PRUEBA DE CONCEPTO............................................................................158
5.1 Definición del caso de estudio.................................................................................159
5.1.1 Reseña histórica de la Cooperativa de transportes Loja..................................159
5.1.2 Servicios ofrecidos por la CTL..........................................................................160
5.1.3 Cadena de valor de la CTL...............................................................................160
5.1.4 Situación actual de la CTL................................................................................161
5.1.4.1 Negocio....................................................................................................161
5.1.4.2 Datos........................................................................................................162
5.1.4.3 Aplicaciones..............................................................................................162
5.1.4.4 Tecnología................................................................................................163
5.1.5 Problemática....................................................................................................163
5.1.5.1 Descripción del segmento de negocio seleccionado.................................164
5.2 Adopción del marco arquitectónico propuesto en la CTL.........................................165
5.2.1 Iteración de capacidad arquitectónica..............................................................165
5.2.1.1 Fase preliminar.........................................................................................165
5.2.1.1.1 Elaborar o actualizar la planificación estratégica...............................167
5.2.1.1.2 Seleccionar marcos de referencia de gestión empresarial................169
5.2.1.1.3 Establecer los roles y responsabilidades específicos bajo demanda del
equipo de Arquitectura empresarial y su organización......................................171
5.2.1.1.4 Identificar y establecer los principios arquitectónicos........................171
5.2.1.1.5 Identificar las mejores prácticas de los marcos de gestión empresarial
seleccionados e integrarlas con el marco arquitectónico propuesto.................176
5.2.1.1.6 Implementar y configurar el repositorio arquitectónico empresarial...182
5.2.1.2 Fase A: Visión arquitectónica....................................................................184
x
5.2.1.2.1 Establecer el proyecto arquitectónico................................................186
5.2.1.2.2 Identificar interesados, preocupaciones y requerimientos del negocio.
.......................................................................................................................... 186
5.2.1.2.3 Confirmar y elaborar objetivos, impulsores y limitaciones del negocio.
.......................................................................................................................... 188
5.2.1.2.4 Evaluar las capacidades empresariales............................................190
5.2.1.2.5 Definir el alcance...............................................................................193
5.2.1.2.6 Refinar los principios arquitectónicos, si es necesario......................193
5.2.1.2.7 Desarrollar la visión arquitectónica....................................................193
5.2.1.2.8 Definir los beneficios que entregará la arquitectura destino y los
indicadores claves de desempeño....................................................................194
5.2.1.2.9 Identificar riesgos y actividades de mitigación...................................195
5.2.1.2.10 Desarrollar el Enunciado del trabajo arquitectónico; asegurar su
aprobación........................................................................................................196
5.2.2 Iteración de desarrollo arquitectónico...............................................................196
5.2.2.1 Seleccionar modelos de referencia, puntos de vista y herramientas........198
5.2.2.2 Desarrollar la descripción de las arquitecturas de línea base y destino....201
5.2.2.3 Realizar el análisis de brechas.................................................................202
5.2.2.4 Definir los componentes candidatos que conformarán la Hoja de ruta de la
implementación.....................................................................................................203
5.2.2.5 Conducir revisiones formales con los interesados....................................203
5.2.2.6 Crear la versión preliminar del Documento de definición arquitectónica.. .203
5.3 Análisis de los resultados obtenidos........................................................................204
CONCLUSIONES................................................................................................................ 205
RECOMENDACIONES.......................................................................................................207
BIBLIOGRAFÍA................................................................................................................... 208
ANEXOS............................................................................................................................. 213
ANEXO 1: Iteración de capacidad arquitectónica TOGAF 9.1........................................214
ANEXO 2: Iteración de desarrollo arquitectónico TOGAF 9.1.........................................216
ANEXO 3: Descripción de la iteración de transición arquitectónica TOGAF 9.1.............220
ANEXO 4: Iteración de transición arquitectónica TOGAF 9.1.........................................224
ANEXO 5: Descripción de la iteración de gobernanza arquitectónica TOGAF 9.1..........226
ANEXO 6: Iteración de gobernanza arquitectónica TOGAF 9.1......................................229
ANEXO 7: Descripción de la fase de gestión de requerimientos....................................231
ANEXO 8: Gestión de requerimientos TOGAF 9.1.........................................................232
xi
ANEXO 9: Guías y técnicas TOGAF 9.1.........................................................................233
ANEXO 10: Artefactos TOGAF 9.1.................................................................................235
ANEXO 11: Entregables TOGAF 9.1..............................................................................242
ANEXO 12: Iteración de capacidad arquitectónica del marco de referencia adaptado.. .245
ANEXO 13: Iteración de desarrollo arquitectónico del marco de referencia adaptado....247
ANEXO 14: Evaluación de los artefactos de las fases B, C y D......................................251
ANEXO 15: Relaciones de los tableros Kanban del marco arquitectónico adaptado......258
ANEXO 16: Marco arquitectónico adaptado...................................................................259
ANEXO 17: Estructura del equipo de arquitectura empresarial y su organización..........276
ANEXO 18: Principios arquitectónicos............................................................................288
ANEXO 19: Evaluación de capacidades.........................................................................311
ANEXO 20: Visión arquitectónica...................................................................................331
ANEXO 21: Enunciado del trabajo arquitectónico...........................................................342
ANEXO 22: Documento de definición arquitectónica......................................................358
xii
ÍNDICE DE FIGURAS
Figura 1: Metodología de la investigación...............................................................................8

Figura 2: Clasificación de empresas de acuerdo a su tamaño o magnitud............................10
Figura 3: Distribución de empresas en el Ecuador................................................................13
Figura 4: Sectorización de las PYMEs en el Ecuador............................................................13
Figura 5: Distribución geográfica de las PYMEs....................................................................14
Figura 6: Actividades económicas de las PYMEs de la zona de planificación 7....................18
Figura 7: Tipos de compañías de la zona de planificación 7.................................................19
Figura 8: Factores para la incorporación de las TIC..............................................................21
Figura 9: Etapas de la incorporación de las TIC's en las empresas......................................22
Figura 10: Existencia de departamento de TIC.....................................................................23
Figura 11: Número de personal de TIC.................................................................................23
Figura 12: Interconectividad y redes.....................................................................................24
Figura 13: Nivel de conocimiento respecto a TIC del gerente...............................................24
Figura 14: Software en las empresas....................................................................................25
Figura 15: Importancia de TIC's en las empresas.................................................................26
Figura 16: Beneficio de las TIC para el mejoramiento de los resultados empresariales........27
Figura 17: Dimensionamiento empresarial............................................................................30
Figura 18: Marco de transformación de negocios de Venkatraman.......................................32
Figura 19: Marco de transformación BTM2...........................................................................33
Figura 20: Ciclo de vida de la transformación.......................................................................34
Figura 21: Roles de gestión de Business transformation management methodology............34
Figura 22: Marco de transformación de negocios en países en vías de desarrollo...............35
Figura 23: Ecuación de arquitectura empresarial..................................................................38
Figura 24: Principales áreas de Gobernanza integrada........................................................39
Figura 25: Enfoque de los marcos de arquitectura empresarial............................................40
Figura 26: Evolución de los marcos de referencia de arquitectura empresarial.....................42
Figura 27: Modelo de procesos arquitectónicos de Gartner..................................................45
Figura 28: Método de desarrollo arquitectónico de IBM EAF.................................................46
Figura 29: Método de desarrollo arquitectónico de ORACLE EAF........................................48
Figura 30: Marco arquitectónico SAP EAF............................................................................49
Figura 31: Cubo EA3............................................................................................................. 50
xiii
Figura 32: Método de desarrollo arquitectónico de TOGAF...................................................55
Figura 33: Puntos de vista de DODAF...................................................................................57
Figura 34: Metamodelo del enfoque común de FEAf............................................................58
Figura 35: Relación entre arquitectura empresarial y metodologías ágiles...........................62
Figura 36: Diseño de arquitecturas ágiles.............................................................................64
Figura 37: Enfoque de arquitectura empresarial ágil.............................................................64
Figura 38: Elementos de enfoque ágil de arquitectura empresarial.......................................65
Figura 39: Revolución ágil.....................................................................................................65
Figura 40: Tablero Kanban....................................................................................................66
Figura 41: Método de desarrollo arquitectónico....................................................................71
Figura 42: Guías del ADM.....................................................................................................85
Figura 43: Técnicas ADM......................................................................................................86
Figura 44: Relaciones entre los productos arquitectónicos de TOGAF..................................87
Figura 45: Metamodelo de contenidos..................................................................................89
Figura 46: Continuum arquitectónico.....................................................................................90
Figura 47: Continuum de soluciones.....................................................................................90
Figura 48: Marco de capacidades arquitectónicas................................................................92
Figura 49: Modelo de referencia técnico...............................................................................93
Figura 50: Modelo de referencia de infraestructura integrada de información.......................94
Figura 51: Visión preliminar del marco arquitectónico propuesto........................................101
Figura 52: Iteración de capacidad arquitectónica del marco propuesto...............................102
Figura 53: Relaciones de los tableros de la Iteración de capacidad arquitectónica.............103
Figura 54: Cuadro resumen de los cambios de la fase preliminar.......................................120
Figura 55: Tablero Kanban de la fase preliminar.................................................................121
Figura 56: Cuadro resumen de los cambios de la fase A....................................................138
Figura 57: Tablero Kanban de la fase A...............................................................................139
Figura 58: Iteración de desarrollo arquitectónico.................................................................140
Figura 59: Relaciones de los tableros de la Iteración de desarrollo arquitectónico.............140
Figura 60: Tablero Kanban de las Fases B, C y D del marco propuesto..............................154
Figura 61: Cuadro resumen de los cambios de la fases B, C y D........................................155
Figura 62: Visión general del marco arquitectónico propuesto............................................156
Figura 63: Tablero Kanban del marco propuesto.................................................................157
Figura 64: Logo de la Cooperativa de transportes Loja.......................................................159
xiv
Figura 65: Cadena de valor orientada a servicios de la CTL...............................................161
Figura 66: Tecnología actual de la CTL...............................................................................163
Figura 67: Proceso operativo del servicio de transportes de la CTL....................................164
Figura 68: Fase preliminar del marco arquitectónico propuesto..........................................166
Figura 69: Marcos de gestión empresarial para la CTL.......................................................169
Figura 70: Proceso de gestión de proyectos.......................................................................176
Figura 71: Integración de TOGAF 9.1 y PMBOK.................................................................177
Figura 72: Método de gestión de portafolio de proyectos CREOPM...................................178
Figura 73: Proceso de gestión de riesgos de COSO II........................................................179
Figura 74: Integración de TOGAF e ITIL.............................................................................180
Figura 75: Integración de COBIT con otros marcos de gestión...........................................181
Figura 76: Modelo de supervisión de COBIT.......................................................................181
Figura 77: Cuadrante mágico de Gartner sobre ECM (2015)..............................................182
Figura 78: Estructura del repositorio arquitectónico de la CTL............................................184
Figura 79: Fase A: Visión arquitectónica del marco arquitectónico propuesto.....................185
Figura 80: Evaluación de las capacidades empresariales de la CTL...................................191
Figura 81: Diagrama de concepto de solución....................................................................193
Figura 82: Fases B, C y D del marco arquitectónico propuesto...........................................197
Figura 83: Modelo de referencia técnico de la CTL.............................................................199
Figura 84: Arquitectura de referencia SOA..........................................................................201
Figura 85: Relaciones de los tableros Kanban del marco propuesto...................................258
Figura 86: Método de desarrollo arquitectónico...................................................................264
Figura 87: Continuum empresarial de la Cooperativa de transportes Loja..........................268
Figura 88: Estructura del repositorio arquitectónico de la CTL............................................269
Figura 89: Unidades funcionales de la CTL.........................................................................280
Figura 90: Estructura de la gobernanza..............................................................................286
Figura 91: Estrategia de soporte para la gobernanza..........................................................287
Figura 92: Modelo de madurez de capacidades arquitectónicas (ACMM)...........................328
Figura 93: Nivel de madurez de BTM2................................................................................329
Figura 94: Modelo de negocio de la CTL.............................................................................336
Figura 95: Cadena de valor de la CTL.................................................................................338
Figura 96: Proceso de planificación de turnos de la CTL....................................................339
Figura 97: Arquitectura destino de la CTL...........................................................................340
xv
Figura 98: Modelo de referencia técnico de la CTL.............................................................371
Figura 99: Arquitectura de referencia SOA..........................................................................374
xvi
ÍNDICE DE TABLAS
Tabla 1: PYMEs en la zona de planificación 7.......................................................................17

Tabla 2: Penetración de las TIC's en el sector empresarial...................................................25
Tabla 3: Clasificación de marcos de referencia arquitectónicos............................................43
Tabla 4: Ontología empresarial Zachman..............................................................................53
Tabla 5: Evaluación de los principales marcos de referencia arquitectónicos........................60
Tabla 6: Descripción de la fase preliminar de TOGAF...........................................................73
Tabla 7: Artefactos de la fase preliminar de TOGAF..............................................................74
Tabla 8: Descripción de la fase A: Visión arquitectónica de TOGAF......................................75
Tabla 9: Artefactos de la fase A : visión arquitectónica de TOGAF.........................................76
Tabla 10: Descripción de fase B: Arquitectura de negocio de TOGAF...................................77
Tabla 11: Artefactos de la fase B : arquitectura de negocio de TOGAF..................................78
Tabla 12: Descripción de fase C: Arquitectura de datos de TOGAF.......................................79
Tabla 13: Artefactos de la fase C: Arquitectura de datos de TOGAF......................................80
Tabla 14: Descripción de fase C: Arquitectura de aplicaciones de TOGAF............................81
Tabla 15: Artefactos de la fase C: Arquitectura de aplicaciones de TOGAF...........................82
Tabla 16: Descripción de fase D: Arquitectura tecnológica de TOGAF..................................83
Tabla 17: Artefactos de la fase D: Arquitectura tecnológica de TOGAF.................................84
Tabla 18: Características de las PYMEs de la zona de planificación 7 del Ecuador..............97
Tabla 19: Características del marco arquitectónico propuesto..............................................99
Tabla 20: Características a desarrollar en las PYMEs.........................................................100
Tabla 21: Evaluación de los objetivos de la fase preliminar del marco propuesto...............105
Tabla 22: Evaluación de los pasos de la fase preliminar del marco propuesto....................106
Tabla 23: Evaluación de los artefactos de la fase preliminar................................................112
Tabla 24: Evaluación de los entregables de la fase preliminar.............................................112
Tabla 25: Productos arquitectónicos de la fase preliminar del marco propuesto..................115
Tabla 26: Evaluación del entregable Estructura del equipo de arquitectura empresarial.....116
Tabla 27: Estructura resultante del entregable Principios arquitectónicos...........................118
Tabla 28: Evaluación del entregable Marco arquitectónico adaptado..................................118
Tabla 29: Herramientas adicionales de la fase preliminar del marco propuesto..................119
Tabla 30: Evaluación de los objetivos de la fase A del marco propuesto.............................122
Tabla 31: Evaluación de los pasos de la fase A del marco propuesto..................................123
Tabla 32: Evaluación de los artefactos de la fase A.............................................................129
xvii
Tabla 33: Evaluación de los entregables de la fase A..........................................................129
Tabla 34: Productos arquitectónicos de la fase A del marco propuesto...............................131
Tabla 35: Estructura resultante del entregable Evaluación de capacidades........................132
Tabla 36: Evaluación del entregable Visión arquitectónica..................................................133
Tabla 37: Evaluación del entregable Enunciado del trabajo arquitectónico.........................134
Tabla 38: Herramientas adicionales de la fase A: visión arquitectónica...............................137
Tabla 39: Evaluación de los objetivos de la fases B, C y D.................................................141
Tabla 40: Evaluación de los pasos de la fases B, C y D......................................................142
Tabla 41: Evaluación de los entregables de las fases B, C y D...........................................147
Tabla 42: Productos arquitectónicos de las fases B, C y D del marco propuesto................147
Tabla 43: Evaluación del entregable Documento de definición arquitectónica.....................149
Tabla 44: Evaluación del entregable Especificación de requerimientos arquitectónicos......152
Tabla 45: Herramientas adicionales de las fases de B, C y D.............................................153
Tabla 46: Objetivos y metas estratégicas de la CTL............................................................167
Tabla 47: Catálogo de principios arquitectónicos de la CTL................................................172
Tabla 48: Mapa de interesados de la CTL...........................................................................186
Tabla 49: Evaluación de las capacidades de negocio de la CTL.........................................190
Tabla 50: Evaluación de las capacidades de datos de la CTL.............................................190
Tabla 51: Evaluación de las capacidades de aplicaciones de la CTL..................................191
Tabla 52: Evaluación de las capacidades tecnológicas de la CTL.......................................191
Tabla 53: Análisis de riesgos del proyecto arquitectónico....................................................195
Tabla 54: Componentes candidatos para la Hoja de ruta de la implementación..................203
Tabla 55: Iteración de capacidad arquitectónica de TOGAF................................................214
Tabla 56: Iteración de desarrollo arquitectónico..................................................................216
Tabla 57: Descripción de fase E: Oportunidades y soluciones de TOGAF...........................220
Tabla 58: Artefactos de la fase E: Oportunidades y soluciones de TOGAF..........................221
Tabla 59: Descripción de fase F: Planificación de la migración de TOGAF..........................222
Tabla 60: Artefactos de la fase E: Planificación de la migración de TOGAF........................223
Tabla 61: Iteración de transición arquitectónica...................................................................224
Tabla 62: Descripción de fase G: Gobernanza de la implementación de TOGAF................226
Tabla 63: Descripción de fase H: Gestión del cambio.........................................................228
Tabla 64: Iteración de gobernanza arquitectónica...............................................................229
Tabla 65: Descripción de gestión de requerimientos de TOGAF..........................................231
Tabla 66: Gestión de requerimientos...................................................................................232
Tabla 67: Guías para adaptar el proceso ADM....................................................................233
xviii
Tabla 68: Técnicas para el desarrollo arquitectónico...........................................................233
Tabla 69: Catálogos del método de desarrollo arquitectónico.............................................235
Tabla 70: Diagramas del método de desarrollo arquitectónico............................................237
Tabla 71: Matrices del método de desarrollo arquitectónico................................................240
Tabla 72: Entregables del método de desarrollo arquitectónico..........................................242
Tabla 73: Iteración de capacidad arquitectónica del marco de referencia adaptado............245
Tabla 74: Iteración de desarrollo arquitectónico del marco de referencia adaptado............247
Tabla 75: Evaluación de los artefactos de las fases B, C y D..............................................251
Tabla 76: Artefactos del contenido arquitectónico adaptado................................................265
Tabla 77: Entregables del contenido arquitectónico adaptado.............................................266
Tabla 78: Integración de TOGAF y PMBOK........................................................................270
Tabla 79: Integración de COBIT y TOGAF...........................................................................274
Tabla 80: Roles y responsabilidades del equipo de arquitectura empresarial......................281
Tabla 81: Matriz RACI del proyecto arquitectónico..............................................................284
Tabla 82: Plantilla para la definición de principios arquitectónicos.......................................292
Tabla 83: Principios arquitectónicos de la Cooperativa de transportes Loja........................293
Tabla 84: Principio de negocio: Planificación del negocio....................................................294
Tabla 85: Principio de negocio: Procesos simples y flexibles..............................................295
Tabla 86: Principio de negocio: Centrado en el cliente........................................................295
Tabla 87: Principio de negocio: Habilidades adecuadas......................................................296
Tabla 88: Principio de negocio: Maximización de beneficios para la empresa.....................296
Tabla 89: Principio de negocio: Independencia tecnológica................................................297
Tabla 90: Principio de datos: Flujos de información formalmente definidos.........................297
Tabla 91: Principio de datos: Alineación con las necesidades del negocio..........................298
Tabla 92: Principio de datos: Claridad y consistencia..........................................................298
Tabla 93: Principio de datos: Toma de decisiones...............................................................299
Tabla 94: Principio de aplicaciones: Arquitectura de aplicaciones.......................................299
Tabla 95: Principio de aplicaciones: Trazabilidad................................................................300
Tabla 96: Principio de aplicaciones: Flexibilidad..................................................................300
Tabla 97: Principio de aplicaciones: Consolidación.............................................................301
Tabla 98: Principio de aplicaciones: Orientada a la integración...........................................301
Tabla 99: Principio de aplicaciones: Orientada al servicio...................................................302
Tabla 100: Principio de aplicaciones: Interoperabilidad.......................................................302
Tabla 101: Principio de aplicaciones: Acceso a la información............................................303
Tabla 102: Principio de aplicaciones: Soluciones de código abierto....................................303
xix
Tabla 103: Principio de aplicaciones: Maximizar el retorno y minimizar el riesgo................304
Tabla 104: Principio de aplicaciones: Sistemas legados......................................................304
Tabla 105: Principio de aplicaciones: Disponibilidad de documentación.............................305
Tabla 106: Principio de aplicaciones: Seguridad.................................................................305
Tabla 107: Principio de tecnología: Responsables..............................................................306
Tabla 108: Principio de tecnología: Modelo empresarial de integración tecnológica...........306
Tabla 109: Principio de tecnología: Enfoque de métricas de nivel de calidad......................307
Tabla 110: Principio de tecnología: Mantenimiento de la infraestructura.............................308
Tabla 111: Principio de tecnología: Racionalización de productos y plataforma..................308
Tabla 112: Principio de tecnología: Selección de productos................................................309
Tabla 113: Principio de tecnología: Portafolio de productos................................................309
Tabla 114: Principio de tecnología: Reutilizar, comprar y luego construir.............................310
Tabla 115: Principio de tecnología: Criterios de seguridad..................................................310
Tabla 116: Modelo de evaluación de la capacidad del negocio...........................................316
Tabla 117: Modelo de evaluación de las capacidades de TI................................................319
Tabla 118: Modelo de madurez de la capacidad arquitectónica (ACMM)............................325
Tabla 119: Objetivos y metas estratégicas de la CTL..........................................................347
Tabla 120: Interesados del trabajo arquitectónico...............................................................350
Tabla 121: Plantilla del documento a completar en reuniones.............................................353
Tabla 122: Planificación de las comunicaciones del trabajo arquitectónico.........................354
Tabla 123: Análisis de riesgos del proyecto.........................................................................355
Tabla 124: Objetivos, metas y limitaciones del trabajo arquitectónico.................................363
Tabla 125: Conjeturas del trabajo arquitectónico.................................................................365
Tabla 126: Riesgos del trabajo arquitectónico.....................................................................366
Tabla 127: Problemas del trabajo arquitectónico.................................................................367
Tabla 128: Dependencias del trabajo arquitectónico...........................................................367
Tabla 129: Sistemas de la Cooperativa de transportes Loja................................................368
Tabla 130: Cadena de valor del servicio de transporte de la CTL.......................................369
Tabla 131: Matriz de interacción de aplicaciones................................................................370
Tabla 132: Análisis de brechas - negocio: estrategia...........................................................375
Tabla 133: Análisis de brechas - negocio: modelos empresariales......................................376
Tabla 134: Análisis de brechas - negocio: procesos............................................................376
Tabla 135: Análisis de brechas -negocio: roles, actores y habilidades................................377
Tabla 136: Análisis de brechas - negocio: comunicación.....................................................378
Tabla 137: Análisis de brechas - datos: componentes lógicos y físicos...............................378
xx
Tabla 138: Análisis de brechas - datos: administración, migración y gobernanza...............379
Tabla 139: Análisis de brechas – datos: toma de decisiones...............................................379
Tabla 140: Análisis de brechas - datos: seguridad de la información...................................380
Tabla 141: Análisis de brechas - aplicaciones: componentes lógicos y físicos....................381
Tabla 142: Análisis de brechas - aplicaciones: SOA............................................................382
Tabla 143: Análisis de brechas - aplicaciones: aplicaciones corporativas...........................382
Tabla 144: Análisis de brechas - aplicaciones: consideraciones de seguridad....................383
Tabla 145: Análisis de brechas - tecnología: plataforma, componentes y seguridad...........384
Tabla 146: Análisis de brechas - tecnología: estrategias de TI............................................384
Tabla 147: Análisis de brechas de arquitectura empresarial................................................385
xxi
RESUMEN
TOGAF es uno de los principales marcos de Arquitectura empresarial. Su objetivo primordial

es brindar un enfoque estructurado para garantizar que los proyectos de TIC's se ajusten a
los objetivos de negocio de la empresa. Es un marco ampliamente utilizado, aceptado y
reconocido como un modelo de la industria.
Las pequeñas y medianas empresas (PYMEs) se caracterizan principalmente por su

dinamismo, flexibilidad e innovación. Sin embargo, para que las PYMEs logren redes de
producción de mayor valor agregado, con innovaciones tanto en sus procesos como en sus
productos o servicios, deberán prepararse para un salto tecnológico.
El proceso de incorporación de infraestructura tecnológica en las PYMEs debe ser guiado

por un marco que asegure el alineamiento estratégico entre los objetivos del negocio y la
tecnología. La compleja estructura de TOGAF dificulta su implementación en este tipo de
empresas.
Por lo tanto, a partir del análisis de las características de las PYMEs y de los componentes
del documento TOGAF, el presente trabajo propone un marco de referencia de arquitectura
empresarial basado en TOGAF y adaptado a los requerimientos de las PYMEs.
PALABRAS CLAVES: TOGAF, ADM, arquitectura empresarial (AE), tecnologías de

información (TI), pequeñas y medianas empresas (PYMEs), capacidad arquitectónica,
desarrollo arquitectónico.
1
ABSTRACT
TOGAF is one of the leading enterprise architecture frameworks. Its primary objective is to
provide a structured approach to ensure that information technology projects meet the
enterprise business objectives. TOGAF is a framework widely used, accepted and
recognized as an industry model.
Small and medium enterprises (SME) are mainly characterized by dynamism, flexibility and
innovation. However, for SME achieve higher value added production networks, with
innovations in processes and products or services, they should be prepared for a
technological leap.
The process of incorporating technological infrastructure in SME should be guided by a

framework that ensures the strategic alignment between business goals and technology. The
complex structure of TOGAF hinders its implementation in these types of enterprises.
Therefore, based on the analysis of the characteristics of SME and the components of
TOGAF document, this document proposes a framework for enterprise architecture based on
TOGAF and adapted to the requirements of SME.
KEYWORDS: TOGAF, ADM, enterprise architecture (EA), information technology (IT), small
and medium business enterprises (SME), architecture capability, architecture development.
2
INTRODUCCIÓN
Durante los últimos años, las grandes empresas han priorizado el alineamiento estratégico
entre sus objetivos de negocio y tecnología. Como consecuencia de ello, han alcanzado
ventajas competitivas que van desde la incursión en nuevos mercados, optimización de
recursos y generación de mayores ingresos. Esto nos lleva a cuestionarnos: ¿las PYMEs
están preparadas para beneficiarse de este tipo de ventajas competitivas?.
En nuestra economía, las PYMEs son fundamentales para el desarrollo de la producción.

Sin embargo, la insuficiente participación de tecnología en sus procesos, no ha permitido
aprovechar eficientemente sus estructuras organizacionales, que se caracterizan por
adaptarse rápidamente a los cambios. Suárez (2010) explica que en este tipo de empresas
“los procesos de negocio son apoyados por componentes tecnológicos aislados; la
operación se centra en procedimientos y existen altos costos de integración de tecnologías
de información y comunicación”.
Arquitectura empresarial es una metodología de mejora continua que posibilita la alineación

entre tecnologías de información y negocio. Dentro de esta disciplina, el marco de referencia
TOGAF destaca por ser ampliamente acogido en empresas de todo el mundo. Este marco
arquitectónico apoya el establecimiento y aseguramiento de arquitecturas empresariales de
calidad. Sin embargo, TOGAF está orientado a empresas consolidadas, por lo que su
implementación en PYMEs deberá estar sujeta a una adaptación previa.
Con estos antecedentes, surge la necesidad de proponer un marco de referencia de

arquitectura empresarial que se adapte a las características y necesidades de las PYMEs.
En base al documento TOGAF (versión 9.1) y al enfoque ágil de arquitectura empresarial, se
definirán los principales elementos del marco de referencia arquitectónico adaptado.
Cuando se culmine el proceso de adaptación de TOGAF a los requerimientos de las PYMEs,

se elaborará una prueba de concepto. Se tomará como caso de estudio a la Cooperativa de
transportes Loja, cuyas características a nivel de infraestructura tecnológica se asemejan a
las identificadas en las PYMEs. El marco resultante permitirá definir la arquitectura
necesaria para soportar el primer segmento de la cadena de valor de la empresa.
3
El contenido del trabajo ha sido dividido en 5 capítulos, los mismos que se describen
brevemente a continuación:
El primer capítulo, titulado EMPRESA, abarca el estudio del concepto, funciones y

clasificación de las empresas. El análisis se centrará en las pequeñas y medianas empresas
de la zona de planificación 7 del Ecuador, a través del cual se logrará describir la percepción
de las PYMEs respecto a las tecnologías de la información y comunicación.
El segundo capítulo, denominado ARQUITECTURA EMPRESARIAL, explica los principales

conceptos referentes a la disciplina de investigación. Además, se efectúa un análisis de los
marcos de referencia arquitectónicos más relevantes y se describe el proceso de selección
del marco arquitectónico base.
En el tercer capítulo, CONCEPTUALIZACIÓN DE TOGAF, se desarrollará la

conceptualización del marco de referencia que nos servirá de base para la adaptación de
una solución orientada a PYMEs. Dentro de este capítulo, se explica a detalle los principales
componentes del documento TOGAF: conceptos básicos, método de desarrollo
arquitectónico (ADM, por sus siglas en inglés), fases, objetivos, pasos, productos
arquitectónicos, guías y técnicas, entre otros.
En el cuarto capítulo, PROPUESTA, se presenta el prototipo del marco de referencia

adaptado a PYMEs, detallando objetivos, pasos, productos arquitectónicos y herramientas
de apoyo por cada una de las fases que conforman las iteraciones de capacidad y desarrollo
arquitectónico.
Finalmente, en el quinto capítulo, PRUEBA DE CONCEPTO, se describirá la prueba de

concepto del marco arquitectónico propuesto, en un segmento de negocio de la cadena de
valor de la Cooperativa de transportes Loja, con el propósito de verificar su validez.
4
OBJETIVOS
Objetivo general.
• Adaptar, en base a ADM - TOGAF, un marco de referencia que se ajuste a las

necesidades de las PYMEs de la zona de planificación 7 del Ecuador.
Objetivos específicos.
• Realizar un análisis de los principales componentes de ADM - TOGAF, con el fin de

obtener los elementos necesarios para la adaptación de un marco de referencia
orientado a las necesidades de las PYMEs.
• Establecer las entradas, pasos, técnicas y productos arquitectónicos de las fases que
conforman las iteraciones de capacidad y desarrollo arquitectónico del marco de
referencia propuesto.
• Realizar una prueba de concepto del marco propuesto en un segmento de negocio
de la Cooperativa de transportes Loja.
5
CAPÍTULO 1: EMPRESA
1.1 Metodología de investigación.
A continuación, se describe la metodología de investigación empleada para desarrollar el

presente trabajo.
1.1.1 Enfoque metodológico.
Se ha definido al enfoque mixto como enfoque metodológico. Hernández, R., Fernández, C.,
& Baptista, P. (2006) describen al enfoque mixto como la combinación de las características
del enfoque cualitativo y cuantitativo. Además, explica que este enfoque permite la
aplicación de la deducción en la generación de hipótesis y la integración de la inducción en
los hallazgos.
En el diseño del marco de referencia arquitectónico propuesto, se implementará el enfoque

cuantitativo al recolectar y analizar datos, principalmente para determinar la realidad de las
empresas hacia las cuales está orientado el marco. En cambio, a través de descripciones y
observaciones propuestas por el método cualitativo, se formulará teorías para la resolución
de la problemática.
1.1.2 Método de investigación.
Para el desarrollo de la presente investigación se optó por el método empírico-analítico.

Este método representa un proceso de investigación en el cual los contenidos proceden
principalmente de la experiencia. Una de sus principales características es ser auto-
correctivo y progresivo, es decir las formulaciones se crean a partir de la superación gradual
de errores.
1.1.3 Fases de la investigación.
En base al método propuesto por Sánchez (2011), se han establecido las siguientes fases a
cumplir (Figura 1) para el proceso de adaptación del marco de referencia arquitectónico:
7
1. Planteamiento del problema: El primer paso al efectuar una investigación es definir
el planteamiento del problema. Este paso permitirá estructurar formalmente la idea
de la investigación y establecer los límites del proyecto.
2. Exploración de la información: Denominada también fase exploratoria, abarca la

revisión literaria sistemática de trabajos relacionados y fuentes de información que
aporten a construir la solución. En el documento, los capítulos 1, 2 y 3 hacen
referencia a conceptos y antecedentes necesarios para el desarrollo de la solución.
3. Diseño de la solución: Dentro de esta fase se procede a: a) Elaborar criterios de

evaluación que posibiliten la adaptación del método de desarrollo arquitectónico y del
marco de contenidos, a las características de las PYMEs identificadas en el capítulo
1. b) Evaluar los elementos del método de desarrollo arquitectónico y la estructura
del marco de contenidos. c) Definir los componentes del método de desarrollo
arquitectónico adaptado y la estructura de los principales productos arquitectónicos.
4. Prueba de concepto: Una prueba de concepto es la implementación parcial de la

solución propuesta, con el propósito de verificar que la teoría en cuestión es válida.
El capítulo 5 describe la validación realizada sobre el marco de referencia
arquitectónico propuesto.
5. Análisis de los resultados: Una vez que se ha desarrollado la investigación se

deben analizar y discutir los resultados. De acuerdo a Bernal (2000): “el análisis de
resultados consiste en interpretar los hallazgos relacionados con el problema de
investigación, objetivos propuestos e hipótesis formuladas, con la finalidad de
evaluar si se confirman las teorías o se generan debates con las teorías existentes”.
Figura 1: Metodología de la investigación.

Fuente: Sánchez (2011).
Elaboración propia.
8
1.2 Definición de empresa.
Las empresas son entidades que se constituyen como el motor de toda sociedad. Por esta
razón, es conveniente analizar las definiciones que han elaborado algunos autores referente
al concepto de empresa:
• El diccionario de la Real academia de la lengua española (2014) define a la empresa

como la “unidad de organización dedicada a actividades industriales, mercantiles o
de prestación de servicios con fines lucrativos”.
• De acuerdo a Pallares et al (2005), autor del libro titulado “Hacer empresa: un reto”,
la empresa puede ser considerada como “un sistema dentro del cual una persona o
grupo de personas desarrollan un conjunto de actividades encaminadas a la
producción y/o distribución de bienes y/o servicios, enmarcados en un objeto social
determinado”.
• Romero (1997), define a la empresa como “el organismo formado por personas,
bienes materiales, aspiraciones y realizaciones comunes para dar satisfacciones a
su clientela”.
Teniendo en cuenta las anteriores definiciones, se puede sintetizar que la empresa es una
unidad organizada, conformada por capital humano, bienes materiales y capacidades, que
permiten la producción de bienes y/o prestación de servicios para alcanzar los objetivos
iniciales planteados por la entidad.
1.3 Funciones de la empresa.
Fayol (1916), teórico clásico de la Administración, propuso seis funciones básicas que toda
empresa debería cumplir y que hoy en día aún se mantienen vigentes:
• Funciones técnicas: Funciones que se encuentran directamente ligadas con la

producción de bienes y/o prestación de servicios.
• Funciones comerciales: Funciones que se encuentran relacionadas con los
procesos de compra, venta e intercambio.
9
• Funciones financieras: Funciones que se encargan del manejo y gestión del
capital.
• Funciones de seguridad: Funciones que intentan garantizar el bienestar del
personal de la empresa.
• Funciones contables: Funciones que permiten el registro y control de los recursos
que maneja la empresa.
• Funciones administrativas: Funciones que permiten coordinar las anteriores
funciones descritas.
1.4 Clasificación de las empresas.
Las empresas pueden ser clasificadas de acuerdo a diversos criterios, dentro de los cuales
se han seleccionado los siguientes: tamaño o magnitud, actividades que desarrollan y origen
del capital.
1.4.1 De acuerdo a su tamaño o magnitud.
Dentro de esta clasificación se encuentran: micro-empresas, talleres artesanales, pequeñas

industrias, medianas industrias y grandes empresas.
Figura 2: Clasificación de empresas de acuerdo a su tamaño o magnitud.

Fuente: Código orgánico de la producción, comercio e inversiones (2013).
10
1.4.2 De acuerdo a la actividad que desarrollan.
Se pueden clasificar en:
• Comercial: Empresas dedicadas a entregar bienes desde el productor hacia el

intermediario o al consumidor. No realizan cambios sobre la naturaleza de los bienes.
• Industria: Empresas dedicadas a la transformación de bienes menores en mayores.
• Servicios: Empresas que prestan servicios con el fin de atender a necesidades.
• Financieras: Empresas cuya función es ser intermediarios financieros y prestar
servicios financieros y de negocios.
1.4.3 De acuerdo al origen del capital.
De acuerdo a esta clasificación las empresas pueden ser:
• Empresas públicas. Organizaciones en las cuales el capital le pertenece al Estado.

• Empresas privadas. Entidades en las cuales el capital proviene de particulares.
• Empresas mixtas. Empresas en las cuales la propiedad del capital es compartido
entre el Estado y particulares.
1.4.4 De acuerdo a la forma de organización del capital.
De acuerdo a este criterio las empresas pueden ser:
• Individuales. Empresas en las cuales el capital se conforma gracias al aporte de

solamente una persona natural.
• Sociedades. Empresas en las cuales el capital se conforma mediante el aporte de
varias personas naturales o jurídicas. A su vez, el artículo segundo de la Ley de
compañías del Ecuador (2014), distingue las siguientes sociedades mercantiles:
◦ Compañía en nombre colectivo.

◦ Compañía en comandita simple y dividida por acciones.
11
◦ Compañía de responsabilidad limitada.
◦ Compañía anónima.
◦ Compañía de economía mixta.
1.5 PYMEs en el Ecuador.
A continuación, se describe la situación actual de las PYMEs en nuestro país.
1.5.1 Definición de PYMEs.
El Servicio de Rentas Internas (2014) en su portal web, define a PYMEs como “el conjunto
de pequeñas y medianas empresas que de acuerdo a su volumen de ventas, capital social,
cantidad de trabajadores, y su nivel de producción o activos presentan características
propias de este tipo de entidades económicas.” En el Ecuador, los sectores económicos
sobre los cuales se desarrollan las PYMEs son los siguientes:
• Comercio al por mayor y menor.

• Agricultura, silvicultura y pesca.
• Industrias manufactureras.
• Construcción, transporte, almacenamiento, y comunicaciones.
• Bienes inmuebles y servicios prestados a las empresas.
• Servicios comunales, sociales y personales.
De acuerdo al directorio de empresas del año 2012, con el que cuenta el Instituto nacional
de estadísticas y censos (INEC), existen alrededor de 16000 PYMEs en nuestro país. Por lo
tanto, las PYMEs pueden ser consideradas como el motor de la economía ecuatoriana.
1.5.2 Situación actual de las PYMEs en el Ecuador.
Como se mencionó anteriormente, la actividad de las PYMEs en nuestro país es muy

relevante. Junto a las microempresas, conforman el sector empresarial más grande del país.
12
Con los datos ofrecidos por el SRI e INEC, se pudo realizar un análisis sectorial de las
PYMEs, el cual se lo presenta en la siguiente figura:
Figura 3: Distribución de empresas en el Ecuador.

Fuente: SRI (2015).
De la misma forma, se presenta a continuación la sectorización de las PYMEs.
Figura 4: Sectorización de las PYMEs en el Ecuador.

Fuente: SRI (2015).
13
Como se puede observar en la Figura 4, los sectores que destacan con un mayor número de
porcentaje de empresas (41%) son comercio y servicios. No es de sorprenderse, si en los
últimos años han sido consideradas como actividades principales en nuestro país. Las
actividades de servicios pueden desarrollarse con menores niveles de inversión, mientras
que las actividades de comercio se han visto beneficiadas gracias al incremento de
consumo y a los mejores ingresos de la población.
Independientemente del sector en el cual se encuentre una PYME, la empresa debería

apuntar a:
• Capacitación del personal, tanto a nivel gerencial como a nivel de mano de obra. De
esta manera se generan diferencias competitivas en la empresa.
• Búsqueda constante de nuevos mercados en los cuales se pueda ofrecer los
productos.
• Innovación, gracias a la adopción de nuevas tecnologías de trabajo.
En cuanto a la distribución geográfica de las PYMEs en el Ecuador, territorialmente se

ubican de la siguiente manera:
Figura 5: Distribución geográfica de las PYMEs.

Fuente: Superintendencia de compañías (2014).
14
1.5.3 Fortalezas de las PYMEs.
• Capacidad de generación de empleos.

• Capacidad de adaptación ante eventualidades externas al negocio.
• Rapidez en la toma de decisiones.
• Requieren menores recursos de inversión.
• Bajo costo en la implementación de infraestructura de TIC.
• Flexibilidad frente a los cambios.
1.5.4 Debilidades de las PYMEs.
• Insuficiente capacitación del capital humano.

• Poca capacidad de financiamiento.
• Insuficiente maquinaria y tecnología para la fabricación de productos.
• Falta de estrategias gerenciales.
• Falta de fomento a los créditos otorgados hacia este tipo de empresas.
• Solamente el 8% de las PYMEs logran exportar sus productos.
1.5.5 Aspectos legales de PYMEs.
Uno de los aspectos importantes en la constitución de una PYME es su formalización legal,

es decir la adopción de los instrumentos necesarios para el funcionamiento en una actividad
determinada. Los requisitos para la formalización dependerán del tipo de compañía que se
vaya a constituir.
De forma general, se debe conocer que para la constitución de las compañías, se debe
tener capacidad civil para contratar, no se lo puede realizar entre padres e hijos no
emancipados ni entre cónyuges, se debe operar bajo una razón social que no estuviere
registrada previamente en la Superintendencia de compañías y se debe tener en el país un
asesor legal que pueda representar a la empresa, responder por demandas y cumplir con
obligaciones para el cumplimiento de su objeto social.
15
Gracias a la formalización de la empresa, se obtendrán ventajas como el mejoramiento de la
imagen corporativa, posicionamiento empresarial, acceso a créditos, ingreso a nuevos
mercados, sostenibilidad financiera y rentabilidad.
1.5.6 Órganos de regulación de PYMEs.
A continuación, se describen los principales órganos de regulación de las PYMEs.
1.5.6.1 Superintendencia de compañías.
La Superintendencia de compañías es el único organismo controlador de las compañías

mercantiles. Se define como “el organismo técnico, con autonomía administrativa y
económica, que vigila y controla la organización, actividades, funcionamiento, disolución y
liquidación de las compañías y otras entidades en las circunstancias y condiciones
establecidas por la Ley”. (Superintendencia de Compañías, 2014).
1.5.6.2 Cámaras de la industria y producción.
Agrupa a un sector fundamental para el desarrollo y crecimiento de la economía nacional.

Este tipo de instituciones son líderes en la representación gremial, comprometidas con el
desarrollo del país y la generación de empleo.
1.5.6.3 Código orgánico de la producción.
Normativa sobre la cual se regirán todas las personas naturales y jurídicas y demás formas
asociativas que desarrollen una actividad productiva.
1.5.6.4 Ley de Compañías.
Es el marco jurídico bajo el cual funcionan las empresas legalmente constituidas en el

Ecuador.
16
1.5.6.5 Código de comercio.
Rige contratos de comercio y obligaciones de los comerciantes en sus operaciones

mercantiles. Además, rige los actos y contratos comerciales desarrollados por individuos
categorizados como no comerciantes.
1.5.7 PYMEs en la zona de planificación 7.
En nuestro país, la zona de planificación 7 está conformada por las siguientes provincias: El
Oro, Loja y Zamora Chinchipe. Este territorio está limitado de la siguiente manera: con
Guayas, Azuay y Morona Santiago, al norte; con Perú, al sur y al este; y con el Océano
Pacífico y Perú, al oeste.
La zona de planificación 7 tiene una superficie de 27.368,26 km², correspondiente al 11% del
territorio ecuatoriano. Habitan 1'126.508 personas, que corresponden al 7,87% de la
población nacional. Registra alrededor de 642 PYMEs, las cuales se encuentran distribuidas
de la siguiente manera:
Tabla 1: PYMEs en la zona de planificación 7.
Provincia Cantidad
El Oro 487
Loja 187
Zamora Chinchipe 8
Total 642
Fuente: Superintendencia de Compañías (2014).

Como se puede observar en la Tabla 1, la provincia de El Oro es aquella que tiene mayor
número de PYMEs (487), mientras que Loja aporta con 187 PYMEs y Zamora Chinchipe con
tan sólo 8.
17
Figura 6: Actividades económicas de las PYMEs de la zona de planificación 7.
Fuente: Superintendencia de Compañías (2014)
Como se observa en la Figura 6, la actividad económica con mayor importancia dentro de

las pequeñas y medianas empresas de la zona de planificación 7 es la que engloba a
labores de agricultura, ganadería, silvicultura y pesca, que corresponden a la naturaleza
productora típica y característica de las provincias que conforman la región sur de nuestro
país.
De la misma manera, se puede apreciar que el comercio al por mayor y menor, es una de
las actividades económicas con mayor preferencia en la zona de planificación 7. La razón
principal de que el comercio tenga un importante peso en el porcentaje de actividades
económicas de la región, se debe fundamentalmente a las insuficientes capacidades
profesionales y tecnológicas que limitan a las empresas en el proceso de incursión en
nuevas fuentes productivas.
Mencionar también, que en cuanto a los tipos de compañías de las PYMEs de la zona 7,
existen dos tipos que prevalecen: las compañías de responsabilidad limitada y las
compañías anónimas. En la Figura 7, se presenta el detalle de los tipos de compañía de la
zona de planificación 7.
18
Figura 7: Tipos de compañías de la zona de planificación 7.
Fuente: Superintendencia de compañías (2014)
1.6 Percepción de TIC's en las PYMEs.
A continuación, se describe qué percepción tienen las PYMEs respecto de las TIC's.
1.6.1 Introducción.
La Organización para la cooperación y desarrollo económico (OCDE, 2010) define a las

TIC's como: “aquellos dispositivos que capturan, transmiten y despliegan datos e
información electrónica y que apoyan el crecimiento y desarrollo económico de la industria
manufacturera y de servicios”.
En cambio, el Centro para el desarrollo de las telecomunicaciones de Castilla (CEDETEL,

2004), indica que: “las tecnologías de la información y comunicación (TIC), constituyen la
19
herramienta más valiosa con la que cuentan las empresas a la hora de adaptarse a las
exigentes condiciones del mercado actual, permitiendo obtener ventajas competitivas y, por
lo tanto, diferenciarse del resto”.
Dentro de los procesos de desarrollo, las TICs tienen roles fundamentales, siendo el más
importante su capacidad para realizar transferencia de información, de manera que las
empresas manejen niveles de información creciente y constante. En la actualidad, es poco
común una cadena de producción donde no se haga uso de dispositivos electrónicos, pues
esto implicaría una actividad netamente artesanal y significaría una reducción en la
capacidad competitiva de la empresa.
Porter (2002), señala que “las empresas pueden ser más productivas en un sector si
emplean métodos especializados y tecnología avanzada”. Es decir, la tecnología es un
importante aliado para el desarrollo de las empresas, constituyéndose como uno de los
pilares en los procesos de producción y cadena de valor de la empresa.
1.6.1.1 Adopción de TIC's en las PYMEs.
Pérez, M., Sánchez, A., Carnicer, M., & Jiménez, M. (2004) expresan que “en comparación
con las grandes empresas, la gestión de las TIC's en las PYMEs es una cuestión que tiene
una menor importancia estratégica”. Es decir, en el caso particular de los países de nuestra
región, la falta de políticas industriales que fomenten la investigación no permite que las
PYMEs puedan contar con herramientas tecnológicas que mejoren su producción.
Debido a que no se han desarrollado las condiciones necesarias para la que la tecnología se
cree o se transfiera, las PYMEs tienen muy poco uso de las TIC. Por lo que muchas de ellas
se ven limitadas en aspectos de competitividad.
Cabe destacar que la utilización de este tipo de herramientas dependerá fundamentalmente

de las necesidades y conocimientos del personal directivo respecto a las TIC's. Pérez et al
(2004), lo explican de la siguiente manera: “la adopción de las TIC está, por tanto,
relacionada, entre otros factores, con el nivel previo de uso de las TIC, con el nivel formativo
del personal directivo y de los empleados/as de la PYME, con la adopción de innovaciones
(cambios) organizativas y con el apoyo”.
20
1.6.2 Incorporación de las TIC's en el sector productivo.
Como se ha venido mencionando anteriormente, gracias a la utilización de TIC's es posible

conseguir aumentos de la productividad y mejoras en el desempeño de las empresas si al
mismo tiempo también se consideran algunos cambios en la organización de la empresa, en
la gestión de los recursos humanos, además de mejorar el entorno regulatorio relacionado
con la tecnología donde las empresas se desenvuelven.
La transformación en la estructura organizativa de la empresa, la adopción de nuevos

modelos de negocios, capacidad de inversión en tecnología, habilidades del recurso
humano, son algunos factores que determinan los distintos niveles de complejidad que una
empresa podría encontrar al momento de incorporar soluciones o aplicaciones basadas en
TIC. La utilización de las aplicaciones también implica diferentes cambios en la gestión de la
empresa, además de la realización de inversiones.
Figura 8: Factores para la incorporación de las TIC.

Fuente: MINTEL en base a Rovira (2013).
Adaptado de Rovira.
21
El Ministerio de telecomunicaciones (MINTEL) basándose en Rovira (2013), resume en la
anterior figura los factores determinantes para la incorporación de las TIC's en las empresas.
Rovira (2013), elaboró el modelo de apropiación de las TIC's en las empresas como un
proceso de adopción evolutiva, con umbrales mínimos de infraestructura tecnológica para
saltar a etapas más avanzadas (puede ser ajustado a la realidad ecuatoriana). Superar una
fase y entrar en la siguiente requiere superar ciertos niveles de complejidad asociados a las
capacidades y la organización de las empresas.
Figura 9: Etapas de la incorporación de las TIC's en las empresas.

Fuente: Rovira (2013).
Adaptado de Rovira.
1.6.3 Situación actual de las TIC's en las PYMEs de nuestro país.
De acuerdo al reporte “Situación de las TIC en las PYMEs del Ecuador”, realizado por el
Ministerio de Industria y productividad (MIPRO), con apoyo de AESOFT, CEPAL e
IMAGINAR; revelan algunos datos interesantes respecto a la percepción de las TIC's en las
PYMEs. Respecto al porcentaje de pequeñas y medianas empresas que tienen un
departamento de TIC (Figura 10), se puede decir que un 78% de las mismas indican que no
lo tienen.
22
Figura 10: Existencia de departamento de TIC
Fuente: MIPRO (2012).
Del porcentaje de empresas que indicaron tener un departamento de TIC, la mayor parte de
las mismas señalan no contar con personal calificado en esta rama, o si lo tienen el número
es realmente mínimo.
Figura 11: Número de personal de TIC.

23
Respecto a temas de conectividad, la mayor parte de las PYMEs tienes acceso a
interconectividad y redes.
Figura 12: Interconectividad y redes.

Un dato que también se puede considerar relevante, es el nivel de conocimiento que el

gerente de la PYME puede tener respecto a TIC's. De acuerdo a los resultados, se evidencia
que gran parte de los gerentes no cuentan con un alto conocimiento de las tecnologías de
información y comunicación.
Figura 13: Nivel de conocimiento respecto a TIC del gerente.

Elaboración propia
24
Por último, un importante dato que arroja el estudio realizado por el MIPRO es la actividad a
la cual está destinado el software con el que cuentan en las empresas.
Figura 14: Software en las empresas.

Adaptado de MIPRO.
Otro estudio respecto a la penetración de las TIC's en el sector empresarial fue desarrollado
por el Ministerio de telecomunicaciones1, cuyos resultados se resumen en la siguiente tabla:
Tabla 2: Penetración de las TIC's en el sector empresarial.
Uso de TIC's Porcentaje (%)
Proporción de empresas que utilizan computadoras. 80,9
Proporción de empresas que utilizan Internet. 87,2
Proporción de empresas con presencia en la Web. 36,5
Proporción de empresas con Intranet. 49,5
Proporción de empresas que reciben pedidos por Internet. 52,3
Proporción de empresas que utilizan banda ancha fija. 99,25
Proporción de empresas que utilizan banda ancha móvil. 0,75
1 Encuesta sobre TICs a nivel empresarial. Disponible en:

http://www.industrias.ec/archivos/CIG/file/CARTELERA/MINTEL-TIC%20para%20el%20Desarrollo.pdf
25
Uso de TIC's Porcentaje (%)
Proporción de empresas que utilizan banda angosta. 0
Proporción de empresas con red de área local (LAN). 52,4
Uso de Internet: banca electrónica/servicios financieros. 73,35
Uso de Internet: capacitación de personal. 20,65
Uso de Internet: contratación interna/externa. 15,75
Uso de Internet: enviar/recibir correo electrónico. 93,2
Uso de Internet: interacción con organizaciones gubernamentales. 61,5
Uso de Internet: obtener información de bienes y servicios. 83,7
Uso de Internet: proveer servicios a clientes. 39,5
Uso de Internet: uso de videoconferencias. 22,9
Fuente: MINTEL (2013).

A partir de la anterior tabla, se puede observar que el uso característico de las tecnologías
de información y comunicación a nivel empresarial, es el de enviar y recibir correos
electrónicos. Además, se puede notar que es bajo el porcentaje de empresas que cuentan
con presencia web.
Figura 15: Importancia de TIC's en las empresas.

26
La opinión de que el uso de TIC's en las empresas es importante para la productividad, es
mayoritaria en casi todas las PYMEs, como se puede evidenciar en la figura 15. Además, en
relación a los beneficios de las TIC para el mejoramiento de los resultados empresariales,
las valoraciones más altas están asociadas con un impacto positivo para la gestión de la
empresa y con la diferenciación de la competencia, como se presenta en la figura 16.
Otro 18.18
Ninguno 30
Procesamiento interno 37.5
Oportunidades de negocio local 41.09
Productividad de empleados 41.77
Oportunidades de negocio internacional 42.34
Incremento de ventas 42.63
Reducción de costos 44.03
Diferenciarse de la competencia 46.3
Mejorar gestión de la empresa 49.01
0 5 10 15 20 25 30 35 40 45 50
Figura 16: Beneficio de las TIC para el mejoramiento de los resultados empresariales.
Elaboración: MINTEL
En resumen, la situación actual de Ecuador, como ya se ha explicado, muestra una

capacidad limitada de absorber tecnología, producto de la falta de una cultura de extensión
tecnológica y de un cierto desconocimiento de las posibilidades para acceder y utilizar en su
provecho las nuevas tecnologías. Estas deficiencias se reflejan en la escasa producción de
bienes con alto contenido tecnológico o bienes intangibles, susceptibles de ser protegidos
mediante derechos de propiedad intelectual, como es el caso del software.
27
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL
2.1 Conceptos previos.
En esta sección, se describen algunos conceptos previos que permitirán el entendimiento de

arquitectura empresarial.
2.1.1 Dimensionamiento.
El diccionario de la Real academia de la lengua española (2014), define al

dimensionamiento como: “dar mayor dimensión o importancia a algo, generalmente
inmaterial”. Es decir, cuando en arquitectura empresarial nos referimos a dimensionamiento
se pretende indicar que existirán cambios que buscan el mejoramiento íntegro de una
organización.
Rodríguez (2011), explica que se puede abordar el enfoque de una organización desde tres
vistas complementarias:
• Dimensionamiento por benchmarking, el cual:
◦ Aporta: rapidez, reflexión, visión limitada, abaratamiento del proceso de

comparación.
◦ Introduce: primer filtrado y foco en áreas con mayores brechas, posibles no
uniformidades de referencia para reflexión.
◦ Requiere: alta capacidad de adaptación a la realidad de la compañía.
• Dimensionamiento por procesos, el cual:
◦ Aporta: visión global, análisis riguroso, comparativos adecuados.

◦ Introduce: conocimiento uniforme de las tareas que se realizan, priorización,
cuadro para la toma de decisiones objetivas.
◦ Requiere: comprensión profunda de las tareas, misión y procesos, entrevistas y
cuestionarios.
29
• Dimensionamiento por capacidades, el cual:
◦ Aporta: visión global, análisis estratégico, relación general organizativa

(responde a un modelo integral de recursos humanos).
◦ Introduce: conocimiento uniforme entre estructura, procesos y personas; cuadro
de mando, optimización.
◦ Requiere: participación plena de la alta dirección, planificación del proceso de
cambio, mayor capacidad de información y análisis, alto coste y desarrollo largo,
procesos muy sensibles.
Todos los componentes del dimensionamiento empresarial, se resumen en la siguiente

figura:
Figura 17: Dimensionamiento empresarial.

Fuente: Rodríguez (2011).
Adaptado de Rodríguez.
2.1.2 Transformación empresarial.
La aplicación de la tecnología en las empresas, es quizás un factor clave para la

supervivencia de las mismas. Poco a poco, diversas organizaciones optan por digitalizar sus
productos, servicios y ofertas. Esto permite que las empresas logren optimizar sus
operaciones, generen nuevas oportunidades de negocio y obtengan ventajas competitivas.
30
La tecnología, sin duda alguna, es el medio a través del cual las empresas logran adoptar
nuevos modelos de negocio, se abren paso en nuevos mercados y mejoran su
competitividad.
De acuerdo a Basole & Demillo (2006), es evidente que con el pasar de los años, la
tecnología y el negocio cada vez están más vinculados. Por ejemplo, las estrategias
empresariales, procesos y servicios de negocio están estrechamente relacionados con la
plataforma tecnológica de la empresa. Por lo tanto, cualquier cambio en uno de estos
elementos, requerirá cambios en los otros.
Si una organización decide emprender un proceso de transformación empresarial, deberá

considerar sus capacidades (actuales y futuras) de TI, y alinearlas con la planificación
estratégica empresarial. Rara vez, las empresas que inician proyectos de transformación,
no generan cambios sobre la estructura de sus sistemas y procesos. Por lo tanto, el grado
en que una organización emerge con éxito de un proceso de transformación empresarial
depende, en gran medida, de que si los elementos claves que generan valor han sido
conservados o redefinidos.
Popescu et al (2014), expresan que “la transformación empresarial se determina por las
deficiencias de valor (definidas en relación con el estado actual y futuro) y consiste
principalmente en examinar y cambiar los procesos clave de la empresa.” Por lo tanto, el
análisis de las deficiencias de valor permitirá identificar potenciales impactos en el estado
futuro requerido por la empresa. Además, se logrará proyectar posibles consecuencias
(positivas y negativas) de la transformación que influirán en las inversiones y asignaciones
de recursos.
2.1.2.1 Marcos de referencia para transformación de empresas.
Los marcos de transformación de empresas definen un conjunto de prácticas, criterios,

estrategias, modelos y literatura que guiarán a las organizaciones en proyectos de
transformación de sus negocios. A continuación, se repasa algunos de los principales
marcos de transformación empresarial que podrían ser empleados por las pequeñas y
medianas empresas.
31
2.1.2.1.1 Marco de transformación de Venkatraman.
El modelo de alineación estratégica de Venkatraman es un marco de transformación clásico

que permite la conjugación de Negocio y estrategias de TIC's. A pesar de ser un marco que
tiene más de 10 años de vigencia (1994), los conceptos que expone aún cuenta con validez
en la actualidad.
Venkatraman reconoce que las TIC's juegan un papel preponderante para que las empresas
puedan responder a las características de los mercados dinámicos. El marco se centra en la
organización y cambios en los procesos de gestión necesarios para explotar las TIC's. Su
tesis central es que los beneficios de las TIC's se limitan, a menos que las estructuras
organizativas se sometan a cambios que permitan gestionar la respuesta empresarial. (Levy
& Powell, 2004).
Aunque no se propone un modelo incremental, se reconoce qué beneficios potenciales

aumentan de nivel en nivel. Los costos asociados con el cambio en cada nivel aumentan y
las empresas deben tener en cuenta su valor.
Figura 18: Marco de transformación de negocios de Venkatraman.

Fuente: Levy & Powell (2004).
Adaptado de Levy & Powell.
32
2.1.2.1.2 Business transformation management methodology.
Business transformation management methodology (BTM2) proporciona un marco general

para las diferentes disciplinas de gestión y ofrece los vínculos necesarios entre las
disciplinas de gestión, liderazgo, cultura y comunicación que permitirán al proceso de
transformación ser eficaz. Debe ser adaptado a la empresa en particular mediante el uso de
la experiencia de las personas involucradas. Se recalca que cada empresa y cada
transformación del negocio es diferente. (Uhl & Gollenia, 2012).
El primer pilar de este marco (Figura 19) se ocupa de las disciplinas de gestión, que se
integran de manera coherente dentro de este enfoque. Incluye varias disciplinas de gestión:
estrategia, calidad, riesgos, procesos de negocio, programas y proyectos, transformación de
TI, cambio organizacional, y gestión de competencias y formación.
Figura 19: Marco de transformación BTM2.

Fuente: Uhl & Gollenia (2012).
Adaptado de Uhl & Gollenia.
33
El segundo pilar es el ciclo de vida de transformación (Figura 20) que ofrece un mapa del
territorio de cambios y permite comprender la naturaleza iterativa de la transformación.
Figura 20: Ciclo de vida de la transformación.

El tercer pilar es el liderazgo (Figura 21). La base para el liderazgo es la construcción de una
organización que pueda alcanzar de manera efectiva sus objetivos. Las cuatro fases del
ciclo de transformación empresarial son ejecutadas por los siguientes roles de gestión:
Figura 21: Roles de gestión de Business transformation management methodology.

34
2.1.2.1.3 Marco de transformación de negocios electrónicos en PYMEs.
Kapurubandara (2009), en una de sus diversas investigaciones en países en vías de

desarrollo, ha identificado barreras tanto dentro como fuera de las PYMEs (políticas,
culturales, legales, de infraestructura, relacionadas con las características de la empresa y
personal) las mismas que dificultan el proceso de adopción de tecnologías. Expresa que,
para que una pequeña y mediana empresa implemente con éxito las tecnologías y marcos
de transformación empresarial, las barreras identificadas deberán ser abordadas y
superadas.
Tomando en consideración lo anterior, se resume el contenido del marco de transformación

en la siguiente figura:
Figura 22: Marco de transformación de negocios en países en vías de desarrollo.

Fuente: Kapurubandara (2009).
Adaptado de Kapurubandara.
35
2.1.2.1.4 Business transformation enablement program.
El programa de capacitación de transformación de negocios del Gobierno de Canadá

(BTEP, por sus siglas en inglés) proporciona orientación sobre cómo identificar los
problemas relacionados con la transformación de negocio. Permite obtener un profundo
entendimiento de los desafíos y oportunidades que se pueden presentar en el proceso de
transformación empresarial (Dico, 2012).
BTEP recomienda que todos los proyectos desarrollen una evaluación de la transformación.
Esta evaluación se basa en la determinación y el análisis/calificación de una serie de
factores de preparación. El resultado es una comprensión profunda de los desafíos y
oportunidades que podrían presentarse en el transcurso de la transformación empresarial.
Muchos de los desafíos se traducen directamente en riesgos que tienen que ser abordados,
vigilados y, si es posible, mitigados. La metodología que propone BTEP es la siguiente:
1. Determinar factores de preparación: Se deberá establecer qué factores tendrán

impacto en el proceso de transformación empresarial asociado con la migración de
arquitecturas base a destino.
2. Presentar factores de preparación: Una vez que se han determinado los factores,
es necesario presentarlos de tal manera que se facilite su evaluación y el valor
máximo se derive de los participantes. Se recomienda utilizar modelos de madurez.
3. Evaluar factores de preparación: Los factores deberán ser evaluados en una

discusión multidisciplinaria. La evaluación deberá abordar: visión, grado de
calificación, riesgos y acciones a ser tomadas para cada factor.
4. Planificar la preparación y migración: Los resultados de la evaluación permitirán

planificar la migración estratégica y serán un aporte importante para desarrollar el
Plan de implementación y migración.
5. Difundir el plan de implementación: Se deberán planificar reuniones para informar

sobre el proceso de transformación empresarial, a razón de crear conciencia y
cultura respecto del trabajo a realizarse en la empresa.
36
2.2 Arquitectura empresarial.
Arquitectura empresarial es un concepto que con el transcurrir de los años, ha despertado

un gran interés en una cantidad considerable de organizaciones y empresas. Por ello, no es
de sorprenderse que consultoras de prestigio como Gartner Inc. (2014), año tras año
informen que herramientas y soluciones de arquitectura empresarial lideran las tendencias
de sus famosos “cuadrantes mágicos”. La razón es simple: el proceso de adopción de este
tipo de herramientas es una medida que toman las empresas para lograr ventajas
competitivas.
Toda empresa se plantea metas y objetivos a cumplir. Es decir, realizan una reflexión de sus
capacidades y trazan la dirección por la cual han de dirigir sus acciones. Sin embargo, en el
trayecto hacia el futuro deseado surge un número considerable de interrogantes respecto a
la manera en que se deberán cumplir los objetivos estratégicos empresariales. Por ejemplo,
la organización deberá dar respuesta a: ¿se ha logrado maximizar los resultados
esperados?, ¿se tiene un verdadero control sobre los elementos que conforman la
organización?, ¿la tecnología con la que se cuenta, realmente aporta al logro de los
objetivos planteados?.
No podemos aventurarnos a elaborar proyectos que intenten acercarnos hacia la

satisfacción de objetivos definidos, si no conocemos a detalle el entorno y la situación actual
en la que está inmersa la empresa. Por tal motivo, es vital el desarrollo de arquitecturas
empresariales, que gracias a la definición de una línea base y a las estrategias de negocio
adoptadas, permitirán la identificación de brechas y escenarios operativos necesarios para
lograr la arquitectura destino deseada.
Directores ejecutivos de todo el mundo piensan que la clave del éxito de sus negocios radica
en la necesidad de una correcta gestión y explotación de la información. El desarrollo de
arquitecturas empresariales busca solventar dichas necesidades, proporcionando marcos y
directrices estratégicas para la evolución de sus sistemas tecnológicos que responderán a
entornos empresariales cambiantes. Estas directrices deben estar basadas en la misión y
visión de la empresa, y fundamentalmente en el reconocimiento de las estrategias y
procesos que soportan dicha visión.
37
2.2.1 Definición de arquitectura empresarial.
Peter Weill (2007), investigador del MIT Sloan Center for Information Systems Research,
define a la arquitectura empresarial como “la lógica organizacional para procesos de negocio
claves e infraestructura de TI, que refleja la estandarización e integración del modelo de
negocio de una compañía”. De la misma forma, Gartner manifiesta que "arquitectura
empresarial es el proceso de traducir la visión y estrategia de negocio en un cambio
empresarial eficaz, mediante la creación, comunicación, y mejora de los principios y
modelos claves de la empresa" (citado por Op't Land 2008).
Bernard (2012), engloba en una ecuación los elementos esenciales del concepto de
arquitectura empresarial. Su fórmula: arquitectura empresarial = estrategia + negocio +
liderazgo (Figura 23), ha sido complementada con el factor tecnología e intenta diferenciar a
los marcos de arquitectura empresarial de los marcos de planificación de TI, explicando que
la arquitectura empresarial está impulsada por objetivos estratégicos y requerimientos de
negocio.
Figura 23: Ecuación de arquitectura empresarial

Fuente: Bernard (2012).
Adaptado de Bernard.
Arquitectura empresarial es un proceso estandarizado que se sustenta a través de un

programa de gestión. Esta disciplina provee estrategias y un enfoque basado en impulsores
de negocio que permite regular, planificar, tomar decisiones y cuantificar recursos. Para que
el proceso de arquitectura empresarial sea efectivo, deberá formar parte de un grupo de
buena prácticas de gestión que formen una estructura de gobernanza integrada (Figura 24).
En resumen, gracias a arquitectura empresarial se intenta ofrecer un conjunto de estrategias

de negocio que permitan conocer las capacidades actuales de una empresa, con el objetivo
de replantear sus modelos y procesos para lograr la evolución de la organización y el
cumplimiento de sus metas.
38
Figura 24: Principales áreas de Gobernanza integrada.
2.2.2 Perspectivas de arquitectura empresarial.
Bernard (2012) explica que la arquitectura empresarial puede ser vista desde dos
perspectivas:
• Como un programa de gestión.

• Como un método de análisis y diseño iterativo.
Como un programa de gestión, la arquitectura empresarial provee:
• Alineación estratégica: Conecta objetivos, actividades y recursos.

• Regulaciones estandarizadas: Gobernanza e implementación de recursos.
• Soporte a las decisiones: Control financiero y gestión de la configuración.
• Monitoreo de los recursos: Enfoque de ciclo de vida para el desarrollo y la gestión.
39
Como un método de análisis y diseño, la arquitectura empresarial provee:
• Enfoque de arquitectura empresarial: Marco de referencia, método de análisis y

diseño, y conjunto de artefactos.
• Vistas actuales: Vistas de estrategias del estado actual, procesos y recursos.
• Vistas futuras: Vistas de estrategias del estado futuro, procesos y recursos.
• Plan de gestión de arquitectura empresarial: Plan para migrar del estado actual al
estado futuro.
2.2.3 Marcos de referencia de arquitectura empresarial.
Los marcos de arquitectura empresarial dictan “un conjunto de condiciones, conceptos,

valores y prácticas para modelar la realidad de las organizaciones” (Fishman, 2003). Es
decir, son los encargados de ofrecer directrices y guías para aplicar las estrategias de
arquitectura empresarial en las organizaciones; cada cual con su propia estructura y
aplicando diferentes estrategias y modelos de AE.
Bernard (2012) resume el enfoque que los marcos de referencia de arquitectura empresarial
ofrecen a las empresas:
Figura 25: Enfoque de los marcos de arquitectura empresarial.

40
2.2.3.1 Evolución de los marcos de referencia arquitectónicos.
A partir de 1980, los avances tecnológicos de la época incrementaron la complejidad de los

sistemas de información. Por lo tanto, existía la necesidad de desarrollar estructuras que
integren y gestionen los componentes de dichos sistemas. Como lo menciona Schekkerman
(2004), John Zachman, mientras laboraba en la empresa consultora IBM 2, inserta por
primera vez el concepto de Arquitectura empresarial.
El marco de referencia de arquitectura empresarial propuesto por Zachman (1987) es una

analogía a la transcripción de requisitos para desarrollar construcciones. Aporta una visión
sistemática de los elementos que intervienen en los sistemas de información. Como su autor
lo expresa, no es una metodología, mas bien es una ontología que describe un modelo
empresarial integral.
Durante los siguientes años, existieron diversas iniciativas promovidas por el Gobierno
federal de Estados Unidos. Es así, que en 1989 nace el modelo de referencia NIST, que
agrega la idea de segmentación de la arquitectura en dominios, los cuales eran: arquitectura
de negocios, arquitectura de información, arquitectura de sistemas de información,
arquitectura de datos y sistemas de administración de datos.
Los modelos de referencia NIST, EAP y TAFIM TRM aportaron conceptos que permitirían al
Consorcio “The Open Group”, en el año 1995, elaborar la primera versión del marco de
referencia TOGAF. Este marco se constituiría en la base de futuros trabajos sobre
Arquitectura empresarial.
Nuevas investigaciones del Gobierno federal de Estados Unidos, permitieron la creación de

los marcos de referencia FEAF (1999), TEAF (2000) y DoDAF (2003). Estos marcos
conservaron la idea de segmentación en dominios de la arquitectura, reforzaron ideas
previas e introdujeron nuevos conceptos y modelos de referencia. A partir del año 2005, se
han desarrollado extensiones y versiones híbridas de los marcos anteriormente
mencionados. De esta manera, surgen los modelos de referencia Gartner (2005), SAP EAF
(2007) y ORACLE EAF (2009).
2 International Business Machines Corp. (IBM). Empresa de tecnología y consultoría.
41
Cabe destacar, que algunos de los marcos descritos anteriormente aún se encuentran en
vigencia y se han desarrollado nuevas versiones de los mismos, mientras que otros han ido
desapareciendo con el transcurrir de los años. A continuación, se ilustra la evolución que
han tenidos los marcos de referencia de Arquitectura empresarial, desde el año 1987 hasta
la actualidad.
Figura 26: Evolución de los marcos de referencia de arquitectura empresarial.

Fuente: Schekkerman (2004).
Adaptado de Schekkerman.
2.2.3.2 Clasificación de los marcos de referencia arquitectónicos.
Luego de haber revisado la evolución histórica de los marcos de referencia de arquitectura

empresarial, a continuación se muestra la clasificación de los marcos de acuerdo a su
naturaleza:
42
Tabla 3: Clasificación de marcos de referencia arquitectónicos.
Tipo Marcos de referencia
Propietarios Gartner, IBM EAF, Oracle EAF, SAP EAF.
Semi-propietarios EA 3 Cube, Zachman.
Abiertos TOGAF.
Gubernamentales DoDAF, FEAF.
Fuente: Minoli (2008).

2.2.3.2.1 Marcos de referencia propietarios.
Los marcos de referencia propietarios, o comúnmente denominados “privativos”, son

propiedad exclusiva de una sola compañía. Para hacer uso de sus modelos, las empresas
deben pagar por derechos de licencia. Muchas de las veces, para asegurar mejores
resultados, las empresas deben complementar los marcos con otros productos de la misma
compañía.
2.2.3.2.1.1 Gartner
Gartner es considerada como una organización pionera en investigaciones sobre

Tecnologías de la información. Dentro de su amplia variedad de servicios, destaca su
asesoría corporativa en Arquitectura empresarial, la cual para esta empresa tiene carácter
estratégico. En el año 2005, ocurre un hecho muy importante para esta empresa: la
adquisición de la consultora tecnológica META Group, que para ese entonces era el principal
competidor de Gartner.
En base a las investigaciones de META Group y gracias a posteriores trabajos colaborativos,

se publica un modelo no lineal iterativo, que en sí no es un marco de referencia formal. En
base a la premisa “arquitectura empresarial es verbo no sustantivo”, Gartner pone a
disposición de sus clientes un conjunto de buenas prácticas de arquitectura empresarial,
obtenidas a partir de investigación aplicada y su experiencia.
43
Bente et al (2012), explica que Gartner proporciona un enfoque de arriba hacia abajo,
desarrollado a medida del contexto de negocio de sus clientes. Este marco se fundamenta
en que el proyecto arquitectónico debe ser impulsado por la alta dirección de la empresa y
con una visión completa de la empresa en mente. El foco principal de Gartner es la visión y
las prioridades de los altos directivos.
En Gartner, el proyecto arquitectónico se inicia con una visión empresarial y estrategias que
posibiliten su consecución. Por lo tanto, actividades que no estén relacionadas con lo
anterior son intrascendentes. Por esta razón, Gartner sugiere que el esfuerzo arquitectónico
se centre en preocupaciones estratégicas y no en problemas operativos actuales, puesto
que a largo plazo estos desaparecerán o serán irrelevantes.
Para establecer la visión empresarial, Gartner recomienda inicialmente determinar el

contexto del negocio y considerar las prioridades de los altos directivos. La participación de
este grupo de interés será muy importante, y la comunicación con ellos será exclusivamente
en lenguaje de negocios.
Una vez definida la visión, se deberá asegurar que todos los interesados comprendan y
compartan una visión común. Para ello, se comunicará a los interesados una historia simple,
sin estándares de documentación y en lenguaje natural, que explique la problemática, hacia
dónde se dirige la empresa y qué impulsores de negocio deben consolidarse.
La visión empresarial regirá los cambios, asignará prioridades y definirá el valor de negocio
para cada uno de los cambios. Lo anterior será posible mediante el trabajo unificado de los
responsables de las áreas funcionales de la empresa, especialistas técnicos y encargados
de la implementación.
Los cambios comerciales deben ser consolidados con los altos directivos y los cambios
técnicos con los responsables del departamento de tecnología de la empresa. Las métricas
de éxito deberán ser expresadas en términos de negocio, como por ejemplo rentabilidad
operativa, crecimiento del negocio y satisfacción del cliente.
El último paso que propone Gartner es desarrollar, conjuntamente con la alta dirección de la
empresa, una arquitectura de negocio destino que apoye la visión. Luego, con la
44
participación de los responsables del departamento de tecnología y en base a los
requerimientos identificados en la visión empresarial, se deberá desarrollar una arquitectura
de sistemas de información compatible con la nueva arquitectura de negocio. A
continuación, se presenta el modelo original sobre el cual se fundamentó el marco:
Figura 27: Modelo de procesos arquitectónicos de Gartner.

Fuente: Gartner (2005).
Adaptado de Gartner.
2.2.3.2.1.2 IBM EAF
El marco de referencia propuesto por la Academia de tecnología de IBM se basa

principalmente en las guías definidas por TOGAF. Presenta cuatro pilares fundamentales:
arquitectura de negocio, arquitectura de TI, planificación de la transición y gobernanza. El
marco define a la arquitectura empresarial como el proceso de planificación de estrategias y
entrega subsecuente de resultados. (IBM, 2008).
El método de desarrollo arquitectónico del marco (Figura 28) se apoya en productos

arquitectónicos, estándares y principalmente en buenas prácticas. Se destacan las
siguientes buenas prácticas:
45
• Todas las herramientas y metodologías de arquitectura empresarial empiezan con
definiciones del negocio, por lo tanto se debe asegurar que el programa
arquitectónico esté orientado al negocio.
• Las organizaciones deben estar estrechamente vinculadas con los encargados de la
gestión, modelado y mejora continua de los procesos de negocio.
• El equipo de arquitectura empresarial debe comunicar el trabajo efectuado a todas
las áreas involucradas.
• Se debe evitar, en lo posible, la utilización de lenguajes técnicos que dificulten el
entendimiento de los interesados.
• Es importante la adopción de estándares o metodologías de gobernanza de TI.
• El trabajo arquitectónico debe ser pragmático, no teórico.
Figura 28: Método de desarrollo arquitectónico de IBM EAF.

Fuente: IBM (2008).
Adaptado de IBM.
46
2.2.3.2.1.3 ORACLE EAF
El marco de referencia propuesto por Oracle proporciona un enfoque práctico de

arquitectura empresarial. Es una metodología híbrida influenciada por TOGAF, FEAF y
Gartner, cuya motivación es brindar una estructura que permita desarrollar proyectos de tipo
“sólo lo necesario” y “justo a tiempo”. (Oracle, 2009).
Este marco ha sido desarrollado para ofrecer resultados rápidos e incrementales,

reduciendo considerablemente el número de procesos y artefactos de las metodologías
base. Se compone de los siguientes elementos:
• Arquitectura de negocio: Se encarga de alinear el modelo operativo, estrategias y

objetivos del negocio con la tecnología. Además, genera casos de negocio para los
distintos proyectos de transformación de TI.
• Arquitectura de aplicaciones: Describe a las aplicaciones corporativas y servicios
que soportan las funciones del negocio.
• Arquitectura de información: Describe los componentes para la gestión e
intercambio de la información empresarial.
• Arquitectura tecnológica: Describe cómo la infraestructura se integra con las
arquitecturas de negocio, aplicaciones e información.
• Personas, procesos y herramientas: Identifica las personas, procesos y
herramientas necesarias para definir el proyecto arquitectónico.
• Gobernanza arquitectónica: Provee la estructura y procesos para implementar las
estrategias de negocio a través del trabajo arquitectónico.
• Repositorio arquitectónico: Es un almacén interno para todos los artefactos y
entregables desarrollados durante el ciclo de vida arquitectónico.
El marco establece un método genérico (Figura 29) que permite el desarrollo de

arquitecturas. Es un proceso altamente iterativo, que permite la retroalimentación. Está
compuesto de seis fases: visión arquitectónica, estado actual de la arquitectura, estado
futuro de la arquitectura, hoja de ruta estratégica, gobernanza arquitectónica y casos de
negocio. El enfoque del marco permite que algunas de estas fases se ejecuten
simultáneamente.
47
Por cada una de las fases, se desarrollan ciertas tareas y también se producen entregables
(generalmente una presentación que resume los resultados de cada tarea) y artefactos
arquitectónicos (modelos y diagramas).
Figura 29: Método de desarrollo arquitectónico de ORACLE EAF.

Fuente: Oracle (2009).
Adaptado de Oracle.
2.2.3.2.1.4 SAP EAF
El marco arquitectónico SAP EAF (Figura 30) provee una metodología y un conjunto de
herramientas que apoyan la adopción efectiva del modelo arquitectónico SOA 3 en las
empresas. Se basa en una extensión del marco de referencia de arquitectura empresarial
TOGAF, y está específicamente diseñado para soluciones empaquetadas y SOA
empresarial.
3 SOA: Arquitectura orientada a servicios.
48
SAP EAF emplea el mismo método de desarrollo arquitectónico que provee TOGAF,
añadiendo una hoja de trabajo para cada fase, en donde se especifican entradas y salidas.
Además, se incluyen narrativas y descripciones que explican de qué forma desarrollar las
fases. (SAP AG, 2007).
Algunas de las extensiones que propone SAP EAF, fueron incluidas en la versión 9.1 del
marco arquitectónico TOGAF.
Figura 30: Marco arquitectónico SAP EAF.

Fuente: SAP AG (2007).
Adaptado de SAP AG.
2.2.3.2.2 Marcos de referencia semi - propietarios.
Los marcos de referencia semi – propietarios otorgan autorización a las empresas para
hacer uso libre de sus modelos en fines sin ánimo de lucro. En marcos de esta categoría, el
soporte suele tener alto costo. A continuación, se describen los marcos arquitectónicos que
pertenecen a esta clasificación.
49
2.2.3.2.2.1 EA 3 Cube
EA 3 Cube es un marco de diseño geométrico (Figura 31) creado por Scott Bernard en 2004.
Su principal objetivo es identificar el alcance arquitectónico y establecer las relaciones
existentes entre las distintas áreas funcionales de la empresa. Establece jerárquicamente
los siguientes niveles: metas e iniciativas, productos y servicios, datos e información,
sistemas y aplicaciones, y redes e infraestructura.
Figura 31: Cubo EA3.

Dentro del marco existen segmentos de diversas actividades, conocidos como “líneas de
negocio”, que permiten reducir el riesgo y promover la eficiencia. Cada uno de estos
segmentos tiene una subarquitectura, compuesta por los cinco niveles anteriormente
mencionados. (Bernard, 2012).
Una arquitectura que abarca los cinco niveles del marco, centrada en una o más líneas de
negocio, puede ser denominada como un segmento general de toda la arquitectura.
50
De forma general, se identifican 6 elementos de diseño:
• El marco de referencia: Compuesto por 5 niveles jerárquicos, líneas de negocio y

segmentos arquitectónicos. Proporciona un conjunto abstracto de vistas
empresariales, que reflejan la manera en que se produce y organiza la información
arquitectónica.
• Componentes de arquitectura empresarial: Pueden ser objetivos cambiantes,
procesos, estándares y recursos que pueden extenderse en toda la empresa o estar
contenidos en una línea específica de negocio. Existen dos tipos de componentes:
verticales y transversales. Un componente vertical sirve solamente a una línea de
negocio. En cambio, un componente transversal puede servir a muchas líneas de
negocio.
• Arquitectura actual: Identifica los componentes arquitectónicos que existen
actualmente en la empresa por cada nivel del marco. Sirve para generar un
inventario de línea base de los recursos y actividades empresariales.
• Arquitectura futura: Documenta los componentes arquitectónicos nuevos o a ser
modificados, que son necesarios por la empresa para impulsar nuevas iniciativas
estratégicas.
• Plan de gestión de arquitectura empresarial: Es un “documento vivo”, esencial
para planificar la transición hacia un entorno operativo futuro. También, proporciona
descripciones de los puntos de vista arquitectónicos actuales y futuros.
• Hilos: Son elementos que están presentes en todos los niveles del marco. Se
distinguen 3 hilos:
◦ Seguridad: Es necesario establecer un programa de seguridad que incluya

consideraciones respecto a la información, personal, operaciones e instalaciones.
◦ Estándares: Sin duda alguna, la adopción de estándares relacionados con la
tecnología es una de las principales funciones de Arquitectura empresarial. La
importancia del uso de estándares es que mejoran la integración de los
componentes arquitectónicos.
◦ Habilidades: El marco considera a las personas como uno de sus mayores
recursos. Por lo tanto, establece ciertas consideraciones respecto a contratación,
validación de competencias y requisitos de formación.
51
2.2.3.2.2.2 Zachman.
El marco de referencia Zachman es definido por su autor como una ontología, generalmente
empleada para la descripción de una empresa. No puede ser considerado una metodología,
debido a que no proporciona las directrices para la implementación de la arquitectura.
Mientras una ontología se encarga de definir la estructura, una metodología en cambio
define el proceso.
La importancia de una ontología radica en que los procesos que se basen en estructuras
ontológicas serán predecibles e inclusive existirá la posibilidad de repetir resultados. Por lo
tanto, se puede decir que el marco Zachman es la estructura fundamental de la Arquitectura
empresarial.
John A. Zachman (2008), creador del marco, lo define como la intersección entre dos
clasificaciones históricas utilizadas durante muchos años. La primera consiste en las
preguntas primitivas: qué, cómo, cuándo, quién, dónde y por qué, las cuales son la base
para la comunicación.
La segunda se deriva del proceso de transformación de una idea abstracta en una instancia,
que fue postulado inicialmente por los antiguos filósofos griegos y que consiste en los
siguientes pasos: identificación, definición, representación, especificación, configuración y
creación de instancias.
Se escogieron estas dos clasificaciones debido a que ambas han sido utilizadas para
desarrollar representaciones descriptivas de edificios, medios de transporte, y un sinnúmero
de complejos productos industriales.
Normalmente, el marco se representa en una matriz de orden 6 * 6 (tabla 4). Sus columnas
se encuentran conformadas por las interrogantes primitivas, mientras que sus filas están
representadas por el proceso de instanciación (transformación). Por consiguiente, las
clasificaciones del marco serán cada una de las celdas de la matriz, que son la intersección
entre las preguntas y las transformaciones. Actualmente, el marco de referencia Zachman se
encuentra en la versión 3.0, publicada en el año 2011. (Zachman, 2011).
52
Tabla 4: Ontología empresarial Zachman.
Nombres de clasificación Nombres de clasificación
- Qué Cómo Dónde Quiénes Cuándo Por qué -
Perspectiva de audiencia Nombres de modelos
Integraciones compuestas → ← Alineaciones → ← Integraciones compuestas
Perspectiva del Contextos del

ejecutivo Identificación de Identificación de Identificación de Identificación de Identificación de Identificación de alcance
(Planificadores del inventario. procesos. distribuciones. responsabilidades. tiempos. motivaciones (Lista de identificación de
contexto del negocio) alcance)
Perspectiva del Conceptos de

gestor del negocio Definición del Definición de Definición de Definición de Definición de Definición de negocio
(Propietarios del concepto inventario. procesos. distribuciones. responsabilidades. tiempos. motivaciones. (Modelos de definición de
de negocio) negocio)
Perspectiva del Lógica de los

→ Transformaciones alineadas ←
→ Transformaciones alineadas ←
arquitecto Representación Representación de Representación de Representación de Representación de Representación de sistemas
(Diseñadores de la lógica del inventario. procesos. distribuciones. responsabilidades. tiempos. motivaciones. (Modelos de representación
del negocio) de sistemas)
Perspectiva del Instalaciones

ingeniero Especificación del Especificación de Especificación de Especificación de Especificación de Especificación de tecnológicas
(Constructores de la inventario. procesos. distribuciones. responsabilidades. tiempos. motivaciones. (Modelos de representación
infraestructura el negocio) de tecnología)
Perspectiva del Componentes de

técnico Configuración del Configuración de Configuración de Configuración de Configuración de Configuración de herramientas
(Implementadores de los (Modelos de
inventario. procesos. distribuciones. responsabilidades. tiempos. motivaciones.
componentes del configuración de
negocio) herramientas)
Perspectiva de la Instancias de
Creación de Creación de Creación de Creación de Creación de Creación de
empresa operaciones
instancias del instancias de instancias de instancias de instancias de instancias de
(Usuarios) responsabilidades. (Implementaciones)
inventario. procesos. distribuciones. tiempos. motivaciones.
EMPRESA EMPRESA
Integraciones compuestas → ← Alineaciones → ← Integraciones compuestas
Perspectiva de audiencia
Conjuntos de Flujos de Redes de Asignación de Ciclos de Propósitos de la
-
Nombres empresariales inventarios procesos distribución. responsabilidades. tiempos. motivación.
Fuente: Zachman (2011).

Adaptado de Zachman.
53
2.2.3.2.3 Marcos de referencia abiertos.
Los marcos de referencia abiertos posibilitan a las empresas emplear gratuitamente sus
modelos y ajustarlos a necesidades específicas. En esta clasificación, existen marcos de
referencia que ofrecen extensa documentación de forma gratuita.
2.2.3.2.3.1 TOGAF.
TOGAF es desarrollado y mantenido por The Open Group Architecture Forum. La primera
versión de TOGAF fue desarrollada en 1995, y se basó en el marco de referencia de
Arquitectura para la administración de la información del Departamento de defensa de los
Estados Unidos.
En los años posteriores, el consorcio The Open Group publicó sucesivamente nuevas
versiones del marco en su repositorio web. Luego de haberse publicado la versión técnica
(TOGAF 7) y la versión empresarial (TOGAF 8), en diciembre de 2011 se publica la versión
actual del marco (TOGAF 9.1) que incluiría sustanciales cambios y nuevos conceptos. Los
principales componentes de TOGAF 9.1 son: método de desarrollo arquitectónico (ADM, por
sus siglas en inglés), continuum empresarial, marco de capacidades arquitectónicas, marco
de contenidos arquitectónicos y guías y técnicas para la implementación del ADM.
El núcleo de TOGAF es el ADM (Figura 32), el cual es su método de desarrollo y de gestión

del ciclo de vida arquitectónico. Este método es iterativo, lo cual posibilita un avance
progresivo y retroalimentación por cada una de sus fases. Para cada fase, el marco provee
una narrativa que incluye: objetivos, enfoques, pasos, entradas y salidas.
Actualmente, TOGAF es considerado como el marco de referencia arquitectónico más

utilizado por las organizaciones a nivel mundial. The Open Group (2015), proporciona
estadísticas que avalan la anterior afirmación, puesto que el 80% de las empresas que
integran el Global Titans 504 y el 60% de las empresas que conforman el Fortune 500 5
utilizan este marco de referencia.
4 Listado de las 50 empresas con mayor capitalización de mercado en el mundo.

5 Listado de las 500 mayores empresas estadounidenses de capital abierto a cualquier inversor.
54
Además, otro dato importante es que empresas como: IBM, CISCO, ORACLE, Cognizant,
Hewlett Packard, cuentan en su nómina con al menos 9 arquitectos arquitectos con
certificación en TOGAF. (The Open Group, 2015).
En resumen, TOGAF se destaca por ofrecer un estándar confiable, normas y métodos

coherentes, y promover la comunicación entre las partes interesadas. Además, brinda
modelos verticales de la industria, casos prácticos de estudio, extensa documentación y un
conjunto de lecciones aprendidas.
Figura 32: Método de desarrollo arquitectónico de TOGAF.

Fuente: The Open Group (2015).
Adaptado de The Open Group.
55
2.2.3.2.4 Marcos de referencia gubernamentales.
Los marcos de referencia gubernamentales han sido creados para suplir necesidades
específicas de las agencias federales de los Estados Unidos. Gracias a sus contribuciones,
han permitido cimentar las bases para posteriores marcos de referencia. Los modelos,
métodos e información adicional de este tipo de marcos se encuentra disponible de manera
gratuita en los portales oficiales de las agencias.
2.2.3.2.4.1 DoDAF.
La primera versión de DoDAF se publica en el año 2003, producto de la reestructuración del

extinto marco arquitectónico C4ISR. Su predecesor fue un proyecto desarrollado por el
Departamento de defensa de los Estados Unidos, cuyo objetivo era generar un modelo
ajustado a las necesidades de los combatientes y que fomente la interoperabilidad.
DoDAF fue creado para proporcionar mejor orientación, descripciones de productos

arquitectónicos e información suplementaria. Amplió la aplicabilidad de la práctica
arquitectónica a todas las áreas del Departamento de defensa, y no solamente al área de
Control y Armas como en C4ISR. (Departamento de defensa de Estados Unidos, 2010).
DoDAF constituye una mejora notable frente a su predecesor, respecto a la concepción de

arquitectura empresarial. Con DoDAF, los arquitectos cuentan con libertad para crear
arquitecturas empresariales que satisfagan la demanda de sus clientes. En agosto de 2010,
se publica la versión actual del marco (DoDAF 2.02), que se enfoca principalmente en los
datos. Para ello, propone modelos que garantizan la reutilización de la información y el
entendimiento común de los principales artefactos, modelos y puntos de vista
arquitectónicos.
Un componente principal de DoDAF es la definición de puntos de vista (Figura 33). Un punto

de vista arquitectónico está compuesto por datos que han sido organizados para facilitar la
comprensión. Además, DoDAF cuenta con 6 procesos principales: 1) integración de
capacidades y desarrollo de sistemas, 2) adquisición de sistemas, 3) ingeniería de sistemas,
4) planificación, presupuestación y ejecución, 5) gestión de portafolio y 6) operaciones.
56
Figura 33: Puntos de vista de DODAF.
Fuente: Departamento de defensa de Estados Unidos (2010).
Adaptado de Departamento de defensa de Estados Unidos.
2.2.3.2.4.2 FEAF.
En 1999 se publica la primera versión del marco arquitectónico federal FEAF. Fue
desarrollado con el propósito de guiar el diseño e implementación de arquitecturas en las
agencias federales de los Estados Unidos. Está basado en un conjunto de mejores prácticas
comerciales y en el modelo arquitectónico NIST.
Su desarrollo se ralentizó un poco debido a los acontecimientos suscitados el 11 de

Septiembre de 20016, por lo que sus posteriores entregas fueron aumentos sucesivos en el
desarrollo de sus principales modelos de referencia. Inicialmente, incluía algunos conceptos
del marco de referencia de arquitectura empresarial Zachman y del proceso de planificación
EAP.
En el año 2012, la Oficina de administración y presupuesto de Estados Unidos (OMB, por

sus siglas en inglés) publica el “Enfoque común de arquitectura empresarial federal”, que
permitió estandarizar la práctica arquitectónica entre las agencias federales del país. Incluye
un conjunto de principios arquitectónicos que permiten a las agencias optimizar sus
servicios, minimizar brechas de rendimiento y lograr compromiso entre las partes
involucradas.
6 11 de Septiembre de 2001, atentados terroristas en Estados Unidos.
57
Al año siguiente, se publica la segunda versión del marco arquitectónico FEAf, en el cual se
establecen herramientas que permitirán la implementación del Enfoque común. Su principal
objetivo es acelerar el proceso de transformación de las agencias y permitir la adopción de
nuevas tecnologías, mediante: estandarización, herramientas de análisis y reportería, hoja
de ruta arquitectónica y un método repetitivo ágil.
El núcleo de FEAf es su modelo de referencia consolidado, que proporciona a las agencias

un marco para describir y analizar sus inversiones. Este modelo consolidado consta de 6
otros modelos interrelacionados, que describen las sub-arquitecturas identificadas por el
marco: estrategia, negocio, datos, aplicaciones, infraestructura y seguridad.
Mediante la aplicación de los 6 modelos de referencia, las agencias establecen una línea de
visión desde sus objetivos estratégicos, considerados su nivel organizacional más alto,
hasta los sistemas e infraestructura que permiten alcanzar sus objetivos. A continuación, se
presenta el metamodelo del enfoque común del marco.
Figura 34: Metamodelo del enfoque común de FEAf.

Fuente: OMB (2013).
Adaptado de OMB.
58
2.2.3.3 Evaluación de los marcos de referencia arquitectónicos.
Tras analizar los principales marcos de referencia arquitectónicos, se debe seleccionar el

marco de referencia que será adaptado a las necesidades de las pequeñas y medianas
empresas.
Sessions, R. (2007) publicó el documento “Una comparación de los cuatro principales

marcos de arquitectura empresarial”, en el cual se establecen los siguientes criterios para
evaluar y comparar a los marcos arquitectónicos FEAF, Gartner, TOGAF y Zachman:
• Taxonomía: Cómo el marco clasifica los artefactos arquitectónicos.

• Procesos arquitectónicos: Cómo el marco guía el proceso de creación de
arquitecturas empresariales.
• Modelos de referencia: Si el marco provee un conjunto de modelos de referencia.
• Práctica arquitectónica: Cómo el marco ayuda a asimilar la importancia de la
práctica arquitectónica y cómo ayuda a desarrollar una cultura arquitectónica en la
empresa.
• Modelos de madurez: Cómo el marco ayuda a evaluar la efectividad y la madurez
de la práctica arquitectónica en la empresa.
• Enfoque de negocio: Si el marco se centrará en el uso de la tecnología para
impulsar el valor del negocio, en donde el valor del negocio se define como
reducción de gastos y/o aumento de ingresos.
• Gobernanza: Cómo el marco ayudará en la comprensión y creación de un modelo
de gestión eficaz de la arquitectura.
• Segmentación de la arquitectura: Cómo el marco guiará el proceso de creación de
particiones autónomas de la arquitectura.
• Catálogo prescriptivo: Cómo el marco guiará el proceso de creación de un catálogo
de bienes arquitectónicos reutilizables.
• Neutralidad del proveedor: Si el marco tiene dependencia de proveedores.
• Disponibilidad de la información: Se refiere a la cantidad de información gratuita y
de calidad que provee el marco.
• Tiempo de valoración: Se refiere al tiempo empleado antes de empezar a construir
soluciones con un alto valor comercial.
59
Las calificaciones se asignan de la siguiente manera:
1: Ha desarrollado poco trabajo en esta área.

2: Posee un trabajo poco aceptable en esta área.
3: Posee un trabajo aceptable en esta área.
4: Tiene un buen trabajo en esta área.
Sessions menciona que los criterios y las calificaciones pueden ser modificadas
dependiendo del contexto de la investigación. Por lo tanto, se ha decidido conservar los
criterios establecidos por el autor del documento en mención y se actualizarán las
calificaciones asignadas, puesto que el documento original fue creado en el año 2007 y han
surgido nuevas versiones de los marcos de referencia FEAF y TOGAF.
Tabla 5: Evaluación de los principales marcos de referencia arquitectónicos.

Criterios FEAF Gartner TOGAF Zachman
Taxonomía 2 1 4 4
Procesos arquitectónicos 2 3 4 1
Modelos de referencia 4 1 4 1
Práctica arquitectónica 2 4 3 1
Modelo de madurez 3 2 2 1
Enfoque de negocio 3 4 3 1
Gobernanza 3 3 3 1
Segmentación de la arquitectura 4 3 4 1
Catálogo prescriptivo 4 2 4 1
Neutralidad del proveedor 3 1 4 2
Disponibilidad de información 3 1 4 2
Tiempo de valoración 1 4 3 1
Fuente: Sessions (2007).
Adaptado de Sessions.
De forma general, las mejores calificaciones de acuerdo a los criterios establecidos, las
presenta el marco de referencia TOGAF, por lo tanto es el marco arquitectónico
seleccionado para la presente investigación.
60
Sin embargo, como se evidencia en la anterior tabla, el marco no cuenta con un buen
trabajo referente a modelos de madurez. Por esta razón, se complementará el marco
arquitectónico seleccionado con el marco de transformación empresarial BTM2, que
establece un modelo de madurez comprensible y que puede ser implementado en las
PYMEs.
2.2.4 Enfoque ágil.
La agilidad es una característica que en los últimos tiempos ha sido adoptada por todo tipo
de empresas. Cuando hablamos de agilidad, no precisamente nos referimos a la
culminación de proyectos o programas en menor tiempo, sino a la optimización de recursos
empresariales y priorización de procesos clave a fin de conseguir un objetivo.
2.2.4.1 Concepto de ágil.
Con la aparición de tendencias tecnológicas como SMAC (Social, Móvil, Analytics y Cloud),
han emergido numerosas oportunidades y riesgos potenciales en la conformación de
negocios. La gran mayoría de expertos concuerdan en que para desarrollar el denominado
“salto tecnológico”, las organizaciones deberán contar con estructuras organizacionales
ágiles.
La Real Academia de la Lengua Española (2014) define agilidad como la “cualidad de actuar
o desarrollarse con rapidez o prontitud”. En el contexto de los negocios, Bloomberg (2013)
describe a agilidad como “la habilidad de responder a los cambios en el entorno empresarial
y obtener ventajas competitivas de los mismos”. Es decir, agilidad es un mecanismo que
toda empresa debería adoptar en sus prácticas arquitectónicas.
Sin embargo, agilidad no es sólo la habilidad de responder a los cambios, es una capacidad
dinámica de las empresas que permitirá el proceso de identificación de oportunidades y
amenazas, resolución de conflictos y generación de cambios en la base de recursos
empresariales. Agilidad no se resume en rapidez, es un concepto también orientado a
calidad.
61
2.2.4.2 Manifiesto ágil.
En nuestra rama de estudio, se suele asociar el término ágil con metodologías ágiles de
desarrollo de software. En febrero de 2011, expertos en desarrollo de software crearon el
Manifiesto ágil, documento que contiene 4 postulados para la construcción de software.
Bloomberg (2013) expresa que es posible extender los principios del Manifiesto ágil al
concepto de arquitectura empresarial:
• “Individuos y su interacción, por encima de los procesos y herramientas”: Como un

sistema de personas, procesos y tecnología, el concepto de empresa se vincula
mayormente con el factor humano (cultura organizacional, habilidades y
capacidades).
• “El software que funciona, por encima de la documentación exhaustiva”: La
tecnología debe funcionar para asegurar la agilidad del negocio.
• “La colaboración con el cliente, por encima de la negociación contractual”: La
participación de los altos directivos incrementa las probabilidades de éxito del trabajo
arquitectónico.
• “La respuesta al cambio, por encima del seguimiento de un plan”: El contexto
cambiante de las empresas requiere de arquitecturas empresariales flexibles.
En la siguiente figura, Greefhorst (2015) describe cómo el concepto de arquitectura

empresarial podría verse enriquecido por características de las metodologías ágiles:
Figura 35: Relación entre arquitectura empresarial y metodologías

ágiles.
Fuente: Greefhorst (2015).
Adaptado de Greefhorst.
62
2.2.4.3 Arquitecturas empresariales ágiles.
Bloomberg (2013), describe la necesidad latente de las organizaciones por conseguir

agilidad en sus negocios, básicamente a través del soporte de las siguientes características:
• Receptividad: Impulsor táctico que asegura la respuesta eficiente y rápida a

cambios positivos en el entorno empresarial.
• Resiliencia: Impulsor táctico del negocio para confrontar situaciones que compliquen
la consecución de objetivos estratégicos, en base a la mitigación de riesgos.
• Innovación: Valor estratégico que permite la mejora del modelo de negocios
empresarial, a través de cambios organizacionales, productivos o tecnológicos a fin
de obtener ventajas competitivas.
La agilidad es una característica fundamental de todas las empresas. Se puede disponer de

forma aislada de recursos ágiles tecnológicos o humanos, sin embargo el mayor beneficio
se obtendrá cuando se desarrolle agilidad en todas las dimensiones empresariales.
Bloomberg (2015) menciona que Allen Brown, alto directivo de The Open Group, considera
que “el término ágil está asociado en gran parte a construcción de soluciones antes que a
arquitecturas empresariales”. Es decir, se tiende a relacionar únicamente agilidad con
metodologías de desarrollo de software ágiles.
La arquitectura se centra en el diseño general de los sistemas, describiendo cómo los

componentes se acoplarán para alcanzar los objetivos del negocio. Por lo tanto,
arquitectura empresarial se concibe bajo la premisa de que las organizaciones son
“sistemas de sistemas” (personas, procesos, tecnología). Sin embargo, la definición general
de arquitectura empresarial suele ser estática y para conseguir agilizarla es necesario
incorporar una nueva característica empresarial: emergente.
La característica emergente en las empresas permitirá establecer condiciones iniciales y

reglas simples a los comportamientos de los sistemas, evolucionando a través de enfoques
iterativos y ciclos de retroalimentación. De esta manera, una arquitectura empresarial ágil se
centrará en la identificación y soporte de potenciales cambios del negocio a través
infraestructuras tecnológicas flexibles.
63
Swende, E., Ohlin, B., Dahkvist, J. (2011) expresan que una arquitectura empresaria ágil
debe posibilitar la creación de estados de transición funcionales (Figura 36). Análogamente
a las metodologías de desarrollo de software ágiles, el enfoque ágil en arquitectura
empresarial debe asegurar retroalimentación en todos los tipos de iteraciones del ciclo de
desarrollo arquitectónico y no luego de haber finalizado la ejecución del proyecto.
Figura 36: Diseño de arquitecturas ágiles.

Fuente: Swende et al (2011).
Adaptado de Swende et al.
De acuerdo a las características mencionadas por los autores anteriormente citados, las
arquitecturas empresariales ágiles deben ser aproximadas y adaptativas. Partiendo de
escenarios en los que aún no existe una concepción madura del estado futuro que se desea
alcanzar, el enfoque ágil permitirá no sobredimensionar el proyecto arquitectónico
consecuente y ser flexible ante posibles cambios.
Figura 37: Enfoque de arquitectura empresarial ágil.

Fuente: Swende et al (2011).
Adaptado de Swende et al.
64
La siguiente figura describe los elementos del enfoque ágil de arquitectura empresarial:7
Figura 38: Elementos de enfoque ágil de arquitectura

empresarial.
Fuente: Bloomberg (2015).
Adaptado de Bloomberg.
El desarrollo de arquitecturas ágiles posibilitará emerger en una revolución ágil:
Figura 39: Revolución ágil.

7 BizOps, Business Operations Services.
65
2.2.4.4 Técnicas ágiles
De acuerdo a Owen & Burnett (2015), el Manifiesto Ágil impulsó a las empresas a enfocarse
en la comunicación, colaboración, funcionamiento del software, organización y flexibilidad
para adaptarse a las realidades emergentes del negocio. Por esta razón, se han
desarrollado técnicas que permitan generar innovación y conseguir agilidad en el negocio.
2.2.4.4.1 Kanban
Kanban (palabra con origen japonés, donde kan significa visual y ban significa tablero) es
una herramienta implementada por primera vez en la fábrica japonesa de automóviles
TOYOTA, a fin de controlar los recursos y tiempos necesarios, por cada proceso inmerso en
la generación de nuevos productos.
Figura 40: Tablero Kanban.

Los tableros de Kanban son representaciones visuales de cómo se efectuará un proceso o

un flujo de trabajo, es decir definen la hoja de ruta y conceptos relevantes para la misma.
Los conceptos se representan como una tarjeta en el tablero y pueden ser dispuestos de un
estado a otro.
66
Un tablero Kanban está compuesto de los siguientes elementos:
• Etapas: Una etapa es un marcador de posición para el estado del trabajo efectuado.
• Límites: Cada etapa está definida por límites, los mismos que indican el número
máximo de conceptos existentes en una etapa. Los límites son muy importantes,
puesto que previenen que una etapa se sobrecargue de trabajo.
Kanban es una herramienta útil al momento de adoptar un enfoque ágil para Arquitectura
empresarial, debido a que nos brinda una vista del progreso del trabajo de los principales
conceptos de Arquitectura empresarial. En este contexto, un tablero puede representar una
idea, una capacidad del negocio o un componente de una aplicación.
Generalmente, un tablero Kanban define los siguientes estados: en espera, para realizar,
realizándose y realizado. Los anteriores estados pueden ser representados mediante
colores, que nos permitirán decidir en qué tareas debemos prestar mayor atención.
Owen & Burnett (2015), explican que “Kanban se deriva de los métodos de fabricación
denominados -justo a tiempo-, los cuales se centraban en lo que se necesita para lograr un
resultado en particular y en la integración de la cadena de suministro para maximizar la
producción”. Por lo tanto, si hacemos una analogía con el enfoque ágil de arquitectura
empresarial, la línea de producción es la cantidad de arquitecturas necesarias para incluir un
cambio en el programa o proyecto.
Kanban se constituye como una herramienta clave para la gestión de los modelos
contextuales de cambio, permitiendo concentrarse en los elementos arquitectónicos
necesarios y posibilitando mejor comprensión y comunicación entre las partes interesadas.
El núcleo del marco arquitectónico TOGAF, su método de desarrollo arquitectónico ADM,

también puede ser representado como un tablero Kanban. En ADM, el trabajo se efectúa de
izquierda a derecha, por lo tanto cada etapa del tablero Kanban corresponderá a las fases
definidas en el ADM y los conceptos serán los entregables a desarrollar por cada etapa.
67
CAPÍTULO 3: CONCEPTUALIZACIÓN DE TOGAF
3.1 Conceptos básicos.
A continuación, se presentan algunos conceptos importantes para el entendimiento del

marco arquitectónico TOGAF.
3.1.1 Historia de TOGAF.
TOGAF es un marco de referencia arquitectónico que surgió hace dos décadas con el
objetivo de convertirse en un estándar para el desarrollo de arquitecturas empresariales.
Actualmente, TOGAF se encuentra en su versión 9.1, lanzada en Diciembre del 2011.
Fue creado por los miembros del consorcio The Open Group. TOGAF no siempre ha
incorporado un enfoque holístico de arquitectura empresarial, puesto que inicialmente, sólo
se incluyó en TOGAF las arquitecturas técnicas (versiones 1 a 7), sin embargo, el dominio
de la arquitectura de negocios fue implantado en el marco en la versión 8, siendo impulsado
rápidamente entre las opciones de marcos para arquitecturas empresariales de hoy en día.
3.1.2 ¿Qué es TOGAF?.
The Open Group Architecture Framework (TOGAF) es un marco arquitectónico, que brinda
un conjunto de métodos y herramientas para el desarrollo de una amplia gama de
arquitecturas de TI. Permite a los usuarios diseñar, evaluar y construir la arquitectura
adecuada para su organización, lo cual implicará reducir los costos de: planificación, diseño
e implementación de arquitecturas basadas en soluciones de sistemas abiertos.
La clave para que TOGAF siga siendo un método práctico fiable, es el método de desarrollo
arquitectónico (ADM), el cual define las necesidades del negocio y el desarrollo de una
arquitectura que responda a esas necesidades, utilizando los elementos de TOGAF y otros
activos arquitectónicos a disposición de la organización.
Las empresas que buscan acceso inmediato a la información pueden utilizar TOGAF para
definir y poner en práctica estructuras y procesos que permitan el consumo de la
69
información integrada dentro y entre las empresas. Las organizaciones que diseñan e
implementan sus arquitecturas empresariales utilizando TOGAF se aseguran un diseño y
especificación de adquisiciones que pueda facilitar una implementación de sistemas
abiertos, permitiendo así lograr beneficios con menor riesgo.
3.1.3 Dimensiones de TOGAF.
TOGAF ha sido modelado en cuatro dimensiones o niveles:

• Arquitectura de negocios, en la cual se define la estrategia de negocios,
gobernanza, estructura y procesos clave de la organización.
• Arquitectura de datos, en la cual se describe la estructura de los datos físicos y
lógicos de la organización, y los recursos de gestión de estos datos.
• Arquitectura de aplicaciones, en la cual se provee un plano para cada uno de los
procesos de negocio en los que se fundamenta la organización.
• Arquitectura tecnológica, en la cual se describe la estructura hardware, software y
de redes requerida para dar soporte a la implantación de las aplicaciones principales,
de misión crítica, de la organización.
3.1.4 Aplicabilidad de TOGAF.
Una de las principales causas de fracasos en proyectos de TI, es la dificultad de

entendimiento entre negocio y tecnología. El problema no sólo reside en la especificación de
requisitos, sino en el entendimiento de las soluciones e implicación en el proyecto. TOGAF,
desde la visión de The Open Group, facilita la creación de un entorno de comunicación sin
barreras, donde la información fluye entre los diferentes implicados.
Por lo tanto, normalmente TOGAF puede ser aplicado en:

• Creación de aplicaciones de misión crítica.
• Minimizar riesgos de no entendimiento entre negocio y tecnología.
• Generación de valor y de oportunidades de transformación empresarial.
• Describir, documentar y continuar los sistemas y aplicaciones construidas.
70
3.2 Método de desarrollo arquitectónico.
El método de desarrollo arquitectónico (ADM, por sus siglas en inglés) constituye la pieza
fundamental de TOGAF.
3.2.1 Definición.
Este método está compuesto de diferentes fases a realizar de forma cíclica. De tal forma
que en cada ciclo de ejecución vaya madurando la solución arquitectónica de la
organización y el valor que aporta al negocio.
Figura 41: Método de desarrollo arquitectónico.

71
El orden de las fases es hasta cierto punto dependiente de la madurez arquitectónica de la
empresa. En otras ocasiones, el orden puede ser definido por los principios arquitectónicos
o de negocio de la empresa.
3.2.2 Puntos claves.
• Es iterativo: a lo largo de todo el proceso, entre las fases, y dentro de las fases.
• Puede ser integrado con otros marcos de referencia de arquitectura empresarial y de
soporte adicional.
• En pequeñas y medianas empresas deberá ser ajustado previamente para su
implementación.
• Al ser un método genérico, está destinado a ser utilizado por empresas en una
amplia variedad de geografías y en diferentes tipos de sectores de la industria.
3.2.3 Iteraciones.
El método de desarrollo arquitectónico da lugar a varios conceptos que se podrían

caracterizar como iteraciones:
1. Iteraciones para desarrollar el contexto arquitectónico: Iniciativas individuales
ligadas a Solicitudes de trabajo arquitectónico. La arquitectura resultante se agregará
al contexto arquitectónico, ya sea ampliándolo o modificándolo.
2. Iteraciones dentro de un ciclo del ADM: Los proyectos pueden operar múltiples
fases o desplazarse entre ellas.
3. Iteraciones para gestionar la capacidad arquitectónica: Los proyectos pueden
requerir una nueva iteración para ajustar su capacidad arquitectónica como resultado
de la identificación nuevos requerimientos.
ADM-TOGAF sugiere los siguientes ciclos de iteraciones:

• Iteraciones de capacidad arquitectónica.
• Iteraciones de desarrollo arquitectónico.
• Iteraciones de planificación de la transición.
• Iteraciones de gobernanza arquitectónica.
72
3.2.4 Iteración de capacidad arquitectónica.
Las iteraciones de capacidad arquitectónica apoyan la creación y evolución de las

capacidades arquitectónicas requeridas por la organización. Este ciclo incluye la puesta en
marcha inicial de la actividad arquitectónica con un objetivo dado o un tipo de compromiso
arquitectónico, estableciendo o ajustando el enfoque, principios, alcance, visión y estructura
de la gobernanza.
Una visión general de las fases que conforman la iteración de capacidad arquitectónica, se
describe en el ANEXO 1: Iteración de capacidad arquitectónica TOGAF 9.1.
3.2.4.1 Fase preliminar.
La fase preliminar prepara a las organizaciones para emprender proyectos de arquitectura

empresarial de manera exitosa.
Tabla 6: Descripción de la fase preliminar de TOGAF.
Objetivos Pasos
• Determinar las capacidades deseadas por la • Determinar las áreas de la empresa

organización: que serán impactadas.
◦ Examinar el contexto organizacional para • Confirmar los marcos de referencia de
llevar a cabo el proyecto de arquitectura gobernanza y de soporte adicional.
empresarial. • Definir y establecer el equipo de
◦ Identificar y determinar el alcance de los Arquitectura empresarial y su
unidades de la empresa que serán organización.
afectadas por la capacidad arquitectónica. • Identificar y establecer los principios
◦ Identificar marcos de referencia arquitectónicos.
establecidos, métodos y procesos que se
• Adaptar TOGAF y, si es necesario,
entrecrucen con la capacidad arquitectónica.
otros marcos de referencia
◦ Establecer la madurez de la capacidad
destino.
arquitectónicos seleccionados.
• Implementar herramientas
• Establecer las capacidades arquitectónicas: arquitectónicos.
◦ Definir y establecer el modelo organizacional
de arquitectura empresarial.
◦ Definir y establecer el proceso detallado y
los recursos para la gobernanza
arquitectónica.
◦ Seleccionar y poner en práctica las
herramientas que apoyen la actividad
arquitectónica.
◦ Definir los principios arquitectónicos.
73
Entradas Salidas (Entregables)
• Otros marcos de referencia • Modelo organizacional de

arquitectónicos. arquitectura empresarial.
• Estrategias del consejo organizacional, • Marco de referencia
planes de negocio; estrategia de arquitectónico adaptado,
negocio; estrategia de TI; principios de incluyendo principios
negocio, objetivos de negocio e arquitectónicos.
impulsores del negocio. • Repositorio arquitectónico inicial.
• Marcos de referencia de gobernanza. • Reafirmación o referencia de los
• Capacidades arquitectónicas. principios, objetivos impulsores
• Acuerdos de asociación y contratos. del negocio.
• Modelo organizacional de Arquitectura • Solicitud de trabajo
empresarial existente. arquitectónico.
• Marco de referencia arquitectónico • Marco de referencia de
existente, si lo hay, incluyendo: gobernanza.
◦ Método arquitectónico.
◦ Contenido arquitectónico.
◦ Herramientas configuradas e
implementadas.
◦ Principios arquitectónicos.
◦ Repositorio arquitectónico.
Fuente: TOGAF 9, versión de bolsillo.

Adaptado de: The Open Group.
A continuación, se describen los artefactos arquitectónicos que complementarán a los

entregables producidos en esta fase.
Tabla 7: Artefactos de la fase preliminar de TOGAF.
Artefactos
• Catálogos
◦ Catálogo de principios

Adaptado de: The Open Group.
3.2.4.2 Fase A: Visión arquitectónica.
La fase A: Visión arquitectónica aborda el establecimiento del proyecto e inicia la iteración

del ciclo de desarrollo arquitectónico, estableciendo el alcance, limitaciones y expectativas
de la iteración. Se ejecuta con el objetivo de validar el contexto del negocio y producir la
aprobación del Enunciado del trabajo arquitectónico.
74
Tabla 8: Descripción de la fase A: Visión arquitectónica de TOGAF.
Objetivos Pasos
• Desarrollar una visión de alto nivel de las • Establecer el proyecto arquitectónico.

capacidades y valor de negocio que se • Identificar interesados, preocupaciones y
desean obtener como resultado de la requerimientos de negocio.
arquitectura empresarial propuesta. • Confirmar y elaborar objetivos,
impulsores y limitaciones de negocio.
• Obtener la aprobación de la Solicitud del • Evaluar las capacidades del negocio.
trabajo arquitectónico que define un • Evaluar la preparación para la
programa de trabajo para desarrollar e transformación del negocio.
implementar la arquitectura descrita en la • Definir el alcance.
Visión arquitectónica. • Confirmar y elaborar Principios
arquitectónicos, incluyendo principios de
negocio.
• Desarrollar la Visión arquitectónica.
• Definir las propuestas de valor de la
arquitectura destino e indicadores claves
de desempeño.
• Identificar riesgos de la transformación
del negocio y actividades de mitigación.
• Desarrollar el Enunciado del trabajo
arquitectónico; asegurar su aprobación.
• Solicitud de trabajo arquitectónico. • Enunciado del trabajo arquitectónico

• Principios, objetivos e impulsores del aprobado.
negocio. • Declaraciones refinadas de principios,
• Modelo organizacional de arquitectura objetivos e impulsores del negocio.
empresarial. • Principios arquitectónicos.
• Marco de referencia arquitectónico • Evaluación de capacidades.
adaptado, incluyendo adaptación del • Marco de referencia arquitectónico
método arquitectónico, contenido adaptado.
arquitectónico, principios arquitectónicos • Visión arquitectónica, incluyendo:
y herramientas configuradas e ◦ Requerimientos clave refinados y de
implementadas. alto nivel de los interesados.
• Repositorio arquitectónico cargado con la • Versión preliminar del Documento de
documentación arquitectónica existente. definición arquitectónica, incluyendo:
◦ Arquitectura de negocio de línea base
y destino.
◦ Arquitectura de datos de línea base y
destino.
◦ Arquitectura de aplicaciones de línea
base y destino.
◦ Arquitectura tecnológica de línea base
y destino.
◦ Plan de comunicaciones.

Elaboración: The Open Group.
75
Tabla 9: Artefactos de la fase A : visión arquitectónica de TOGAF.
Artefactos
• Diagramas
◦ Diagrama de cadena de valor.
◦ Diagrama de concepto de solución.
• Matrices
◦ Matriz de interesados.

3.2.5 Iteración de desarrollo arquitectónico.
Las iteraciones de desarrollo arquitectónico permiten la creación de contenido a través del

desplazamiento o integración de las fases: arquitectura de negocio, arquitectura de sistemas
de información y arquitectura tecnológica. Estas iteraciones aseguran que la arquitectura se
considere como un todo.
En este tipo de iteración las revisiones de los interesados son por lo general más amplias.
Como las iteraciones convergen hacia un objetivo, las extensiones en Oportunidades y
soluciones y en las fases de Planificación de la migración, aseguran que la factibilidad de la
implementación de la arquitectura se tome en cuenta mientras ésta se finaliza. Una visión
general de las fases que conforman la iteración de desarrollo arquitectónica, se describe en
el ANEXO 2: Iteración de desarrollo arquitectónico TOGAF 9.1.
3.2.5.1 Fase B: Arquitectura de negocio.
La fase B: Arquitectura de negocio aborda el desarrollo de una arquitectura de negocio que

apoye la visión arquitectónica acordada. De forma general, la arquitectura de negocio
describe a las estrategias de generación de productos/servicios y todos los aspectos
relevantes con el entorno empresarial.
76
Tabla 10: Descripción de fase B: Arquitectura de negocio de TOGAF.
Objetivos Pasos
• Desarrollar la arquitectura de negocio • Seleccionar modelos de referencia,

destino describiendo cómo la empresa puntos de vista y herramientas.
tiene que operar para alcanzar los • Desarrollar la descripción de la línea
objetivos de negocio, responder a las base de la arquitectura de negocio.
motivaciones estratégicas definidas en • Desarrollar la descripción de la
la Visión arquitectónica y responder a arquitectura de negocio destino.
la Solicitud de trabajo arquitectónico y • Realizar el análisis de brechas.
las preocupaciones de los interesados. • Definir los componentes candidatos de
la Hoja de ruta del trabajo
• Identificar componentes candidatos arquitectónico.
para la Hoja de ruta del trabajo • Resolver los impactos del contexto
arquitectónico basándose en las arquitectónico.
brechas identificadas entre la • Conducir revisiones formales con los
arquitectura de negocio de línea base interesados.
y destino. • Finalizar la arquitectura de negocio.
• Crear el Documento de definición
arquitectónica.
• Solicitud del trabajo arquitectónico. • Enunciado del trabajo arquitectónico,

• Principios, objetivos, e impulsores del actualizado.
negocio. • Principios de negocio validados,
• Evaluación de capacidades. objetivos e impulsores del negocio.
• Plan de comunicaciones. • Versión preliminar del Documento de
• Modelo organizacional de arquitectura definición arquitectónica, incluyendo:
empresarial. ◦ Arquitectura de negocio de línea
• Marco de referencia arquitectónico base y destino (detalladas).
adaptado. ◦ Vistas correspondientes a puntos de
• Enunciado del trabajo arquitectónico vista seleccionados que respondan a
aprobado. las preocupaciones clave de los
• Principios arquitectónicos, incluyendo interesados.
principios de negocio, cuando ya • Documento de Especificación de
existan. requerimientos arquitectónicos,
• Continuum empresarial. incluyendo actualizaciones de
• Repositorio arquitectónico contenido:
• Visión arquitectónica, incluyendo: ◦ Resultados del análisis de brechas
◦ Requerimientos clave refinados y de ◦ Requerimientos técnicos.
alto nivel de los interesados. ◦ Requerimientos de negocio
• Versión preliminar del Documento de actualizados.
definición arquitectónica. • Componentes de la arquitectura de
negocio de la Hoja de ruta del trabajo
arquitectónico.

77
Tabla 11: Artefactos de la fase B : arquitectura de negocio de TOGAF.
Artefactos
• Catálogos
◦ Catálogo de organización / actor.
◦ Catálogo de Impulsor / Meta / Objetivo.
◦ Catálogo de roles.
◦ Catálogo de servicios/funciones de negocio.
◦ Catálogo de ubicaciones.
◦ Catálogo de proceso/evento/control/producto.
◦ Catálogo de contrato/medida.
• Diagramas
◦ Diagrama de presencia del negocio.
◦ Diagrama de servicio/información.
◦ Diagrama de descomposición funcional.
◦ Diagrama de ciclo de vida del producto.
◦ Diagrama de meta/objetivo/servicio.
◦ Diagrama de casos de uso.
◦ Diagrama de descomposición de la organización.
◦ Diagrama de flujos de proceso.
◦ Diagrama de eventos.
• Matrices
◦ Matriz de interacción del negocio.
◦ Matriz de actor/rol.

3.2.5.2 Fase C: Arquitectura de sistemas de información.
La fase C: Arquitectura de sistemas de información aborda la documentación de la

estructura fundamental de los sistemas de TI de una empresa, representada por los
principales tipos de sistemas de información y aplicaciones que los utilizan. En esta fase
hay dos tipos de arquitecturas que se pueden desarrollar secuencialmente o
simultáneamente:
• Arquitectura de datos.
• Arquitectura de aplicaciones.
78
3.2.5.2.1 Arquitectura de datos.
Tabla 12: Descripción de fase C: Arquitectura de datos de TOGAF.
Objetivos Pasos
• Desarrollar la arquitectura de datos destino • Seleccionar modelos de referencia, puntos

que sea funcional a la arquitectura de de vista y herramientas.
negocio y a la visión arquitectónica, y que • Desarrollar la descripción de la línea base
responda a la vez a la Solicitud del trabajo de la arquitectura de datos.
arquitectónico y a las preocupaciones de los • Desarrollar la descripción de la arquitectura
interesados. de datos destino.
• Realizar un análisis de brechas.
• Identificar los componentes candidatos que • Definir los componentes candidatos que
podrían conformar la Hoja de ruta del conforman la Hoja de ruta del trabajo
trabajo arquitectónico basándose en las arquitectónico.
brechas identificadas entre las arquitectura • Resolver los impactos en el contexto
de datos de línea base y destino. arquitectónico.
• Conducir una revisión formal con los
interesados.
• Finalizar la arquitectura de datos.
• Crear el Documento de definición
arquitectónica.

• Evaluación de capacidades. actualizado si fuera necesario.
• Plan de comunicaciones. • Principios de datos validados.
• Modelo organizacional de arquitectura • Versión preliminar del Documento de
empresarial. definición arquitectónica, con
• Marco de referencia arquitectónico actualizaciones de contenido:
adaptado. ◦ Arquitectura de datos de línea base y
• Principios de datos. destino.
• Enunciado del trabajo arquitectónico. ◦ Vistas de la arquitectura de datos
• Visión arquitectónica. correspondiente a los puntos de vista
• Repositorio arquitectónico. seleccionados que responden a las
• Versión preliminar del Documento de preocupaciones clave de los interesados.
definición arquitectónica. • Versión preliminar del documento de
• Documento preliminar de Especificación de Especificación de requerimientos
requerimientos arquitectónicos. arquitectónicos, incluyendo actualizaciones
de contenido:
◦ Resultados del análisis de brechas
◦ Requerimientos de interoperabilidad.
◦ Requerimientos técnicos relevantes.
◦ Limitaciones de la arquitectura
tecnológica.
◦ Requerimientos de negocio y
aplicaciones actualizados.
• Componentes de la arquitectura de datos
que son parte de la Hoja de ruta del trabajo
arquitectónico.

79
En la anterior tabla, se presentan los principales componentes de la arquitectura de datos.
En esta fase, se deberán abordar las siguientes temáticas: gestión de datos, migración de
datos y gobernanza de datos.

Tabla 13: Artefactos de la fase C: Arquitectura de datos de TOGAF.
Artefactos
• Catálogos
◦ Catálogo de componentes de entidades de datos.
• Diagramas
◦ Diagrama conceptual de datos.
◦ Diagrama lógico de datos.
◦ Diagrama de diseminación de datos.
◦ Diagrama de seguridad de datos.
◦ Diagrama de migración de datos.
◦ Diagrama del ciclo de vida de datos.
• Matrices
◦ Matriz de funciones de entidades/negocio de datos.
◦ Matriz de aplicaciones/datos.

3.2.5.2.2 Arquitectura de aplicaciones.
La arquitectura de aplicaciones proporciona un modelo de referencia para el despliegue de

los sistemas de aplicaciones e información individuales, sus interacciones y sus relaciones
con las principales funciones y procesos de negocio de la organización. La arquitectura de
aplicaciones está fuertemente relacionada con la arquitectura de datos, formando en
conjunto la arquitectura de sistemas de información.
En la siguiente tabla, se presentan los principales componentes de la arquitectura de

aplicaciones.
80
Tabla 14: Descripción de fase C: Arquitectura de aplicaciones de TOGAF.
Objetivos Pasos
• Desarrollar la arquitectura de aplicaciones • Seleccionar modelos de referencia, puntos

destino que sea funcional a la arquitectura de vista y herramientas.
de negocio y a la visión arquitectónica, que • Desarrollar la descripción de la línea base
responda a la vez a la Solicitud de trabajo de la arquitectura de aplicaciones.
arquitectónico y a las preocupaciones de • Desarrollar la descripción de la arquitectura
los interesados. de aplicaciones destino.
• Realizar el análisis de brechas.
• Identificar componentes candidatos de la • Definir los componentes candidatos que
Hoja de ruta del trabajo arquitectónico conforman la Hoja de ruta del trabajo
basándose en las brechas identificadas arquitectónico.
entre las arquitectura de aplicaciones de • Resolver los impactos del contexto
línea base y destino. arquitectónico.
• Conducir una revisión formal con los
interesados.
• Finalizar la arquitectura de aplicaciones.
• Crear el Documento de definición de
arquitectónica.

• Plan de comunicaciones. • Principios de aplicaciones validados.
empresarial. definición arquitectónica, con
adaptado. ◦ Arquitectura de aplicaciones de línea
• Principios de aplicaciones. base y destino.
• Enunciado del trabajo arquitectónico. ◦ Vistas de la arquitectura de aplicaciones
• Visión arquitectónica. correspondiente a los puntos de vista
• Repositorio arquitectónico. seleccionados que responden a las
• Versión preliminar del Documento de preocupaciones clave de los interesados.
definición arquitectónica. • Versión preliminar del documento de
• Documento preliminar de Especificación de Especificación de requerimientos
requerimientos arquitectónicos. arquitectónicos, incluyendo actualizaciones
de contenido:
◦ Resultados del análisis de brechas.
◦ Requerimientos de interoperabilidad.
◦ Requerimientos técnicos relevantes.
◦ Limitaciones en la arquitectura
tecnológica.
◦ Requerimientos de negocio y datos
actualizados.
• Componentes de la arquitectura de
aplicaciones de la Hoja de ruta del trabajo
arquitectónico.

81
Tabla 15: Artefactos de la fase C: Arquitectura de aplicaciones de TOGAF.
Artefactos
• Catálogos
◦ Catálogo de portafolio de aplicaciones.
◦ Catálogo de interfaces.
• Diagramas
◦ Diagrama de comunicación de aplicaciones.
◦ Diagrama de ubicaciones de aplicaciones y usuarios.
◦ Diagrama de de casos de uso de aplicaciones.
◦ Diagrama de gestión empresarial.
◦ Diagrama de realización de procesos/aplicaciones.
◦ Diagrama de ingeniería de software.
◦ Diagrama de migración de aplicaciones.
◦ Diagrama de distribución de software.
• Matrices
◦ Matriz de aplicaciones / organización.
◦ Matriz de aplicaciones / roles.
◦ Matriz de aplicaciones / funciones.
◦ Matriz de interacción de aplicaciones.

3.2.5.3 Fase D: Arquitectura tecnológica.
La fase D: Arquitectura tecnológica aborda la documentación de la estructura esencial de

sistemas de TI, representada en hardware, software y tecnología de comunicaciones.
Describe las capacidades lógicas de software y hardware necesarias para soportar la
implementación de servicios empresariales, de datos y aplicaciones. Esto incluye
infraestructura de TI, middleware, redes, comunicaciones, procesamiento, estándares
tecnológicos, etc.
En la siguiente tabla, se presentan los principales componentes de la arquitectura de

aplicaciones.
82
Tabla 16: Descripción de fase D: Arquitectura tecnológica de TOGAF.
Objetivos Pasos
• Desarrollar la arquitectura tecnológica • Seleccionar modelos de referencia,

destino de tal manera que permita que puntos de vista y herramientas.
los componentes lógicos y físicos de • Desarrollar la descripción de la línea
datos y aplicaciones, así como aquellos base de la arquitectura tecnológica.
de la visión arquitectónica, correspondan • Desarrollar la descripción de la
a la Solicitud del trabajo arquitectónico y arquitectura tecnológica destino.
respondan a las preocupaciones de los • Realizar el análisis de brechas.
interesados. • Definir los componentes candidatos que
conforman la Hoja de ruta del trabajo
• Identificar los componentes candidatos arquitectónico.
de la Hoja de ruta del trabajo • Resolver los impactos del contexto
arquitectónico basándose en las brechas arquitectónico.
identificadas entre la arquitectura • Conducir revisiones formales con los
tecnológica de línea base y destino. interesados.
• Finalizar la arquitectura tecnológica.
• Crear el Documento de definición de
arquitectónica.

• Plan de comunicaciones. • Principios de tecnología validados.
empresarial. definición arquitectónica, conteniendo
adaptado. ◦ Arquitectura tecnológica de línea base
• Principios de tecnología. y destino.
• Enunciado del trabajo arquitectónico. ◦ Vistas de la arquitectura de
• Visión arquitectónica. aplicaciones correspondiente a los
• Repositorio arquitectónico. puntos de vista seleccionados que
• Versión preliminar del Documento de responden a las preocupaciones clave
definición arquitectónica. de los interesados.
• Documento preliminar de Especificación • Versión preliminar del documento de
de requerimientos arquitectónicos. Especificación de requerimientos
arquitectónicos, incluyendo
actualizaciones de contenido:
◦ Resultados del análisis de brechas.
◦ Requerimientos resultantes de las
Fases B y C y de tecnología
actualizados.
• Componentes de la arquitectura
tecnológica de la Hoja de ruta del trabajo
arquitectónico.

83
Tabla 17: Artefactos de la fase D: Arquitectura tecnológica de TOGAF.
Artefactos
• Catálogos
◦ Catálogo de estándares de tecnología.
◦ Catálogo de portafolio de tecnología.
• Diagramas
◦ Diagrama de entornos y ubicaciones.
◦ Diagrama de descomposición de la plataforma.
◦ Diagrama de procesamiento.
◦ Diagrama de red informática / hardware.
◦ Diagrama de ingeniería de comunicaciones.
• Matrices
◦ Matriz de aplicaciones / tecnología.
3.2.6 Iteración de transición arquitectónica.
Las iteraciones de transición arquitectónica apoyan a la creación de la Hoja de ruta para el

trabajo arquitectónico para los cambios formales para una arquitectura definida. La
descripción de las fases de la iteración de transición arquitectónica se encuentra en el
ANEXO 3: Descripción de la iteración de transición arquitectónica TOGAF 9.1. Además, una
visión general de las fases que conforman la iteración de transición arquitectónica, se
describe en el ANEXO 4: Iteración de transición arquitectónica TOGAF 9.1.
3.2.7 Iteración de gobernanza arquitectónica.
Las iteraciones de gobernanza arquitectónica apoyan al control de la actividad de cambio a

medida que se avanza hacia una arquitectura destino definida. La descripción de las fases
de la iteración de transición arquitectónica se encuentra en el ANEXO 5: Descripción de la
iteración de gobernanza arquitectónica TOGAF 9.1. Además, una visión general de las fases
que conforman la iteración de capacidad arquitectónica, se describe en ANEXO 6: Iteración
de gobernanza arquitectónica TOGAF 9.1.
84
3.2.8 Gestión de requerimientos.
El proceso de gestión de requerimientos arquitectónicos se aplica a todas las fases del ciclo
ADM. El proceso de gestión de requerimientos es un proceso dinámico que aborda la
identificación de los requerimientos de la empresa, almacenándolos, y luego gestionándolos
al ingreso y egreso de las fases relevantes del ADM.
La descripción de las fases de la iteración de transición arquitectónica se encuentra en el

ANEXO 7: Descripción de la fase de gestión de requerimientos. Además, una visión general
de las fase de gestión de requerimientos, se describe en el ANEXO 8: Gestión de
requerimientos TOGAF 9.1.
3.3 Guías y técnicas del método de desarrollo arquitectónico.
Las guías (Figura 42) son directrices que soportan la adaptación del ADM. Estas guías se
pueden adaptar a diferentes escenarios, por estilo de proceso o para una arquitectura
especifica. Incluyen las siguientes partes del documento TOGAF:
• Aplicando iteraciones al ADM.

• Aplicando ADM en diferentes niveles de la empresa.
• Arquitectura de seguridad y ADM.
• Usando TOGAF para definir y gobernar SOA.
Figura 42: Guías del ADM.

Fuente: The Open Group.
85
Las técnicas (Figura 43) soportan tareas especificas dentro de ADM tales como:
• Definición de principios arquitectónicos.

• Gestión de interesados.
• Patrones arquitectónicos.
• Escenarios de negocio.
• Análisis de brechas.
• Planificación de la migración.
• Interoperabilidad.
• Transformación empresarial.
• Gestión de riesgos.
• Planificación de la generación de capacidades.
Figura 43: Técnicas ADM.

Más información respecto a guías y técnicas del método de desarrollo arquitectónico, se

detalla en el ANEXO 9: Guías y técnicas TOGAF 9.1.
86
3.4 Marco del contenido arquitectónico.
El marco del contenido arquitectónico proporciona un modelo estructural que posibilita que
los principales productos de trabajo que un arquitecto crea, puedan ser definidos
constantemente y de una forma organizada. Usa las siguientes categorías (Figura 44) para
describir el tipo de producto arquitectónico: artefactos, entregables y bloques de
construcción.
Figura 44: Relaciones entre los productos arquitectónicos de TOGAF.

3.4.1 Artefactos.
Un artefacto es el producto de trabajo más granular. Facilita la descripción de arquitecturas

desde puntos de vista. Ejemplos: diagrama de red, especificación casos de uso. Se
subdivide en catálogos, diagramas y matrices. Más información respecto de los artefactos
que se desarrollan en el método de desarrollo arquitectónico, se detalla en el ANEXO 10:
Artefactos TOGAF 9.1.
87
3.4.2 Entregables.
Un entregable es el producto de trabajo que está contractualmente definido y que es

revisado, acordado y firmado por los actores. La unión de estos entregables forma un
proyecto. El entregable es lo que representa la salida de los proyectos dentro de las
organizaciones. Más información respecto de los entregables del método de desarrollo
arquitectónico se detalla en el ANEXO 11: Entregables TOGAF 9.1.
3.4.3 Bloques de construcción.
Representan un componente potencialmente reusable de negocios, tecnología información,

o capacidad arquitectónica, que combina otros bloques constructivos. Los bloques de
construcción pueden ser definidos a varios niveles: ABBs (architecture building blocks)
típicamente describen la capacidad requerida en forma de SBBs (solution building blocks)
que representan componentes que son usados para implementar una capacidad requerida.
3.4.4 Metamodelo de contenidos.
El metamodelo de contenidos (Figura 45) proporciona una definición de todos los tipos de
bloques de construcción que pueden existir dentro de una arquitectura. Muestra cómo estos
bloques de construcción pueden ser descritos y relacionados entre sí.
Además identifica preocupaciones, muestra las relaciones posibles entre ellas, y, finalmente,
identifica los artefactos que se pueden utilizar para que los represente. Está dividido acorde
a las fases del método de desarrollo arquitectónico:
• Principios de negocio, visión y requerimientos: Este grupo de artefactos tienen

como objetivo captar el contexto organizacional de la empresa a partir del modelado
arquitectónico.
• Arquitectura de negocio: Este grupo de artefactos intentan definir cómo opera la
empresa, cuál es motivación, cuál es su estructura y qué capacidades ha
desarrollado.
88
• Arquitectura de sistemas de información: Este grupo de artefactos capturan los
requerimientos de los sistemas de información, a partir de los modelos de datos y
aplicaciones.
• Arquitectura tecnológica: Este grupo de artefactos definen qué recursos
tecnológicos son necesarios para la implementación de la arquitectura.
• Ejecución de la arquitectura: Este grupo de artefactos permiten identificar a las
arquitecturas de transición requeridos para alcanzar la solución requerida.
Figura 45: Metamodelo de contenidos.

Fuente: The Open Group
Adaptado de The Open Group
89
3.5 Continuum empresarial.
La interpretación más sencilla de continuum empresarial es la de ser un repositorio virtual,

en el cual la organización deberá añadir y clasificar los distintos artefactos arquitectónicos.
La ventaja de coleccionar organizadamente toda esta documentación es que en distintos
procesos podrán ser reutilizados y resultará más fácil ver la forma en la que han
evolucionado. El continuum empresarial consiste tanto del continuum arquitectónico como
del continuum de soluciones.
El continuum arquitectónico especifica la estructura de los artefactos arquitectónicos

reutilizables, incluyendo reglas, representaciones y relaciones de los sistemas de
información disponibles en la organización.
Figura 46: Continuum arquitectónico.

Mientras que el continuum de soluciones describe la implementación del continuum

arquitectónico mediante la definición de bloques constitutivos de solución.
Figura 47: Continuum de soluciones.

90
3.6 Vistas, puntos de vista e interesados.
A continuación, se describen los conceptos más importantes sobre esta temática.
3.6.1 Vista.
Una vista es una representación de todo un sistema desde la perspectiva de un conjunto

relacionado de preocupaciones.
3.6.2 Punto de vista.
Un punto de vista, define la perspectiva desde la cual se toma una vista. Más
específicamente, un punto de vista define: cómo construir y utilizar un punto de vista (por
medio de un esquema o plantilla adecuada); la información que debe aparecer en la vista;
las técnicas de modelado para expresar y analizar la información; y una justificación de
estas decisiones (por ejemplo, describiendo el propósito y destinatario de la vista).
3.6.3 Interesados.
Las partes interesadas son personas que tienen un papel clave o preocupaciones sobre el
sistema; por ejemplo, usuarios, desarrolladores o administradores. Las partes interesadas
pueden ser individuos, grupos u organizaciones.
3.7 Marco de la capacidad arquitectónica.
Con el fin de operar con éxito una función arquitectónica dentro de una empresa, es
necesario poner en marcha las estructuras apropiadas de procesos, funciones,
responsabilidades y habilidades para desarrollar la capacidad arquitectónica. El marco de la
capacidad arquitectónica proporciona un conjunto de materiales de referencia para la forma
de establecer una función de este tipo de arquitectura: guías, plantillas, antecedentes, etc.
91
Figura 48: Marco de capacidades arquitectónicas
Fuente: The Open Group
Adaptado de The Open Group
3.8 Modelos de referencia.
TOGAF, en su versión 9.1, proporciona la descripción de dos modelos de referencia, los

cuales pueden ser incluidos en el continuum empresarial: el modelo de referencia técnico
(TRM, por sus siglas en inglés) y el modelo de referencia de la infraestructura de la
información integrada (III-RM).
3.8.1 Modelo de referencia técnico.
El modelo de referencia técnico es universalmente aplicable y, por lo tanto, se puede utilizar

para construir cualquier arquitectura de sistema. Su principal objetivo es proporcionar una
taxonomía núcleo ampliamente aceptada, y una representación visual apropiada de la
taxonomía.
92
3.8.1.1 Componentes del modelo de referencia técnico.
Un modelo de referencia técnico presenta los siguientes componentes:
• Una taxonomía, que define la terminología, y proporciona una descripción coherente

de los componentes y la estructura conceptual de un sistema de información.
• Un gráfico asociado, que proporciona una representación visual de la taxonomía,
como una ayuda para la comprensión.
Figura 49: Modelo de referencia técnico.

3.8.2 Modelo de referencia de la infraestructura integrada de información.
III-RM no sólo es un subconjunto del modelo de referencia técnico en términos de su

alcance general, sino que también se expande con el fin de proporcionar ayuda para hacer
frente a uno de los desafíos clave que enfrentan los arquitectos empresariales: la necesidad
de diseñar una infraestructura de información integrada que permita flujos de información sin
frontera.
93
3.8.2.1 Componentes del modelo de referencia III.
Un modelo de referencia de la infraestructura integrada de la información presenta los

siguientes componentes:
• Una taxonomía, que define la terminología, y proporciona una descripción coherente

de los componentes y la estructura conceptual de una infraestructura de información
integrada.
• Un gráfico asociado, que proporciona una representación visual de la taxonomía, y la
interrelación de los componentes como una ayuda para la comprensión.
Figura 50: Modelo de referencia de infraestructura integrada de información.

94
CAPÍTULO 4: PROPUESTA
4.1 Introducción.
Para que una PYME logre innovación en sus líneas de producción, es necesaria la
incorporación de infraestructura tecnológica adecuada, que soporte los procesos clave de la
empresa. Sin embargo, la infraestructura tecnológica seleccionada no puede estar aislada
de los objetivos e iniciativas impulsadas por el negocio.
De acuerdo al estudio desarrollado en el capítulo 1, se pudo establecer la situación actual de

las pequeñas y medianas empresas de la zona de planificación 7 de nuestro país,
evidenciándose una falta de cultura en la adopción tecnológica y de un cierto
desconocimiento de las posibilidades de aprovechar las nuevas tecnologías.
Con estos antecedentes, se evidencia la importancia de la adopción de Arquitectura

empresarial en este tipo de empresas, debido a que las prácticas de Arquitectura
empresarial guiarán y asegurarán el alineamiento estratégico entre los objetivos del negocio
y la tecnología. Con esto, las pequeñas y medianas empresas podrán alcanzar ventajas
competitivas, incursionar en nuevos mercados y generar mayores ingresos.
Por lo tanto, el presente marco arquitectónico es una guía que se ajusta a las características
identificadas en una pequeña y mediana empresa, se basa en los contenidos del marco
arquitectónico de referencia TOGAF (versión 9.1). y en las prácticas del enfoque ágil de
Arquitectura empresarial.
4.2 Criterios para la adaptación del marco de referencia arquitectónico.
A continuación, se detallan los criterios que permitirán la adaptación del marco de referencia
arquitectónico seleccionado a las características de las pequeñas y medianas empresas.
4.2.1 Características de las pequeñas y medianas empresas.
En base a la información recopilada en el capítulo 1, se presenta a continuación las

principales características de las PYMEs de la zona de planificación 7 del Ecuador:
96
Tabla 18: Características de las PYMEs de la zona de planificación 7 del Ecuador.
Dominio Características
Habilidades profesionales. • No existen programas de capacitación continua del

personal.
• Perfiles profesionales no validados o inexistentes.
• La alta dirección cuenta con escasa formación en
áreas distintas a la gestión empresarial.
Negocio. • No se cuenta con planificación estratégica

actualizada, o no está formalmente documentada.
• Los procesos de negocio no se encuentran
definidos, o no están formalmente documentados.
• La toma de decisiones se basa en la intuición.
• Estructuras organizacionales flexibles a los cambios.
• No existen estrategias de marketing ni
posicionamiento empresarial.
Tecnologías de información • No se cuenta con infraestructura tecnológica

y comunicación. adecuada.
• La inversión en TIC's es mínima.
• No se cuenta con un departamento de TIC's.
• El software empresarial apoya principalmente a las
actividades financieras o de ofimática.
• Las aplicaciones corporativas no dan soporte
completo a los procesos de negocio.
• Las adquisiciones de TIC's no se encuentran
planificadas.
• Las adquisiciones de TIC's tienen como objetivo
fundamental apoyar la gestión empresarial.
• No existen herramientas de gestión documental.
4.2.2 Recomendaciones de The Open Group para la adaptación de TOGAF
El marco de referencia arquitectónico TOGAF nace con el objetivo de brindar un enfoque

estructurado para:
• Organizaciones que necesitan un flujo de información continuo y sin fronteras.

• Empresas donde los sistemas de información son un obstáculo para la operación.
• Organizaciones que buscan impulsar el cambio estratégico del negocio, convirtiendo
las TIC's en un elemento esencial de la táctica y estrategia del negocio.
97
• Empresas cuyos objetivos estratégicos no se encuentran alineados a las
adquisiciones de activos tecnológicos.
Sin embargo, sería compleja la adopción de la estructura original del marco arquitectónico,
en organizaciones cuyas capacidades empresariales y tecnológicas no están fuertemente
consolidadas. Por esta razón, TOGAF recomienda realizar una adaptación previa al método
de desarrollo arquitectónico ADM, describiendo los siguientes escenarios en donde es
necesario el proceso de adaptación:
• El orden de las fases del método de desarrollo arquitectónico puede verse

modificado de acuerdo al nivel de madurez organizacional o por los principios de
negocio / arquitectura de la empresa. Es decir, si se han desarrollado proyectos
arquitectónicos previos en la empresa, el desarrollo arquitectónico se enfocará
principalmente en las fases relevantes con el propósito del nuevo trabajo
arquitectónico.
• Si la empresa cuenta con un marco de referencia arquitectónico u otro marco de
referencia adicional (por ejemplo: marcos de gestión de portafolio/proyecto), el
método de desarrollo arquitectónico deberá ser ajustado a los procesos de dichos
marcos.
• En empresas pequeñas y medianas, se recomienda reducir la dimensión del método
de desarrollo arquitectónico, para que el mismo se encuentre en sintonía con el nivel
de recursos de este tipo de empresas.
Todas las modificaciones que pueda sufrir el método de desarrollo arquitectónico ADM se
pueden efectuar gracias a que es un método genérico, el cual está orientado a satisfacer la
mayor parte de requerimientos organizacionales y ser utilizado en distintas circunstancias /
escenarios.
4.2.3 Características del marco de referencia orientado a PYMEs.
En base a las características identificadas en las pequeñas y medianas empresas, y a las

propiedades del enfoque ágil, se presenta a continuación los atributos que deberá incluir el
marco arquitectónico propuesto:
98
Tabla 19: Características del marco arquitectónico propuesto.
Características Descripción
Simplicidad. Basado en el entendimiento profundo de los principales

conceptos de Arquitectura empresarial, el marco deberá definir
lo esencial y clarificarlo.
Flexibilidad. La estructura del marco no debe ser rígida. Por lo tanto,

deberá facilitar su modificación y adaptación cuando las
circunstancias lo requieran.
Comprensibilidad. La estructura del marco deberá posibilitar comprensión global

y rápida respecto de las actividades a desarrollar en el
proyecto.
Vocabulario natural y El contenido del marco propuesto deberá ser expresado en

común. términos comprensibles para todas las áreas de la empresa.
Coherencia. La estructura del marco deberá ser representativa de la

madurez de la categoría de empresas en cuestión. Esto
permitirá no sobredimensionar el trabajo consecuente.
Enfoque incremental. El marco deberá estar diseñado en base a un enfoque que

posibilite distribuir el esfuerzo en secuencias lineales de
tiempo.
Orientado a la El marco deberá fomentar la participación activa de los

colaboración. involucrados en el trabajo arquitectónico, a fin de lograr
liderazgo y responsabilidades compartidas.
Trazabilidad. El marco deberá asegurar la gestión de requerimientos, a

través del ciclo de vida arquitectónico.
Multidisciplinario. El marco deberá ser capaz de condensar el conocimiento de

múltiples disciplinas a razón de satisfacer los objetivos del
proyecto arquitectónico. Además, debe posibilitar fácil
integración con las prácticas de marcos de gestión empresarial
y estándares abiertos.
Retroalimentación. El marco de referencia debe proveer mecanismos de

retroalimentación a través de las iteraciones efectuadas para
el desarrollo del trabajo arquitectónico.
Documentación. El marco de referencia deberá proporcionar la documentación

suficiente para soportar el trabajo arquitectónico, a través de
un modelo estructural sencillo de contenidos.
Fuente: Definición de marco de referencia de Arquitectura Empresarial para PYMES. -Iteraciones de

gobernanza y transición arquitectónica ADM TOGAF-. Carchi, K. (2016).
99
De la misma forma, se presentan a continuación las características que deberán desarrollar
las pequeñas y medianas empresas para lograr agilidad en sus funciones y procesos de
negocio:
Tabla 20: Características a desarrollar en las PYMEs.
Característica Descripción
Receptividad. Habilidad / capacidad para responder rápida y

eficientemente a potenciales cambios positivos en el
entorno empresarial.
Resiliencia. Habilidad / capacidad para responder rápida y

eficientemente a cambios negativos en el entorno
empresarial.
Innovación. Habilidad para introducir cambios en el entorno empresarial

a fin de alcanzar ventajas competitivas.
Convergencia. Capacidad para concentrar los puntos de vista de los

distintos grupos de interés en pro del éxito del trabajo
arquitectónico.

4.3 Marco arquitectónico propuesto.
En la Figura 51, se presenta una visión general del marco propuesto, estableciéndose los
pasos que serán desarrollados en cada fase del marco, para las iteraciones de capacidad y
desarrollo arquitectónico, que serán descritas en el presente capítulo.
Cabe destacar, que los pasos de las fases que conforman las iteraciones de gobernanza y
transición arquitectónica, son descritas en el trabajo “Definición de marco de referencia de
Arquitectura Empresarial para PYMES. -Iteraciones de gobernanza y transición
arquitectónica ADM TOGAF-.” desarrollado por Carchi, K.
A continuación, se detalla el proceso de adaptación del marco de arquitectura empresarial a

las características de las pequeñas y medianas empresas.
100
Figura 51: Visión preliminar del marco arquitectónico propuesto.
101
La Iteración de capacidad arquitectónica (Figura 52) define dos fases: fase preliminar y fase
A: visión arquitectónica, que constituyen el proceso de preparación inicial que debe sufrir
una PYME previo al desarrollo de arquitecturas empresariales. Esta iteración apoya la
definición y el desarrollo de las capacidades arquitectónicas requeridas por la empresa.
Para una visión general de los elementos que conforman esta iteración, revisar el ANEXO
12: Iteración de capacidad arquitectónica del marco de referencia adaptado.
Figura 52: Iteración de capacidad arquitectónica del marco

propuesto.
De acuerdo a la integración de Kanban y TOGAF, se presenta a continuación los tableros

que conforman esta iteración y sus respectivas relaciones:
102
Figura 53: Relaciones de los tableros de la Iteración de capacidad
arquitectónica.
La fase preliminar intenta responder las interrogantes “dónde, qué, por qué, quién y cómo”
se realizará el trabajo arquitectónico. Gracias a la revisión de los principales elementos del
contexto organizacional, la empresa es capaz de describir la necesidad del desarrollo
arquitectónico.
The Open Group (2016) sugiere que previo al desarrollo de la fase preliminar, los principales
involucrados del proyecto arquitectónico deberían dar respuesta a las siguientes
interrogantes:
• ¿Qué es la empresa y cuál es su propósito?. De esta manera, se podrá

comprender las características, necesidades y objetivos de la empresa.
• ¿Cuál es la posición estratégica, enfoque y entorno de la empresa?. Es
necesaria la revisión de 6 modelos empresariales (si existen) para determinar la
posición estratégica empresarial:
103
◦ Modelo de negocio: Describe la planificación empresarial respecto a qué
ingresos y beneficios se desean obtener.
◦ Modelo operativo: Está enfocado principalmente en las tareas y procesos
desarrollados en la empresa. Por lo tanto, define las actividades que permitirán
generar valor de negocio.
◦ Modelo organizacional: Representa la estructura organizacional de la empresa,
definiendo líneas de autoridad, comunicaciones, roles y responsabilidades.
◦ Modelo econométrico: Dota de contenido cuantitativo a fenómenos
económicos, permitiendo realizar análisis estructurales, predicciones y
simulaciones.
◦ Modelo de responsabilidad: Es empleado generalmente para asociar
actividades con recursos humanos.
◦ Modelo de gestión de riesgos: Su principal función es promover actividades y
técnicas que posibiliten la identificación y mitigación de riesgos empresariales.
• ¿Qué contexto se requiere para establecer las capacidades arquitectónicas?.

Un proyecto de transformación empresarial exitoso requiere de un horizonte de
planificación, el cual posibilite establecer estrategias alineadas a la visión de la
empresa. De esta manera, se tendrá claro el estado de la empresa en 1, 3, 5 o 10
años en el futuro.
• ¿Qué principios arquitectónicos posibilitarán la creación de oportunidades?.

Desde la revisión del contexto organizacional, la empresa requiere la identificación
de potenciales principios que posibiliten: toma de decisiones, alineación estratégica,
gobernanza y reacción a los cambios.
4.3.1.1.1 Objetivos.
La fase preliminar busca el cumplimiento de dos objetivos: identificar las capacidades que
espera lograr la empresa luego del trabajo arquitectónico y planificar el proceso de
generación de dichas capacidades. A continuación, se describe el proceso de evaluación de
los objetivos proporcionados por el marco arquitectónico TOGAF y su adaptación a las
características de las PYMEs:
104
Tabla 21: Evaluación de los objetivos de la fase preliminar del marco propuesto.
Objetivos Objetivos
Adaptación
originales resultantes
1. Determinar las Tipo de adaptación: semántico. 1. Determinar las

capacidades capacidades
deseadas por la Fundamento: empresariales
organización: que se
◦ Examinar el • Considerando los criterios de ajuste para pretenden
contexto alcanzar gracias
el marco propuesto, se ha decidido
organizacional al trabajo
simplificar el enunciado del objetivo,
para llevar a arquitectónico.
omitiendo las actividades a desarrollar,
cabo el
proyecto de las mismas que serán descritas
arquitectura posteriormente en los pasos de la fase y
empresarial. así facilitar la comprensión del lector.
◦ Identificar y
determinar el Criterios de ajuste: simplicidad,
alcance de las comprensibilidad y vocabulario natural y
unidades de la común.
empresa que
serán
afectadas por
la capacidad
arquitectónica.
◦ Identificar
marcos de
referencia
establecidos,
métodos y
procesos que
se entrecrucen
con la
capacidad
arquitectónica.
◦ Establecer la
madurez de la
capacidad
destino.
2. Establecer las Tipo de adaptación: semántico. 2. Planificar el

capacidades proceso de
arquitectónicas: Fundamento: generación de
◦ Definir y capacidades.
establecer el
• Se replanteó el enunciado, con el fin de
modelo
lograr una mejor comprensión sobre el
organizacional
de arquitectura
objetivo a cumplir. Además, se omitió la
empresarial. actividad a desarrollar, la cual será
incluida en los pasos de la fase.
Criterios de ajuste: simplicidad,

vocabulario natural y común.
105
Observaciones:
• Los objetivos de esta fase son imprescindibles en el proceso de preparación inicial

que debe sufrir una empresa previo a la adopción de las prácticas de Arquitectura
empresarial.
• Las modificaciones efectuadas a los objetivos de la fase preliminar fueron
principalmente de tipo semántico.
• Se ha decidido preservar la idea original de los objetivos a cumplir en esta fase,
modificando sus enunciados a fin de conseguir mejor comprensión de los mismos.
4.3.1.1.2 Pasos.
En la Tabla 22, se presenta el proceso de evaluación de los pasos de la fase preliminar del
marco arquitectónico TOGAF 9.1, que serán ajustados a las características de las PYMEs.
Tabla 22: Evaluación de los pasos de la fase preliminar del marco propuesto.
Pasos originales Adaptación Pasos resultantes
1. Determinar las Tipo de adaptación: ajustado a las 1. Elaborar o

áreas de la características de las PYMEs. actualizar la
empresa que planificación
serán estratégica.
impactadas.
Fundamento:
• El paso inicial de la fase preliminar de

TOGAF, intenta describir la necesidad
del trabajo arquitectónico, gracias al
entendimiento de los objetivos que
persigue la empresa y del contexto
organizacional en el que participa.
• Aramayo (2016), expresa que la

planificación estratégica es un medio por
el cual las empresas intentan alcanzar
sus objetivos estratégicos, en donde se
considera una visión integral a largo
plazo, y una apropiación del contexto
organizacional.
106
• Con estos antecedentes, se puede

establecer que para entender el contexto
empresarial y por consiguiente definir la
necesidad del trabajo arquitectónico, es
imprescindible la revisión de la
planificación estratégica de la empresa.
• Sin embargo, de acuerdo a las

características identificadas en las
PYMEs y al reporte desarrollado por el
Ministerio de Industrias y Productividad*,
se logró establecer que un gran número
de empresas de este tipo no cuentan con
planificación estratégica o la misma no
se encuentra actualizada.
• Por tal razón, se consideró pertinente

iniciar el proyecto arquitectónico
validando la existencia de la planificación
estratégica de la empresa.
Criterios de ajuste: coherencia.
Consideraciones:
◦ Es muy importante que se contemple

el desarrollo de un diagnóstico de TI,
como una de las actividades
resultantes de la planificación
estratégica de la empresa.
◦ Una herramienta útil para dar

seguimiento al cumplimiento de la
planificación estratégica es el Cuadro
de Mando Integral (CMI).
2. Confirmar los Tipo de adaptación: ajustado a las 2. Seleccionar

marcos de características de las PYMEs. marcos de
referencia de referencia de
gobernanza y de Fundamento: gestión
soporte empresarial.
adicional. • Los marcos de gestión empresarial
permiten la generación de capacidades
operativas. Dentro de este tipo de
marcos, se pueden mencionar las
siguientes categorías:
◦ Marcos de gestión de proyectos:

Proporcionan un enfoque para la
107
óptima gestión de las actividades y

recursos de los proyectos
empresariales.
◦ Marcos de gestión de portafolio de

proyectos: Permiten la selección de
proyectos y programas adecuados que
apoyen la consecución de los objetivos
estratégicos.
◦ Marcos de gestión de operaciones:

Administran la operaciones diarias de
la empresa, incluyendo las
relacionadas con tecnología.
◦ Marcos de gestión de riesgos:

Brindan soporte para la gestión de los
riesgos en toda la empresa.
◦ Marcos de gestión de gobernanza:

Apoyan la implementación de distintos
aspectos del Gobierno de TI.
• Tomando en cuenta el reporte de la

situación actual de las PYMEs
anteriormente mencionado, se pudo
determinar que la gran mayoría de
PYMEs no cuentan con marcos de
gestión empresarial. Por tal motivo, se
redefinió el paso para indicar la
necesidad de seleccionar marcos de
gestión empresarial, de los cuales se
identificarán las mejores prácticas en el
paso número 5.
Consideraciones:
• A continuación, se sugiere un listado de

marcos de los cuales las PYMEs podrían
adoptar sus mejores prácticas:
◦ Gestión de proyectos: PMBOK.
◦ Gestión de portafolio de proyectos:
CREOPM.
◦ Gestión de operaciones: ITIL.
◦ Gestión de riesgos: COSO.
◦ Gestión de gobernanza: COBIT.
Criterio de ajuste: coherencia,

multidisciplinario.
108
3. Definir y Tipo de adaptación: ajustado a las 3. Establecer los

establecer el características de las PYMEs. roles y
equipo de responsabilidad
Arquitectura Fundamento: es específicos
empresarial y su bajo demanda
organización. • La estructuración de un equipo de del equipo de
Arquitectura empresarial completo en Arquitectura
una PYME, representaría muchas empresarial y su
complicaciones a nivel de presupuesto, organización.
perfiles profesionales y cultura
organizacional, por lo que redefinió el
paso indicando que se establecerán los
roles y responsabilidades específicos
bajo demanda.
Criterios de ajuste: coherencia,

flexibilidad.
Consideraciones:
• Los roles mínimos que una PYME

debería cubrir son:
◦ Arquitecto en jefe: Responsable de la
gestión arquitectónica en la empresa.
◦ Arquitecto de software: Principal
responsable de la toma de decisiones
técnicas.
◦ Arquitecto de integración:
Responsable de la integración de
aplicaciones, integración de datos e
integración de procesos.
• El proceso de conformación del equipo

de arquitectura empresarial deberá ser
documentado en el entregable
Estructura del equipo de arquitectura
empresarial y su organización.
4. Identificar y Tipo de adaptación: ninguno. 4. Identificar y

establecer los establecer los
principios Consideraciones: principios
arquitectónicos. arquitectónicos.
• Se sugiere hacer uso de la técnica
Principios arquitectónicos descrita en el
marco TOGAF, en la cual se establecen
lineamientos para la definición de
principios arquitectónicos. Además, se
presentan un conjunto de principios de
ejemplo.
109
• La definición de los principios

arquitectónicos de la empresa deberá
ser documentada en el entregable
Principios arquitectónicos y una visión
general de los mismos deberá ser
descrita en el artefacto Catálogo de
Principios arquitectónicos.
5. Adaptar TOGAF Tipo de adaptación: ajustado a las 5. Identificar las

y, si es características de las PYMEs. mejores
necesario, otros prácticas de los
marcos de Fundamento: marcos de
referencia gestión
arquitectónicos • Considerando que la madurez empresarial e
seleccionados. arquitectónica de las PYMEs es integrarlas con
limitada*, se estableció que este tipo de el marco
empresas no están en condiciones de arquitectónico
adoptar marcos de gestión empresarial propuesto.
en su total dimensión. Por lo tanto, se
sugiere que las PYMEs asuman las
mejores prácticas de los marcos
seleccionados en el paso 2, los cuales
se ajustan a las necesidades y
características de este tipo de empresas.
Consideraciones:
• Las mejores prácticas identificadas

deberán ser documentadas en el
entregable Marco arquitectónico
adaptado.
Criterios de ajuste: coherencia,

multidisciplinario.
6. Implementar Tipo de adaptación: ajustado a las 6. Implementar y

herramientas características de las PYMEs. configurar el
arquitectónicas. repositorio
Fundamento: arquitectónico
empresarial.
• Desarrollar un proyecto de arquitectura
empresarial, conlleva la responsabilidad
de gestionar eficazmente la información
resultante. La herramienta que permite la
gestión de los productos arquitectónicos
de la empresa es el repositorio
arquitectónico.
110
• TOGAF propone una estructura compleja

para el repositorio arquitectónico. Por tal
motivo, se sugiere la adopción de
herramientas de gestión de contenido
empresarial (ECM, por sus siglas en
inglés) que faciliten la gestión de los
productos arquitectónicos de la empresa.
• Como la principal herramienta a ser

implementada en esta fase es el
repositorio arquitectónico empresarial, se
redefinió el paso para especificar la
implementación y configuración de esta
herramienta.
Criterios de ajuste: coherencia y

documentación.
Consideraciones:
• Una visión general de la estructura del

repositorio implementado deberá ser
descrita en el entregable Marco
arquitectónico adaptado.
* Situación de las TIC en las PYMEs del Ecuador. MIPRO (2012).
Observaciones:
• Los pasos originales de la fase preliminar del marco arquitectónico TOGAF

requirieron ajuste a las características y capacidades de las pequeñas y medianas
empresas, debido a que el marco de referencia TOGAF está orientado a empresas
con estructuras organizacionales consolidadas.
• Se ha conservado la idea fundamental de esta fase que es desarrollar un proceso de
preparación previo a la adopción de prácticas de Arquitectura empresarial.
4.3.1.1.3 Productos arquitectónicos.
Se evaluaron los productos arquitectónicos (artefactos y entregables) para validar su

importancia en el proceso arquitectónico y la estructura de sus contenidos.
111
4.3.1.1.3.1 Artefactos.
En la fase preliminar de TOGAF 9.1, se establece la utilización de un sólo artefacto:

Catálogo de principios, el cual se evalúa en la siguiente tabla:
Tabla 23: Evaluación de los artefactos de la fase preliminar.
Iteraci
ón
Fase Tipo Nombre Evaluación
Fase Catálogo. Catálogo de principios. Un Catálogo de principios

Capacidad
preliminar proporciona una versión resumida

de los principios arquitectónicos
definidos para el proyecto, la cual
facilita la comprensión de los
involucrados. Por lo tanto, se
considera pertinente su utilización.
4.3.1.1.3.2 Entregables.
En la siguiente tabla, se describe la evaluación desarrollada de los entregables de la fase

preliminar del marco arquitectónico de referencia:
Tabla 24: Evaluación de los entregables de la fase preliminar.
Uso de la
Iteración Fase Nombre Ponderación Evaluación
plantilla
Fase Solicitud de Media • TOGAF 9.1 expresa que la --

Capacidad
preliminar trabajo Solicitud de trabajo

arquitectónico arquitectónico es el punto
de partida del proyecto.
• Representa un tipo de
contrato entre las partes
involucradas. Sin embargo,
al contener información
descrita en un alto nivel de
detalle, podría generar
dificultades para su
desarrollo.
• Se sugiere reemplazar este
entregable por un contrato
de trabajo simple.
112
Uso de la
plantilla
Modelo Media • Para asegurar el desarrollo Adaptada

organizacional exitoso del proyecto
de arquitectura
empresarial.
arquitectónico, resulta
imprescindible la definición
de la estructura del equipo
de arquitectura empresarial.
• Gracias a este entregable
se podrá establecer qué
roles y qué
responsabilidades son
necesarias cubrir para el
desarrollo efectivo del
trabajo arquitectónico.
• Para un fácil entendimiento
del contenido del
entregable, se cambiará su
nombre por Estructura del
equipo de arquitectura
empresarial y su
organización.
Principios Alta • Cualquier empresa que Completa

arquitectónicos. inicie proyectos de
arquitectura empresarial,
requiere de directrices que
garanticen y gobiernen el
cumplimiento del trabajo
planificado. Es allí, donde
surge la necesidad de la
definición de principios
arquitectónicos en las
PYMEs, los cuales se
constituirán como la base
para la toma de decisiones
en la empresa.
Principios de Media • Aunque el contenido de –

negocio, este entregable posibilita
objetivos, e refinar la estrategia del
impulsores. negocio y establecer la
visión empresarial, no se
contempla la utilización de
este producto arquitectónico
debido a que su contenido
ha sido incluido en otros
entregables.
113
Uso de la
plantilla
Repositorio Media • Una herramienta útil para --

arquitectónico. organizar y compartir la
información generada a lo
largo de las fases del
proyecto de arquitectura
empresarial es el repositorio
arquitectónico.
• Un repositorio
arquitectónico
correctamente estructurado
permitirá a los involucrados
tomar decisiones oportunas
en base a información
precisa y organizada.
• Al ser la principal
herramienta a configurarse
en esta fase, el proceso de
implementación de la
misma será incluida en el
entregable Marco
arquitectónico adaptado,
por lo tanto no se hará uso
de la plantilla de este
entregable.
Marco Alta • Como se ha explicado a lo Adaptada

arquitectónico largo del presente trabajo,
adaptado. resulta indispensable la
adaptación previa del marco
de arquitectura empresarial
en base a las
características de la
empresa.
• Las adaptaciones
desarrolladas sobre el
marco arquitectónico
deberán ser documentadas
en este entregable.
En la siguiente tabla, se presentan los productos arquitectónicos (entradas y salidas) que

deberán ser considerados para el desarrollo de la fase preliminar del marco propuesto. Las
entradas y salidas originales del marco arquitectónico base (TOGAF 9.1) pueden ser
revisadas en la página 73.
114
Tabla 25: Productos arquitectónicos de la fase preliminar del marco propuesto.
Entradas de TOGAF 9.1 Entradas del marco propuesto
• Otros marcos de referencia Entradas no arquitectónicas:

arquitectónicos. • Estrategias, planes y principios de
• Estrategias del consejo organizacional, negocio. *
planes de negocio; estrategia de negocio; • Estrategias de TI. *
estrategia de TI; principios de negocio, • Marcos legales. *
objetivos de negocio e impulsores del • Contratos. *
negocio. • Planificación estratégica de la empresa. *
• Marcos de referencia de gobernanza.
• Capacidades arquitectónicas.
• Acuerdos de asociación y contratos.
• Modelo organizacional de Arquitectura
empresarial existente.
• Marco de referencia arquitectónico
existente, si lo hay, incluyendo:
◦ Método arquitectónico.
◦ Contenido arquitectónico.
◦ Herramientas configuradas e
implementadas.
◦ Principios arquitectónicos.
◦ Repositorio arquitectónico.
Salidas de TOGAF 9.1 Salidas del marco propuesto
• Modelo organizacional de arquitectura Salidas no arquitectónicas:

empresarial. • Elaboración o actualización de la
• Marco de referencia arquitectónico planificación estratégica de la empresa.
adaptado, incluyendo principios
arquitectónicos. Salidas arquitectónicas:
• Repositorio arquitectónico inicial. • Artefactos:
• Reafirmación o referencia de los ◦ Catálogo de principios arquitectónicos.
principios, objetivos impulsores del • Entregables:
negocio. ◦ Estructura del equipo de arquitectura
• Solicitud de trabajo arquitectónico. empresarial y su organización.
• Marco de referencia de gobernanza. ◦ Principios arquitectónicos.
◦ Marco arquitectónico adaptado.
* Si existen.
A continuación, se describen los cambios efectuados en la estructura (contenidos) de los

entregables que conforman la fase preliminar:
• Estructura del equipo de arquitectura empresarial y su organización.
El entregable Estructura del equipo de arquitectura empresarial y su organización (que

corresponde al entregable Modelo Organizacional de arquitectura empresarial del marco
115
arquitectónico base) documenta los roles y responsabilidades de quienes llevarán a cabo el
proyecto arquitectónico. En cuanto a la estructura del entregable, considerando que se
pretende lograr simplicidad, se desarrollará una versión más compacta de los apartados del
mismo.
Tabla 26: Evaluación del entregable Estructura del equipo de arquitectura empresarial.
Contenido original Adaptación Contenido resultante
1. Propósito del • Ninguno. 1. Propósito del documento

documento.
2. Alcance de las áreas • Es necesario que se 2. Unidades involucradas

afectadas. indiquen las unidades con el proyecto
1. Alcance. funcionales de la arquitectónico.
empresa con las que
interactuarán los
integrantes del equipo de
• Se replanteó el
enunciado del apartado,
a fin de lograr mayor
comprensión del
contenido a desarrollar.
Criterios de ajuste:
comprensibilidad.
3. Evaluación de madurez, • No se consideró este --

brechas y resoluciones apartado, pues de
aproximadas. acuerdo a las
1. Evaluación de características
madurez. identificadas en las
2. Brechas. PYMEs, las empresas no
3. Enfoque de cuentan con un equipo
resolución. de arquitectura
empresarial ni con los
profesionales que
puedan cumplir los roles
requeridos para la
conformación del mismo.
coherencia.
4. Roles y • Ninguno. 3. Roles y

responsabilidades. responsabilidades.
1. Roles y 1. Roles y
responsabilidades RACI. responsabilidades RACI.
116
5. Limitaciones. • Considerando los 4. Limitaciones.

1. Limitaciones. criterios de ajuste del 1. Limitaciones a nivel
2. Limitaciones a nivel marco arquitectónico organizacional.
organizacional. propuesto, se sintetizó el 2. Limitaciones de
3. Requerimientos de contenido de este punto presupuesto.
información y para lograr una
limitaciones de estructura más sencilla
presupuesto. del mismo.
4. Limitaciones
externas y de negocio. Criterios de ajuste:
simplicidad.
6. Requerimientos de • Considerando los 5. Presupuesto.

presupuesto. criterios de ajuste del
1. Requerimientos. marco arquitectónico
propuesto, se sintetizó el
enunciado del apartado
como Presupuesto, que
engloba el contenido a
desarrollar en este
punto.
simplicidad y vocabulario
natural y común.
7. Gobernanza y estrategia • Ninguno. 6. Gobernanza y estrategia

de soporte. de soporte.
1. Estructura de la 1. Estructura de la
gobernanza. gobernanza.
2. Estrategia de 2. Estrategia de
soporte. soporte.
• Principios arquitectónicos.
El entregable Principios arquitectónicos documenta la definición de los principios que

orquestarán el trabajo arquitectónico a lo largo del proyecto. La estructura original del
documento contiene los elementos necesarios para definir los principios arquitectónicos de
la empresa, por lo cual no se efectuarán cambios sobre la misma.
117
Tabla 27: Estructura resultante del entregable Principios arquitectónicos.
Contenido resultante
1. Propósito del documento.

2. Descripción de principios arquitectónicos.
3. Listado de principios.
4. Principios de negocio.
5. Principios de datos.
6. Principios de aplicaciones.
7. Principios de tecnología.
• Marco arquitectónico adaptado.
El entregable Marco arquitectónico adaptado contiene los ajustes específicos que se han
desarrollado al marco de referencia TOGAF. A continuación, se describe la estructura
resultante del entregable:
Tabla 28: Evaluación del entregable Marco arquitectónico adaptado.
1. Propósito del documento. • Ninguno. 1. Propósito del documento.
2. Método de desarrollo • Ninguno. 2. Método de desarrollo

arquitectónico. arquitectónico.
1. Método 1. Método
arquitectónico. arquitectónico.
3. Contenido arquitectónico • Ninguno. 3. Contenido arquitectónico

adaptado. adaptado.
1. Entregables 1. Entregables
2. Artefactos 2. Artefactos
4. Herramientas configuradas • La principal herramienta a 4. Continuum empresarial y

e implementadas. implementar en esta fase herramientas.
1. Herramientas. es el repositorio 1. Continuum
arquitectónico. Sin arquitectónico.
embargo, para 2. Continuum de
complementar la estructura soluciones.
del repositorio se ha creído 3. Repositorio
conveniente describir al arquitectónico.
Continuum empresarial,
contenedor que engloba a
118
la herramienta
mencionada.
simplicidad, documentación.
5. Interfaces con modelos y • Como se explicó 5. Mejores prácticas de los

marcos de gobernanza . anteriormente, las PYMEs marcos de gestión
1. Marcos de no están en condiciones de empresarial seleccionados.
arquitectura empresarial. adoptar marcos de gestión
2. Marcos de gestión de empresarial en su
capacidades. dimensión original. Por tal
3. Marcos de gestión de motivo, se describirán las
portafolios. mejores prácticas que se
4. Marcos de gestión de identificaron en el paso
proyectos. número 5 de esta fase.
5. Marcos de gestión de
operaciones. Criterios de ajuste:
coherencia, multidisciplinario.
4.3.1.1.4 Herramientas adicionales.
Durante el desarrollo de la fase, existen algunas herramientas que pueden apoyar la

ejecución de los pasos (al ser herramientas adicionales, su implementación es opcional).
Tabla 29: Herramientas adicionales de la fase preliminar del marco propuesto.
Tipo Nombre Descripción
Herramienta Gestores de Soluciones que permiten la administración de los

contenido contenidos y documentos que se generan en la
empresarial (ECM). empresa, posibilitando su integración en la
automatización de procesos.
Técnica Principios Directriz que ofrece una guía de elaboración de

arquitectónicos. principios arquitectónicos. Ofrece un conjunto de
principios de ejemplo para su utilización.
De manera general, se presenta en la Figura 54 un cuadro resumen de los cambios

efectuados en la fase preliminar del marco arquitectónico.
119
Figura 54: Cuadro resumen de los cambios de la fase preliminar.
120
Gracias a la integración del marco arquitectónico TOGAF y a la técnica ágil, se presenta en
la siguiente figura el tablero resultante de la fase preliminar del marco propuesto.
Figura 55: Tablero Kanban de la fase preliminar.

Dentro de esta fase, la PYME estará en capacidad de clarificar el propósito del trabajo
arquitectónico, lo cual le permitirá articular su visión a los objetivos del negocio, responder a
los impulsores estratégicos, refinar sus principios arquitectónicos y abordar las
preocupaciones de los grupos de interés.
Además, se deberá establecer el alcance del trabajo arquitectónico, el cual debe estar
diseñado en base a una evaluación práctica de recursos y capacidades disponibles, y en el
valor que realmente pueda desarrollar la empresa luego del ejercicio arquitectónico. De esta
manera, la empresa podrá establecer los límites de la arquitectura, definiendo lo que estará
dentro y fuera del alcance del esfuerzo arquitectónico.
121
Como se mencionó anteriormente, la fase A: Visión arquitectónica proporciona un panorama

de alto nivel de la motivación del trabajo arquitectónico. A continuación, se describe el
proceso de evaluación de los objetivos proporcionados por el marco arquitectónico TOGAF y
su adaptación a las características de las PYMEs:
Tabla 30: Evaluación de los objetivos de la fase A del marco propuesto.
Objetivos originales Adaptación Objetivos resultantes
1. Desarrollar una visión Tipo de adaptación: 1. Desarrollar una visión

de alto nivel de las semántico. de alto nivel de las
capacidades y del valor capacidades y del valor
de negocio que se Fundamento: negocio deseados.
desean obtener como
resultado del trabajo • Se simplificó el
arquitectónico. enunciado del objetivo,
a fin de lograr una
rápida comprensión del
propósito que se
pretende alcanzar.
simplicidad,
comprensibilidad.
2. Obtener la aprobación Tipo de adaptación: 2. Obtener la aprobación

del Enunciado del semántico. del entregable
trabajo arquitectónico, Enunciado del trabajo
que define un Fundamento: arquitectónico.
programa de trabajo
para desarrollar e • Se simplificó el
implementar la enunciado del objetivo,
arquitectura descrita en a fin de lograr una
la Visión arquitectónica. rápida comprensión del
propósito que se
pretende alcanzar.
simplicidad,
comprensibilidad.
122
4.3.1.2.2 Pasos.
En la Tabla 31, se presenta el proceso de evaluación de los pasos de la fase A del marco
arquitectónico TOGAF 9.1, que serán ajustados a las características de las PYMEs.
Tabla 31: Evaluación de los pasos de la fase A del marco propuesto.
1. Establecer el Tipo de adaptación: ninguno. 1. Establecer el

proyecto proyecto
arquitectónico. Consideraciones: arquitectónico.
• En este paso, se planificará la ejecución

de los ciclos del método de desarrollo
arquitectónico, de acuerdo a las
prácticas del marco de gestión de
proyectos (PMBOK), que se identificaron
en el paso número 5 de la fase
preliminar.
• Este proceso de planificación deberá ser

documentado en el entregable Marco
arquitectónico adaptado (desarrollado
en la fase preliminar) y también será una
entrada para el desarrollo del entregable
Enunciado del trabajo arquitectónico
(apartado 6).
2. Identificar Tipo de adaptación: ninguno. 2. Identificar

interesados, interesados,
preocupaciones Consideraciones preocupaciones
y requerimientos y
de negocio. • Se sugiere que para el desarrollo de requerimientos
este paso se utilice la técnica Gestión de del negocio.
interesados propuesta por TOGAF, la
cual proporciona un proceso para la
gestión de los principales interesados
del trabajo arquitectónico.
• La información producida en este paso

deberá ser incluida en el entregable
(apartado 4).
123
• De la misma manera, como producto de

este paso se desarrollará el artefacto
mapa de interesados, que describe de
forma resumida a los involucrados en el
esfuerzo arquitectónico, su nivel de
participación y sus principales
preocupaciones.
3. Confirmar y Tipo de adaptación: ninguno. 3. Confirmar y

elaborar elaborar
objetivos, Consideraciones: objetivos,
impulsores y impulsores y
limitaciones del • La información producida en este paso limitaciones del
negocio. deberá ser incluida en los entregables negocio.
Visión arquitectónica (apartado 3) y
(apartado 3).
4. Evaluar las Tipo de adaptación: combinado. 4. Evaluar las

capacidades del capacidades
negocio. Fundamento: empresariales.
• Se integraron los pasos Evaluar las

capacidades del negocio (paso 4) y
Evaluar la preparación para la
transformación del negocio (paso 5),
bajo el enunciado Evaluación de
capacidades empresariales (ahora paso
4), debido a que son actividades
complementarias.
• Pese a que esta evaluación, en este tipo

de empresas, podría revelar resultados
muy bajos, este paso es importante
porque permitirá identificar limitaciones
que deberán reevaluarse en las fases E
y F. A diferencia del diagnóstico de TI,
esta evaluación posee un mayor nivel de
detalle.
• Una buena práctica descrita por TOGAF

en este paso es el desarrollo del
artefacto Diagrama de cadena de valor,
para contrastar las capacidades
empresariales con el contexto
empresarial.
124
• Esta evaluación se documenta en el

entregable Evaluación de capacidades.
Criterios de ajuste: simplicidad,

flexibilidad, comprensibilidad.
5. Evaluar la • Este paso ha sido integrado en el paso --

preparación número 4.
para la
transformación
del negocio.
6. Definir el Tipo de adaptación: ninguno. 5. Definir el

alcance. alcance.
Consideraciones:
• Como parte del proceso de definición del

alcance del trabajo arquitectónico, la
empresa deberá establecer:
◦ Las áreas de la empresa que estarán
involucradas.
◦ Tiempo estimado que durará el
proyecto arquitectónico.
◦ Nivel de formalidad requerido para el
desarrollo de los productos
arquitectónicos.
• La definición del alcance del proyecto

arquitectónico deberá ser documentada
en el entregable Enunciado del trabajo
arquitectónico (apartado 3).
7. Confirmar y Tipo de adaptación: semántico. 6. Refinar los

elaborar principios
Principios • Considerando los criterios de ajuste del arquitectónicos,
arquitectónicos, marco propuesto, se redefinió el si es necesario.
incluyendo enunciado del paso, a fin de conseguir
principios de una rápida comprensión del trabajo a
negocio. desarrollar.
Criterios de ajuste: comprensibilidad y

simplicidad.
Consideraciones:
• Si existen cambios sobre los principios

arquitectónicos de la empresa, es
125
necesario actualizar el entregable

Principios arquitectónicos y el artefacto
Catálogo de Principios arquitectónicos.
8. Desarrollar la Tipo de adaptación: ninguno. 7. Desarrollar la

visión visión
arquitectónica. Consideraciones: arquitectónica.
• Una buena práctica descrita por TOGAF

para el desarrollo de la visión
arquitectónica de la empresa es la
elaboración del artefacto Diagrama de
concepto de solución, que ilustra los
principales componentes de la solución y
muestra cómo ésta será beneficiosa
para la empresa.
• El desarrollo de la visión arquitectónica

que desea alcanzar la empresa deberá
ser documentada en el entregable
Visión arquitectónica.
9. Definir las Tipo de adaptación: semántico. 8. Definir los

propuestas de beneficios que
valor de la Fundamento: entregará la
arquitectura arquitectura
destino e • Medina (2014) define a una propuesta destino y los
indicadores de valor como el conjunto de ventajas o indicadores
claves de diferenciadores que nacen como claves de
desempeño. resultado de la adopción de una desempeño.
solución.
• Los indicadores claves de rendimiento

(KPIs, por sus siglas en inglés) definen
métricas para cuantificar los resultados
de la solución arquitectónica a partir de
los objetivos establecidos en la
planificación estratégica (desarrollada
en la fase preliminar).
• Considerando los criterios de ajuste del

marco propuesto, se redefinió el
enunciado del paso, para manejar un
vocabulario que sea comprensible para
los principales interesados del proyecto.
Criterios de ajuste: simplicidad y

126
Consideraciones:
• Existen tres enfoques para definir

medidores claves de desempeño:
◦ Orientados al fin.
◦ Orientados al tiempo.
◦ Orientados a la operación.
• Para la definición de indicadores claves

de desempeño, se suele tomar como
referencia el acrónimo SMART:
◦ Specific (Específicos).
◦ Measurable (Medibles).
◦ Achiveable (Alcanzables).
◦ Realistic (Realistas).
◦ Timely (Medibles en el tiempo).
• Los beneficios que se obtendrán a partir

de la implementación de la arquitectura
destino, deberán estar alineados a los
indicadores clave de desempeño.
• La información resultante de este paso

apoyará el desarrollo del entregable
Enunciado del trabajo arquitectónico.
10. Identificar Tipo de adaptación: semántico. 9. Identificar

riesgos de la riesgos y
transformación Fundamento: actividades de
del negocio y mitigación.
actividades de • Considerando los criterios de ajuste del
mitigación. marco propuesto, se sintetizó el
enunciado del paso a fin de comprender
con rapidez el trabajo a efectuar.
• Criterios de ajuste: simplicidad,

Consideraciones:
• El proceso de identificación de riesgos

deberá desarrollarse de acuerdo a las
prácticas del marco de gestión de
riesgos, identificadas en el paso número
5 de la fase preliminar.
127
• Se sugiere considerar la técnica Gestión

de riesgos propuesta por TOGAF, en la
que se describen lineamientos para la
identificación de riesgos.
• Los riesgos identificados y su posterior

análisis deberán ser documentados en el
entregable Enunciado del trabajo
arquitectónico (apartado 7).
11. Desarrollar el Tipo de adaptación: ninguno. 10. Desarrollar el

Enunciado del Enunciado del
trabajo trabajo
arquitectónico; arquitectónico;
asegurar su asegurar su
aprobación. aprobación.
Observaciones:
• Los pasos de esta fase no sufrieron modificaciones sustanciales, debido a que son
elementos imprescindibles de las prácticas de arquitectura empresarial. Sin
embargo, se determinaron las herramientas que facilitarán el desarrollo de los pasos
de la fase.

En la siguiente tabla, se presenta la evaluación desarrollada sobre los artefactos de la fase

A: visión arquitectónica:
128
Tabla 32: Evaluación de los artefactos de la fase A.
Iteraci
ón
Visión arquitectónica.
Diagrama Diagrama de cadena El diagrama de cadena de valor es
Capacidad
de valor. una poderosa herramienta de

análisis, cuyo propósito es apoyar
en el proceso de planificación
estratégica, identificando
oportunidades para generar
ventajas competitivas.
Diagrama Diagrama de concepto El diagrama de concepto de

de solución. solución es un artefacto importante
en el proceso arquitectónico
porque representa un “bosquejo
de lápiz” de la solución esperada
desde el inicio del trabajo
arquitectónico.
Matriz Mapa de interesados. En una pequeña y mediana

empresa sería importante el uso
de un mapa de interesados puesto
que al comprender el grupo de
interés se podrá centrar esfuerzos
en las áreas que satisfagan las
necesidades de los interesados.
En la siguiente tabla, se describe la evaluación desarrollada de los entregables de la fase A

del marco arquitectónico de referencia:
Tabla 33: Evaluación de los entregables de la fase A.
Uso de la
plantilla
Visión Evaluación de Alta • Un paso importante a Completa

Capacidad
arquitect capacidades desarrollar, previo a la

ónica. descripción de las
arquitecturas requeridas, es
la evaluación de las
capacidades de la empresa.
129
Uso de la
plantilla
• El entregable evaluación de
capacidades posibilita la
comprensión del nivel de
capacidad actual y futuro de
la empresa en cuatro
dominios: negocio, TI,
madurez arquitectónica y
preparación de la
transformación del negocio.
Plan de Media • Un aspecto importante para --

comunicaciones garantizar el éxito del
trabajo arquitectónico es la
difusión y comunicación de
la información generada en
el proyecto.
• Para conseguir una
adecuada comunicación es
necesario planificar y
gestionar este proceso. De
allí, la importancia de la
definición de un plan de
comunicaciones, el cual
constituye una herramienta
que recoge los
involucrados, mecanismos y
tipos de comunicación para
el proyecto de arquitectura
empresarial.
• Se integrará el contenido
del Plan de
comunicaciones en el
entregable Enunciado del
Visión Alta • El entregable Visión Adaptada

arquitectónica arquitectónica tiene gran
utilidad debido a que
proporciona una versión
resumida de la arquitectura
resultante.
• La visión arquitectónica es
una conceptualización ideal
documentada del proyecto
que permitirá establecer
acciones y decisiones con
mayor facilidad.
130
Uso de la
plantilla
Enunciado del Alta • El entregable Enunciado Adaptada

trabajo del trabajo arquitectónico es
arquitectónico uno de los principales
entregables para el
desarrollo de la
arquitectura, debido a que
es el documento contra el
cual se medirá la correcta
ejecución del proyecto.
En la siguiente tabla, se presentan los productos arquitectónicos que deberán desarrollarse

durante la fase A:
Tabla 34: Productos arquitectónicos de la fase A del marco propuesto.
Entradas de TOGAF 9.1 Entradas del marco propuesto
• Solicitud de trabajo arquitectónico. Entradas no arquitectónicas:

• Principios, objetivos e impulsores del • Planificación estratégica.
negocio.
• Modelo organizacional de arquitectura Entradas arquitectónicas:
empresarial. • Estructura del equipo de arquitectura
• Marco de referencia arquitectónico empresarial.
adaptado, incluyendo adaptación del • Principios arquitectónicos.
método arquitectónico, contenido • Marco arquitectónico adaptado.
arquitectónico, principios arquitectónicos
y herramientas configuradas e
implementadas.
• Repositorio arquitectónico cargado con
la documentación arquitectónica
existente.
Salidas de TOGAF 9.1 Salidas del marco propuesto
• Enunciado del trabajo arquitectónico Salidas arquitectónicas:

aprobado. • Artefactos:
• Declaraciones refinadas de principios, ◦ Diagrama de cadena de valor.
objetivos e impulsores del negocio. ◦ Diagrama de concepto de la solución.
• Principios arquitectónicos. ◦ Mapa de interesados.
• Evaluación de capacidades.
• Marco de referencia arquitectónico • Entregables:
adaptado. ◦ Evaluación de capacidades.
• Visión arquitectónica, incluyendo: ◦ Actualización del documento
◦ Requerimientos clave refinados y de Principios arquitectónicos.
131
alto nivel de los interesados. ◦ Visión arquitectónica.
• Versión preliminar del Documento de ◦ Enunciado del trabajo arquitectónico.
definición arquitectónica, incluyendo:
◦ Arquitecturas de negocio, datos,
aplicaciones y tecnología de línea
base y destino.
• Plan de comunicaciones.
Las entradas y salidas originales del marco arquitectónico base (TOGAF 9.1) pueden ser
revisadas en la página 74. A continuación, se describen los cambios efectuados en la
estructura (contenidos) de los entregables que conforman la fase preliminar:
• Evaluación de capacidades.
El entregable Evaluación de capacidades documenta los resultados de las evaluaciones de

la empresa en cuanto a capacidades de negocio y TI, madurez arquitectónica y preparación
para la transformación del negocio. La estructura original del documento contiene los
elementos necesarios para realizar la evaluación de capacidades, por lo cual no se
realizaron cambios sobre la misma.
Tabla 35: Estructura resultante del entregable Evaluación de capacidades.
Contenido resultante
1. Propósito del documento.

2. Evaluación de las capacidades del negocio.
1. Capacidad de negocio de línea base.
2. Capacidad de negocio destino.
3. Evaluación de las capacidades de TI.
1. Capacidades de TI de línea base.
1. Capacidad de datos, aplicaciones y tecnología.
2. Capacidades de TI destino.
1. Capacidad de datos, aplicaciones y tecnología
4. Evaluación de la madurez arquitectónica.
5. Evaluación de la preparación de la transformación del negocio.
• Visión arquitectónica.
El entregable Visión arquitectónica se puede considerar como una versión resumida del
Documento de definición arquitectónica, en donde se plasma la visión que tiene la empresa
132
de los cambios que se derivarán de la implementación de la arquitectura destino. A
continuación, se describen los cambios desarrollados sobre la estructura del entregable.
Tabla 36: Evaluación del entregable Visión arquitectónica.
1. Propósito del • Ninguno. 1. Propósito del

documento. documento.
2. Descripción del • Se sintetizó el contenido 2. Descripción del

problema. de este apartado, problema.
1. Lista de considerando las 1. Enunciado de la
asuntos/escenarios a características de ajuste visión del negocio.
ser considerados. del marco propuesto, a 2. Diagrama de la
2. Enunciado de la fin de lograr una visión del negocio.
visión del negocio. estructura más 3. Impulsores del
3. Diagrama de la compacta del contenido. cambio y oportunidades.
visión del negocio.
4. Impulsores del Criterios de ajuste:
cambio y oportunidades. simplicidad y
comprensibilidad.
3. Objetivos detallados. • Este apartado no se --

considerará en este
entregable, debido a
que su contenido es
descrito en el
documento Enunciado
del trabajo
arquitectónico.
simplicidad.
4. Actores y sus roles y • La información del --

responsabilidades. apartado actores y sus
1. Actores humanos y roles y
roles. responsabilidades, no
2. Actores se considerará en este
computacionales y roles. entregable, debido a
3. Requerimientos. que su contenido es
descrito en el
documento Enunciado
del trabajo
arquitectónico.
simplicidad.
133
5. Entorno y modelos de • Se sintetizó el contenido 3. Modelo de procesos.
procesos. de este apartado,
1. Descripción de considerando las
procesos. características de ajuste
2. Pasos de los del marco propuesto,
procesos mapeados al con el fin de lograr una
entorno. estructura más sencilla
3. Pasos de los del mismo.
procesos mapeados a
las personas. Criterios de ajuste:
4. Flujos de simplicidad y
información. comprensibilidad.
6. Modelo arquitectónico • No se incluyó el punto 4. Modelo arquitectónico

resultante. Principios de TI debido a resultante.
1. Limitaciones. que su descripción se 1. Limitaciones.
2. Principios de TI. efectúa en el entregable 2. Arquitectura que
3. Arquitectura que Principios soporta el negocio.
soporta el negocio. arquitectónicos.
4. Requerimientos • Además, no se
mapeados a la consideró el punto
arquitectura. requerimientos
mapeados a la
arquitectura, a fin de
tener una estructura
más simple del
apartado.
simplicidad.
7. Enunciado de la visión • Ninguno. 5. Enunciado de la visión

final. final.
• Enunciado del trabajo arquitectónico.
El documento más importante de la fase A: Visión arquitectónica es el Enunciado del trabajo

arquitectónico, cuyo contenido servirá como herramienta de medición del éxito en la
ejecución del proyecto. A continuación, se describe la evaluación de su estructura:
Tabla 37: Evaluación del entregable Enunciado del trabajo arquitectónico.
134
2. Enunciado del trabajo • El contenido de este 2. Antecedentes.

arquitectónico. apartado se sintetizó
1. Solicitud del como Antecedentes,
proyecto y para brindar una visión
antecedentes. general y simple del
2. Descripción del mismo.
proyecto y alcance.
3. Vista general. Criterios de ajuste:
4. Alineamiento simplicidad y
estratégico. comprensibilidad.
3. Objetivos y alcance. • Se sintetizó el contenido 3. Objetivos y alcance.

1. Objetivos. de este apartado, 1. Objetivos.
2. Alcance. considerando las 2. Alcance.
3. Interesados, características de ajuste
preocupaciones y vistas. del marco propuesto,
4. Enfoque de con el fin de lograr una
gestión. estructura más sencilla
5. Cambios en los del mismo.
procedimientos de
alcance. Criterios de ajuste:
simplicidad y flexibilidad.
4. Roles y • Debido a que los --

responsabilidades. contenidos del apartado
1. Estructura de la han sido abordados en
gobernanza. anteriores entregables,
2. Procesos del no se lo considerará en
proyecto. el presente entregable.
3. Roles y
responsabilidades Criterios de ajuste:
5. Enfoque arquitectónico. • Como algunos de los 4. Metodologías relevantes

1. Procesos contenidos del apartado, y estándares de la
arquitectónicos. han sido abordado en industria.
2. Contenido anteriores entregables,
arquitectónico. se replanteó el
3. Metodologías enunciado del apartado
relevantes y estándares como Metodologías
de la industria. relevantes y estándares
4. Soporte del de la industria.
continuum empresarial.
simplicidad.
135
6. Plan de trabajo. • Considerando los 5. Plan de trabajo.

1. Ítems de trabajo. criterios de ajuste del 1. Plan de
2. Plan de marco propuesto, se comunicaciones.
comunicaciones. sintetizó el contenido del 2. Plan de proyecto y
1. Eventos. apartado a fin de lograr calendario.
2. Canales. una estructura más
3. Formatos. compacta del mismo.
4. Contenido.
3. Duración y Criterios de ajuste:
esfuerzo. simplicidad y flexibilidad.
4. Colaboración.
5. Plan de proyecto y
calendario.
7. Riesgos y mitigaciones. • Considerando los 6. Riesgos y mitigaciones.

1. Análisis de riesgos. criterios de ajuste del 1. Análisis de riesgos.
2. Conjeturas. marco propuesto, se
sintetizó el contenido del
apartado a fin de lograr
una estructura más
compacta del mismo.
simplicidad.
8. Criterios de aceptación y • Ninguno. 7. Criterios de aceptación

procedimientos. y procedimientos.
1. Métricas. 1. Métricas.
2. Procedimiento de 2. Procedimiento de
aceptación/cierre. aceptación/cierre.
9. Firma de aprobación. • Ninguno. 8. Firma de aprobación.
Durante el desarrollo de la fase, existen algunas herramientas que pueden apoyar la

ejecución de los pasos planteados (al ser herramientas adicionales, su implementación es
opcional).
136
Tabla 38: Herramientas adicionales de la fase A: visión arquitectónica.
Marcos de Business • Es una metodología para el aseguramiento del éxito

referencia de transformation de los proyectos de transformación empresarial.
soporte management • Proporciona un enfoque holístico que integra
adicional. methodology. conocimientos técnicos y metodológicos específicos
de diferentes áreas de transformación.
• En esta fase, se ha tomado en consideración
únicamente su modelo de madurez.
Marco de • El marco de capacidades arquitectónicas ofrece un

capacidades conjunto de materiales de referencia para el proceso
arquitectónicas. de establecer la función arquitectónica.
• En esta fase, se ha tomado en consideración
únicamente el modelo de madurez arquitectónica
propuesto: DoC ACMM
• El propósito del modelo es mejorar las
probabilidades generales de éxito de proyectos de
arquitectura empresarial, mediante la identificación
de áreas débiles y la definición de una ruta evolutiva
para el desarrollo de la arquitectura.
Técnicas. Planificación • Es una técnica de planificación de negocios que se

basada en centra en los resultados del negocio. Proporciona
capacidades. pautas para la planificación, ingeniería y entrega de
capacidades estratégicas de negocio para la
empresa.
Evaluación de • Es una directriz que se implementa para evaluar y

la preparación cuantificar la disposición de una organización para
de la sufrir modificaciones.
transformación • Está basada en en el Programa de capacitación en
del negocio. transformación de negocios del Gobierno
canadiense.
Gestión de • Describe el enfoque de gestión de los grupos de

interesados. interés y los pasos recomendados para efectuar
dicha gestión.
Gestión de • Esta técnica ofrece conceptos de buenas prácticas

riesgos. en gestión de riesgos. Proporciona los principales
elementos para apoyar el proceso de identificación y
mitigación de riesgos.
De manera general, se presenta en la Figura 56 un cuadro resumen de los cambios

efectuados en la fase preliminar del marco arquitectónico.
137
Figura 56: Cuadro resumen de los cambios de la fase A.
138
la siguiente figura el tablero resultante de la fase A del marco propuesto.
Figura 57: Tablero Kanban de la fase A.

Gracias a las iteraciones de desarrollo arquitectónico (Figura 58), la arquitectura puede ser
interpretada de manera global. Permiten la generación de contenido arquitectónico a través
de la integración de las siguientes fases:
• Fase B: Arquitectura de negocio.
• Fase C: Arquitectura de sistemas de información.
◦ Sistemas de información – datos.
◦ Sistemas de información – aplicaciones.
• Fase D: Arquitectura tecnológica.
Para una visión general de los elementos que conforman esta iteración, revisar el ANEXO
13: Iteración de desarrollo arquitectónico del marco de referencia adaptado.
139
Figura 58: Iteración de desarrollo arquitectónico.
De acuerdo a la integración de Kanban y TOGAF, se presenta a continuación los tableros

que conforman esta iteración y sus respectivas relaciones:
Figura 59: Relaciones de los tableros de la Iteración de desarrollo arquitectónico.

140
4.3.2.1 Modelo genérico para las fases B, C y D.
Dado que las fases de la iteración de desarrollo arquitectónico efectúan pasos similares para
alcanzar objetivos comunes, se ha creído conveniente proporcionar un modelo genérico
para los dominios que conforman esta iteración (negocio, datos, aplicaciones, tecnología).
Las fases de la iteración de desarrollo arquitectónico persiguen dos objetivos en común:

desarrollar la arquitectura destino del dominio en cuestión (negocio, datos, aplicaciones,
tecnología) y establecer los posibles componentes que conformarán el entregable Hoja de
ruta de la implementación (generado en la fase E).
Tabla 39: Evaluación de los objetivos de la fases B, C y D.
Objetivos originales Adaptación Objetivos resultantes
1. Desarrollar la Tipo de adaptación: 1. Desarrollar la

arquitectura destino semántico. arquitectura destino.
describiendo cómo la
empresa tiene que • De acuerdo a los
operar para alcanzar los criterios de ajuste del
objetivos de negocio, marco propuesto, se
responder a las decidió simplificar los
motivaciones enunciados de los
estratégicas definidas objetivos, para lograr
en la Visión una fácil comprensión
arquitectónica y de sus propósitos
responder a la Solicitud
de trabajo arquitectónico Criterios de ajuste:
y las preocupaciones de comprensibilidad y
los interesados. vocabulario natural y
común.
2. Identificar componentes 2. Identificar posibles
candidatos para la Hoja componentes a ser
de ruta del trabajo incluidos en la Hoja de
arquitectónico ruta de la
basándose en las implementación.
brechas identificadas
entre la arquitectura de
línea base y destino.
141
4.3.2.1.2 Pasos.
En la Tabla 40, se presenta el proceso de evaluación de los pasos de la fases de la Iteración

de desarrollo arquitectónico del marco arquitectónico TOGAF 9.1, que serán ajustados a las
características de las PYMEs.
Tabla 40: Evaluación de los pasos de la fases B, C y D.
1. Seleccionar Tipo de adaptación: ajustado a las 1. Seleccionar

modelos de características de las PYMEs. modelos de
referencia, referencia,
puntos de vista Consideraciones: puntos de vista
y herramientas. y herramientas.
• Para el desarrollo de este paso, se
sugiere tomar en cuenta las siguientes
actividades:
1. Validar la definición de los

principios arquitectónicos de la
empresa.
2. Seleccionar recursos relevantes
para la descripción de la arquitectura.
◦ Modelos de referencia: Son

abstracciones que facilitan la
comprensión de la arquitectura. Para
cada dominio, se sugiere considerar
los siguientes modelos (Montalván,
2016):
Negocio: Business
Reference Model (BRM) – Es
un modelo que se concentra
en los aspectos
organizaciones y funcionales
del núcleo del negocio.
Datos: Data Reference

Model (DRM) – Es un
modelo basado en un
enfoque orientado a
estándares, cuyo propósito
principal es la compartición y
reuso de los datos.
142
Aplicaciones: Application
Reference Model (ARM) – Es
un modelo que permite la
categorización de sistemas y
la definición de estándares y
tecnologías.
Tecnología:
Technical Reference Model
(TRM) – Provee un modelo y
taxonomía de servicios
genéricos para la plataforma
de aplicaciones:
Infrastructure Reference
Model (III RM) – Provee un
modelo y taxonomía para el
diseño de infraestructuras
que permitan el flujo de
información sin fronteras.
IRM – Infrastructure
Reference Model: Es una
guía que provee las mejores
prácticas para la
implementación de la
tecnología.
3. Seleccionar los puntos de vista

relevantes.
◦ Puntos de vista: Son las

preocupaciones del grupo de interés
que deben ser abordadas en la
arquitectura destino.
4. Seleccionar las herramientas que

ayudarán en el proceso de
descripción arquitectónica:
◦ Por cada una de las fases de la

iteración de desarrollo arquitectónico
se deberán determinar técnicas que
permitan la descripción de la
arquitectura destino. Además, se
deberán seleccionar los catálogos,
diagramas y matrices necesarios.
◦ En la tabla 45, se presenta un

conjunto de herramientas que
facilitarán el proceso de descripción
arquitectónica.
143
◦ En la tabla 42, se presenta un listado

de los artefactos (catálogos,
diagramas y matrices) que apoyarán
la descripción de la arquitectura.
Este conjunto de artefactos, han sido
seleccionados de acuerdo a las
principales características de las
PYMEs.
2. Desarrollar la Tipo de adaptación: combinado. 2. Desarrollar la

descripción de descripción de
la línea base de Fundamento: las
la arquitectura. arquitecturas
• A los pasos: “desarrollar la descripción de línea base y
de la arquitectura de línea base” y destino.
“desarrollar la descripción de la
arquitectura destino”, se decidió
unificarlos por ser actividades
relacionadas.
• Las descripciones de las arquitecturas

de línea base y destino deberán
apoyarse en los modelos de referencia
seleccionados en el paso número 1.
Criterios de ajuste: comprensibilidad,

flexibilidad y simplicidad.
Consideraciones:
• Las descripciones de las arquitecturas

deberán ser documentadas en el
entregable Documento de definición
arquitectónica.
3. Desarrollar la • Se integró en el anterior paso. --

descripción de
la arquitectura
destino.
4. Realizar el Tipo de adaptación: Ninguna. 3. Realizar el

análisis de análisis de
brechas. Consideraciones: brechas.
• Se sugiere la utilización de la técnica

Análisis de brechas, la cual brinda un
conjunto de lineamientos y directrices.
144
• El proceso de análisis de brechas

deberá ser documentado en el
arquitectónica.
5. Definir los Tipo de adaptación: Ninguna. 4. Definir los

componentes componentes
candidatos que Consideraciones: candidatos que
conforman la conforman la
Hoja de ruta del • Como resultado de este paso, se deberá Hoja de ruta de
trabajo elaborar un listado de los posibles la
arquitectónico. proyectos que serán incluidos en la Hoja implementación.
de ruta de la implementación, la misma
que se genera en la fase E.

flexibilidad.
6. Resolver los Tipo de adaptación: Ajustado a las --

impactos del características de las PYMEs.
contexto
arquitectónico. Consideraciones:
• No se consideró este paso debido a que

para esta categoría de empresas no se
abordó el concepto de contexto
arquitectónico.

flexibilidad y coherencia.
7. Conducir Tipo de adaptación: Ninguna. 5. Conducir

revisiones revisiones
formales con • En las revisiones formales que se formales con
los interesados. desarrollen con los interesados se los interesados.
deberá verificar que la motivación
original expuesta en el entregable
(desarrollado en el la fase A: Visión
arquitectónica) se refleje en la
descripción de la arquitectura.
8. Finalizar la Tipo de adaptación: Combinado. 6. Crear la

arquitectura. versión
preliminar el
Documento de
definición
145
Consideraciones: arquitectónica.
• Los pasos finalizar la arquitectura y

crear el documento de definición
arquitectónica se combinaron por ser
actividades complementarias.
• Como resultado de este paso, se deberá

generar la primera versión del
arquitectónica.

flexibilidad y simplicidad.
9. Crear el • Se integró en el anterior paso. --

Documento de
definición de
arquitectónica.

En el ANEXO 14: Evaluación de los artefactos de las fases B, C y D., se presenta la

evaluación desarrollada sobre los artefactos de la fases que conforman la Iteración de
desarrollo arquitectónico
En la siguiente tabla, se describe la evaluación desarrollada de los entregables de la fase A

del marco arquitectónico de referencia:
146
Tabla 41: Evaluación de los entregables de las fases B, C y D.
Uso de la
Fase Nombre Ponderación Evaluación plantilla
Fases Documento de Alta El Documento de especificación de Adaptada

B, C y especificación de requerimientos arquitectónicos es un
D. requerimientos entregable importante para la
arquitectónicos. planificación de la implementación
de la arquitectura. Proporciona una
visión cuantitativa de la solución a
desarrollar, estableciendo criterios
medibles a cumplir durante la
implementación.
Documento de Alta El Documento de definición Adaptada

definición arquitectónica es un entregable
arquitectónica. indispensable debido a que
proporciona una visión cualitativa de
la solución, complementando al
documento de especificación de
requerimientos arquitectónicos. Es el
contenedor de los artefactos
generados durante el proceso de
descripción arquitectónica.
En la siguiente tabla, se presentan los productos arquitectónicos que deberán desarrollarse

durante en las fases de la Iteración de desarrollo arquitectónico.
Tabla 42: Productos arquitectónicos de las fases B, C y D del marco propuesto.
Fase Entradas de TOGAF 9.1 Entradas del marco propuesto
Fases • Solicitud del trabajo arquitectónico. Entradas no arquitectónicas:

B, C y • Modelo organizacional de • Planificación estratégica.
D arquitectura empresarial.
• Principios arquitectónicos. Entradas arquitectónicas:
• Marco arquitectónico adaptado. • Entregables:
• Evaluación de capacidades. ◦ Estructura del equipo de arquitectura
• Visión arquitectónica. empresarial y su organización.
• Enunciado del trabajo arquitectónico ◦ Principios arquitectónicos.
aprobado. ◦ Marco arquitectónico adaptado.
◦ Evaluación de capacidades.
• Especificación de requerimientos
◦ Visión arquitectónica.
arquitectónicos preliminar. ◦ Enunciado del trabajo arquitectónico
• Documento de definición aprobado.
arquitectónica preliminar. ◦ Documento de especificación de
• Hoja de ruta del trabajo arquitectónico requerimientos arquitectónicos
preliminar. preliminar.
◦ Documento de definición
arquitectónica preliminar.
147
Fase Salidas de TOGAF 9.1 Salidas del marco propuesto
Fase • Catálogos, diagramas y matrices Salidas arquitectónicas:

B requeridas. • Artefactos:
• Documento de Especificación de ◦ Catálogo de medida - contrato.
requerimientos arquitectónicos ◦ Catálogo de
preliminar. impulsores/metas/objetivos.
• Documento de definición ◦ Diagrama de casos de uso.
arquitectónica preliminar. ◦ Diagrama de descomposición
• Hoja de ruta del trabajo arquitectónico funcional.
preliminar. ◦ Diagrama de flujos de procesos.
◦ Matriz de actor/rol.
• Entregables:
◦ Versión preliminar del documento
de Especificación de
requerimientos arquitectónicos.
de definición arquitectónica.

C: requeridas. • Artefactos:
Datos • Documento de Especificación de ◦ Catálogo de entidades de
requerimientos arquitectónicos datos/componentes de datos.
preliminar. ◦ Diagrama conceptual de datos.
• Documento de definición ◦ Diagrama lógico de datos.
arquitectónica preliminar. ◦ Matriz de aplicaciones/ datos.
• Hoja de ruta del trabajo arquitectónico
preliminar. • Entregables:
Fase C: • Catálogos, diagramas y matrices Salidas arquitectónicas:

Aplicaci
ones
requeridas. • Artefactos:
• Documento de Especificación de ◦ Catálogo de portafolio de
requerimientos arquitectónicos aplicaciones.
preliminar. ◦ Diagrama de casos de uso de
• Documento de definición aplicaciones.
arquitectónica preliminar. ◦ Diagrama de comunicaciones.
• Hoja de ruta del trabajo arquitectónico ◦ Matriz de interacción de
preliminar. aplicaciones.
• Entregables:
148
Fase Salidas de TOGAF 9.1 Salidas del marco propuesto

D requeridas. • Artefactos:
• Documento de Especificación de ◦ Catálogo de estándares
requerimientos arquitectónicos tecnológicos.
preliminar. ◦ Catálogo de portafolio de
• Documento de definición tecnología.
arquitectónica preliminar. ◦ Diagrama de descomposición de la
• Hoja de ruta del trabajo arquitectónico plataforma tecnología.
preliminar. ◦ Matriz de aplicaciones –
tecnología.
• Entregables:
Los productos arquitectónicos originales del marco base, pueden ser revisados en la página
76. A continuación, se describen los cambios efectuados en la estructura (contenidos) de los
entregables de las fases de la Iteración de desarrollo arquitectónico:
• Documento de definición arquitectónica.
El Documento de definición arquitectónica contiene la información producida por los

artefactos de las fases de la Iteración de Desarrollo arquitectónico. Su principal objetivo es
proporcionar una visión cualitativa de la solución y servir como medio para comunicar la
intención de los arquitectos. El contenido del entregable es información de alto nivel, por lo
tanto no se pudo reducir considerablemente la estructura del documento.
Tabla 43: Evaluación del entregable Documento de definición arquitectónica.
2. Alcance. • Ninguno. 2. Alcance.
149
3. Metas, objetivos y • Considerando los criterios 3. Metas, objetivos y

limitaciones. de ajuste, se sintetizará el limitaciones.
1. Metas del negocio y contenido del apartado,
TI. para lograr una estructura
2. Objetivos derivados más sencilla del mismo.
de las metas.
3. Interesados y sus • Criterios de ajuste:
preocupaciones. simplicidad y flexibilidad.
4. Limitaciones.
5. Capacidades.
4. Cumplimiento. • No se incluirá el punto 4. Cumplimiento.

1. Principios Principios 1. Políticas y
arquitectónicos. arquitectónicos, debido a estándares.
2. Políticas y que su definición ya ha
estándares. sido desarrollada en otro
entregable.
5. Riesgos y problemas. • Ninguno. 5. Riesgos y problemas.

1. Conjeturas. 1. Conjeturas.
2. Riesgos. 2. Riesgos.
3. Problemas. 3. Problemas.
4. Dependencias. 4. Dependencias.
6. Arquitectura de línea • Ninguno. 6. Arquitectura de línea

base. base.
1. Modelos de 1. Modelos de
arquitectura de negocio. arquitectura de negocio.
arquitectura de datos. arquitectura de datos.
arquitectura de arquitectura de
aplicaciones. aplicaciones.
arquitectura tecnológica. arquitectura tecnológica.
7. Sustento y justificación • Debido a que el --

para el enfoque contenido del apartado,
arquitectónico. en su mayoría ha sido
1. Razón fundamental. desarrollado en
2. Enfoque. anteriores entregables,
3. Decisiones no se considerará el
arquitectónicas. desarrollo de mismo.
4. Gobernanza
arquitectónica. Criterios de ajuste:
150
8. Mapeo al repositorio • Debido a que parte del --

arquitectónico. contenido del apartado,
1. Artefactos. ha sido desarrollado en
2. Mapeo al contexto anteriores entregables y
arquitectónico. considerando los criterios
3. Mapeo a modelos de ajuste, no se
de referencia. considerará el desarrollo
4. Mapeo a de mismo.
estándares.
5. Evaluación de Criterios de ajuste:
reusabilidad. simplicidad y flexibilidad.
9. Arquitectura destino. • Ninguno. 7. Arquitectura destino.

arquitectura de negocio. arquitectura de negocio.
arquitectura de datos. arquitectura de datos.
arquitectura de arquitectura de
arquitectura tecnológica. arquitectura tecnológica.
10. Análisis de brechas • Ninguno. 8. Análisis de brechas

preliminar. preliminar.
11. Evaluación de impactos. • La evaluación presentada --

1. Referencia a en este apartado deberá
requerimientos estar alineada a los
específicos. procedimientos
2. Prioridad de establecidos por la fase
requerimientos. de gestión de
3. Fases a ser requerimientos y las
revisadas. fases subsiguientes a las
4. Conclusiones. de la Iteración de
5. Recomendaciones. desarrollo arquitectónico.
• Documento de especificación de requerimientos arquitectónicos.
Este documento lista un conjunto de datos cuantitativos que describen lo que debe realizar
el proyecto de implementación para cumplir con la arquitectura destino. A diferencia del
anterior documento, este entregable proporciona una vista cuantitativa de la solución.
151
Tabla 44: Evaluación del entregable Especificación de requerimientos arquitectónicos.
1. Propósito del • Ninguno. 1. Propósito del

documento. documento.
2. Requerimientos • Se combinaron los 2. Requerimientos

arquitectónicos. puntos requerimientos arquitectónicos.
1. Requerimientos arquitectónicos y 1. Requerimientos
arquitectónicos. requerimientos de arquitectónicos.
2. Requerimientos de interoperabilidad bajo el 2. Limitaciones.
interoperabilidad. enunciado 3. Conjeturas.
3. Limitaciones. requerimientos 4. Medidas de éxito.
4. Conjeturas. arquitectónicos, para
5. Medidas de éxito. lograr simplicidad en la
estructura del
entregable.
3. Contratos de servicios. • Se ha decidido no --

1. Contratos de considerar el apartado
servicios de negocio. contratos de servicios,
2. Contratos de debido a la relevancia
servicios de del contenido para este
aplicaciones. entregable.
4. Implementación. • Ninguno. 3. Implementación.

1. Directrices de 1. Directrices de
implementación. implementación.
2. Especificaciones de 2. Especificaciones
implementación. de implementación.
3. Estándares de 3. Estándares de
implementación. implementación.
Durante el desarrollo de la fases, existen algunas herramientas que pueden apoyar la

ejecución de los pasos planteados (al ser herramientas adicionales, su implementación es
opcional).
152
Tabla 45: Herramientas adicionales de las fases de B, C y D.
Herramientas Attribute Driven Es un método sistemático que permite el diseño de

Design (ADD) arquitecturas de software. Se centra en el diseño de
requerimientos de calidad de la arquitectura.
Enterprise Architect Enterprise Architect ofrece un ambiente de

modelado colaborativo. Gestiona el ciclo de vida del
desarrollo de software. Basado en estándares
abiertos como UML ó BPMN. Además, soporta la
integración con marcos arquitectónicos como
TOGAF.
CANVAS Es una herramienta práctica para desarrollar

modelos de negocio. A través de un tablero permite
describir la lógica de cómo una organización crea,
entrega y captura valor. Consta de nueve elementos:
clientes, propuestas de valor, canales de
distribución, relaciones con los clientes, fuentes de
ingresos, recursos claves, actividades clave,
alianzas clave y estructura de costes.
Modelo de vistas de “4+1” es uno de los modelos más aceptados para la

arquitectura “4+1” descripción arquitectónica. Define cuatro vistas
principales: lógica, procesos, desarrollo y física.
Además, define una vista transversal a las
anteriores: escenarios. Una de sus principales
ventajas es la de ser de naturaleza genérico, por lo
cual puede integrarse con otras notaciones y
herramientas.
Sonargraph Es un potente analizador de código estático que

permite monitorear sistemas de software y asegurar
atributos de calidad técnica.
Técnicas Análisis de La premisa básica de esta técnica es la de identificar

brechas. deficiencias entre las arquitecturas de línea base y
destino. Además, provee un medio importante para
establecer qué componentes arquitectónicos han
sido omitidos luego de generar la visión
arquitectónica.
Escenarios de Esta técnica posibilita: identificar requerimientos de

negocio negocio y técnicos para la arquitectura, y definir
metas y objetivos para el desarrollo arquitectónico.
Es una herramienta importante para identificar las
necesidades del negocio, y derivar requisitos.
Patrones Es una valiosa técnica para el diseño arquitectónico.

arquitectónicos. Provee terminología, formatos e información
153
suficiente para una adecuado adopción de patrones

arquitectónicos.
Requerimientos de Dependiendo del grado en que la información y los

interoperabilidad. servicios serán compartidos, esta técnica puede
aportar directrices importantes para establecer
requerimientos de interoperabilidad.

la siguiente figura el tablero resultante de las fases B, C y D del marco propuesto.
Figura 60: Tablero Kanban de las Fases B, C y D del marco propuesto.

Se presenta en la Figura 61 un cuadro resumen de los cambios efectuados en las fases de

la iteración de desarrollo arquitectónico. De forma general, en la Figura 62 se muestra una
visión global del marco arquitectónico propuesto para las PYMEs y en la Figura 63 se
presenta el tablero resultante de las iteraciones desarrolladas en el presente trabajo. Las
relaciones de los tableros Kanban se detallan en el ANEXO 15: Relaciones de los tableros
Kanban del marco arquitectónico adaptado.
154
Figura 61: Cuadro resumen de los cambios de la fases B, C y D.
155
Figura 62: Visión general del marco arquitectónico propuesto.
156
Figura 63: Tablero Kanban del marco propuesto.
157
CAPÍTULO 5: PRUEBA DE CONCEPTO
5.1 Definición del caso de estudio.
A continuación, se describe la prueba de concepto desarrollada.
5.1.1 Reseña histórica de la Cooperativa de transportes Loja.
Figura 64: Logo de la Cooperativa de transportes Loja.

Fuente: Cooperativa de transportes Loja.
La Cooperativa de transportes Loja (CTL) nace el 15 de febrero de 1961 como producto de

la cohesión de 38 socios de las cooperativas Ecuador, Celica y Cenepa. Su funcionamiento
inició con las siguientes frecuencias: Loja-Cariamanga, Loja-Celica y Loja-Macará. Fue
constituida jurídicamente mediante el acuerdo ministerial nro. 1525, e inscrita en el Registro
general de cooperativas el 13 de abril de 1961.
Dentro de los acontecimientos históricos más relevantes de la cooperativa se destaca el

primer viaje con frecuencia Loja-Quito, en un tiempo aproximado de 22 horas, efectuado en
el año 1971. Además, es importante mencionar las gestiones desarrolladas a partir de 1993
para la importación de vehículos con carrocería extranjera.
La Cooperativa de transportes Loja es considerada como una de las empresas de transporte

pioneras en el Ecuador, por el desarrollo de nuevas unidades de producción como: taller de
carrocerías, estación de servicios, almacén de repuestos, lavadora y lubricadora. Es
importante mencionar también el proyecto de renovación continua de sus unidades
vehiculares, a través del cual se innova en la prestación de servicios a sus clientes.
Actualmente la cooperativa cuenta con 135 socios, quienes mantienen su compromiso de

generar nuevas oportunidades de crecimiento y emprender proyectos que conserven el sitial
de líderes del sector transportista ecuatoriano.
159
5.1.2 Servicios ofrecidos por la CTL.
La Cooperativa de Transportes Loja ofrece a la colectividad los siguientes servicios:
• Transporte de pasajeros: Transporte terrestre de personas a nivel cantonal,

provincial, nacional e internacional (Perú).
• Expresos internacionales: Renta de unidades para giras internacionales.
• Transporte de cargas y encomiendas: Entrega y recepción de cargas y
encomiendas.
• Estación de servicios: Venta de combustible.
• Taller de carrocerías: Reparación y revisión de la flota de unidades de la
Cooperativa.
• Lavadora y lubricadora: Lavado y mantenimiento de vehículos.
5.1.3 Cadena de valor de la CTL.
Montalván (2016) propone en la Figura 65, la cadena de valor orientada a servicios para la
Cooperativa de Transporte Loja, en la que se pueden distinguir los siguientes tipos de
procesos:
• Procesos estratégicos: Posibilitan la definición y el desarrollo de los objetivos

estratégicos de la empresa. Dentro de esta categoría se han identificado los
siguientes procesos: direccionamiento estratégico, gestión de la calidad,
comunicación y marketing.
• Procesos misionales: También denominados procesos clave, son aquellos que
generan valor agregado y permiten la satisfacción del cliente. Dentro de esta
categoría se han identificado los siguientes procesos: transporte de personas y
transporte de encomiendas y carga.
• Procesos de apoyo: Encargados de permitir el control y mejora continua. Por lo
general están relacionados con las normas de los modelos de gestión. Dentro de
esta categoría se han identificado los siguientes procesos: gestión financiera, gestión
de infraestructura tecnológica, desarrollo tecnológico, talento humano, adquisiciones
y auditoría y control.
160
Figura 65: Cadena de valor orientada a servicios de la CTL.
Fuente: Montalván (2016).
Adaptado de Montalván.
5.1.4 Situación actual de la CTL..
Íñiguez (2016) en base a la auditoría desarrollada por el SEPS (2013), nos presenta un
informe de la situación actual de la Cooperativa de transportes Loja, la cual se describe en
los cuatro dominios empresariales de la Cooperativa:
5.1.4.1 Negocio.
En la Cooperativa de Transportes Loja se han identificado de forma preliminar las siguientes

características del negocio:
• Estructura administrativa poco flexible.

• No existe una definición formal de los procesos que soportan el negocio.
• No se han definido las competencias laborales para cada puesto.
161
• No se han definido políticas de atención y orientación al cliente.
• No es posible medir la calidad de servicios prestados.
• No existen mecanismos de comunicación interna y externa.
5.1.4.2 Datos.

características del dominio datos:
• No existen modelos de datos formalmente documentados.

• No existen repositorios estructurados de la información digital.
• No existen estrategias documentadas para la explotación de información
empresarial.
• Las aplicaciones que soportan el negocio manejan su propia base de datos, por lo
tanto no existe integración entre la información que producen.
5.1.4.3 Aplicaciones.

características del dominio aplicaciones:
• No existe una arquitectura de aplicaciones definida.

• Las aplicaciones que soportan el negocio en la Cooperativa de Transportes Loja son:
◦ Sistema de Gestión de turnos: Gestionado actualmente mediante una hoja de
cálculo electrónica.
◦ Sistema de venta de boletos (NOVO).
◦ Sistema de contabilidad y pagos (SISCON).
◦ Sistema de facturación (E-Facturas).
• No existe integración de las aplicaciones que soportan el negocio.
162
5.1.4.4 Tecnología.
Las tecnologías con las que cuenta la Cooperativa de Transportes Loja puede ser descrita
en la siguiente figura:
Figura 66: Tecnología actual de la CTL.

Fuente: Íniguez (2016).
Adaptado de Íñiguez.
5.1.5 Problemática.
Como se evidencia en la situación actual de la Cooperativa de Transportes Loja, las

decisiones y estrategias del negocio se encuentran aisladas de las iniciativas tecnológicas.
Además, la disposición actual de la infraestructura tecnológica de la Cooperativa es una
limitante para la adopción de nuevos esquemas de negocio.
163
La Cooperativa de Transportes Loja emprendió un proceso de planificación estratégica, en el
cual a nivel de tecnología se busca desarrollar un proyecto de transformación tecnológica
integral. La principal meta de este proyecto es la alineación de los objetivos estratégicos del
negocio con el proyecto de transformación.
La herramienta que asegurará el éxito del alineamiento estratégico entre Negocio y TI en la

Cooperativa, será la adopción de prácticas de Arquitectura empresarial. Sin embargo, ante
las limitadas características de la empresa, sería complejo el proceso de adopción de
prácticas arquitectónicas.
Por estas razones, se adoptará el marco arquitectónico propuesto en el Capítulo 3, el cual

se adapta a las características de las PYMEs, que se asemejan a las identificadas en la
Cooperativa de Transportes Loja.
5.1.5.1 Descripción del segmento de negocio seleccionado.
Tomando como referencia la cadena de valor de la Cooperativa de transportes Loja (figura

65), para la validación de la aplicabilidad del marco arquitectónico propuesto, se ha tomado
el primer segmento de negocio “Planificación de turnos” del servicio de transporte de
personas.
Figura 67: Proceso operativo del servicio de transportes de la CTL.

Gracias al proceso de planificación de turnos, la cooperativa es capaz de programar

anualmente las rutas y frecuencias (cantonales, interprovinciales e internacionales) que
ofrece a sus usuarios. En la actualidad, la cooperativa efectúa la planificación de turnos vía
hojas de cálculo electrónicas.
164
A continuación, se mencionan algunos de los problemas identificados en el proceso de
planificación de turnos (Montalván, 2016):
• Gestión manual de los turnos.

• Redundancia, ambigüedad e inconsistencia de la información.
• Es compleja la introducción de cambios en la planificación.
• Si existiera alguna modificación en la planificación, no existen mecanismos para
informar a los involucrados del mismo.
Para soportar la planificación de turnos de la cooperativa, se requiere un sistema capaz de

generar la distribución automática de rutas y frecuencias, que posibilite su acceso en todo
momento y desde cualquier lugar, y que permita la difusión de la nueva planificación
efectuada.
5.2 Adopción del marco arquitectónico propuesto en la CTL.
A continuación, se describe el proceso de adopción del marco arquitectónico propuesto para

uno de los segmentos de negocio de la cadena de valor de la Cooperativa de Transportes
Loja.
En la Iteración de capacidad arquitectónica, la Cooperativa de Transportes Loja sufrirá un

proceso de preparación inicial previo a la generación de capacidades arquitectónicas.
Para el desarrollo de la fase preliminar, se tomó como referencia el detalle del marco
arquitectónico propuesto en el Capítulo 4. En la siguiente figura, se presenta el trabajo a
desarrollar en esta fase.
165
Figura 68: Fase preliminar del marco arquitectónico propuesto.
166
Dentro de esta fase, la Cooperativa debe alcanzar los siguientes objetivos:
1. Determinar las capacidades empresariales que se pretenden alcanzar gracias al

2. Planificar el proceso de generación de capacidades.
Para la consecución de los objetivos propuestos, se llevó a cabo el desarrollo de los

siguientes pasos:
5.2.1.1.1 Elaborar o actualizar la planificación estratégica.
Como se explicó anteriormente, la Cooperativa de transportes Loja emprendió un proceso

de planificación estratégica, que fue aprobado por el Consejo de administración y socios de
la empresa. Esta planificación está desarrollada desde Enero de 2016 y está proyectada
hasta Diciembre de 2020. En la siguiente tabla, se presentan los objetivos y metas
estratégicas propuestas en la planificación:
Tabla 46: Objetivos y metas estratégicas de la CTL.
Perspectiva Objetivo Metas
Financiera Garantizar y maximizar la • Mejorar y distribuir de manera

rentabilidad y la excelencia equitativa los ingresos
financiera de la Cooperativa. generados por el servicio A, a
través de la implementación del
sistema caja común
• Garantizar el funcionamiento
descentralizado, autónomo y
sustentable de las unidades de
negocio de la Cooperativa
• Definir un modelo
presupuestario que haga del
presupuesto anual un
instrumento no sólo de
justificación del gasto y de
asignación de los recursos, sino
también una herramienta
fundamental para dotar de una
mayor transparencia a la
gestión y operación de la
Cooperativa de Transportes
Loja.
• Unificar el flujo de información
167
financiera en una sola

plataforma de acceso en el que
se integre y gestione la
información que generan las
diferentes áreas operativas y de
• Mejorar la provisión de
servicios a través de la
implantación de una cultura de
procesos que se ejecute en
base a la cadena de valor de la
Cooperativa.
De crecimiento Impulsar proyectos que • Implementar la línea de servicio

garanticen la sostenibilidad y turístico.
liderazgo de la Cooperativa en el • Expandir el servicio AAA hacia
mercado. nuevas rutas que permitan
ampliar la cobertura del
servicio.
• Potenciar el posicionamiento e
imagen de marca a través de
un Plan de marketing.
• Mejorar el servicio y
rentabilidad del transporte y
entrega de carga a través de la
transformación integral del área
de encomiendas.
• Mejorar la calidad en la
prestación de los servicios de la
sede central a través del
mejoramiento infraestructura
de cada uno de los servicios
ofrecidos.
• Modernizar y mejorar la calidad
en la prestación de los servicios
de las oficinas a nivel nacional
a través del mejoramiento de la
infraestructura física,
administrativa, encomiendas,
tecnología y conectividad.
de los servicios de
mantenimiento mecánico y
reparación de carrocerías que
se ofrecen a los socios de la
Cooperativa.
Tecnológica Transformación tecnológica La definición de las metas

integral de la Cooperativa de específicas depende del
Transportes Loja. diagnóstico inicial de TI a
desarrollarse en la Cooperativa de
Transportes Loja.
168
De formación y Implementar un enfoque moderno • Definir un enfoque de gestión

gestión del talento y de mejores prácticas para la por competencias para la
humano. gestión del capital humano. planificación del recurso
humano
• Disponer de programas de
formación y capacitación que
habiliten tanto a socios,
personal operativo y empleados
en el desempeño de sus
funciones.
Fuente: Cooperativa de Transportes Loja – Planificación estratégica (2016).
Adaptado de Cooperativa de Transportes Loja.
5.2.1.1.2 Seleccionar marcos de referencia de gestión empresarial.
A continuación, se presentan los marcos de referencia de gestión empresarial seleccionados

para la Cooperativa de Transportes Loja:
Figura 69: Marcos de gestión empresarial para la CTL.

169
• Guía de fundamentos de gestión de proyectos (PMBOK): Fue desarrollado por el
Project Management Institute (PMI), con el objetivo de unificar las prácticas sobre
gestión de proyectos. Es el estándar más ampliamente reconocido para manejar y
administrar proyectos. Representa un conjunto de conocimientos desarrollados a
partir de la experiencia y de estudios sistemáticos. Documenta nueve áreas de
conocimiento y cinco grupos de procesos, los cuales considera universales para casi
todo tipo de proyectos. (Zwikael, 2009).
• CREOPM: Es un instrumento utilizado por las empresas para calcular la utilidad que
presentan sus decisiones. Considera el valor de negocio, valor financiero, valor de TI
y los distintos riesgos al momento de optar por un proyecto. Establece dos tipos de
portafolios: CAPEX y OPEX, que contemplan los gastos de capital y los gastos
operativos respectivamente. (Bayney & Chakravati, 2012).
• Biblioteca de infraestructura de tecnologías de información (ITIL): Es el enfoque

de gestión de servicios de TI más ampliamente aceptado en el mundo. Provee una
base conceptual y buenas prácticas para la gestión de servicios de TI, desarrollo de
tecnologías de información y operaciones relacionadas. Es un marco de mejores
prácticas elaborado por los sectores público y privado a nivel internacional, que
describe cómo los recursos de TI deben ser organizados para ofrecer un valor
empresarial. (Potgieter, Botha & Lew, 2005).
• Marco de gestión de riesgos empresariales COSO III: COSO proporciona las

mejores prácticas referente a gestión de riesgos y ejecución de controles internos.
En el año 2013 se publicó la tercera versión de esta metodología de gestión de
riesgos, definiendo cinco componentes a tener en cuenta: entornos de control,
evaluación de riesgos, actividades de control, información y comunicación,
actividades de monitoreo y supervisión.
• Objetivos de control para la información y tecnologías relacionadas (COBIT):

Es un estándar abierto utilizado por las organizaciones de todo el mundo. Su
principal propósito es el de servir como marco de control para facilitar la alineación
entre las tecnologías de información (TICs) y el Negocio. COBIT propone un marco
de acción en donde se midan criterios de información, se auditen recursos
170
relacionados a las tecnologías de información y se evalúen los distintos procesos
involucrados. (Ridley et al, 2004).
Mayor información de los marcos de gestión seleccionados se encuentra en el ANEXO 13:

Marco arquitectónico adaptado.
5.2.1.1.3 Establecer los roles y responsabilidades específicos bajo demanda del

equipo de Arquitectura empresarial y su organización.
La conformación del equipo de arquitectura empresarial para la Cooperativa de transportes

Loja presentó algunas limitaciones: en la empresa no se cuenta con un departamento de TI
adecuadamente estructurado, no existe la cantidad suficiente de profesionales capacitados
para desarrollar los roles definidos ni se tiene planificado invertir demasiado para la creación
del equipo.
Sin embargo, se definieron los siguientes roles específicos bajo demanda que la empresa
debería cubrir para el desarrollo del trabajo arquitectónico:
• Arquitecto en jefe: Responsable de la gestión arquitectónica en la empresa.

• Arquitecto de software: Principal responsable de la toma de decisiones técnicas.
• Arquitecto de integración: Responsable de la integración de aplicaciones, integración
de datos e integración de procesos.
De ser necesario, se podría contratar para actividades específicas a arquitectos para los
dominios empresariales (Negocio, Datos, Aplicaciones, Tecnología). Para mayor información
de la estructura del equipo de arquitectura empresarial, revisar el ANEXO 17: Estructura del
equipo de arquitectura empresarial y su organización.
5.2.1.1.4 Identificar y establecer los principios arquitectónicos.
En el siguiente catálogo, se describen los principios arquitectónicos que regirán el trabajo a

desarrollar en la Cooperativa de transportes Loja:
171
Tabla 47: Catálogo de principios arquitectónicos de la CTL.
Dominio Código Nombre Enunciado
CTL-PAN-001 Planificación del La arquitectura de negocio apoya a la

Negocio
negocio planificación operativa y estratégica.
CTL-PAN-002 Procesos simples y La arquitectura del negocio permite el

flexibles diseño de procesos de negocio
simples y flexibles.
CTL-PAN-003 Centrado en el La arquitectura de negocio debe estar

cliente orientada en las necesidades del
cliente.
CTL-PAN-004 Habilidades La arquitectura de negocio debe

adecuadas fomentar la formación y capacitación
continua del personal.
CTL-PAN-005 Maximización de La arquitectura de negocio debe estar

beneficios para la diseñada para proporcionar el máximo
empresa beneficio a la empresa.
CTL-PAN-006 Independencia La arquitectura de negocio no está

tecnológica limitada por la tecnología.
CTL-PAD-001 Flujos de información La arquitectura de datos describe

Datos
formalmente completamente las estructuras y la

definidos conexión de la información del negocio
vía flujos de datos.
CTL-PAD-002 Alineación con las La arquitectura de datos asegura que

necesidades del los requerimientos de información
negocio estén debidamente alineados e
integrados con el cumplimiento de las
necesidades del negocio.
CTL-PAD-003 Claridad y La arquitectura de datos fomenta la

consistencia calidad de los datos a través de
definiciones claras y consistentes.
CTL-PAD-004 Toma de decisiones La arquitectura de datos proporciona

un marco básico para la explotación
de la información y toma de
decisiones.
172
CTL-PAA-001 Arquitectura de La arquitectura de aplicaciones es un

Aplicaciones
aplicaciones factor importante para el

aseguramiento de calidad de los
sistemas corporativos.
CTL-PAA-002 Trazabilidad La arquitectura de aplicaciones debe

garantizar la puesta en marcha de los
procesos de negocio.
CTL-PAA-003 Flexibilidad La arquitectura de aplicaciones debe

ser altamente modular, multi-capas y
flexible.
CTL-PAA-004 Consolidación La arquitectura de aplicaciones debe

promover primero la consolidación de
aplicaciones y luego la integración.
CTL-PAA-005 Orientada a la La arquitectura de aplicaciones debe

integración. reducir la complejidad de la
integración e incrementar la
simplicidad de las aplicaciones.
CTL-PAA-006 Orientada al servicio. La arquitectura de aplicaciones debe

seguir un enfoque orientado a
servicios (SOA) y en la nube (Cloud
computing).
CTL-PAA-007 Interoperabilidad La arquitectura de aplicaciones debe

permitir la interoperabilidad.
CTL-PAA-008 Acceso a la La arquitectura de aplicaciones debe

información. garantizar el acceso a los datos sin
importar su residencia o formato para
su consumo y análisis.
CTL-PAA-009 Soluciones de código Las aplicaciones que soportan el

abierto. negocio deberán estar implementadas
en plataformas de código abierto.
CTL-PAA-010 Maximizar el retorno La arquitectura de aplicaciones debe

y minimizar el riesgo tener un enfoque de cartera para el
análisis, planificación, gobierno y
optimización de las aplicaciones
empresariales.
173
CTL-PAA-011 Sistemas legados La arquitectura de aplicaciones debe

anticipar y planificar el reemplazo y
transición de las aplicaciones legadas.
CTL-PAA-012 Disponibilidad de La arquitectura de aplicaciones y los

documentación sistemas deben ser documentados
comprensivamente.
CTL-PAA-013 Seguridad Las aplicaciones deben cumplir con

requerimientos arquitectónicos de
seguridad.
CTL-PAT-001 Responsables. Todos los modelos, patrones, planos,

Tecnología
componentes, servicios y tecnologías

identificadas deberán tener
propietarios; ellos serán responsables
de la planificación, gestión,
administración y apoyo.
CTL-PAT-002 Modelo empresarial Es imprescindible contar con modelos

de integración empresariales de integración
tecnológica tecnológica que definan los conceptos
arquitectónicos básicos: diseños,
planos, componentes, servicios,
niveles de calidad, catálogos, carteras
de infraestructura, etc., así como sus
interrelaciones.
CTL-PAT-003 Enfoque de métricas Las implementaciones tecnológicas

de nivel de calidad requieren discusiones que deben
ocurrir tan pronto como sea posible,
entre los accionistas de la empresa y
las partes interesadas, incluyendo a:
arquitectos de aplicaciones,
arquitectos de tecnología, proveedores
de servicios y personal de operaciones
y mantenimiento.
CTL-PAT-004 Mantenimiento de la El mantenimiento de la infraestructura,

infraestructura. con excepción de reparaciones
críticas, deberá estar previamente
planificado; así como nuevas
iniciativas de despliegue de
aplicaciones y tecnologías.
174
CTL-PAT-005 Racionalización de La arquitectura tecnológica debe

productos y asegurar la racionalización de la
plataforma variedad de productos y plataformas
de TIC's.
CTL-PAT-006 Selección de Los productos se seleccionan con

productos. respecto a la optimización de las
métricas de nivel de calidad. La
tecnología, uniformidad, capacidad de
integrarse con los sistemas existentes,
costos, criterios de seguridad y
requisitos de privacidad también
deben ser considerados.
CTL-PAT-007 Portafolio de Es necesario la adopción de un

productos. enfoque de cartera en la planificación
y gestión de los productos de TIC's,
incluyendo software, hardware e
infraestructura.
CTL-PAT-008 Reutilizar, comprar y El diseño, ejecución y entrega de la

luego construir infraestructura se ajustará a los
principios arquitectónicos de
tecnología establecidos para la
empresa. El orden de preferencia para
la infraestructura y los componentes
de la infraestructura será el de:
reutilizar, comprar y luego construir.
CTL-PAT-009 Criterios de La seguridad y privacidad deben ser

seguridad diseñadas en los sistemas como parte
integral del proceso de diseño
tecnológico. Los sistemas se
diseñarán en base a criterios de
robustez y medidas de recuperación
ante desastres, con la intención de
asegurar la planificación de la
continuidad del negocio.
Fuente: Gómez, J. (2016).

Adaptado de Gómez.
Para mayor nivel de detalle (fundamentos e implicaciones) de los principios arquitectónicos

de la CTL, revisar el ANEXO 18: Principios arquitectónicos.
175
5.2.1.1.5 Identificar las mejores prácticas de los marcos de gestión empresarial
seleccionados e integrarlas con el marco arquitectónico propuesto.
• PMBOK: Esta guía de buenas prácticas de gestión de proyectos, define 5 grupos

básicos de procesos y nueve áreas de conocimiento. Los grupos básicos de
procesos definen el siguiente ciclo de gestión de proyectos:
Figura 70: Proceso de gestión de proyectos.

Fuente: PMBOK.
Adaptado de PMBOK.
PMBOK establece las siguientes consideraciones a tomar en cuenta por los responsables
de la gestión de proyectos, que permitirán asegurar el éxito de los mismos:
◦ Seleccionar los procesos apropiados dentro de los Grupos de Procesos de la

Dirección de Proyectos, necesarios para cumplir con los objetivos del proyecto.
◦ Usar un enfoque definido para adaptar las especificaciones del producto y los
planes, de tal forma que se puedan cumplir los requisitos del proyecto y del
producto.
◦ Cumplir con los requisitos para satisfacer las necesidades, deseos y expectativas
de los interesados.
◦ Equilibrar las demandas concurrentes de alcance, tiempo, costes, calidad,
recursos y riesgos para producir un producto de calidad.
The Open Group (2016) ha desarrollado la integración de los procesos arquitectónicos

establecidos por el marco de referencia TOGAF con los principales procesos del marco de
gestión de proyectos PMBOK. La gestión del proyecto arquitectónico iniciará con la fase A:
Visión arquitectónica, en donde como primera actividad se tiene que establecer el proyecto
arquitectónico.
176
A continuación, se presenta en la siguiente figura, la integración de los marcos de referencia
TOGAF y PMBOK:
Figura 71: Integración de TOGAF 9.1 y PMBOK.

177
• CREOPM: Como método de gestión de portafolio de proyectos, CREOPM dicta el
siguiente método:
Figura 72: Método de gestión de portafolio de proyectos CREOPM.

Fuente: Riofrío, B (2015).
Adaptado de Riofrío.
1. Categorizar: Proceso en el cual se desarrollar una diferencia entre los proyectos

discretos o los no discretos. Además, se definen reglas de lo que se puede hacer
y lo que no.
2. Analizar riesgos: Proceso en el cual se identifica, cuantifica, cualifica y se
gestionan los principales riesgos (de negocio, externos, operacionales, etc).
3. Evaluar: Proceso en el cual se valoran retornos de inversión, riesgos, costos y
tiempo.
4. Optimizar: Proceso en el cual se busca la mejor combinación de proyectos que
será parte del portafolio.
5. Priorizar: Proceso en el cual se determina la prioridad para la ejecución de los
proyectos, a través de indicadores cuantitativos o cualitativos para generar un
rango de proyectos.
6. Gestionar: Proceso en el cual se involucran: gestión de riesgos, gestión de
recursos, gestión de interesados y gestión del nivel de madurez.
178
• COSO: COSO II como marco de gestión de riesgos empresariales, proporciona el
siguiente proceso de gestión de riesgos:
Figura 73: Proceso de gestión de riesgos de COSO II.

Fuente: Deloitte & Touche (2012).
Adaptado de Deloitte & Touche.
Además, en el proceso de evaluación de riesgos se deben tomar las siguientes

consideraciones:
◦ Determinar riesgos a partir de dos perspectivas: Probabilidad e Impacto.

◦ Entre las técnicas propuestas del marco, se recomienda utilizar “determinar
riesgos” y “medir los objetivos relacionados”.
◦ En la evaluación de riesgos, la gerencia considera eventos previstos e
inesperados.
◦ Los riesgos inherentes y residuales son evaluados.
Cabe aclarar, que para la presente prueba de concepto se tomará en consideración las
mejores prácticas de gestión de riesgos establecidas por TOGAF, las mismas que se
mencionan en la técnica: Gestión de riesgos.
• ITIL: El método de desarrollo arquitectónico (ADM) de TOGAF y el ciclo de vida del

servicio establecido por ITIL, tienen algunos puntos en común (Figura 74). Sin
embargo, se deben considerar las siguientes cuestiones:
◦ El desarrollo de la arquitectura empresarial es parte de TOGAF. El alcance de

ITIL es limitado al desarrollo de una arquitectura tecnológica eficiente, por lo tanto
el desarrollo de la arquitectura empresarial está fuera de alcance en ITIL.
179
◦ La ejecución de operaciones de TI y la prestación de servicios de TI se
encuentran únicamente en el alcance de ITIL, a diferencia de TOGAF que no
cubre el desarrollo y mantenimiento de un entorno de tiempo de ejecución. Una
vez que una solución de TI se ha integrado al entorno tecnológico, se convierte
en (parte de) uno o más servicios, cuestión que TOGAF no gestiona.
Figura 74: Integración de TOGAF e ITIL.

• COBIT: El marco de gobernanza COBIT considera su integración con otros marcos

de gestión, dentro de los cuales soporta a TOGAF en dos dominios: Alinear,
Planificar y Organizar, y Desarrollar, adquirir e implementar. En la siguiente figura, se
evidencia la relación entre TOGAF y COBIT.
180
Figura 75: Integración de COBIT con otros marcos de gestión.
Fuente: ISACA (2014).
Adaptado de ISACA.
Del marco de referencia COBIT se tomará en consideración su modelo de supervisión,

descrito en la siguiente figura:
Figura 76: Modelo de supervisión de COBIT.

Fuente: ISACA (2014).
Adaptado de ISACA.
181
5.2.1.1.6 Implementar y configurar el repositorio arquitectónico empresarial.
Gartner (2015) en la siguiente figura, propone un conjunto de soluciones seleccionadas a

partir de los siguientes criterios:
Figura 77: Cuadrante mágico de Gartner sobre ECM (2015).

Fuente: Gartner (2015).
Adaptado de Gartner.
• Capacidad de ejecución: Producto o servicio, viabilidad general, costo, capacidad

de respuesta, marketing, experiencia del cliente y operaciones.
• Completitud de la visión: Comprensión del mercado, estrategia de
comercialización, estrategia de ventas, estrategia de oferta, modelo de negocio,
estrategia de industria, innovación y estrategia geográfica.
En el cuadrante mágico de Gartner para gestores de contenidos empresariales, se destacan

cuatro categorías:
182
 Líderes: Tienen los puntajes más altos combinando la capacidad de ejecución y la
completitud de visión. Se caracterizan por tener una visión altamente articulada,
tienen amplio soporte de su plataforma y brindan una adecuada atención al cliente.
 Competidores: Ofrecen buenas funcionalidades pero carecen de la visión de los
líderes.
 Visionarios: Se basan principalmente en los componentes principales de un gestor
de contenidos empresariales. Tienen una fuerte comprensión del mercado pero
tienen menor capacidad de ejecución que los líderes.
 Jugadores de nicho: Se centran en categorías específicas de la tecnología ECM.
Por lo general, funcionan solamente para determinadas regiones, industrias o
dominios.
El contexto en el cual se desarrolló la evaluación de Gartner, se enfoca principalmente en

empresas líderes y firmemente constituidas. Sin embargo, la consultora Gartner sugiere que
para empresas en donde se desee obtener los beneficios de este tipo de soluciones, pero
en las cuales no se cuente con los recursos para la implementación y administración de las
mismas, se debería seleccionar una herramienta que satisfaga por lo menos las siguientes
necesidades:
 Gestión de documentos en formato electrónico.

 Control de versiones en los documentos.
 Flujos de trabajo para el envío de documentos.
 Acceso seguro a documentos individuales.
 Acceso a través de dispositivos móviles.
 Organización de la información.
 Búsqueda y filtros en el repositorio de documentos.
Alfresco, DocuWare, Hyland, M-Files, Microsoft y Upland Software son empresas que
ofrecen soluciones orientadas a satisfacer las necesidades anteriormente descritas. Sin
embargo, el gestor de contenidos empresariales Alfresco One destaca por su simplicidad,
modernidad y estrategias que aseguran la integridad de la información. Ofrece una versión
de prueba, y se caracteriza por fomentar la colaboración simple y proporcionar una
comunidad activa de desarrollo y soporte.
183
La herramienta se organizará de acuerdo a la siguiente estructura, la cual permitirá dar
soporte al Continuum empresarial de la Cooperativa.
Figura 78: Estructura del repositorio arquitectónico de la CTL.

En la Figura 79, se presenta el trabajo que es necesario desarrollar para completar la fase.
Dentro de esta fase, la Cooperativa deberá alcanzar los siguientes objetivos:
1. Desarrollar una visión de alto nivel de las capacidades y del valor de negocio que se
desean obtener como resultado del trabajo arquitectónico.
2. Obtener la aprobación del entregable Enunciado del trabajo arquitectónico.
Para la consecución de los objetivos propuestos, se llevó a cabo el desarrollo de los

siguientes pasos:
184
Figura 79: Fase A: Visión arquitectónica del marco arquitectónico propuesto.
185
5.2.1.2.1 Establecer el proyecto arquitectónico.
El proceso de establecer el proyecto arquitectónico, de acuerdo a la integración de TOGAF

con PMBOK, consiste en aplicar el marco de gestión de proyectos a la ejecución de el ADM.
El gerente del proyecto que podría ser el arquitecto en jefe, será el responsable de la
ejecución del ciclo ADM. Además, se deberá determinar la cultura de la empresa y los
procesos y procedimientos existentes (en la Cooperativa de transportes Loja no existen
modelos de gestión de proyectos).
5.2.1.2.2 Identificar interesados, preocupaciones y requerimientos del negocio.
Este paso se apoyará del artefacto mapa de interesados, descrito a continuación:
Tabla 48: Mapa de interesados de la CTL.

Interesado Implicación Clase Jerarquía Nivel de interés Interés
Presidente Alta preocupación Mantener Alta Alto • Beneficios.

satisfechos
en la alineación • Recursos.
estratégica y en la • Limitaciones
validación de los • Alineación
objetivos estratégica.
estratégicos.
Gerente Responsable de la Mantener Alta Alto • Beneficios.

general satisfecho
elaboración de la • Recursos.
solicitud del trabajo • Limitaciones
arquitectónico. Alta • Alineación
preocupación en la estratégica.
alineación
estratégica y en la
validación de los
objetivos
estratégicos.
Asamblea de Encargados de la Mantener Alta Alto • Beneficios.

socios satisfechos
aprobación del • Recursos.
proyecto de
arquitectura
empresarial.
186
Consejo de Garantizan la Monitorear Media Medio • Recursos.

administraci
ón optimización de
recursos. Apoyan el
proceso de toma de
decisiones.
Consejo de Responsables de Monitorear Media Medio • Recursos.

vigilancia
evaluar el • Calendario.
cumplimiento del
proyecto en
calendario y
recursos. Apoyan la
definición de
métricas de
desempeño.
Apoyan el proceso
de toma de
decisiones.
Recursos Encargados de la Mantener Baja Medio • Recursos.

humanos informado
gestión del capital
humano. Definen
los roles y
responsabilidades
a cumplir.
Responsables del
proceso de
conformación del
equipo de
arquitectura
empresarial.
Departamento Colaboran en las Mantener Baja Alto • Limitaciones

de sistemas satisfechos
decisiones sobre la de TI.
elección de la • Requerimie
plataforma ntos de TI.
tecnológica. Alto • Usabilidad.
conocimiento de las
capacidades de TI
de la empresa.
Contabilidad Encargados de Mantener Baja Medio • Beneficios.

satisfechos
desarrollar • Recursos.
presupuestos para
el proyecto, y
efectuar
estimaciones.
187
Operarios Responsables de Mantener Baja Medio • Usabilidad.

desarrollar los informado
procesos que
soportan el
negocio.
5.2.1.2.3 Confirmar y elaborar objetivos, impulsores y limitaciones del negocio.
Referente a la perspectiva tecnológica, la Cooperativa de transportes Loja ha definido el

siguiente objetivo:
• Transformación tecnológica integral: Actualmente, la infraestructura tecnológica

de la empresa no permite una gestión adecuada de los procesos de negocio. Por lo
tanto, la Cooperativa de transportes Loja requiere un proyecto de transformación
tecnológica que permita alinear sus estrategias de TI con los objetivos estratégicos
de la empresa.
◦ Acciones estratégicas:
▪ Contratar una consultoría de TI.
▪ Definir áreas de transformación.
▪ Desarrollar el proyecto de transformación de TI.
▪ Presentar proyecto a la Asamblea general de socios para su aprobación.
▪ Ejecutar proceso de transformación de TI.
◦ Responsables:
▪ Gerencia.
▪ Consejo de administración.
▪ Socios.
◦ Indicadores de rendimiento:
▪ Cobertura de transformación de TI.
▪ Porcentaje de áreas intervenidas.
188
◦ Plazo:
▪ Inicio: Enero de 2016.
▪ Finalización: Diciembre de 2020.
Los impulsores de cambio y oportunidades pueden ser identificados a partir del análisis del
entorno empresarial. Los impulsores que provocan cambios en la empresa son cuatro:
• Contexto del mercado: En el contexto del mercado se consideran las relaciones

con los proveedores, restricciones regulatorias, valor del mercado, costos y
tendencias de la industria. Se ha determinado que:
◦ Se mantienen restricciones arancelarias relacionadas a la prestación de servicios
de transporte.
◦ Existen regulaciones y proyectos de gobiernos locales que dificultan las
operaciones de la empresa.
◦ Alto control gubernamental.
• Competidores: A través de este factor, se analiza a empresas que prestan servicios

similares a los ofrecidos por la empresa. Este factor permite determinar la propuesta
de valor de la competencia. La Cooperativa de transportes Loja debe hacer frente a:
◦ Incremento en la capacidad operativa de la competencia.
◦ Creciente número de instituciones competidoras en transporte intercantonal
• Clientes: Este factor permite el entendimiento de los clientes potenciales y actuales

de la empresa. La importancia de analizar este factor es permitir orientar el diseño de
los servicios a las necesidades del cliente. La Cooperativa de transportes Loja,
sensible a las necesidades de sus clientes, ha emprendido proyectos para innovar la
experiencia de sus usuarios.
• Estrategias: Este factor describe los impulsores y objetivos empresariales,

proporcionando un contexto para las propuestas de valor y el modelo operativo que
las soporta. Con la nueva planificación estratégica de la Cooperativa existen
objetivos que la empresa deberá desarrollar para alcanzar su visión.
189
5.2.1.2.4 Evaluar las capacidades empresariales.
Para evaluar las capacidades empresariales de la Cooperativa de transportes Loja, se

definieron ciertos criterios en los dominios de negocio, datos, aplicaciones y tecnología. A
continuación, se presenta de forma resumida los resultados de dichas evaluaciones:
En cuanto a las capacidades de negocio de la Cooperativa, se determinó:
Tabla 49: Evaluación de las capacidades de negocio de la CTL.
Subdominio Evaluación
• Motivación
0,875/1,75
• Impulsores, metas, objetivos y medidas.
• Funciones
• Procesos, calidad de servicio, eventos, 0,375/2,25
controles.
• Organización
0,5/1
• Actores, roles.
Total 1,75/5
En cuanto a las capacidades de datos de la Cooperativa, se determinó:
Tabla 50: Evaluación de las capacidades de datos de la CTL.
• Modelo de datos
• Entidades de datos, componentes 0/2
lógicos y físicos de datos.
• Gestión de la información
• Organización, migración, gobernanza,
0.75/3
toma de decisiones y consideraciones
de seguridad.
Total 0.75/5
En cuanto a las capacidades de aplicaciones de la Cooperativa, se determinó:
190
Tabla 51: Evaluación de las capacidades de aplicaciones de la CTL.
• Arquitectura de aplicaciones
0,47/3,125
• Componentes lógicos y físicos.
• Administración
• Consideraciones de seguridad, 0.47/1,875
estrategias de TI.
Total 0.94/5
En cuanto a las capacidades de tecnología de la Cooperativa, se determinó:
Tabla 52: Evaluación de las capacidades tecnológicas de la CTL.
• Modelo de integración tecnológica

• Plataforma, componentes lógicos y 0/3
físicos, consideraciones de seguridad
• Administración
0,5/2
• Estrategias de TI.
Total 0,5/5
Lo anteriormente descrito, se puede representar en la siguiente figura:
0
Negocio Datos Aplicaciones Tecnología
Figura 80: Evaluación de las capacidades empresariales de la CTL.
191
Como se puede observar en la anterior figura, la Cooperativa de transportes Loja no cuenta
con capacidades sólidas en negocio y TI. Al no existir procesos formalmente definidos,
modelo de datos, arquitectura de aplicaciones ni modelo de integración tecnológica, se
crean muchas brechas para alcanzar la visión arquitectónica de la empresa.
Respecto a la madurez arquitectónica de la empresa, gracias al modelo de madurez ACMM,

se estableció que la Cooperativa se encuentra en el nivel 0: ninguno, debido a que aún no
se han desarrollado iniciativas de arquitectura empresarial en la empresa. De la misma
manera, se sugirió que la empresa alcance el nivel 3: definido, en el cual todos los procesos
de arquitectura empresarial y el modelo técnico de referencia se encuentren establecidos.
Se evaluó también cuán preparada está la empresa para desarrollar proyectos de

transformación empresarial, para ello se tomó como referencia el modelo de madurez
establecido por BTM2. La Cooperativa de transportes Loja actualmente se encuentra en el
primer nivel del modelo, debido a que presenta las siguientes características:
• Preparación de TI: aplicaciones locales de TI, datos no armonizados, diferentes

conceptos de soporte de TI, falta de estrategias.
• Preparación de procesos: procesos locales, falta de estándares en los procesos,
propietarios de los procesos no definidos.
• Preparación organizacional: no existen políticas globales, dominios centrados en
necesidades locales.
Finalmente, se sugirió que la empresa alcance el tercer nivel del modelo:
• Preparación de TI: TI globalmente armonizado, sistemas totalmente integrados,

altas funcionalidades de informes, externalización de tareas menos importantes.
• Preparación de procesos: organización global flexible, mejora e innovación
permanente.
• Preparación organizacional: procesos que apoyan la documentación y
optimización, adaptación rápida a nuevos requerimientos del negocio.
Para mayor información de la evaluación de capacidades desarrollada, revisar: ANEXO 19:

Evaluación de capacidades.
192
5.2.1.2.5 Definir el alcance.
Para el presente trabajo, se tiene planificado definir los componentes arquitectónicos

necesarios para soportar el primer segmento de la cadena de valor de la Cooperativa:
planificación de turnos. Sin embargo, para mantener la coherencia en el desarrollo del
trabajo se especificarán también aquellos componentes que sean transversales a toda la
cadena de valor.
5.2.1.2.6 Refinar los principios arquitectónicos, si es necesario.
Conforme avance el proceso arquitectónico en la empresa, se deberá evaluar si es

pertinente la actualización de el artefacto y entregable “Principios arquitectónicos”
establecidos en la fase preliminar. Refinar los principios arquitectónicos es una buena
práctica arquitectónica porque permitirá tener consistencia entre las descripciones de la
arquitectura y sus directrices (principios arquitectónicos).
5.2.1.2.7 Desarrollar la visión arquitectónica.
Figura 81: Diagrama de concepto de solución.

193
La Cooperativa de transportes Loja necesita emprender un proyecto de transformación
integral tecnológico que le permita adoptar nuevos modelos de negocio y ofrecer servicios
que satisfagan los requerimientos de los clientes. Para lograrlo, se sugirió adoptar la
tendencia tecnológica SMAC (redes sociales, dispositivos móviles, análisis de datos y
computación en la nube), la cual posibilitará a la empresa generar nuevas oportunidades e
innovar en la forma de prestación de servicios. En la Figura 81, se presenta el diagrama de
concepto de solución que contiene a la visión arquitectónica de la empresa. Para mayor
información de la visión arquitectónica de la CTL, revisar el ANEXO 20: Visión
arquitectónica.
5.2.1.2.8 Definir los beneficios que entregará la arquitectura destino y los

indicadores claves de desempeño.
Los beneficios identificados (Montalván, 2016) a partir de la adopción del modelo

tecnológico SMAC (arquitectura destino de la CTL) son :
• Monitoreo y control de procesos.
• Mejora continua de procesos.
• Aseguramiento de integridad, consistencia y privacidad de la información.
• Explotación y análisis de la información.
• Toma de decisiones.
• Difusión e intercambio de información.
• Interoperabilidad de sistemas informáticos.
• Soporte no complejo de sistemas informáticos.
• Adopción de protocolos de seguridad en el control de acceso a los sistemas.
• Conjunto de canales y dispositivos adecuados para el acceso.
• Agilidad en la prestación de los servicios bajo demanda.
A partir de la planificación estratégica de la empresa, se han identificado preliminarmente los

siguientes indicadores claves de desempeño:
• Cobertura de transformación de TI desarrollada de acuerdo al proyecto de
transformación de TI.
• Porcentaje de áreas intervenidas hasta el año 2020.
194
5.2.1.2.9 Identificar riesgos y actividades de mitigación.
Para la identificación de riesgos y sus principales actividades de mitigación, se ha tomado

como referencia el proceso de gestión de riesgos establecido en la técnica Gestión de
riesgos de TOGAF. En la siguiente tabla, se presenta el resultado de dicho análisis:
Tabla 53: Análisis de riesgos del proyecto arquitectónico.
Riesgo Frecuencia Impacto Mitigación
Falta de compromiso de Media Medio • Crear una cultura de

los involucrados. comunicación y educación
respecto del trabajo
arquitectónico parar
generar compromiso en los
involucrados.
• Asegurar la ejecución del
plan de comunicaciones del
proyecto.
Falta de apoyo de la alta Baja Medio • Lograr conciencia y

dirección. compromiso respecto a la
participación activa de la
alta dirección.
Comunicación Media Bajo • Asegurar la ejecución del

inadecuada. plan de comunicaciones del
proyecto.
Insuficiente cantidad de Alta Medio • Evaluar la posibilidad de

profesionales capacitados que un profesional cubra
para formar el equipo de más de un rol.
arquitectura empresarial. • Desarrollar programas de
capacitación y formación
del personal.
Estimación errónea de Media Alto • Emplear estándares o

recursos. metodologías para
estimación.
Planificación inadecuada. Media Alto • Definir hojas de ruta y

potenciales arquitecturas de
transición, que
proporcionen una visión del
trabajo a efectuar.
195
Visión arquitectónica Baja Alto • Alinear los objetivos
sobredimensionada. estratégicos de la empresa
con las estrategias de TI.
Medición inadecuada del Media Medio • Definir e implementar

desempeño. indicadores clave de
desempeño.
Seguimiento inadecuado Media Medio • Implementar herramientas

de los resultados. como el cuadro de mando
integral para medir el
cumplimiento de las
estrategias de la empresa.
5.2.1.2.10 Desarrollar el Enunciado del trabajo arquitectónico; asegurar su

aprobación.
Una vez culminados los pasos de la fase A, se ha desarrollado el Enunciado del trabajo
arquitectónico, el cual contiene la mayor parte de contenidos generados en esta fase. Para
más información revisar
Para el presente proceso de prueba de concepto, se tomará en consideración únicamente la

arquitectura de aplicaciones. Sin embargo, se detallarán los elementos transversales a los
dominios restantes.
Dentro de las fases de esta iteración, la Cooperativa debe alcanzar los siguientes objetivos:
1. Desarrollar la arquitectura destino.

2. Identificar posibles componentes a ser incluidos en la Hoja de ruta de la
implementación.
En la figura 82, se presenta el trabajo a desarrollar en las fases de esta iteración. Para la
consecución de los objetivos propuestos, se llevó a cabo el desarrollo de los siguientes
pasos:
196
Figura 82: Fases B, C y D del marco arquitectónico propuesto.
197
5.2.2.1 Seleccionar modelos de referencia, puntos de vista y herramientas.
Para la definición de la arquitectura de aplicaciones destino, se ha tomado en consideración

el modelo de referencia técnico presentado en la figura 83. En este modelo, se pueden
distinguir las siguientes capas (Montalván, 2016):
• Capa de Desarrollo: Capa que hace referencia a los servicios empleados para:
◦ Desarrollo de aplicaciones
◦ Desarrollo de aplicaciones de Inteligencia de negocios.
◦ Composición de procesos.
◦ Modelado de datos.
◦ Exploración de datos.
• Capa de Integración: Capa que hace de mediación para la comunicación entre

capas. Los servicios que se encuentran en esta capa son:
◦ Servicios de mediación
◦ Mensajería
◦ Conectividad
◦ Movimiento de datos.
• Capa de Interacción: Capa que se encuentra ubicada entre los medios de acceso y
la capa de aplicación, esta capa permite:
◦ Interacción con entornos web.

◦ Interacción con entornos móviles.
◦ Interacción con dispositivos
◦ Interacción con servicios/API
◦ Interacción con redes sociales
◦ Interacción con el negocio
◦ Alertas y notificaciones programables.
198
Figura 83: Modelo de referencia técnico de la CTL.
Elaboración: Montalván (2016).
• Capa de aplicaciones: contiene a todas las aplicaciones, además cuenta con

servicios de orquestación que preparan a las mismas para compartir información.
Esta capa está compuesta por:
◦ Aplicaciones del negocio: En la Cooperativa de transportes Loja se han

identificado las siguientes aplicaciones:
▪ Sistema de gestión de turnos.

▪ Sistema de venta de boletos.
199
▪ Sistema de control de abordaje.
▪ Sistema de control de equipaje.
▪ Sistema de control y localización.
▪ Sistema de control de arribo.
▪ Sistema de control y seguimiento.
◦ Servicios del negocio.

◦ Análisis del negocio.
◦ Aplicaciones de medios sociales.
◦ Orquestación de procesos de negocio.
◦ Servicios de orquestación.
◦ Reglas de negocio.
• Capa de Infraestructura: Capa que permite la construcción de redes que permiten

la comunicación entre aplicaciones. Compuesta por los siguientes servicios:
◦ Computación basada en servidores

◦ Computación móvil
◦ Virtualización y aprovisionamiento
• Capa de seguridad: está encargada de que se cumplan los protocolos de seguridad

establecidos por la organización, para preservar la integridad de la información y las
aplicaciones. Los servicios de esta capa son:
◦ Seguridad en: aplicaciones, transporte de información, API s, datos, móvil, web

services.
◦ Gestión de identificación al acceso al sistema.
• Capa de gestión: Permite la administración de la interacción entre los componentes

de las diferentes capas. Esta capa permite la gestión de:
◦ Aplicaciones, Servicios, Procesos de negocio y Reglas de negocio.

◦ De ambientes para: Cloud, Móviles y Dispositivos inteligentes.
200
5.2.2.2 Desarrollar la descripción de las arquitecturas de línea base y destino.
• Arquitectura de aplicaciones de línea base: Como se mencionó anteriormente, la

Cooperativa de transportes Loja no cuenta con una arquitectura de aplicaciones, por
lo tanto no se puede establecer la descripción de la misma.
• Arquitectura de aplicaciones destino: De acuerdo a la visión arquitectónica de la

empresa, el modelo arquitectónico de la empresa que soportará las nuevas
operaciones del negocio es Arquitectura Orientada a Servicios (SOA).
Figura 84: Arquitectura de referencia SOA.

Fuente: Romero (2015).
Adaptado de Romero.
201
◦ Arquitectura orientada a servicios: es un marco de trabajo conceptual que
establece una estructura de diseño para la integración de aplicaciones, que
permite a las organizaciones unir los objetivos de negocio, en cuanto a
flexibilidad de integración con sistemas legados y alineación directa a los
procesos de negocio, con la infraestructura de TI. A continuación, se presenta la
arquitectura de aplicaciones destino de la Cooperativa de transportes Loja, que
se acopla al modelo técnico de referencia mencionado anteriormente.
▪ Capa de presentación: Capa que interactúa directamente con el usuario

final.
▪ Capa de lógica de negocios: Capa encargada del procesamiento de los
datos. Contiene reglas y directrices del negocio.
▪ Capa de datos: Capa que brinda acceso a los datos. Es utilizada
principalmente por una herramienta de persistencia.
▪ Capa transversal: Capa que contiene características comunes para todas
las capas (seguridad, gestión, comunicaciones).
La descripción detallada del nuevo modelo arquitectónico se encuentra documentada en el

ANEXO 22: Documento de definición arquitectónica.
5.2.2.3 Realizar el análisis de brechas.
Un paso clave en las fases de la iteración de desarrollo arquitectónico es evaluar y validar si

existen componentes no incluidos en la descripción arquitectónico. La arquitectura debe
soportar todas las necesidades esenciales de procesamiento de información de la
organización. La fuente más crítica para efectuar el análisis de brechas son las
preocupaciones de las partes interesadas que no han sido abordadas en el trabajo
arquitectónico previo.
En el ANEXO 23: Documento de definición arquitectónica, se puede encontrar el análisis de

brechas desarrollado para el proyecto arquitectónico.
202
5.2.2.4 Definir los componentes candidatos que conformarán la Hoja de ruta de la
implementación.
Preliminarmente y a partir del análisis de brechas desarrollado en el anterior paso, se han

establecido los siguientes componentes:
Tabla 54: Componentes candidatos para la Hoja de ruta de la implementación.
Dominio Proyecto
Negocio Unificación y estandarización de procesos.
Definición de la nueva infraestructura de datos de la

Datos
empresa.
Aplicaciones Implementación de un nuevo esquema arquitectónico
Despliegue de la plataforma tecnológica que soporte el

Tecnología
nuevo esquema arquitectónico.
Los componentes anteriormente descritos conformarán el entregable Hoja de ruta de la

implementación, que se desarrollará en las fases E y F del marco arquitectónico propuesto.
5.2.2.5 Conducir revisiones formales con los interesados.
Una vez que se ha culminado preliminarmente el proceso de descripción arquitectónico, es

necesario que se establezcan revisiones formales con los interesados para acordar cambios
y buscar conformidad con los modelos presentados. De ser necesario se deberá actualizar
el entregable Documento de definición arquitectónica.
5.2.2.6 Crear la versión preliminar del Documento de definición arquitectónica.
Al haber desarrollado las revisiones formales con los interesados y al actualizar el contenido
generado hasta el momento, se deberá elaborar la versión preliminar del Documento de
definición arquitectónica.
203
5.3 Análisis de los resultados obtenidos.
Aunque la validación del marco arquitectónico propuesto, se la desarrolló a nivel conceptual,

definiendo claramente la visión arquitectónica de la Cooperativa de transportes Loja y las
brechas preliminares para alcanzar la arquitectura destino, el proceso arquitectónico llevado
a cabo se caracterizó por su simplicidad y coherencia.
El lenguaje natural de la descripción de los componentes del método de desarrollo

arquitectónico, posibilitó desarrollar fácilmente el trabajo planificado en la empresa. Además,
al haberse empleado un lenguaje común se logró un entendimiento rápido del alcance del
proyecto arquitectónico por parte de todos los interesados.
La alineación entre objetivos, pasos y productos arquitectónicos del marco propuesto

permitió efectuar un trabajo vinculado y secuencial, proporcionando claridad respecto al
esfuerzo a realizar por cada una de las fases.
El marco propuesto fue enriquecido sustancialmente con las herramientas, marcos de

soporte adicional y técnicas seleccionadas para apoyar al método de desarrollo
arquitectónico. Aunque su uso no se considera obligatorio, son alternativas válidas que
colaboran en tareas específicas del ADM, brindando mejores prácticas y guías.
La documentación organizada fue un proceso imprescindible en el trabajo efectuado en la

empresa. El marco propuesto no reduce considerablemente la cantidad de productos
arquitectónicos a desarrollar, sin embargo ofrece versiones más compactas del contenido de
los documentos. Ésta es una característica muy importante del marco, debido a que
generalmente el proceso de documentación en las empresas es considerado tedioso.
De forma general, el marco arquitectónico propuesto fue una solución válida que simplificó el
trabajo a desarrollar en la empresa. A través de sus componentes, se logró que la
Cooperativa de transportes Loja soporte procesos de arquitectura empresarial, que apoyen
el proyecto de transformación tecnológica integral requerido por la empresa.
204
CONCLUSIONES
• Las pequeñas y medianas empresas (PYMEs) de la zona de planificación 7,

presentan una capacidad tecnológica limitada, producto de la falta de una cultura de
extensión tecnológica y del desconocimiento de las posibilidades para acceder y
aprovechar nuevas tecnologías.
• La integración de prácticas de arquitectura empresarial con esquemas ágiles, facilita

el desarrollo de marcos arquitectónicos adaptados a las características de las
pequeñas y medianas empresas.
• Para lograr la definición de los principales componentes del marco arquitectónico

propuesto, fue necesario determinar la estructura de las PYMEs de nuestro país,
particularmente las pertenecientes a la zona de planificación 7, e identificar sus
principales características.
• En base al análisis de cada una de las fases que conforman las iteraciones de
capacidad y desarrollo arquitectónico del ADM, y a las características de las
metodologías ágiles se logró reducir el nivel de complejidad del marco arquitectónico
TOGAF y conciliar las actividades específicas para su implementación en PYMEs.
• El marco arquitectónico propuesto se presenta como una herramienta que permitirá a

la Cooperativa de transportes Loja mejorar su entorno de negocio, operativo,
financiero, organizacional, econométrico, de responsabilidad y de gestión de riesgos,
debido a que posibilita:
◦ Facilidad en la comprensión de los principales procesos de arquitectura
empresarial.
◦ Establecer las mejores prácticas a ser integradas en las PYMEs.
◦ Mejorar la cultura organizacional de la empresa.
◦ Racionalizar los recursos empresariales (humanos, financieros, materiales y
tecnológicos).
◦ Formular estrategias para la gestión de los riesgos.
205
• La adopción de prácticas arquitectónicas para la transformación empresarial
dependerá, en gran medida, del grado de compromiso del grupo de interesados del
proyecto.
• Debido a que la Cooperativa de transportes Loja no ejecutó su planificación

estratégica 2016-2020, el presente trabajo se desarrolla a nivel de propuesta.
206
RECOMENDACIONES
• Adoptar íntegramente el modelo propuesto en el presente trabajo, debido a que su

implementación incrementará las posibilidades de éxito de proyectos de
transformación empresarial en PYMEs.
• Previo al proceso de adopción del marco arquitectónico en una PYME, los altos
directivos de la empresa deben tener noción de prácticas de arquitectura empresarial
y metodologías ágiles; mientras que el equipo de arquitectura empresarial deberá
lograr conocimientos consolidados.
• En procesos de transformación empresarial, para lograr la alineación de los objetivos

de negocio y TI, es necesario que se ejecute la planificación estratégica empresarial.
• Complementar las prácticas del marco arquitectónico propuesto con las mejores
prácticas identificadas de los marcos de gestión de negocios y TI, lo cual permitirá
desarrollar un enfoque holístico en una PYME.
• Crear una cultura organizacional de comunicación y educación, respecto del trabajo

arquitectónico a efectuar, posibilitando la generación de un compromiso de
conciencia de los involucrados.
• Lograr una participación activa de la alta dirección y de las unidades operativas de la

empresa en la ejecución del proyecto de transformación empresarial.
207
BIBLIOGRAFÍA
• Aramayo, O. (2016). Manual de planificación estratégica.

• Basole, R., & DeMillo, R. (2006). Enterprise IT and transformation.Enterprise
transformation: Understanding and enabling fundamental change, 223-252.
• Bayney R. & Chakravati R. (2012). Enterprise Project Portfolio Management: Building
Competencies for R&D and IT Investment Success.
• Bente, S., Bombosch, U., & Langade, S. (2012). Collaborative enterprise architecture:
enriching EA with lean, agile, and enterprise 2.0 practices. Newnes.
• Bernal, C. (2000). Metodología de la investigación para administración y economía.
• Bernard, S. (2012). An introduction to enterprise architecture. AuthorHouse.
• Bloomberg, J. (2013). The agile architecture revolution: how cloud computing, rest-
based SOA, and mobile computing are changing enterprise IT. John Wiley & Sons.
• Bloomberg, J. (2015). Does agile EA equal agile plus EA?. Recuperado de:
http://www.opengroup.org/node/3035
• Carchi, K. (2016). Definición de marco de referencia de Arquitectura Empresarial
para PYMES. -Iteraciones de gobernanza y transición arquitectónica ADM TOGAF.
UTPL.
• CEDETEL (2004). Implantación de servicios avanzados de información y
comunicación a colectivos de PYME de áreas periféricas del Sudeste Europeo (TIC-
PYME). Castilla y León: TIC, PYME.
• Deloitte & Touche (2012). Evaluación de riesgos en práctica. COSO.
• Departamento de defensa de los Estados Unidos (2010). The DoD Architecture
framework DODAF Version 2.02.
• Dico, A. (2012). Towards Whole-of-Government EA with TOGAF and SOA.Enterprise
Architecture for Connected E-Government: Practices and Innovations, 177-204.
• Fayol, H. (1916). Administration Industrielle Et Générale [Libro]. París:[sn].
• Fishman N., Selkow W. (2003). Enterprise Architecture Using the Zachman
Framework. Thomson Course Technology.
• Gartner Inc. (2005). Gartner Enterprise Architecture Framework: Evolution 2005.
• Gartner Inc. (2015). Magic Quadrant for ECM. Recuperado de:
https://www.gartner.com/doc/reprints?id=1-2Q79LWH&ct=151021&st=sb
208
• Gómez, J. (2015). Levantamiento, definición e implementación de la Capa de
Negocio de MALCA Cía. Ltda., utilizando la descripción del modelado arquitectónico
ADM-TOGAF. UTPL.
• Greefhorst, D. (2015). Agile, TOGAF and Enterprise Architecture: Will they Blend?.
Recuperado de: http://slideshare.net/dannygreefhorst/agile-togaf-and-enterprise-
architecture-will-they-blend
• Hernández, R., Fernández, C., & Baptista, P. (2006). Metodología de la investigación.
México: Editorial Mc Graw Hill.
• IBM (2008). Enterprise architecture concept and practice. Recuperado de:
http://www-05.ibm.com/lt/globali_patirtis/pdf/Enterprise_Architecture_-
_concept_and_practice.pdf
• Instituto Nacional de Estadísticas y Censos. (2012). Directorio de Empresas y
Establecimientos 2012. Recuperado de:
http://anda.inec.gob.ec/anda/index.php/catalog/110/related_materials
• Íñiguez (2016). Definición de un Marco de Referencia para Gobernanza de TI,
basado en la norma ISO 38500, para la Cooperativa de Transportes Loja. UTPL.
• ISACA (2014). COBIT 4.1 Framework.
• Kapurubandara, M. (2009). A framework to e-transform SMEs in developing
countries. The Electronic Journal of Information Systems in Developing Countries, 39.
• Levy, M., & Powell, P. (2004). Strategies for Growth in SMEs: The Role of Information
and Information Sytems. Butterworth-Heinema.
• Ministerio de telecomunicaciones. (2013). Encuesta sobre TIC's a nivel empresarial.
• Minoli, D. (2008). Enterprise architecture A to Z: frameworks, business process
modeling, SOA, and infrastructure technology. CRC Press.
• MIPRO & AESOFT (2012). Reporte de situación de las TIC en las PYMEs del
Ecuador. Recuperado de: http://aesoft.com.ec/ticsyproductividad/.
• MIPRO (2013). Código orgánico de la producción, comercio e inversiones.
Recuperado de: http://www.proecuador.gob.ec/wp-
content/uploads/2013/07/codigoproduccion.pdf
• Montalván (2016). Definición del modelo técnico de referencia (TRM) e
infraestructura integrada de información (III-RM), basados en TOGAF 9.1, propuestos
para transformación digital de empresas.
• OCDE (2010). Las TIC y el desarrollo económico de México. Recuperado de:
209
https://www.oecd.org/centrodemexico/presentaciones2010.htm
• OMB (2013). Federal Enterprise Architecture Framework. Version 2. Recuperado de:
https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/fea_v2.pdf
• Op't Land, M., Proper, E., Waage, M., Cloo, J., & Steghuis, C. (2008). Enterprise
Architecture. Springer.
• Oracle (2015). Enterprise architecture for Digital Business. Recuperado de:
http://www.oracle.com/us/solutions/enterprise-architecture/oow-2015-digital-business-
2762659.pdf
• Pallares, Z., Romero, D., & Herrera, M. (2005). Hacer Empresa: Un Reto. España:
Fondo Editorial Nueva Empresa.
• Pérez, M., Sánchez, A., Carnicer, M., & Jiménez, M. (2004). La adopción del
teletrabajo y las tecnologías de la información: estudio de relaciones y efectos
organizativos. Revista de economía y empresa, 22(52), 11-28.
• PMBOK (2013). Guía de los fundamentos de gestión de proyectos.
• Popescu, T., Achim, I., & Kadar, M. (2014). Enterprise Transformation Through
Supporting Information Systems. The Case Of A Romanian Hotel Chain. In Balkan
Region Conference on Engineering and Business Education (Vol. 1, No. 1, pp. 131-
136).
• Porter, M., & Stern, S. (2002). National innovative capacity, in: M.E. Porter, J.D.
Sachs, P.K. Cornelius, J.W. McArthur, K. Schwab (eds.), The Global Competitiveness
Report 2001-2002, New York: Oxford University Press, 102-118.
• Potgieter, B., Botha, J., & Lew, C. (2005). Evidence that use of the ITIL framework is
effective. In 18th Annual conference of the national advisory committee on computing
qualifications, Tauranga, NZ (pp. 160-167).
• Real Academia Española. (2014). Diccionario de la lengua española (22 ed.).
Consultado en: http://www.rae.es/rae.html.
• Ridley, G., Young, J., & Carroll, P. (2004). COBIT and its Utilization: A framework from
the literature. In System Sciences, 2004. Proceedings of the 37th Annual Hawaii
International Conference on (pp. 8-pp). IEEE.
• Riofrío, B. (2015). “Identificación de activos en los portafolio de TI”. UTPL.
• Rodríguez, L. (2011). Dimensionamiento. Recuperado de:
http://pwcspain.typepad.com/files/experiencias-en-procesos-de-
dimensionamiento.pdf
210
• Romero, F. (2015). Levantamiento y definición de la capa Arquitectónica de Sistemas
y Aplicaciones del Grupo Empresarial Monterrey, utilizando la descripción del
modelado arquitectónico ADM-TOGAF. UTPL.
• Romero, R. (1997). Marketing.Tercera edición. Editora Palmir E.I.R.L. Págs. 9 al 15.
• Rovira, S., (2013). Incorporación de TIC en el sector productivo: uso y desuso de las
políticas públicas para favorecer su difusión. Rovira, S. y Stumpo, G.(Comp.). Entre
mitos y realidades. TIC, políticas públicas y desarrollo productivo en América Latina,
17-53.
• Sabesan, S., Hornford, D., Toder, S., Street, K., Hornford, T. (2016). Word-Class EA:
A Leader’s Approach to Establishing and Evolving an EA Capability. The Open Group.
Recuperado de: https://www2.opengroup.org/ogsys/publications/viewDocument.html?
publicationid=14260&documentid=13432
• Sánchez, J. C. (2011). Metodología de la investigación científica y tecnológica.
Ediciones Díaz de Santos.
• Schekkerman, J. (2004). How to survive in the jungle of enterprise architecture
frameworks: Creating or choosing an enterprise architecture framework. Trafford
Publishing.
• Servicio de Rentas Internas. (2015). PYMES. Recuperado de:
http://www.sri.gob.ec/de/32
• Sessions (2013). “Una comparación de los cuatro principales marcos de arquitectura
empresarial”. Recuperado de: https://msdn.microsoft.com/en-
us/library/bb466232.aspx
• Suárez, A. (2010). Importancia de la arquitectura empresarial en las organizaciones
modernas. Revista Matices tecnológicos, 2. Recuperado de:
http://www.unisangil.edu.co/publicaciones/index.php/revista-matices-
tecnologicos/article/view/102.
• Superintendencia de compañías (2014). Recuperado de:
https://www.supercias.gov.ec/web/privado/marco%20legal/CODIFIC%20%20LEY
%20DE%20COMPANIAS.pdf
• Swende, E., Ohlin, B., Dahkvist, J. (2011). Agile EA in Theory and Practice.
Recuperado de: http://www.irm.se/document/document/168.
• The Open Group (2009). The open group architecture framework (TOGAF). Versión
9. Recuperado de: http://pubs.opengroup.org/architecture/togaf9-doc/arch/
• The Open Group (2015). A Pocket Guide. The Open Group.
211
• The Open Group (2015). The open group architecture framework (TOGAF). Versión
9.1. Versión online disponible: http://pubs.opengroup.org/architecture/togaf9-
doc/arch/
• The Open Group (2016). How to Manage an Architecture Project using the Togaf
Framework and Mainstream Project Management Methods. The Open Group.
• The Open Group (2016). TOGAF and ITIL. The Open Group.
• Uhl, A., & Gollenia, L. A. (2012). A Handbook of Business Transformation
Management Methodology. Gower.
• Weill P. (2007). Sexta Conferencia de E-Business. MIT Center for Information
Systems Research. Barcelona-España, Marzo 27, 2007.
• Zachman, J. (1987). A Framework for Information Systems Architecture. In: IBM
Systems Journal, vol 26, no 3. IBM Publication G321-5298.
• Zachman, J. (2008). John Zachman's Concise Definition of The Zachman
Framework™. Zachman International, USA.
• Zachman, J. (2011). The Zachman Framework. Version 3.
• Zwikael, O. (2009). The relative importance of the PMBOK® Guide's nine Knowledge
Areas during project planning. Project Management Journal, 40(4), 94-103.
212
ANEXOS
213
ANEXO 1: Iteración de capacidad arquitectónica TOGAF 9.1.
Tabla 55: Iteración de capacidad arquitectónica de TOGAF.
Fase Entradas Objetivos Pasos Salidas Técnicas

Fase preliminar.
• Otros marcos de 1. Determinar las capacidades 1. Determinar las áreas • Modelo Principios
referencia arquitectónicos. deseadas.
◦ Examinar el contexto de la empresa que organizacional de arquitectónicos
• Estrategias del consejo
organizacional, planes y
organizacional para llevar serán impactadas. arquitectura
a cabo el proyecto. 2. Confirmar los marcos
estrategia de negocio; ◦ Identificar y determinar el
empresarial.
estrategia de TI; principios alcance de los unidades de referencia de • Marco de referencia
objetivos e impulsores del de la empresa que serán gobernanza y de arquitectónico
negocio. afectadas por la capacidad
arquitectónica.
soporte adicional. adaptado, incluyendo
• Marcos de referencia de
gobernanza. ◦ Identificar marcos de 3. Definir y establecer el principios
• Capacidades referencia establecidos, equipo de arquitectónicos.
métodos y procesos que
arquitectónicas. se entrecrucen con la arquitectura • Repositorio
• Acuerdos de asociación y capacidad arquitectónica. empresarial y su arquitectónico inicial.
contratos. ◦ Establecer la madurez de
• Modelo organizacional de la capacidad destino.
organización. • Reafirmación o
arquitectura empresarial 2. Establecer las capacidades 4. Identificar y referencia de los
existente. arquitectónicas. establecer los principios, objetivos
• ◦ Definir y establecer el
Marco de referencia
modelo organizacional de
principios impulsores del
arquitectónico existente, si arquitectónicos.
lo hay, incluyendo:
arquitectura empresarial. negocio.
◦ Método arquitectónico,
◦ Definir y establecer el 5. Adaptar TOGAF y, si • Solicitud de trabajo
proceso detallado y los
contenido recursos para la es necesario, otros arquitectónico.
arquitectónico, gobernanza. marcos de referencia • Marco de referencia
herramientas ◦ Seleccionar y poner en arquitectónicos
práctica las herramientas
de gobernanza.
configuradas e
implementadas, que apoyen la actividad seleccionados.
principios arquitectónica. 6. Implementar
◦ Definir los principios
arquitectónicos, arquitectónicos.
herramientas
repositorio arquitectónicas.
arquitectónico.
214
Fase A: Visión arquitectónica.
• Solicitud de trabajo 1. Desarrollar una visión 1. Establecer el proyecto • Enunciado del trabajo • Planificació
arquitectónico. de alto nivel de las arquitectónico. arquitectónico n basada en
• Principios, objetivos e capacidades y valor 2. Identificar interesados, aprobado. las
impulsores del negocio. de negocio que se preocupaciones y • Declaraciones capacidade
• Modelo organizacional requerimientos de refinadas de principios, s.
desean obtener como
de arquitectura negocio. objetivos e impulsores • Gestión de
empresarial.
resultado de la 3. Confirmar y elaborar del negocio. interesados.
• Marco de referencia arquitectura objetivos, impulsores y • Principios • Evaluación
arquitectónico empresarial limitaciones de arquitectónicos. de
adaptado, incluyendo propuesta. negocio. • Evaluación de preparación
adaptación del método 4. Evaluar las capacidades. de
arquitectónico, 2. Obtener la capacidades del • Marco de referencia transformaci
contenido aprobación del negocio. arquitectónico ón de
arquitectónico, Enunciado del 5. Evaluar la preparación adaptado. negocios.
principios trabajo arquitectónico para la transformación • Visión arquitectónica, • Gestión de
arquitectónicos y del negocio. incluyendo: riesgos.
que define un
herramientas 6. Definir el alcance. • Requerimientos clave
programa de trabajo 7. Confirmar y elaborar
configuradas e refinados y de alto nivel
implementadas. para desarrollar e Principios de los interesados.
• Repositorio implementar la arquitectónicos, • Versión preliminar del
arquitectónico cargado arquitectura descrita incluyendo principios Documento de
con la documentación en la Visión de negocio. definición
arquitectónica arquitectónica. 8. Desarrollar la Visión arquitectónica,
existente. arquitectónica. incluyendo:
9. Definir las propuestas • Arquitecturas de
de valor de la negocio, datos,
arquitectura destino e aplicaciones y
indicadores claves de tecnología de línea
desempeño. base y destino. Plan de
comunicaciones.
Fuente: TOGAF, versión 9.1.

215
ANEXO 2: Iteración de desarrollo arquitectónico TOGAF 9.1.
Tabla 56: Iteración de desarrollo arquitectónico.

Arquitectura de negocio.
• Solicitud del trabajo 1. Desarrollar la 1. Seleccionar modelos de • Enunciado del trabajo • Análisis de
arquitectónico. referencia, puntos de vista arquitectónico, actualizado.
arquitectura de negocio brechas.
• Principios, objetivos, e y herramientas. • Principios de negocio
destino describiendo validados, objetivos e • Escenarios
impulsores del negocio. cómo la empresa tiene 2. Desarrollar la descripción
impulsores del negocio.
• Evaluación de capacidades. de la arquitectura de de negocio.
que operar para alcanzar negocio de línea base.
• Versión preliminar del
• Plan de comunicaciones. Documento de definición
• Modelo organizacional de
los objetivos de negocio, 3. Desarrollar la descripción arquitectónica, incluyendo:
arquitectura empresarial. responder a las de la arquitectura de arquitecturas de negocio de
• Marco de referencia motivaciones negocio de destino. línea base y destino
arquitectónico adaptado. estratégicas definidas en 4. Realizar un análisis de (detalladas); vistas
la visión arquitectónica y brechas. correspondientes a puntos de
• Enunciado del trabajo
5. Definir los componentes vista seleccionados que
arquitectónico aprobado. responder a la Solicitud responden a las
• Principios arquitectónicos. de trabajo arquitectónico candidatos de la Hoja de preocupaciones clave de los
• Continuum empresarial. y las preocupaciones de ruta del trabajo interesados.
• Repositorio arquitectónico arquitectónico. • Documento de Especificación
los interesados. 6. Resolver los impactos del
• Visión arquitectónica, de requerimientos
incluyendo: requerimientos contexto arquitectónico. arquitectónicos, incluyendo
clave refinados y de alto
2. Identificar componentes 7. Conducir una revisión actualizaciones de contenido:
nivel de los interesados. candidatos para la Hoja formal con los interesados. resultados del análisis de
de ruta del trabajo 8. Finalizar la arquitectura de brechas, requerimientos
• Versión preliminar del técnicos, requerimientos de
Documento de definición arquitectónico negocio. negocio actualizados.
arquitectónica. basándose en las 9. Crear el Documento de • Componentes de la
brechas identificadas definición arquitectónica. arquitectura de negocio del la
entre las arquitecturas Hoja de ruta del trabajo
arquitectónico.
de negocio de línea base
y destino.
216
Arquitectura de datos.
• Solicitud del trabajo 1. Desarrollar la 1. Seleccionar modelos de • Enunciado del trabajo Análisis de
arquitectónico. arquitectura de datos referencia, puntos de arquitectónico, actualizado si
fuera necesario.
brechas.
• Evaluación de destino que sea vista y herramientas. • Principios de datos
capacidades. funcional a la 2. Desarrollar la validados.
• Plan de comunicaciones. arquitectura de negocio y descripción de la • Versión preliminar del
• Modelo organizacional a la visión arquitectónica, arquitectura de datos Documento de definición
de arquitectura y que responda a la vez de línea base. arquitectónica, con
empresarial. a la Solicitud del trabajo actualizaciones de contenido:
3. Desarrollar la arquitecturas de datos de
• Marco de referencia arquitectónico y a las
descripción de la línea base y destino; vistas
arquitectónico adaptado. preocupaciones de los de la arquitectura de datos
arquitectura de datos
• Principios de datos. interesados. correspondiente a los puntos
destino.
• Enunciado del trabajo de vista seleccionados que
2. Identificar los 4. Realizar un análisis de responden a las
arquitectónico.
componentes candidatos brechas. preocupaciones clave de los
• Repositorio que podrían conformar la 5. Definir los interesados.
componentes • Versión preliminar del
arquitectónico. Hoja de ruta del trabajo documento de Especificación
• Versión preliminar del arquitectónico candidatos que de requerimientos
Documento de definición basándose en las conforman la Hoja de arquitectónicos, incluyendo
arquitectónica. brechas identificadas ruta del trabajo actualizaciones de contenido:
entre las arquitectura de arquitectónico. resultados del análisis de
• Documento preliminar de brechas, requerimientos de
Especificación de datos de línea base y 6. Resolver los impactos interoperabilidad de datos,
requerimientos destino. en el contexto requerimientos técnicos
arquitectónicos. arquitectónico. relevantes, limitaciones en la
7. Conducir una revisión arquitectura tecnológica,
requerimientos de negocio
formal con los actualizados, requerimientos
interesados. de aplicaciones actualizados.
8. Finalizar la arquitectura • Componentes de la
de datos. arquitectura de datos que
9. Crear el Documento de son parte de la Hoja de ruta
del trabajo arquitectónico.
definición
arquitectónica.
217
Arquitectura de aplicaciones.
• Solicitud del trabajo 1. Desarrollar la 1. Seleccionar modelos de • Enunciado del trabajo • Análisis de
arquitectónico, actualizado si brechas.
arquitectónico. arquitectura de referencia, puntos de
fuera necesario. • Patrones
• Evaluación de aplicaciones destino vista y herramientas. arquitectónicos.
• Principios de aplicaciones
capacidades. que sea funcional a la 2. Desarrollar la validados. • Requerimientos
descripción de la • Versión preliminar del de
• Plan de arquitectura de interoperabilidad.
arquitectura de Documento de definición
comunicaciones. negocio y a la visión aplicaciones de línea arquitectónica, con
• Modelo organizacional arquitectónica, y que base. actualizaciones de contenido:
de arquitectura responda a la vez a la 3. Desarrollar la • Arquitecturas de aplicaciones
de línea base y destino;
empresarial. Solicitud de trabajo descripción de la vistas de la arquitectura de
• Marco de referencia arquitectónico y a las arquitectura de aplicaciones correspondiente
arquitectónico preocupaciones de los aplicaciones destino. a los puntos de vista
interesados. 4. Realizar el análisis de seleccionados que
adaptado. responden a las
• Principios de brechas.
preocupaciones clave de los
2. Identificar 5. Definir los componentes
aplicaciones. interesados.
candidatos que
• Enunciado del trabajo componentes • Versión preliminar del
conforman la Hoja de documento de Especificación
arquitectónico. candidatos de la Hoja ruta del trabajo de requerimientos
• Visión arquitectónica. de ruta del trabajo arquitectónico. arquitectónicos, incluyendo
• Repositorio arquitectónico 6. Resolver los impactos actualizaciones de contenido:
basándose en las resultados del análisis de
arquitectónico. del contexto brechas, requerimientos de
• Versión preliminar del brechas identificadas arquitectónico. interoperabilidad de
Documento de entre las arquitectura 7. Conducir una revisión aplicaciones, requerimientos
definición de aplicaciones de formal con los técnicos relevantes,
interesados. limitaciones en la
arquitectónica. línea base y destino. arquitectura tecnológica,
8. Finalizar la arquitectura
• Documento preliminar de aplicaciones.
requerimientos de negocio
de Especificación de actualizados, requerimientos
9. Crear el Documento de de datos actualizados.
requerimientos definición de • Componentes de la
arquitectónicos. arquitectónica. arquitectura de aplicaciones
de la Hoja de ruta del trabajo
arquitectónico.
218
Arquitectura tecnológica.
• Solicitud del trabajo 1. Desarrollar la • Seleccionar modelos de • Enunciado del trabajo Análisis de
referencia, puntos de arquitectónico, actualizado si
arquitectónico. arquitectura fuera necesario.
brechas.
• Evaluación de tecnológica destino de vista y herramientas.
• Principios de tecnología
capacidades. tal manera que • Desarrollar la validados.
descripción de la • Versión preliminar del
• Plan de permita que los
arquitectura tecnológica Documento de definición
comunicaciones. componentes lógicos y de línea base. arquitectónica, conteniendo
• Modelo organizacional físicos de datos y • Desarrollar la actualizaciones de contenido:
de arquitectura aplicaciones, así como descripción de la
arquitectura tecnológica de
línea base y destino; vistas
empresarial. aquellos de la visión arquitectura tecnológica de la arquitectura de
• Marco de referencia arquitectónica, destino. aplicaciones correspondiente
arquitectónico correspondan a la • Realizar el análisis de a los puntos de vista
Solicitud del trabajo brechas. seleccionados que
adaptado. responden a las
• Principios de arquitectónico y • Definir los componentes
preocupaciones clave de los
tecnología. respondan a las candidatos que interesados.
preocupaciones de los conforman la Hoja de • Versión preliminar del
• Enunciado del trabajo ruta del trabajo documento de Especificación
arquitectónico. interesados.
arquitectónico. de requerimientos
• Visión arquitectónica. • Resolver los impactos arquitectónicos, incluyendo
• Repositorio 2. Identificar los del contexto actualizaciones de contenido:
componentes resultados del análisis de
arquitectónico. arquitectónico. brechas, requerimientos
• Versión preliminar del candidatos de la Hoja • Conducir una revisión resultantes de las Fases B y
Documento de de ruta del trabajo formal con los C, requerimientos de
arquitectónico interesados. tecnología actualizados.
definición • Componentes de la
arquitectónica. basándose en las • Finalizar la arquitectura
arquitectura tecnológica de la
brechas identificadas tecnológica.
• Documento preliminar Hoja de ruta del trabajo
entre la arquitectura • Crear el Documento de arquitectónico.
de Especificación de definición de
requerimientos tecnológica de línea
arquitectónica.
arquitectónicos. base y destino.

219
ANEXO 3: Descripción de la iteración de transición arquitectónica TOGAF 9.1.
Las iteraciones de transición arquitectónica apoyan a la creación de la Hoja de ruta para el

trabajo arquitectónico para los cambios formales para una arquitectura definida.
Una visión general de las fases que conforman la iteración de transición arquitectónica, se
describe en el ANEXO 4: Iteración de transición arquitectónica TOGAF 9.1.
1. Fase E: Oportunidades y soluciones.
La fase E: Oportunidades y soluciones es la primera fase que directamente se refiere a la

implementación. Describe el proceso de identificación de los medios de entrega (proyectos,
programas o carteras) que proporciona la arquitectura destino identificada en las fases
anteriores.
Tabla 57: Descripción de fase E: Oportunidades y soluciones de TOGAF.
Objetivos Pasos
• Generar la versión inicial y completa de • Determinar o confirmar atributos claves

la Hoja de ruta del trabajo arquitectónico, para el cambio empresarial.
basándose en el análisis de brechas y • Determinar limitaciones del negocio para
en los componentes candidatos la implementación.
resultantes de las fases B, C y D. • Examinar y consolidar los resultados de
los análisis de brechas realizados.
• Determinar si un enfoque incremental es • Examinar los requerimientos
requerido, y si fuera así, identificar las consolidados entre funciones de negocio
arquitecturas de transición que relacionadas.
proporcionarán valor continuo de • Consolidar y reconciliar los
negocio. requerimientos de interoperabilidad.
• Refinar y validar dependencias.
• Confirmar el grado de preparación y
riesgos para la transformación del
negocio.
• Formular la estrategia de
implementación y migración.
• Identificar y agrupar los paquetes de
trabajo principales.
• Identificar las arquitecturas de transición.
• Crear la Hoja de ruta del trabajo
arquitectónico y el Plan de
implementación y migración.
220
• Información del producto. • Enunciado del trabajo arquitectónico

• Solicitud del trabajo arquitectónico. actualizado.
• Evaluación de capacidades. • Visión arquitectónica actualizada.
• Plan de comunicaciones. • Versión preliminar del Documento de
• Metodologías de planificación. definición arquitectónica, incluyendo:
• Modelos de gobierno y marcos de ◦ Arquitecturas de transición.
referencia. • Versión preliminar del documento de
• Marco de referencia arquitectónico Especificación de requerimientos
adaptado. arquitectónicos, actualizado si fuera
• Enunciado del trabajo arquitectónico. necesario.
• Visión arquitectónica. • Evaluación de capacidades, incluyendo:
• Repositorio arquitectónico. ◦ Capacidades de negocio y TI.
• Versión preliminar del Documento de • Hoja de ruta del trabajo arquitectónico,
definición arquitectónica. incluyendo:
• Versión preliminar del documento de ◦ Carteras de paquetes de trabajo.
Especificación de requerimientos ◦ Identificación de arquitecturas de
arquitectónicos. transición, si existen y
• Solicitudes de cambio a los programas y recomendaciones de implementación.
proyectos existentes. • Plan de implementación y migración,
• Componentes candidatos de la Hoja de incluyendo:
ruta del trabajo arquitectónico ◦ Estrategia de implementación y
resultantes de las Fases B, C y D. migración.


Tabla 58: Artefactos de la fase E: Oportunidades y soluciones de TOGAF.
Artefactos
• Diagramas
◦ Diagrama de contexto del proyecto.
◦ Diagrama de beneficios.

2. Fase F: Planificación de la migración.
La fase F: Planificación de la migración aborda la preparación de la migración; es decir, se

bosqueja cómo moverse desde la línea base de la arquitectura hacia la arquitectura destino
finalizando con un Plan de implementación y migración en detalle.
221
Tabla 59: Descripción de fase F: Planificación de la migración de TOGAF.
Objetivos Pasos
• Finalizar la Hoja de ruta del trabajo • Confirmar las interacciones del Plan de
arquitectónico y el Plan de implementación implementación y migración con marcos
y migración que lo apoya. de referencia de gestión de la empresa.
• Asignar el valor de negocio a cada
• Asegurar que el Plan de implementación y paquete de trabajo Estimar las
migración se alinee al enfoque de la necesidades de recursos, los tiempos del
empresa para la gestión e implementación proyecto y la disponibilidad / medio de
de cambios en la cartera general de entrega.
cambios empresariales. • Priorizar los proyectos de migración a
través de la realización de una evaluación
• Asegurar que el valor de negocio y los de costo-beneficio y validación de riesgos.
costos de los paquetes de trabajo y • Confirmar la Hoja de ruta del trabajo
arquitecturas de transición sean bien arquitectónico y actualizar el Documento
entendidos por los interesados. de definición arquitectónica.
• Completar el Plan de implementación y
migración.
• Completar el ciclo de desarrollo y
documentar las lecciones aprendidas.
• Solicitud del trabajo arquitectónico. • Plan de implementación y migración

• Plan de comunicaciones. (detallado), incluyendo:
• Modelo organizacional de arquitectura ◦ Estrategia de implementación y
empresarial. migración.
• Modelos de gobernanza y marcos de • Distribución de proyectos y carteras de
referencia. implementación.
• Marco de referencia arquitectónico • Cartas constitutivas de proyectos
adaptado. (opcionales).
• Enunciado del trabajo arquitectónico. • Documento de definición arquitectónica
• Visión arquitectónica. finalizado, incluyendo:
• Repositorio arquitectónico. ◦ Arquitecturas de transición finalizadas, si
• Versión preliminar del Documento de existen.
definición arquitectónica, incluyendo: • Especificación de requerimientos
◦ Arquitecturas de transición, si existen. arquitectónicos, finalizada.
• Versión preliminar del documento de • Hoja de ruta del trabajo arquitectónico,
Especificación de requerimientos finalizado.
arquitectónicos. • Bloques de construcción arquitectónicos
• Solicitudes de cambio en programas y reutilizables.
proyectos existentes. • Solicitudes de trabajo arquitectónico para
• Hoja de ruta del trabajo arquitectónico. una nueva iteración del ADM (si existen).
• Evaluación de capacidades, incluyendo: • Modelo de gobernanza de la
◦ Capacidades de negocio implementación.
◦ Capacidades de TI • Solicitudes de cambio para la capacidad
• Plan de implementación y migración arquitectónica que surgen de las lecciones
(descripción), incluyendo: aprendidas.
◦ Estrategia de alto nivel de
implementación y migración

222
Tabla 60: Artefactos de la fase E: Planificación de la migración de TOGAF.
Artefactos
• Diagramas
◦ Diagrama de contexto del proyecto.
◦ Diagrama de beneficios.

223
ANEXO 4: Iteración de transición arquitectónica TOGAF 9.1.
Tabla 61: Iteración de transición arquitectónica.

Oportunidades y soluciones.
• Información del producto. 1. Generar la versión 1. Determinar o confirmar • Enunciado del trabajo • Planificación
• Solicitud del trabajo atributos claves para el cambio arquitectónico actualizado.
inicial y completa de la empresarial.
basada en
arquitectónico. • Visión arquitectónica
Hoja de ruta del 2. Determinar limitaciones del actualizada. capacidades.
• Evaluación de capacidades. negocio para la • Requerimient
trabajo arquitectónico, • Versión preliminar del
• Plan de comunicaciones. implementación. Documento de definición os de
• Metodologías de basándose en el 3. Examinar y consolidar los arquitectónica, incluyendo:
planificación. interoperabili
análisis de brechas y resultados de los análisis de • Arquitecturas de transición, si
dad
• Modelos de gobierno y en los componentes brechas de las fases B a D. existen.
marcos de referencia. 4. Examinar los requerimientos • Versión preliminar del
• Marco de referencia candidatos resultantes consolidados entre funciones documento de Especificación
de las fases B, C y D. de negocio relacionadas. de requerimientos
arquitectónico adaptado. 5. Consolidar y reconciliar los arquitectónicos, actualizado si
• Enunciado del trabajo requerimientos de fuera necesario.
arquitectónico. 2. Determinar si un interoperabilidad. • Evaluación de capacidades,
• Visión arquitectónica. 6. Refinar y validar dependencias. incluyendo:
enfoque incremental
• Repositorio arquitectónico. 7. Confirmar el grado de • Capacidades de negocio y TI.
• Versión preliminar del es requerido, y si fuera preparación y riesgos para la • Hoja de ruta del trabajo
Documento de definición así, identificar las transformación del negocio. arquitectónico, incluyendo:
8. Formular la estrategia de • Carteras de paquetes de
arquitectónica y del arquitecturas de implementación y migración.
documento de trabajo.
transición que 9. Identificar y agrupar los • Identificación de arquitecturas
Especificación de paquetes de trabajo.
requerimientos
proporcionarán valor de transición, si existen.
10. Identificar las arquitecturas de • Recomendaciones de
arquitectónicos. continuo de negocio. transición. implementación.
• Solicitudes de cambio a los 11. Crear la Hoja de ruta del • Plan de implementación y
programas y proyectos trabajo arquitectónico y el Plan migración, incluyendo:
existentes. de implementación y • Estrategia de implementación y
migración. migración.
• Componentes candidatos
de la Hoja de ruta del
trabajo arquitectónico de
las Fases B, C y D.
224
Planificación de la migración.
• Solicitud del trabajo 1. Finalizar la Hoja de 1. Confirmar las • Plan de implementación y Técnicas de
arquitectónico. ruta del trabajo interacciones del Plan de migración (detallado), planificación de
• Plan de comunicaciones. implementación y incluyendo:
• Modelo organizacional de arquitectónico y el • Estrategia de la migración.
Plan de migración con marcos de
arquitectura empresarial. implementación y
referencia de gestión de
• Modelos de gobernanza y implementación y migración.
marcos de referencia. la empresa. • Distribución de proyectos y
migración que lo 2. Asignar el valor de
• Marco de referencia carteras de
apoya. negocio a cada paquete
arquitectónico adaptado. implementación.
• Enunciado del trabajo de trabajo. • Cartas constitutivas de
arquitectónico. 2. Asegurar que el Plan 3. Estimar las necesidades proyectos (opcionales).
• Visión arquitectónica. de implementación y de recursos, los tiempos • Documento de definición
• Repositorio arquitectónico. migración se alinee al del proyecto y la arquitectónica finalizado,
• Versión preliminar de los disponibilidad / medio de incluyendo:
enfoque de la • Arquitecturas de transición
documentos de definición entrega.
arquitectónica, incluyendo: empresa para la finalizadas, si existen.
gestión e 4. Priorizar los proyectos
arquitecturas de transición, • Especificación de
de migración a través de
si existen; y de implementación de requerimientos
Especificación de la realización de una arquitectónicos, finalizada.
cambios en la cartera evaluación de costo-
requerimientos • Hoja de ruta del trabajo
arquitectónicos. general de cambios beneficio y validación de arquitectónico, finalizado.
• Solicitudes de cambio en empresariales. riesgos. • Bloques de construcción
programas y proyectos. 5. Confirmar la Hoja de ruta arquitectónicos
• Hoja de ruta del trabajo 3. Asegurar que el valor del trabajo arquitectónico reutilizables.
arquitectónico. • Solicitudes de trabajo
de negocio y los y actualizar el
• Evaluación de capacidades. arquitectónico para una
costos de los Documento de definición
• Plan de implementación y nueva iteración del ADM (si
paquetes de trabajo y arquitectónica. existen).
migración, incluyendo:
estrategia de alto nivel de arquitecturas de 6. Completar el Plan de • Modelo de gobernanza de
implementación y implementación y la implementación.
transición sean bien
migración. migración. • Solicitudes de cambio para
entendidos por los 7. Completar el ciclo de la capacidad arquitectónica
interesados. desarrollo y documentar que surgen de las lecciones
las lecciones aprendidas. aprendidas.

225
ANEXO 5: Descripción de la iteración de gobernanza arquitectónica TOGAF 9.1.
Las iteraciones de gobernanza arquitectónica apoyan al control de la actividad de cambio a

medida que se avanza hacia una arquitectura destino definida.
Una visión general de las fases que conforman la iteración de gobernanza arquitectónica, se
describe en el ANEXO 6: Iteración de gobernanza arquitectónica TOGAF 9.1.
1. Fase G: Gobernanza de la implementación.
La fase G: Gobernanza de la implementación, define cómo la arquitectura delimita los

proyectos de implementación, supervisa al mismo tiempo que se implementa, y produce un
contrato arquitectónico firmado. En esta fase se reúne toda la información relevante para la
gestión exitosa de los proyectos de implementación. Cabe destacar, que paralelamente a
esta fase existe la ejecución de un proceso de desarrollo específico de la organización, en
donde sucede el desarrollo real.
En la siguiente tabla, se describen los principales elementos que conforman la fase de

gobernanza de la implementación:
Tabla 62: Descripción de fase G: Gobernanza de la implementación de TOGAF.
Objetivos Pasos
• Asegurar el cumplimiento de la • Confirmar el alcance y prioridades para

arquitectura destino a través de la implementación con el equipo de
proyectos de implementación. desarrollo de la empresa.
• Identificar los recursos y habilidades
• Realizar funciones de gobernanza requeridas para la implementación.
arquitectónica apropiadas para la • Guiar el desarrollo de la
solución y para toda solicitud de implementación de las soluciones.
cambio de la arquitectura impulsada • Realizar revisiones de cumplimiento de
por la implementación. la arquitectura destino.
• Poner en práctica la operación de
negocio y TI.
• Realizar la revisión posterior a la
implementación y cerrar la
implementación.
226
• Solicitud del trabajo arquitectónico. • Contrato arquitectónico firmado.

• Evaluación de capacidades. • Evaluaciones de cumplimiento.
• Modelo organizacional de arquitectura • Solicitudes de cambio.
empresarial. • Análisis de impacto-recomendaciones
• Marco de referencia arquitectónico de implementación.
adaptado. • Soluciones implementadas,
• Enunciado del trabajo arquitectónico. incluyendo:
• Visión arquitectónica. ◦ Sistema implementado en
• Repositorio arquitectónico. conformidad con la arquitectura.
• Documento de definición ◦ Repositorio arquitectónico cargado.
arquitectónica. ◦ Recomendaciones de cumplimiento
• Especificación de requerimientos arquitectónico y excepciones.
arquitectónicos. ◦ Recomendaciones de
• Hoja de ruta del trabajo arquitectónico. requerimientos para la prestación de
• Modelo de gobernanza de la servicios.
Implementación. ◦ Recomendaciones de métricas de
• Contrato arquitectónico. rendimiento.
• Solicitud de trabajo arquitectónico ◦ Acuerdos de nivel de servicio (SLAs,
identificado en las Fases E y F. por sus siglas en inglés).
• Plan de implementación y migración. ◦ Visión arquitectónica, actualizada
posteriormente a la implementación.
◦ Documento de definición
arquitectónica, actualizado
posteriormente a la implementación.
◦ Modelo de operación de negocio y TI
para la solución implementada.

Adaptado deThe Open Group.
2. Fase H: Gestión del cambio.
La fase H: Gestión del cambio asegura que los cambios en la arquitectura se gestionen de
una manera controlada. El objetivo del proceso de gestión del cambio arquitectónico es el
aseguramiento de que la arquitectura alcance el valor de negocio objetivo original. Lo cual
incluye la gestión de los cambios arquitectónicos de forma coherente y estructurada.
Este proceso proporcionará activos de monitorización como solicitudes de cambios, nuevos

desarrollos tecnológicos y cambios en el entorno empresarial. Además, el proceso de
gestión del cambio arquitectónico tiene como objetivo establecer y soportar a la arquitectura
empresarial como una arquitectura dinámica. En la siguiente tabla, se describen los
principales elementos que conforman la fase de gestión del cambio:
227
Tabla 63: Descripción de fase H: Gestión del cambio.
Objetivos Pasos
• Asegurar que el ciclo de vida de la • Establecer el proceso de realización

arquitectura se mantenga. del valor.
• Implementar herramientas de
• Asegurar la ejecución del marco de supervisión.
referencia de gobernanza • Gestionar los riesgos.
arquitectónica. • Proporcionar un análisis de la gestión
de cambios arquitectónicos.
• Asegurar que la capacidad • Desarrollar los requerimientos de
arquitectónica empresarial cumple con cambio para cumplir con los objetivos
los requerimientos actuales. de rendimiento.
• Gestionar el proceso de gobernanza.
• Activar el proceso de implementación
de cambios.
• Solicitud del trabajo arquitectónico. • Actualizaciones de la arquitectura.

• Modelo organizacional de arquitectura • Cambios al marco de referencia
empresarial. arquitectónico y a los principios.
• Marco de referencia arquitectónico • Nueva Solicitud de trabajo
adaptado. arquitectónico, para iniciar otro ciclo
• Enunciado del trabajo arquitectónico del ADM.
• Visión arquitectónica. • Enunciado del trabajo arquitectónico,
• Repositorio arquitectónico. actualizado si fuera necesario.
• Documento de definición • Contrato arquitectónico, actualizado si
arquitectónica. fuera necesario.
• Especificación de requerimientos • Evaluaciones de cumplimiento,
arquitectónicos. actualizadas si fuera necesario.
• Hoja de ruta del trabajo arquitectónico.
• Solicitudes de cambio debido a
cambios tecnológicos.
cambios de negocio.
lecciones aprendidas.
• Modelo de gobernanza de la
implementación.
• Contrato arquitectónico (firmado).
• Evaluaciones de cumplimiento.
• Plan de implementación y migración.

228
ANEXO 6: Iteración de gobernanza arquitectónica TOGAF 9.1.
Tabla 64: Iteración de gobernanza arquitectónica.

Gobernanza de la implementación.
• Solicitud del trabajo 1. Asegurar el 1. Confirmar el alcance y • Contrato arquitectónico --

arquitectónico. prioridades para la firmado.
cumplimiento de la • Evaluaciones de
• Evaluación de capacidades. implementación con el
• Modelo organizacional de arquitectura destino a equipo de desarrollo de la cumplimiento.
arquitectura empresarial. través de proyectos de empresa. • Solicitudes de cambio.
• Marco de referencia implementación. 2. Identificar los recursos y • Análisis de impacto-
arquitectónico adaptado. habilidades requeridas para recomendaciones de
la implementación. implementación.
• Enunciado del trabajo 2. Realizar funciones de 3. Guiar el desarrollo de la • Sistema implementado en
arquitectónico.
• Visión arquitectónica. gobernanza implementación de las conformidad con la
arquitectura.
• Repositorio arquitectónico. arquitectónica soluciones.
• Repositorio arquitectónico
• Documento de definición apropiadas para la 4. Realizar revisiones de cargado.
arquitectónica. solución y para toda cumplimiento de la • Recomendaciones de
• Especificación de arquitectura destino. cumplimiento arquitectónico y
solicitud de cambio de 5. Poner en práctica la
requerimientos excepciones.
arquitectónicos. la arquitectura operación de negocio y TI. • Recomendaciones de
• Hoja de ruta del trabajo impulsada por la 6. Realizar la revisión requerimientos para la
arquitectónico. implementación. posterior a la prestación de servicios.
• Modelo de gobernanza de implementación y cerrar la • Recomendaciones de
la Implementación. implementación. métricas de rendimiento.
• Contrato arquitectónico. • Acuerdos de nivel de
• Solicitud de trabajo servicio.
arquitectónico identificado • Visión arquitectónica y
en las Fases E y F. Documento de definición
arquitectónica, actualizados
• Plan de implementación y
posteriormente a la
migración.
implementación.
• Modelo de operación de
negocio y TI para la solución
implementada.
229
Gestión del cambio.
• Solicitud del trabajo 1. Asegurar que el ciclo 1. Establecer el proceso 1. Actualizaciones de la Gestión de
arquitectónico. de vida de la de realización del arquitectura. riesgos.
• Modelo organizacional de
arquitectura empresarial. arquitectura se valor. 2. Cambios al marco de
• Marco de referencia mantenga. 2. Implementar referencia
arquitectónico adaptado. herramientas de arquitectónico y a los
• Enunciado del trabajo 2. Asegurar la ejecución supervisión. principios.
arquitectónico del marco de 3. Gestionar los riesgos. 3. Nueva Solicitud de
• Repositorio arquitectónico. referencia de 4. Proporcionar un trabajo arquitectónico,
• Documento de definición gobernanza análisis de la gestión para iniciar otro ciclo
arquitectónica. arquitectónica. de cambios del ADM.
• Especificación de arquitectónicos. 4. Enunciado del trabajo
requerimientos
3. Asegurar que la 5. Desarrollar los arquitectónico,
arquitectónicos.
• Hoja de ruta del trabajo capacidad requerimientos de actualizado si fuera
arquitectónico. arquitectónica cambio para cumplir necesario.
• Solicitudes de cambio empresarial cumple con los objetivos de 5. Contrato
debido a cambios con los requerimientos rendimiento. arquitectónico,
tecnológicos.
• Solicitudes de cambio
actuales. 6. Gestionar el proceso actualizado si fuera
debido a cambios de de gobernanza. necesario.
negocio. 7. Activar el proceso de 6. Evaluaciones de
• Solicitudes de cambio implementación de cumplimiento,
debido a lecciones cambios. actualizadas si fuera
aprendidas.
• Modelo de gobernanza de necesario.
la implementación.
• Contrato arquitectónico
(firmado).
• Evaluaciones de
conformidad.
• Plan de implementación y
migración.

230
ANEXO 7: Descripción de la fase de gestión de requerimientos.
La capacidad para hacer frente a los cambios de requerimientos es crucial para el proceso
del ADM, dado que la arquitectura, por su propia naturaleza, aborda la incertidumbre y el
cambio, tendiendo un puente entre las aspiraciones de los interesados y lo que se puede
entregar como una solución práctica.
Tabla 65: Descripción de gestión de requerimientos de TOGAF.
Objetivos Pasos
• Asegurar que el proceso de gestión de • Identificar y documentar requerimientos.

requerimientos sea mantenido y operado • Establecer los requerimientos de la línea
en todas las fases relevantes del ADM. base.
• Supervisar los requerimientos de la línea
• Gestionar los requerimientos base.
arquitectónicos identificados durante toda • Identificar cambios en los requerimientos;
la ejecución del ciclo ADM o en una de sus quitar, añadir, modificar y reexaminar
fases. prioridades.
• Identificar cambios en los requerimientos y
• Asegurar que los requerimientos registrar las prioridades; identificar y
arquitectónicos relevantes estén resolver conflictos; generar declaraciones
disponibles para el uso, en cada fase de impacto de requerimientos.
cuando éstas se ejecutan. • Evaluar el impacto de los cambios en los
requerimientos en las fases actuales y
previas del ADM.
• Implementar los requerimientos que
provienen de la fase H.
• Actualizar el repositorio de requerimientos.
• Implementar los cambios requeridos en la
fase actual.
• Evaluar y revisar los análisis de brechas
de las fases anteriores.
Las entradas al proceso de gestión de • Evaluación del impacto de los

requerimientos son las salidas relacionadas requerimientos.
con requerimientos producidas en cada fase • Especificación de requerimientos
del ADM. arquitectónicos, si es necesario.
Los primeros requerimientos de alto nivel se

producen como parte de la Visión
arquitectónica. Cada dominio arquitectónico
genera entonces requerimientos detallados.

231
ANEXO 8: Gestión de requerimientos TOGAF 9.1.
Tabla 66: Gestión de requerimientos.
Entradas Objetivos Pasos Salidas Técnicas
Las entradas al 1. Asegurar que el 1. Identificar y documentar • Evaluación del • Gestión de

proceso de gestión de proceso de gestión de requerimientos. impacto de los riesgos.
2. Establecer los requerimientos de la • Requerimientos de
requerimientos son las requerimientos sea requerimientos.
línea base. interoperabilidad.
salidas relacionadas mantenido y operado • Especificación de
3. Supervisar los requerimientos de la
con requerimientos en todas las fases línea base. requerimientos
producidas en cada relevantes del ADM. 4. Identificar cambios en los arquitectónicos, si es
fase del ADM. requerimientos; quitar, añadir, necesario.
2. Gestionar los modificar y reexaminar prioridades.
requerimientos 5. Identificar cambios en los
arquitectónicos requerimientos y registrar las
identificados durante prioridades; identificar y resolver
toda la ejecución del conflictos; generar declaraciones de
ciclo ADM o en una de impacto de requerimientos.
6. Evaluar el impacto de los cambios
sus fases.
en los requerimientos en las fases
actuales y previas del ADM.
3. Asegurar que los 7. Implementar los requerimientos que
requerimientos provienen de la fase H.
arquitectónicos 8. Actualizar el repositorio de
relevantes estén requerimientos.
disponibles para el uso, 9. Implementar los cambios requeridos
en cada fase cuando en la fase actual.
éstas se ejecutan. 10. Evaluar y revisar los análisis de
brechas de las fases anteriores.

232
ANEXO 9: Guías y técnicas TOGAF 9.1.
Tabla 67: Guías para adaptar el proceso ADM.
Guías para adaptar el proceso ADM
Iteraciones en el método de Describe las distintas formas de iteraciones que pueden

desarrollo arquitectónico. ocurrir: iteraciones dentro de un ciclo ADM, iteraciones para
desarrollar el contexto arquitectónico e iteraciones para
gestionar la capacidad arquitectónica.
Aplicación del método de Describe cómo TOGAF utiliza los conceptos de niveles y
desarrollo arquitectónico a Continuum Empresarial para proporcionar un marco
través del contexto conceptual para la organización del contexto arquitectónico.
arquitectónico.
Arquitectura de seguridad y Explica las consideraciones de seguridad que deben

ADM. evaluarse durante la implementación del método de
desarrollo arquitectónico.
Usando TOGAF para definir y Describe los métodos, herramientas, materiales de referencia
gobernar SOA. y normas sugeridas por The Open Group para la adopción e
implementación de SOA.

Tabla 68: Técnicas para el desarrollo arquitectónico.
Técnicas para el desarrollo arquitectónico
Principios arquitectónicos. Explica conceptos básicos respecto a los principios

arquitectónicos utilizados en el desarrollo de una arquitectura
empresarial.
Gestión de Interesados. Sugiere normas para identificar individuos y grupos de

interés dentro de una organización. Además, dicta
estrategias para ayudar a tratar con los interesados.
Patrones arquitectónicos. Describe las directrices para el uso de patrones

arquitectónicos.
Escenarios de negocio. Describe un método para derivar los requisitos de negocio

para la arquitectura y los requisitos técnicos implicados.
También proporciona directrices sobre la definición de metas
y objetivos para el desarrollo arquitectónico.
233
Análisis de brechas. Técnica utilizada para validar una arquitectura que se está
desarrollando. La idea es poner de relieve un déficit entre la
arquitectura de línea base y la arquitectura destino.
Técnicas de planificación de la Contiene una serie de técnicas que se utilizan para apoyar la
migración. planificación de la migración en las fases E y F.
Requerimientos de Contiene las directrices para la definición y establecimiento

interoperabilidad. de requisitos de interoperabilidad. Proporciona una definición
de interoperabilidad de forma clara e inequívoca en varios
ámbitos (empresa, servicio, información y técnicas).
Evaluación de la preparación de Técnica utilizada para evaluar y cuantificar la disposición de

transformación de negocios. una organización a sufrir modificaciones. Se basa en el
trabajo del Gobierno canadiense y su programa de
transformación de negocios (BETP).
Gestión de riesgos. Técnica utilizada para mitigar los riesgos en la ejecución de

un proyecto arquitectónico. Se centra en la clasificación,
identificación, evaluación y seguimiento de los riesgos.
Planificación basada en la Se centra en la planificación, ingeniería, y entrega de

capacidad. capacidades estratégicas de negocio para la empresa.
Combina los esfuerzos necesarios de todas las líneas de
negocio para alcanzar la capacidad deseada.

234
ANEXO 10: Artefactos TOGAF 9.1.
Tabla 69: Catálogos del método de desarrollo arquitectónico.
Iteración Fase Nombre Entidad Descripción
Fase Catálogo de Principio. Contiene los principios

Capacidad
preliminar. principios. arquitectónicos que describen la

solución ideal que puede adoptar
la empresa.
Fase B: Catálogo de Unidad de Proporciona una referencia de

Desarrollo
arquitectura impulsores – organización. cómo la empresa cumple sus

de negocio. metas – Impulsor. impulsores a través de metas,
objetivos. Meta. objetivas y medidas (opcional).
Objetivo.
Medida
Catálogo de Servicio Proporciona una lista completa de

medida - empresarial. los contratos de servicio
contrato. Servicio de acordados y las medidas adjuntas
sistema de a esos contratos.
información.
Contrato.
Medida.
Catálogo de Unidad de Captura una lista definitiva de

organización organización. todos los participantes que
– actor. Actor. interactúan con tecnologías de
Ubicación. información, incluidos usuarios y
propietarios de los sistemas de TI.
Catálogo de Proceso. Proporciona un listado de eventos

proceso – Evento. para la generación de productos, y
evento – Control. controles aplicados en la ejecución
control – Producto. de los procesos.
producto.
Catálogo de Rol. Proporciona una lista de todas las

roles. zonas o niveles de autorización
dentro de la empresa.
Catálogo de Unidad de Provee una descomposición

servicios – organización. funcional de la empresa, actuando
funciones. Función de como un suplemento para el
negocio. Diagrama de descomposición
Servicio funcional.
empresarial.
Información de
servicio del
sistema.
235
Catálogo de Ubicación. Proporciona un listado de todos los

ubicaciones. lugares en los que la empresa
efectúa sus operaciones
comerciales.
Fase C: Catálogo de Datos de la Identifica una lista de todos los

arquitectura entidades de entidad. datos en uso de la empresa,
de sistemas datos – Componente incluyendo entidades y
de componentes lógico de componentes de datos.
información
– datos.
de datos. datos.
Componente
físico de datos.
Fase C: Catálogo de Componente Documenta la relación entre

arquitectura interfaces. lógico de interfaces y aplicaciones,
de sistemas datos. permitiendo que las dependencias
de Componente se comuniquen tan pronto como
información
–
físico de datos. sea posible.
aplicaciones. Relaciones.
Catálogo de Servicio de Proporciona un listado de todas las

portafolio de sistema de aplicaciones de la empresa.
aplicaciones. información.
Componente
lógico de
aplicación.
Componente
físico de
aplicación.
Fase D: Catálogo de Servicio de Contiene los estándares utilizados

arquitectura estándares de plataforma. para implementar la arquitectura
tecnológica. tecnología. Componente tecnológica de la empresa.
lógico
tecnológico.
Componente
físico
tecnológico.
Catálogo de Servicio de Lista las tecnologías usadas en la

portafolio de plataforma. empresa, incluyendo hardware y
tecnología. Componente software.
lógico
tecnológico.
Componente
físico
tecnológico.
236
Gestión de Catálogo de Requisito. Capta las actividades que la

requerimientos.
requisitos. Suposición. empresa tiene que desarrollar para
Restricción. cumplir con sus objetivos.
Brecha.

Tabla 70: Diagramas del método de desarrollo arquitectónico.
Iteración Fase Nombre Descripción
Visión Diagrama de cadena Proporciona una orientación de alto

Capacidad
arquitectónica. de valor. nivel de la empresa y cómo interactúa

con el mundo exterior.
Diagrama de Proporciona una orientación de alto

concepto de solución. nivel de la solución que se prevé
desarrollar para cumplir con los
objetivos del trabajo arquitectónico.
Fase B: Diagrama de casos Muestra las relaciones entre los

Desarrollo
arquitectura de de uso de negocio. consumidores y proveedores de

negocio. servicios de negocio. Ayuda a validar la
interacción entre actores y sus roles en
procesos y funciones.
Diagrama del ciclo de Permite ayudar a entender los ciclos de

vida del producto. vida de las entidades clave dentro de la
empresa.
Diagrama de Muestra en una página las

descomposición de capacidades que son relevantes para
funciones. el desarrollo arquitectónico.
Diagrama de Describe los vínculos entre actores,

descomposición de la roles y ubicaciones dentro de un árbol
organización. organizacional.
Diagrama de eventos. Representa la relación entre los

eventos y procesos.
Diagrama de flujos de Muestra el flujo secuencial de control

procesos. entre actividades.
237
Diagrama de Describe los vínculos entre los

presencia del objetivos de negocio, unidades
negocio. organizativas, funciones de negocio y
servicios. Además, mapea las
funciones de negocio a los
componentes técnicos que entregan
las capacidades requeridas.
Diagrama de Define las formas en las que un

metas/objetivos/servic servicio puede contribuir a la
ios. consecución de una visión o estrategia
de negocio.
Diagrama de Muestra la información necesaria para

servicios de negocio soportar uno o más servicios de
e información. negocio. Describe los datos que se
producen/consumen y la fuente de
información.
Fase C: Diagrama conceptual Describe las relaciones entre las

arquitectura de de datos. entidades de datos clave de la
sistemas de empresa.
información –
datos.
Diagrama de difusión Muestra la relación entre las entidades
de datos. de datos, servicios de negocio y
componentes de aplicaciones.
Diagrama de Contiene una disposición general del

migración de datos. contexto de migración de los datos.
Diagrama de Describe qué actores (persona,

seguridad de datos. organización, sistema) pueden acceder
a los datos de la empresa.
Diagrama del ciclo de Contiene los cambios de estado de los

vida de datos. datos y los eventos que pueden
desencadenarlos.
Diagrama lógico de Muestra las vistas lógicas de las

datos. relaciones entre las entidades claves
de la empresa.
Fase C: Diagrama de gestión Muestra cómo una o más aplicaciones

arquitectura de empresarial. interactúan con los componentes de
sistemas de aplicaciones y tecnológicos que
información – apoyan la gestión operativa de una
aplicaciones. solución.
238
Diagrama de Es un esquema que muestra la

aplicación y ubicación distribución geográfica de las
de usuario. aplicaciones utilizadas.
Diagrama de casos Muestra las relaciones entre

de uso de consumidores y proveedores de
aplicaciones. servicios de aplicaciones.
Diagrama de Muestra los componentes de

comunicación de aplicaciones e interfaces entre
aplicaciones. componentes. Representa todos los
modelos y asignaciones relacionadas
con la comunicación entre
aplicaciones.
Diagrama de Muestra cómo las aplicaciones físicas

distribución de se distribuyen a través de la tecnología
software. física y la ubicación de esa tecnología.
Diagrama de Separa las aplicaciones en paquetes,

ingeniería de módulos, servicios y operaciones
software. desde una perspectiva de desarrollo.
Diagrama de Identifica las aplicaciones temporales,

migración de áreas de almacenamiento y la
aplicaciones. infraestructura necesaria para apoyar
el proceso de migración.
Diagrama de Representa claramente la secuencia

realización de de eventos cuando múltiples
procesos/aplicacione aplicaciones están involucradas en la
s. ejecución de un proceso de negocio.
Fase D: Diagrama de red Muestra una vista lógica

arquitectura informática – “implementada” de los componentes
tecnológica. hardware. lógicos de aplicaciones en un entorno
de red distribuida.
Diagrama de Representa la plataforma tecnológica

descomposición de que soporta la arquitectura de sistemas
plataforma. de información.
Diagrama de Identifica las ubicaciones desde las

entornos y que los usuarios suelen interactuar con
ubicaciones. las aplicaciones. Además, identifica
cuáles ubicaciones albergan ciertas
aplicaciones/tecnologías.
239
Diagrama de Se centra en las unidades de

procesamiento. despliegue de codificación
/configuración y cómo éstas se
despliegan en la plataforma
tecnológica.
Fase E: Diagrama de contexto Vincula un paquete de trabajo a las

Transición
Oportunidades del proyecto. organizaciones, funciones, servicios,

y soluciones. procesos, aplicaciones, datos y
tecnología que se pueden añadir,
eliminar o ser afectadas por el
proyecto.
Diagrama de Muestra las oportunidades

beneficios. identificadas en la definición
arquitectónica, clasificándolas de
acuerdo a su tamaño relativo,
beneficios y complejidad.

Tabla 71: Matrices del método de desarrollo arquitectónico.
Visión Mapa de interesados. Identifica los grupos de interés para el

Capacidad
arquitectónica. compromiso arquitectónico, su

influencia sobre el compromiso, sus
preguntas clave, temas o
preocupaciones a ser abordadas por el
marco de referencia arquitectónico.
Fase B: Matriz de actor – rol. Muestra qué actores desempeñan

Desarrollo
arquitectura de ciertos roles, apoyando en la definición

negocio. de requerimientos de seguridad y
habilidades.
Matriz de interacción Describe las interacciones y relaciones

del negocio. entre las áreas y funciones de negocio
de la empresa.
Fase C: Matriz de entidad de Ilustra las relaciones entre las

arquitectura de datos – funciones de entidades de datos y las funciones de
sistemas de negocio. negocio dentro de la empresa.
información –
datos.
240
Matriz de Describe la relación entre las

aplicaciones – datos. aplicaciones (componentes) y las
entidades de datos que son accedidas
y actualizadas por ellas.
Fase C: Matriz de Describe la relación entre las

arquitectura de aplicaciones – aplicaciones y las funciones de negocio
sistemas de funciones. dentro de la empresa.
información –
aplicaciones.
Matriz de Describe la relación entre las
aplicaciones – aplicaciones y las áreas
organización. organizacionales dentro de la empresa.
Matriz de interacción Representa las relaciones de

de aplicaciones. comunicación entre aplicaciones.
Matriz de roles – Describe la relación entre las

aplicaciones. aplicaciones y los roles de negocio que
las utilizan.
Fase D: Matriz de Documenta el mapeo de aplicaciones a

arquitectura aplicaciones – la plataforma tecnológica.
tecnológica. tecnología.

241
ANEXO 11: Entregables TOGAF 9.1.
Tabla 72: Entregables del método de desarrollo arquitectónico.
Nombre Salida de... Entrada para.. Descripción
Principios Fase Fase preliminar, A, Contiene directrices y un conjunto detallado de principios arquitectónicos
arquitectónicos. preliminar, A, B, C, D, E, F, G, H genéricos en las dimensiones: negocio, datos, aplicaciones y tecnología.
B, C, D
Repositorio Fase Fase preliminar, A, Documenta la estructura del repositorio que permitirá gestionar entregables,
arquitectónico. preliminar B, C, D, E, F, G, H localizar activos reutilizables, y publicar los resultados a las partes interesadas.
Modelo organizacional Fase Fase preliminar, A, Define los límites entre los distintos profesionales de arquitectura empresarial y
de arquitectura preliminar B, C, D, E, F, G, H las relaciones de gobernanza que se extienden a través de estos límites.
empresarial.
Solicitud de trabajo Fase A, G Se envía desde la organización patrocinadora hacia la organización que se
arquitectónico. preliminar, F, H encargará de desarrollar el trabajo arquitectónico, para desencadenar el inicio de
un ciclo de desarrollo arquitectónico.
Marco arquitectónico Fase Fase preliminar, A, Antes de desarrollar el trabajo arquitectónico, es necesario el ajuste del marco
adaptado. preliminar, A B, C, D, E, F, G, H, arquitectónico de referencia a las necesidades de la empresa. A este nivel se
Gestión de seleccionarán productos arquitectónicos adecuados para satisfacer las
requerimientos necesidades del proyecto y de los interesados.
Visión arquitectónica. A,E B, C, D, E, F, G, H, Proporciona un resumen de los cambios en la empresa, que se devengarán a
Gestión de partir de la implementación exitosa de la arquitectura destino.
requerimientos
242
Evaluación de A, E B, C, D, E, F Agrupa evaluaciones de capacidad en las dimensiones: negocios, datos,

capacidades. aplicaciones y tecnología. Además evalúa las capacidades arquitectónicas de la
empresa.
Plan de A B, C, D, E, F Describe la gestión del proceso de comunicación dentro de una organización.

comunicaciones. Especifica los grupos de interesados, las necesidades de comunicación y los
mecanismos que serán usados para comunicarse con los interesados y para que
ellos puedan acceder a la información.
Enunciado del trabajo A, B, C, D, E, B, C, D, E, F, G, H, Define el alcance y el enfoque que se utilizará para completar un ciclo de
arquitectónico. F, G, H Gestión de desarrollo arquitectónico.
requerimientos
Documento de B, C, D, E, F C, D, E, F, G, H Es el contenedor que agrupa los artefactos arquitectónicos básicos creados

definición durante un proyecto y obtiene información relacionada importante a partir de los
arquitectónica. mismos.
Especificación de B, C, D, E, F, C, D, Gestión de Ofrece un conjunto de enunciados cuantitativos que describen lo que el proyecto
requerimientos Gestión de Requerimientos de implementación debe hacer para cumplir con la arquitectura.
arquitectónicos. Requerimiento
s
Hoja de ruta del trabajo B, C, D, E, F B, C, D, E, F La hoja de ruta del trabajo arquitectónico enumera los paquetes de trabajo que
arquitectónico. realizará la arquitectura destino y las coloca en una línea de tiempo para mostrar
la progresión de la arquitectura de línea base a la arquitectura destino.
Plan de implementación E,F F Ofrece un calendario de los proyectos que realizará la arquitectura destino.
y migración. Incluye proyectos ejecutables agrupados en portafolios y programas gestionados.
243
Arquitecturas de E,F F Muestra la empresa en estados incrementales reflejando los períodos de

transición. transición que se establecen entre las arquitecturas de línea base y destino.
Bloques de construcción F,H A, B, C, D, E Provee documentación arquitectónica y modelos del repositorio arquitectónico.
arquitectónicos.
Contrato arquitectónico. - - Son los acuerdos conjuntos entre el equipo de desarrollo y los directivos respecto
a entregas, calidad y aptitud para el propósito arquitectónico.
Modelo de gobernanza F G,H Una vez que la arquitectura se ha definido, es necesario planificar cómo las
de la implementación. arquitecturas de transición definidas se regirán mediante la implementación.
Evaluación del G H Proporcionan un mecanismo para revisar el progreso del proyecto y asegurar que
cumplimiento. el diseño e implementación avanza en línea con los objetivos estratégicos y
arquitectónicos.
Bloques de construcción G A,B,C,D,E,F,G Son bloques específicos de la implementación del repositorio arquitectónico de la
de la solución. empresa.
Solicitud de cambio H Gestión de Asegura que la arquitectura alcanza su valor de negocio objetivo original. Esto
arquitectónico. requerimientos incluye la gestión de cambios de una manera coherente.
Evaluación del impacto Gestión de Gestión de Evalúa los requerimientos arquitectónicos y la especificación actual para
de requerimientos. requerimientos requerimientos identificar los cambios que se deben hacer y sus consecuencias.

244
ANEXO 12: Iteración de capacidad arquitectónica del marco de referencia adaptado.
Tabla 73: Iteración de capacidad arquitectónica del marco de referencia adaptado.

Fase Objetivos Pasos Entradas Salidas Técnicas
1. Determinar las 1. Elaborar o actualizar la Entradas no Salidas no arquitectónicas: –
Fase preliminar.
capacidades planificación estratégica. arquitectónicas: • Contrato de trabajo simple.

empresariales que se • Estrategias, • Elaboración o actualización de la
pretenden alcanzar planes y planificación estratégica de la empresa.
gracias al trabajo principios de
arquitectónico. negocio. *
• Estrategias de
2. Planificar el proceso de 2. Seleccionar marcos de TI. * -- --
generación de referencia de gestión • Marcos legales.
capacidades. empresarial. *
• Contratos. *
3. Establecer los roles y • Planificación Entregable: --
responsabilidades requeridos estratégica de la • Estructura del equipo de arquitectura
bajo demanda del equipo de empresa. * empresarial y su organización.
Arquitectura empresarial, y su
organización. * Si existen.
4. Identificar y establecer los Artefactos: Principios

principios arquitectónicos. • Catálogo de principios arquitectónicos. arquitectónicos.
Entregable:
5. Identificar las mejores Entregable: --

prácticas de los marcos de • Marco arquitectónico adaptado.
gestión empresarial e
integrarlas con el marco
arquitectónico.
6. Implementar y configurar el La información resultante deberá ser --

repositorio arquitectónico documentada en el entregable Marco
empresarial. arquitectónico adaptado.
245
1. Desarrollar una visión 1. Establecer el proyecto Entradas no La información resultante deberá ser documentada en --
Fase A: Visión arquitectónica
de alto nivel de las arquitectónico. arquitectónicas: el entregable Enunciado del trabajo arquitectónico.
capacidades y del valor • Planificación
de negocio deseados. 2. Identificar interesados, estratégica de la Artefacto: Gestión de
preocupaciones y requerimientos empresa. • Mapa de interesados. interesados.
de negocio.
La información resultante deberá ser documentada en
Entradas el entregable Enunciado del trabajo arquitectónico.
arquitectónicas:
3. Confirmar y/o elaborar objetivos, • Estructura del La información resultante deberá ser documentada en --
impulsores y limitaciones del negocio. equipo de los entregables Enunciado del trabajo arquitectónico y
arquitectura Visión arquitectónica.
empresarial y su
4. Evaluar las capacidades organización. Artefacto: --
empresariales. • Principios • Diagrama de cadena de valor.
arquitectónicos. Entregable:
• Marco • Evaluación de capacidades.
arquitectónico
5. Definir el alcance. adaptado. La información resultante deberá ser documentada en --
el entregable Enunciado del trabajo arquitectónico.
6. Refinar los principios Artefacto: --

arquitectónicos, si es • Catálogo de principios arquitectónicos
(actualizado).
necesario.
Entregable:
• Principios arquitectónicos (actualizado).
7. Desarrollar la visión arquitectónica. Artefacto: --

• Diagrama de concepto de solución.
Entregable:
2. Obtener la aprobación 8. Definir los beneficios que entregará la La información resultante deberá ser documentada en --
arquitectura destino y los indicadores el entregable Enunciado del trabajo arquitectónico.
del Enunciado del claves de desempeño.
9. Identificar riesgos y actividades de La información resultante deberá ser documentada en Gestión de riesgos.
mitigación. el entregable Enunciado del trabajo arquitectónico.
10. Desarrollar el Enunciado del trabajo Entregable: --

arquitectónico y asegurar su aprobación. • Enunciado del trabajo arquitectónico.

246
ANEXO 13: Iteración de desarrollo arquitectónico del marco de referencia adaptado.
Tabla 74: Iteración de desarrollo arquitectónico del marco de referencia adaptado.

Fase B: Arquitectura de negocio.
1. Desarrollar la 1. Seleccionar modelos de Entradas no Artefactos: Escenarios de

arquitectónicas: • Catálogo de contrato – medida. negocio.
arquitectura de referencia, puntos de vista
• Planificación • Catálogo de impulsores/metas/objetivos.
negocio destino. y herramientas. estratégica. • Diagrama de casos de uso.
• Diagrama de descomposición funcional.
2. Desarrollar la descripción Entradas • Diagrama de flujos de procesos. –
de las arquitecturas de arquitectónicas: • Matriz de actor/rol.
• Entregables:
negocio de línea base y ◦ Estructura del
destino. equipo de
arquitectura
3. Realizar el5 análisis de empresarial y Análisis de brechas.
su organización
brechas. ◦ Principios
arquitectónicos.
2. Identificar posibles 4. Definir los componentes ◦ Marco Los componentes candidatos identificados –
que conformarán la Hoja de arquitectónico deberán ser una entrada para el desarrollo
componentes a ser adaptado.
ruta de la implementación. de la Hoja de ruta de la implementación,
incluidos en la Hoja ◦ Evaluación de creada en la fase E: Oportunidades y
de ruta de la capacidades.
soluciones.
◦ Visión
implementación. arquitectónica.
5. Conducir revisiones ◦ Enunciado del Si es necesario, se deberá actualizar el –
formales con los trabajo contenido del entregable Documento de
interesados. arquitectónico definición arquitectónica.
aprobado.
6. Crear la versión preliminar Entregables: –

• Versión preliminar del Documento de
del Documento de
especificación de requerimientos
definición arquitectónica. arquitectónicos.
• Versión preliminar del Documento de
definición arquitectónica.
247
1. Desarrollar la 1. Seleccionar modelos de Entradas no Artefactos: --

Fase C: Sistemas de información – Datos.
arquitectónicas:
arquitectura de referencia, puntos de • Planificación • Catálogo de entidades de
datos destino. vista y herramientas. estratégica. datos/componentes de datos.
• Diagrama conceptual de datos.
Entradas
• Diagrama lógico de datos.
2. Desarrollar la descripción arquitectónicas: --
• Entregables: • Matriz de aplicaciones / datos.
de las arquitecturas de ◦ Estructura del
datos de línea base y equipo de
destino. arquitectura
empresarial y
su organización.
◦ Principios
3. Realizar el análisis de arquitectónicos.
Análisis de
brechas. ◦ Marco brechas.
arquitectónico
adaptado.
2. Identificar posibles 4. Definir los componentes ◦ Evaluación de Los componentes candidatos –
capacidades.
componentes a ser que conformarán la Hoja ◦ Visión
identificados deberán ser una entrada
incluidos en la Hoja de ruta de la arquitectónica. para el desarrollo de la Hoja de ruta
de ruta de la implementación. ◦ Enunciado del de la implementación, creada en la
implementación. trabajo fase E: Oportunidades y soluciones.
arquitectónico
aprobado.
◦ Documento de
5. Conducir revisiones especificación
Si es necesario, se deberá actualizar –
formales con los de el contenido del entregable
interesados. requerimientos Documento de definición
arquitectónicos
preliminar.
arquitectónica.
◦ Documento de
definición
6. Crear la versión arquitectónica Entregables: –
preliminar del preliminar. • Versión preliminar del Documento
Documento de definición de especificación de
arquitectónica. requerimientos arquitectónicos.
• Versión preliminar del Documento
248
Fase C: Sistemas de información – Aplicaciones.
1. Desarrollar la 1. Seleccionar modelos de Entradas no Artefactos: • Patrones
arquitectónicas: arquitectónicos.
arquitectura de referencia, puntos de • Planificación • Catálogo de portafolio de • Requerimientos de
aplicaciones vista y herramientas. estratégica. aplicaciones. interoperabilidad.
destino. • Diagrama de casos de uso de
Entradas
2. Desarrollar la descripción arquitectónicas:
aplicaciones. --
de las arquitecturas de • Entregables: • Diagrama de comunicaciones.
aplicaciones de línea ◦ Estructura del • Matriz de interacción de
equipo de
base y destino. arquitectura
aplicaciones.
empresarial y
3. Realizar el análisis de su organización. Análisis de
◦ Principios
brechas. arquitectónicos.
brechas.
◦ Marco
2. Identificar posibles 4. Definir los componentes arquitectónico Los componentes candidatos –
adaptado.
componentes a ser que conformarán la Hoja ◦ Evaluación de identificados deberán ser una entrada
incluidos en la Hoja de ruta de la capacidades. para el desarrollo de la Hoja de ruta
de ruta de la implementación. ◦ Visión de la implementación, creada en la
arquitectónica.
implementación. ◦ Enunciado del
fase E: Oportunidades y soluciones.
trabajo
5. Conducir revisiones arquitectónico Si es necesario, se deberá actualizar –
aprobado. el contenido del entregable
formales con los ◦ Documento de
interesados. especificación Documento de definición
de arquitectónica.
requerimientos
arquitectónicos
6. Crear la versión preliminar.
Entregables: –
preliminar del ◦ Documento de • Versión preliminar del Documento
Documento de definición definición de especificación de
arquitectónica
arquitectónica. preliminar.
249
1. Desarrollar la 1. Seleccionar modelos de Entradas no Artefactos: --

Fase D: Arquitectura tecnológica.
arquitectónicas:
arquitectura de referencia, puntos de • Catálogo de estándares
• Planificación
aplicaciones vista y herramientas. estratégica. tecnológicos.
destino. • Catálogo de portafolio de
Entradas tecnología.
2. Desarrollar la descripción arquitectónicas:
--
de las arquitecturas • Entregables:
• Diagrama de descomposición de la
◦ Estructura del plataforma tecnología.
tecnológicas de línea
equipo de • Matriz de aplicaciones – tecnología.
base y destino. arquitectura
empresarial y
3. Realizar el análisis de su organización. Análisis de
◦ Principios
brechas. arquitectónicos.
brechas.
◦ Marco
2. Identificar posibles 4. Definir los componentes arquitectónico Los componentes candidatos –
adaptado.
componentes a ser que conformarán la Hoja ◦ Evaluación de identificados deberán ser una entrada
incluidos en la Hoja de ruta de la capacidades. para el desarrollo de la Hoja de ruta
de ruta de la implementación. ◦ Visión de la implementación, creada en la
arquitectónica.
implementación. ◦ Enunciado del
fase E: Oportunidades y soluciones.
trabajo
5. Conducir revisiones arquitectónico Si es necesario, se deberá actualizar –
aprobado. el contenido del entregable
formales con los ◦ Documento de
interesado. especificación Documento de definición
de arquitectónica.
requerimientos
arquitectónicos
6. Crear la versión preliminar.
Entregables: –
preliminar del ◦ Documento de • Versión preliminar del Documento
Documento de definición definición de especificación de
arquitectónica
arquitectónica. preliminar.
250
ANEXO 14: Evaluación de los artefactos de las fases B, C y D.
Tabla 75: Evaluación de los artefactos de las fases B, C y D.
Fase B Catálogo. Catálogo de Se considera necesario el uso de un catálogo

impulsores – metas – de impulsores /metas /objetivo, debido a que
objetivos. en cualquier tipo de empresa se constituye
como una poderosa herramienta de
planificación estratégica.
Fase B Catálogo. Catálogo de medida - La utilización de un catálogo de medida –

contrato. contrato es importante debido a que
proporciona una visión general de los
acuerdos de nivel de servicio (ANS)
establecidos.
Fase B Catálogo. Catálogo de áreas Este catálogo complementa a la matriz de

organizativas – actor. interesados y es una herramienta útil para
comprender la composición de la empresa.
Su uso dependerá del nivel de formalidad
requerido por la empresa.
Fase B Catálogo. Catálogo de proceso No se considera obligatorio el uso de este

– evento – control – catálogo debido a que su contenido puede
producto. ser reemplazado por el que se presenta en
un diagrama de flujos de procesos.
Fase B Catálogo. Catálogo de roles. Este catálogo puede complementar a la

matriz de roles y responsabilidades, por lo
que su desarrollo será útil en cualquier
empresa, ofreciendo una visión general de
los roles.
Fase B Catálogo. Catálogo de servicios Pese a que el catálogo de servicios –

– funciones. funciones es útil en el proceso de identificar
nuevas capacidades requeridas para soportar
iniciativas de cambio en el negocio o en la
tecnología, su uso dependerá del nivel de
formalidad requerido por la empresa.
Fase B Catálogo. Catálogo de No se considera indispensable el uso de un

ubicaciones. catálogo de ubicaciones, debido a que la
mayoría de PYMEs no cuenta con múltiples
lugares para efectuar sus operaciones
comerciales.
251
Fase B Diagrama. Diagrama de casos Este diagrama permite a las empresas una
de uso de negocio. mejor comprensión de sus procesos o
servicios de negocio y de las entidades que
los consumen o participan en su
implementación, por lo tanto es
imprescindible su uso.
Fase B Diagrama. Diagrama del ciclo de Dependiendo del tipo de empresa

vida del producto. (comercial/industrial/servicios), este diagrama
podría ser útil para identificar posibles
controles, procesos y procedimientos para la
generación de productos.
Fase B Diagrama. Diagrama de Este diagrama brinda un perspectiva

descomposición funcional de las capacidades de negocio,
funcional. posibilitando una comprensión rápida de las
funciones del negocio. Su uso es
imprescindible en el proceso arquitectónico.
Fase B Diagrama. Diagrama de Este artefacto presenta una cadena de

descomposición de la mando de los responsables de la toma de
organización. decisiones en la empresa. Su uso dependerá
del nivel de formalidad requerido por la
empresa.
Fase B Diagrama. Diagrama de eventos. Este artefacto proporciona una visión general
de los factores desencadenantes de un
proceso. Su uso dependerá del nivel de
Fase B Diagrama. Diagrama de flujos de La mayor parte de las PYMEs no cuentan con
procesos. una descripción formal de sus procesos. Por
lo tanto, este artefacto es una herramienta
valiosa para definir las secuencias de
actividades y controles que se aplican para
efectuar un proceso.
Fase B Diagrama. Diagrama de Este artefacto es una herramienta de

presencia del comunicación de alto nivel sobre cómo las
negocio. unidades organizativas prestan sus servicios.
Fase B Diagrama. Diagrama de Este diagrama proporciona una guía de cómo

metas/objetivos/servicios.
los servicios de negocio contribuyen al
rendimiento del negocio. Su uso dependerá
del nivel de formalidad requerido por la
empresa.
252
Fase B Diagrama. Diagrama de Es opcional el uso de este artefacto, pues su

servicios de negocio contenido es desarrollado en la descripción
e información. de la arquitectura de datos.
Fase B Matriz. Matriz de actor – rol. Esta matriz es una herramienta útil en el
proceso de determinar las necesidades de
formación y capacitación del personal. Esta
matriz muestra qué actores desarrollan
ciertos roles, permitiendo determinar
sobrecarga de trabajo o duplicidad de
actividades. Por lo tanto, es un artefacto
imprescindible en el proceso arquitectónico.
Fase B Matriz Matriz de interacción El uso de este artefacto es opcional, debido a

del negocio. que su contenido es descrito también en el
diagrama de descomposición funcional de la
empresa.
Fase C: Catálogo. Catálogo de Un catálogo de entidades de datos –

Datos entidades de datos – componentes de datos será útil para apoyar a
componentes de los procesos de gobierno de datos y gestión
datos. de información. Por lo tanto, se cree
pertinente su utilización.
Fase C: Diagrama. Diagrama conceptual El diagrama conceptual de datos es la

Datos de datos. representación más abstracta del modelo de
datos de la empresa. Debido a su
simplicidad, es útil para comunicar ideas a
una amplia gama de grupos de interés; por lo
tanto su adopción es imprescindible.
Fase C: Diagrama. Diagrama de difusión El principal uso del diagrama de difusión de

Datos de datos. datos es representar la replicación de datos y
los responsables de las entidades. Por lo
tanto, su adopción dependerá del nivel de
Fase C: Diagrama. Diagrama de La migración de datos puede ser expresada

Datos migración de datos. en un nivel conceptual, lógico o físico.
Incluso, los diagramas de comunicación de
aplicaciones pueden ser utilizados para
expresar la migración de datos. Por lo tanto,
la utilización de este diagrama es opcional.
Fase C: Diagrama. Diagrama de Este diagrama apoya a los procesos de

Datos seguridad de datos. gestión de seguridad de datos,
proporcionando una visión general de qué
actores pueden acceder a los datos de los
253
sistemas. Su adopción dependerá del nivel

de formalidad requerido por la empresa.
Fase C: Diagrama. Diagrama del ciclo de El diagrama de ciclo de vida de datos es un

Datos vida de datos. elemento importante para la gestión de los
datos de negocio a través de su ciclo de vida.
Sin embargo, su adopción dependerá del
nivel de formalidad requerido por la empresa.
Fase C: Diagrama. Diagrama lógico de El propósito del diagrama lógico de datos es

Datos datos. representar claramente las relaciones entre
las entidades de datos y ayudar en la
comprensión de los modelos de datos. Por lo
tanto, es imprescindible su uso.
Fase C: Matriz. Matriz de entidad de Este artefacto apoya a los procesos de

Datos datos – funciones de gobierno de datos. Su adopción dependerá
negocio. del nivel de formalidad requerido por la
empresa.
Fase C: Matriz. Matriz de La matriz de aplicaciones – datos es una

Datos aplicaciones – datos. herramienta útil para asegurar la integridad
de datos, debido a que identifica escenarios
de duplicidad de datos y determina
situaciones en donde diferentes aplicaciones
actualicen los mismos datos
simultáneamente. Su uso resulta
imprescindible.
Fase C:
Aplicaciones
Catálogo. Catálogo de La importancia de un catálogo de interfaces
interfaces. radica en que permite comprender el grado
de interacción de las aplicaciones que
soportan el negocio. Sin embargo, su
contenido es similar al presentado en la
matriz de interacción de aplicaciones. Por lo
tanto, su desarrollo se considera opcional.
Fase C:
Aplicaciones
Catálogo. Catálogo de portafolio El catálogo de portafolio de aplicaciones da
de aplicaciones. inicio a la Fase C: Arquitectura de sistemas
de información – Aplicaciones. Es importante
su uso, debido a que permite identificar
iniciativas de cambio en las aplicaciones y
evaluar la adhesión de las aplicaciones a
cierto conjunto de estándares.
Fase C:
Aplicaciones
Diagrama. Diagrama de gestión Este diagrama es una especialización del
empresarial. diagrama de comunicaciones, por lo tanto no
es indispensable su utilización.
254
Fase C:
Aplicaciones
Diagrama Diagrama de De acuerdo a las características de las
aplicación y ubicación PYMEs, no es útil el uso de este diagrama
de usuario. debido a que no existe una extensa
distribución geográfica en las solicitudes
generadas a los sistemas corporativos.
Fase C:
Aplicaciones
Diagrama Diagrama de casos Este diagrama es muy importante para el
de uso de proceso de descripción arquitectónica, puesto
aplicaciones. que ilustra qué conexiones existen entre las
aplicaciones y usuarios. Es una herramienta
útil para identificar potenciales requerimientos
de los sistemas.
Fase C:
Aplicaciones
Diagrama Diagrama de Este diagrama es muy importante para el
comunicación de proceso de descripción arquitectónica porque
aplicaciones. proporciona una visión general de las
relaciones entre aplicaciones, componentes e
interfaces.
Fase C:
Aplicaciones
Diagrama Diagrama de Este diagrama es útil en proyectos de
distribución de consolidación de aplicaciones. Su adopción
software. dependerá del nivel de formalidad requerido
por la empresa.
Fase C:
Aplicaciones
Diagrama Diagrama de Las PYMEs son empresas que priorizan la
ingeniería de compra de software antes que su creación.
software. Por lo tanto, este diagrama no sería útil para
este tipo de empresas, debido a que está
orientado a equipos de desarrollo de
software.
Fase C:
Aplicaciones
Diagrama Diagrama de El diagrama de migración de aplicaciones
migración de constituye una herramienta útil para la
aplicaciones. planificación de arquitecturas de transición,
puesto que identifica las etapas necesarias
para asegurar la migración de aplicaciones.
Fase C:
Aplicaciones
Diagrama Diagrama de Este diagrama es un complemento para el
realización de diagrama de comunicaciones, por lo tanto su
procesos/aplicaciones. uso es opcional.
Fase C:
Aplicaciones
Matriz. Matriz de Esta matriz es importante porque permite
aplicaciones – alinear las aplicaciones corporativas con las
funciones. funciones de negocio desarrolladas por la
empresa. Sin embargo, su uso dependerá del
nivel de formalidad requerido por la empresa.
255
Fase C:
Aplicaciones
Matriz. Matriz de El uso de esta matriz dependerá del nivel de
aplicaciones – formalidad requerido por la empresa en el
unidades proceso de descripción de la arquitectura de
organizativas. aplicaciones.
Fase C:
Aplicaciones
Matriz. Matriz de interacción La matriz de interacción de aplicaciones es
de aplicaciones. un artefacto importante para la descripción
arquitectónica, debido a que muestra las
relaciones de comunicación que tienen las
aplicaciones, permitiendo la identificación de
interfaces entre las mismas.
Fase C:
Aplicaciones
Matriz. Matriz de roles – Esta matriz permite describir cómo las
aplicaciones. personas interactúan con las aplicaciones.
Sin embargo, su adopción es opcional en el
proceso de descripción de la arquitectura de
aplicaciones.
Fase D Catálogo. Catálogo de El uso de un catálogo de estándares de

estándares de tecnología permitirá tener una vista
tecnología. instantánea de los estándares desplegados o
por desplegar en la empresa, por lo tanto
importante su uso.
Fase D Catálogo. Catálogo de portafolio El catálogo de portafolio de tecnología es el

de tecnología. punto de inicio para la fase D. Se ajusta con
los estándares establecidos en el modelo de
referencia técnico (TRM). Es importante su
utilización debido a que permitirá evaluar el
cumplimiento de la adhesión a estándares
tecnológicos en la empresa.
Fase D Diagrama. Diagrama de red El diagrama de red informática – hardware es

informática – un diagrama que muestra el ambiente
hardware. tecnológico en alto nivel. Su adopción
dependerá del nivel de formalidad requerido
por la empresa.
Fase D Diagrama. Diagrama de El diagrama de descomposición de la

descomposición de plataforma proporciona una visión general de
plataforma. la infraestructura tecnológica de la empresa,
por lo tanto es importante su uso para lograr
una adecuada comprensión de los
componentes tecnológicos que soportarán la
arquitectura de sistemas de información.
Fase D Diagrama. Diagrama de No se considera relevante el uso de este

entornos y diagrama, debido a que la mayoría de
ubicaciones. PYMEs no cuenta con múltiples lugares para
efectuar sus operaciones comerciales.
256
Fase D Diagrama. Diagrama de El diagrama de procesamiento define las

procesamiento. unidades de despliegue de la plataforma
tecnológica de la empresa. Su adopción
dependerá del nivel de formalidad
establecido por la empresa.
Fase D Matriz. Matriz de La utilidad de la matriz de aplicaciones –

aplicaciones – tecnología radica en que se constituye como
tecnología. un complemento para el diagrama de
descomposición de la plataforma tecnológica,
por lo tanto su uso es importante.
257
ANEXO 15: Relaciones de los tableros Kanban del marco arquitectónico adaptado.
Figura 85: Relaciones de los tableros Kanban del marco propuesto.

258
ANEXO 16: Marco arquitectónico adaptado.
259
Marco arquitectónico adaptado
Proyecto: Arquitectura empresarial - CTL.
Cliente: Cooperativa de Transportes Loja.
2016
260
Índice del documento
Propósito del documento.....................................................................................................263
Método de desarrollo arquitectónico...................................................................................263
Contenido arquitectónico adaptado.....................................................................................265
Continuum empresarial y herramientas...............................................................................267
Mejores prácticas de los marcos de gestión empresarial....................................................270
261
Información del documento
Nombre del
Arquitectura empresarial – CTL.
proyecto
Preparado N° de versión del

Francisco Oswaldo Vargas Naula. 1.0
por documento
Fecha de versión del

Título Marco arquitectónico adaptado. 2016-10-04
documento
Revisado por Armando Augusto Cabrera Silva. Fecha de revisión --
Lista de distribución
Desde Fecha Teléfono/fax/email
Francisco Oswaldo Vargas Naula. 2016-10-04 fovargas@utpl.edu.ec
Fecha
A Acción* Teléfono/fax/email
de fin
En
Armando Augusto Cabrera Silva. aacabrera@utpl.edu.ec
revisión.
* Tipos de acciones: aprobado, en revisión, informe, archivo.
Historial de versiones del documento
Nº Fecha Revisado por Descripción Nombre del archivo
Armando Augusto Versión inicial del

1.0 2016-10-04 CTL-FPT-MAA_v0.1
Cabrera Silva. documento.
262
1 Propósito del documento.
El presente documento describe al marco arquitectónico adaptado, ajustado a las

necesidades de la Cooperativa de transportes Loja.
TOGAF proporciona un marco arquitectónico estándar de la industria, que puede ser

utilizado en una amplia variedad de organizaciones. Sin embargo, antes que TOGAF se
pueda utilizar eficazmente dentro de un proyecto arquitectónico, es necesario su adaptación
en dos niveles.
En primer lugar, es necesario adaptar el modelo TOGAF para su integración en la empresa.

Esta adaptación incluirá la integración con marcos de gestión de
proyectos/portafolio/programa, personalización de terminología, desarrollo de estilos de
presentación, selección, configuración y despliegue de herramientas de arquitectura, etc. La
formalidad y detalle de los marcos adoptados también debe alinearse con otros factores
contextuales de la empresa, tales como la cultura, actores, modelos comerciales para la
arquitectura empresarial, y el nivel actual de la capacidad arquitectónica.
Una vez que el marco se ha adaptado a la empresa, es necesario su integración con el

proyecto de arquitectura específico. La adaptación a este nivel permitirá seleccionar los
productos arquitectónicos adecuados para satisfacer las necesidades del proyecto y las
partes interesadas.
2 Método de desarrollo arquitectónico.
A continuación, se describe al método empleado para el desarrollo arquitectónico:
2.1 Método de desarrollo arquitectónico.
Para el presente proyecto arquitectónico, se implementará el método de desarrollo

arquitectónico propuesto en el trabajo “Definición de marco de referencia de Arquitectura
empresarial para PYMEs”. De forma general, se presenta a continuación las fases a
desarrollar:
263
• Iteración de capacidad arquitectónica: Fase preliminar, Fase A: visión
arquitectónica.
• Iteración de desarrollo arquitectónico: Fase B: Arquitectura de Negocio, Fase C:
Arquitectura de Sistemas de Información, Fase D: Arquitectura tecnológica.
• Iteración de planificación de la transición: Fase E: Oportunidades y soluciones,
Fase F: planificación de la migración.
• Iteración de gobernanza arquitectónica: Fase G: Gobernanza de la
implementación, Fase H: Gestión del cambio.
• Gestión de requerimientos (transversal a todas las iteraciones).
Figura 86: Método de desarrollo arquitectónico.

264
3 Contenido arquitectónico adaptado.
Durante el proyecto arquitectónico, se generará contenido que puede ser de dos tipos:
entregable o artefactos (catálogos, diagramas y matrices).
3.1 Artefactos arquitectónicos.
A continuación, se presenta un listado de los artefactos a desarrollar para el presente

proyecto:
Tabla 76: Artefactos del contenido arquitectónico adaptado.
Iteración Fase Tipo Artefacto
Capacidad Fase Catálogo • Principios arquitectónicos.

arquitectónica preliminar.
Visión Diagrama • Diagrama de cadena de valor.

arquitectónica. • Diagrama de concepto de solución
Matriz • Mapa de interesados.
Arquitectura de Catálogo • Catálogo de contrato – medida.

Desarrollo negocio. • Catálogo de
arquitectónico impulsores/metas/objetivos.
Diagrama • Diagrama de casos de uso.

• Diagrama de descomposición
funcional.
• Diagrama de flujos de procesos.
Matriz • Matriz de actor/rol.
Arquitectura de Catálogo • Catálogo de entidades de

datos. datos/componentes de datos.
Diagramas • Diagrama conceptual de datos.

• Diagrama lógico de datos.
Matriz • Matriz de aplicaciones / datos.
Arquitectura de Catálogo • Catálogo de portafolio de

Diagramas • Diagrama de casos de uso de

aplicaciones
• Diagrama de comunicaciones.
Matriz • Matriz de interacción de aplicaciones.
265
Arquitectura Matriz • Matriz de aplicaciones – tecnología.
tecnológica.
Diagrama • Diagrama de descomposición de la
plataforma tecnológica.
Catálogo • Catálogo de estándares de

tecnología.
• Catálogo de portafolio de tecnología.
Diagramas • Diagrama de contexto.

Transición Oportunidades • Diagrama de beneficios de proyectos.
arquitectónica y soluciones.
Matrices • Matriz de evaluación y deducción de
factores de implementación.
• Matriz de brechas, soluciones y
dependencias consolidadas.
Todo el ciclo ADM Gestión de Catálogo • Catálogo de requerimientos

requerimientos.
3.2 Entregables arquitectónicos.
A continuación, se presenta un listado de los entregables a desarrollar para el presente

proyecto:
Tabla 77: Entregables del contenido arquitectónico adaptado.
Iteración Fase Entregable
Capacidad Preliminar. • Planificación estratégica.

arquitectónica • Estructura del equipo de arquitectura
empresarial y su organización.
• Marco arquitectónico adaptado.
Visión arquitectónica. • Evaluación de capacidades.

• Enunciado de trabajo arquitectónico.
Desarrollo Arquitecturas de • Documento de definición arquitectónica.

arquitectónico negocio, sistemas de • Documento de especificación de requerimientos.
información y
tecnología.
Transición Oportunidades y • Hoja de ruta de la implementación.

arquitectónica soluciones. • Plan de implementación y migración
• Escenarios operativos.
266
Planificación de la • Modelo de gobernanza de la implementación.
migración. • Bloques de construcción.
• Solicitudes de cambios
Gobernanza Gobernanza de la • Acuerdos de nivel de servicio.

arquitectónica implementación. • Contratos arquitectónicos.
• Evaluaciones de cumplimiento.
Gestión del cambio. • Solicitudes de trabajo arquitectónico. (cambios

considerables).
Todo el ciclo Gestión de • Evaluación de impacto de requerimientos.

ADM requerimientos.
4 Continuum empresarial y herramientas.
El continuum empresarial es el método de clasificación que provee TOGAF de los activos

empresariales. Permite a la empresa reutilizar artefactos y soluciones arquitectónicas para
maximizar las oportunidades de éxito de trabajos arquitectónicos. Cabe destacar que el
continuum empresarial tiene dos especializaciones: continuum arquitectónico y continuum
de soluciones.
4.1 Continuum arquitectónico.
Ofrece una forma organizada para definir y permitir la comprensión de reglas genéricas, sus
representaciones y relaciones. Representa la estructura de los Bloques de construcción
arquitectónico (ABBs, por sus siglas en inglés), los mismos que evolucionan a lo largo del
ciclo de desarrollo arquitectónico desde entidades abstractas y genéricas hasta activos
arquitectónico. Existen cuatro principales clasificaciones:
• Arquitecturas de la Fundación: Compuestas por elementos genéricos, principios y

directrices que permiten construir arquitecturas más específicas.
• Arquitecturas de Sistemas Comunes: Permiten la selección e integración de
servicios de las Arquitecturas de la Fundación para crear arquitecturas que posibiliten
el desarrollo de soluciones altamente reutilizables.
267
• Arquitecturas de la Industria: Guían la integración de componentes de sistemas
comunes con componentes específicos de la Industria. Permiten la creación de
soluciones para problemas específicos de los clientes en un determinado sector de la
Industria.
• Arquitecturas específicas: Describen el despliegue final de los componentes de la
solución para una empresa en particular.
4.2 Continuum de soluciones.
Proporcionada una forma organizada para definir y permitir la comprensión de la aplicación

de los activos definidos en el Continuum arquitectónico. Define los elementos disponibles en
el entorno empresarial como Bloques de construcción de la solución. (SBBs, por sus siglas
en inglés).
Figura 87: Continuum empresarial de la Cooperativa de transportes Loja.

268
4.3 Repositorio arquitectónico.
El repositorio arquitectónico actúa como una zona de espera para todos los proyectos
relacionados con la arquitectura dentro de la empresa. El repositorio permite a los proyectos
gestionar sus entregables, identificar activos reutilizables y publicar los resultados a las
partes interesadas y a otras.
4.3.1 Herramienta seleccionada.
Existe una variedad de herramientas que podrían ser utilizadas para gestionar el repositorio
arquitectónico de la empresa. Sin embargo, se ha decidido optar por una herramienta de tipo
Gestor de contenido empresarial (ECM, por sus siglas en inglés), la cual facilitará el proceso
de administración del contenido generado. Para el presente proyecto se ha seleccionado a
Alfresco ECM, como la herramienta que permita administrar el repositorio arquitectónico de
la empresa.
Figura 88: Estructura del repositorio arquitectónico de la CTL.

269
Alfresco ECM8, es una solución informática que ha sido integrada en un gran número de
empresas a nivel mundial. Destaca por ser de código abierto y permitir la gestión de
cualquier tipo de contenido empresarial. Fomenta la colaboración simple y ofrece una
comunidad activa de desarrollo y soporte.
5 Mejores prácticas de los marcos de gestión empresarial.
A continuación, se listan las mejores prácticas que se adoptarán de los marcos de gestión
empresarial.
5.1 Marco de gestión de proyectos.
• Guía de fundamentos de gestión de proyectos (PMBOK): Fue desarrollado por el

Project Management Institute (PMI)9, con el objetivo de unificar las prácticas sobre
gestión de proyectos. Es el estándar más ampliamente reconocido para manejar y
administrar proyectos. Representa un conjunto de conocimientos desarrollados a
partir de la experiencia y de estudios sistemáticos. Documenta nueve áreas de
conocimiento y cinco grupos de procesos, los cuales considera universales para casi
todo tipo de proyectos. (Zwikael, 2009).
Tabla 78: Integración de TOGAF y PMBOK.
Fase Paso TOGAF Consideración PMBOK
Fase A Establecer el proyecto • Determinar cultura organizacional y

arquitectónico. procesos existentes.
• Entender el caso de negocio del
proyecto.
• Desarrollar la descripción del proyecto.
Identificar interesados, • Identificar interesados.

preocupaciones y • Desarrollar una estrategia de gestión
requerimientos del negocio. de interesados.
Confirmar y elaborar objetivos, • Para el desarrollo de este paso, utilizar

impulsores y limitaciones del el proceso de PMBOK: definir el
negocio. alcance.
8 Alfresco ECM, gestor documental de plataforma abierta. Página oficial: https://www.alfresco.com/es.

9 PMI, organización internacional de Gestión de proyectos. Página oficial: https://www.pmi.org/.
270
Evaluar las capacidades • Para el desarrollo de este paso,

empresariales. utilizar el proceso de PMBOK:
definir el alcance.
Definir el alcance. • Para el desarrollo de este paso,

utilizar el proceso de PMBOK:
gestión del alcance del proyecto.
Refinar los principios • Este paso no está directamente

arquitectónicos, si es relacionado con los procesos de
necesario. gestión de proyectos.
Desarrollar la visión • Para el desarrollo de este paso,

arquitectónica. utilizar el proceso de PMBOK:
definir el alcance.
Definir los beneficios que • Para el desarrollo de este paso,

entregará la arquitectura utilizar el proceso de PMBOK:
destino y los indicadores definir el alcance.
claves de desempeño.
Identificar riesgos y • Para el desarrollo de este paso,

actividades de mitigación. utilizar el proceso de PMBOK:
◦ Planificar la gestión de riesgos.
◦ Identificar riesgos.
◦ Desarrollar un análisis cualitativo
de los riesgos.
◦ Desarrollar un análisis
cuantitativo de los riesgos.
◦ Planificar la respuesta a los
riesgos.
Desarrollar el Enunciado del • Para el desarrollo de este paso,

trabajo arquitectónico; utilizar el proceso de PMBOK:
asegurar su aprobación. ◦ Desarrollar el plan de gestión del
proyecto.
◦ Crear la estructura de desglose
de trabajo.
◦ Planificar el calendario.
◦ Definir las actividades.
◦ Secuenciar las actividades.
◦ Secuenciar los recursos de las
actividades.
◦ Estimar la duración de las
actividades.
◦ Desarrollar el calendario.
◦ Planificar la gestión de costos.
◦ Estimar costos.
◦ Determinar el presupuesto.
271
Fases B a F -- • Para el desarrollo de estas fases,

se deben considerar los siguientes
procesos:
◦ Dirigir y gestionar el trabajo
arquitectónico.
◦ Desarrollar un control integrado
de cambios.
◦ Cerrar el proyecto o la fase.
◦ Validar el alcance.
◦ Controlar el alcance.
◦ Controlar la calidad.
◦ Desarrollar el aseguramiento de
calidad.
◦ Gestionar el compromiso de los
interesados.
• Además, para actividades de

ejecución y monitoreo, se deben
considerar los siguientes procesos.
◦ Gestión de la integración.
◦ Gestión del alcance.
◦ Gestión de costos.
◦ Gestión de la calidad.
◦ Gestión de recursos humanos.
◦ Gestión de las comunicaciones.
◦ Gestión de riesgos.
Fase F Completar el ciclo de • Cerrar la fase o el proyecto.

desarrollo arquitectónico y
documentar las lecciones
aprendidas.
Fuente: PMBOK.
Adaptado de PMBOK.
• CREOPM: Es un instrumento utilizado por las empresas para calcular la utilidad que
presentan sus decisiones. Considera el valor de negocio, valor financiero, valor de TI
y los distintos riesgos al momento de optar por un proyecto. Establece dos tipos de
portafolios: CAPEX y OPEX, que contemplan los gastos de capital y los gastos
operativos respectivamente. (Bayney & Chakravati, 2012).
◦ Del marco CREOPM, para el desarrollo del presente proyecto arquitectónico, se

tomará en consideración su método de gestión de portafolio: 1) categorizar, 2)
analizar riesgos, 3) evaluar, 4) optimizar, 5) priorizar, 6) gestionar.
272
5.2 Marcos de gestión de operaciones.
• Biblioteca de infraestructura de tecnologías de información (ITIL): Es el enfoque

de gestión de servicios de TI más ampliamente aceptado en el mundo. Provee una
base conceptual y buenas prácticas para la gestión de servicios de TI, desarrollo de
tecnologías de información y operaciones relacionadas. Es un marco de mejores
prácticas elaborado por los sectores público y privado a nivel internacional, que
describe cómo los recursos de TI deben ser organizados para ofrecer un valor
empresarial. (Potgieter, Botha & Lew, 2005).
◦ Con ITIL en un rol operacional y TOGAF como el marco estratégico de toda la

empresa, su integración es posible en la mayoría de contextos. Debido a que el
área funcional para la arquitectura empresarial es toda la empresa, y en cambio
para ITIL es la prestación de servicios de TI, podemos asignar fácilmente
procesos y puntos de integración, utilizando ITIL como mecanismo de prestación
de servicios de TI y TOGAF como marco empresarial.
◦ La integración de estos marcos permitirá funciones de colaboración en toda la
empresa, ya que las unidades de negocio primarias y las funciones de prestación
de servicios de TI han definido puntos de interacción a lo largo del ciclo de
prestación de servicios, desde la estrategia empresarial hasta la jubilación del
servicio.
5.3 Marcos de gestión de riesgos.
• Marco de gestión de riesgos empresariales COSO III: COSO proporciona las

mejores prácticas referente a gestión de riesgos y ejecución de controles internos.
En el año 2013 se publicó la tercera versión de esta metodología de gestión de
riesgos, definiendo cinco componentes a tener en cuenta: entornos de control,
evaluación de riesgos, actividades de control, información y comunicación,
actividades de monitoreo y supervisión.
◦ Aunque para la gestión de riesgos empresariales, se tomará en consideración las

buenas prácticas dictadas por la técnica Gestión de riesgos de TOGAF, es
pertinente considerar el proceso de gestión de riesgos propuesto por COSO III:
273
▪ 1) Identificar riesgos, 2) desarrollar criterios para la evaluación de los riesgos,
3) evaluar riesgos, 4) evaluar dependencias de los riesgos, 5) priorizar
riesgos, 6) responder a los riesgos.
◦ Además, se tomará en cuenta las siguientes sugerencias propuestas para la

gestión de riesgos.
▪ Determinar riesgos a partir de dos perspectivas: probabilidad e impacto.
▪ En la evaluación de riesgos, la gerencia considera eventos previstos e
inesperados.
▪ Los riesgos inherentes y residuales son evaluados.
5.4 Marcos de gestión de la gobernanza.
• Objetivos de control para la información y tecnologías relacionadas (COBIT):

Es un estándar abierto utilizado por las organizaciones de todo el mundo. Su
principal propósito es el de servir como marco de control para facilitar la alineación
entre las tecnologías de información (TICs) y el Negocio. COBIT propone un marco
de acción en donde se midan criterios de información, se auditen recursos
relacionados a las tecnologías de información y se evalúen los distintos procesos
involucrados. (Ridley et al, 2004). A continuación, se describe la integración entre los
elementos de COBIT y los componentes del documento TOGAF.
Tabla 79: Integración de COBIT y TOGAF.
COBIT Componentes TOGAF
Dominio: Gobierno. • Junta arquitectónica.

• Gobernanza arquitectónica.
• Modelos de madurez arquitectónica.
Dominio: Alinear, Planificar, Organizar.
• Desarrollar una visión arquitectónica. • Fase A: Visión arquitectónica.

• Definir una arquitectura de referencia. • Fases B, C y D.
• Seleccionar oportunidades y soluciones. • Fase E.
• Definir la implantación de la arquitectura. • Fases F y G.
• Proveer servicios de arquitectura • Fase G y Gestión de requerimientos.
empresarial.
274
6 Referencias bibliográficas.
• Bayney R. & Chakravati R. (2012). Enterprise Project Portfolio Management: Building

Competencies for R&D and IT Investment Success.
• Potgieter, B., Botha, J., & Lew, C. (2005). Evidence that use of the ITIL framework is
effective. In 18th Annual conference of the national advisory committee on computing
qualifications, Tauranga, NZ (pp. 160-167).
• Ridley, G., Young, J., & Carroll, P. (2004). COBIT and its Utilization: A framework from
the literature. In System Sciences, 2004. Proceedings of the 37th Annual Hawaii
International Conference on (pp. 8-pp). IEEE.
• Sánchez, L. (2016). COSO ERM y la gestión de riesgos. Quipukamayoc,23 (44).
Recuperado de:
http://revistasinvestigacion.unmsm.edu.pe/index.php/quipu/article/download/11625/10
435.
• Zwikael, O. (2009). The relative importance of the PMBOK® Guide's nine Knowledge
Areas during project planning. Project Management Journal, 40(4), 94-103.
275
ANEXO 17: Estructura del equipo de arquitectura empresarial y su organización.
276
Estructura del equipo de arquitectura
empresarial y su organización
Proyecto: Arquitectura empresarial CTL.
2016
277
Unidades vinculadas con el proyecto arquitectónico...........................................................280
Roles y responsabilidades..................................................................................................281
Limitaciones........................................................................................................................ 285
Presupuesto........................................................................................................................ 285
Gobernanza y estrategia de soporte...................................................................................286
278
Nombre del
Arquitectura empresarial CTL.
proyecto

por documento
Equipo de arquitectura empresarial y su Fecha de versión del

Título 2016-10-04
organización. documento
Fecha
de fin
En
revisión.

1.0 2016-10-04 CTL-FPT-EEA_v0.1
279
El presente documento describe al equipo de arquitectura empresarial y su organización.
Con el fin de establecer un marco arquitectónico exitoso, se debe definir la estructura del
equipo de arquitectura empresarial. Además, un aspecto importante en el desarrollo del
presente entregable es la definición de las principales funciones del gobierno arquitectónico.
2 Unidades vinculadas con el proyecto arquitectónico.
La Cooperativa de Transportes Loja está compuesta por las siguientes unidades funcionales:
Figura 89: Unidades funcionales de la CTL.

280
• Unidades primarias: Hacen referencia a la desagregación de la empresa en sus
principales áreas organizativas.
• Unidades secundarias: Conformadas por las áreas del negocio que dan soporte a
las actividades de producción y generación de servicios (transporte, encomiendas,
estación de servicios, almacén de repuestos y taller mecánico).
El proyecto arquitectónico tiene relaciones intrínsecas con todas las unidades funcionales de
la empresa. Sin embargo, como el presente ejercicio arquitectónico se centrará en el
segmento Planificación de turnos de la cadena de valor empresarial, el proyecto
arquitectónico estará estrechamente relacionado con el área de Transporte de la
Cooperativa.
3 Roles y responsabilidades.
El marco de habilidades arquitectónicas propuesto por TOGAF, define los siguientes roles
arquitectónicos:
Tabla 80: Roles y responsabilidades del equipo de arquitectura empresarial.
Rol Responsabilidad
Miembros de la junta La junta arquitectónica* es un elemento fundamental en la

arquitectónica. estrategia de gobernanza, representativo de los actores
clave del trabajo arquitectónico. Sus principales
responsabilidades son:
• Definir actividades de gobernanza.

• Proporcionar un mecanismo de control fundamental para
asegurar el cumplimiento arquitectónico.
• Proporcionar un mecanismo de control para la
aceptación formal y aprobación de la arquitectura.
• Asegurar la alineación entre la arquitectura y las
estrategias y objetivos de negocio.
• Resolver ambigüedades, problemas o conflictos.
• Proporcionar asesoramiento, orientación e información.
• Proporcionar las bases para las decisiones relacionadas
con cambios arquitectónicos.
* El tamaño recomendado para la junta arquitectónica es

de 4-5 miembros (máximo 10).
281
Patrocinador del proyecto. • Solicitar el proyecto arquitectónico.
• Brindar los recursos necesarios para la ejecución del
• Tomar decisiones de alto nivel.
Gestor de la arquitectura de • Establecer la visión, objetivos y criterios de éxito para el

TI / Arquitecto en jefe. trabajo arquitectónico.
• Crear, refinar y supervisar la ejecución de los procesos
internos de la función arquitectónica, incluyendo la
documentación de los mismos.
• Administrar los miembros del equipo, participando en los
procesos de contratación del personal, establecimiento
de objetivos del equipo y de evaluaciones de
desempeño.
• Gestionar la asignación de recursos para cumplir con las
necesidades estratégicas de la empresa.
• Lograr compromiso entre los involucrados del trabajo
arquitectónico.
Arquitectos de soluciones: De forma general, las responsabilidades de cualquier

arquitecto de soluciones son:
• Conocer e interpretar requerimientos.
• Crear modelos bien formulados de los componentes de
la solución.
• Validar, refinar y ampliar los modelos.
• Dar seguimiento continuo de los modelos y actualizarlos
según sea necesario para mostrar cambios, adiciones y
alteraciones.
• Arquitecto • Alinear la estrategia de TI y la planificación de la

empresarial. empresa con los objetivos de negocio.
• Optimizar la gestión de la información, a través del
entendimiento de necesidades de negocio y
capacidades tecnológicos.
• Promocionar la infraestructura y aplicaciones
compartidas para reducir costos.
• Trabajar con arquitectos de negocio, datos, aplicaciones
y tecnología para el diseño de soluciones.
• Mitigar riesgos de los activos de TI.
• Arquitecto de • Desarrollar arquitecturas de negocio futuras basado en

negocio. el conocimiento de los diversos escenarios de negocio.
• Identificar, validar y refinar objetivos de negocio.
• Definir procesos clave y de soporte de la empresa.
• Definir los datos compartidos en toda la empresa y sus
interrelaciones.
• Identificar las relaciones entre las funciones, capacidad
y unidades del negocio.
282
• Arquitecto de • Diseñar el modelo lógico de datos.
datos. • Desarrollar reglas de negocio.
• Coordinar el proceso de armonización de datos.
• Comprender y comunicar los requerimientos de
información de la arquitectura destino.
• Establecer estrategias para la integración y
mantenimiento de los datos corporativos.
• Arquitecto de • Definir la arquitectura de aplicaciones.

software. • Resolver problemas funcionales de alto-nivel.
• Coordinar el proceso de desarrollo de soluciones de
software.
• Diseñar interfaces y servicios de software.
• Arquitecto de • Definir la plataforma tecnológica que soportará las

tecnología. aplicaciones corporativas.
• Seleccionar e implementar estándares tecnológicos.
• Resolver problemas técnicos, para asegurar que los
componentes del diseño técnico se incorporan
correctamente.
Arquitecto de integración Responsable de la integración de los sistemas de

información, tecnología y procesos de negocio.
Gestor de • Planificar, ejecutar, monitorear y evaluar los proyectos.

programa/proyecto. • Coordinar los procesos de reclutamiento, selección,
orientación, formación y asignación de personal.
• Comunicar las expectativas del trabajo arquitectónico.
Diseñador de TI. Conserva las mismas responsabilidades que un arquitecto

de TI, enfocándose en la traducción de la arquitectura en
soluciones.

En base a la anterior tabla y a las características de la Cooperativa de transportes Loja, se

establece que para el presente trabajo arquitectónico, los principales roles a cubrir bajo
demanda son:
• Arquitecto en jefe.
• Arquitecto de software.
• Arquitecto de integración.
283
Consideraciones:
• Dependiendo de la etapa del proceso arquitectónico, un profesional podría cumplir

múltiples roles.
• Para actividades específicas del desarrollo arquitectónico se podría requerir la
contratación adicional de alguno de los roles mencionados en la tabla.
• La junta arquitectónica estará conformada por: arquitecto en jefe, encargado del
departamento de sistemas de la Cooperativa y el patrocinador del proyecto.
A continuación, se presenta la matriz RACI correspondiente a los principales involucrados

del trabajo arquitectónico:
Tabla 81: Matriz RACI del proyecto arquitectónico.
R: responsable.
Junta arquitectónica
programa/portafolio
los departamentos
Arquitecto en jefe
Responsables de
Arquitectos de
A: aprobador.
Arquitecto de
Patrocinador
integración
soluciones
Gestor de
C: consultado.
I: informado.
Definir principios arquitectónicos. A A I R C C I
Desarrollar la visión arquitectónica. A A I R I I I
Efectuar el proceso de desarrollo

A A C R C C I
arquitectónico.
Generar la hoja de ruta del trabajo

A I I R C C I
arquitectónico.
Desarrollar evaluación de impactos. I I I R I C C
Efectuar el proceso de implementación. I I I R C R/I C
Evaluar el cumplimiento. R/A I I R/I R C I
Adoptar estándares arquitectónicos. I I I R/A I I C
Evaluar el desempeño. I I I R C C I
Gestionar cambios. A I I R/A C C C

284
4 Limitaciones.
A continuación se presentan limitaciones identificadas respecto al presente trabajo

arquitectónico.
4.1 Limitaciones a nivel organizacional.
• Resulta muy difícil implementar un departamento de arquitectura empresarial dentro

de la empresa.
• Algunos de los roles definidos anteriormente pueden verse descartados, debido a la
poca cantidad de profesionales capacitados en arquitectura empresarial.
• A causa de la insuficiente madurez de capacidades encontrada en la empresa, no se
podrán observar resultados a corto plazo, puesto que el tiempo idóneo para la
ejecución del proyecto debe ser entre 3 a 5 años.
4.2 Limitaciones de presupuesto.
• La contratación de los profesionales requeridos para la conformación del equipo de

arquitectura empresarial, representaría costos elevados para la empresa. Por lo
tanto, se sugiere la contratación de los roles principales indicados anteriormente y de
ser necesario contratar personal para actividades específicas del proyecto.
5 Presupuesto.
Los requerimientos de presupuesto mínimos para la conformación del equipo de arquitectura

empresarial son:
• Presupuesto para cubrir los rubros y honorarios de los integrantes del equipo de
• Presupuesto para materiales de oficina, equipos de informática y redes de
telecomunicaciones necesarias para el desarrollo de las actividades del equipo.
285
6 Gobernanza y estrategia de soporte.
De acuerdo al documento TOGAF, existen 3 áreas clave para la gestión arquitectónica:

desarrollo, implementación y despliegue. Una vez conformado el equipo de arquitectura
empresarial, es necesario definir los responsables para cada una de las áreas. La correcta
administración de las anteriores áreas y una adecuada administración del contenido
arquitectónico generado permitirá la aplicación efectiva de la gobernanza arquitectónica.
6.1 Estructura de la gobernanza.
En la siguiente figura, se describe las principales funciones de gobernanza para el proyecto

arquitectónico:
Figura 90: Estructura de la gobernanza.

286
6.2 Estrategia de soporte.
Dentro de la visión arquitectónica de la Cooperativa de Transportes Loja, dentro del dominio

de Arquitectura de Sistemas de Información, se proyecta la adopción de una arquitectura
orientada a servicios (SOA). The Open Group, en la siguiente figura, establece la estrategia
de soporte que debe seguir la empresa para la gobernanza del modelo arquitectónico en
mención:
Figura 91: Estrategia de soporte para la gobernanza.

287
ANEXO 18: Principios arquitectónicos.
288
Principios arquitectónicos
Proyecto: Propuesta de marco de

Cliente: Cooperativa de transportes Loja.
2016
289
Descripción de principios arquitectónicos............................................................................292
Listado de principios............................................................................................................ 293
Principios de negocio.......................................................................................................... 294
Principios de datos.............................................................................................................. 297
Principios de aplicaciones...................................................................................................299
Principios de tecnología......................................................................................................306
290
Nombre del
Arquitectura empresarial CTL.
proyecto

por documento

Título Principios arquitectónicos. 2016-10-04
documento
Fecha
de fin
En
revisión.

1.0 2016-10-04 CTL-FPT-PAA_v0.1
291
El presente documento detalla los principios arquitectónicos a los cuales la Cooperativa de

transportes Loja se adhiere. El propósito del documento es definir los principios
arquitectónicos para los dominios/subdominios más relevantes.
Nota 1: Un principio define las reglas perdurables que gobiernan la arquitectura de un

sistema deseado; por ejemplo la arquitectura destino. Es obligatorio considerar a los
principios en el diseño de las arquitecturas.
Nota 2: El equipo de arquitectura empresarial podría crear un documento de principios para

el dominio o varios documentos, uno por cada subdominio.
Nota 3: Si este documento contiene todos los principios para un dominio, la sección 3 se
puede dividir en varias secciones, una para cada subdominio.
Nota 4: Este documento se basa en las mejores prácticas de arquitectura empresarial,

TOGAF, y en el formato de la documentación actual de la arquitectura dentro de la
Cooperativa de transportes Loja.
2 Descripción de principios arquitectónicos.
Los principios son normas generales y directrices, destinadas a ser duradera y rara vez
modificadas, que informan y apoyan a la manera en que una organización avanza en el
cumplimiento de su misión. A su vez, los principios pueden ser sólo un elemento de un
conjunto estructurado de ideas que colectivamente definen y orientan a la organización.
A continuación, se presenta la plantilla para la definición de principios arquitectónicos:
Tabla 82: Plantilla para la definición de principios arquitectónicos.
Nombre <Nombre del principio>
Referencia <Identificador único del principio>
292
Enunciado El enunciado debe comunicar de manera sucinta y sin ambigüedades la
regla fundamental. En su mayor parte, los principios para la gestión de la
información son similares de una organización a otra. Es de vital importancia
que la declaración de principios sea inequívoca.
Fundamento El fundamento debe resaltar los beneficios empresariales de la adhesión al

principio, utilizando terminología de negocios. Indica la similitud de los
principios de información y tecnología con los principios que rigen las
operaciones de negocio. También debe describir la relación con otros
principios, y las intenciones en relación a una interpretación equilibrada.
Además, describe situaciones donde un principio debería tener mayor
precedencia o tener más peso que otro para tomar una decisión.
Implicaciones Las implicaciones deben resaltar los requisitos, tanto para negocio y TI,
para llevar a cabo el principio - en términos de recursos, costos y
actividades/tareas. A menudo, será evidente que los sistemas actuales,
estándares o prácticas serán incongruentes para la adopción del principio. El
impacto para el negocio y las consecuencias de la adopción de un principio
deben indicarse claramente. El lector debe discernir fácilmente la respuesta
a: "¿Cómo me afecta?". Es importante no simplificar en exceso, trivializar o
juzgar el mérito del impacto. Algunas de las consecuencias serán
identificadas como sólo impactos potenciales, y pueden ser especulativas y
no totalmente analizadas.
3 Listado de principios.
En la siguiente tabla, se lista el conjunto de principios arquitectónicos que deberán

desarrollarse en la Cooperativa de transportes
Tabla 83: Principios arquitectónicos de la Cooperativa de transportes Loja.
Dominio Principio
Negocio • Planificación del negocio

• Procesos simples y flexibles
• Centrado en el cliente
• Habilidades adecuadas
• Maximización de beneficios para la empresa
• Independencia tecnológica
Datos • Flujos de información formalmente definidos

• Alineación con las necesidades del negocio
• Claridad y consistencia
• Toma de decisiones
293
Aplicaciones • Arquitectura de aplicaciones
• Trazabilidad
• Flexibilidad
• Consolidación
• Orientada a la integración.
• Orientada al servicio.
• Interoperabilidad
• Acceso a la información.
• Soluciones de código abierto.
• Maximizar el retorno y minimizar el riesgo
• Sistemas legados
• Disponibilidad de documentación.
• Seguridad
Tecnología • Responsables.
• Modelo empresarial de integración tecnológica
• Enfoque de métricas de nivel de calidad
• Mantenimiento de la infraestructura.
• Racionalización de productos y plataforma
• Selección de productos.
• Portafolio de productos.
• Reutilizar, comprar y luego construir
• Criterios de seguridad
4 Principios de negocio.
Tabla 84: Principio de negocio: Planificación del negocio.
Nombre Planificación del negocio
Referencia CTL-PAN-001
Enunciado La arquitectura de negocio apoya a la planificación operativa y estratégica.
Fundamento La práctica arquitectónica incluye las herramientas requeridas para apoyar a

la planificación estratégica y operativa del negocio.
Implicaciones • Posicionar el negocio en el contexto empresarial.

• Asegurar la alineación entre metas de negocio y prioridades de la
empresa.
• Desarrollar modelos de negocio para cumplir con los objetivos
operacionales y estratégicos.
• Analizar los riesgos del negocio y desarrollar estrategias de mitigación
de riesgos.
Fuente: Gómez (2015).

Adaptado de Gómez.
294
Tabla 85: Principio de negocio: Procesos simples y flexibles.
Nombre Procesos simples y flexibles
Enunciado La arquitectura del negocio permite el diseño de procesos de negocio

Fundamento Las oportunidades para incrementar la eficiencia, efectividad y calidad

pueden ser identificadas y desarrolladas a través de procesos de negocio
Implicaciones • Analizar los procesos de negocio para facilitar, integrar, eliminar

redundancias e incrementar la eficiencia.
• Identificar procesos de negocio con fines de reuso.
• Diseñar procesos de negocio que permitan dar agilidad al negocio.
• Implementar herramientas de gestión y automatización de procesos
de negocio (BPM - Business process management).

Adaptado de Gómez.
Tabla 86: Principio de negocio: Centrado en el cliente
Nombre Centrado en el cliente
Enunciado La arquitectura de negocio debe estar orientada en las necesidades del

cliente.
Fundamento Los modelos de negocio están diseñados para satisfacer las necesidades
de las áreas de negocio de la empresa; y éstas a su vez existen para
cubrir las necesidades de los grupos destinatarios.
Implicaciones • Asegurar que el grupo objetivo se encuentra bien definido y

entendido.
• Definir objetivos estratégicos, objetivos de negocio y medidas de
rendimiento en términos de resultados para el grupo objetivo.
• Adoptar un enfoque orientado al cliente.
• Implementar herramientas para la administración de las relaciones
con el cliente. (CRM – Customer relationship management).

Adaptado de Gómez.
295
Tabla 87: Principio de negocio: Habilidades adecuadas.
Nombre Habilidades adecuadas
Enunciado La arquitectura de negocio debe fomentar la formación y capacitación

continua del personal.
Fundamento La conducta y rendimiento del personal influye directamente en la calidad

de los servicios que brinda la empresa. Desarrollar capacidades en el
personal proporcionará beneficios para éstos y para la empresa. Gracias
a la capacitación continua se logrará formar trabajadores más
competentes y hábiles.
Implicaciones • Definir claramente roles y responsabilidades.

• Planificar programas de capacitación y certificación continua para el
personal.

Adaptado de Gómez.
Tabla 88: Principio de negocio: Maximización de beneficios para la empresa.
Nombre Maximización de beneficios para la empresa
Enunciado La arquitectura de negocio debe estar diseñada para proporcionar el

máximo beneficio a la empresa.
Fundamento Este principio se puede resumir como: “servicio por sobre uno mismo”.
Las decisiones tomadas desde una perspectiva que englobe a toda la
empresa tienen un mayor valor a largo plazo que aquellas decisiones
tomadas desde un punto de vista particular.
Un máximo rendimiento en las inversiones requiere decisiones que se
adhieran a las prioridades de toda la empresa.
Implicaciones • Planificar la ejecución de cambios y adquisiciones.

• Evaluar las prioridades que presenten los distintos departamentos
que componen la empresa.
• Ajustar las prioridades de acuerdo a cómo surjan las necesidades.

Adaptado de Gómez.
296
Tabla 89: Principio de negocio: Independencia tecnológica.
Nombre Independencia tecnológica
Enunciado La arquitectura de negocio no está limitada por la tecnología.
Fundamento La arquitectura de negocio describe el modelo de negocio

independientemente de la tecnología que lo soporta y proporciona el
fundamento para el análisis de oportunidades de automatización.
Implicaciones • Eliminar restricciones tecnológicas al definir la arquitectura del

negocio.
• Asegurar que los procesos automatizados se describen en el nivel de
procesos de negocio con fines de análisis y diseño.

Adaptado de Gómez.
5 Principios de datos.
Tabla 90: Principio de datos: Flujos de información formalmente definidos.
Nombre Flujos de información formalmente definidos
Referencia CTL-PAD-001
Enunciado La arquitectura de datos describe completamente las estructuras y la

conexión de la información del negocio vía flujos de datos.
Fundamento Un correcto diseño de los flujos de información de la empresa contribuye

al proceso de toma de decisiones estratégicas y entrega del servicio.
Implicaciones • Garantizar que las necesidades de datos e información del negocio

sean claramente comunicadas.
• Documentar los flujos y vínculos de información para asegurar el
entendimiento de los propietarios de los datos.
• Establecer un proceso formal de administración de datos.
• Organizar la información de acuerdo a procesos, métodos y
estándares arquitectónicos.
• Implementar herramientas de gestión de contenidos empresariales
(ECM - Enterprise content management).

Adaptado de Gómez.
297
Tabla 91: Principio de datos: Alineación con las necesidades del negocio.
Nombre Alineación con las necesidades del negocio
Enunciado La arquitectura de datos asegura que los requerimientos de información

estén debidamente alineados e integrados con el cumplimiento de las
necesidades del negocio.
Fundamento La utilización adecuada de la información, siendo ésta completa y

precisa, apoyará sustancialmente en el manejo eficiente de la empresa.
Implicaciones • Colaborar y participar con el área de negocios de la empresa para

reforzar los requerimientos de información.
• Modelar y diseñar la arquitectura de datos utilizando un enfoque
arquitectónico “arriba-abajo”.

Adaptado de Gómez.
Tabla 92: Principio de datos: Claridad y consistencia.
Nombre Claridad y consistencia
Enunciado La arquitectura de datos fomenta la calidad de los datos a través de

definiciones claras y consistentes.
Fundamento La utilización adecuada de la información completa y precisa, apoyará

sustancialmente en el manejo eficiente de la empresa.
Implicaciones • Establecer una taxonomía de términos comunes que se adhiera a los

repositorios de información de la empresa.
• Definir estándares de información para mejorar la calidad, integridad
y confiabilidad.

Adaptado de Gómez.
298
Tabla 93: Principio de datos: Toma de decisiones.
Nombre Toma de decisiones
Enunciado La arquitectura de datos proporciona un marco básico para la explotación

de la información y toma de decisiones.
Fundamento Una eficiente gestión de la información posibilita la creación de ventajas

competitivas y constituye un soporte para la toma de decisiones
empresarial. A través de técnicas de explotación de información, la
empresa podrá tomar decisiones de inversión estratégicas basadas en
datos, y por lo tanto, con menor riesgo.
Implicaciones • Efectuar un diagnóstico de la situación actual de los datos.

• Evaluar la posibilidad de incorporar nuevas fuentes de datos.
• Implementar técnicas de explotación de información como Big data
analytics.

Adaptado de Gómez.
6 Principios de aplicaciones.
Tabla 94: Principio de aplicaciones: Arquitectura de aplicaciones.
Nombre Arquitectura de aplicaciones
Referencia CTL-PAA-001
Enunciado La arquitectura de aplicaciones es un factor importante para el

aseguramiento de calidad de los sistemas corporativos.
Fundamento La arquitectura de aplicaciones tiene un impacto directo sobre la

capacidad de los sistemas para satisfacer atributos de calidad. Además,
gracias a la reutilización de diseños arquitectónicos posibilita la reducción
de costos en la construcción de soluciones informáticas.
Implicaciones • Capturar, documentar y priorizar los requerimientos necesarios para

la elección y diseño de la arquitectura.
• Adopción de estándares y modelos para el proceso de descripción
arquitectónica.
• Implementar herramientas para el diseño y validación de la
arquitectura.

Adaptado de Gómez.
299
Tabla 95: Principio de aplicaciones: Trazabilidad.
Nombre Trazabilidad
Enunciado La arquitectura de aplicaciones debe garantizar la puesta en marcha de los

Fundamento El enunciado anterior permitirá:

• Definir procesos que garanticen la disponibilidad de la información.
• Alinear el negocio.
• Ser flexible ante los cambios.
• Facilitar la transformación de la arquitectura de negocio.
• Posibilitar la trazabilidad de requerimientos del negocio.
• Minimizar las inconformidades en los requerimientos.
Implicaciones • Implementar modelos, técnicas y estándares para la identificación y

especificación de requerimientos de software.
• Documentar adecuadamente los requisitos de las partes interesadas.

Adaptado de Gómez.
Tabla 96: Principio de aplicaciones: Flexibilidad.
Nombre Flexibilidad
Enunciado La arquitectura de aplicaciones debe ser altamente modular, multi-capas y

flexible.

• Optimizar la agilidad.
• Minimizar la complejidad de integración.
• Simplificar la implementación, despliegue y mantenimiento.
• Mejorar la escalabilidad, capacidad de actualización, compatibilidad.
• Facilitar y mejorar la mantenibilidad.
• Permitir cambios en la plataforma tecnológica con efectos mínimos en
los procesos de negocio.
Implicaciones • Evaluar la necesidad de implementar estrategias de empresa orientada a

servicios.
• Asegurar que las aplicaciones que soportan el negocio estén diseñadas
bajo patrones arquitectónicos y estén orientadas a arquitecturas
basadas en componentes (CBA), servicios (SOA), móviles y en la nube
(Cloud computing).

Adaptado de Gómez.
300
Tabla 97: Principio de aplicaciones: Consolidación.
Nombre Consolidación
Enunciado La arquitectura de aplicaciones debe promover primero la consolidación

de aplicaciones y luego la integración.
• Reducir costos.
• Reducir la complejidad de integración.
• Minimizar duplicidad de soluciones.
• Simplificar el mantenimiento y soporte de aplicaciones.
Implicaciones • Efectuar un diagnóstico de la situación actual de las aplicaciones

corporativas.
• Realizar un análisis de ajuste y costo-beneficio.

Adaptado de Gómez.
Tabla 98: Principio de aplicaciones: Orientada a la integración.
Nombre Orientada a la integración.
Enunciado La arquitectura de aplicaciones debe reducir la complejidad de la

integración e incrementar la simplicidad de las aplicaciones.
Fundamento Esto permitirá:
• Reducir costos.
• Agilizar los procesos de negocio.
• Disminuir el soporte y mantenimiento de aplicaciones.
• Reducir al máximo la duplicidad de sistemas
• Incrementar la flexibilidad de las aplicaciones.
Implicaciones • Asegurar que las aplicaciones que soportan el negocio implementen

estándares arquitectónicos y desarrollen interfaces con bajo
acoplamiento.
• Desarrollar un plan de integración de aplicaciones.
• Definir puntos de integración de aplicaciones.

Adaptado de Gómez.
301
Tabla 99: Principio de aplicaciones: Orientada al servicio.
Nombre Orientada al servicio.
Enunciado La arquitectura de aplicaciones debe seguir un enfoque orientado a servicios

(SOA) y en la nube (Cloud computing).

• Mejorar la agilidad del negocio.
• Mejorar la prestación de servicios.
• Soportar la transformación de servicios.
• Crear oportunidades para la integración de servicios.
• Reducción potencial de costos de activos de TI.
• Promover interoperabilidad.
• Ubicuidad.
Implicaciones • Considerar SOA como una iniciativa integral, no centrada en la

tecnología.
• Efectuar un análisis del inventario de servicios.
• Planificar la migración de componentes tecnológicos a servicios en la
nube.

Adaptado de Gómez.
Tabla 100: Principio de aplicaciones: Interoperabilidad.
Nombre Interoperabilidad
Enunciado La arquitectura de aplicaciones debe permitir la interoperabilidad.

• Soportar iniciativas inter-empresariales de colaboración.
• Ayudar a que la empresa sea vista como una empresa consolidada.
• Facilitar la consolidación de funciones similares.
• Facilitar el intercambio de información entre patrones internos y
externos.
• Soportar procesos de racionalización.
• Reducir costos.
Implicaciones • Verificar que las aplicaciones que soportan el negocio manejen

interfaces estándar y apliquen normas de seguridad o de la industria.
• Adoptar estándares abiertos para asegurar la interoperabilidad de las
aplicaciones.

Adaptado de Gómez.
302
Tabla 101: Principio de aplicaciones: Acceso a la información.
Nombre Acceso a la información.
Referencia CTL-PAA-008.
Enunciado La arquitectura de aplicaciones debe garantizar el acceso a los datos sin

importar su residencia o formato para su consumo y análisis.
Fundamento En la actualidad es indispensable contar con la habilidad de analizar

dinámicamente la información que se produce para poder realizar
predicciones sobre posibles resultados. Por esta razón, las aplicaciones
corporativas y procesos consumidores deben tener acceso transparente
a la información que necesitan, cuando la necesitan y en el formato
requerido.
Implicaciones • Implementar componentes de integración de datos que permitan un

acceso ágil a la información, esté donde esté y de manera
independiente de la arquitectura de datos.
• Implementar un bus de servicios empresariales (ESB) que se
encargue de la publicación para consumo público y de la traducción
de formatos y protocolos de mensajes.

Adaptado de Gómez.
Tabla 102: Principio de aplicaciones: Soluciones de código abierto.
Nombre Soluciones de código abierto.
Enunciado Las aplicaciones que soportan el negocio deberán estar implementadas

en plataformas de código abierto.
Fundamento Las aplicaciones de código abierto permiten:
• Reducir costos de licencias y mantenimiento de las aplicaciones.

• Promover la interoperabilidad.
• Ofrecer flexibilidad a los diversos entornos operativos y componentes
tecnológicos.
Implicaciones • Planificar la migración de aplicaciones y sistemas a tecnologías de

código abierto.

Adaptado de Gómez.
303
Tabla 103: Principio de aplicaciones: Maximizar el retorno y minimizar el riesgo.
Nombre Maximizar el retorno y minimizar el riesgo
Enunciado La arquitectura de aplicaciones debe tener un enfoque de cartera para el

análisis, planificación, gobierno y optimización de las aplicaciones
empresariales.
• Optimizar las inversiones que se realizan en la compra de

aplicaciones.
• Mejorar la planificación de aplicaciones.
• Mejorar la gestión de activos de TIC's.
Implicaciones • Reducir el número de aplicaciones.

• Garantizar la implementación de un enfoque de planificación y
priorización de aplicaciones en la empresa.

Adaptado de Gómez.
Tabla 104: Principio de aplicaciones: Sistemas legados.
Nombre Sistemas legados
Enunciado La arquitectura de aplicaciones debe anticipar y planificar el reemplazo y

transición de las aplicaciones legadas.
• Reducir al mínimo la probabilidad y riesgo de mantener aplicaciones

que son funcionalmente deficientes.
• Reducir la probabilidad de que la implementación de soluciones sean
costosas y de difícil mantenimiento.
• Facilitar una postura receptiva de la empresa en cuanto a TIC's, que
pueda responder a los requisitos cambiantes a través del tiempo.
Implicaciones • Establecer estrategias de renovación de sistemas legados.

• Desarrollar un esquema de prioridades para reemplazar sistemas
obsoletos, legados y redundantes.

Adaptado de Gómez.
304
Tabla 105: Principio de aplicaciones: Disponibilidad de documentación.
Nombre Disponibilidad de documentación
Enunciado La arquitectura de aplicaciones y los sistemas deben ser

documentados comprensivamente.
• Facilitar la transformación de la arquitectura de negocios.

• Mejorar la trazabilidad de los requerimientos de negocio.
• Minimizar potenciales desajustes entre requerimientos
• Soportar el mantenimiento futuro del sistema.
Implicaciones • Asegurar la adherencia de la práctica arquitectónica en la creación

de artefactos.
• Garantizar que el diseño de aplicaciones refleje la utilización de
principios arquitectónicos de aplicaciones, prácticas y estándares.

Adaptado de Gómez.
Tabla 106: Principio de aplicaciones: Seguridad.
Nombre Seguridad
Enunciado Las aplicaciones deben cumplir con requerimientos arquitectónicos de

seguridad.

• Alinear las aplicaciones con las políticas, normas y procedimientos
de seguridad.
• Facilitar la transformación de los requisitos de seguridad.
• Mejorar la trazabilidad de los requisitos de seguridad.
• Reducir al mínimo los riesgos de seguridad.
Implicaciones • Garantizar que las aplicaciones reflejen principios de seguridad

arquitectónica, prácticas y estándares.
• Planificar la ejecución de controles internos que posibiliten la
identificación de riesgos de seguridad.

Adaptado de Gómez.
305
7 Principios de tecnología.
Tabla 107: Principio de tecnología: Responsables.
Nombre Responsables.
Referencia CTL-PAT-001
Enunciado Todos los modelos, patrones, planos, componentes, servicios y

tecnologías identificadas deberán tener propietarios; ellos, serán
responsables de la planificación, gestión, administración y apoyo.
Fundamento Es necesario que se garantice la rendición de cuentas para todos los

servicios, patrones, modelos y componentes tecnológicos.
Implicaciones • Definir nuevos roles y responsabilidades de propiedad según sea

necesario. (Quién).
• Identificar servicios, patrones, modelos y componentes tecnológicos
a utilizar. (Qué).

Adaptado de Gómez.
Tabla 108: Principio de tecnología: Modelo empresarial de integración tecnológica.
Nombre Modelo empresarial de integración tecnológica
Enunciado Es imprescindible contar con modelos empresariales de integración

tecnológica que definan los conceptos arquitectónicos básicos: diseños,
planos, componentes, servicios, niveles de calidad, catálogos, carteras
de infraestructura, etc., así como sus interrelaciones.
Fundamento Un modelo empresarial de integración tecnológica permite:

• Establecer un vocabulario común.
• Ofrecer una visión integral de la infraestructura tecnológica de la
empresa.
Implicaciones • Comunicar y actualizar el modelo.

Adaptado de Gómez.
306
Tabla 109: Principio de tecnología: Enfoque de métricas de nivel de calidad.
Nombre Enfoque de métricas de nivel de calidad
Enunciado Las implementaciones tecnológicas requieren discusiones que deben

ocurrir tan pronto como sea posible, entre los accionistas de la empresa y
las partes interesadas, incluyendo a: arquitectos de aplicaciones,
arquitectos de tecnología, proveedores de servicios y personal de
operaciones y mantenimiento. Como resultado de estas negociaciones,
se deberán definir métricas de nivel de calidad integrales e incluir las
siguientes categorías y aspectos.
• Convencional.
◦ Escalabilidad.
◦ Disponibilidad.
◦ Recuperabilidad.
• Extendidas.
◦ Seguridad.
◦ Integridad.
◦ Integrabilidad.
◦ Usabilidad.
◦ Confiabilidad.
◦ Compatibilidad.
◦ Asequibilidad.
• Adaptabilidad.
◦ Reusabilidad.
◦ Capacidad de actualización incremental para cualquier nivel de
calidad.
◦ Capacidad de cambiar lógica de presentación.
Fundamento La inclusión de métricas de nivel calidad permite:
• Facilitar la obtención de requerimientos no funcionales.

• Mejorar el proceso de obtención de requisitos de parte de los
interesados.
• Mejorar la calidad de los sistemas.
• Mejorar el acceso a las infraestructuras de aplicaciones.
• Mejorar la seguridad y protección de la privacidad.
Implicaciones • Asegurar que los procesos de: selección de productos, registro de

proveedores, planificación y recopilación de requisitos, cuenten con
métricas de nivel de calidad.
• Adoptar y documentar métricas de nivel de calidad en la
implementación de soluciones, servicios e infraestructura.

Adaptado de Gómez.
307
Tabla 110: Principio de tecnología: Mantenimiento de la infraestructura.
Nombre Mantenimiento de la infraestructura.
Enunciado El mantenimiento de la infraestructura, con excepción de reparaciones

críticas, deberá estar previamente planificado; así como nuevas
iniciativas de despliegue de aplicaciones y tecnologías.
Fundamento Planificar el mantenimiento de la infraestructura permitirá:
• Reducir costos de mantenimiento.

• Reducir el riesgo de la infraestructura sin soporte, que puede dar
lugar a que el tiempo de inactividad no planificado sea significativo.
Implicaciones • Definir estrategias de mantenimiento preventivo de los componentes

tecnológicos de la empresa.
• Comunicar la estrategia con el grupo de interés.

Adaptado de Gómez.
Tabla 111: Principio de tecnología: Racionalización de productos y plataforma.
Nombre Racionalización de productos y plataforma
Enunciado La arquitectura tecnológica debe asegurar la racionalización de la

variedad de productos y plataformas de TIC's.
Fundamento La racionalización posibilitará:
• Minimizar la diversidad tecnológica.

• Reducir costos de inversión y mantenimiento de TIC's.
• Incrementar la interoperabilidad entre productos y plataformas,
eliminando islas tecnológicas.
Implicaciones • Seleccionar e implementar estándares tecnológicos.

• Definir una hoja de ruta para la migración del entorno actual de TIC's
hacia un conjunto reducido de tecnologías.
• Evaluar potenciales cambios en tecnologías y aplicaciones.
• Vincular a este principio: políticas, normas y procedimientos que
gobiernen la adquisición de tecnologías.

Adaptado de Gómez.
308
Tabla 112: Principio de tecnología: Selección de productos.
Nombre Selección de productos.
Enunciado Los productos se seleccionan con respecto a la optimización de las métricas

de nivel de calidad. La tecnología, uniformidad, capacidad de integrarse con
los sistemas existentes, costos, criterios de seguridad y requisitos de
privacidad también deben ser considerados.
Fundamento Una adecuada selección de productos posibilitará:

• Reducir la complejidad, costos y riesgos del entorno tecnológico.
• Minimizar los costos de integración y administración de sistemas.
• Consolidar relaciones con proveedores.
• Proteger los activos críticos y aumentar el nivel de confianza en la
prestación de servicios.
Implicaciones • Incluir criterios de integración en los procesos de evaluación y selección

de tecnologías. *
* La selección de tecnologías podría verse limitada.

Adaptado de Gómez.
Tabla 113: Principio de tecnología: Portafolio de productos.
Nombre Portafolio de productos.
Enunciado Es necesario la adopción de un enfoque de cartera en la planificación y

gestión de los productos de TIC's, incluyendo software, hardware e
infraestructura.
Fundamento El enfoque de cartera permite:
• Mejorar la planificación, gestión, evaluación de riesgos y la flexibilidad de

satisfacer las cambiantes necesidades del negocio.
• Reducir complejidad y costos de mantenimiento.
• Reducir el riesgo global para el negocio.
Implicaciones • Definir e implementar un proceso de gestión del ciclo de vida de

productos de TIC's.
• Incluir el costo de mantenimiento de los productos, versiones soportadas
y gastos de migración en los casos de negocio.

Adaptado de Gómez.
309
Tabla 114: Principio de tecnología: Reutilizar, comprar y luego construir.
Nombre Reutilizar, comprar y luego construir
Enunciado El diseño, ejecución y entrega de la infraestructura se ajustará a los

principios arquitectónicos de tecnología establecidos para la empresa. El
orden de preferencia para la infraestructura y los componentes de la
infraestructura será el de: reutilizar, comprar y luego construir.

• Reducir la complejidad y costos de mantenimiento de la infraestructura.
• Proteger las inversiones existentes de TIC's.
• Incrementar la calidad de las soluciones de TIC's.
• Incrementar la eficiencia y la utilización de recursos de TIC's.
Implicaciones • Definir e implementar un proceso de gestión del ciclo de vida de

productos de TIC's.

Adaptado de Gómez.
Tabla 115: Principio de tecnología: Criterios de seguridad.
Nombre Criterios de seguridad
Enunciado La seguridad y privacidad deben ser diseñadas en los sistemas como parte
integral del proceso de diseño tecnológico. Los sistemas se diseñarán en
base a criterios de robustez y medidas de recuperación ante desastres, con
la intención de asegurar la planificación de la continuidad del negocio.
Fundamento La inserción de criterios de seguridad posibilitará:

• Evitar el incumplimiento de las políticas de seguridad o privacidad.
• Mantener la confianza pública de la empresa.
• Brindar protección contra robos, pérdidas, daños o modificación no
autorizada de los activos de TIC's.
• Asegurar que los servicios críticos del área de programas y sistemas
estén disponibles, gracias a un plan de recuperación o contingencia.
Implicaciones • Determinar los requerimientos de seguridad y privacidad con las partes

interesadas, en base a políticas y necesidades del negocio.
• Desarrollar un modelo de seguridad consistente, confiable y eficaz.
• Exigir procesos de seguridad y de administración de la privacidad.
• Utilizar mecanismos de evaluación para identificar amenazas y riesgos;
así como controles de selección que satisfagan los objetivos de control.

Adaptado de Gómez.
310
ANEXO 19: Evaluación de capacidades.
311
Evaluación de capacidades

2016
312
Evaluación de las capacidades del negocio........................................................................315
Evaluación de las capacidades de TI..................................................................................319
Evaluación de la madurez arquitectónica............................................................................324
Evaluación de la preparación de transformación del negocio..............................................329
313
Nombre del
proyecto

por documento

Título Evaluación de capacidades. 2016-10-04
documento
Fecha
de fin
En
revisión.

1.0 2016-10-04 CTL-FVA-EVC_v0.1
314
Antes de embarcarse en una detallada definición de la arquitectura, es valioso comprender

el nivel de capacidad de las líneas base y objetivo de la empresa. Esta evaluación de la
capacidad puede ser examinada en varios niveles:
 ¿Cuál es el nivel de capacidad de la empresa en su conjunto?. ¿Dónde la empresa

desea aumentar u optimizar la capacidad?. ¿Cuáles son las áreas de enfoque
arquitectónico que apoyarán el desarrollo deseado de la empresa?.
 ¿Cuál es el nivel de capacidad o madurez de la función de TI dentro de la empresa?.

¿Cuáles son las posibles consecuencias de la realización del proyecto arquitectónico
en términos de gobernanza de diseño, gobernanza operativa, habilidades y estructura
de la organización?. ¿Cuál es el estilo apropiado, nivel de formalidad, y cantidad de
detalle del proyecto para encajar con la cultura y la capacidad de TI de la
organización?.
 ¿Cuál es la capacidad y la madurez de la función arquitectónica dentro de la empresa?.

¿Qué bienes arquitectónicos se encuentran actualmente en existencia?. ¿Son
mantenidos y precisos?. ¿Qué normas y modelos de referencia deben tenerse en
cuenta?. ¿Hay probabilidades de que sean oportunidades para crear activos
reutilizables durante el proyecto arquitectónico?.
 Cuando existan brechas de capacidad, ¿en qué medida está el negocio listo para
transformarse con la finalidad de alcanzar la capacidad destino?. ¿Cuáles son los
riesgos para la transformación, las barreras culturales, y otras consideraciones que
deben abordarse más allá de la brecha de capacidad básica?.
2 Evaluación de las capacidades del negocio.
Para evaluar las capacidades del negocio se pueden implementar dos tipos de métodos, a
través de los cuales se determinará si las diversas áreas del negocio se encuentran en la
capacidad de adaptarse a una arquitectura empresarial.
315
 Métodos cualitativos: Este tipo de métodos emplea cuestionarios y exámenes los
mismos que proveen conclusiones cualitativas sobre los objetivos evaluados.
 Métodos cuantitativos: Son enfoques más retrospectivos y se basan en mediciones
cuantitativas que se llevan a cabo durante la fase de implementación.
Para la presente evaluación se hará uso de métodos cualitativos, debido a que es el

método más adecuado en la etapa de inicio del desarrollo arquitectónico.
2.1 Capacidad de negocio de línea base.
La obtención de la capacidad de negocio de línea base se la efectuará mediante la

resolución de la siguiente evaluación, que abarca los puntos más importantes del negocio de
una empresa.
Tabla 116: Modelo de evaluación de la capacidad del negocio.
Subdo Parcial
Ítem Sí No
minio mente
1. ¿La planificación estratégica de la empresa se

Motivación
encuentra validada y actualizada?.
2. ¿Se identifican y definen proyectos para alcanzar

los objetivos propuestos en la planificación
estratégica?.
3. ¿Se realizan seguimientos periódicos de la práctica

de los planes y estrategias?.
4. ¿Se han validado los modelos de negocio,

operativo, organizacional, econométrico, contable y
de gestión de riesgos de la empresa?.
5. ¿Se implementan herramientas para el

diseño/validación de los modelos de la empresa?.
6. ¿Se garantiza que las estrategias corporativas se

cumplan a nivel operacional?.
7. ¿Dentro de la organización se implementan

indicadores de desempeño?.
8. ¿Los procesos que soportan el negocio están

formalmente definidos?.
316
Subdo Parcial
Ítem Sí No
minio mente
9. ¿La organización emplea técnicas, métodos o

Funciones
estándares para la definición de procesos de

negocio?.
10. ¿Los procesos de negocio ofrecen un

comportamiento flexible y adaptable?.
11. ¿Los procesos de negocio están diseñados

adoptando un enfoque orientado al cliente?.
12. ¿Se diseña procesos de negocio independientes

de la tecnología?.
13. ¿Se definen propietarios para cada uno de los

procesos?.
14. ¿La empresa alinea los procesos de negocio con la

estrategia?.
15. ¿Cuenta la empresa con un sistema de gestión de

procesos de negocio para: definir, actualizar, medir,
analizar y mejorar de manera continua los
procesos?.
16. ¿Se ha implementado un motor de reglas de

negocio completo y escalable con capacidad de
edición en línea y soporte completo?.
17. ¿Se ha validado los perfiles profesionales del

Organización
personal?.
18. ¿El personal de la institución conoce las estrategias

y planes de la empresa, cómo les afectan y cuál
debe ser su aporte a los mismos?.
19. ¿Cuenta la organización con canales de

información formales e informales?
20. ¿Cuenta la empresa con políticas de atención y

orientación al cliente formalmente definidas, que
permitan la evaluación de la calidad de los servicios
prestados?.
Como se puede observar en la anterior evaluación, la capacidad actual de negocio de la

Cooperativa de transportes Loja es débil. En cuanto a procesos, la Cooperativa de
317
transportes Loja aún no ha desarrollado una definición formal de los mismos. Tampoco
utiliza herramientas de automatización o gestión de procesos que permitan evaluar el
rendimiento y así realizar mejoras continuas sobre los servicios de negocio que ofrece la
institución. Además, se carece de una definición actualizada de las competencias laborales
para cada rol de la empresa.
Es evidente también, la falta de adopción de estándares y modelos específicos propuestos

por la industria. De la misma forma, es imperante la reestructuración de los mecanismos de
comunicación tanto interna como externa de la empresa.
2.2 Capacidad de negocio destino.
La capacidad de negocio destino es establecida a partir de los puntos que aún no se han
implementado o se los ha realizado parcialmente y se rige a los principios arquitectónicos de
la empresa. Por lo tanto, una vez desarrollado el trabajo arquitectónico dentro de la
Cooperativa de transportes Loja, además de madurar las fortalezas que tiene actualmente,
la empresa deberá desarrollar los siguientes aspectos:
• Definir claramente mecanismos de comunicación externa e interna.

• Establecer roles y responsabilidades.
• Adoptar estándares para la definición de procesos de negocio.
• Adoptar un enfoque orientado al cliente para el diseño de procesos de negocio.
• Definir procesos de negocios flexibles y adaptables.
• Implementar modelos de negocio específicos de la industria.
• Implementar sistemas de gestión y automatización de procesos.
• Implementar sistemas de gestión de relaciones con el cliente.
• Implementar un motor de reglas de negocio completo.
• Elaborar estrategias para asegurar el cumplimiento de los planes estratégicos de la
empresa.
• Establecer indicadores de rendimiento para la mejora continua de procesos.
318
3 Evaluación de las capacidades de TI.
3.1 Capacidades de TI de línea base.
La obtención de las capacidades de TI de línea base se efectuará mediante la resolución de

la siguiente evaluación, que abarca los puntos más importantes de las áreas de datos,
aplicaciones e infraestructura tecnológica de una empresa.
Tabla 117: Modelo de evaluación de las capacidades de TI.
Subdominio Ítem Sí No Parcialmente
Datos
1. ¿La empresa cuenta con un modelo que defina los

Modelo de datos
componentes físicos y lógicos de datos?.
2. ¿Los flujos y necesidades de información de la

empresa se encuentran formalmente definidos?.
3. ¿Los requerimientos de información se encuentran

alineados con las necesidades del negocio?.
4. ¿Existe una taxonomía común de términos

empresariales?.
5. ¿Cuenta la empresa con datos consistentes, claros y

Gestión de la información
precisos?.
6. ¿Existen estrategias que aseguren la integridad,

accesibilidad y disponibilidad de información?.
7. ¿Existe un modelo de gestión de requerimientos de

información?.
8. ¿La empresa posee estándares para la gestión de la

información?.
9. ¿La empresa accede a los datos sin importar su

residencia o formato para su consumo?.
10. ¿La información apoya la toma de decisiones

empresarial?.
319
Aplicaciones.
11. ¿Las aplicaciones que soportan el negocio están

Arquitectura de aplicaciones
diseñadas bajo patrones arquitectónicos, normas y

estándares?.
12. ¿Las aplicaciones corporativas hacen uso de

conceptos de arquitecturas basadas en
componentes, servicios y en la nube?.
13. ¿Existen políticas en el diseño de aplicaciones, que

promuevan la reutilización de componentes?.
14. ¿Se han desarrollado interfaces estándar y puntos

de integración para las aplicaciones corporativas?.
15. ¿Se han adoptado estándares abiertos que

aseguren la interoperabilidad de aplicaciones?.
16. ¿Existe planificación para la integración de las

aplicaciones que soportan el negocio?.
17. ¿Se ha implementado un bus de servicios

empresariales (ESB) que se encargue de la
publicación para consumo público, traducción de
formatos y protocolos de mensajes?.
18. ¿Las aplicaciones corporativas soportan iniciativas

inter-empresariales de colaboración?.
19. ¿Las aplicaciones corporativas están disponibles

para los usuarios móviles?.
20. ¿Las aplicaciones corporativas cuentan con

documentación clara y precisa?.
21. ¿Existen estrategias de renovación de sistemas

Administración
legados?.
22. ¿Los cambios en la plataforma tecnológica tienen

efectos mínimos en los procesos de negocio?.
23. ¿Cuenta la empresa con un enfoque de planificación

y priorización de aplicaciones?.
24. ¿Se prioriza la compra de software antes que la

construcción del mismo?.
320
25. ¿Se ha planificado la ejecución de controles internos
que permitan identificar vulnerabilidades y evaluar el
rendimiento de los sistemas?.
26. ¿Se han establecido políticas de control de acceso a

las distintas aplicaciones de la empresa?.
Infraestructura tecnológica.
27. ¿Existe un modelo empresarial de integración

Modelo de integración tecnológica
tecnológica que defina diseños, planos,

componentes, servicios, niveles de calidad,
catálogos, carteras de infraestructura, etc., así como
sus interrelaciones?
28. ¿Existen responsables formalmente definidos de la

planificación, gestión y administración de activos
tecnológicos?.
29. ¿Cuenta la empresa con métricas de nivel de calidad

para la implementación de soluciones, servicios e
infraestructura?.
30. ¿En el proceso de diseño tecnológico se considera

la seguridad y privacidad como parte integral de los
sistemas?.
31. ¿Existe un modelo de seguridad consistente,

confiable y eficaz para todos los activos tecnológicos
de la empresa?.
32. ¿Se consideran criterios de integración en los

procesos de evaluación y selección de tecnologías?.
33. ¿Se ha desarrollado un inventario de activos

Administración
tecnológicos de la empresa?.
34. ¿Existen estrategias de planificación para el

mantenimiento y despliegue de infraestructura
tecnológica?.
35. ¿Se han definido políticas de racionalización de

productos y plataformas tecnológicas?.
36. ¿Se ha establecido un proceso de gestión del ciclo

de vida de productos tecnológicos?.
321
3.1.1 Capacidad de datos de línea base.
• Los flujos de información no se encuentran formalmente definidos.

• Ausencia de estándares para la gestión de información.
• No se ha elaborado una taxonomía de términos comunes.
• No existe un procedimiento para la gestión de requerimientos de información.
3.1.2 Capacidad de aplicaciones de línea base.
• Las aplicaciones que soportan el negocio no están construidas en base a un modelo

de referencia técnico ni bajo políticas de diseño establecido por la empresa.
• No se han efectuado controles internos que determinen el rendimiento y
vulnerabilidades de los sistemas.
• Se prioriza la compra antes que la construcción del software.
• Ausencia de políticas de control de acceso a los distintos sistemas.
• No existen estrategias para la renovación de sistemas legados.
• Los sistemas con los que cuenta la empresa actualmente no aseguran la adopción
de la tendencia tecnológica SMAC (social, móvil, analytics, cloud).
3.1.3 Capacidad de tecnología de línea base.
• No existen responsables formalmente definidos para la gestión de los activos.

• No existen estrategias documentadas para el mantenimiento y despliegue de la
infraestructura tecnológica.
• No se han adoptado métricas de nivel de calidad para la implementación de servicios
e infraestructura tecnológica de la empresa ni se han definidos políticas de
racionalización de productos y plataforma tecnológica.
• No se ha establecido un proceso de gestión del ciclo de vida tecnológico.
• No existe un modelo de seguridad consistente, confiable y eficaz para todos los
activos tecnológicos.
322
3.2 Capacidades de TI destino.
3.2.1 Capacidad de datos destino.
La arquitectura de datos destino deberá asegurar el cumplimiento de:
• Definición de estrategias que aseguren la consistencia, integridad, accesibilidad y

disponibilidad de la información.
• Elaboración de un modelo de gestión de requerimientos de información.
• Alineación de los requerimientos de información con las necesidades del negocio.
• Utilización de medidas de seguridad para la protección de los datos.
3.2.2 Capacidad de aplicaciones destino.
La arquitectura de aplicaciones destino deberá asegurar el cumplimiento de:
• Auditoría a los sistemas que soportan el negocio, para asegurar el cumplimiento de:
◦ Diseño en base a patrones arquitectónicos y conceptos de arquitecturas basadas
en componentes, servicios y orientadas a la nube.
◦ Utilización de estándares abiertos que aseguren la interoperabilidad de
aplicaciones.
◦ Definición de interfaces estándares y puntos de integración para posibilitar el
soporte a iniciativas empresariales de colaboración.
◦ Reutilización de componentes.
◦ Disponibilidad para usuarios móviles.
◦ Documentación clara.
• Implementación de un bus de servicios empresariales.

• Adopción de un enfoque de planificación y priorización de aplicaciones.
• Definición de estrategias para la renovación de sistemas legados.
• Ejecución de controles internos periódicos para la detección de vulnerabilidades en
los sistemas y evaluar el rendimiento de los mismos.
• Especificación de políticas de control de acceso a las distintas aplicaciones.
323
3.2.3 Capacidad de tecnología destino.
La arquitectura de tecnología destino deberá asegurar el cumplimiento de:
• Definición de un modelo integral para la selección, despliegue y mantenimiento de

los activos tecnológicos; en el cual se adopten métricas de nivel de calidad y
aspectos de seguridad.
• Establecer políticas de racionalización de productos y plataforma tecnológica, que
aseguren que las adquisiciones de infraestructura tecnológica estén directamente
ligadas con la consecución de un objetivo estratégico de la empresa.
• Documentar el proceso de gestión del ciclo de vida de los activos tecnológicos y
especificar los responsables para el cumplimiento del mismo.
4 Evaluación de la madurez arquitectónica.
Para realizar la evaluación de la madurez arquitectónica, se ha tomado como referencia el

marco US DoC ACMM realizado por el Departamento de comercio de Estados Unidos. El
principal objetivo de este marco es la identificación de áreas débiles para proveer una ruta
definida de evolución en pro de la mejora del proceso arquitectónico.
US DoC ACMM analiza 9 características de la empresa:
a) Procesos arquitectónicos.
b) Desarrollo arquitectónico.
c) Alineación con el negocio.
d) Participación de la alta dirección.
e) Participación de la unidad operativa.
f) Comunicación de la arquitectura.
g) Seguridad de TI.
h) Gobernanza arquitectónica.
i) Inversión en TI y estrategias de adquisición.
324
Tabla 118: Modelo de madurez de la capacidad arquitectónica (ACMM).
Nivel Denominación Elementos arquitectónicos
0 Ninguno No existe una arquitectura empresarial de la cual tratar.
1 Inicial 1. Los procesos son ad-hoc y locales. Algunos procesos de

arquitectura empresarial son definidos. No hay procesos
arquitectónicos unificados a través de tecnologías o procesos de
negocio. El éxito depende de los esfuerzos individuales.
2. Los procesos de arquitectura empresarial, documentación y

normas están definidos informalmente.
3. Vinculación mínima o implícita a las estrategias de negocio o

impulsores de negocio.
4. Limitada participación de los directivos en el trabajo

arquitectónico.
5. Aceptación limitada de la unidad operativa del proceso de

6. Poca comunicación respecto del trabajo arquitectónico.
7. Las consideraciones de seguridad de TI son ad-hoc y locales.
8. No se evidencia gobernanza de normas arquitectónicas.
9. Poca o ninguna participación del personal de planificación y

adquisición en el proceso de arquitectura empresarial. Poca o
ninguna adherencia a estándares existentes.
2 En desarrollo 1. El trabajo arquitectónico está documentado. El proceso

arquitectónico ha desarrollado funciones y responsabilidades
claras.
2. Se ha identificado la visión, principios, alineación estratégica,

arquitecturas de línea base y destino. Existen normas
arquitectónicas, pero no necesariamente vinculadas a la
arquitectura destino. Modelo de referencia técnico (TRM) y perfil
de estándares establecidos.
3. Vinculación explícita a los procesos de negocio.
4. Gestión de concienciación del esfuerzo arquitectónico.
325
5.
6. Puesta en marcha del trabajo. Designación de responsabilidades.
7. Se han compartido los entregables resultantes del trabajo

arquitectónico en el repositorio arquitectónico.
8. Se han definido claramente las funciones y responsabilidades

respecto a seguridad de TI.
9. Gobernanza de algunos estándares arquitectónicos y algunos

que se adhieren al perfil de estándares existentes.
10. Poco o ningún gobierno formal de la inversión en TI. La unidad de

operación demuestra cierta adhesión a perfiles de estándares
existentes.
3 Definido 1. La arquitectura está bien definida y comunicada al personal

involucrado con el trabajo arquitectónico.
2. El análisis de brechas y el plan de migración se han completado.

El TRM y el perfil de estándares han sido totalmente
desarrollados. Se han identificado objetivos y métodos de TI.
3. La arquitectura de TI está integrada con la planificación del

capital y el control de las inversiones.
4. Los altos directivos participan en el trabajo arquitectónico.
5. La mayoría de los elementos de la unidad operativa muestran

aceptación o están participando activamente en el proceso de
6. Los documentos de arquitectura se actualizan con regularidad.
7. Se ha elaborado un perfil arquitectónico de estándares de

seguridad de TI y se integra con la arquitectura empresarial.
8. Gobernanza explícitamente documentada de la mayoría de las

inversiones en TI.
9. Existencia de estrategias de adquisición de TI.
4 Gestionado 1. El trabajo arquitectónico es parte de la cultura organizacional. Las
326
métricas de calidad asociadas con el proceso arquitectónico son

capturadas.
2. La documentación de arquitectura empresarial se actualiza en un

ciclo regular para reflejar la evolución de la arquitectura
empresarial. Las arquitecturas de negocios, datos y tecnología
son definidas por estándares apropiados de facto.
3. La planificación del capital y el control de las inversiones se

ajustan en base a las lecciones aprendidas. Evaluación periódica
de los impulsores del negocio.
4. El personal directivo de la empresa se encuentra altamente

involucrado en la revisión de los procesos arquitectónicos.
5. La unidad operativa ha sido totalmente aceptada y participa

activamente en el proceso de arquitectura de TI.
6. Los documentos de arquitectura se actualizan regularmente y son

revisados con frecuencia para los últimos desarrollos de
arquitectura y estándares.
7. Las métricas de rendimiento asociadas con la arquitectura de

seguridad de TI son capturadas.
8. Gobernanza explícita de todas las inversiones en TI. Procesos

formales para la gestión de las variaciones que retroalimentan la
9. Todas las adquisiciones y compras de TI planificadas son guiadas

y se rigen por la arquitectura empresarial.
5 Medido 1. Esfuerzos ajustados para optimizar y mejorar continuamente los

procesos arquitectónicos.
2. Se utilizan estándares para mejorar el proceso de desarrollo

arquitectónicos.
3. Las métricas de los procesos arquitectónicos se utilizan para

optimizar e impulsar los vínculos comerciales. El negocio está
involucrado en las mejoras de los procesos continuos de
4. El personal directivo se involucra en la optimización y mejoras de

los procesos de desarrollo arquitectónico y gobernanza.
327
5. Retroalimentación sobre todos los procesos arquitectónicos.
6. Los productos arquitectónicos son utilizados para la toma de

decisiones en la organización y para cada decisión de negocios
relacionados con TI.
7. La retroalimentación de las métricas de seguridad de TI se

utilizan para impulsar mejoras en los procesos arquitectónicos.
8. Gobernanza explícita de todas las inversiones en TI.
9. No existen inversiones o actividades de adquisición en TI sin

planificación.
De acuerdo a los criterios presentados en la siguiente figura, se puede establecer que la

Cooperativa de transportes Loja actualmente se encuentra en el nivel 0 : Ninguno, debido a
que aún no existe un trabajo de arquitectura empresarial.
Figura 92: Modelo de madurez de capacidades arquitectónicas (ACMM).

En la Cooperativa de transportes Loja, se aspira a llegar preliminarmente hasta el nivel 3 :

Definido, en el cual la empresa tenga los procesos de arquitectura empresarial debidamente
definidos y documentados, y los estándares bajo los cuales se fundamentará la arquitectura
se describan en el modelo de referencia técnico (TRM).
328
5 Evaluación de la preparación de transformación del negocio.
Para realizar la evaluación de la preparación del negocio, se ha tomado como base el

modelo de madurez de transformación de Business transformation management
methodology (BTM2). A partir de la siguiente figura, se determinará el nivel actual en el que
se encuentra la empresa y el nivel hasta el cual se pretende llegar luego del trabajo
arquitectónico.
Figura 93: Nivel de madurez de BTM2.

Fuente: Business transformation management methodology.
Adaptado de Business transformation management methodology.
329
De acuerdo a la anterior figura, y basándonos en las evaluaciones de capacidades de
negocio y TI, se puede establecer que la Cooperativa de Transportes Loja se encuentra en
el nivel 1 de la escala que define BTM2. Es decir, referente a TI: no existen aplicaciones
integradas ni estrategias que soporten el negocio; referente a procesos: los procesos no se
encuentran debidamente definidos ni adoptan estándares de la industria; y referente a la
organización: se evidencia la falta de políticas globales.
Para el presente trabajo arquitectónico, se sugiere que la Cooperativa de Transportes Loja

alcance el nivel 3 establecido en la escala de BTM2, en el cual se cumpla: estrategias y
soporte global de TI para procesos, adopción de estándares y herramientas para la
automatización de procesos y políticas organizacionales globales bien definidas.
330
ANEXO 20: Visión arquitectónica.
331
Visión arquitectónica

2016
332
Descripción del problema....................................................................................................335
Modelo de procesos............................................................................................................ 338
Modelo arquitectónico resultante.........................................................................................339
Enunciado final de la visión.................................................................................................341
333
Nombre del
proyecto

por documento

Título Visión arquitectónica. 2016-10-04
documento
Fecha
de fin
En
revisión.

1.0 2016-10-04 CTL-FVA-VAA_v0.1
334
La Visión arquitectónica se crea en la fase inicial del ciclo de vida del proyecto y provee una
vista de alto nivel de la arquitectura final del producto. El propósito de la visión es acordar
desde un inicio el resultado deseado del trabajo arquitectónico, por lo tanto, los arquitectos
pueden enfocarse en áreas críticas para validar la factibilidad de la ejecución del proyecto
arquitectónico. La Visión arquitectónica también da soporte a las comunicaciones del
proyecto ofreciendo una versión inicial a nivel de un resumen ejecutivo de la definición
arquitectónica completa.
2 Descripción del problema.
2.1 Enunciado de la visión del negocio.
La Cooperativa de transportes Loja adoptará el modelo de negocios de referencia propuesto

por TOGAF. Este modelo se compone de las siguientes perspectivas:
• Entorno: Esta perspectiva intenta validar el contexto sobre el cual opera el negocio.
Consta de cuatro elementos: contexto del mercado, competidores, clientes y
estrategias. El objetivo de entender el entorno es identificar oportunidades y
debilidades de la empresa en su contexto. La importancia de esta perspectiva es que
permite generar el conocimiento necesario para desarrollar las siguientes cuatro
perspectivas.
• Propuesta de valor: Describe la oferta de servicios producida por la empresa.
Gracias a esta perspectiva se logra establecer la experiencia del cliente y el conjunto
de expectativas de los accionistas. Además, proporciona un conjunto básico de
necesidades a cumplir. El reto de la empresa es generar una propuesta de valor
capaz de atraer una suficiente cantidad de clientes, suplir las necesidades de los
clientes y generar beneficios para los accionistas.
• Modelo operativo: El modelo operativo describe los recursos a disposición que
serán desplegados para generar la propuesta de valor. Un buen diseño del modelo
operativo de la empresa permitirá que la alta dirección evalúe al negocio a través de
varios puntos de vista. El reto de la empresa es identificar un adecuado alineamiento
de los recursos que proveerán la experiencia necesaria al cliente y accionistas.
335
• Riesgos: La perspectiva de riesgos posibilita a la empresa identificar riesgos que
pueden presentarse en la entrega de la propuesta de valor. Brinda un enfoque para
identificar vulnerabilidades externas e internas. Mediante el análisis de riesgos, la
empresa está en capacidad de determinar potenciales escenarios negativos y las
acciones necesarias para manejarlos.
• Cumplimiento: Esta perspectiva describe las actividades que la empresa debe
efectuar para asegurar una correcta entrega de la propuesta de valor. Dicha entrega
debe ser desarrollada mediante estándares de práctica empresarial. El reto de la
empresa es traducir las limitaciones comerciales, de calidad, éticas, legales y
regulatorias en un conjunto de políticas operacionales.
2.2 Diagrama de la visión del negocio.
A continuación, se presenta el diagrama de la visión del negocio:
Figura 94: Modelo de negocio de la CTL.

336
2.3 Impulsores de cambio y oportunidades.
Los impulsores de cambio y oportunidades pueden ser identificados a partir del análisis del
entorno empresarial. Los impulsores que provocan cambios en la empresa son cuatro:
• Contexto del mercado: En el contexto del mercado se consideran las relaciones

con los proveedores, restricciones regulatorias, valor del mercado, costos y
tendencias de la industria. Se ha determinado que:
◦ Se mantienen restricciones arancelarias relacionadas a la prestación de servicios
de transporte.
◦ Existen regulaciones y proyectos de gobiernos locales que dificultan las
operaciones de la empresa.
◦ Alto control gubernamental.
• Competidores: A través de este factor, se analiza a empresas que prestan servicios

similares a los ofrecidos por la empresa. Este factor permite determinar la propuesta
de valor de la competencia. La Cooperativa de transportes Loja debe hacer frente a:
◦ Incremento en la capacidad operativa de la competencia.
◦ Creciente número de instituciones competidoras en transporte intercantonal
• Clientes: Este factor permite el entendimiento de los clientes potenciales y actuales

de la empresa. La importancia de analizar este factor es permitir orientar el diseño de
los servicios a las necesidades del cliente. La Cooperativa de transportes Loja,
sensible a las necesidades de sus clientes, ha emprendido proyectos para innovar la
experiencia de sus usuarios.
• Estrategias: Este factor describe los impulsores y objetivos empresariales,

proporcionando un contexto para las propuestas de valor y el modelo operativo que
las soporta. Con la nueva planificación estratégica de la Cooperativa existen
objetivos que la empresa deberá desarrollar para alcanzar su visión.
A partir de los anteriores impulsores de cambio, se identificaron las siguientes

oportunidades:
337
• Crecimiento poblacional y mayor requerimiento del servicio.
• Normativas que restringen el ingreso de nuevos competidores a ciertas rutas.
• Considerable diferencia entre los servicios prestados y los ofertados por los
competidores.
• La Cooperativa de transportes Loja cuenta con la más grande flota vehicular del país.
• El aparecimiento de nuevas tecnologías permiten la adopción de nuevos modelos de
negocio.
3 Modelo de procesos.
En la actualidad, la Cooperativa de transportes Loja no cuenta con un modelo de procesos

definido.
3.1 Vista general.
A continuación, se describe la cadena de valor de la Cooperativa:
Figura 95: Cadena de valor de la CTL.

338
De acuerdo a la cadena de valor de la Cooperativa de transportes Loja, y tomando en
consideración el servicio de transporte de personas, se establecen los siguientes procesos
de negocio:
• Planificación de turnos: El proceso de planificación de turnos consiste en la gestión

de las frecuencias a desarrollar por las unidades de transporte durante un año.
• Venta de boletos: El proceso de venta de boletos describe la adquisición cupos
disponibles en las unidades de transporte, efectuada en las distintas boleterías de la
empresa a nivel nacional.
• Abordaje: El proceso de abordaje se compone de dos actividades: acceso de los
usuarios a las unidades de transporte y registro del equipaje de los clientes.
• Viaje: El proceso de viaje describe el recorrido de las unidades de transporte.
• Arribo: El proceso de arribo se compone de dos actividades: salida de los usuarios y
la devolución del equipaje de los clientes.
A continuación, se muestra el proceso del segmento de negocio seleccionado para el

presente trabajo arquitectónico:
Figura 96: Proceso de planificación de turnos de la CTL.

Elaboración: Montalván.
4 Modelo arquitectónico resultante.
En este apartado se describirá limitantes del modelo arquitectónico resultante y una breve
descripción de la arquitectura que soportará el negocio.
339
4.1 Limitaciones.
Como se ha descrito anteriormente, las capacidades de negocio y de TI de la Cooperativa

de transportes Loja no están debidamente consolidadas. Tampoco existe una preparación
de la empresa para adoptar proyectos de transformación empresarial. Por lo tanto, las
principales limitaciones identificadas se relacionan con las insuficientes capacidades
empresariales de la organización.
4.2 Arquitectura que soporta el negocio.
Figura 97: Arquitectura destino de la CTL.

Fuente: Romero, F. (2015).
Adaptado de Romero.
A continuación, se describe la arquitectura que soporta la visión del negocio:
340
• Arquitectura orientada a servicios: es un marco de trabajo conceptual que
establece una estructura de diseño para la integración de aplicaciones, que permite a
las organizaciones unir los objetivos de negocio, en cuanto a flexibilidad de
integración con sistemas legados y alineación directa a los procesos de negocio, con
la infraestructura de TI. Está conformada por las siguientes capas
◦ Capa de presentación: Capa que interactúa directamente con el usuario final.

◦ Capa de lógica de negocios: Capa encargada del procesamiento de los datos.
Contiene reglas y directrices del negocio.
◦ Capa de datos: Capa que brinda acceso a los datos. Es utilizada principalmente
por una herramienta de persistencia.
◦ Capa transversal: Capa que contiene características comunes para todas las
capas (seguridad, gestión, comunicaciones).
5 Enunciado final de la visión.
Comprendiendo los beneficios de la alineación estratégica, entre los objetivos del negocio y
las estrategias de TI, surge en la Coooperativa de transportes Loja la necesidad de
emprender un proyecto de transformación tecnológica integral. Como solución a este
proyecto, se ha seleccionado la tendencia tecnológica SMAC (redes sociales, dispositivos
móviles, análisis de datos y computación en la nube) como modelo para soportar innovación
en la prestación del servicio de transporte en la empresa.
En el dominio de negocios, preliminarmente se ha identificado la necesidad de evaluar los

modelos empresariales de la Cooperativa, modelar los procesos de negocio, generar
estrategias de gestión del personal y definir mecanismos de comunicación.
En el dominio de sistemas de información, es imprescindible desarrollar un modelo de datos

empresarial, adoptar un modelo de explotación de la información y diseñar una arquitectura
de aplicaciones orientada a servicios que soporte las aplicaciones corporativas. Finalmente,
en el dominio de tecnología, se planificará un inventario de los activos tecnológicos con los
que cuenta la empresa y se definirá la plataforma tecnológica empresarial.
341
ANEXO 21: Enunciado del trabajo arquitectónico.
342

2016
343
Antecedentes...................................................................................................................... 346
Objetivos y alcance............................................................................................................. 346
Metodologías relevantes y estándares de la industria.........................................................349
Plan de trabajo.................................................................................................................... 350
Riesgos y mitigaciones........................................................................................................355
Criterios de aceptación y procedimientos............................................................................356
344
Nombre del
proyecto

por documento

Título Enunciado del trabajo arquitectónico. 2016-10-04
documento
Fecha
de fin
En
revisión.

1.0 2016-10-04 CTL-VAA-ETA_v0.1
345
Este documento es el Enunciado del trabajo arquitectónico para la Propuesta de marco de

arquitectura empresarial en la Cooperativa de transportes Loja.
El Enunciado del trabajo arquitectónico define el alcance y el enfoque que se utilizará para
completar el proyecto arquitectónico. El Enunciado del trabajo arquitectónico, es por lo
general, el documento por medio del cual el éxito de la ejecución de proyecto arquitectónico
será medido, y puede constituir la base de un acuerdo contractual entre el proveedor y el
consumidor de servicios arquitectónicos. En general, toda la información en este documento
debe ser de alto nivel.
2 Antecedentes.
A continuación, se presentan los antecedentes para el desarrollo del trabajo arquitectónico

en la Cooperativa de transportes Loja.
2.1 Solicitud del proyecto y antecedentes.
La Cooperativa de transportes Loja, a fin de lograr la adopción de nuevos esquemas de

negocio, ha identificado la necesidad de un proyecto de transformación tecnológica integral.
Por lo tanto, el presente trabajo arquitectónico se muestra como una solución válida para
garantizar el éxito del proyecto.
Arquitectura empresarial provee un enfoque que ayuda la alineación entre los objetivos
estratégicos de la empresa y las estrategias de TI. Su implementación en la Cooperativa
permitirá guiar el proceso de transformación tecnológica que requiere la empresa.
Cabe destacar, que no existen trabajos arquitectónicos previos en la empresa.
3 Objetivos y alcance.
A continuación, se describe el objetivo estratégico de la Cooperativa referente a la

tecnología:
346
3.1 Objetivos.
Tabla 119: Objetivos y metas estratégicas de la CTL.
Financiera Garantizar y maximizar la • Mejorar y distribuir de manera

rentabilidad y la excelencia equitativa los ingresos
financiera de la Cooperativa. generados por el servicio A, a
través de la implementación del
sistema caja común
• Definir un modelo
presupuestario que haga del
presupuesto anual un
instrumento no sólo de
mayor transparencia a la
gestión y operación de la
Cooperativa de Transportes
Loja.
• Mejorar la provisión de
servicios a través de la
implantación de una cultura de
procesos que se ejecute en
base a la cadena de valor de la
Cooperativa.
De crecimiento Impulsar proyectos que • Implementar la línea de servicio

garanticen la sostenibilidad y turístico.
liderazgo de la Cooperativa en el • Expandir el servicio AAA hacia
mercado. nuevas rutas que permitan
ampliar la cobertura del
servicio.
imagen de marca a través de
un Plan de marketing.
• Mejorar el servicio y
rentabilidad del transporte y
entrega de carga a través de la
347
transformación integral del área

de encomiendas.
mejoramiento infraestructura
de cada uno de los servicios
ofrecidos.
de las oficinas a nivel nacional
a través del mejoramiento de la
de los servicios de
reparación de carrocerías que
se ofrecen a los socios de la
Cooperativa.
Tecnológica Transformación tecnológica La definición de las metas

integral de la Cooperativa de específicas depende del
Transportes Loja. diagnóstico inicial de TI a
desarrollarse en la Cooperativa de
Transportes Loja.
De formación y Implementar un enfoque moderno • Definir un enfoque de gestión

gestión del talento y de mejores prácticas para la por competencias para la
humano. gestión del capital humano. planificación del recurso
humano
• Disponer de programas de
habiliten tanto a socios,
personal operativo y empleados
en el desempeño de sus
funciones.
Fuente: Cooperativa de Transportes Loja – Planificación estratégica (2016).
Adaptado de Cooperativa de Transportes Loja.
En el dominio tecnológico, la empresa busca dar solución al objetivo de transformar

integralmente la tecnología de la Cooperativa de transportes Loja. Se espera lograr la
alineación de los objetivos estratégicos con el proyecto de transformación y cubrir el 100%
de las áreas de transformación hasta Diciembre de 2020, fecha estipulada para la
finalización del proyecto.
348
3.2 Alcance.

cadena de valor.
4 Metodologías relevantes y estándares de la industria.
Dentro de la industria de transporte, se ha identificado la siguiente metodología para

sistemas de transporte inteligente:
• Sistemas de transporte inteligente (ITS): Proporciona una arquitectura que facilita

el aprovisionamiento de contenidos, aplicaciones y servicios, a través de un enfoque
en donde los usuarios puedan acceder a servicios correspondientes a cada vehículo.
Gracias a este enfoque, se han identificado las siguientes oportunidades:
◦ Modelos de negocio basados en servicios de entrega en la nube.
◦ Nuevas aplicaciones.
◦ Nuevos servicios de valor agregado.
◦ Nuevos actores que puedan obtener estos beneficios.
Esta metodología propone un enfoque conceptual de arquitecturas en la nube

jerárquicas, en donde se aprovecha la creación de nuevos modelos de negocio en
escenarios donde se complementa las capacidades de computación en la nube con
el ecosistema ITS. La arquitectura propuesta está conformada por tres niveles:
◦ Nube local: Los vehículos individual o colectivamente representan un recurso

informático extraordinario, en términos de procesamiento y almacenamiento.
◦ Nubes intermedias: Utilizadas para situaciones en donde se necesite mayor
procesamiento.
◦ Nubes convencionales: Proporcionan una integración efectiva de los recursos
computacionales y almacenamiento distribuido para las partes interesadas.
349
5 Plan de trabajo.
A continuación se detallan los principales aspectos que conforman el plan de trabajo.
5.1 Plan de comunicaciones.
5.1.1 Interesados.
Tabla 120: Interesados del trabajo arquitectónico.
Título Descripción Preocupaciones
Gerente Representante legal de la • Desaprobación del desarrollo del

empresa. Es la persona que tiene proyecto arquitectónico por parte
el poder de la dirección financiera de los demás miembros directivos
y organizativa de la institución. Es de la empresa.
el principal interesado del • Pérdida de dinero y tiempo en el
desarrollo del proyecto desarrollo de proyectos.
Presidente Es la persona responsable de • La implementación del trabajo

dirigir, planificar y controlar las arquitectónico no cumpla con las
actividades de la empresa. metas y objetivos de la institución
en el tiempo estimado.
Consejo de Representantes de los • Tomar decisiones oportunas.

administración accionistas. Son los encargados • Falta de consenso.
de la aprobación de proyectos y
toma de decisiones.
Consejo de Responsables de ejercer • Las decisiones que se realizan

vigilancia funciones de control y vigilancia a sobre el trabajo arquitectónico no
los altos directivos de la reflejen la opinión mayoritaria de
cooperativa. los socios.
Accionistas Propietarios de las unidades de • Implementación de un sistema

transporte. Inversionistas equitativo de caja común.
financieros de la empresa. • Implementación de un adecuado
sistema de planificación de
turnos.
• El trabajo arquitectónico no
incremente la rentabilidad de la
institución.
350
Título Descripción Preocupaciones
Jefe de recursos Dirige, controla y gestiona las • Poco personal capacitado para
humanos actividades referidas a la cumplir con los perfiles requeridos
administración del personal. para el equipo arquitectónico.
Jefe de Implementar, innovar y mantener • Implementación de nuevos

departamento de sistemas de información en base sistemas.
sistemas de a los requerimientos de la • Los equipos que posee la
información empresa. empresa no puedan soportar a la
arquitectura tecnológica destino.
Contador general Registra y procesa las • Incorrecto registro de los ingresos

transacciones económicas de la de cada unidad de transporte.
empresa, elabora informes
periódicos, balances y estados
financieros para analizar la
situación económica y financiera
de la empresa.
Auditor interno Planifica, ejecuta y evalúa • El trabajo arquitectónico no

acciones de auditoría interna para cumpla con estándares de la
todas las áreas de la empresa. industria y normativas legales.
Personal de Responsable de la venta, • Disminución de personal

boletería recepción de boletos y atención al requerido para este cargo.
cliente. • Dificultad en el manejo de nuevos
sistemas.
Personal Equipo de trabajo de la institución • Cambio en las operaciones,

(choferes, asistentes de choferes, procesos y normativas
accionistas, secretaria general, institucionales que rigen sus
etc.) labores.
5.1.2 Mecanismos de comunicación.
Los mecanismos de comunicación que adoptará la Cooperativa de transportes Loja deben

estar alineados con el cumplimiento de los objetivos del negocio, de tal manera que se
establezcan medios que permitan dar a conocer las acciones, proyectos, planes y mejoras
que la empresa se encuentre implementando. Para definir los mecanismos de
comunicación es importante que la empresa defina los siguientes aspectos:
351
5.1.2.1 Eventos.
A continuación, se lista de manera general los posibles eventos a realizarse durante el

desarrollo del trabajo arquitectónico:
• Reunión inicial para efectuar el contrato del trabajo arquitectónico.

• Reuniones de revisión de avances del proyecto: semanales, quincenales o
mensuales.
• Reuniones para la evaluación de cambios en el trabajo arquitectónico o aparición de
nuevos requerimientos.
• Reuniones de capacitación y comunicación de nuevas disposiciones al personal.
• Reunión de cierre del trabajo arquitectónico.
5.1.2.2 Canales.
• Boletín interno.
• Correo electrónico .
• Documentación digital.
• Documentación impresa.
• Redes sociales.
5.1.2.3 Tipo de comunicación.
• Comunicación ascendente.
• Comunicación descendente.
• Comunicación horizontal.
• Comunicación formal.
• Comunicación informal.
5.1.3 Formato de la comunicación.
A continuación, se describe la estructura del documento que resuma los puntos más
importantes de las reuniones realizadas para el desarrollo del trabajo arquitectónico:
352
Tabla 121: Plantilla del documento a completar en reuniones.
Información general
Nombre del proyecto <<Nombre del proyecto>>
Descripción <<Pequeña descripción del proyecto de arquitectura empresarial>>
Responsable <<Responsable de dirigir la reunión>>
Área involucrada <<Personal involucrado y destinatarios de la comunicación>>
Lugar y fecha <<Lugar y fecha en que se emite la comunicación>>
Detalle del asunto de la reunión
<<Descripción detallada del motivo de la reunión>>
Orden de la reunión
<<Temáticas debatidas por los miembros de la reunión>>
Acuerdos adoptados
<<Compromisos y actividades pactadas (indicándose responsables, fechas y mecanismos de

control)>>
353
Evaluación del avance del proyecto
<<Establecer criterios que evalúen el nivel de éxito que ha tenido el proyecto>>
5.1.4 Planificación de las comunicaciones.
De forma general, se listan las principales reuniones a realizarse durante el trabajo

arquitectónico:
Tabla 122: Planificación de las comunicaciones del trabajo arquitectónico.
Evento Canal Contenido Fecha
Reunión inicial. • Correo electrónico. Contrato de trabajo Enero 2016

• Contenido digital. arquitectónico.
Reuniones • Correo electrónico. Evaluación de Cada semana

semanales. • Contenido digital. riesgos, cambios y
requerimientos.
Reuniones • Correo electrónico. Revisión de estado Cada mes

mensuales. • Contenido digital. de avance del
proyecto.
Capacitaciones al • Correo electrónico. Comunicación al Cada mes

personal. • Contenido digital. personal sobre las
etapas del proyecto
Reunión de cierre • Correo electrónico. Cierre y Diciembre

del trabajo • Contenido digital. presentación del 2020
arquitectónico. trabajo
arquitectónico
desarrollado.
Fuente: Planificación estratégica de la Cooperativa de transportes Loja.

354
5.2 Plan de proyecto y calendario.
La planificación del proyecto es acorde a las fases del método de desarrollo arquitectónico:
• Fase preliminar.
• Fase A: visión arquitectónica.
• Fase B: arquitectura de negocio.
• Fase C: arquitectura de sistemas de información.
• Fase D: arquitectura tecnológica.
• Fase E: oportunidades y solución.
• Fase F: planificación de la migración.
• Fase H: gobernanza de la implementación.
• Fase G: gestión de cambios.
Debido a que el proyecto de transformación tecnológica comienza con un diagnóstico inicial

de TI en el mes de Junio del presente año, no es posible aún generar el calendario del
proyecto.
6 Riesgos y mitigaciones.
A continuación, se presenta el análisis de riesgos desarrollado para el presente proyecto de

transformación empresarial.
6.1 Análisis de riesgos.
Tabla 123: Análisis de riesgos del proyecto.
Falta de compromiso de los Media Medio Crear una cultura de

involucrados. comunicación y educación
respecto del trabajo arquitectónico
parar generar compromiso en los
involucrados.
Asegurar la ejecución del plan de
comunicaciones del proyecto.
355
Falta de apoyo de la alta Baja Medio Lograr conciencia y compromiso

dirección. respecto a la participación activa
de la alta dirección.
Comunicación inadecuada. Media Bajo Asegurar la ejecución del plan de

comunicaciones del proyecto.
Insuficiente cantidad de Alta Medio Evaluar la posibilidad de que un

profesionales capacitados profesional cubra más de un rol.
para formar el equipo de Desarrollar programas de
arquitectura empresarial. capacitación y formación del
personal.
Estimación errónea de Media Alto Emplear estándares o

recursos. metodologías para estimación.
Planificación inadecuada. Media Alto Definir hojas de ruta y potenciales

arquitecturas de transición, que
proporcionen una visión del
trabajo a efectuar.
Visión arquitectónica Baja Alto Alinear los objetivos estratégicos

sobredimensionada. de la empresa con las estrategias
de TI.
Medición inadecuada del Media Medio Definir e implementar indicadores

desempeño. clave de desempeño.
Seguimiento inadecuado de Media Medio Implementar herramientas como

los resultados. el cuadro de mando integral para
medir el cumplimiento de las
estrategias de la empresa.
7 Criterios de aceptación y procedimientos.
A continuación, se detallan los principales criterios de aceptación y procedimientos.
7.1 Métricas e indicadores clave de desempeño.
Preliminarmente, se han definido los siguientes indicadores clave de desempeño:
• Cobertura de transformación de TI realizada de acuerdo al proyecto de

transformación de TI.
• Porcentaje de áreas intervenidas hasta el año 2020.
356
7.2 Procedimientos de aceptación / cierre.
El cierre incluye la entrega organizada de los productos arquitectónicos generados durante

el desarrollo de la fase, iteración o proyecto, así como la verificación del cumplimiento de los
acuerdos contractuales y de la ejecución de las evaluaciones de desempeño establecidas.
Se formaliza el cierre del proyecto a través del acta de cierre firmada por patrocinador y los
responsables de la administración y supervisión del proyecto.
357
ANEXO 22: Documento de definición arquitectónica.
358
Documento de definición arquitectónica
Proyecto: Arquitectura empresarial - CTL.
2016
359
Alcance............................................................................................................................... 362
Metas, objetivos y limitaciones............................................................................................362
Riesgos y problemas........................................................................................................... 365
Arquitectura de línea base..................................................................................................367
Arquitectura destino............................................................................................................ 367
Análisis de brechas preliminar.............................................................................................375
360
Nombre del
proyecto

por documento

Título Documento de definición arquitectónica. 2016-10-04
documento
Fecha
de fin
En
revisión.

1.0 2016-10-04 CTL-DAA-DDA_v0.1
361
El Documento de definición arquitectónica es el contenedor de entrega para los principales

artefactos arquitectónicos creados durante un proyecto. El Documento de definición
arquitectónica abarca todos los dominios arquitectónicos (negocios, datos, aplicaciones y
tecnología) y también examina todos los estados relevantes de la arquitectura (estado base,
estado interino y objetivo).
El Documento de definición arquitectónica es un complemento del Documento de

especificación de requerimientos arquitectónicos, con un objetivo complementario:
• El Documento de definición arquitectónica proporciona una visión cualitativa de la

solución y tiene como objetivo comunicar la intención de los arquitectos.
• El Documento de especificación de requerimientos arquitectónicos proporciona una
visión cuantitativa de la solución, estableciendo criterios mensurables que deben
cumplirse durante la implementación de la arquitectura.
Se sugiere que en este documento se haga referencia a las diversas entregas en el

contenedor. Por ejemplo, los principios arquitectónicos serán documentados en el
entregable Principios arquitectónicos y en ese documento se hace referencia aquí.
2 Alcance.

cadena de valor.
3 Metas, objetivos y limitaciones.
A continuación, se describen las metas, objetivos y limitaciones identificadas para el

desarrollo del trabajo arquitectónico.
362
Tabla 124: Objetivos, metas y limitaciones del trabajo arquitectónico.
Objetivo Metas Limitaciones
Garantizar y maximizar • Mejorar y distribuir de manera • No definidas aún.

la rentabilidad y la equitativa los ingresos
excelencia financiera de generados por el servicio A, a
la Cooperativa. través de la implementación del
sistema caja común
• Definir un modelo presupuestario
que haga del presupuesto anual
un instrumento no sólo de
mayor transparencia a la gestión
y operación de la Cooperativa de
Transportes Loja.
• Mejorar la provisión de servicios
a través de la implantación de
una cultura de procesos que se
ejecute en base a la cadena de
valor de la Cooperativa.
Impulsar proyectos que • Implementar la línea de servicio • No definidas aún.

garanticen la turístico.
sostenibilidad y liderazgo • Expandir el servicio AAA hacia
de la Cooperativa en el nuevas rutas que permitan
mercado. ampliar la cobertura del servicio.
imagen de marca a través de un
Plan de marketing.
• Mejorar el servicio y rentabilidad
del transporte y entrega de carga
a través de la transformación
integral del área de
encomiendas.
mejoramiento infraestructura de
cada uno de los servicios
363
ofrecidos.
de las oficinas a nivel nacional a
través del mejoramiento de la
de los servicios de
reparación de carrocerías que se
ofrecen a los socios de la
Cooperativa.
Transformación La definición de las metas Preliminarmente, se han

tecnológica integral de la específicas depende del diagnóstico identificado las siguientes
Cooperativa de inicial de TI a desarrollarse en la limitaciones sobre el trabajo
Transportes Loja. Cooperativa de Transportes Loja. arquitectónico:
• Resulta muy difícil
implementar un
departamento de
arquitectura empresarial
dentro de la empresa.
• Algunos de los roles
definidos anteriormente
pueden verse
descartados, debido a la
poca cantidad de
profesionales
capacitados en
• A causa de la
insuficiente madurez de
capacidades encontrada
en la empresa, no se
podrán observar
resultados a corto plazo,
puesto que el tiempo
idóneo para la ejecución
del proyecto debe ser
entre 3 a 5 años.
• La contratación de los
profesionales requeridos
para la conformación del
equipo de arquitectura
empresarial,
representaría costos
elevados para la
empresa.
364
Implementar un enfoque • Definir un enfoque de gestión • No definidas aún.

moderno y de mejores por competencias para la
prácticas para la gestión planificación del recurso humano
del capital humano. • Disponer de programas de
habiliten tanto a socios, personal
operativo y empleados en el
desempeño de sus funciones.
4 Riesgos y problemas.
A continuación, se presentan los riesgos y problemas identificados para el presente trabajo

arquitectónico.
4.1 Conjeturas.
Conforme se complete la descripción arquitectónica en las fases B, C y D, se deberán

describir conjeturas a ser confirmadas o consideradas en las fases E y F del proyecto
arquitectónico.
Tabla 125: Conjeturas del trabajo arquitectónico.

ID Conjetura Descripción Fecha Fuente Responsable
-- Por definir Por definir Por definir Por definir Por definir

4.2 Riesgos.
Preliminarmente, se han identificado los siguientes riesgos que podrían afectar al trabajo
arquitectónico:
365
Tabla 126: Riesgos del trabajo arquitectónico.
ID Riesgo Frecuencia Impacto Mitigación
RIE- Falta de compromiso Media Medio • Crear una cultura de

001 de los involucrados. comunicación y educación
respecto del trabajo
arquitectónico parar generar
compromiso en los involucrados.
• Asegurar la ejecución del plan
de comunicaciones del proyecto.
RIE- Falta de apoyo de la Baja Medio • Lograr conciencia y compromiso

002 alta dirección. respecto a la participación activa
de la alta dirección.
RIE- Comunicación Media Bajo • Asegurar la ejecución del plan

003 inadecuada. de comunicaciones del proyecto.
RIE- Insuficiente cantidad Alta Medio • Evaluar la posibilidad de que un

004 de profesionales profesional cubra más de un rol.
capacitados para • Desarrollar programas de
formar el equipo de capacitación y formación del
arquitectura personal.
empresarial.
RIE- Estimación errónea Media Alto • Emplear estándares o

E005 de recursos. metodologías para estimación.
RIE- Planificación Media Alto • Definir hojas de ruta y

006 inadecuada. potenciales arquitecturas de
transición, que proporcionen una
visión del trabajo a efectuar.
RIE- Visión arquitectónica Baja Alto • Alinear los objetivos estratégicos

007 sobredimensionada. de la empresa con las
estrategias de TI.
RIE- Medición inadecuada Media Medio • Definir e implementar

008 del desempeño. indicadores clave de
desempeño.
RIE- Seguimiento Media Medio • Implementar herramientas como

009 inadecuado de los el cuadro de mando integral
resultados. para medir el cumplimiento de
las estrategias de la empresa.
4.3 Problemas.

describir los problemas que pudieran afectar al proyecto arquitectónico:
366
Tabla 127: Problemas del trabajo arquitectónico.
ID Problema Estado Fecha inicio Fecha cierre Responsable Responsable del Comentarios
grupo de trabajo
-- Por Por Por Por Por Por definir Por definir

definir definir definir definir definir

4.4 Dependencias.

describir dependencias a ser confirmadas o consideradas en las fases E y F del proyecto
arquitectónico.
Tabla 128: Dependencias del trabajo arquitectónico.

ID Título Descripción Impacto Medidas Comentarios
-- Por definir Por definir Por definir Por definir

5 Arquitectura de línea base.
Actualmente, la Cooperativa de transportes Loja no tiene una arquitectura de aplicaciones

definida. Por lo tanto, la descripción de la arquitectura de línea base no aplica para el
presente ejercicio arquitectónico.
6 Arquitectura destino.
A continuación, se describe la arquitectura de aplicaciones destino que la Cooperativa de

transportes Loja implementará para soportar sus principales procesos de negocio:
367
A partir de la cadena de valor de la Cooperativa de transportes Loja y de la visión
arquitectónica de la empresa, se ha identificado la implementación de las siguientes
aplicaciones para el servicio de transportes de personas:
Tabla 129: Sistemas de la Cooperativa de transportes Loja.
Nombre Proceso de negocio Descripción Abreviatura
Sistema de Planificación de Planifica y calendariza las SGT

gestión de turnos turnos frecuencias disponibles en el lapso
de un año.
Sistema de venta Venta de boletos Gestiona la venta de boletos SVB

de boletos disponibles para cada ruta.
Sistema de Abordaje Gestiona la información resultante SCA

control de de la lectura de los códigos QR o de
abordaje barra, impresos en cada boleto de
acceso.
Sistema de Viaje Gestiona la información resultante SCE

control de de la lectura de los códigos QR o de
equipaje barra, impresos en los boletos del
equipaje adicional de los pasajeros.
Sistema de Viaje Gestiona la información de las rutas SLC

localización y recorridas por las unidades.
control de viaje Controla número de paradas y
velocidad.
Sistema de Arribo Controla la llegada de los pasajeros SCL

control de arribo y el equipaje adicional.
Sistema de Control y Analiza el cumplimiento de cada SCS

control de seguimiento uno de los procesos gestionados
incidencias y por los anteriores sistemas. Detecta
generación de fallos y posibles soluciones. Genera
reportes. reportes en tiempo real.

En la tabla 131, se presentan las interacciones existentes entre los sistemas descritos
anteriormente:
368
Tabla 130: Cadena de valor del servicio de transporte de la CTL
Infraestructura y ambiente: Infraestructura tecnológica adecuada – equipos de computación – infraestructura física adecuada – mantenimiento de instalaciones, equipos y sistemas.
Actividades de apoyo
Dirección general y recursos humanos: Contratación y capacitación del personal – responsabilidad social.
Organización interna y tecnológica: Incursión móvil y social – Big data analytics – sistemas Integrados – innovación – sistema financiero – call center (CRM).
Abastecimiento: Compra de equipos – licencias.
Planificación de turnos Venta de boletos Abordaje Viaje Arribo Auditoría y control Finanzas
Actividades primarias
Sistemas
Sistema de gestión de Sistema de venta de boletos. Sistema de control de Sistema de localización y Sistema de control de arribo. Sistemas de control de Sistema financiero.
turnos. abordaje y equipaje. control de viaje. incidencias y de
generación de reportes.
* Calendarización. * Calendarización. * Códigos QR. * GPS. * GPS. * Códigos QR. * Servicio de

Módulos
* Herramientas de * Servicio de transferencia de * SMS. * Google Maps. * Google Maps. * Calendarización. transferencia de
ofimática. fondos. * BPMS. * BPMS. * Redes sociales. * Servicio de fondos.
* Correo electrónico * Correo electrónico corporativo. * SMS. transferencia de fondos. * Herramientas de
corporativo. * SMS. * BPMS. * GPS. ofimática.
* Redes sociales. * BPMS. * Google Maps. * Correo electrónico
* BPMS. * ECM. * Call center. corporativo.
* ECM * Call center. * Call center.
* Sistema de venta de * Sistema de gestión de turnos. * Sistema de venta de * Sistema de venta de * Sistema de venta de boletos. * Sistema de gestión de * Sistema de gestión de
Interacciones
boletos. * Sistema de control de abordaje boletos. boletos. * Sistema de control de turnos. turnos.
* Sistema de control de y equipaje. * Sistema de localización * Sistema de control de abordaje y equipaje. * Sistema de venta de * Sistema de venta de
incidencias. * Sistema de localización y y control de viaje. abordaje y equipaje. * Sistema de localización y boletos. boletos.
* Sistema de generación control de viaje. * Sistema de control de * Sistema de control de control de viaje. * Sistema de control de * Sistema de control de
de reportes. * Sistema de control de arribo. arribo. arribo. * Sistema de control de arribo. abordaje y equipaje. incidencias.
* Sistema financiero. * Sistema de control de * Sistema de control de * Sistema de control de * Sistema de control de * Sistema de localización * Sistema de
incidencias. incidencias. incidencias. incidencias. y control de viaje. generación de reportes.
* Sistema de generación de * Sistema de generación * Sistema de * Sistema de generación de * Sistema de control de
reportes. de reportes. generación de reportes. reportes. arribo.
* Sistema financiero. * Sistema financiero.
Sistema móvil de información (Android / IOS).
Sistema de control de incidencias (BPM).
Sistema de generación de información (Big data analytics).

369
Tabla 131: Matriz de interacción de aplicaciones.
SGT SVB SCA SCE SLC SCL SCS
SGT Provee - - - - Provee

información información
SVB Provee - - - - Provee

SCA - Solicita - - - Provee

SCE - Solicita Solicita - - Provee

información información información
SLC - Solicita Solicita - - Provee

información información información
SCL - Solicita Solicita Solicita Solicita Provee

información información información información información
SCS Provee Provee Provee Provee Provee Provee

información información información información información información

370
Para la descripción de la arquitectura de aplicaciones destino de la Cooperativa de
transportes Loja, se ha tomado en consideración el siguiente modelo de referencia:
• Modelo de referencia técnico (TRM): Montalván (2016), propone el siguiente

modelo de referencia técnico para el proceso de transformación empresarial de la
Cooperativa:
Figura 98: Modelo de referencia técnico de la CTL.

Elaboración: Montalván (2016).
En este modelo, se pueden distinguir las siguientes capas (Montalván, 2016):
◦ Capa de Desarrollo: Capa que hace referencia a los servicios empleados para:
371
▪ Desarrollo de aplicaciones
▪ Desarrollo de aplicaciones de Inteligencia de negocios.
▪ Composición de procesos.
▪ Modelado de datos.
▪ Exploración de datos.
◦ Capa de Integración: Capa que hace de mediación para la comunicación entre

capas. Los servicios que se encuentran en esta capa son:
▪ Servicios de mediación
▪ Mensajería
▪ Conectividad
▪ Movimiento de datos.
◦ Capa de Interacción: Capa que se encuentra ubicada entre los medios de

acceso y la capa de aplicación, esta capa permite:
▪ Interacción con entornos web.

▪ Interacción con entornos móviles.
▪ Interacción con dispositivos
▪ Interacción con servicios/API
▪ Interacción con redes sociales
▪ Interacción con el negocio
▪ Alertas y notificaciones programables.
◦ Capa de aplicaciones: contiene a todas las aplicaciones, además cuenta con

servicios de orquestación que preparan a las mismas para compartir información.
Esta capa está compuesta por:
▪ Aplicaciones del negocio: En la Cooperativa de transportes Loja se han

identificado las siguientes aplicaciones:
• Sistema de gestión de turnos.

• Sistema de venta de boletos.
372
• Sistema de control de abordaje.
• Sistema de control de equipaje.
• Sistema de control y localización.
• Sistema de control de arribo.
• Sistema de control y seguimiento.
▪ Servicios del negocio.

▪ Análisis del negocio.
▪ Aplicaciones de medios sociales.
▪ Orquestación de procesos de negocio.
▪ Servicios de orquestación.
▪ Reglas de negocio.
◦ Capa de Infraestructura: Capa que permite la construcción de redes que

permiten la comunicación entre aplicaciones. Compuesta por los siguientes
servicios:
▪ Computación basada en servidores

▪ Computación móvil
▪ Virtualización y aprovisionamiento
◦ Capa de seguridad: está encargada que se cumplan los protocolos de seguridad

establecidos por la organización, para preservar la integridad de la información y
las aplicaciones. Los servicios de esta capa son:
▪ Seguridad en: aplicaciones, transporte de información, API s, datos, móvil,

web services.
▪ Gestión de identificación al acceso al sistema.
◦ Capa de gestión: Permite la administración de la interacción entre los

componentes de las diferentes capas. Esta capa permite la gestión de:
▪ Aplicaciones, Servicios, Procesos de negocio y Reglas de negocio.

▪ De ambientes para: Cloud, Móviles y Dispositivos inteligentes.
373
• Arquitectura de aplicaciones destino: De acuerdo a la visión arquitectónica de la
empresa, el modelo arquitectónico de la empresa que soportará las nuevas
operaciones del negocio es Arquitectura Orientada a Servicios (SOA).
Figura 99: Arquitectura de referencia SOA.

Fuente: Romero (2015).
Adaptado de Romero.
◦ Arquitectura orientada a servicios: es un marco de trabajo conceptual que

establece una estructura de diseño para la integración de aplicaciones, que
permite a las organizaciones unir los objetivos de negocio, en cuanto a
flexibilidad de integración con sistemas legados y alineación directa a los
374
procesos de negocio, con la infraestructura de TI. A continuación, se presenta la
arquitectura de aplicaciones destino de la Cooperativa de transportes Loja, que
se acopla al modelo técnico de referencia mencionado anteriormente.
▪ Capa de presentación: Capa que interactúa directamente con el usuario

final.
▪ Capa de lógica de negocios: Capa encargada del procesamiento de los
datos. Contiene reglas y directrices del negocio.
▪ Capa de datos: Capa que brinda acceso a los datos. Es utilizada
principalmente por una herramienta de persistencia.
▪ Capa transversal: Capa que contiene características comunes para todas
las capas (seguridad, gestión, comunicaciones).
7 Análisis de brechas preliminar.
A continuación, se describe el proceso de análisis de las brechas existentes para lograr la

arquitectura de aplicaciones destino. Sin embargo, se ha considerado de manera preliminar,
a los componentes transversales en los dominios empresariales restantes.
7.1 Negocio.
Tabla 132: Análisis de brechas - negocio: estrategia.
Motivación: estrategia.
Capacidad destino Establecer mecanismos de seguimiento y retroalimentación para la

planificación estratégica empresarial.
Capacidad actual Se ha definido la planificación estratégica de la empresa hasta el

año 2020.
Deficiencias • No existen instrumentos de monitorización del cumplimiento de

las estrategias empresariales.
• No existe retroalimentación: no se puede aprender sobre la
estrategia ni mejorarla.
Plan de acción • Definir indicadores claves de desempeño (KPIs, por sus siglas
en inglés) medibles, alcanzables, relevantes y disponibles a
tiempo.
• Utilizar el Cuadro de Mando Integral (CMI) como herramienta
para medir resultados, a partir de la definición de indicadores
financieros y no financieros derivados de la visión estratégica
375
de la empresa. Adicionalmente, servirá como instrumento para
detectar las desviaciones de la planificación estratégica y
definir las iniciativas para abordar la situación.
• Establecer acuerdos de nivel de servicio (ANS) que describan
las expectativas de calidad del servicio prestado por los
departamentos de la empresa.
Tabla 133: Análisis de brechas - negocio: modelos empresariales.
Motivación: modelos empresariales.
Capacidad destino Desarrollar un programa de acción que describa el proceso de

generación de valor y que sirva como eje rector para orquestar las
estrategias a través de estructuras organizacionales.
Capacidad actual No se han validado los modelos empresariales de la empresa.
Deficiencias No existe una definición clara de cómo la empresa obtendrá sus

ingresos y podrá ser rentable, por ende resulta complejo persuadir
potenciales acreedores o inversionistas.
Plan de acción • Validar los modelos empresariales de la empresa.

• Adoptar el modelo de negocios Canvas como herramienta para
agregar valor a las estrategias de negocio.
• Desarrollar un modelo operativo integral que conecte la visión
estratégica y el modelo de negocio con los procesos clave de
la empresa.
• Validar supuestos de requerimientos de recursos y
proyecciones financieras en el plan de negocios empresarial.
Tabla 134: Análisis de brechas - negocio: procesos.
Función: procesos.
Capacidad destino Diseñar la arquitectura de procesos de negocio, en la cual se

definan: metodología, enfoque, estándares, responsables y
herramientas necesarias para la definición y evolución de los
procesos que soportan el negocio.
Capacidad actual No existe definición formal de los procesos que soportan el

negocio.
Deficiencias • No se cuenta con una visión sistemática de las actividades de

la organización.
• Los procesos no son capaces de reaccionar autónomamente a
los cambios.
376
• Es difícil la gestión de nuevos requerimientos y la identificación
de oportunidades para la mejora continua de los procesos.
Plan de acción • Analizar los procesos de negocio para facilitar, integrar,

eliminar redundancias e incrementar la eficiencia.
• Identificar procesos de negocio con fines de reuso.
• Identificar los propietarios de cada proceso.
• Utilizar un enfoque orientado al cliente para el diseño de
• Emplear los principios básicos de la serie de normas ISO
9000:2015 para el aseguramiento de la calidad de procesos.
• Adoptar Business Process Model and Notation (BPMN)
como estándar para el diseño de procesos.
• Evaluar la posibilidad de adoptar modelos de procesos de
negocio específicos de la industria.
• Incluir la definición de reglas de negocio en el documento de
especificación de requerimientos.
• Implementar un sistema de gestión y automatización de
procesos (BPMS) como Bonita BPM. Si existen reglas de
negocio complejas, es recomendable la integración con un
sistema de gestión de reglas de negocio (BRMS) como Drools.
Tabla 135: Análisis de brechas -negocio: roles, actores y habilidades.
Organización: Roles, actores y habilidades.
Capacidad destino • Desarrollar una estrategia de gestión del capital humano que
integre los procesos de: captación, selección, capacitación,
remuneración y evaluación del desempeño del personal.
Capacidad actual • No existe clara definición de roles y responsabilidades.

• Sobrecarga de trabajo.
• Duplicidad de tareas.
Deficiencias • No existe clara definición de roles y responsabilidades.

• Sobrecarga de trabajo.
• Duplicidad de tareas.
Plan de acción • Definir un enfoque de gestión por competencias para la

planificación de recursos humanos.
• Elaborar una matriz de asignación de responsabilidades (RACI)
actualizada y comunicarla con el personal.
• Incluir en el plan de recursos humanos, programas de
certificación y capacitación continua del grupo societario y
personal.
377
Tabla 136: Análisis de brechas - negocio: comunicación.
Organización: Comunicación.
Capacidad destino Establecer mecanismos de interacción interna y externa que

garanticen una cultura de comunicación empresarial y
posicionamiento de la imagen respectivamente.
Capacidad actual No existen estrategias de comunicación y marketing empresarial.
Deficiencias • Focalización de la información: no se comunica a niveles

inferiores.
• Fallas en los mecanismos de convocatoria a reuniones.
• Es difícil comunicar a los clientes acerca de las promociones y
nuevos servicios que ofrece la empresa.
• No existe retroalimentación del cliente respecto a los servicios
prestados.
Plan de acción • Elaborar un plan estratégico de comunicación integral (PECI)

en el que se describan elementos, ámbitos, estrategias y
canales de comunicación. Además, se deberá incluir las
estrategias y tácticas de los planes de Marketing y Social
Media.
• Implementar un sistema para la administración de las
relaciones con el cliente (CRM) como SuiteCRM.
7.2 Dimensión: Datos
Tabla 137: Análisis de brechas - datos: componentes lógicos y físicos.
Modelo de datos: componentes lógicos y físicos.
Capacidad destino Desarrollar modelos de datos que aseguren la alineación de los

requerimientos de información con las necesidades del negocio.
Capacidad actual • No existen modelos de datos formalmente documentados.
Deficiencias • Requerimientos de información innecesarios.

• Dificultad en la introducción de nuevos requerimientos.
• Polisemia de términos.
Plan de acción • Definir una taxonomía común de términos empresariales que

se adhiera a los repositorios de información y comunicarla con
el personal.
• Documentar los flujos y vínculos de información para asegurar
el entendimiento de los propietarios de los datos.
• Diseñar modelos de datos utilizando un enfoque arquitectónico
“arriba-abajo”.
378
Tabla 138: Análisis de brechas - datos: administración, migración y gobernanza.
Gestión de información: administración, migración y gobernanza.
Capacidad destino Implementar una estrategia de gestión de información empresarial

que sirva como marco para facilitar los procesos de
almacenamiento, integración, uso, acceso y entrega de los
recursos de información en toda la empresa.
Capacidad actual • No existe estandarización sobre el ingreso de información.

• No existen repositorios estructurados de información digital.
Deficiencias • Duplicidad, desperdicio y pérdida de información.

• Complejidad en la explotación de la información.
• Información inconexa.
Plan de acción • Realizar un diagnóstico inicial de la situación de los datos en la

empresa.
• Definir las etapas del ciclo de vida de datos desde la creación
hasta cuando es obsoleto u eliminado el dato.
• Elaborar estrategias para la gestión de la información
empresarial (EMI) y establecer una hoja de ruta para su
implementación.
• Elaborar un plan en el que se incluya la metodología y
aspectos de seguridad a considerar en el proceso de migración
de datos.
• Definir e implementar repositorios de tipo empresarial y
arquitectónico, en los cuales se organice y clasifique la
información producida por el negocio y el trabajo arquitectónico
respectivamente.
• Implementar un sistema de gestión de contenido empresarial
(ECM) como Alfresco para la administración de la
documentación generada por los procesos de negocio.
• Adoptar las recomendaciones de la norma ISO 8000:150 para
la gestión y gobierno de datos.
• Adoptar los principios básicos de la guía de buenas prácticas
para la gestión de datos DAMA DMBOK.
• Seleccionar las normas ISO 30300/30301 como estándares
para la gestión documental.
Tabla 139: Análisis de brechas – datos: toma de decisiones.
Gestión de información: toma de decisiones.
Capacidad destino Desarrollar capacidades analíticas de información que permitan

generar escenarios de probabilidad para la toma de decisiones
empresarial, mediante la adopción Big Data Analytics como modelo
de análisis de la información.
Capacidad actual No existen estrategias documentadas para explotación de

información empresarial.
379
Deficiencias • Decisiones basadas en la intuición y no en el conocimiento.
• Es difícil identificar nuevas oportunidades de negocio.
• Es imposible la reacción inmediata a cualquier movimiento
dentro de la industria.
Plan de acción • Definir la cadena de valor de la inteligencia en la empresa:

datos, información, conocimiento e inteligencia.
• Evaluar la necesidad de incorporar fuentes de datos externas
que complementen a las ya existentes en la empresa, como
redes sociales.
• Elaborar un proyecto que describa las fases para la
implementación de Big Data.
◦ Conceptualización del problema y sus necesidades:
Establecer el tipo de datos a tratar y las necesidades reales
del proyecto.
◦ Definición, planificación y ejecución del proyecto.
• Selección de la plataforma tecnológica
adecuada: De acuerdo al tipo de Big Data
requerido por la organización, se deberá
especificar la categoría de base de datos y el
framework a utilizar. (Se recomienda emplear
tecnologías como Apache Hadoop o Apache
Spark que son soluciones implementadas en
un gran número de empresas).
• Implementación: Se deberá detallar el proceso
de captura, transformación, almacenamiento y
análisis de los datos.
◦ Entrega y cierre del proyecto.
• Comunicación en la optimización de toma de
decisiones: Existe la necesidad de definir un
lenguaje de comunicación adaptado para el
consumo de los resultados por parte de las
áreas de negocio.
• Integración en productos y servicios de datos.
• Adoptar los principios básicos del estándar internacional de Big
Data UIT-T Y.3600.
Tabla 140: Análisis de brechas - datos: seguridad de la información.
Gestión de información: seguridad de la información
Capacidad destino Desarrollar un modelo de seguridad de la información que defina

políticas, estándares y mecanismos de control para la información
que maneja la empresa.
Capacidad actual No existen estrategias para la seguridad de la información en la

empresa.
Deficiencias • Información vulnerable e inconsistente.

• Pérdida de información.
• Acceso no autorizado a la información.
380
• Interrupciones en el acceso a los datos.
Plan de acción • Efectuar un análisis de riesgos de la información empresarial.

• Desarrollar un modelo de seguridad de la información que
defina: lineamientos, estrategias y grupos de interés.
• Planificar controles de seguridad para el tratamiento de los
riesgos.
• Planificar copias de seguridad de la información empresarial.
• Adoptar los principios básicos de la serie de normas ISO
27000 para la gestión de la seguridad de la información.
7.3 Dimensión: Aplicaciones
Tabla 141: Análisis de brechas - aplicaciones: componentes lógicos y físicos.
Arquitectura de aplicaciones: componentes lógicos y físicos.
Capacidad destino Construir una arquitectura de aplicaciones que se ajuste a las

necesidades del negocio y sirva como estructura para la integración de
los sistemas de software corporativos.
Capacidad actual No existe una arquitectura de aplicaciones definida.
Deficiencias • No existe descripción de los componentes de los sistemas ni de las

interfaces de comunicación de los mismos.
• El contexto en el que operan los sistemas empresariales no posibilita
la trazabilidad de los requerimientos del negocio.
• Es imposible garantizar criterios de calidad para las soluciones
informáticas.
• Es imposible la reutilización de componentes de software.
• Altos costos de mantenimiento de las aplicaciones corporativas.
Plan de acción • Capturar, documentar y priorizar los requerimientos necesarios para

el diseño de la arquitectura.
• Planificar la implementación del estilos arquitectónicos “arquitectura
orientada a servicios SOA” (arquitectura destino).
• Planificar el mantenimiento de la arquitectura de aplicaciones
implementada.
• Emplear el modelo de vistas de arquitectura “4+1” como enfoque
para describir la arquitectura de aplicaciones.
• Utilizar el lenguaje unificado de modelado (UML, por sus siglas en
inglés) como estándar para modelar sistemas de software.
• Seleccionar Enterprise Architect como herramienta para modelado.
• Adoptar los principios básicos del estándar IEEE 830 para la
especificación de requerimientos de software.
• Aplicar la metodología Attribute Driven Design (ADD) para la
identificación de los atributos de calidad requeridos.
• Adoptar los principios básicos del estándar internacional
ISO/IEC/IEEE 42010: “Sistemas e ingeniería de software” como
modelo conceptual para la descripción de la arquitectura.
381
• Utilizar la herramienta Sonargraph-Architect para validar el diseño
de la arquitectura.
Tabla 142: Análisis de brechas - aplicaciones: SOA.
Arquitectura de aplicaciones: SOA.
Capacidad destino Desarrollar un programa SOA que defina las implicaciones y el ciclo de
vida de implementación de la arquitectura orientada a servicios, la cual
permitirá a la empresa alinear los objetivos del negocio con la
infraestructura de TI.
Capacidad actual No existe una arquitectura de aplicaciones definida.
Deficiencias • No es posible eliminar la brecha existente entre los procesos de

negocio y las implementaciones de TI.
• Resulta difícil la integración de los sistemas corporativos.
• Es dificultoso soportar cambios continuos del negocio.
Plan de acción • Planificar la implementación de la solución SOA:

◦ Análisis de requerimientos y definición de condiciones de éxito.
◦ Definir el dominio SOA.
◦ Comprender la naturaleza de la información a intercambiar, fuentes
de información y procesos de negocio.
◦ Identificar y definir interfaces.
◦ Definir servicios y sus límites de información.
◦ Definir nuevos procesos de negocio que automaticen la interacción
entre servicios.
◦ Seleccionar la tecnología a utilizar.
• Establecer servicios que permitan la interacción con el usuario:
servicios de composición, de colaboración y de presentación.
• Definir los procesos del gobierno SOA.
• Establecer políticas de especificación para: diseño, reuso,
interoperabilidad, versionamiento y mejora continua de servicios.
Tabla 143: Análisis de brechas - aplicaciones: aplicaciones corporativas.
Arquitectura de aplicaciones: aplicaciones corporativas.
Capacidad destino Desarrollar estrategias de adquisición y priorización de soluciones

informáticas para los procesos de negocio de la empresa.
Capacidad actual • Las soluciones informáticas actuales no soportan los procesos de

negocio de la empresa.
• No existe integración entre las aplicaciones.
Deficiencias • Los sistemas corporativos no permiten una gestión adecuada de los

servicios prestados.
382
• Los sistemas empresariales no posibilitan la toma de decisiones en
tiempo real.
Plan de acción • Desarrollar un diagnóstico de las aplicaciones empresariales

actuales.
• Adoptar un enfoque de planificación y priorización de aplicaciones.
• Planificar la adquisición de sistemas para cada uno de los segmentos
de la cadena de valor de la empresa, basados en los principios
arquitectónicos de la empresa y en la arquitectura de aplicaciones
establecida.
• Asegurar que las aplicaciones corporativas cuentan con
documentación clara y precisa.
• Definir estrategias de renovación de sistemas legados.
• Planificar la integración de los sistemas empresariales, permitiendo
que operen de forma orquestada y conjunta para modelar los
◦ Definir servicios de conectividad, de modelado de procesos de
negocio, de integración de la información y de mensajería.
• Desarrollar un bus de servicios empresariales (ESB) que garantice la
orquestación de servicios. Se recomienda utilizar una plataforma de
código abierto como OpenESB.
Tabla 144: Análisis de brechas - aplicaciones: consideraciones de seguridad.
Administración: consideraciones de seguridad.
Capacidad destino Desarrollar procedimientos de seguridad básicos que proporcionen

protección preventiva para las aplicaciones empresariales.
Capacidad actual No existen mecanismos que garanticen seguridad en las aplicaciones

empresariales.
Deficiencias • Posible fuga de información.

• Accesos no autorizados a las aplicaciones empresariales.
Plan de acción • Planificar la ejecución de controles internos que permitan identificar

vulnerabilidades y evaluar el rendimiento de las aplicaciones.
• Establecer políticas de control de acceso a las distintas aplicaciones
de la empresa.
• Asegurar que las aplicaciones empresariales estén diseñadas bajo
estándares y normas de seguridad.
383
7.4 Dimensión: Tecnología.
Tabla 145: Análisis de brechas - tecnología: plataforma, componentes y seguridad.
Modelo empresarial de integración tecnológica: plataforma, componentes lógicos y

físicos, consideraciones de seguridad.
Capacidad destino Desarrollar un modelo empresarial de integración tecnológica que defina

los componentes lógicos y físicos de la plataforma tecnológica de la
empresa.
Capacidad actual No existe un modelo empresarial de integración tecnológica.
Deficiencias • No se garantiza protección contra robos, pérdidas, daños o

modificación no autorizada de los activos de TIC's.
• Dificultad en el proceso de despliegue de la plataforma tecnológica
de la empresa.
• No existe rendición de cuentas del estado de los activos tecnológicos
de la empresa.
• Posibles islas tecnológicas.
Plan de acción • Planificar un inventario de los activos tecnológicos de la empresa.

• Definir diseños, planos, componentes, servicios, sistemas operativos,
niveles de calidad, catálogos, carteras de infraestructura, y sus
interrelaciones.
• Planificar el despliegue de la infraestructura en la nube.
• Elaborar perfiles de estándares tecnológicos.
• Establecer un portafolio de estándares tecnológicos que permitan
evaluar la adopción de los mismos.
• Definir los propietarios para los procesos de planificación, gestión y
administración de activos tecnológicos.
• Establecer y asegurar la adopción de métricas de nivel de calidad
para la implementación de soluciones, servicios e infraestructura.
• Elaborar estrategias para la gestión del ciclo de vida de productos
tecnológicos.
• Desarrollar un modelo de seguridad para los activos tecnológicos de
la empresa.
Tabla 146: Análisis de brechas - tecnología: estrategias de TI.
Administración: Estrategias de TI.
Capacidad destino Elaborar estrategias que posibiliten procesos planificados de selección,

mantenimiento y despliegue de los activos tecnológicos de la empresa.
Capacidad actual No existen estrategias de TI documentadas.
Deficiencias • Altos costos de mantenimiento.

• Infraestructura sin soporte.
• Alto riesgo de inactividad en los sistemas.
384
Plan de acción • Definir estrategias de planificación para el mantenimiento y
despliegue de la infraestructura tecnológica.
• Definir políticas de racionalización de productos y plataformas
tecnológicas.
• Establecer procesos de evaluación de vulnerabilidades para
identificar y cuantificar las debilidades del sistema.
• Elaborar un plan de contingencia que aseguren la disponibilidad de
los activos tecnológicos críticos.
7.5 Arquitectura empresarial.
Tabla 147: Análisis de brechas de arquitectura empresarial.
Elemento
Plan de acción
arquitectónico
Procesos • Definir procesos arquitectónicos ad-hoc.

arquitectónicos
• Documentar el programa de procesos arquitectónicos básicos.
• Desarrollar funciones y responsabilidades claras para el proceso
arquitectónico.
• Definir totalmente la arquitectura y comunicarla al personal

involucrado en el trabajo arquitectónico.
Desarrollo • Establecer informalmente procesos arquitectónicos, documentación

arquitectónico y estándares a través de medios ad-hoc.
• Documentar la visión, principios arquitectónicos, alineamiento

estratégico, arquitecturas base y arquitecturas destino.
• Establecer el modelo técnico de referencia y el perfil de estándares.
• Completar el análisis de brechas y el plan de migración.

• Alinear los estándares arquitectónicos a los conductores del negocio
gracias a las mejores prácticas, principios de TI y arquitectura
destino.
Alineación con el • Alinear mínimamente o implícitamente la arquitectura con las

negocio estrategias o conductores del negocio.
• Alinear explícitamente la arquitectura con las estrategias o

conductores del negocio.
• Alinear explícitamente la arquitectura con los requerimientos de

información.
• Integrar el trabajo arquitectónico con las planificaciones de capital y
el control de inversiones.
385
Elemento
Plan de acción
arquitectónico
Participación de la • Lograr conciencia o participación limitada del equipo de gestión en

alta dirección el proceso arquitectónico.
• Lograr participación ocasional/selectiva del equipo de gestión en el

proceso arquitectónico con diversos grados de compromiso.
• Lograr conciencia y participación activa del equipo de gestión en el

proceso arquitectónico.
• Lograr gestión activa de la administración para la adopción de
estándares.
Participación de la • Alcanzar aceptación limitada de la unidad operativa en el trabajo

unidad operativa arquitectónico. (Apoyo individual en el trabajo arquitectónico).
• Designar las responsabilidades del trabajo de arquitectura

empresarial.
• Lograr una comprensión clara del estado actual de la arquitectura en
la empresa. (Participación limitada de la empresa en el trabajo
arquitectónico).
• Lograr aceptación de los elementos más importantes de la unidad

operativa respecto del trabajo arquitectónico. (La mayor parte de la
empresa está involucrada en el trabajo arquitectónico).
Comunicación de la • Iniciar una cultura de comunicación y educación respecto del trabajo

arquitectura arquitectónico efectuado.
• Planificar reuniones para informar respecto al estado del trabajo

arquitectónico.
• Informar de avances del trabajo arquitectónico vía correo
corporativo.
• Completar educación de la arquitectura para el equipo de TI.
• Utilizar herramientas de ofimática para la documentación del trabajo
arquitectónico.
• Realizar presentaciones periódicas del estado del trabajo

arquitectónico por parte del equipo de TI.
• Implementar herramientas como MEGA TOGAF 9 on HOPEX para
la gestión de la documentación del trabajo arquitectónico.
• Actualizar con regularidad los entregables arquitectónicos
resultantes.
• Completar educación de la arquitectura para las unidades operativas
de la empresa.
Seguridad de TI • Definir consideraciones de seguridad de TI ad-hoc.
• Definir claramente roles y responsabilidades para la arquitectura de
386
Elemento
Plan de acción
arquitectónico
seguridad de TI.
• Desarrollar completamente la arquitectura de seguridad de TI e

integrarla con la arquitectura de TI.
Gobernanza • Lograr un acuerdo limitado con la estructura de gobierno.
• Lograr gobernanza sobre estándares arquitectónicos y adherencia al

perfil de estándares.
• Alcanzar alta comprensión de la estructura de gestión propuesta.
• Desarrollar gobernanza explícita sobre la mayor parte de

inversiones de TI.
• Definir procesos formales para la gestión de cambios.
Inversión en TI y • Iniciar la participación del personal de adquisición en el trabajo

estrategias de arquitectónico.
adquisición
• Gobernanza informal sobre las estrategias de inversión y
adquisición de TI.
• Incluir medidas de cumplimiento en las estrategias de adquisición de

TI.
• Lograr adherencia al perfil de estándares por parte de las unidades
operativas.
• Conseguir participación activa del personal de adquisición en la
estructura de gobierno del trabajo arquitectónico.
• Considerar costos y beneficios en la identificación de proyectos.

387

Vargas Na Ula Francisco Oswaldo

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

Vargas Na Ula Francisco Oswaldo

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja

TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y

Definición de marco de referencia de Arquitectura empresarial para

AUTOR: Vargas Naula, Francisco Oswaldo.

DIRECTOR: Cabrera Silva, Armando Augusto, Mg.

El presente trabajo de titulación: “Definición de marco de referencia de Arquitectura

Loja, Enero de 2017.

Además de las personas mencionadas anteriormente, quiero entregar mi más sincero y

APROBACIÓN DEL DIRECTOR DEL TRABAJO DE TITULACIÓN........................................ii

Figura 1: Metodología de la investigación...............................................................................8

Tabla 1: PYMEs en la zona de planificación 7.......................................................................17

TOGAF es uno de los principales marcos de Arquitectura empresarial. Su objetivo primordial

Las pequeñas y medianas empresas (PYMEs) se caracterizan principalmente por su

El proceso de incorporación de infraestructura tecnológica en las PYMEs debe ser guiado

PALABRAS CLAVES: TOGAF, ADM, arquitectura empresarial (AE), tecnologías de

The process of incorporating technological infrastructure in SME should be guided by a

En nuestra economía, las PYMEs son fundamentales para el desarrollo de la producción.

Arquitectura empresarial es una metodología de mejora continua que posibilita la alineación

Con estos antecedentes, surge la necesidad de proponer un marco de referencia de

Cuando se culmine el proceso de adaptación de TOGAF a los requerimientos de las PYMEs,

El primer capítulo, titulado EMPRESA, abarca el estudio del concepto, funciones y

El segundo capítulo, denominado ARQUITECTURA EMPRESARIAL, explica los principales

En el tercer capítulo, CONCEPTUALIZACIÓN DE TOGAF, se desarrollará la

En el cuarto capítulo, PROPUESTA, se presenta el prototipo del marco de referencia

Finalmente, en el quinto capítulo, PRUEBA DE CONCEPTO, se describirá la prueba de

• Adaptar, en base a ADM - TOGAF, un marco de referencia que se ajuste a las

• Realizar un análisis de los principales componentes de ADM - TOGAF, con el fin de

A continuación, se describe la metodología de investigación empleada para desarrollar el

1.1.1 Enfoque metodológico.

En el diseño del marco de referencia arquitectónico propuesto, se implementará el enfoque

1.1.2 Método de investigación.

Para el desarrollo de la presente investigación se optó por el método empírico-analítico.

1.1.3 Fases de la investigación.

2. Exploración de la información: Denominada también fase exploratoria, abarca la

3. Diseño de la solución: Dentro de esta fase se procede a: a) Elaborar criterios de

4. Prueba de concepto: Una prueba de concepto es la implementación parcial de la

5. Análisis de los resultados: Una vez que se ha desarrollado la investigación se

Figura 1: Metodología de la investigación.

• El diccionario de la Real academia de la lengua española (2014) define a la empresa

1.3 Funciones de la empresa.

• Funciones técnicas: Funciones que se encuentran directamente ligadas con la

1.4 Clasificación de las empresas.

1.4.1 De acuerdo a su tamaño o magnitud.

Dentro de esta clasificación se encuentran: micro-empresas, talleres artesanales, pequeñas

Figura 2: Clasificación de empresas de acuerdo a su tamaño o magnitud.

Se pueden clasificar en:

• Comercial: Empresas dedicadas a entregar bienes desde el productor hacia el

1.4.3 De acuerdo al origen del capital.

De acuerdo a esta clasificación las empresas pueden ser:

• Empresas públicas. Organizaciones en las cuales el capital le pertenece al Estado.

1.4.4 De acuerdo a la forma de organización del capital.

De acuerdo a este criterio las empresas pueden ser:

• Individuales. Empresas en las cuales el capital se conforma gracias al aporte de

◦ Compañía en nombre colectivo.

1.5 PYMEs en el Ecuador.

A continuación, se describe la situación actual de las PYMEs en nuestro país.

1.5.1 Definición de PYMEs.

• Comercio al por mayor y menor.

1.5.2 Situación actual de las PYMEs en el Ecuador.

Como se mencionó anteriormente, la actividad de las PYMEs en nuestro país es muy

Figura 3: Distribución de empresas en el Ecuador.

De la misma forma, se presenta a continuación la sectorización de las PYMEs.

Figura 4: Sectorización de las PYMEs en el Ecuador.