INTEGRACIÓN DE BUENAS PRÁCTICAS PARA LA …dspace.utpl.edu.ec/bitstream/123456789/1657/3/Román...

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

ESCUELA DE CIENCIAS DE LA COMPUTACIÓN

INTEGRACIÓN DE BUENAS PRÁCTICAS PARA LA DEFINICIÓN DE UN FRAMEWORK DE

ARQUITECTURA EMPRESARIAL PARA LA UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

Memoria del proyecto de fin de carrera previo a la obtención del título de Ingeniero en Sistemas Informáticos y Computación.

AUTOR: Carlos Aníbal Román Pachar

DIRECTOR: Ing. Armando Cabrera Silva

CO-DIRECTOR: Ing. Patricio Abad Espinoza

Loja – Ecuador 2011

Página ii

Ing.

Armando Cabrera Silva

DIRECTOR DE TESIS

C E R T I F I C A:

Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la

obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN,

y una vez que éste cumple con todas las exigencias y los requisitos legales establecidos

por la Universidad Técnica Particular de Loja, autoriza su presentación para los fines

legales pertinentes.

Loja, Marzo de 2011

______________________

Ing. Armando Cabrera Silva

DIRECTOR DE TESIS

Página iii

Autoría

El presente proyecto de tesis con cada una de sus observaciones, análisis, evaluaciones,

conclusiones y recomendaciones emitidas, es de absoluta responsabilidad del autor.

Además, es necesario indicar que la información de otros autores empleada en el

presente trabajo está debidamente especificada en fuentes de referencia y apartados

bibliográficos.

_________________

Carlos A. Román P.

Página iv

Cesión de derechos

Yo, Carlos Aníbal Román Pachar, declaro conocer y aceptar la disposición del Art. 67 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”

_________________

Carlos A. Román P.

Página v

Agradecimiento

Agradezco de la manera más sincera a mi director de tesis Ing. Armando Cabrera por haber guiado esta investigación de manera impecable. Gracias por ser aparte de un docente: un amigo.

Agradezco a mis padres, por haberme acompañado, amado y apoyado siempre en el diario devenir, en especial a mi madre Anita.

Dejo sentada mi imperecedera gratitud a mis amigos, especialmente a mi hermano de ideales y convicciones Diego Peralta. A mis profesores que han sabido guiar e infundir en mí la capacidad de razonar con mente fría, en especial al Ing. Nelson Piedra por haberme brindado su amistad y sus conocimientos.

Finalmente quiero dejar un profundo gracias a todos mis familiares, demás amigos y compañeros, de quienes he aprendido mucho y me han brindado su apoyo desde siempre.

Para todos ellos: mi eterna gratitud.

Carlos

Página vi

A Anita, por haberme regalado la vida en dos ocasiones. Gracias madrecita por tu amor, entrega y apoyo, te quiero.

A mi abuela, por ser mi segunda madre. Siempre vivirás en mí.

A Elizabeth, por darme infinitas razones para seguir. Gracias dama mía.

A mis tíos, primos, y demás familiares por brindarme su afecto y apoyo siempre.

A la familia Peralta Suing, por ser mí segunda familia. A sus cuatro hijos por considerarme y haberse convertido en mis hermanos.

A Noxfero, por ser la voz que desde las profundidades de mi mente luchaba en las innumerables veces en las que ya no podía más.

Carlos

INTEGRACIÓN DE BUENAS PRACTICAS PARA LA DEFINICIÓN DE UN FRAMEWORK DE ARQUITECTURA EMPRESARIAL

ORIENTADO A LA UTPL

EA – UTPL - 1 - | P á g i n a

ESQUEMA DE CONTENIDOS

SECCION 1: VISION GENERAL DEL PROYECTO .............................................................. - 10 -

Introducción .......................................................................................................................... - 11 -

Objetivos ................................................................................................................................ -12 -

Resultados esperados ......................................................................................................... - 13 -

Fases del Proyecto ............................................................................................................... - 13 -

SECCION 2: VISION GENERAL DE LA ARQUITECTURA EMPRESARIAL ....................... - 14 -

1.0 INTRODUCCIÓN A LA ARQUITECTURA EMPRESARIAL ......................................... - 15 -

1.1 Introducción .................................................................................................................... - 15 -

1.2 Las Raíces de la Arquitectura Empresarial .................................................................. - 16 -

1.3 Definiendo qué es Arquitectura Empresarial ............................................................... - 20 -

1.3.1 ¿Qué se quiere decir con “Arquitectura”? ................................................................ - 20 -

1.3.2 ¿Qué se quiere decir con “Empresarial”? ................................................................ - 20 -

1.3.3 Concepción Formal ..................................................................................................... - 21 -

1.4 Dominio de la Arquitectura ............................................................................................ - 23 -

1.4.1 Arquitectura de Negocio ............................................................................................. - 24 -

1.4.2 Arquitectura de Información ....................................................................................... - 24 -

1.4.3 Arquitectura de Aplicaciones ..................................................................................... - 25 -

1.4.4 Arquitectura de Infraestructura .................................................................................. - 25 -

1.5 La importancia de de la transición entre “As is” y el “To be” .................................. - 25 -

1.6 EA como eje organizacional .......................................................................................... - 26 -

1.7 Potenciales ventajas y beneficios de una EA .............................................................. - 26 -

1.7.1 Beneficios para el cliente ............................................................................................ - 27 -

1.7.2 Beneficios para el Personal ........................................................................................ - 27 -

1.7.3 Beneficios para la Empresa ........................................................................................ - 27 -

1.8 La meta ............................................................................................................................ - 28 -

1.9 Enfoque arquitectónico hacía las TI ............................................................................. - 28 -

1.10 Gestión de la Arquitectura ........................................................................................... - 29 -


ORIENTADO A LA UTPL


1.11 Construyendo una EA .................................................................................................. - 30 -

1.11.1 Ciclo de vida Arquitectónico .................................................................................... - 30 -

1.11.2 Introducción a Lenguajes de Desarrollo ................................................................. - 31 -

1.11.2.1 Archimate ................................................................................................................ - 31 -

1.11.2.2 UML .......................................................................................................................... - 31 -

1.11.2.3 BPMN ....................................................................................................................... - 32 -

1.11.3 Introducción a Frameworks EA ................................................................................ - 32 -

1.11.3.1 Zachman .................................................................................................................. - 33 -

1.11.3.2 TOGAF ..................................................................................................................... - 34 -

1.11.3.3 FEA ........................................................................................................................... - 35 -

1.11.3.4 Gartner ..................................................................................................................... - 36 -

1.11.4 Introducción a Herramientas para EA ..................................................................... - 37 -

SECCION 3: ANALISIS DE FRAMEWORKS Y HERRAMIENTAS ...................................... - 39 -

2.0 FRAMEWORKS ............................................................................................................... - 40 -

2.1 Zachman .......................................................................................................................... - 40 -

2.2. TOGAF ............................................................................................................................ - 43 -

2.3. Federal Enterprise Architecture (FEA) ........................................................................ - 45 -

2.3.1. Perspectiva de FEA sobre la Arquitectura Empresarial ......................................... - 46 -

2.3.2. Modelos de Referencia ............................................................................................... - 47 -

2.3.3. Procesos de FEA ........................................................................................................ - 48 -

2.3.4. Medición del nivel de satisfacción ............................................................................ - 48 -

2.4. Gartner ........................................................................................................................... - 48 -

2.5. E2AF ................................................................................................................................ - 50 -

2.5.1. Visualización de E2AF ................................................................................................ - 51 -

2.6. Comparación .................................................................................................................. - 53 -

3.0 ANÁLISIS DE HERRAMIENTAS ..................................................................................... - 57 -

3.1 Enfoque ........................................................................................................................... - 57 -

3.2 Análisis dimensional ...................................................................................................... - 58 -

3.3 Funcionalidad ................................................................................................................. - 58 -


ORIENTADO A LA UTPL


3.3.1 Metodologías y Modelos ............................................................................................. - 58 -

3.3.2 Interface para el desarrollo de Modelos. ................................................................... - 61 -

3.3.3 Automatización de la Herramienta ............................................................................. - 63 -

3.3.4 Personalización y Extensión. ..................................................................................... - 64 -

3.3.5 Manipulación y Análisis .............................................................................................. - 66 -

3.3.6 Repositorio ................................................................................................................... - 67 -

3.3.7 Arquitectura de Implementación ................................................................................ - 69 -

3.3.8 Licenciamiento y Soporte Técnico ............................................................................ - 70 -

3.3.9 Resultados Arquitectónicos ....................................................................................... - 71 -

3.4 Utilidad ............................................................................................................................. - 73 -

3.5 Resultados de la evaluación .......................................................................................... - 74 -

SECCION 4: DEFINICION DEL FRAMEWORK .................................................................... - 77 -

4.0 ELEMENTOS CONSTITUTIVOS ..................................................................................... - 78 -

4.1 Introducción .................................................................................................................... - 78 -

4.2 Componentes ................................................................................................................. - 78 -

4.2.1 Método de desarrollo arquitectónico (ADM) ............................................................ - 78 -

4.2.2 El continuum arqauitectónico ................................................................................... - 78 -

4.3 Elementos ........................................................................................................................ - 78 -

4.3.1 Eventos de negocio ..................................................................................................... - 79 -

4.3.2 Organizaciones de negocio ........................................................................................ - 79 -

4.3.3 Ciclo de negocio .......................................................................................................... - 79 -

4.3.4 Calendario de Negocios .............................................................................................. - 80 -

4.3.5 Funciones de Negocio ................................................................................................ - 80 -

4.3.6 Sistemas de Información ............................................................................................ - 80 -

4.3.7 Dominios de Bases de Datos ..................................................................................... - 80 -

4.3.8 Clases tipo Objetos de Bases de Datos .................................................................... - 80 -

4.3.9 Objetos de Bases de Datos de Sistemas de Información ........................................ - 80 -

4.3.10 Nivel de Gestión ......................................................................................................... - 81 -

4.3.11 Misión ......................................................................................................................... - 81 -


ORIENTADO A LA UTPL


4.3.12 Universidades llevando a cabo misiones ................................................................ - 81 -

4.3.13 Universidades llevando a cabo funciones .............................................................. - 81 -

4.3.14 Cargos ........................................................................................................................ - 81 -

4.3.15 Cargos llevando a cabo misiones ............................................................................ - 81 -

4.3.16 Análisis del nodo de ciclo de vida de recursos ...................................................... - 82 -

4.3.17 Recursos .................................................................................................................... - 82 -

5.0 DEFINICION DEL FRAMEWORK .................................................................................... - 83 -

5.1 Fase Preliminar ............................................................................................................... - 84 -

5.1.1 Objetivos ...................................................................................................................... - 84 -

5.1.2 Enfoque de entregables .............................................................................................. - 85 -

5.1.3 Contexto organizacional ............................................................................................. - 85 -

5.1.3.1 Requerimientos que solvetan la adopción de la EA ............................................. - 86 -

5.1.3.2 Principios organizacionales .................................................................................... - 86 -

5.1.3.3 Frameworks de gestión ............................................................................................ - 86 -

5.1.3.4 Planeación para madurez de la EA ......................................................................... - 87 -

5.1.4 Definición del equipo de trabajo ................................................................................ - 90 -

5.1.5 Ejemplos de principios arquitectónicos .................................................................... - 92 -

5.1.6 Análisis de brechas ..................................................................................................... - 91 -

5.1.7 Entradas ....................................................................................................................... - 94 -

5.1.8 Salidas .......................................................................................................................... - 95 -

5.1.9 Definición del proceso de la fase preliminar ............................................................ - 96 -

5.1.10 Plantillas para la fase preliminar ............................................................................ - 101 -

5.1.10.1 Plantilla para el modelo organizacional de la UTPL .......................................... - 101 -

5.1.10.2 Plantilla para principios, objetivos y conductores del negocio ....................... - 107 -

5.1.10.3 Plantilla para principios arquitectónicos ........................................................... - 113 -

5.1.10.4 Plantilla para la solicitud del trabajo arquitectónico ......................................... - 117 -

5.1.10.5 Plantilla para la adaptación de la EA .................................................................. - 122 -

5.1.10.6 Plantilla para el repositorio arquitectónico ........................................................ - 126 -

5.2 Fase A: Visión Arquitectónica ..................................................................................... - 130 -


ORIENTADO A LA UTPL


5.2.1 Objetivos .................................................................................................................... - 130 -

5.2.2 Enfoque ...................................................................................................................... - 131 -

5.2.3 Escenarios de Negocio ............................................................................................. - 131 -

5.2.4 Entradas ..................................................................................................................... - 132 -

5.2.5 Salidas ........................................................................................................................ - 133 -

5.2.6 Definición del proceso de visión arquitectónica .................................................... - 135 -

5.2.7 Plantillas para la fase de visión arquitectónica ...................................................... - 143 -

5.2.7.1 Plantilla para la declaración del trabajo arquitectónico ..................................... - 143 -

5.2.7.2 Plantilla para la evaluación de la capacidad ........................................................ - 151 -

5.2.7.3 Plantilla para el plan de comunicaciones ............................................................. - 154 -

5.2.7.4 Plantilla para la visión arquitectónica .................................................................. - 157 -

5.3 Fase B: Arquitectura de Negocio ................................................................................ - 163 -

5.3.1. Objetivos ................................................................................................................... - 163 -

5.3.2 Enfoque ...................................................................................................................... - 164 -

5.3.3 Modelado de negocio ................................................................................................ - 164 -

5.3.4 Repositorio arquitectónico ....................................................................................... - 165 -

5.3.5 Entradas ..................................................................................................................... - 166 -

5.3.6 Salidas ....................................................................................................................... - 167 -

5.3.7 Definición del proceso de arquitectura de negocio ............................................... - 169 -

5.3.8 Plantillas para la fase de arquitectura de negocio ................................................. - 178 -

5.3.8.1 Plantilla para la especificación de los requisitos arquitectónicos .................... - 178 -

5.3.8.2 Plantilla para el Roadmap de la arquitectura ....................................................... - 182 -

5.4 Fase C: Arquitectura de Sistemas de Información ................................................... - 187 -

5.4.1 Objetivos .................................................................................................................... - 187 -

5.4.2 Enfoque ...................................................................................................................... - 187 -

5.4.3 Entradas ..................................................................................................................... - 188 -

5.4.4 Fase C1: Arquitectura de Datos ............................................................................... - 189 -

5.4.4.1 Objetivos ................................................................................................................. - 190 -


ORIENTADO A LA UTPL


5.4.4.2 Enfoque ................................................................................................................... - 190 -

5.4.4.3 Entradas .................................................................................................................. - 191 -

5.4.4.4 Salidas ..................................................................................................................... - 192 -

5.4.4.5 Definicón del proceso de la arquitectura de datos ............................................. - 194 -

5.4.4.6 Plantillas para la fase de la arquitectura de datos .............................................. - 202 -

5.4.4.6.1 Plantillas para especificación de la arquitectura de datos .............................. - 202 -

5.4.5 Fase C2: Arquitectura de Aplicaciones ................................................................... - 206 -

5.4.5.1 Objetivos ................................................................................................................. - 206 -

5.4.5.2 Entradas .................................................................................................................. - 207 -

5.4.5.3 Salidas ..................................................................................................................... - 208 -

5.4.5.4 Definicón del proceso de la arquitectura de datos ............................................. - 209 -

5.4.5.5 Plantillas para la fase de la arquitectura de aplicaciones .................................. - 218 -

5.4.5.5.1 Plantillas para especificación de la arquitectura de aplicaciones .................. - 218 -

5.5 Fase D: Arquitectura de Tecnología .......................................................................... - 223 -

5.5.1 Objetivos ................................................................................................................... - 223 -

5.5.2 Repositorio arquitectónico ....................................................................................... - 223 -

5.5.3 Modelo técnico referencial ....................................................................................... - 224 -

5.5.4 Entradas ..................................................................................................................... - 225 -

5.5.5 Salidas ........................................................................................................................ - 226 -

5.5.6 Definición del proceso para la arquitectura de tecnología .................................... - 228 -

5.5.7 Plantillas para la fase de la arquitectura de tecnología ......................................... - 239 -

5.5.7.1 Plantilla para la especificación de la arquitectura de tecnología ...................... - 239 -

5.6 Fase E: Oportunidades y Soluciones ......................................................................... - 244 -

5.6.1 Objetivos ................................................................................................................... - 244 -

5.6.2 Entradas ..................................................................................................................... - 244 -

5.6.3 Salidas ........................................................................................................................ - 245 -

5.6.4 Definición del proceso de la fase de oportunidades y soluciones ....................... - 247 -

5.6.5 Plantillas para la fase de oportunidades y soluciones .......................................... - 260 -

5.6.5.1 Plantilla para la arquitectura de transición .......................................................... - 260 -


ORIENTADO A LA UTPL


5.6.5.2 Plantilla el plan de implementación y migración ................................................. - 266 -

5.7 Fase F: Plan de Migración ........................................................................................... - 269 -

5.7.1 Objetivos .................................................................................................................... - 269 -

5.7.2 Entradas ..................................................................................................................... - 270 -

5.7.3 Salidas ........................................................................................................................ - 271 -

5.7.4 Definición de proceso para la fase de migración ................................................... - 273 -

5.7.5 Plantillas para la fase de migración ......................................................................... - 287 -

5.7.5.1 Plantilla para los bloques constitutivos de la arquitectura ................................ - 287 -

5.7.5.2 Plantilla para el contrato arquitectónico con socios y desarrolladores ........... - 290 -

5.7.5.3 Plantilla para el contrato arquitectónico con usuarios del negocio .................. - 296 -

5.8 Fase G: Implementación de Gobernanza ................................................................... - 301 -

5.8.1 Objetivos .................................................................................................................... - 301 -

5.8.2 Enfoque ...................................................................................................................... - 302 -

5.8.3 Entradas .................................................................................................................... - 302 -

5.8.4 Salidas ........................................................................................................................ - 303 -

5.8.5 Definición de proceso para la fase de gobernanza ................................................ - 304 -

5.8.6 Plantillas para la fase de gobernanza ...................................................................... - 310 -

5.8.6.1 Plantilla para bloques constitutivos de soluciones ............................................ - 310 -

5.8.6.2 Plantilla para la evaluación del cumplimiento ..................................................... - 313 -

5.9 Fase H: Gestión del Cambio de la Arquitectura ........................................................ - 316 -

5.9.1 Objetivos .................................................................................................................... - 316 -

5.9.2 Enfoque ...................................................................................................................... - 316 -

5.9.3 Conductores del cambio ........................................................................................... - 317 -

5.9.3.1 Proceso de gestión del cambio de la EA .............................................................. - 317 -

5.9.3.2 Directrices para mantener la EA en lugar de rediseñarla ................................... - 318 -

5.9.4 Entradas ..................................................................................................................... - 318 -

5.9.5 Salidas ........................................................................................................................ - 319 -

5.9.6 Definición del proceso para la fase de gestión del cambio ................................... - 321 -

5.9.7 Plantillas para la fase de gestión del cambio ......................................................... - 327 -


ORIENTADO A LA UTPL


5.9.7.1 Plantilla para la evaluación del impacto de los requisitos ................................. - 327 -

5.9.7.2 Plantillas para la solicitud de cambio arquitectónico ......................................... - 330 -

6.0 PLAN DE ACCIÓN PARA LA IMPLANTACION DEL PROYECTO EA_UTPL ........... - 333 -

6.1 Refinamiento del framework ........................................................................................ - 333 -

6.2 Implementación del la solución EA ............................................................................ - 333 -

6.2.1 Plan de acción ............................................................................................................ - 334 -

6.2.2 Análisis FODA ............................................................................................................ - 334 -

6.2.3 Plan de acción ............................................................................................................ - 334 -

7.0 CONCLUSIONES Y RECOMENDACIONES ................................................................. - 357 -

7.1 Conclusiones ................................................................................................................ - 357 -

7.2 Recomendaciones ........................................................................................................ - 357 -

ANEXOS ............................................................................................................................... - 358 -

Anexo 1: Recursos para EA - UTPL .................................................................................. - 359 -

1.1 Artefactos para EA - UTPL ........................................................................................... - 359 -

1.1.1 Artefactos de la fase preliminar ............................................................................... - 359 -

1.1.2 Artefactos para la visión arquitectónica ................................................................. - 361 -

1.1.3 Artefactos para la arquitectura de negocio ............................................................. - 363 -

1.1.4 Artefactos para la arquitectura de sistemas de información ................................ - 367 -

1.1.4.1 Artefactos para la arquitectura de datos .............................................................. - 367 -

1.1.4.2 Artefactos para la arquitectura de aplicaciones .................................................. - 369 -

1.1.5 Artefactos para la arquitectura de tecnología ........................................................ - 372 -

1.2 Plantilla para el levantamiento de la Arquitectura de TI de la UTPL ........................ - 374 -

Anexo 2: Índices y bibliografía .......................................................................................... - 390 -

2.1 Glosario de Figuras ...................................................................................................... - 391 -

2.2 Glosario de tablas ......................................................................................................... - 392 -

2.3 Blibliografía ................................................................................................................... - 393 -


ORIENTADO A LA UTPL


Anexo 3: Artículos del proyecto ........................................................................................ - 395 -

3.1 PLAN DE ACTUACIÓN PARA LA IMPLEMENTACIÓN DE UN FRAMEWORK ARQUITECTURA EMPRESARIAL ORIENTADO A INSTITUCIONES DE EDUCACIÓN SUPERIOR ....................................................................................................................... - 396 -

3.2 International Conference on Software Technology and Engineering (ICSTE 2010) / IEEE: Roadmap for the implementation of an Enterprise Architecture Framework Oriented to Institutions of Higher Education in Ecuador

Disponible en: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5608752


ORIENTADO A LA UTPL


EA – UTPL

SECCION 1:

VISION GENERAL DEL PROYECTO


ORIENTADO A LA UTPL


INTRODUCCIÓN

La gestión de las tecnologías de información juega un papel importante dentro la estructura

organizativa de las instituciones de educación superior. Manejar la infraestructura tecnológica,

servicios, recursos en línea y datos, se ha convertido en algunas de las principales preocupaciones

que los lideres de TI deben tomar en consideración para satisfacer a cada una de las funciones de la

UTPL y con esto responder a los cambios regulatorios, cambios del entorno externo, la creciente

competencia y la globalización, así como las expectativas cambiantes del medio ambiente.

La comprensión de las interrelaciones entre las personas, los procesos de negocio,

aplicaciones, datos, y tecnologías subyacentes será fundamental para lograr esta sinergia entre todas

las partes de la institución. De lo anterior deriva la necesidad del desarrollo de un enfoque de

Arquitectura Empresarial (EA) que será fundamental para manejar dichas interrelaciones. Es por ello

que el presente trabajo investigativo pretende integrar un conjunto de buenas prácticas para definir un

framework de EA que permita contar con un marco arquitectónico y conjugue la visión institucional

con las TI.

Si bien se puede afirmar que toda organización cuenta con un esquema EA informal o

empírico, es necesaria la adopción de un modelo formal, que nos lleve al establecimiento de una

efectiva gobernanza de TI. Así, la arquitectura una vez establecida nos servirá para conocer al

detalle cómo se manejará toda la estructura de negocio de toda la UTPL (o segmento arquitectónico).

En los capítulos siguientes de la presente tesis se integrará la información y componentes necesarios

(mejores prácticas) para consolidar la definición de un framework de arquitectura empresarial para la

UTPL.


ORIENTADO A LA UTPL


OBJETIVOS

Objetivo General

• Integrar las mejores prácticas que lleven a una definición robusta de un framework de arquitectura empresarial orientado a instituciones de educación superior basado en el contexto de la Universidad Técnica Particular de Loja.

Objetivos Específicos

• Definir los todos los conceptos para lograr un grado de comprensión integral de todo lo relacionado a la arquitectura empresarial.

• Establecer un análisis de los frameworks arquitectónicos más importantes para a partir de dicho análisis poder establecer la adopción, adaptación o definición del framework para la UTPL.

• Realizar un análisis y contrastación de herramientas orientadas para apoyar al enfoque arquitectónico (definición, modelado, etc).

• Definir un modelo de desarrollo para la EA (ciclo arquitectónico dentro del framework) junto con los procesos asociados a dicho modelo.

• Definir los entregables y artefactos asociados al framework a definirse.

• Establecer un plan de actuación para la implementación en la UTPL del framework desarrollado.


ORIENTADO A LA UTPL


Resultados esperados

• Visión de framework arquitectónico para la UTPL consolidada.

• Análisis comparativo de frameworks de mayor importancia.

• Modelo de desarrollo arquitectónico consolidado (ciclo arquitectónico dentro del framework).

• Artefactos y entregables levantados y listos para su uso cuando el framework requiera ser implementado en un futuro.

• Componentes arquitectónicos detallados.

• Análisis comparativo de herramientas para modelar y almacenar (repositorio) la arquitectura.

Fases del proyecto

• Inicio

o Definición y Alcance o Recursos o Cronograma

• Fase I

o Conceptualización teórica de la arquitectura empresarial. o Evaluación de frameworks para arquitectura empresarial. o Evaluación de herramientas para arquitectura empresarial. o Estudio de enfoques arquitectónicos en instituciones de educación superior. o Selección de frameworks (metodologías) y componentes.

• Fase II

o Definición del framework para la UTPL o Definición de artefactos y entregables del framework.

• Fase III

o Establecimiento de un plan de acción con fines de dejar especificado un

esquema de implementación del framework UTPL.

• Fase IV

o Levantamiento de documentación Final


ORIENTADO A LA UTPL


EA – UTPL

SECCION 2:

VISION GENERAL DE LA ARQUITECTURA EMPRESARIAL


ORIENTADO A LA UTPL


1.0 INTRODUCCIÓN A LA ARQUITECTURA EMPRESARIAL 1.1 Introducción

En términos operativos el área tecnológica es la más activa debido a que proporciona, mantiene y crea soluciones para apoyar a los objetivos del negocio. Es necesario realizar un análisis que vaya más allá de una formulación neta de software y hardware como solución única a un problema particular, así, el análisis debe cubrir el contexto del problema abarcando a todos los participantes involucrados. De la mano surge la necesidad de un manejo formal de políticas, límites, reglas, estándares, cambios de mercado, etc. de acuerdo a las condiciones dinámicas a las que se enfrenta la UTPL.

El concepto actual de Arquitectura Empresarial (EA, por sus siglas en inglés se utilizará esta nomenclatura para hacer mención a esta disciplina) implica una forma de representar de manera integrada y relacional a una organización, pudiendo considerar todos y cada uno de los elementos que la componen. Esto conlleva a poder establecer una visión de los negocios que ayuda a alinear la tecnología a las necesidades de la organización, desde una perspectiva estratégica. Por tanto es necesario definir una EA que armonice los factores: inversión tecnológica, requerimientos, aplicaciones, cambios en procesos, modelado de negocio, factores de mercado, recursos disponibles (humanos, técnicos) de todas las áreas para cumplir las metas integral y coordinadamente.

Luego de más de dos década de su creación formal, la EA ha madurado con enfoques específicos, siendo estructurada por directrices, modelos, restricciones, que parten del estado actual de la institución con respecto a la misión, para servir como puente de avance hacia la visión, o viceversa.

Esta disciplina se ha pulido constantemente para abordar dos grandes problemas evidentes en cuanto a tecnología de la información (TI) que dificultan la consecución de los fines formalizados en la visión. El primer problema está orientado a manejar la complejidad creciente de los sistemas de tecnología de la información, mientras que el otro inconveniente es la dificultad creciente para poder ofrecer un valor de negocio real con esos sistemas (alinear las TI a los objetivos de negocio).

Basada en las premisas referentes a la complejidad de sistemas y a un pobre alineamiento de negocio, la EA buscará como fin primario ofrecer el máximo valor de negocio a la UTPL. Se habla de una dependencia de ambos problemas porque el cómo se maneje la complejidad incidirá de manera directa en la mejora de las oportunidades para ofrecer un valor real al negocio. En las siguientes secciones se abordarán los aspectos integrales relacionados con las raíces a la EA, para poder llegar a una comprensión integral de cómo afrontar los dos problemas mencionados anteriormente.

El contexto particularizado de la necesidad de una Arquitectura Empresarial para la U.T.P.L., se erige sobre algunas razones más específicas:


ORIENTADO A LA UTPL


• Los datos se encuentran es repositorios (silos) usualmente separados y aislados, y se necesita un esfuerzo de trabajo significativo para tomar dichos datos de un sistema, manipularlos e ingresarlos en otro sistema (Ej: Sistema Académico, Sistema del Centro de Digitalización, el CEDIB).

• La información no fluye con facilidad, las TI son un cuello de botella para el manejo del cambio organizacional porque la información necesitada para tomar decisiones clave no está disponible. (Ej: No existe una formalización a nivel de TI con enfoque a SOA).

• Se observa una falta de integración de la información, esto significa que los estudiantes y/o el personal a menudo tiene que visitar varios sistemas para obtener la información que necesitan (Ej: Sistema académico y sistema de archivo si se deja de estudiar por un tiempo).

• Los procesos de trabajo, las prácticas, conocimientos, habilidades y el apoyo a sistemas de TI no están bien integrados para proporcionar capacidades estratégicas. (Hace falta un uso formal de estándares).

• La institución carece de la agilidad en cuanto a respuesta con algunos sistemas en periodos críticos (Ej: Cuellos de botella presentados durante el proceso de matriculación).

• La duplicación de procesos de negocio significa que una misma actividad se completa con diferentes sistemas en la institución. (Ej: Sistema académico y sistemas a medida para generación de estadísticas institucionales en base a los estudiantes)

• La alta dirección no tiene conoce si la institución recibe una inversión en sistemas de TI. (Ej: La adquisición de hardware y software no sigue una estrategia o arquitectura de TI estructurada)

• Diferentes partes de la Institución dan diferentes respuestas a las mismas preguntas del personal o de estudiantes. (Ej: Grupos de desarrollo, gerentes de proyecto, stakeholders con roles de usuario y alta gerencia tienen enfoques dispares con respecto a proyectos de la institución).

Estas y entre otras son algunas de las razones que han creado las interrogantes ineludibles para llegar a establecer la necesidad de formalizar un enfoque de EA en la UTPL a través de la búsqueda de la definición de un Framework.

Con la finalidad de abordar el problema es necesario tener claro algunos conceptos que permitan entender la real dimensión de lo que significa contar con una estrategia de TI basada en los principios de la EA, para llegar a ese punto es necesario conocer en inicio los orígenes e historia de esta disciplina.


ORIENTADO A LA UTPL


1.2 Las Raíces de la Arquitectura Empresarial

Figura 1: Línea de Vida de la Arquitectura Empresarial [5]

El campo de la arquitectura empresarial tuvo origen en 1987, con la publicación en el diario de sistemas de IBM de un artículo titulado "Un marco para la Arquitectura de Sistemas de Información", por Jhon A. Zachman1

“El coste involucrado y el éxito de una empresa dependen cada vez más en sus sistemas de información, se requiere un enfoque disciplinado para la gestión de esos sistemas. “[3]

. En ese documento, Zachman estableció tanto el reto y la visión de la EA que orientarían el campo para los próximos 20 años. El reto consistía en gestionar la complejidad de los sistemas que cada vez son enfocados a arquitecturas distribuidas. Zachman dice:

La visión de Zachman era que el valor y la agilidad del negocio podrían ser mejor realizadas por un enfoque holístico para la arquitectura de sistemas, es decir observar todos los temas importantes desde cada una de las perspectivas importantes. Su enfoque basado en múltiples

1 Mayor Información disponible en el sitio oficial: http://www.zifa.com/


ORIENTADO A LA UTPL


perspectivas para la arquitectura de sistemas es lo que él originalmente describió como “Framework Arquitectónico para Sistemas de Información”, luego renombrado como “Framework de Arquitectura Empresarial”.

Zachman fue la gran influencia para crear una EA en uno de los intentos más tempranos hechos por una rama del gobierno de EE.UU., el Departamento de Defensa (DoD). Este intento fue conocido como el “Framework de Arquitectura Técnica para Gestión de la Información” (TAFIM2

TAFIM y otras metodologías para ajustar mejor los proyectos técnicos enfocados a necesidades de la empresa fueron observadas por el Congreso de los EE.UU. Influenciados por los beneficios prometidos por TAFIM, el Congreso en 1996 aprobó una ley conocida como Ley Clinger-Cohen de 1996 [04], también conocida como la “Acta de ley para gestión de Tecnología de la Información”, esta establecía que todas las agencias federales debían tomar medidas para mejorar la eficacia de sus inversiones en TI. El Consejo de CIOs

) y fue introducido en 1994.

3

En Abril de 1998 el congreso de CIOs empezó a trabajar en su mayor proyecto, el “Framework de Arquitectura Empresarial Federal”

, formado por CIOs de todos los órganos gubernamentales más importantes, fue creado en 1996 con la finalidad supervisar este esfuerzo. [4]

4

Con el pasar de los años la responsabilidad de la Arquitectura Empresarial Federal pasó del congreso

(FEAF). La versión 1.1 [6] de este Framework fue lanzada en septiembre de 1999. Aquel documento contenía algunas ideas innovadoras, como el uso de arquitecturas segmentadas (que enfoca la EA en áreas de la empresa) por ejemplo.

5 de CIOs a la oficina de Gerencia y Presupuesto (OBM)6

La actividad de Arquitectura Empresarial en el Gobierno de EE. UU. ha sido enorme, pero el progreso se ha dado lentamente y los casos de éxito se ven ensombrecidos por grandes fracasos. En 2004, a ocho años de aprobada la ley Clinger-Cohen, la Oficina de Contabilidad General (GAO, por sus siglas en inglés) reportó:

. EN el año 2002 la OBM evolucionó y cambió la metodología FEAF dejándola como Arquitectura Empresarial Federal (FEA).

“Sólo 20 de 96 agencias examinadas habína establecido al menos las bases para la gestión eficaz de una arquitectura. Además, mientras que 22 agencias crecieron en madurez desde el año 2001, 24 agencias disminuyeron en madurez y 47 agencias permanecieron sin cambios.” [06]

2 Technical Architecture Framework for Information Management. Disponible en http://citeseerx.ist.psu.edu/viewdoc/summary?

doi=10.1.1. 25.1473 3 Chief Information Officer: Alto ejecutivo de una empresa, responsable de la tecnología de información y de los sistemas informáticos que

apoyan los objetivos de negocio. 4 Federal Enterprise Architecture Framework. Disponible en el sitio: http://www.cio.gov/Documents/fedarch1.pdf 5 Información sobre el congreso disponible en el sitio oficial: http://www. cio.gov/ 6 Office of Management and Budget. Mayor información disponible en el sitio official: www.whitehouse.gov/omb/


ORIENTADO A LA UTPL


Desde Enero de 2005, la GAO ha castigado severamente a varias agencias de EE. UU. por fallas en su adopción o uso de Arquitectura Empresarial. Algunos ejemplos abarcan el FBI, el Departamento de Defensa, el Departamento de Seguridad Nacional y la NASA.

En 1998, cuatro años luego de la aparición del TAFIM, este fue oficialmente retirado por el departamento de defensa. El trabajo realizado por esta metodología fue entregado al “The Open Group”. Ellos lo transformaron en un nuevo estándar que es conocido hoy como “El Framework Arquitectónico de The Open Group”, (TOGAF)7

Durante 2005, casi al mismo tiempo en el que OBM se estaba convirtiendo en la fuerza dominante para el sector público, otra organización adoptó medidas para convertirse en una fuerza dominante para el sector privado, este grupo se llama Gartner

.

8

Gartner había luchado para construir una arquitectura empresarial práctica, pero nunca alcanzó el rango de Meta Group. En 2005, Gartner decidió que si no podían competir con Meta Group, debería dar el mejor paso maestro siguiente: Comprarlo.

. En ese año Gatner ya era una de las organizaciones más influyentes especializadas en consultoría a nivel de CIO, para el área específica de EA el grupo de asesoramiento e investigación de TI no era Gatner, sino el Meta Group.

Tras la compra de Meta Group, Gartner/Meta pasaron un año observando y analizando lo que cada compañía tenía hasta ese entonces en cuanto a Arquitectura Empresarial y Metodologías. Las dos empresas discutieron la mejor manera de conciliar sus métodos a menudo muy diferentes. Al final, un algoritmo bastante simple fue aplicado para resolver lo anerior: Si a Meta le parecía bien, estaban dentro, si no le parecía, estaban fuera siendo absorbidos totalmente por Gatner. El Grupo Meta aceptó el proceso arquitectónico, el cual dejaba fuera los Frameworks y se centraba en los procesos.

En los últimos años, se ha comprobado con mayor exactitud el beneficio clave que se puede obtener de la EA, es decir la capacidad de apoyar la toma de decisiones en el cambio de las empresas. Debido a que la EA reúne a los modelos de negocio (por ejemplo, modelos de procesos, organigramas, etc) y modelos técnicos (por ejemplo, arquitecturas de sistemas, modelos de datos, diagramas de estado, etc) es posible determinar el impacto del cambio organizacional sobre los sistemas, y también el impacto en el negocio de los cambios a los sistemas.

Debido a estos beneficios han aparecido algunos Frameworks como DoDAF, MODA, AGATE, CIMOSA, PERA o SAGA que han adoptado un modelo de metadatos estándar para definir los elementos críticos de arquitectura y las dependencias entre ellos. Las aplicaciones basadas en estos modelos pueden consultar la información especializada en arquitectura subyacente, proporcionando un mecanismo simple y fuerte para el seguimiento de estrategias a los efectos organizativos y tecnológicos. La figura 1 mostrada en principio ilustra la línea de vida correspondiente a la aparición de los distintos Frameworks EA.

7 The Open Group Architectural Framework. Disponible en el sitio oficial: http://www.opengroup.org/togaf/ 8 Mayor información disponible en el sitio oficial: http://www.gartner.com/


ORIENTADO A LA UTPL


1.3 Definiendo qué es Arquitectura Empresarial

“Tal como las construcciones, las empresas pueden ser descritas en términos de su arquitectura. A veces dicha arquitectura es resultado de planeación, otras simplemente aparece.” [2]

1.3.1 ¿Qué se quiere decir con “Arquitectura”?

La IEEE cuando emprendió la formalización de aspectos relacionados al trabajo arquitectónico creó el estándar IEEE 1471, a pesar de la dificultad y lo elusivo del concepto, ANSI/IEEE publicaron en Octubre del año 2000 lo que es denominado “Práctica Recomendada” en la que una arquitectura es definida como:

“La organización fundamental de un sistema, consagrada en sus componentes, sus relaciones entre sí y entre el entorno, y los principios que guían su diseño y evolución”

Otro punto a considerarse es que la palabra arquitectura implica un enfoque hacia el software u otro tipo de sistema técnico. De ello deriva que un arquitecto empresarial no es lo mismo que un analista de sistemas y la EA no es un proceso que debería ser controlado por el departamento de sistemas de información. EA compete a la tecnología en el sentido de que esta tiene características operacionales, proveyendo así un contexto operacional y necesidades únicas para alinear la tecnología con otros aspectos del negocio.

1.3.2 ¿Qué se quiere decir con “Empresarial”?

Este término es un recurso de mayor confusión que el término arquitectura, debido principalmente a su amplitud, ya que la literatura general y documentación técnica están orientadas a un lenguaje orientado a negocios, esto supone una dificultad para adoptar el término adecuadamente si hablamos de organizaciones del sector público. Sin embargo, The Open Group Plantea una definición bastante clara en TOGAF [1] que condensa el término en dos partes y las explica:

“Empresa, es cualquier colección de organizaciones (o áreas) que tienen un conjunto común de metas y/o un simple resultado final. El término Empresa en el contexto de la Arquitectura Empresarial puede ser usado para denotar ambas: Una empresa entera (abarcando la totalidad de sus sistemas de información) y un dominio específico dentro de la empresa. En ambos casos, la arquitectura cruza múltiples sistemas y grupos funcionales dentro de la empresa”.

Si sustituimos la palabra “institucional” por “empresa” y eliminamos las referencias a resultados finales, entonces podemos tener una definición más cercana al contexto de la UTPL, es decir, un contexto netamente educacional. Nuestra empresa es la institución, en este caso, la Universidad.

The Open Group implica la consideración de la arquitectura de un modelo con un dominio estructural específico (un área o facultad) dentro de la empresa, o incluso se profundiza en una


ORIENTADO A LA UTPL


especialización particular del campus como bibliotecas, registros de estudiantes, etc. En términos prácticos, este enfoque puede parecer una base razonable para empezar un análisis de la “empres” en conjunto.

1.3.3 Concepción Formal

“El término Arquitectura Empresarial (EA) se refiere a una colección estructurada, armonizada y dinámica de planes que tienen como fin el desarrollo de un panorama empresarial de TI” [2]. La variedad de niveles de detalle y de vistas permiten que el arquitecto empresarial represente varios aspectos de sistemas de información y su alineamiento con el negocio. Esto manejado desde un enfoque de escenario tridimensional en función del tiempo (en el pasado, presente y escenarios futuros). Esta arquitectura:

• Se organiza en varios niveles de detalle y puntos de vista. • Está diseñada específicamente para Stakeholders específicos (por ej: administradores,

planificadores, los propietarios y diseñadores). • Ilustra los diferentes aspectos de los sistemas informáticos (por ej: datos, funciones, interfaces,

plataformas, redes) y su alineamiento con el negocio (por ej: objetivos, estrategias, procesos de negocio).

Proveer una definición absoluta de EA es complejo, Lankhorst [2] usa en cambio una idea de estructura organizacional para ofrecer una definición: “Arquitectura Empresarial es un todo coherente de principios, métodos y modelos que son usados en el diseño y realización de la estructura organizacional de la empresa, procesos de negocio, sistemas de información e infraestructura”.

Puede ser visto formalmente también como un esquema mediante el cual se representan todos los componentes, procesos y políticas que maneja una determinada organización con el fin de alinear las reglas de negocio a las TI existentes a nivel organizacional. Sin embargo es importante considerar que “La arquitectura empresarial no provee la arquitectura específica de un sistema (netamente), pero provee los servicios, estándares, conceptos de diseño, componentes y configuraciones que pueden ser usadas para guiar el desarrollo de la arquitectura tecnológica que da cumplimiento a requerimientos específicos”. [6]

Cualquier EA describe a la empresa como una estructura coherente y documenta el estado actual de la organización, el estado deseado y la brecha entre ambos. El modelo de arquitectura de sistemas no debe ser visto como una cápsula. Las características de la arquitectura deben haber sido consecuencia de un análisis del negocio del cual se partirá para determinar la estrategia de sistemas (Arquitectura de negocio).

La estrategia de un enfoque genérico convencional emplea cuatro perspectivas (negocio, información, aplicaciones y tecnología) para disminuir la brecha entre las necesidades de la empresa y la tecnología. Estas perspectivas describen los procesos necesarios para alcanzar las metas corporativas. Cada perspectiva describe el estado actual, el estado futuro y la brecha entre ambos de


ORIENTADO A LA UTPL


manera granulada. La meta es tomar decisiones estratégicas efectivas en el área de información tecnológica. Es importante no perder de vista que la tecnología es sólo un subsistema del sistema conocido como negocio. Es de suma importancia que la dirección general coordine todos los factores y recursos que intervienen en el sistema. El grado de éxito será logrado en la medida que estos factores y recursos interactúen adecuadamente. Como todo proceso, la estrategia de sistemas puede ser medida y controlada, la mejora en el proceso de implementación de soluciones para el negocio es uno de los beneficios de ver la estrategia como un flujo o proceso.

Al final se tiene una base de procesos para la parte tecnológica de esta manera el conocimiento se incorpora al negocio. Con esta metodología se cumple la meta de alinear la tecnología a las necesidades del negocio.

Una forma de comprender esto, es considerar en donde la EA se adapta como un proceso de gestión. Lankhorst representa la EA dentro de una pirámide de gestión de procesos. En la cúspide se encuentra la misión de la empresa, la razón por la que esta existe. En los niveles inferiores se encuentran toda la visión y la estrategia empresarial, más abajo bajo una Gestión Senior se crean metas estratégicas para partir de “como es” a un futuro escenario llamado “Ser”. Traduciendo esas metas en cambios a los procesos de negocio, a las operaciones diarias y a los Sistemas TI es donde la EA entra en el juego.

Figura 2: Arquitectura Empresarial como Herramienta de Gestión [7]


ORIENTADO A LA UTPL


1.4 Dominio de la Arquitectura

Llamado también dimensión o anatomía, abarca las áreas clave de la vida organizacional, incluyendo al personal y sus dominios de trabajo que conforman la organización. La EA a veces es referida como el “lugar” en donde todas las áreas clave se reúnen.

Hay varios enfoques de estructuración del dominio de la EA, estos esencialmente se distinguen entre ellos en términos del número de niveles arquitectónicos que abarcan, la demarcación de esos niveles y su granularidad. Una estructura generalizada y simplificada planteada en [2] considera tres elementos esenciales que son relevantes para la toma de decisiones y la gestión en contexto de la EA. La figura 3 ilustra dichos componentes:

Figura 3: Dimensiones Base de una EA [2]

Algunas representaciones incluyen más niveles o subniveles, estos modelos son mencionados y utilizados por diversas metodologías y abarcan aspectos de seguridad, información, datos e integración de la arquitectura. Los componentes adicionales mencionados pueden ser apropiadamente asignados al modelo básico mostrado en la pirámide de la Figura 3, sin embargo la experiencia ha demostrado que los modelos de EA complejos tienden a generar volúmenes de datos que son difíciles de manejar, más cuando se usa la arquitectura para propósitos de análisis y planeación. “Aunque los modelos complejos pueden ser exactos, en términos prácticos resultan inútiles.” [2]


ORIENTADO A LA UTPL


Dado el dominio base y para efectos de un mejor análisis y comprensión se hará una explicación de un modelo basado en cuatro elementos (Negocio, Información, Aplicaciones, Tecnología), como lo muestra la figura 4:

Figura 4: Dominio de EA [1]

1.4.1 Arquitectura de Negocio

En esta dimensión se define la estrategia de negocio, el gobierno, la organización, y los

procesos dominantes del negocio de la organización. Usualmente se encuentra estructurada por: • Mapas de estrategias, objetivos, políticas corporativas, modelo de operación. • Descomposiciones funcionales (por ejemplo, IDEF0, TDAA), capacidad empresarial y modelos

de organización expresados como arquitecturas de empresa / línea de negocios. • Procesos de negocio, de flujo de trabajo y normas que articulan las autoridades asignadas,

responsabilidades y las políticas. • Ciclos de Organización, periodos y plazos. • Proveedores de hardware, software y servicios.

1.4.2 Arquitectura de Información

Describe la estructura de los datos físicos y lógicos de la organización, y los recursos de gestión de estos datos e información. Usualmente esta dimensión abarca


ORIENTADO A LA UTPL


• La arquitectura de información, que brinda una visión holística sobre el flujo de información en la empresa.

• Metadatos, abarcando datos que describen los elementos de datos de la empresa. • Modelos de datos, conceptualmente expresados como arquitecturas de información de la

empresa, lógicas y físicas.

1.4.3 Arquitectura de Aplicaciones

Proporciona un modelo para los sistemas individuales que se desplegarán, las interacciones entre dichos sistemas y sus relaciones a los procesos del negocio de base de la organización. Esta dimensión usualmente está estructurada por:

• Inventarios de software y diagramas, expresado como arquitecturas conceptual / funcionales o como sistemas de empresa / línea de negocio.

• Interfaces entre aplicaciones, es decir, eventos, mensajes y flujos de datos.

1.4.4 Arquitectura de Infraestructura

Describe la estructura de hardware, software y redes requerida para dar soporte a la implantación de las aplicaciones principales y de misión crítica, de la organización. Esta dimensión se halla estructurada por:

• Un middleware entre aplicaciones. • Entornos de ejecución de aplicaciones y marcos operativos, incluyendo las aplicaciones de

entornos de servidores y sistemas operativos, entornos de autenticación y autorización, sistemas de seguridad y de funcionamiento, y sistemas de monitoreo.

• Hardware, plataformas y hosting como servidores, centros de datos y salas de ordenadores. • Redes de área local y amplia, diagramas de conexión a Internet. • Intranet, Extranet, Internet, comercio electrónico, vínculos EDI con los colaboradores dentro y

fuera de la organización. • Sistema Operativo. • Software de infraestructura, como Servidores de aplicaciones, DBMS, etc. • Lenguajes de programación, etc expresado como arquitectura de empresa / línea de negocio de

la tecnología.

1.5 La importancia de de la transición entre “As is” y el “To be”

Partiendo del hecho del “as is” asociado a la línea base y del “to be” como el objetivo, es importante considerar estos dos puntos dentro del desarrollo arquitectónico. La organización presta atención y asigna recursos para solventar lo que la esta busca ser en el futuro, pero también hay un grado de conciencia pleno respecto al estado actual (activos de información existentes, procesos de negocio, estructuras organizacionales, infraestructuras varias, etc).


ORIENTADO A LA UTPL


Partiendo de esos dos hechos, es muy importante que el proceso que especifique la línea base sea tomado con la mayor seriedad del caso por de él derivarán las acciones iniciales a tomar y la ruta a seguir en busca de la EA objetivo. La retroalimentación de los profesionales ejemplifica la importancia de esto: No se puede saber a dónde va alguien mientras no se tenga claro en dónde se está. También es de valor notar que la mayoría de instituciones tiene en algún sentido una “arquitectura”, incluso si esta haya sido llevada informalmente y no se haya documentado.

Identificar el estado actual puede servir también para encontrar brechas, redundancias y activos de datos ocultos, así como mostrar quién hace qué y en dónde dentro de la institución en la que lo hace. Tal proceso debe incluir alguna forma de análisis estratégico de brechas liderando la documentación de un Roadmap (ruta de camino) para la Arquitectura.

1.6 EA como eje organizacional

Cada área de análisis de la EA puede ser considerada como una disciplina de estrategia separada, ya que se enfoca en distintos niveles separados de personas dentro de una organización. A menudo cada grupo tiene sus propias herramientas, métodos, reglas, principios y políticas, etc., así como medios distintos de comunicar y compartir información sobre su área. Entonces ellos deben tener su “propia forma” de arquitectura, es decir, una particularización a medida de la EA global que especifique sus formas de “llevar las cosas”.

El hecho de considerar a la EA como eje fundamental dentro de la organización se funda en la capacidad de la EA de actuar como un elemento cohesivo (pegamento) que reúne las particularidades mencionadas en un Framework, ofreciendo así un balance a toda la empresa. Esta también es la razón base por la que la EA es llamada muchas veces “Meta Arquitectura”.

1.7 Potenciales ventajas y beneficios de una EA

Las ventajas y beneficios dependen estrictamente del modelo de dominio que se utilice para el desarrollo de la EA. En términos generales la premisa “LA EA soporta gestión de TI logrando que se hagan las cosas correctas de la manera correcta con un mínimo riesgo” [Alemán] garantiza la eficiencia y efectividad, mientras que la ausencia de riesgos no es más que alta seguridad. Las ventajas más significativas que ofrece son:

• Debido a que es una práctica de mejora continua, plantea una metodología que madurará gradualmente a medida que la organización la vaya adoptando.

• Promueve una visión integral del modelo de negocio, basándose en la interacción de todas las dimensiones involucradas.

• Ayuda a crear un repositorio único de información donde se incluyen los modelos que reflejan los procesos de la empresa, estos artefactos plasman las dimensiones que definen al negocio, además de identificar la relación que existe entre ellas.

• Brinda soporte a la operación, identificando impactos en los ajustes al modelo de negocio para conocer las implicaciones de un cambio, antes de arrancar un esfuerzo o nuevo proyecto.


ORIENTADO A LA UTPL


• Proporciona información para generar posibles escenarios de solución y de esta manera sirva como herramienta para la toma de decisiones en los ajustes a los procesos.

Existen beneficios inmediatos en las áreas globales:

• Eficiencia de TI: Involucra hacer bien las cosas. • Efectividad de TI: Involucra hacer las cosas que deben hacerse (las correctas). • Confiabilidad de la EA: Hacer las cosas con un mínimo riesgo.

Pero se puede hacer una división tricotómica más detallada de beneficios en base a tres áreas, como se muestra a continuación.

1.7.1 Beneficios para el cliente

Los clientes de la empresa cuentan con una organización más eficiente y oportuna capaz de adaptarse a las necesidades del entorno y ofrecer servicios estandarizados con tiempos de respuesta adecuados.

1.7.2 Beneficios para el Personal

Se derivan de aspectos como conocer oportunamente información integral relevante sobre cómo funciona la organización, por medio de los modelos de referencia. Esto implica el conocer a detalle cómo funcionan los procesos en los que interviene cada persona, así como otros procesos con los que se tiene contacto, para obtener mejores resultados como equipo.

Brinda una clara identificación de tareas y recursos que facilitan la operación, así como el evitar duplicación de tareas y esfuerzos, aprovechando mejor las habilidades y áreas de experiencia y especialización de todo el personal.

Es posible trabajar en un ambiente ordenado de mejora continua que mantiene vigentes los esfuerzos de la organización. Así como también ofrece un grupo interdisciplinario de información oportuna y especializada que permite evaluar las propuestas de cambios del personal y apoya a la toma de decisiones al respecto.

1.7.3 Beneficios para la Empresa

Desde un enfoque organizacional integral cuenta con un marco de referencia que documenta la operación de la empresa en modelos actualizados constantemente, que permiten tener una visión integral de la organización. También brinda conocimiento sobre las interrelaciones entre las dimensiones que se haya seleccionado como las más importantes.

Ayuda a identificar los elementos que impactan cada vez que existe un ajuste a la operación o nuevo proyecto de manera integral y sistémica para poder reaccionar rápidamente ante esos cambios.


ORIENTADO A LA UTPL


Esto lleva a un beneficio derivado de trabajar con una práctica institucional, a lo largo de la organización, que haga de la mejora continua un ejercicio estandarizado, ordenado y productivo.

Finalmente brinda un soporte robusto de herramientas que aportan elementos para la toma de decisiones, para “armar” proyectos que afectan positivamente en el cumplimiento de los objetivos de la organización.

1.8 La meta

Como ya se ha mencionado la principal meta de la EA es Hacer las cosas correctas de manera correcta, mejorando la seguridad. Se busca crear transparencia y establecer un instrumento de navegación para el proceso de gestión y un control efectivo, así se revelan las dependencias ocultas y puntos de impacto. Esto es la base para apreciar cómo las metas, productos, procesos de negocio, aplicaciones, plataformas, infraestructura y equipamiento están ligados unos a otros.

Mediante la detección de factores a considerarse al inicio del proyecto, se determinan las tareas necesarias para saber en dónde será necesario que intervengan dichos factores, en dónde deben ser esenciales para adaptarse a interfaces, revisar definiciones de productos, reformular textos de ayuda, y configurar la infraestructura.

Una fortaleza de la EA es que puede ser aplicada a un área o la empresa en su totalidad. Contiene la información esencial para planear, organizar, guiar y controlar cada unidad de TI. Así se convierte la EA en el esqueleto de la Gobernanza de TI.

1.9 Enfoque arquitectónico hacía las TI

La Arquitectura Empresarial es un meta-modelo (un gran plan) enfocado a Sistemas de TI, Se describen los sistemas en base a dos dimensiones: componentes y capas, especificando tareas y capacidades asociadas a esas dimensiones, alinea de esta manera los componentes a requerimientos funcionales/no funcionales:

• Qué componente es necesario para cumplir una misión específica o requisito técnico. • Qué requisitos se cumplen en cada componente. • Qué componentes generan nuevas necesidades. • Qué requisitos son mutuamente dependientes o contradictorios.

El plan también especifica las interfaces entre los componentes y capas y entre el sistema y su ambiente externo. Además, establece convenios para la realización de las interfaces y describe el comportamiento del sistema de comunicación.

El estándar ANSI / IEEE 1471 - 2000 nos dice: "Conceptualmente una arquitectura de TI es la organización fundamental de un sistema, encarnada en sus componentes, sus relaciones entre sí y el medio ambiente y los principios que gobiernan su diseño y evolución.


ORIENTADO A LA UTPL


Prácticamente se representa en las descripciones arquitectónicas de los puntos de vista de los interesados." [1] Precisamente por ese enfoque mencionado es que la EA se orienta formalmente hacía las TI.

1.10 Gestión de la Arquitectura

Comprende la planificación, desarrollo, uso y mantenimiento de la EA. Organiza los procesos correspondientes, las guías y el control del desarrollo. Así se puede decir que prescribe métodos para lograr la estrecha integración entre los procesos de negocio, aplicaciones e infraestructura de TI.

Figura 5: Gestión de la EA [2]

Esta gestión es responsable de:

• Los procesos estratégicos para la documentación, análisis y planificación de la EA. • Los procesos operativos para la aplicación general de la EA y de comprobación del

cumplimiento con los modelos de arquitectura referenciales y estándares definidos de la infraestructura.

• La definición de los procedimientos de documentación. • Análisis y metodologías de planificación. • Procedimientos de evaluación. • Herramientas y su integración en el ámbito adecuado. • Procedimientos y responsabilidades • Figuras clave y control.

La arquitectura tiene una gestión operativa y una dimensión estratégica. Documentación de

EA estratégica, análisis y la planificación son necesarios para generar medidas que se llevarán a cabo en los proyectos o actividades lineales. La gestión de la arquitectura está en la obligación de ofrecer un apoyo concreto (por ej: mediante el desarrollo de modelos de arquitectura de referencia en las


ORIENTADO A LA UTPL


áreas de software y arquitectura de sistemas, así como el control de su aplicación e implementación) y, en general, conseguir las cosas sigan su ritmo normal.

La gestión comprende todos los procesos, métodos, herramientas, responsabilidades y

normas que son necesarias para que las cosas funcionen, para asegurarse de que los sistemas de TI hacen exactamente lo que tienen que hacer.

1.11 Construyendo una EA

Debido a su naturaleza socio-técnica, la EA involucra a stakeholders internos y externos dentro de la institución. Por esta razón se han desarrollado varias metodologías estructuradas así como frameworks para poder desarrollar y mantener una arquitectura (o partes de ella). Todas las metodologías y frameworks tienen un ciclo de vida arquitectónico, definen los entregables que serán producidos en cada nivel y como estos deben ser verificados y probados. A continuación se abordan algunos aspectos a considerarse en la construcción.

1.11.1 Ciclo de vida Arquitectónico

Figura 6: Ciclo de Vida Genérico de una EA [7]

Un ciclo de vida genérico podemos observarlo en la figura 6, en la cual se ilustran los pasos generales que a menudo tienen lugar en el desarrollo de una EA. Es importante notar la naturaleza crítica del ciclo de vida, el uso de arquitecturas base y objetivo, la necesidad de adquisición ejecutiva y el control dado por la gobernanza.


ORIENTADO A LA UTPL


1.11.2 Introducción a Lenguajes de Desarrollo

1.11.2.1 Archimate

ArchiMate es un lenguaje para modelado de arquitectura empresarial abierto e independiente, forma parte de los estándares abiertos organizados por el The Open Group y se basa en el estándar IEEE 1471. Es apoyado por varios proveedores de herramientas y las empresas consultoras.

Figura7: ArchiMate Architectural Framework basado en Henk Jonkers (2004) [13]

Este lenguaje se distingue de otros como el Lenguaje Unificado de Modelado (UML) y Business Process Modeling Notation (BPMN) por su bien definido metamodelo , y un mayor ámbito de modelado y de aplicación EA. Define un lenguaje para diseñar y modelar una EA en tres niveles (business, application, technology). Archimate permite modelar una EA con cierto nivel de abstracción adecuado para el arquitecto (enterprise architect) y los usuarios del negocio. Un modelo en Archimate puede ser extendido a UML o BPMN para proveer un mayor nivel de detalle si fuese necesario.

1.11.2.2 UML

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el


ORIENTADO A LA UTPL


sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

1.11.2.3 BPMN

Es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). El principal objetivo de BPMN es proveer una notación estándar que sea fácilmente leíble y entendible por parte de todos los involucrados e interesados del negocio (stakeholders). Entre estos interesados están los analistas de negocio (quienes definen y redefinen los procesos), los desarrolladores técnicos (responsables de implementar los procesos) y los gerentes y administradores del negocio (quienes monitorizan y gestionan los procesos). En síntesis BPMN tiene la finalidad de servir como lenguaje común para cerrar la brecha de comunicación que frecuentemente se presenta entre el diseño de los procesos de negocio y su implementación.

1.11.3 Introducción a Frameworks EA

Existen varios frameworks, pero se deberá prestar especial atención a los cuatro enfoques más relevantes de esta disciplina, se deberán contrastar a profundidad Zachman, FEA, TOGAF y Gartner. Es por ello necesario abordar brevemente a cada metodología y considerar un estudio [18] propuesto por Gartner en el que predice que el 95% de las organizaciones soportarán múltiples enfoques de EA hasta el año 2015.

Gartner ha identificado en su estudio cuatro enfoques arquitectónicos de EA: tradicional, federado, medio exterior y diversidad gestionada. El análisis ha demostrado que la mayoría de practicantes de la disciplina EA harán uso de una mezcla de más de uno de estos enfoques basados en sus necesidades de negocio. Los enfoques mencionados se definen como:

• Tradicional: el equipo de EA toma como base la estructura organizacional para facilitar el proceso de EA, se centra en el contenido normativo que sirve para guiar la consistente toma de decisiones de proyectos con el plan maestro consagrado a la arquitectura. Este enfoque tiende a funcionar bien en organizaciones en las que gran parte de la toma de decisiones es centralizada y son relativamente estables en términos del ritmo de cambio. No funciona tan bien en organizaciones donde la toma de decisiones y la autoridad son distribuidas y donde el ritmo de cambio en los negocios es alto.

• Federado: hecho para organizaciones grandes y complejas, en donde la toma de decisiones es a menudo muy descentralizada, con unidades de negocio caracterizadas por una considerable autonomía en la EA. Una arquitectura federada se centra en definir el núcleo y elementos comunes entre los departamentos y unidades. Este enfoque se adapta bien a las


ORIENTADO A LA UTPL


organizaciones distribuidas geográficamente y es menos eficaz en las organizaciones altamente centralizadas con un negocio homogéneo.

• Medio exterior: es una aproximación a EA por la que los arquitectos se centran en la gestión de las dependencias clave entre las partes de la organización que tengan el mayor impacto en la capacidad de cambio. Este enfoque se centra en la interoperabilidad arquitectónica mediante la definición de un pequeño, pero robusto, conjunto de general de estándares estables de interfaz, al tiempo que permite una completa autonomía de la toma de decisiones para las tecnologías y productos específicos que se usan en las soluciones. Este enfoque es muy adecuado para las organizaciones y los "ecosistemas de negocios", donde las unidades de negocio, socios y proveedores no están bajo el control directo de un equipo central de EA.

• Diversidad gestionada: se centra en la definición de varias opciones. Este enfoque de EA conjuga la necesidad de un conjunto de normas con la necesidad de una diversidad de soluciones para aumentar la innovación, el crecimiento empresarial y ventaja competitiva. Los equipos de proyectos pueden decidir cuál es el producto mejor se adapte a las necesidades del proyecto, en lugar de tener una única norma que les imponga. La ventaja de este enfoque es que permite a los usuarios y equipos (de la EA) seleccionar la herramienta correcta para su trabajo, lo que permite la innovación desde la diversidad. La desventaja de este enfoque es que los usuarios y equipos del proyecto deben aceptar una mayor responsabilidad en sus decisiones.

Con un enfoque combinado de EA, las organizaciones tratarán de determinar el equilibrio

apropiado de control de su arquitectura mediante la aplicación de un enfoque arquitectónico adecuado. Esto significa que el equipo de EA tendrá que determinar un framework de decisión que les permitirá evaluar y ponderar qué enfoque se deberá usar para cualquier solución que se deba dar, definiendo qué podría ser más apropiado considerando la tecnología, información y aspectos de negocio. 1.11.3.1 Zachman

Se define formalmente como una taxonomía de “artefactos arquitectónicos”9

El propio John Zachman describe su trabajo de la siguiente manera:

en términos de una organización (es decir, documentación, especificaciones, modelos) que son utilizados en asuntos particulares dentro del movimiento de la empresa de acuerdo al direccionamiento que se tenga de algún asunto en el que se mueve el negocio.

El Framework EA tiene su aplicación en las empresas como una estructura lógica simple de

clasificación y organización, las representaciones descriptivas de una Empresa que son importantes para la administración de la misma, como también el desarrollo de los Sistemas Empresariales. [10]

Según Zachman: el esquema del Framework ha estado con nostros por cientos de años, y estoy seguro que lo estará aún por un ciento de años más. Lo que cambiaremos será el entendimiento de éste y cómo lo usaremos para le Ingeniería Empresarial y Manufactura [11].

9 Cualquier entregable tangible desarrollado en base a las necesidades organizacionales.


ORIENTADO A LA UTPL


La siguiente dimensión que propone Zachman es un enfoque descriptivo de los artefactos,

entonces las preguntas esenciales a responder son: qué, cómo, cuándo, dónde, quién y por qué del proyecto. El contexto de éstas preguntas se verá afectado por quién es el propietario que formula las preguntas, de acuerdo a la necesidad imperante en un momento determinado.

La idea estructural que sugiere Zachman sobre la EA, insinúa una composición en celdas particulares en las que se enmarcará solamente un artefacto, con este objeto se evitará que exista ambigüedad, debido a que siempre se conocerá cuál es el lugar en el que habita un artefacto determinado.

Una segunda sugerencia dentro de la taxonomía de Zachman indica que se deberá considerar un trabajo cumplido siempre y cuando se haya concluido con una celda particular. Esto garantizará que no se produzcan mezclas en los propietarios del trabajo y los artefactos en desarrollo.

Cuando cada una de las celdas dispuestas en una parrilla (grid) está llena con cada uno de los artefactos que conforman el Sistema, cada uno de los participantes tendrá una visión más amplia de éste, desde cada uno de los ángulos de disposición, obviamente con el enfoque de EA. 1.11.3.2 TOGAF

TOGAF se define a sí mismo como un Framework, no obstante, la parte más importante de

TOGAF es su Método de Arquitectura de Desarrollo, el cual es mejor conocido como ADM.

El éxito de la arquitectura empresarial propuesta por TOGAF es la división de ésta arquitectura en cuatro capas [1]:

• Arquitectura de Negocio: engloba los parámetros relacionados con el negocio de ésta forma se

logra conocer los objetivos y estrategia del mismo. • Arquitectura de Aplicaciones: describe cómo las aplicaciones son diseñadas y cómo se

desarrolla la interacción entre éstas. • Arquitectura de Datos: describe como empresa almacena los datos, los organiza y accede a

ellos. • Arquitectura Técnica: describe la infraestructura del hardware y software que soporta las

aplicaciones y su interacción.

ADM es un repositorio para la creación de la arquitectura, y éste puede organizarse como un proceso, lo que en teoría resumiría el concepto de TOGAF en una Arquitectura de Procesos, en vez de un Framework Arquitectónico o una Metodología, como es definido por The Open Group.

En contraposición con Zachman: “es necesario categorizar los artefactos” [17], en TOGAF, se

entrega una técnica que permita crear dichos artefactos. TOGAF en el ámbito de la arquitectura empresarial se enfoca directamente dentro de la arquitectura continua, creando rangos que incluirán


ORIENTADO A LA UTPL


desde la arquitectura genérica más grande, hasta la más pequeña y específica, a éste tipo de técnica se la conoce como Enterprise Cotinuum. La metodología ADM de TOGAF permite precisamente lograr aquel movimiento que va desde lo genérico hasta lo específico.

Una diferenciación un tanto precisa de los niveles—en los que se pretende desglosar lo

universal y convertirlo en específico—descritos en TOGAF, es el siguiente:

Fundation Architectures, en el que se incluyen todos los principios arquitectónicos que podrán—al menos en teoría—ser utilizados por cualquier TI en el campo empresarial de su dominio.

El siguiente nivel de especificación, es el de Arquitectura de Sistemas Comunes, es el diseño

arquitectónico que se desea ver en muchos de los tipos de empresas. Otro nivel de especificación es el concerniente a Arquitecturas Industriales, y relacionado a las empresas que tienen el mismo dominio, y en cuyo caso el crecimiento se desarrolla de forma exponencial (caso de sucursales).

Se denomina en TOGAF un nivel específico a las Arquitecturas Organizacionales; y son las

arquitecturas que harán específica a una determinada empresa. 1.11.3.3 FEA

Su objetivo primordial es implementar un marco referencial de Arquitectura Empresarial común y transversal, para las múltiples agencias y funciones gubernamentales de los EE UU. Visto desde el punto de vista de análisis, se convierte en uno de los más potentes Frameworks, debido a que posee un estudio de taxonomía comprensivo, al igual que Zachman, además de una arquitectura de procesos como TOGAF. Entonces FEA puede ser considerado como una metodología para la creación de una Arquitectura Empresarial, o el resultado de la aplicación de procesos a una Empresa Particular.

Generalmente se describe a FEA como un conjunto conformado por cinco modelos referenciales para incrementar su performance: Negocios, Servicios, Componentes, Tecnologías y Datos. Aquellos son considerados los elementos constitutivos de FEA, aunque un tratamiento minucioso necesariamente incluirá los siguientes parámetros [06]:

• Una visión general de cómo la Arquitectura Empresarial deberá ser vista • Un conjunto de modelos de referencia para describir las diferentes perspectivas de la

Arquitectura Empresarial • Procesos para crear la Arquitectura Empresarial • Procesos Transaccionales para la migración de una Pre-Arquitectura Empresarial a un

paradigma Post-Arquitectura Empresarial • Una taxonomía para catalogar activos que están incluidos en las competencias de la

Arquitectura Empresarial • Una aproximación a la medición de satisfacción del uso de una Arquitectura Empresarial para

conducir el valor del negocio.


ORIENTADO A LA UTPL


La Oficina de Administración del Programa de Arquitectura Empresarial Federal (FEAPMO)10

“Un leguaje común y un Framework que describe y analiza inversiones IT, mejora la colaboración y por último transforma al Gobierno Federal en Ciudadano-centralizado, orientado a resultado, en base al mercado organizacional como un conjunto progresivo en la Agenda de Administración del Presidente” [06]

afirma que FEA provee:

La perspectiva de FEA de EA en una empresa, es la construcción en segmentos, basados en

la idea introducida por FEAF. Siendo entonces un segmento aquella línea mayor de la funcionalidad de un negocio, de la misma forma que lo serían los recursos humanos. Existiendo así dos tipos de segmentos: los segmentos núcleo visión-área, y los segmentos negocio-servicio.

Los segmentos de negocio-servicio, son fundamentales para la mayoría de organizaciones

políticas—probablemente para todas ellas—por ésta razón, éste tipo de arquitectura empresarial ha servido como soporte para las instituciones gubernamentales dentro de las oficinas federales en Estados Unidos.

FEA consiste en un conjunto de “Modelos de Referencia” interrelacionados, diseñados para

facilitar el análisis entre agencias y la identificación de valores duplicados de inversión, brechas y oportunidades de colaboración entre éstas. Colectivamente, los modelos referenciales componen el Framework para describir los elementos importantes de FEA en una vía común y consistente [06].

1.11.3.4 Gartner

Según la concepción de Gartner, la Arquitectura Empresarial trae consigo tres elementos constituyentes: propietarios del negocio, especialistas de información e implementadores de tecnología; como objetivo está siempre la unificación de éstos tres elementos, pensado en un futuro acople a una visión común para dar valor al negocio.

Más allá de cualquier desarrollo de artefactos y documentos técnicos, Gartner se preocupa

por una eficiente implementación de una maqueta definida como “una sola idea común”, y deberá ser entendida y compartida por todos los participantes activos de la empresa.

De acuerdo a los modelos de negocio, en muchas empresas, se experimenta cambios

continuos en ciertos procesos, para éste caso, Gartner sugiere una creación de Arquitectura Empresarial, de una manera en la que cada miembro conozca la naturaleza, objetivos y el impacto de dichos cambios.

La propuesta de Gartner es mucho más acertada si se propone en términos de estrategia, y

no tanto de ingeniería. Esta visión se enfoca en el destino del negocio, y lo más importante de éste

10 Mayor información disponible en: http://www.aboutus.org/Feapmo.gov


ORIENTADO A LA UTPL


concepto es que la idealización de destino no se preocupa tanto por el dónde está yendo la empresa sino más bien por el cómo está yendo.

El Framework de Arquitectura Empresarial de Gartner, es justo, preciso y orientado a resolver

los paradigmas creativos en los andamiajes colectivos, se presenta un modelo arquitectónico como un conjunto unitario y equilibrado en el que cada participante deberá conocer exactamente cada visión y enfoque para poder operar coherentemente de acuerdo a sus niveles de competencia. Luego de la definición de un objetivo común, será posible implementar modelos que resuelvan de forma eficiente los movimientos futuros del negocio. La principal preocupación de Gartner es el cómo mover las fichas sobre la marcha, entonces se puede encontrar algún tipo de metodología que no se resolverá mediante modelado debido a que se ha demostrado que nadie es capaz de modelar absolutamente todo [12].

1.11.4 Introducción a Herramientas para EA

Las empresas están constantemente sujetas a cambios internos y externos. Una manera de lidiar con esos cambios es estar integrado y ser ágil. Mediante el uso de una EA se puede lograr tal integración y agilidad de una manera consistente y coherente, a través de herramientas creadas para el proceso de desarrollo de la EA. Este principio se describe a continuación, en la figura 8.

Figura 8: Interacción de la herramienta [13]

Se deben considerar algunos aspectos técnicos expresados en la figura 9, para poder evaluar, comparar y conocer a las herramientas que más se adapten a las necesidades de la organización.


ORIENTADO A LA UTPL


HERRAMIENTA EA

Propósito ContenidoFormato

RelacionesEMPRESA

Visualizaciones Lenguaje

Aplicaciones

Información

Negocio

Tecnología

AgilidadIntegración

Productos / ServiciosProcesos

Organización

Middle warePlataforma

Red

Datos Software

InternasExternas

EsquemasGráficosModelosPatrones

DirectricesPrincipios

ReglasPuntos de inicio

Narrativas

Figura 9: Proceso EA visto desde una herramienta [13]


ORIENTADO A LA UTPL


EA – UTPL

SECCION 3:

ANALISIS DE FRAMEWORKS Y HERRAMIENTAS


ORIENTADO A LA UTPL


2.0 ANALISIS DE FRAMEWROKS

Los enfoques que se dan para la Arquitectura Empresarial, son diversos y generalmente utilizan diferentes tipos de técnicas y metodologías basadas en principios establecidos por la ingeniería que se ha logrado consolidar—por determinada institución dedicada a la Arquitectura Empresarial—a lo largo de los años.

Cada uno de los frameworks que se revisará en éste documento contiene información

robustecida por el tiempo de vida de las instituciones, y que además es producto del esfuerzo investigativo de los procesos creativos de: arquitectos empresariales, conjunto de técnicos y especialistas que con sus aportes han llevado las perspectivas de un grupo de entusiastas a la creación de costumbres que se han plasmado en metodologías y técnicas ahora aplicadas en diversas empresas alrededor del mundo.

El presente documento ha reunido a cuatro grandes nombres (Zachman, FEA, Gartner,

TOGAF) que han aportado de manera fundamental en la hoy madura idea de Arquitectura Empresarial, ellos—como se explicó en líneas anteriores—difieren en la forma de conducir a las empresas hacia la Arquitectura Empresarial, pero coinciden en el objetivo que se persigue, cada una de las “formas” de arquitectura tienen resultados significativos que de cualquier manera conducen hacia una efectiva y eficiente Gobernanza de TI.

Para finalizar, se mencionará por selección histórica primeramente las técnicas y

metodologías de Zachman, posteriormente TOGAF, luego FEA y finalmente Gartner, el orden establecido sugiere guiar de forma didáctica al entendimiento de cuatro de las prácticas más efectivas para llegar a crear un Framework de Arquitectura Empresarial con miras al uso de ésta en nuestra cotidianidad.

2.1 Zachman

Para entender los aspectos que puntualizan el Framework de Zachman, es necesario primeramente definir formalmente el término Framework, y de acuerdo al Diccionario de Patrimonio de Estados Unidos, se lo define de la como:

“Una estructura para soportar o encerrar algo, especialmente un soporte esquelético, usado

como fundamento para algo que está siendo construido; Una plataforma externa de trabajo, un andamio; Una estructura fundamental, como para un trabajo escrito; Un conjunto de asunciones, conceptos, valores y prácticas que constituyen el medio para ver la realidad. [23].”

Una taxonomía, por otro lado, es definida como: La clasificación de organismos en un sistema ordenado, que indica la relación natural: La

ciencia, leyes, o principios de clasificación, sistematización; División en un grupo ordenado o categorías. [1]


ORIENTADO A LA UTPL


En base a éstos conceptos se deduce que en particular Zachman se puede definir más bien como una taxonomía de artefactos arquitectónicos en términos de una organización (es decir, documentación, especificaciones, modelos) y que son utilizados en asuntos particulares dentro del movimiento de la empresa de acuerdo al direccionamiento que se tenga de algún asunto en el que se mueve el negocio.

El propio John Zachman describe su trabajo de la siguiente manera: El Framework EA tiene su aplicación en las empresas como una estructura lógica simple de

clasificación y organización, las representaciones descriptivas de una empresa son importantes para la administración de la misma, así como también en el desarrollo de los Sistemas Empresariales. [10]

En términos empresariales, se deberá tomar en cuenta el entredicho que sugiere que el

Framework de Zachman va incluso más allá de lo relacionado a las TI, por ejemplo en un párrafo del libro de Zachman encontramos lo siguiente:

…en el debido curso, usted descubrirá que el Framework existe en todo lo que usted hace, no

únicamente en proyectos de TI. Cuando se entienda completamente el Framework, usted llegará a ser más eficiente en todo lo que haga. Esto significa todo, Ésta declaración no está hecha a la ligera [24]. Zachman al respecto afirma que el esquema del Framework ha estado con nosotros por cientos de años, y estoy seguro que lo estará aún por un ciento de años más. Lo que cambiaremos será el entendimiento de éste y cómo lo usaremos para la Ingeniería Empresarial y Manufactura [11].

La siguiente dimensión que propone Zachman es un enfoque descriptivo de los artefactos,

entonces las preguntas esenciales a responder son: qué, cómo, cuándo, dónde, quién y por qué del proyecto. El contexto de éstas preguntas se verá afectado por quién es el propietario en cuestión que formulará las preguntas, de acuerdo a la necesidad imperante en un momento determinado.

Para entender de mejor forma lo anteriormente dicho, se utilizará un ejemplo de la siguiente

forma: Diagramaremos la perspectiva de “dato” desde diferentes puntos de vista dentro del mismo concepto Empresarial.

Dato para el propietario, significan las entradas del negocio. Éstos datos pueden contener

información sobre las entradas en sí, como también la información relacionada a los vendedores y productos, o cualquier tipo de relación que puedan tener estas entradas, o bajo cualquier punto de vista que pueda tener el propietario del negocio, por citar un ejemplo, las diferentes asociaciones demográficas de productos e inventario.

En contraposición tenemos el punto de vista de la persona encargada de implementar la base

de datos, su concepción de “dato”, no será considerada una entrada de negocio, sino más bien un conjunto de filas y columnas que están vinculadas entre sí por medio de operaciones matemáticas de unión y proyección. Este tipo de persona no se interesará por los grupos demográficos de productos, sino por relaciones de I, II y III Forma Normal.


ORIENTADO A LA UTPL


Desde el punto de vista de Zachman ninguna de éstas perspectivas es mejor que la otra, sino que ambas tienen la misma relevancia e importancia, al respecto citó:

Estamos teniendo problemas de comunicación entre una y otra arquitectura de los Sistemas

de Información, porque el conjunto arquitectónico representa la existencia, en vez de una única arquitectura. Ninguna es incorrecta o acertada. Las arquitecturas son diferentes. Son aditivas y complementarias. Existen razones para gastar los recursos para el desarrollo de cada representación arquitectónica. Así como también hay riesgos asociados a no desarrollar con ninguna de las representaciones arquitectónicas. [3].

La idea estructural que sugiere Zachman sobre la EA, apunta hacia una composición en

celdas particulares en las que se enmarcará solamente un artefacto, con este objeto se evitará que exista ambigüedad, debido a que siempre se conocerá cuál es el lugar en el que habita un artefacto determinado.

Figura 10: Grid de Zachman [18]

Una segunda sugerencia dentro de la taxonomía de Zachman indica que se deberá considerar

un trabajo cumplido siempre y cuando se haya concluido con una celda particular. Esto garantizará que no se produzcan mezclas en los propietarios del trabajo y los artefactos en desarrollo.


ORIENTADO A LA UTPL


Cuando cada una de las celdas dispuestas en una malla (grid) está llena con cada uno de los

artefactos que conforman el Sistema, cada uno de los participantes tendrá una visión más amplia de éste, desde cada uno de los ángulos de disposición, obviamente con el enfoque de EA.

2.2. TOGAF

The Open Group Architecture Framework, mejor conocido por acrónimo TOGAF, siendo éste propiedad del The Open Group. El éxito de la arquitectura empresarial propuesta por TOGAF es la división de ésta arquitectura en cuatro categorías que son las siguientes:

• Arquitectura de Negocio: Engloba los parámetros relacionados con el negocio de ésta forma se

logra conocer los objetivos. • Arquitectura de Aplicación: Describe cómo las aplicaciones son diseñadas y cómo se desarrolla

la interacción entre éstas. • Arquitectura de Datos: Describe como la empresa almacena los datos, los organiza y accede a

ellos. • Arquitectura Técnica: Describe la infraestructura del hardware y software que soporta las

aplicaciones y su interacción.

TOGAF se define a sí mismo como un Framework, no obstante, la parte más importante de TOGAF es su método de desarrollo arquitectónico, el cual es mejor conocido como ADM. ADM es una metodología (repositorio) para la creación de arquitectura, y éste puede organizarse como un proceso, lo que en teoría resumiría el concepto de TOGAF en una Arquitectura de Procesos, en vez de un Framework Arquitectónico o una Metodología, como es definido por The Open Group.

En contraposición con Zachman que dice cómo es necesario categorizar los artefactos, en

TOGAF se entrega una técnica que permita crear dichos artefactos. El enfoque de TOGAF en el ámbito de la EA se orienta directamente dentro de la Arquitectura Continua, creando rangos que incluirán desde la arquitectura genérica más grande, hasta la más pequeña y específica, a éste tipo de técnica se la conoce como Enterprise Continuum. La tecnología ADM de TOGAF permite precisamente que logre suceder aquel movimiento que va desde lo genérico hasta lo específico.

Una diferenciación un tanto precisa de los niveles—en los que se pretende desglosar lo

universal y convertirlo en específico—descritos en TOGAF, es el siguiente: Fundation Architecture, en el que se incluyen todos los principios arquitectónicos que podrán—al menos en teoría—ser utilizados por cualquier TI campo empresarial de su dominio.

El siguiente nivel de especificación, es el de Arquitectura de Sistemas Comunes, y ésta es el

diseño arquitectónico que se desea ver en muchos de los tipos de empresas. Otro nivel de especificación es el concerniente a Arquitecturas Industriales, y son las relacionadas a las empresas que tienen el mismo dominio, y en cuyo caso el crecimiento se desarrolla de forma exponencial (caso de sucursales).


ORIENTADO A LA UTPL


Se denomina en TOGAF un nivel específico a las Arquitecturas Organizacionales; y son las arquitecturas que harán específica a una determinada empresa.

Figura 11: Continuum de TOGAF [1]

TOGAF considera apropiado alojar dentro de la Fundation Architecture, varias líneas de

conocimiento que pueden enmarcarse dentro de las Arquitectura de TI genérica, éstas son: Modelo de Referencia Técnico (Technical Reference Model) TRM, y la Base de Información Estándar (Standards Information Base) SIB, este último es un conjunto de estándares y pseudo - estándares que The Open Group recomienda considerar en la construcción de una arquitectura de TI.

Siendo el ADM (Método de Desarrollo Arquitectónico) el motivo de desarrollo de TOGAF, es

necesario reconocer que éste está basando sus líneas de conformación desde una perspectiva rotativa en el que SIB y TRM son meras sugerencias, es decir, no existe ninguna exigencia en cuanto al desarrollo de una arquitectura empresarial con TOGAF, que haga rígida su infraestructura y se imponga la utilización de éstas. Las fases de ADM son las siguientes:


ORIENTADO A LA UTPL


Figura 12: Método de Desarrollo Arquitectónico (ADM) de TOGAF [18]

Una particularidad de TOGAF—en contraposición con Zachman—es que aquí no se solicita

como requisito previo la finalización de alguna de sus fases, es decir, las fases pueden terminar incompletas, saltadas, combinadas, reorganizadas o reconfiguradas para adaptarse a las necesidades de una situación determinada. De esta forma no debería sorprendernos que dos diferentes consultores certificados TOGAF, se encuentren usando dos procesos totalmente diferentes, incluso cuando ellos trabajan en la misma organización. Para obtener documentación en detalle de éstos particulares, se puede adquirir bibliografía de TOGAF [25].

En éste contexto, TOGAF se presenta como una arquitectura muy flexible, de éste modo el

resultado obtenido por una aplicación de la metodología de TOGAF podría derivar en una arquitectura buena, mala, o indiferente, puesto que TOGAF se enfoca en el proceso de cómo llegar a desarrollar e implementar dicha arquitectura, siendo así, no necesariamente se creará una buena arquitectura empresarial, de esta forma una empresa es libre de usar Consultores Certificados o su personal de planta para el desarrollo de un Framework con ésta metodología. 2.3. Federal Enterprise Architecture (FEA)

La Arquitectura Empresarial Federal (FEA, por sus siglas en inglés) tiene como objetivo

primordial, implementar un marco referencial de Arquitectura Empresarial común y transversal, para las múltiples agencias y funciones gubernamentales.

Visto desde el punto de vista de análisis, se convierte en uno de los más potentes

Frameworks, debido a que posee un estudio de taxonomía comprensivo, al igual que Zachman, además de una arquitectura de procesos como TOGAF. Entonces FEA puede ser considerado como una metodología para la creación de una Arquitectura Empresarial, o el resultado de la aplicación de procesos a una Empresa Particular.

Generalmente se describe a FEA como un conjunto conformado por cinco modelos

referenciales para incrementar su performance: Negocios, Servicios, Componentes, Tecnologías y


ORIENTADO A LA UTPL


Datos. Aquellos son considerados los elementos constitutivos de FEA, aunque un tratamiento minucioso necesariamente incluirá los siguientes parámetros: [26]

• Una visión general de cómo la Arquitectura Empresarial deberá ser vista • Un conjunto de modelos de referencia para describir las diferentes perspectivas de la

Arquitectura Empresarial • Procesos para crear la Arquitectura Empresarial • Procesos Transaccionales para la migración de una Pre-Arquitectura Empresarial a un

paradigma Post-Arquitectura Empresarial • Una taxonomía para catalogar activos que están incluidos en las competencias de la

Arquitectura Empresarial • Una aproximación a la medición de satisfacción del uso de una Arquitectura Empresarial para

conducir el valor del negocio.

Según la Oficina de Administración del Programa de Arquitectura Empresarial Federal (FEAPMO por sus siglas en inglés), al respecto de FEA, indican que provee: un leguaje común y un Framework que describe y analiza inversiones IT, mejora la colaboración y por último transforma al Gobierno Federal en Ciudadano-centralizado, orientado a resultados, en base al mercado organizacional como un conjunto progresivo en la Agenda de Administración del Presidente [26]

Figura 13: Aplicación de Arquitectura Segmentada [26]

2.3.1. Perspectiva de FEA sobre la Arquitectura Empresarial

La perspectiva de FEA de EA en una empresa, es la construcción en segmentos, basados en

la idea introducida por FEAF [27]. Siendo entonces un segmento una línea mayor de la funcionalidad de un negocio, de la misma forma que los recursos humanos. Existen dos tipos de segmentos: los segmentos núcleo visión-área, y los segmentos negocio-servicio.

Los segmentos de negocio-servicio, son fundamentales para la mayoría de las organizaciones

políticas—probablemente para todas ellas—por ésta razón, éste tipo de arquitectura empresarial ha servido como soporte para las instituciones gubernamentales dentro de las oficinas federales en Estados Unidos.


ORIENTADO A LA UTPL


La diferencia entre servicios empresariales y segmentos—especialmente negocios-servicios—

se presenta de forma confusa e imperceptible. Ambas son compartidas en la organización, pero principalmente los objetivos que se persiguen, podrían definir dichas diferencias, es decir la orientación negocio-servicio tiene objetivos que abarcan únicamente una política organizacional, mientras que los objetivos de los Servicios Empresariales abarcan a la Empresa entera.

FEA creará segmentos generales de acuerdo al marco referencial que propone su

construcción como Arquitectura Empresarial, éstos tendrán la capacidad de universalidad de acuerdo a los objetivos que persigue el negocio. Cada segmento podrá ser compartido por las diferentes áreas disciplinarias y podrá—o deberá—ser administrado de forma particular.

Una diferenciación importante que se debe considerar cuando se consolida FEA en una

empresa, es la relacionada a la orientación de éste puesto que se evitará la confusión de conceptos relacionados a su enfoque en segmentos, puesto que fácilmente se puede enredar las ideas y encaminar su construcción como Arquitectura orientada a servicios, las razones—aparentemente obvias—concluyen en que los servicios se preocuparán únicamente del aspecto técnico en la empresa, mientras que los segmentos incluirán además una arquitectura de datos y de negocios.

2.3.2. Modelos de Referencia

El objetivo principal dentro de la definición formal de FEA, es la creación e implementación de un lenguaje común, centrados en la mejora de la comunicación, cooperación y colaboración a través de los límites de las políticas de la organización. De acuerdo a FEAPMO: FEA consiste en un conjunto de “Modelos de Referencia” interrelacionados, diseñados para facilitar el análisis entre agencias y la identificación de valores duplicados de inversión, brechas y oportunidades de colaboración entre las agencias. Colectivamente, los modelos referenciales (componen) el Framework para describir los elementos importantes de FEA en una vía común y consistente [26].

En éste contexto [26], entonces los Modelos de Referencia serán: • El Modelo de Referencia de Negocio (Bussiness Reference Model BRM) provee al negocio una

visión de varias funciones del Gobierno Federal, por ejemplo, el BRM define un estándar de capacidad de negocio llamado Administrador de Recursos de Agua el cual es una subfunción de Recursos Naturales el cual es considerado la líneas base del negocio, o huésped para el área de negocio de los Servicios a la Ciudadanía.

• El Modelo Referencial de Componentes (Components Reference Model CRM) brinda una visión más TI que pueda soportar funcionalidad de negocio. Por ejemplo, el CRM define el sistema cliente-analista.

• El Modelo de Referencia Técnica (Technical Reference Model TRM) define las distintas tecnologías y estándares que podrán ser usados en la construcción de un Sistema TI. Por ejemplo, el TRM define HTTP como un protocolo de un subconjunto para un servicio de transporte que a su vez, será un subconjunto de Servicios de Entrega y Acceso.


ORIENTADO A LA UTPL


• El Modelo de Referencia de Datos (Data Reference Model DRM) define vías estándar en la descripción de datos. Por ejemplo, DRM define una entidad como atributos contenidos o participantes en relaciones.

• El Modelo de Referencia de Rendimiento (Performance Reference Model PRM) define una vía estándar para la descripción de los valores entregados por la Arquitectura Empresarial. Por ejemplo, el PRM describe la calidad como un área de tecnología de medición, que será especificada como “el grado en el que la tecnología satisface la funcionalidad o los requisitos de capacidad”.

2.3.3. Procesos de FEA

• Primero: Análisis Arquitectónico—Define una visión simple y consistente de los segmentos, y lo

relaciona con el Plan Organizacional. • Segundo: Definición Arquitectónica—Define el estado de la arquitectura deseada del segmento,

documentos de objetivos de rendimiento, considera alternativas de diseño, y desarrolla una arquitectura empresarial para un segmento, incluyendo el negocio, datos, servicios, y Arquitectura Tecnológica.

• Tercero: Inversiones y Financiamiento Estratégico—Considera cómo el proyecto deberá ser financiado.

• Cuarto: Administración del Programa, Plan y Ejecución de Proyectos—Crea un plan para manejar y ejecutar un proyecto, incluyendo hitos y medidas de rendimiento que posteriormente evaluarán la satisfacción del proyecto.

2.3.4. Medición del Nivel de Satisfacción

Para evaluar los niveles de satisfacción del Framework FEA, es necesario considerar:

• Finalización Arquitectónica: Nivel de Madurez de la arquitectura en sí. • Uso Arquitectónico: Qué tan eficientemente la agencia usa la arquitectura en la toma de

decisiones. • Resultados Arquitectónicos: Los beneficios se están realizando con el uso de la arquitectura.

La Oficina de Gerencia y Presupuestos OBM por sus siglas en Inglés (Office of Management and Budget), asigna a cada agencia un rango de satisfacción. Basado en los marcadores de cada categoría y los marcadores acumulados, con los colores verde, amarillo y rojo, de acuerdo al grado que se logre captar de la experiencia de los usuarios. 2.4. Gartner


ORIENTADO A LA UTPL


Hasta el momento se ha revisado tres diferentes metodologías que tienen enfoques heterogéneos, por ejemplo: una taxonomía (Zachman), un proceso (TOGAF), una metodología completa (FEA), en cambio Gartner es considerada como una práctica.

La arquitectura es un verbo, no un sustantivo. ¿Qué quiere decir esto?, esto significa que los

procesos que están en marcha, mantenimiento y especialmente en el apalancamiento de una Arquitectura Empresarial, serán quienes se encarguen de la vitalidad de dicha Arquitectura.

Una arquitectura no es solamente un conjunto organizado y equilibrado de artefactos, sino

más bien la idea conceptualizada del uso y categorización mediante taxonomías (procesos o metodologías) de éstos y cómo servirán de soporte y guía a través de su desarrollo.

Según la concepción de Gartner, la Arquitectura Empresarial trae consigo tres elementos

constituyentes: propietarios del negocio, especialistas de información e implementadores de tecnología; como objetivo está siempre la unificación de éstos tres elementos, pensado en un futuro acople a una visión común para el valor del negocio.

Más allá de cualquier desarrollo de artefactos y documentos técnicos, Gartner se preocupa

por una eficiente implementación de una maqueta definida como “una sola idea común”, y deberá—por ser común—ser entendida y compartida por todos los participantes activos de la empresa.

Figura 14: Modelo de Arquitectura Empresarial de Gartner [18]


ORIENTADO A LA UTPL


De acuerdo a los modelos de negocio, en muchas empresas, se experimenta cambios continuos en ciertos procesos, para éste caso, Gartner sugiere la creación de Arquitectura Empresarial, de una manera en la que cada miembro conozca la naturaleza, objetivos y el impacto de dichos cambios.

La razón de entendimiento de Gartner sobre la Arquitectura Empresarial, es mucho más

acertada si se propone en términos de estrategia, y no tanto ingeniería. Esta visión se enfoca en el destino del negocio, y lo más importante de éste concepto es que idealización de destino no se preocupa tanto por el dónde está yendo la empresa sino más bien por el cómo está yendo.

La Arquitectura Empresarial de Gartner, es justa, precisa y orientada a resolver los

paradigmas creativos en los andamiajes colectivos, se presenta un modelo arquitectónico como un conjunto unitario y equilibrado en el que cada participante deberá conocer exactamente cada visión y enfoque para poder operar coherentemente de acuerdo a sus niveles de competencia. Luego de la definición de un objetivo común, será posible implementar modelos que resuelvan de forma eficiente los movimientos futuros del negocio. La principal preocupación de Gartner es el cómo mover las fichas, entonces se puede encontrar algún tipo de metodología que no se resolverá mediante modelado debido a que se ha demostrado que nadie es capaz de modelar absolutamente todo [26]. 2.5. E2AF

La arquitectura empresarial extendida (Extended Enterprise Architecture Framework E2AF por

sus siglas en inglés) tiene como eje fundamental la integración de los parámetros organizacionales y tecnológicos todo enmarcado en el plano de una unificación holística de tres elementos fundamentales: El elemento de construcción, el elemento de función y el elemento de estilo [28].

Desde la perspectiva organizacional generalmente no se ha dado importancia a la

construcción y función de los parámetros relacionados con la arquitectura empresarial, restando de manera considerable la participación del estilo—en el mejor de los casos—o simplemente ignorando las competencias que éste supone. Debido a que en la arquitectura extendida se considera el estilo además de los anteriormente citados, se entenderá que éste está relacionado con el comportamiento cultural, valores, normas y principios y de qué manera se incorporan éstos en los valores institucionales de las organizaciones.

Al mismo tiempo, la arquitectura empresarial direcciona los aspectos de Negocio, Información,

Sistemas de Información e Infraestructura Tecnológica de una manera integral que abarca la organización y su entorno en el plan de zonificación y a un nivel de plano de una ciudad [28].

En una cantidad innumerable de empresas, se aborda el tema de arquitectura empresarial

incluyendo únicamente el plano tecnológico, de ésta forma lo que se sugiere con el E2AF es lograr generar en los arquitectos empresariales un conjunto de métodos, técnicas y buenas prácticas con la capacidad de integrar los aspectos empresariales con los tecnológicos, así se tendría una elaborada marca de proyección a objetivos concretos, administración y manejo de la complejidad abordados dentro de un ciclo de cambio continuo guiados por la Arquitectura Empresarial Extendida.


ORIENTADO A LA UTPL


De esta forma, el arquitecto empresarial no es solamente un técnico, sino un experto en la

yuxtaposición Negocio-Tecnología, e idóneo en la creación de valores empresariales, formando un ente constitutivo tomando como ingredientes las oportunidades de negocio y las posibilidades tecnológicas dentro del marco holístico que engloba el framework extendido. 2.5.1. Visualización de E2AF

El E2AF es framework simple creado por Institute For Enterprise Architecture Develop IFEAD,

desarrollado con el propósito de comunicar los aspectos arquitectónicos a los stakeholder. Al igual que Zachman, se intenta responder al qué y cómo pero con un enfoque un poco más profundo y tecnificado, se asume las modificaciones a las preguntas, de la siguiente manera:

• ¿por qué?: Considerando la visión, principios estratégicos, ambiente y alcance en un nivel

contextual • ¿con quién?: Valor neto de las relaciones, cooperación, elementos de colaboración dentro de

un marco ambiental • ¿qué?: Requerimientos y representaciones ligadas al plano conceptual • ¿cómo?: Un análisis a nivel lógico de las representaciones lógicas • ¿con quién?: Representación de las soluciones en el marco físico • ¿cuándo?: Análisis ambiental en el plano transformacional


ORIENTADO A LA UTPL


Figura 15: Marco Arquitectónico de E2AF [29]


ORIENTADO A LA UTPL


El análisis anterior se presenta varios niveles de competencia dentro de la aplicabilidad del

framework, ésos son el nivel privado (empresarial), gobernanza y seguridad, además de aspectos externos diversos que pueden influir directamente con los objetivos del negocio y por ende modificar el valor de éste.

En éste contexto, con E2AF, se determina que el nivel de arquitectura empresarial se busca

agregar valores a las áreas que están direccionadas dentro del enfoque específico (negocios, información, etc.) y se las cubrirá totalmente, mediante la utilización de un estándar el IEEE 1471-2000 [29]

El punto de vista del la Gobernanza puntualiza los conocimientos de una estructura de

auténtica gobernanza organizativa, acoplando responsabilidades y servicios en función de cómo éstos influyen en las decisiones arquitectónicas [29]

El punto de vista de la Seguridad se toma especial cuidado en la definición formal del soporte

organizacional para abordar los parámetros de las TI de una forma consistente; de esta forma el arquitecto—según el enfoque del modelo—deberá decidir alinear la balanza para conseguir un equilibrio entre máxima seguridad y máxima usabilidad [29].

El E2AF puede ligar muchísimos aspectos de estudio en el marco arquitectónico dentro de

una institución, de ésta forma en los lineamientos y guías de construcción, se ofrece una ayuda para evitar los errores de conceptualización, es decir, crear una autonomía dentro de los niveles de abstracción con el fin de evitar confusiones. Será necesario separar: estrategias de requerimientos, requerimientos de soluciones, soluciones de implementaciones y finalmente las implementaciones de las transformaciones.

En conclusión el adoptar E2AE garantiza:

• Que los resultados puedan ser utilizados como un diccionario para administrar y navegar en los aspectos relevantes de una institución.

• Los planes de actuación serán definidos para identificar las tareas necesarias y las actividades • Con E2AE se identificarán los elementos de complejidad a ser direccionados, las personas

involucradas en el proceso así como las relaciones y dependencias existentes entre éstos • E2AE guiará de forma eficiente en todos las Actividades Arquitectónicas.

2.6 Comparación

Los enfoques de arquitectura empresarial son diversos, es por ello que para poder seleccionar el adecuado para la organización en el que se lo necesita—o desea—implementar, siempre será útil un análisis comparativo de dichas metodologías, Roger Sessions en 2007 desarrolló un estudio en el que de acuerdo a varios criterios se evaluaba los diferentes Frameworks [18], las puntuaciones de Sessions obedecían los siguientes parámetros:


ORIENTADO A LA UTPL


1: Significa trabajo pobre en ese ámbito 2: Significa trabajo inadecuado en ese ámbito 3: Significa trabajo aceptable en ese ámbito 4: Significa un buen trabajo en ese ámbito

Taxonomía, se refiere a que tan bien se puede usar la metodología para clasificar varios artefactos arquitectónicos.

Zachman: 4 TOGAF: 2 FEA: 2 Gartner: 1 E2AF 2

Procesos, se refiere a cómo se guía en su totalidad a través de los procesos, paso a paso,

para la creación de la Arquitectura Empresarial. Zachman: 1 TOGAF: 4 FEA: 2 Gartner: 3 E2AF 4

Gobierno de un Modelo de Referencia se refiere a de qué manera es útil la metodología

ayudando a construir un conjunto de modelos de referencia. Zachman: 1 TOGAF: 3 FEA: 4 Gartner: 1 E2AF 3

Prácticas de Orientación se refiere a cuánto la metodología te ayuda a asimilar el

entendimiento de la Arquitectura Empresarial en una organización y en el desarrollo de una cultura de valor y uso.


Madurez del Modelo se refiere a los procesos de evaluación de eficiencia y madurez en

diferentes organizaciones dentro de una misma empresa. Zachman: 1 TOGAF: 1 FEA: 3 Gartner: 2 E2AF 1


ORIENTADO A LA UTPL


Enfoque de Negocio se refiere a si la metodología se enfocará en el uso de tecnología en la conducción de los valores de la empresa.


Dirección de Gobernanza se refiere a cómo puede la metodología entender y crear un modelo

efectivo de gobernanza para la Arquitectura Empresarial. Zachman: 1 TOGAF: 2 FEA: 3 Gartner: 3 E2AF 2

Dirección de Partición hace referencia a cómo la metodología ayudará a guiar en el proceso

de partición efectiva de la empresa en entidades autónomas. Zachman: 1 TOGAF: 2 FEA: 4 Gartner: 3 E2AF 2

Catálogo Prescriptivo se refiere a cómo la metodología guiará para la creación de un catálogo

arquitectónico de bienes, el que podrá ser re-usado en futuras actividades. Zachman: 1 TOGAF: 2 FEA: 4 Gartner: 2 E2AF 2

Neutralidad del Vendedor se refiere a la percepción que se tiene al encontrarse con un

consultor de determinada metodología. Zachman: 2 TOGAF: 4 FEA: 3 Gartner: 1 E2AF 2

Disponibilidad de Información se refiere a la cantidad y calidad de información libre y de pago

que hay sobre la metodología. Zachman: 2 TOGAF: 4 FEA: 2 Gartner: 1 E2AF 2


ORIENTADO A LA UTPL


Estimación de Tiempo Se refiere a la cantidad de tiempo que probablemente sea usada en la

metodología, después de empezar usándola en la construcción de una solución Zachman: 1 TOGAF: 3 FEA: 1 Gartner: 4 Gartner: 2

Luego del análisis realizado, los resultados se muestran en la tabla 1

TABLA I: Análisis Comparativo [18]

Criterio Zachman TOGAF FEA Gartner E2AF Taxonomía

4 2 2 1 2

Procesos

1 4 2 3 4

Gobierno de un Modelo de Referencia

1 3 4 1 3

Prácticas de Orientación

1 2 2 4 3

Madurez del modelo

1 1 3 2 1

Enfoque de Negocio

1 2 1 4 2

Dirección de Gobernanza

1 2 3 3 2

Dirección de Partición

1 2 4 3 2

Catálogo Prescriptivo

1 2 4 2 2

Neutralidad del Vendedor

1 2 4 2 2

Disponibilidad de Información

2 4 2 1 2

TOTAL

15 26 31 26 25


ORIENTADO A LA UTPL


3.0 ANALISIS DE HERRAMIENTAS INTRODUCCIÓN

En el desarrollo de EA se hace uso de modelos específicos, para ello se requiere el uso de

herramientas de modelado que posean fortalezas y ventajas frente a otras, solo así se podrá llegar a analizar y optimizar el portafolio de estrategias de negocio, las estructuras organizacionales, procesos de negocio, tareas, actividades, flujos de información, aplicaciones e infraestructura tecnológica.

Al adoptar un enfoque arquitectónico es importante tener a disponibilidad, herramientas que

sirvan como soporte para el desarrollo, almacenamiento, presentación y mejora de las representaciones de EA. Estas representaciones se integrarán en un repositorio de manera estandarizada, dando así el soporte necesario al análisis Arquitectónico.

Al igual que las Metodologías EA, las Herramientas que sirven al propósito del desarrollo

Arquitectónico se encuentran también en constante desarrollo, algunas han emergido en los últimos años, otras más antiguas están constantemente planteándose desafíos para evolucionar.

Debido a la importancia resaltada con anterioridad, a continuación se hará un análisis

comparativo de las herramientas más representativas basándonos en dos análisis referenciales: Gartner [1] y el Instituto para desarrollo de EA [2], así como un estudio propio de cada una de ellas.

3.1 Enfoque

Es necesario plantearse el análisis de las herramientas desde un enfoque orientado al

Framework sobre el cual se trabajará tomando como referencia dos dimensiones base: la funcionalidad básica de cada herramienta, y la utilidad que brindará a los distintos profesionales involucrados.

Al hablar de funcionalidad, esta se describe en base a requerimientos como “qué capacidad

tiene la herramienta de realizar diferentes funciones”, necesarias para la actividad de desarrollo de una EA. El análisis de herramientas está estructurado en las siguientes áreas:

• Metodologías y Modelos. • Interface de Desarrollo de Modelos. • Automatización de la Herramienta. • Personalización y Extensión. • Manipulación y Análisis. • Repositorio. • Arquitectura de implementación. • Licenciamiento y Soporte Técnico. • Resultados Arquitectónicos.


ORIENTADO A LA UTPL


La segunda dimensión, está dada por la utilidad que la herramienta da a los diferentes profesionales, captura desde el propósito de la herramienta el hecho de si es apta o no, y describe que tan usable podría ser la herramienta para profesionales particulares. Los profesionales a considerarse son:

• Arquitectos Empresariales. • Arquitectos de soluciones. • Planificadores estratégicos / Dirección. • Gerentes de Empresa. • Arquitectos de software e ingenieros. • Socios externos.

3.2 Análisis dimensional

Las Herramientas EA proveen un repositorio para almacenar, estructurar y relacionar una amplia variedad de información referente a los modelos y artefactos arquitectónicos, por otra parte proveen el soporte necesario para el análisis y presentación de dicha información con el fin de encontrar y llegar a satisfacer las necesidades de los Stakeholders.

3.3 Funcionalidad

Esta dimensión intenta captar qué tan bien la herramienta realiza las funciones básicas necesarias para apoyar la actividad de desarrollo de la EA. Cada uno de los ítems abordados será especificado en un cuadro comparativo de herramientas en base a todos los aspectos de funcionalidad.

Para una mejor comprensión se subdivide la funcionalidad de una herramienta de EA en ocho

áreas clave:

3.3.1 Metodologías y Modelos

La característica más importante de una herramienta es el soporte que brinda para determinados modelos y enfoques metodológicos. Los enfoques de la herramienta dictan los tipos de metodologías de EA que la herramienta es capaz de soportar (TOGAF, FEAF, etc.), y hasta cierto punto, el tipo de análisis y las funciones que la herramienta es capaz de realizar. En cambio el soporte en base a modelos hace referencia a estructuras formales de representación (UML, Archimate, etc.) que se deben considerar al momento de modelar una EA. En esta sección también se considera la cómo la herramienta aplica los enfoques metodológicos y de modelo que pretende apoyar.

Para la valoración se considera el soporte a metodologías en el primer cuadro y el soporte de

lenguajes de modelado en el segundo. La tabla 2 especifica la valoración en cuanto al enfoque metodológico por cada una de las herramientas.

TABLA 2: Contrastación de Metodologías


ORIENTADO A LA UTPL


Vendedor Herramienta

METODOLOGÍAS

TOGAF 9 (2,5)

Zachman (2.5)

FEAF (2,5)

Otros (2,5)

PUNT /10

Aam Tech SAMU 2,5 2,5 5

Acceptsoftware Accept 360 2,5 2,5

Adaptive Adaptive EA Manager, IT Portfolio Manager, Metadata Manager 2,5 2,5

Agilense EA Webmodeler 2,5 2,5

Altova Altova Enterprise Suite 2,5 2,5

Alfabet Planning IT 2,5 2,5 ASG Software Solutions ASG-Rochade 2,5 2,5

Avolution Abacus 2,5 2,5

Bizzdesign Bizzdesign Architect, Bizzdesigner 2,5 2,5

Casewise Corporate Modeler Enterprise Edition 2,5 2,5 2,5 2,5 10

CACI International SimProcess 2,5 2,5

Enterprise Elements Elements Repository 2,5 2,5

Forsight Modeling y Validation Tool set 2,5 2,5 Future Tech Systems Inc ENVISION VIP 2,5 2,5

GoAgile GoAgile MAP Product Suite 2,5 2,5

IBM IBM Rational Software Architect 2,5 2,5 5

IDS Scheer ARIS Bussiness Performance Edition 2,5 2,5

Intelligile Corporation MAP Suite + ITAA 2,5 2,5 5

Kontion Consulting UDEF Explorer 2,5 2,5

LogicLibrary Logidex 2,5 2,5

Mega International Mega Process Architect designer 2,5 2,5 5

CA NetViz Suite 2,5 2,5

Palisade Risk & Decision Analysis 2,5 2,5

Metastorm Metastorm Enterprise Products 2,5 2,5

Qualiware Qualiware Product Suite 2,5 2,5 Salamander Organisation MooD Transformation Technology 2,5 2,5

Select Bussiness Solutions Select Solution Factory 2,5 2,5

Simon Labs Simon Tool 2,5 2,5

Sparx Systems Enterprise Architect 2,5 2,5 2,5 2,5 10

IBM - TeleLogic System Architect Family + Rhapsody 2,5 2,5 5

Troux Troux 8 2,5 2,5 2,5 2,5 10

Visisble Visisble Advantage 2,5 2,5


ORIENTADO A LA UTPL


El otro aspecto considerado en la valoración es el soporte de lenguajes de modelado. La tabla 3

especifica la valoración en cuanto al enfoque de modelos por cada una de las herramientas:

TABLA 3: Contrastación de Modelos

Vendedor Herramienta

LENGUAJES DE MODELADO PUNT /10 UML

(2,5) Archimate 1.0 (2,5)

BPMN (2,5)

UML 2.1 (2,5)

Aam Tech SAMU 2,5 2,5 5


Adaptive Adaptive EA Manager, IT Portfolio Manager, Metadata Manager 2,5 2,5

Agilense EA Webmodeler 2,5 2,5

Altova Altova Enterprise Suite 2,5 2,5 5

Alfabet Planning IT 2,5 2,5 ASG Software Solutions ASG-Rochade 2,5 2,5

Avolution Abacus 2,5 2,5 2,5 2,5 10

Bizzdesign Bizzdesign Architect, Bizzdesigner 2,5 2,5 2,5 7,5

Casewise Corporate Modeler Enterprise Edition 2,5 2,5 2,5 2,5 10 CACI International SimProcess 2,5 2,5 5

Enterprise Elements Elements Repository 2,5 2,5

Forsight Modeling y Validation Tool set 2,5 2,5 5 Future Tech Systems Inc ENVISION VIP 2,5 2,5 5

GoAgile GoAgile MAP Product Suite 2,5 2,5

IBM IBM Rational Software Architect 2,5 2,5 5

IDS Scheer ARIS Bussiness Performance Edition 2,5 2,5 2,5 7,5 Intelligile Corporation MAP Suite + ITAA 2,5 2,5


LogicLibrary Logidex 2,5 2,5 Mega International Mega Process Architect designer 2,5 2,5 5

CA NetViz Suite 2,5 2,5


Metastorm Metastorm Enterprise Products 2,5 2,5 5

Qualiware Qualiware Product Suite 2,5 2,5 Salamander Organisation MooD Transformation Technology 2,5 2,5

Select Bussiness Solutions

Select Solution Factory 2,5 2,5 5

Simon Labs Simon Tool 2,5 2,5 5


ORIENTADO A LA UTPL


Sparx Systems Enterprise Architect 2,5 2,5 2,5 2,5 10

IBM - TeleLogic System Architect Family + Rhapsody 2,5 2,5 2,5 7,5

Troux Troux 8 2,5 2,5 2,5 7,5

Visisble Visisble Advantage 2,5 2,5

3.3.2 Interface para el desarrollo de Modelos.

Esta parte es esencial, debido a que mediante el uso de la interfaz se diseñará, construirá, mantendrá y manipulará cada uno de los modelos que constituyen parte del modelo arquitectónico. Los modelos son estructuras gráficas conceptuales que se rigen por el manejo de íconos y conexiones entre ellos, una interface también debe permitir anexar información adicional a dichos modelos.

El modelado debe soportarse de manera robusta, por ejemplo mediante automatización de

algunas funciones de dibujado, extendiendo menús o exponiendo de manera cómoda los componentes de los modelos, incluyendo métodos abreviados. Y finalmente es un factor a considerarse la distribución de los objetos en la pantalla de la herramienta, así como su organización, complejidad conceptual, entre otras.

La valoración abarca aspectos como: anticipación y autonomía respecto al modelo, manejo de

valores por defecto, eficiencia del usuario, ley de Fitts11

, interfaces explorables, uso de metáforas, curva de aprendizaje, reducción de latencia, legibilidad, entre otras. Debido a la extensión de un análisis particular para cada aspecto, se los ha englobado en tres grupos por el tipo de prototipado (véase tabla 4) de interfaz al que pertenecen:

• Prototipos Estáticos: Engloban aspectos visuales que no permiten la alteración de componentes, pero sirven para identificar y resolver problemas de diseño (desde la comprensión del usuario).

• Prototipos Dinámicos: permiten la evaluación de un modelo del sistema sobre una estación de trabajo o una terminal. Estos prototipos involucran aspectos de diseño más detallados que los prototipos estáticos, incluyendo la validación del diseño del sistema en términos de requerimientos no funcionales, por ejemplo de performance (en términos de interfaz).

• Prototipos Robustos: deben ser relativamente completos en la simulación de las características dinámicas de la interfaz (presentación de mensajes de error, entrada y edición de datos, etc.). Esta categoría puede ser utilizada para validar los objetivos de diseño.

Tabla 4: Contrastación de Interfaces para desarrollo de modelos

Vendedor Herramienta Prototipos Estáticos (3,33)

Prototipos Dinámicos (3,33)

Prototipos Robustos

(3,33)

PUNT /10

Aam Tech SAMU 3 2,5 2,5 8

11 El tiempo para llegar a un objetivo (visual) es una función de la distancia a dicho objetivo y su tamaño. En otras palabras: El tiempo que se requiere para alcanzar a pulsar un objetivo depende de una relación logarítmica entre su superficie y la distancia a la que se encuentra. Mayor información disponible en: http://www.usabilidadweb.com.ar/fitts.php


ORIENTADO A LA UTPL


Acceptsoftware Accept 360 3 2 5

Adaptive Adaptive EA Manager, IT Portfolio Manager, Metadata Manager

3,33 3,33 6,66

Agilense EA Webmodeler 3,33 3,33 6,66

Altova Altova Enterprise Suite 3 2,5 5,5

Alfabet Planning IT 3 2,5 5,5 ASG Software Solutions ASG-Rochade 3 2,5 5,5

Avolution Abacus 3,33 3,33 6,66

Bizzdesign Bizzdesign Architect, Bizzdesigner 3,33 2,5 3,33 9,16

Casewise Corporate Modeler Enterprise Edition 3,33 3,33 6,66

CACI International SimProcess 3 2,5 5,5

Enterprise Elements Elements Repository 2,5 2 4,5

Forsight Modeling y Validation Tool set 3 2 5

Future Tech Systems Inc ENVISION VIP 2,5 2,5 5

GoAgile GoAgile MAP Product Suite 2,5 2 4,5

IBM IBM Rational Software Architect 3 3,33 2,5 8,83

IDS Scheer ARIS Bussiness Performance Edition 3,33 2,5 3,33 9,16

Intelligile Corporation MAP Suite + ITAA 3 2 5

Kontion Consulting UDEF Explorer 2,5 2 4,5

LogicLibrary Logidex 2,5 2 4,5 Mega International

Mega Process Architect designer 3 3,33 6,33

CA NetViz Suite 3 2 5

Palisade Risk & Decision Analysis 3 3,33 6,33

Metastorm Metastorm Enterprise Products 3,33 3,33 6,66

Qualiware Qualiware Product Suite 3 2 5 Salamander Organisation

MooD Transformation Technology 3 2,5 5,5


Select Solution Factory 3 3,33 6,33

Simon Labs Simon Tool 3 3,33 6,33

Sparx Systems Enterprise Architect 3,33 3,33 3,33 10 IBM – TeleLogic

System Architect Family + Rhapsody 3,33 3,33 3,33 10

Troux Troux 8 3,33 3,33 3,33 10

Visisble Visisble Advantage 3 3,33 6,33

3.3.3. Automatización de la Herramienta.


ORIENTADO A LA UTPL


EL desarrollo en sí y la tarea de poblar los distintos modelos EA es una de las tareas que más tiempo consumen. Es por ello que la herramienta debe tener un motor robusto de automatización para tareas que sean repetitivas o que puedan automatizarse de alguna manera.

La herramienta debe soportar la creación de Macros o Scripts, así se podrán automatizar

acciones, funciones comunes o será posible agrupar múltiples funciones en una sola acción. Esta propiedad de la herramienta se encuentra estrictamente ligada a la capacidad que tenga de ser personalizada. Para finalizar, también debe proveer la disponibilidad de generar automáticamente los modelos EA desde datos albergados dentro del repositorio de la herramienta, o poder generar esos modelos como un resultado de funciones de manipulación de datos especificadas en scripts. La tabla 5 expresa a continuación la valoración basada en criterios de automatización.

TABLA 5: Valoración de criterios de automatización

Vendedor Herramienta Creación de

Macros/ Scripts (3,33)

Generación automática de

Modelos (3,33)

Programación de tareas (3,33)

PUNT / 10

Aam Tech SAMU 3,33 2,5 3,33 9,16


Adaptive Adaptive EA Manager, IT Portfolio Manager, Metadata Manager 3 3,33 6,33

Agilense EA Webmodeler 3 3,33 6,33

Altova Altova Enterprise Suite 3 3


Avolution Abacus 3 3,33 6,33

Bizzdesign Bizzdesign Architect, Bizzdesigner 3,33 3 3,33 9,66

Casewise Corporate Modeler Enterprise Edition 3 3 3,33 9,33


Enterprise Elements Elements Repository 3 3,33 6,33

Forsight Modeling y Validation Tool set 2,5 3,33 5,83 Future Tech Systems Inc ENVISION VIP 3 3,33 6,33

GoAgile GoAgile MAP Product Suite 2,5 3,33 5,83

IBM IBM Rational Software Architect 3,33 3 3,33 9,66

IDS Scheer ARIS Bussiness Performance Edition 3,33 2,5 3,33 9,16

Intelligile Corporation MAP Suite + ITAA 3 2,5 3,33 8,83

Kontion Consulting UDEF Explorer 3 3,33 6,33

LogicLibrary Logidex 3 3,33 6,33 Mega International Mega Process Architect designer 3,33 2,5 3,33 9,16


ORIENTADO A LA UTPL


CA NetViz Suite 3 3,33 6,33

Palisade Risk & Decision Analysis 3 3,33 6,33

Metastorm Metastorm Enterprise Products 3 3 3,33 9,33

Qualiware Qualiware Product Suite 2,5 3,33 5,83 Salamander Organisation MooD Transformation Technology 3 3,33 6,33


Select Solution Factory 3 3,33 6,33

Simon Labs Simon Tool 3 3,33 6,33

Sparx Systems Enterprise Architect 3,33 3 3,33 9,66 IBM – TeleLogic

System Architect Family + Rhapsody 3,33 3 3,33 9,66

Troux Troux 8 3,33 3,33 3,33 10

Visisble Visisble Advantage 2,5 3,33 5,83

3.3.4 Personalización y Extensión.

Desde esta óptica se debe capturar el concepto de cómo una herramienta EA puede ser modificada para cumplir con los requerimientos arquitectónicos de una organización (nivel de personalización). Una herramienta robusta en esta área debe soportar personalización al permitir a los usuarios agregar nuevos enfoques de modelado, brindando la capacidad de modificar los enfoques de modelado actualmente soportados, o bien mediante una interface de programación, dejando así libre la posibilidad de modificar funciones o permitir la integración de la herramienta con otros productos de software.

Un gran número de herramientas para EA soportan altos niveles de personalización, dando

paso a la modificación o agregación incluso de los meta-modelos subyacentes. Un meta-modelo es literalmente “el modelo acerca de un modelo”, describiendo así que entidades pueden existir dentro de determinados modelos, las relaciones legales entre entidades, y sus respectivas propiedades. Así con la disponibilidad de modificar la herramienta con una interface de programación se permite personalizar la funcionalidad y el comportamiento del software para cumplir los únicos requerimientos de la organización.

La personalización se puede conseguir mediante el uso de un lenguaje de secuencias de

comandos (scripts), por ejemplo con aplicaciones Visual Basics (VBA), o a través de soporte para anexar al software componentes externos como componentes Active X/DCOM por ejemplo.

Se puede extender las herramientas EA integrándolas con otro software de manera directa

con una API dentro del software, o haciendo uso de un Middleware como CORBA, ActiveX/DCOM, etc. También la integración puede ser soportada mediante importaciones y exportaciones de datos dentro y fuera de las herramientas usando tipos de archivos estándar, por ejemplo HTML, XML o SYLK. La tabla 6 muestra la valoración referente a los aspectos de personalización y extensión mencionados tomando tres dimensiones como referencia.


ORIENTADO A LA UTPL


TABLA 6: Valoración de Personalización y Extensión

Vendedor Herramienta Modificación de Metamodelos

(3,33)

Modificación de Componentes

(3,33)

Integración API/

Middleware (3,33)

PUNT /10

Aam Tech SAMU 2,5 2 2,5 7,5

Acceptsoftware Accept 360 1,8 2 2 5,8


2,5 2 3,33 7,83

Agilense EA Webmodeler 2 2 4

Altova Altova Enterprise Suite 3,33 2,5 5,83


Avolution Abacus 3,33 2 5,33

Bizzdesign Bizzdesign Architect, Bizzdesigner 3,33 2 3,33 8,66

Casewise Corporate Modeler Enterprise Edition 2,5 2 2,5 7,5


Enterprise Elements Elements Repository 1,8 3,33 5,13

Forsight Modeling y Validation Tool set 3,33 3,33

Future Tech Systems Inc ENVISION VIP 2 2

GoAgile GoAgile MAP Product Suite 2 2

IBM IBM Rational Software Architect 2,5 2 3,33 7,83

IDS Scheer ARIS Bussiness Performance Edition 2 2 2,5 6,5

Intelligile Corporation MAP Suite + ITAA 2 2,5 4,5


LogicLibrary Logidex 2,5 2,5 Mega International

Mega Process Architect designer 2,8 2,8

CA NetViz Suite 2 2


Metastorm Metastorm Enterprise Products 2 2 3 7

Qualiware Qualiware Product Suite 2 2,6 4,6

Salamander Organisation

MooD Transformation Technology 2 2 4


Select Solution Factory 2 2 4

Simon Labs Simon Tool 2 2


ORIENTADO A LA UTPL


Sparx Systems Enterprise Architect 3,33 3,33 3,33 10

IBM - TeleLogic System Architect Family + Rhapsody 2,6 3,33 3,33 9,26

Troux Troux 8 2,5 3,33 3 8,83

Visisble Visisble Advantage 2 2 4

3.3.5 Manipulación y Análisis.

Estos dos puntos están estrictamente ligados a los enfoques particulares de modelado soportados por la herramienta. Por ejemplo, el análisis de flujo está a menudo ligado al modelado de procesos/flujo de trabajo.

El soporte para análisis en la herramienta puede ayudar a determinar de manera simple a qué

nivel es correcto o completo es el modelo, esto relativo a un enfoque particular usado. Un análisis más sofisticado brinda soporte a cierta forma de evaluación del modelo, es decir, que esté sujeto a métodos de análisis específicos basados en evaluaciones; la principal ventaja es poder comparar la arquitectura actual con la la arquitectura que se busca (objetivo).

En cuanto a manipulación, al basarse en funciones, una herramienta puede manejarse para cambiar la forma en la que los modelos son vistos y representados. Esto abarca desde ver modelos en diversas perspectivas (por ejemplo mostrando solo casos particulares de ciertas entidades) hasta amalgamar modelos separados en un modelo simple. La tabla 7 ilustra la valoración en base a los criterios de esta sección.

TABLA 7: Valoración de Manipulación y Análisis

Vendedor Herramienta Evaluación de

Modelos (5)

Manipulación de Modelos (5)

PUNTUACION /10

Aam Tech SAMU 4 5 9


Adaptive Adaptive EA Manager, IT Portfolio Manager, Metadata Manager 4 5 9


Altova Altova Enterprise Suite 3 4 7

Alfabet Planning IT 3 4 7 ASG Software Solutions ASG-Rochade 3 4 7

Avolution Abacus 3 4 7

Bizzdesign Bizzdesign Architect, Bizzdesigner 5 5 10

Casewise Corporate Modeler Enterprise Edition 4 5 9 CACI International SimProcess 4 4 8

Enterprise Elements Elements Repository 4 5 9


ORIENTADO A LA UTPL


Forsight Modeling y Validation Tool set 4 5 9 Future Tech Systems Inc ENVISION VIP 3 4 7

GoAgile GoAgile MAP Product Suite 3 4 7

IBM IBM Rational Software Architect 5 5 10

IDS Scheer ARIS Bussiness Performance Edition 5 5 10 Intelligile Corporation MAP Suite + ITAA 4 5 9

Kontion Consulting UDEF Explorer 3 4 7

LogicLibrary Logidex 3 4 7 Mega International Mega Process Architect designer 3 5 8


Palisade Risk & Decision Analysis 4 4 8

Metastorm Metastorm Enterprise Products 4 5 9

Qualiware Qualiware Product Suite 4 4 4 Salamander Organisation MooD Transformation Technology 4 5 9



Simon Labs Simon Tool 3 4 7

Sparx Systems Enterprise Architect 5 5 10 IBM – TeleLogic System Architect Family + Rhapsody 5 5 10

Troux Troux 8 5 5 10


3.3.6 Repositorio.

Almacena los modelos desarrollados, si bien la mayoría de aplicaciones cuenta con uno, debe considerarse que las funciones provistas por el mismo tienen un impacto significativo en la totalidad de la funcionalidad, escalabilidad y extensibilidad de una herramienta EA.

Es usual encontrarse con sistemas de manejo de bases de datos relacionales de carácter

comercial, o sistemas comerciales orientados a objetos, pero también hay un alto porcentaje de uso de sistemas repositorios propietarios.

El repositorio a menudo dicta la vía mediante la cual los usuarios pueden colaborar, debe entonces proveer soporte para trabajo colaborativo (múltiple, concurrente, varios usuarios en el mismo repositorio). Otra alternativa es que provea la capacidad de combinar modelos desarrollados por distintos modeladores en un solo modelo. La tabla 8 muestra la valoración del repositorio desde cuatro aspectos base de evaluación para el repositorio.


ORIENTADO A LA UTPL


Debe haber a la par un conjunto de propiedades que provean diferentes funciones de manejo de datos, incluyendo la capacidad de soportar versiones de los modelos, de hacer un Roll back a versiones anteriores, de bloquear algunas partes del modelo para que no sean cambiadas, y desde luego considerar control de acceso para parte o la totalidad del modelo.

TABLA 8: Valoración del Repositorio

Vendedor Herramienta Soporte Trabajo

Colaborativo (2,5)

Integración de Modelos

(2,5)

Manejo de Propiedades de

Modelos (2,5)

Seguridad (2,5)

PUNT /10

Aam Tech SAMU 2,5 2 1 2,5 8

Acceptsoftware Accept 360 2 1,5 1,5 2 7


2,5 2,5 1 2 8

Agilense EA Webmodeler 2,5 1 2,5 1 7

Altova Altova Enterprise Suite 2,5 2 1 2,5 8

Alfabet Planning IT 2,5 2 1 2,5 8 ASG Software Solutions ASG-Rochade 2 2 2 2 8

Avolution Abacus 2 2 1,5 1,5 7

Bizzdesign Bizzdesign Architect, Bizzdesigner 2,5 2,5 1,5 2,5 9

Casewise Corporate Modeler Enterprise Edition 2 2,5 2,5 2 9

CACI International SimProcess 2 2 2 2 8

Enterprise Elements Elements Repository 2,5 2,5 1 2 8

Forsight Modeling y Validation Tool set 2 2 1 2 7

Future Tech Systems Inc ENVISION VIP 2 2 1 1 6

GoAgile GoAgile MAP Product Suite 2 2 1 1 6

IBM IBM Rational Software Architect 2,5 2,5 1,5 2,5 9

IDS Scheer ARIS Bussiness Performance Edition 2,5 2 2 2,5 9

Intelligile Corporation MAP Suite + ITAA 2 2 2 2 8

Kontion Consulting UDEF Explorer 2 2 1 2 7

LogicLibrary Logidex 2 2 1 2 7 Mega International

Mega Process Architect designer 2,5 2,5 1 2 8

CA NetViz Suite 2 2 2 2 8

Palisade Risk & Decision Analysis 2 2 2 2 8

Metastorm Metastorm Enterprise Products 2,5 2,5 2 2 9

Qualiware Qualiware Product Suite 2 2 1 2 7

Salamander MooD Transformation 2 2 2 2 8


ORIENTADO A LA UTPL


Organisation Technology


Select Solution Factory 2 2 1 2 7

Simon Labs Simon Tool 2 2 1 2 7

Sparx Systems Enterprise Architect 2,5 2,5 2,5 2,5 10 IBM - TeleLogic

System Architect Family + Rhapsody 2,5 2,5 2,5 2,5 10

Troux Troux 8 2,5 2,5 2,5 2,5 10

Visisble Visisble Advantage 2 2 1 2 7

3.3.7 Arquitectura de Implementación.

Esta sección hace referencia a una descripción de la estructura de herramientas de software y a la implementación de este. Las herramientas EA deben adoptar una o varias arquitecturas de implementación: una estructura simple de tipo usuario final o una de dos niveles a modo de cliente/servidor. La primera arquitectura requiere de herramientas que operen en una sola estación de trabajo, y generalmente que sean de uso de un usuario a la vez. En este tipo de arquitectura únicamente un modelador puede tener acceso al repositorio en un tiempo determinado (un usuario). La segunda arquitectura en cambio a pesar de sus ventajas de concurrencias para varios usuarios al mismo tiempo con respecto al repositorio, presenta generalmente un pobre “acoplamiento entre la herramienta y el repositorio” (A-H-R). La tabla 9 muestra la valoración de ambos criterios mencionados para esta sección.

TABLA 9: Valoración de Arquitectura de Implementación

Vendedor Herramienta Robustez de Modelo

Cliente / Servidor (5) Robustez de

A-H-R (5)

PUNTUACION /10

Aam Tech SAMU 4 5 9








Casewise Corporate Modeler Enterprise Edition 3 4 7 CACI International SimProcess 3 4 7

Enterprise Elements Elements Repository 3 5 8

Forsight Modeling y Validation Tool set 4 4 8


ORIENTADO A LA UTPL


Future Tech Systems Inc ENVISION VIP 3 3 6



IDS Scheer ARIS Bussiness Performance Edition 5 4 9 Intelligile Corporation MAP Suite + ITAA 3 4 7


LogicLibrary Logidex 3 3 6 Mega International Mega Process Architect designer 4 3 7








Sparx Systems Enterprise Architect 5 5 10 IBM - TeleLogic System Architect Family + Rhapsody 5 5 10

Troux Troux 8 5 5 10


3.3.8 Licenciamiento y Soporte Técnico.

Debe considerarse el tipo de licenciamiento que proveen los vendedores porque de ello dependerá cómo deberá ser usada la aplicación (en términos de usuario/ grupo de trabajo) y la cantidad de personas que podrán hacer uso de la herramienta. Es por ello conveniente la presencia de una licencia flotante que pueda brindar soporte a múltiples instancias de instalación del software EA.

Otro punto crítico es conocer si el vendedor es capaz de proveer capacitación para la adecuada

explotación y conocimiento integral de la herramienta. De la mano va el asunto de soporte técnico, es por ello que ha de considerarse el tipo de soporte técnico que ofrece el vendedor y como son los costos asociados al mismo (soporte). Los aspectos mencionados se condensan en tres criterios de evaluación para esta sección mostrados en la tabla 10.

TABLA 10: Valoración de Licenciamiento y Soporte Técnico

Vendedor Herramienta Licencia

Flotante (3,33)

Capacitación Y Soporte Técnico

(3,3)

Servicio de Instalación

(3,33)

PUNT /10

Aam Tech SAMU 3,33 3,33 3,33 10


ORIENTADO A LA UTPL


Acceptsoftware Accept 360 3,33 3,33 6,66

Adaptive Adaptive EA Manager, IT Portfolio Manager, Metadata Manager 3,33 3,33 3,33 10

Agilense EA Webmodeler 3,33 3,33 6,66

Altova Altova Enterprise Suite 3,33 3,33 6,66

Alfabet Planning IT 3,33 3,33 6,66 ASG Software Solutions ASG-Rochade 3,33 3,33 6,66

Avolution Abacus 3,33 3,33 6,66

Bizzdesign Bizzdesign Architect, Bizzdesigner 3,33 3,33 6,66

Casewise Corporate Modeler Enterprise Edition 3,33 3,33 6,66 CACI International SimProcess 3,33 3,33 6,66

Enterprise Elements Elements Repository 3,33 3,33 6,66

Forsight Modeling y Validation Tool set 3,33 3,33 6,66 Future Tech Systems Inc ENVISION VIP 3,33 3,33 6,66

GoAgile GoAgile MAP Product Suite 3,33 3,33 6,66

IBM IBM Rational Software Architect 3,33 3,33 3,33 10

IDS Scheer ARIS Bussiness Performance Edition 3,33 3,33 6,66 Intelligile Corporation MAP Suite + ITAA 3,33 3,33 6,66

Kontion Consulting UDEF Explorer 3,33 3,33 6,66

LogicLibrary Logidex 3,33 3,33 6,66 Mega International Mega Process Architect designer 3,33 3,33 6,66

CA NetViz Suite 3,33 3,33 6,66

Palisade Risk & Decision Analysis 3,33 3,33 6,66

Metastorm Metastorm Enterprise Products 3,33 3,33 3,33 10

Qualiware Qualiware Product Suite 3,33 3,33 6,66 Salamander Organisation MooD Transformation Technology 3,33 3,33 6,66


Select Solution Factory 3,33 3,33 6,66

Simon Labs Simon Tool 3,33 3,33 6,66

Sparx Systems Enterprise Architect 3,33 3,33 6,66 IBM – TeleLogic System Architect Family + Rhapsody 3,33 3,33 3,33 10

Troux Troux 8 3,33 3,33 3,33 10

Visisble Visisble Advantage 3,33 3,33 6,66

3.3.9 Resultados Arquitectónicos.


ORIENTADO A LA UTPL


Los resultados son esenciales en todo proceso de EA, porque deberán satisfacer necesidades específicas planteadas. Sirven de soporte para la correcta selección de un framework y el conjunto de herramientas asociadas al mismo.

Esos resultados deben estar especificados en un contexto sin incurrir en un elevado nivel de

abstracción, porque eso no podría ser suficiente para guiar la toma de decisiones; por otro lado si el contenido es demasiado detallado, puede dificultar la supervisión del impacto y de los riesgos.

Es necesario considerar dos tipos de resultados genéricos en los que se puede centrar como

línea base el análisis de herramientas:

• Resultados esenciales: abarcan los gráficos, modelos, y relatos que toda descripción de la EA debe incluir, para apoyar al alcance y a las características de la EA.

• Apoyo de resultados: están involucrados con los gráficos, modelos y relatos que usa la EA, describe con mayor detalle productos esenciales o aborda un dominio en particular. Es decir, involucra la especificación de extensiones que dan fundamento a los “resultados esenciales de la EA”. Por ejemplo, especificaciones de estándares de terceros usados en la EA.

Ambos criterios mencionados valoran a cada una de las herramientas en la tabla 11.

TABLA 11: Valoración de Resultados Arquitectónicos

Vendedor Herramienta Resultados Esenciales (5)

Apoyo de Resultados (5)

PUNT /10

Aam Tech SAMU 5 3 8








Casewise Corporate Modeler Enterprise Edition 5 4 9

CACI International SimProcess 4 4 8 Enterprise Elements Elements Repository 4 3 7

Forsight Modeling y Validation Tool set 4 3 7 Future Tech Systems Inc ENVISION VIP 4 3 7



IDS Scheer ARIS Bussiness Performance Edition 5 4 9


ORIENTADO A LA UTPL


Intelligile Corporation MAP Suite + ITAA 4 4 8


LogicLibrary Logidex 4 3 7

Mega International Mega Process Architect designer 5 4 9





Select Bussiness Solutions Select Solution Factory 4 3 7


Sparx Systems Enterprise Architect 5 4 9

IBM – TeleLogic System Architect Family + Rhapsody 5 5 10

Troux Troux 8 5 4 9


3.4 Utilidad

En este aspecto la evaluación incluye la idoneidad del uso de las herramientas por profesionales con perfiles específicos. La tabla 12 muestra el soporte de cada herramienta para los profesionales listados. Por ello se ha hecho una clasificación basada en áreas como:

• Arquitectura Empresarial • Arquitectura de Soluciones • Planificación estratégica / Dirección • Gerencia de Software • Arquitectura / Ingeniería de Software • Socios Externos

TABLA 12: Valoración en base a utilidad

Vendedor Herramienta Arqs. EA

Arqs. de Soluciones

Planificadores estratégicos /

Directores

Gerentes de

Software

Arquitectos / ingenieros de

Software

∑

Aam Tech SAMU 2 2

Acceptsoftware Accept 360 2 2 2 6

Adaptive

Adaptive EA Manager, IT Portfolio Manager, Metadata Manager

2 2 2 2 2 10

Agilense EA Webmodeler 2 2 2 2 8

Altova Altova Enterprise Suite 2 2 2 6


ORIENTADO A LA UTPL


Alfabet Planning IT 2 2 2 2 2 10 ASG Software Solutions ASG-Rochade 2 2 2 2 8

Avolution Abacus 2 2 2 6

Bizzdesign Bizzdesign Architect, Bizzdesigner

2 2 2 2 8

Casewise Corporate Modeler Enterprise Edition 2 2 2 2 8

CACI International SimProcess 2 2 4

Enterprise Elements

Elements Repository 2 2 4

Forsight Modeling y Validation Tool set 2 2 2 6

Future Tech Systems Inc ENVISION VIP 2 2 2 2 8

GoAgile GoAgile MAP Product Suite 2 2

IBM IBM Rational Software Architect 2 2 2 6

IDS Scheer ARIS Bussiness Performance Edition

2 2 2 2 8

Intelligile Corporation MAP Suite + ITAA 2 2 2 2 2 10

Kontion Consulting UDEF E2plorer 2 2 2 6

LogicLibrary LogideX 2 2 2 6 Mega International

Mega Process Architect designer 2 2 2 2 2 10



Metastorm Metastorm Enterprise Products 2 2 2 2 8

Qualiware Qualiware Product Suite 2 2 2 2 8

Salamander Organisation

MooD Transformation Technology

2 2 2 6


Select Solution Factory 2 2 2 6

Simon Labs Simon Tool 2 2 SparX Systems Enterprise Architect 2 2 2 6

IBM - TeleLogic

System Architect Family + Rhapsody 2 2 2 2 2 10

TrouX TrouX 8 2 2 2 2 8

Visisble Visisble Advantage 2 2 2 6

3.5 Resultados de la evaluación


ORIENTADO A LA UTPL


La siguiente Tabla ilustra la contrastación basada en puntuaciones. Algunas bajas puntuaciones se deben a la falta de especificación de determinada herramienta en una o varias métricas de evaluación planteadas.

TABLA 13: Resultados Finales de herramientas


ORIENTADO A LA UTPL


Vendedor Herramienta Metodologías

Modelos

Interfaz

Automatización

Personalización

Manipulación

Repositorio

Arq. Impl

Licencia_mien

to

Resultados

Arqs.

Utilidad

TOTAL

Aam Tech SAMU 5 5 8 9,16 7,5 9 8 9 10 8 2 7,33 Acceptsoftware Accept 360 2,5 2,5 5 3,33 5,8 7 7 7 6,66 7 6 5,44 Adaptive Adaptive EA Manager, IT Portfolio

Manager, Metadata Manager 2,5 2,5 6,66 6,33 7,83 9 8 8 10 9 10 7,26

Agilense EA Webmodeler 2,5 2,5 6,66 6,33 4 7 7 9 6,66 7 8 6,06 Altova Altova Enterprise Suite 2,5 5 5,5 3 5,83 7 8 7 6,66 8 6 5,86 Alfabet Planning IT 2,5 2,5 5,5 6,33 5,33 7 8 8 6,66 8 10 6,35 ASG Software Solutions

ASG-Rochade 2,5 2,5 5,5 6,33 4,5 7 8 8 6,66 7 8 6,00

Avolution Abacus 2,5 10 6,66 6,33 5,33 7 7 7 6,66 7 6 6,50 Bizzdesign Bizzdesign Architect, Bizzdesigner 2,5 7,5 9,16 9,66 8,66 10 9 9 6,66 10 8 8,19 Casewise Corporate Modeler Enterprise Edition 10 10 6,66 9,33 7,5 9 9 7 6,66 9 8 8,38 CACI International SimProcess 2,5 5 5,5 6,33 4,5 8 8 7 6,66 8 4 5,95 Enterprise Elements Elements Repository 2,5 2,5 4,5 6,33 5,13 9 8 8 6,66 7 4 5,78 Forsight Modeling y Validation Tool set 2,5 5 5 5,83 3,33 9 7 8 6,66 7 6 5,94 Future Tech Systems ENVISION VIP 2,5 5 5 6,33 2 7 6 6 6,66 7 8 5,59 GoAgile GoAgile MAP Product Suite 2,5 2,5 4,5 5,83 2 7 6 8 6,66 7 2 4,91 IBM IBM Rational Software Architect 5 5 8,83 9,66 7,83 10 9 10 10 10 6 8,30 IDS Scheer ARIS Bussiness Performance Edition 2,5 7,5 9,16 9,16 6,5 10 9 9 6,66 9 8 7,86 Intelligile Corporation MAP Suite + ITAA 5 2,5 5 8,83 4,5 9 8 7 6,66 8 10 6,77 Kontion Consulting UDEF Explorer 2,5 2,5 4,5 6,33 2,5 7 7 6 6,66 7 6 5,27 LogicLibrary Logidex 2,5 2,5 4,5 6,33 2,5 7 7 6 6,66 7 6 5,27 Mega International Mega Process Architect designer 5 5 6,33 9,16 2,8 8 8 7 6,66 9 10 7,00 CA NetViz Suite 2,5 2,5 5 6,33 2 7 8 6 6,66 7 4 5,18 Palisade Risk & Decision Analysis 2,5 2,5 6,33 6,33 3,33 8 8 8 6,66 7 4 5,70 Metastorm Metastorm Enterprise Products 2,5 5 6,66 9,33 7 9 9 9 10 8 8 7,59 Qualiware Qualiware Product Suite 2,5 2,5 5 5,83 4,6 4 7 7 6,66 7 8 5,4+ Salamander Organisation

MooD Transformation Technology 2,5 2,5 5,5 6,33 4 9 8 8 6,66 7 6 5,95


Select Solution Factory 2,5 5 6,33 6,33 4 8 7 6 6,66 7 6 5,89

Simon Labs Simon Tool 2,5 5 6,33 6,33 2 7 7 8 6,66 7 2 5,44 Sparx Systems Enterprise Architect 8 10 10 10 9,66 10 10 10 10 6,66 9 6 9,21 IBM – TeleLogic System Architect Family + Rhapsody 5 7,5 10 9,66 9,26 10 10 10 10 10 10 9,22 Troux Troux 8 10 7,5 10 10 8,83 10 10 10 10 9 8 9,39 Visisble Visisble Advantage 2,5 2,5 6,33 5,83 4 7 7 7 6,66 7 6 5,62


ORIENTADO A LA UTPL


EA – UTPL

SECCION 4:

DEFINICION DEL FRAMEWORK


ORIENTADO A LA UTPL


4.0 ELEMENTOS CONSTITUTIVOS

4.1 Introducción

Como se ha mencionado en los capítulos anteriores, la implementación de una EA apoya en la toma de decisiones estratégicas y efectivas que mejoran la calidad, eficacia y responsabilidad del negocio, así como ayuda a responder de manera rápida y positiva a las oportunidades y desafíos del mercado, consolidaciones del sector y avances tecnológicos.

Dicha EA solo puede ser consolidada con la adecuada selección de componentes y elementos adecuados. Es necesario definir los elementos involucrados en el dominio del proyecto EA-UTPL, así como los componentes y sus respectivos entregables y artefactos.

4.2 Componentes [1]

En base cimentada principalmente al enfoque propuesto por TOGAF 9, la taxonomía de componentes se deriva del mismo, abarcado tres grandes grupos:

4.2.1 Método de desarrollo arquitectónico (ADM)

Especificado ya en capítulos anteriores, es el método definido por TOGAF para el desarrollo de una EA que cumpla con las necesidades empresariales (de negocio) y de TI, en este caso particular para la institución. Ha sido ajustado y personalizado según las necesidades específicas de la institución y en el capítulo siguiente será definido como se debe utilizar para gestionar la ejecución de las actividades de desarrollo de la arquitectura EA-UTPL.

El flujo del proceso será visto en términos de un ciclo de desarrollo arquitectónico (architecture development cycle), dicho proceso será enteramente iterativo y cíclico. Cada paso debe iniciar con la verificación de los requisitos, teniendo en cuenta que la fase C involucra una combinación de arquitectura de datos y arquitectura de aplicaciones.

4.2.2 El continuum arquitectónico

Debe ser interpretado como un "repositorio virtual" de todos los artefactos arquitectónicos disponibles en la institución. Incluye modelos, patrones y descripciones arquitectónicas, entre otros. Estos artefactos pueden existir específicamente al interior de la institución, o en general en la industria de las TI.

El continuum empresarial consiste tanto del continuum arquitectónico como del continuum de soluciones. El 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 institución. El de soluciones describe la implementación del continuum arquitectónico mediante la definición de bloques constitutivos de solución (solution building blocks).

4.3 Elementos


ORIENTADO A LA UTPL


Son la base que guiará al proyecto a una adecuada implantación del proyecto EA-UTPL. Para definir los elementos involucrados existen varias consideraciones [1A] que deben ser tomadas en cuenta:

• Los objetivos del Negocio deben estar bien definidos y acordados antes de iniciar la implantación de cualquier solución de TI.

• Agregar valor al negocio a través de la tecnología de Información es la razón primaria al tomar decisiones de inversión.

• Las decisiones de arquitectura de TI deben maximizar la interoperabilidad y reusabilidad. • Las decisiones de arquitectura de TI deben potenciar la agilidad y la eficiencia empresarial de

la institución. • El marco arquitectónico debe establecer estándares para satisfacer necesidades comunes de

los clientes internos y externos de la institución. • Los requerimientos de TI y de negocio deben adoptar soluciones tecnológicas comerciales en

vez de soluciones propias o personalizadas, que respondan a los principios arquitectónicos en su nivel.

• La identificación, integración e implantación de servicios es la clave para asegurar la flexibilidad y la adaptación del negocio.

• El marco arquitectónico debe ser consistente con las políticas y objetivos estratégicos de la institución.

De lo anterior se deriva una taxonomía puntual de elementos que involucra: 4.3.1 Eventos de negocio

Un evento de negocio (empresarial) es un cruce entre un sistema de información comercial y una función de negocio. Un acto empresarial es un hecho a determinante. Se invoca por la función empresarial, y los sistemas de información empresarial se ejecutan en respuesta a dicha invocación. Eventos de negocio pueden establecerse dentro de los ciclos de evento de negocios y para ciclos naturales, o ambas cosas. 4.3.2 Organizaciones de negocio

Una organización es una unidad dentro de un contexto de negocio, en este particular caso se denomina “institución” o “universidad”. Está establecida por una estratificación jerárquica, por lo que se puede representar cualquier cantidad de niveles organizacionales. 4.3.3 Ciclo de negocio

Durante este se producen eventos de negocios, tales como informes financieros, de vacaciones, de planificaciones empresariales y similares. Dicho ciclo de negocios puede ser simple o complejo. Si es complejo, el ciclo económico consiste en realidad en otros ciclos económicos representados en la estructura de un ciclo económico.


ORIENTADO A LA UTPL


4.3.4 Calendario de negocios

Un calendario del ciclo de negocios es un conjunto de datos recurrentes basados en el calendario, es decir, las fechas que son de interés para la universidad. Por ejemplo, bimestrales, semestrales o semanal, mensual, diario, etc. Los ciclos de calendario de negocio son enlazados a los eventos de negocio para a través de ello poder conocer el tiempo y el lanzamiento de cada evento de negocio. 4.3.5 Funciones de negocio

Una función de negocios es un conjunto de texto que describe la organización jerárquica de las actividades realizadas por una posición dentro de la institución. Las funciones de negocios son totalmente basadas en humanos y si es necesario el apoyo de un sistema de información de negocios, a continuación, un evento de negocios es iniciado. Las funciones de negocio son independientes de las instituciones y se pueden asignar a más de una, o a subdivisiones de la misma. 4.3.6 Sistemas de información

Es un sistema de información de negocio basado en software y se encuentra manejado a través de una metabase. Es conocido por sus características, sus ciclos de operación (de negocios y calendario), sistemas de información subordinados de negocio, bases de datos empleadas, vistas y recursos asociados vida nodos del ciclo. 4.3.7 Dominios de bases de datos

Un dominio de base de datos es un conjunto jerárquicamente organizado de descripciones no intensivas asociadas con un enfoque de misión. Los dominios de bases de datos analizados permiten la identificación de clases y objetos inherentes al tema, así como elementos de datos institucionales y clases propietarias. A menudos dichas clases propietarias a nivel de bases de datos se convierten en tablas. 4.3.8 Clases tipo objetos de bases de datos

Son largas colecciones de datos y procesos que se encuentran ligadas debido a razones

basadas en el negocio; cuando son instanciadas, se procede a través de estados bien definidos. Un objeto de base de datos puede existir de dos maneras: como colección de tablas de base de datos interrelacionadas, o siendo un conjunto basado en columnas anidadas como estructuras dentro de una tabla. Las filas que forman un objeto son transformadas desde un estado válido hacia otra a través de procesos de tablas y objetos de la dase de datos, los que pueden pertenecer a uno o varios dominios. 4.3.9 Objetos de bases de datos de sistemas de información


ORIENTADO A LA UTPL


Es una colección de procesos definida dentro del dominio del sistema manejador de bases de

datos (DBMS), esta se encuentra definida como un procedimiento almacenado que transforma una o más filas de un objeto de base de datos desde un estado válido hacia otro. 4.3.10 Nivel de gestión

Es un nivel burocrático de gestión dentro de la configuración de la organización. Ejemplos de ello son los ejecutivos, séniores, niveles medio, y primer nivel. 4.3.11 Misión

Son descripciones textuales y jerárquicas que definen la existencia misma de la institución, de esta manera se convierten en son las metas finales y objetivos que miden el cumplimiento de la institución desde dentro de diferentes funciones de negocio y organizaciones. La universidad estaría incompleta si una de sus misiones no está definida del todo o parcialmente; de ello deriva el hecho de destacar que no todas las instituciones cumplen sus misiones de manera simultánea (estado ideal), sino que son cumplidas en orden, a medida y sobre tiempo, por lo deben estar sometidas constantemente a revisiones. 4.3.12 la institución apuntando a su misión

Una misión institucional es la asociación de la institución en sí, con una misión que esta debe cumplir. La cardinalidad de esta relación puede estar dada en dos vías: múltiples instituciones asociadas a una sola misión, o una institución asociada a varias misiones. La especificación contenida dentro del artefacto “misión organizacional” debe ser más refinada que la descripción contenida dentro de la declaración general de misión o del contexto de la organización en sí. 4.3.13 La institución apuntando a sus funciones

Cada función sirve de soporte a una misión específica o a varias, la cardinalidad establecida para esta relación es similar a la del punto anterior. Sin embargo cabe destacar que las funciones pueden ser asociadas individual o colectivamente con sistemas de información de negocio, cuando eso sucede, eventos de negocio son creados. 4.3.14 Cargos

Se puede denominar de esta manera a cada colección definida de tareas de trabajo que pueden ser realizadas por una o más personas. Son a menudo asignados a una o varias áreas dentro de la Institución. 4.3.15 Cargos enfocados a la misión


ORIENTADO A LA UTPL


Se formalizan mediante roles, así dichos roles son asignados para lograr cumplir una función

particular dentro de la institución, ya que con ello se alimenta el cumplimiento de una misión. 4.3.16 Análisis del nodo de ciclo de vida de recursos

Se define como un estado de ciclo de vida dentro de un recurso, si por ejemplo el recurso es un empleado, el nodo de ciclo de vida puede ser: requisición de empleado, empleado candidato, nuevas contrataciones, empleados asignados, empleados revisados, empleados separados de, etc. 4.3.17 Recursos

Se definen con bienes permanentes de valor para la universidad. Incluyen por ejemplo: instalaciones, bienes, personal, dinero, acciones, incluso abarcan conceptos abstractos como reputación o certificaciones como los tipos de acreditaciones formales. La ausencia de cualquier recurso simplemente incide en un hecho de incompletitud institucional.


ORIENTADO A LA UTPL


5.0 DEFINICION DEL FRAMEWORK

A partir de las metodologías existentes, no fue posible llegar a un consenso para determinar cuál de todas es la más adecuada, debido a que cada una mostraba fortalezas y debilidades en determinados aspectos (como se vio en el análisis del capítulo 2). Es por ello que el framework a definirse se erige sobre el esquema híbrido, planteado principalmente por el ADM de TOGAF, tomando también como referencia artefactos de Zachman y haciendo uso de la distribución federada del FEA, así como algunos tips de Gartner.

El esquema central del framework está conformado por las 9 fases del ADM de TOGAF, y

dentro de cada uno de ellos se inyectarán los artefactos correspondientes a las otras metodologías (cuando lo requieran). El presente capítulo abarca la especificación necesaria para saber exactamente qué pasos se deben seguir para llegar a la consecución del proyecto EA-UTPL.

FasePreliminar

Fase B:ArquitecturaDe Negocio

Fase C:Arquitecturasde Sistemas

de Información

Fase D:Arquitectura

De Tecnología

Fase E:OportunidadesY Soluciones

Fase F:Plan de

Migración

Fase G:Implementación de Gobernanza

Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica

Gestión deRequisitos

Figura 16: Método de desarrollo arquitectónico [1]


ORIENTADO A LA UTPL


5.1 Fase Preliminar



de Información

Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica


Fase Preliminar

En esta fase se persigue encontrar el dónde, qué, por qué, quién, y cómo referentes a la construcción de la arquitectura. Lo anterior se condensa en la definición de "cómo hacer la arquitectura" para el proyecto EA-UTPL.

Hay dos aspectos principales a considerarse: la definición del framework que se utilizará, y la

definición de los principios arquitectónicos que servirán para sustentar al trabajo arquitectónico. Cabe destacar también que el enfoque institucional para la reutilización de los activos de la arquitectura es una parte fundamental tanto de la definición del framework así como los principios arquitectónicos.

5.1.1 Objetivos

• Revisar el contexto de la UTPL para llevar a cabo el ejercicio de arquitectura empresarial. • Identificar los stakeholders principales y secundarios que serán afectados por la directiva de

crear una EA, así como determinar las necesidades y prioridades de institución. • Asegurarse de que todos los involucrados que participarán en el proceso EA-UTPL se ha

comprometido con éxito.


ORIENTADO A LA UTPL


• Permitir al patrocinador de la arquitectura crear los requisitos para trabajar a través de las áreas de negocio afectadas en la institución.

• Identificar los elementos y el alcance de institución, así como definir las limitaciones y supuestos (mucho más en este caso por tratarse de una arquitectura federada).

• Confirmar un marco de gobernanza y de apoyo que proporcionen procesos de negocio y recursos para la gobernanza de arquitectura.

• Seleccionar y aplicar herramientas de apoyo y otras infraestructuras destinadas a apoyar la actividad arquitectónica.

• Definir los principios arquitectónicos que formarán parte de las restricciones y políticas de cualquier trabajo arquitectónico.

5.1.2 Enfoque de entregables El conjunto de artefactos relacionados a esta fase deben abarcar los siguientes aspectos:

• Definir a la organización. • Lograr una identificación de conductores y elementos clave en el contexto institucional. • Definir los requisitos para EA-UTPL. • Definir los principios arquitectónicos que darán forma a EA-UTPL. • Definir los criterios que se utilizarán. • Definir las relaciones entre los marcos de gestión. • Evaluar de la madurez de la arquitectura empresarial deseada.

5.1.3 Contexto organizacional

La base de todo es el alcance (ámbito) que se busca, pues este será el desafío clave que la arquitectura perseguirá. Partiendo del hecho de que la EA es un activo de planificación estratégica que se está convirtiendo cada vez más una parte integral de gestión empresarial, el ámbito de aplicación arquitectónica determinará que stakeholders claves deben ser tomados en cuenta y cómo la EA ayudará a la gestión de la institución.

De lo anterior deriva el hecho de conocer en un principio el contexto que rodea al framework EA-UTPL, porque ello conducirá a tomar decisiones efectivas y bien informadas. Dicho contexto debe abordar secciones como:

• Modelos comerciales existentes para la adopción de una EA. • Planes presupuestarios para la EA. • Asuntos clave y puntos de atención de los stakeholders. • Asuntos esenciales del negocio, estrategias, principios, metas y controladores. • Procesos que apoyen la ejecución del cambio y el funcionamiento de las TI.

o Gestión de proyectos y administración del portafolio de proyectos. o Sistemas de gestión.


ORIENTADO A LA UTPL


o Análisis del negocio y de diseño. o Gestión de portafolio de aplicaciones, tecnología e información.

• Perspectiva de línea base arquitectónica. • Nivel de formalidad y el rigor que se aplicará. • Puntos de contacto con otras organizaciones, procesos, roles y responsabilidades.

5.1.3.1 Requerimientos que solventan la adopción de la EA

Aspectos imperativos del negocio solventan la EA para manejar requerimientos y ejecutan métricas necesarias para que el trabajo arquitectónico pueda ser realizado. Estos aspectos deberán estar lo suficientemente claros para que el ámbito de la fase preliminar este bien encaminada a los resultados esperados del negocio y a los requerimientos de base; de igual forma definirá y realzará los requerimientos de información de negocio y dará las estrategias necesarias para que el trabajo arquitectónico pueda ser realizado.

5.1.3.2 Principios organizacionales

La definición de los principios arquitectónicos es un aspecto clave para el desarrollo de una la EA formal, ya que el trabajo arquitectónico está conformado por los principios de negocios así como los principios de arquitectura.

• Los principios arquitectónicos se basan normalmente en los principios de negocio. • Definir principios de negocios por lo general se encuentra fuera del ámbito de la función de la

arquitectura.

El conjunto de principios arquitectónicos debe referirse a los principios y objetivos de negocio, también a los conductores estratégicos de negocio definidos en otros lugares dentro de la UTPL. Ha de considerarse que el hecho de la gobernanza arquitectura está estrechamente ligado a los principios arquitectónicos mencionados. Los responsables de la gobernanza deberán ser los responsables de aprobar también los principios arquitectónicos así como resolver algunos aspectos de la arquitectura.

5.1.3.3 Frameworks de gestión

El ADM adaptado es un método que debe coexistir con la mejora de las capacidades operativas de los frameworks de gestión que están presentes dentro de la institución. Tipos / grupos de frameworks incluyen:

• La capacidad de gestión de negocios - determinar qué capacidades de negocios están obligados a ofrecer un valor empresarial, incluida la definición de retorno sobre la inversión y los requisitos de control y medidas de rendimiento dentro de la UTPL.


ORIENTADO A LA UTPL


• Portafolio / Métodos de Gestión de Proyectos - determinar cómo la UTPL gestiona sus iniciativas de cambio.

• Métodos de Gestión de Operaciones - describir cómo la UTPL efectúa sus operaciones del día a día, incluyendo TI.

• Métodos de desarrollo de soluciones - formalizar la forma en que los sistemas empresariales se suministran de acuerdo con las estructuras creadas en la arquitectura de TI.

Durante la aplicación de la arquitectura debe ser consciente de su impacto toda lainstitución,

la fase inicial implica hacer trabajos necesarios para adaptar el ADM de definir un marco específicos de cada organización (en este caso en el ámbito de educación superior).

Frameworks de Gestión de la

Capacidad de Negocio

Método deDesarrollo

ArquitectónicoFrameworks

de Gestión de Proyecto / Portafolio

Frameworks de

DesarrolloDe

Soluciones

Frameworks de Gestión de

Operaciones

Figura 17: Relación del ADM con los frameworks de una institución [1]

5.1.3.4 Planeación para madurez de EA

Modelos de Madurez de Capacidad (CMM) son formas útiles de evaluar los niveles de madurez para aplicar la EA y aspectos de negocio.

Los niveles de madurez proporcionan una medida estratégica de la capacidad de la institución para el cambio, así como una serie de pasos secuenciales que permitan mejorar dicha capacidad. Un


ORIENTADO A LA UTPL


buen modelo de madurez de una EA abarca una amplia gama de características, ya sea de negocios y técnicas.

Para determinar la madurez de la EA institucional se deberán tener en consideración algunos aspectos:

Tabla 14: Criterios de evaluación de madurez para una EA [1]

Prácticas

Framework Arquitectónico

Framework de estándares plantillas y especificaciones para poder organizar y presentar componentes arquitectónicos de negocio y técnicos.

Procesos Arquitectónicos

Metodología para definir, desarrollar y mantener los componentes arquitectónicos.

Gobernanza Arquitectónica

Principios, derechos de decisión, reglas y métodos para conducir el desarrollo y alineamiento arquitectónico en la institución.

Valor Arquitectónico

Definir, medir y comunicar el valor e impacto de la arquitectura con respecto al negocio.

Planeación

Planeación Estratégica

Mediante el uso de principios arquitectónicos y planos para alinear las necesidades del negocio con las capacidades TI, se define el portafolio de estrategia y dirección, así como los recursos asignados.

Planeación Arquitectura

Definición de una visión y un plan de actuación para varios dominios TI mediante la previsión de las necesidades de negocio y las tendencias existentes, y hacer un desarrollo de la arquitectura.

Personas

Estructura y habilidades organizacionales

Definición, planificación y gestión de roles, responsabilidades y competencias para la gestión de la arquitectura.

Gestión de comunicación y stakeholders

Gestión de la comunicación y las expectativas con stakeholders de TI y de negocio que estén interesados o influenciados por la gestión arquitectónica.

Tabla 15: Criterios de evaluación de madurez para una EA [1]


ORIENTADO A LA UTPL


Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

Planeación

Planeación Estratégica

Ninguna Basado en proyectos

Priorización del portafolio de proyecto basado en un plan de

actuación

Construir una entrada clave para unir al negocio y

planeación de TI

La planeación de negocio TI brindan eficiencia y

agilidad extendida en la institución

Planeación Arquitectura

Basado en proyectos

Visión limitada y plan de actuación

Proceso de planeación arquitectónica

establecido Mejora continua Incluye capacidades

extendidas de la institución

Financiamiento Arquitectónico

Asignación basada en proyectos

Fondo de arquitectura central

Financiados con cargo a la eficiencia

Financiación en función del margen de los servicios

Financiación por transacción

Prácticas

Framework Arquitectónico Ninguna

Framework limitado, cubre alguna información

Cubre información y proceso, pero la adopción no es

consistente

Consistentemente adoptado de manera interna

Framework compartido externamente

Proceso Arquitectónico

Procesos basados en proyectos

Procesos definidos enfocados

primariamente sobre la infraestructura

Procesos definidos a través de dominios de

TI

Procesos definidos a través de dominios de negocio y TI

Proceso definido con una clara capacidad de ser adaptado y extendido

Gobernanza Ninguno / Basado en proyectos

Algunos de los principios definidos

para revisar algunos componentes

Juntas y procesos definidos de

gobernanza de TI

Modelo de gobernanza compartida con negocios y TI

Gobernanza de negocio y TI continuamente mejorada para responder al cambio

Valor y Medición Ninguno / Basado en proyectos

Métricas de costo de TI

Métricas de rendimiento de costo

de TI

Objetivos de negocio definidos y medidos, así como métricas

de rendimiento.

Resultados de negocio y métricas de rendimiento de

TI

Personas

Estructura y habilidades

organizacionales

Sin roles, responsabili

dades

Roles formales de tecnología dentro de

proyectos

Roles formalizados y responsabilidades

Rastreo de carrera profesional limpia

Desarrollo proactivo con entrada externa

Gestión de comunicación y

stakeholders

Basado en proyectos

Stakeholders clave identificados e

informados

Consultoría regular con el negocio

Comunicación pro activa y retroalimentación con el

negocio

Colaboración con la institución entera


ORIENTADO A LA UTPL


5.1.4 Definición del equipo de trabajo

La institución se encuentra segmentada en áreas, por lo que la TI se encuentra manejada abarcando campos específicos. Así a nivel de alta gerencia, se debe difundir el contexto general del enfoque EA y lo que ello implica.

Dado el manejo por áreas (departamentos) se planteará a continuación la estructura que se considera más adecuada para la conformación del equipo de trabajo EA, así como se buscará el personal más adecuado a enrolar de acuerdo a perfiles específicos.

La distribución se debe basar en un área de TI encargada del manejo de recursos de TI (entre ellos la EA). Para ello inicialmente es necesario cuál debe ser el tamaño adecuado del departamento en base al tamaño de la institución, a quienes debe informar dicho departamento y cómo será la estructura del mismo.

En primera instancia una vez delimitado el dominio de la arquitectura y basado en el hecho que la institución maneja una oficina de gestión de proyectos (PMO, por sus siglas en inglés) para asuntos de TI, se puede asumir una visión departamental de hasta cincuenta activos humanos. Lo anterior se aplica a una EA embebida dentro de la PMO, para este particular la PMO es independiente (de momento) por lo que se recomienda un estimado de veinte a treinta activos humanos en el equipo EA, porque como se dijo la PMO reside aparte de la EA y necesita de sus propios activos humanos. La figura ilustra la relación de personal con respecto al tamaño y estructura organizacional.


ORIENTADO A LA UTPL


CIO(Director UGTI)

Director o Vicepresidente

De la EA

Director oGerente de

Gobernanza de TI Director oGerente de

Arquitectos deSoluciones

Director oGerente de

Arquitectos deDominio

Director oGerente de TecnologíasEmergentes

Coordinador de Servicios deInvestigación

4 recursos

* Ejecuta la junta de revisión de la EA.* Mantiene el sitio web de la EA.* Gestiona estándares.* Audita la cooperación (Liaison).* Da soporte al repositorio EA.

4 recursos

* Apoya proyectos* Da una visión general de la arquitectura.* Realiza evaluaciones a la arquitectura.* Evalúa a los vendedores.

4 recursos

*Plataforma de estrategias.* Arquitectura de software.* Arquitectura de redes.* Arquitectura de datos.* Arquitectura de seguridad.

4 recursos

* Prueba arquitecturas.* Evalúa tecnologías emergentes.Guía el desarrollo de componentes.Evalúa herramientas de TI.

2 recursos

* Gestiona la investigación.* Realiza análisis y estudios.* Gestiona la presentación comercial.* Realiza evaluación de competitividad.

Figura 18: Estructura del equipo de trabajo [30]

El grupo de trabajo descrito en la figura anterior a nivel más detallado implica las siguientes descripciones:

• Director de la arquitectura empresarial (DEA): Deberá tener diez años de experiencia en función de la institución como mínimo. Dicha experiencia será en función de la capacidad de comunicación superior que es capaz de efectuar debido a su liderazgo. Esta persona debe ser capaz de traducir las ideas complejas y la tecnología en lenguaje de alta dirección. Debe ser muy influyente en las decisiones técnicas clave que afecten a la institución a largo plazo.

• Director de gobernanza de TI (DGTI): deberá ser responsable de los estándares y liderará la junta de revisión de la arquitectura. Coordinará de aprobación de diseños de la arquitectura propuesta para asegurar que los proyectos estén alineados con las normas y la estrategia de TI. Asignará los recursos necesarios para garantizar que los proyectos se completen en el plazo comprometido y presupuestado, así como que se integren con proyectos de la arquitectura de TI. Aprobará las políticas de arquitectura, estándares y procedimientos, y será encargado del mantenimiento del repositorio arquitectónico.

• Director de arquitectos de soluciones (ADS): Deberá actuar como embajador de EA para otros equipos dentro del contexto de TI. Esta persona con frecuencia se reunirá con líderes empresariales para entender y traducir la dirección de negocios en las necesidades de


ORIENTADO A LA UTPL


tecnología. Priorizará y asignará el trabajo a los arquitectos de soluciones. Conducirá el a los arquitectos de soluciones al desarrollo de frameworks comunes sobre la base de la industria y los estándares internos de la EA. Trabajará en estrecha colaboración con los equipos de desarrollo de aplicaciones para ayudar a identificar y definir los servicios técnicos que son candidatos para su reutilización en toda la institución.

• Arquitecto de dominio (ADD): Será responsable de la integridad de los diseños dados por los expertos de dominio a través de toda la TI. Revisa y coordina los esfuerzos a través de las áreas de diseño. Debe asistir a todas las reuniones de la junta y deberá negociar soluciones cuando surjan desacuerdos con respecto a las opciones de diseño.

• Director de tecnologías emergentes (DTE): Estará encargado de realizar pruebas a la arquitectura y evaluará continuamente la aparición de tecnologías emergentes. Preparará la rentabilidad para justificar la adopción de nuevas tecnologías y ayudará a las comunicaciones internas que conducirán a su vez a la adopción exitosa de las principales prácticas y tecnologías.

• Coordinador de servicios de investigación (CSI): Deberá actuar como punto único de contacto para otras instituciones de investigación y de educación, basado en el contexto de las TI y el negocio. Negociará y gestionará los contratos de investigación con empresas externas y responderá a las peticiones de informes de investigación dentro de la TI y del negocio. Preparará resúmenes de información de la investigación, acumulada de varias fuentes, para el uso de gestión. Realizará un seguimiento de las estadísticas de utilización de la firma de investigación e informes sobre la viabilidad de los proveedores de servicios prestados por/para la UTPL. Buscará activamente nuevas fuentes de información para la gestión y producirá actualizaciones periódicas. De igual manera deberá evaluar los aspectos estratégicos referentes a las TI.

5.1.5 Ejemplos de definición de principios arquitectónicos

1. Principios arquitectónicos de negocio Estos ejemplos principios de gestión de la información se aplican a todas las unidades de negocio dentro de la institución:

• Las decisiones de gestión de la información están hechas para proporcionar el máximo beneficio a la institución en su conjunto.

• Todas las unidades de negocio en la institución participan en las decisiones de gestión de la información necesaria para cumplir los objetivos de negocio.

• Las operaciones de la institución se mantienen a pesar de las interrupciones del sistema. • Para el desarrollo de aplicaciones que se utilizan en toda la institución se prefiere que sean

aplicaciones globales, y que no haya desarrollo de aplicaciones similares o duplicadas funcionando por separado en distintas unidades de negocio.

• La arquitectura se basa en un diseño de los servicios que reflejan las actividades del mundo real de negocios con los procesos de negocio de la institución (o entre ella).


ORIENTADO A LA UTPL


• Los procesos de gestión de la información dentro de la UTPL implican cumplir con todas las leyes, políticas y regulaciones.

• La función de la TI es responsable de la propiedad y la aplicación de procesos de TI y la infraestructura que permiten a las soluciones satisfacer las necesidades definidas por el usuario en términos de funcionalidad, de niveles de servicio, costo y tiempo de entrega.

• La propiedad Intelectual de la institución debe ser protegida y esta protección debe reflejarse en la arquitectura de TI, así como en la implementación y los procesos de gobernanza.

2. Principios arquitectónicos de datos

Estos ejemplos principios de gestión de la información se aplican a todas las unidades de relacionadas al manejo de datos dentro de la institución:

• Los datos son un activo que tiene valor para la organización y en consecuencia deben ser

bien administrados. • Los usuarios tienen acceso a los datos necesarios para ejercer sus funciones y por lo tanto,

los datos son compartidos a través de las unidades funcionales y de negocio de la organización.

• Los datos son accesibles a los usuarios para realizar sus funciones. • Cada elemento de dato tiene un administrador responsable de la calidad de dicho. • Los datos se definen coherentemente en toda la organización y las definiciones son

comprensibles y están disponibles para todos los usuarios. • Los datos están protegidos por el uso no autorizado y la divulgación. 3. Principios arquitectónicos de aplicaciones

• Las aplicaciones son independientes de elecciones de tecnologías específicas y por lo tanto

pueden operar en una variedad de plataformas tecnológicas. • Las aplicaciones son fáciles de usar y la tecnología subyacente es transparente para los

usuarios, así ellos pueden concentrarse en sus tareas puntuales.

4. Principios arquitectónicos de tecnología

• Los cambios a aplicaciones y tecnología son hechos solo en respuesta a las necesidades del negocio.

• Los cambios en el entorno de la información de la institución deben aplicarse de manera oportuna.

• La diversidad tecnológica es controlada para reducir al mínimo los gastos de experiencia de mantenimiento en la conectividad, entre entornos de procesamiento múltiple.

• Software y hardware deben ajustarse a los estándares definidos que promueven la interoperabilidad de los datos, de aplicaciones y tecnología.


ORIENTADO A LA UTPL


5.1.6 Análisis de brechas

Permitirá identificar los desafíos que existen actualmente en la TI actual de la UTPL y que obstaculizan la capacidad de la universidad para cumplir su plan estratégico de negocio. Con ello ayudará a validar continuamente la arquitectura en desarrollo.

Lo más importante es resaltar el déficit existente en la línea base arquitectónica y la

arquitectura objetivo, abarcando ítems que deliberadamente han sido omitidos, que han sido accidentalmente dejados fuera, o que aún no hayan sido definidos. Es clave considerar lo que ha sido olvidado, y que las brechas más significativas serán dadas por las expectativas de los stakeholders que no hayan sido abordadas en el trabajo arquitectónico.

La brecha entre los activos de TI actuales y los que se busca por objetivo, da como resultado

dos dimensiones:

• Nuevos activos de TI. (EJ: una estrategia de inversión) • Una reorganización de los activos de TI existentes (Ej: Una estrategia de contención)

Los principales recursos de brechas potenciales incluyen:

• Brechas de dominio de negocio:

o Brechas de personas (por ejemplo, los requisitos de entrenamiento cruzado) o Brechas de proceso (por ejemplo, las ineficiencias de proceso) o Brechas de herramientas (por ejemplo, funcionalidad duplicada o faltante de una

herramienta) o Brechas de información. o Brechas de medición. o Brechas financieras. o Brechas de instalaciones (edificios, oficinas, etc.)

• Brechas de dominio de datos: o Datos sin suficiente circulación. o Datos no alojados en donde se necesitan. o No son los datos que se necesitan. o Datos no disponibles en donde son necesitados. o Datos no creados o Datos que no se consumen. o Brechas entre relaciones de datos.

• Aplicaciones impactadas, eliminadas, o creadas • Tecnologías impactadas, eliminadas, o creadas

5.1.7 Entradas

En términos abstractos para cada fase existen entradas, éstas serán interpretadas como artefactos de referencia externos (referentes a la institución o ajenos) que deben ser considerados.


ORIENTADO A LA UTPL


5.1.7.1 Entradas arquitectónicas

• Modelos pre-existentes que pueden ser usados como línea base para poner en marcha el proyecto EA-UTPL.

• Modelo organizacional para la EA. • Framework de arquitectura existente, si existe. • Principios arquitectónicos existentes. • Repositorio de arquitectura existente, si existe.

5.1.7.2 Entradas no arquitectónicas

• Estrategias, planes, principios, objetivos y conductores del negocio. • Frameworks principales que operan en la institución para gestión de portafolios/proyectos. • Políticas y marcos jurídicos, incluida la estrategia de gobernanza de la arquitectura. • Presupuesto para los alcances de proyectos. • Colaboración y acuerdos contractuales. • Estrategia de TI.

5.1.8 Salidas

• Modelo organizacional de la UTPL para la EA. • Framework arquitectónico a medida. • Repositorio inicial de la arquitectura. • Reformulación de, o referencia a los principios, objetivos y los conductores de negocio. • Solicitud de trabajo arquitectónico. • Framework de gobernanza.


ORIENTADO A LA UTPL


5.1.9 Definición del proceso de la fase preliminar Definición de Procesos

Proceso: FP – FasePreliminar: Definición de esquemas y aspectos iniciales. Cod.Doc FP –

FasePreliminarX Responsable: DTE, ADS, ADD Versión: 1.0

Mantenimiento: DGTI, ADS. Estado: Borrador Publicado X

Descripción: Es el proceso de la fase preliminar que sirve para saber cómo se realizará la arquitectura: frameworks, herramientas y principios arquitectónicos, etc. que se utilizarán.

Alcance: El proceso de la fase preliminar, contempla los siguientes procedimientos:

• Definir a la organización en términos de unidades afectadas. • Identificar conductores y elementos clave en el contexto institucional. • Definir requisitos inicales para el establecimiento del proyecto EA-UTPL. • Establecer el equipo EA-UTPL. • Definir los principios arquitectónicos. • Definir frameworks y herramientas a utilizarse.

Guías de Personalización:

No aplica

Documentos de Referencia:

Los siguientes documentos han sido referenciados en la elaboración de este proceso: NA

Abreviaciones y Acrónimos:

En este documento se usan las siguientes abreviaciones y acrónimos: • ADS: Arquitectos de soluciones • ADD : Arquitectos de dominio • DTE: Director de tecnologías emergentes • DGTI: Director de gobernanza de TI.

Listado de Cambios

Versión Fecha Autor Número (F)igura, (T)abla, o (P)àrrafo

Acción (M)odificar (E)liminar (A)ñadir

Descripción

1.0 26/10/2010 ADS, ADD, DTE Todo A Emisión Inicial

A. Resumen del Proceso Criterios de Entrada:

Criterios de Salida:

• Delimitar los factores que inciden en la fase preliminar.

• Informar de las variaciones y cambios que se producen para cada artefacto en la fase preliminar en base a los artefactos tratados como entradas.

Entradas:

Salidas:

• Modelos pre-existentes • Modelo organizacional.

• Modelo organizacional para la EA. • Esquema inicial de framework de


ORIENTADO A LA UTPL


• Principios arquitectónicos (implícitos). • Presupuesto de proyecto. • Acuerdos contractuales. • Frameworks de portafolios/proyectos que

operan en la institución. • Estrategias y planes de negocio. • Conductores de negocio. • Políticas y marcos jurídicos, estrategia de la

arquitectura de la gobernanza.

Arquitectura a medida. • Reformulación de, o referencia a los

objetivos y los conductores de negocio. • Solicitud de trabajo arquitectónico. • Esquema inicial de framework de

gobernanza.

Roles:

• ADS: Brindar una línea base de la EA. • ADD: Delimitar dominio. • Director de la EA: Integrar resultados. • DGTI: Dar soporte al proceso.

Activos/Referencias:

• Modelo organizacional de la UTPL. • Plan de planteamiento de proyecto. • Informes de rendimiento • Estrategias, planes de negocio, políticas y marco jurídico.

Tareas: 1. Definir el ámbito de aplicación para las unidades de negocio afectadas dentro de la UTPL. 2. Identificar esquema de gobernanza y frameworks de gestión de la institución. 3. Identificar las arquitecturas existentes y el equipo de trabajo. 4. Identificar y establecer los principios de la arquitectura (actual). 5. Seleccionar la arquitectura y adaptar a medida el framework. 6. Aplicar las herramientas arquitectónicas.

Métricas:

• Actual rendimiento y capacidad institucional para emprender la EA. B. Definición Detallada del Proceso

Definición de esquemas y aspectos iniciales. Objetivos del Procedimiento:

• Revisar el contexto de la institución para llevar a cabo el ejercicio de arquitectura empresarial.

• Identificar los stakeholders principales y secundarios que serán afectados por la directiva de crear una EA, así como determinar las necesidades, y prioridades de la institución.

• Asegurarse de que todos los involucrados que participarán en el proceso EA-UTPL se ha comprometido con éxito.

• Permitir al patrocinador de la arquitectura crear los requisitos para trabajar a través de las áreas de negocio afectadas en la institución.

• Identificar los elementos y el alcance de institución, así como definir las limitaciones y supuestos (mucho más en este caso por tratarse de una arquitectura federada).

• Confirmar un marco de gobernanza y de apoyo que proporcionen procesos de negocio y recursos para la gobernanza de la


ORIENTADO A LA UTPL


arquitectura. • Seleccionar y aplicar herramientas de apoyo y otras infraestructuras

destinadas a apoyar la actividad arquitectónica.

• Definir los principios arquitectónicos que formarán parte de las restricciones y políticas de cualquier trabajo arquitectónico.

Roles y Responsabilidades:

Los roles y responsabilidades asociados a este procedimiento se listan a continuación:

• ADS: Especificar una visión general de la EA (línea base), dar mantenimiento al proceso.

• ADD: Delimitar dominio, las unidades de negocio afectadas por la EA.

• Director de la EA: Integrar resultados. • DGTI: Guiar a los demás involucrados a consolidar los principios

arquitectónicos y demás aspectos de esta fase. Dar mantenimiento al proceso.

Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a continuación: a. Establecer los factores que afectan la fase preliminar. b. Controlar los cambios en los artefactos de la fase preliminar.

Entradas: • Modelos pre-existentes pueden ser usados como línea base para poner en marcha el proyecto EA.

• Modelo organizacional de la UTPL. • Framework de arquitectura existente, si existe. • Principios arquitectónicos existentes. • Repositorio de arquitectura existente, si existe. • Estrategias, planes, estrategias, principios, objetivos y los

conductores de negocio. • Frameworks principales que operan en la institución para la gestión

de portafolios/proyectos. • Políticas y marcos jurídicos, incluida la estrategia de gobernanza de

la arquitectura. • Presupuesto para los alcances de proyectos. • Colaboración y acuerdos contractuales. • Estrategia de TI actual.

Pasos y Actividades del Procedimiento:

1. Definir el ámbito de aplicación para las unidades de negocio afectadas.

• Identificar principales unidades de negocio: aquellas que son las más afectadas y lograr dar con eso mayor valor al trabajo arquitectónico.

• Identificar las unidades de negocio no estratégicas: aquellas que se vean en el cambio a su capacidad y que trabajen con las unidades estratégicas (core), pero son de otra manera indirectamente afectadas.

• Identificar unidades de negocio extendidas: las unidades que están fuera del ámbito de la arquitectura planteada y que verán afectadas su propia arquitectura.


ORIENTADO A LA UTPL


• Identificar las comunidades involucradas: los stakeholders que se verán afectados y que están en los grupos de las comunidades.

• Identificar la gobernanza involucrada: incluidos los marcos jurídicos, regulaciones y geografías.

2. Confirmar la gobernanza y frameworks de gestión.

• Tener en cuenta que el framework arquitectónico es la base para la estructura de gobernanza arquitectónica y brinda las directrices que deben ser desarrolladas.

• Analizar cómo el material arquitectónico es procesado bajo la gobernanza, si existiese una gobernanza formal.

• Revisar los actuales modelos de gobernanza y apoyo a la UTPL, así como la forma en que estos tendrán que cambiar para apoyar el framework arquitectónico.

• Evaluar, comprender y aceptar los puntos de contacto de la arquitectura y sus posibles impactos.

3. Definir y establecer la arquitectura, así como el equipo.

• Determinar los activos humanos existentes en la institución y la capacidad de negocio.

• Llevar a cabo una evaluación de madurez del cambio para la sección de arquitectura/negocios de la institución.

• Identificar brechas en las áreas de trabajo existentes. • Asignar funciones clave y responsabilidades para la gestión de la

capacidad de la EA y de la gobernanza. • Definir las solicitudes de modificación de programas de negocios y

proyectos existentes. • Definir el ámbito del nuevo trabajo arquitectónico propuesto a seguir. • Determinar las restricciones sobre el trabajo arquitectónico. • Revisar y acordar con los patrocinadores. • Evaluar las necesidades presupuestarias.

4. Identificar y establecer los principios arquitectónicos.

• Considerar que los principios arquitectónicos se basan en principios de negocio y son fundamentales en el establecimiento de las bases para la gobernanza de arquitectura.

• Establecer normas y directrices generales que vayan a ser duraderas y rara vez modificadas, que informen y apoyen la manera en que la institución se propone a cumplir con su misión.

• Considerar la necesidad de definir un conjunto de principios arquitectónicos que se adecuen a la institución en aspectos de negocio, datos, aplicaciones y tecnología.

5. Seleccionar la arquitectura y adaptar a medida el framework


ORIENTADO A LA UTPL

EA – UTPL - 100 - | P á g i n a

• Determinar si de alguna manera se requiere una adaptación. La adaptación debe producir un conjunto acordado la terminología para la descripción del contenido arquitectónico.

• Adaptar procesos implica: o Eliminar las tareas que ya se llevaron a cabo en otras

partes de la institución. o Añadir las tareas específicas de la institución tales como

puntos de control específicos. o Alinear los procesos a los frameworks de proceso externos

y puntos de contacto claves. • Adaptar la estructura y clasificación de contenidos, permite la

adopción de los frameworks de contenidos de terceros, así como la personalización del framework para soportar los requerimientos de específicos de la institución.

6. Aplicar herramientas arquitectónicas.

• El enfoque de herramientas puede basarse en la norma de aplicación de productividad de oficina, o también puede estar sustentado en una implementación personalizada de herramientas arquitectónicas especializadas.

• Dependiendo del nivel de sofisticación, la implementación de herramientas puede ser desde una tarea trivial a una actividad de implementación de soluciones complejas.

• El capítulo 3 de la presente investigación incluye un análisis de herramientas basado en un esquema de contrastación que puede brindar un aporte significativo a este proceso.

Salidas: Las salidas para este procedimiento se listan a continuación:

• Modelo organizacional para la EA. • Esquema inicial de framework de arquitectura a medida. • Reformulación de los objetivos y los conductores de negocio. • Solicitud de trabajo arquitectónico. • Esquema inicial de framework de gobernanza.

Criterios de Salida: Los criterios de salida para este procedimiento se listan a continuación: a. Informar de las variaciones y cambios que se producen los artefactos de

esta fase, durante el desarrollo de la arquitectura. b. Informar los factores que afectan a la fase preliminar. c. Definir el “por qué” de dichos factores y definir soluciones.

Métricas del Proceso: Las métricas que deben recopilarse en este procedimiento incluyen:

• Rendimiento con respecto a la puesta en marcha del proyecto. • Capacidad institucional para emprender la EA.


ORIENTADO A LA UTPL

EA – UTPL - 101 - | P á g i n a

5.1.10 Plantillas para la fase preliminar

5.1.10.1 Plantilla para levantamiento de: Modelo Organizacional de la UTPL

Modelo Organizacional para Arquitectura Empresarial

Definición de un Framework de Arquitectura Empresarial EA – UTPL

___________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito 2 Alcance del documento 3 Valoración de Madurez, Brechas, y Resolución de Enfoque 4 Roles y responsabilidades 5 Restricciones 6 Requisitos de presupuesto 7 Gobernanza y Estrategia de Apoyo Información del documento Nombre del Proyecto:

Definición de un Framework de Arquitectura Empresarial para la UTPL

Preparado por: Número de Versión: 0.1 Título: Modelo Organizacional para la

Arquitectura Empresarial Fecha de Versión:

Revisado por: Fecha de Revisión: Lista de distribución De Fecha Teléfono/Fax/Email


ORIENTADO A LA UTPL

EA – UTPL - 102 - | P á g i n a

* Tipos de Acción: Aprobado, Revisión, Informe, Archivo, Acción Requerida, Asistir a Reunión, Otro (por favor especificar) Historial de revisión del documento

Nro. de Versión

Fecha de Versión

Revisado por Descripción Nombre de Archivo

1 Propósito de éste documento

Este documento describe el contexto de organizacional a nivel de capa de negocio con el objetivo de aportar a la definición de un framework de EA a ser usado satisfactoriamente, y que deberá ser apoyado por la UTPL, así como los roles y responsabilidades dentro de la misma. De particular importancia es la definición de límites entre las diferentes particiones de la EA y las relaciones de gobernanza que se abarcan a través de este límite.

2 Alcance de la UTPL Se debe delimitar el alcance del proyecto de implementación de EA en la UTPL en términos organizacionales delimitando hasta dónde se quiere extender (hasta dónde se quiere llegar) el enfoque EA dentro de la misma.

3 Valoración de madurez, brechas, y resolución de enfoque Para levantar esta sección se debe utilizar los conceptos y recomendaciones planteados antes de la definición del proceso (ver desde 5.1.2 hasta 5.1.6) en este capítulo. 3.1 Valoración de madurez Permitirá establecer un nivel de madurez para medir la capacidad de gestión del cambio de la UTPL. Los criterios para la evaluación de la misma se encuentran en las tablas 14 y 15, en la parte 5.1.3.4 de este capítulo. 3.2 Brechas Consiste en identificar los desafíos que existen actualmente en la TI actual de la UTPL y que obstaculizan la capacidad de la universidad para cumplir su plan estratégico de negocios. Mayor información disponible en la parte 5.1.6 de este capítulo. Un ejemplo de cómo elaborar una matriz de brechas se sugiere seguir secuencialmente los pasos y el esquema siguientes:

• Elaborar una matriz con todos los bloques constitutivos arquitectónicos (ABBs, por sus siglas en inglés)

de la línea base arquitectónica en el eje vertical (Y), y todos los ABBs de la arquitectura objetivo en el eje horizontal (X).

• Añadir al eje de la línea base arquitectónica una última fila con la etiqueta "nuevo", y al eje de la

Para Acción* Fecha de vencimiento

Teléfono/Fax/Email


ORIENTADO A LA UTPL

EA – UTPL - 103 - | P á g i n a

arquitectura objetivo añadirle al final una columna denominada "eliminado". • Cuando un ABB esté disponible en la línea base y arquitectura objetivo, se deberá registrar ello con la

etiqueta de "incluido" en la celda de intersección de ambas. • Cuando un ABB de la línea base no se encuentre en la arquitectura objetivo, cada uno debe ser

revisado. Si se elimina correctamente, deberá marcarse como tal en la celda "eliminado". Si no lo fuera, una omisión accidental en la arquitectura objetivo se ha descubierto, para que deberá ser abordada por el restablecimiento de la ABB en la siguiente iteración del diseño de la arquitectura.

• Cuando un ABB de la arquitectura de destino no se puede encontrar en la línea base, se deberá marcar en la intersección con la etiqueta "nuevo" como una brecha que debe cubrirse, ya sea mediante el desarrollo o la adquisición del bloque constitutivo correspondiente. El siguiente esquema da un ejemplo claro de de análisis de brechas orientado a un segmento de la arquitectura de TI de Red de la UTPL.

ARQ. OBJETIVO LINEA BASE

Servicios de videoconferencias

Servicios de telefonía

mejorados

Lista de servicios de

correo

Servicios eliminados

(ELIMINADO)

Servicios de radiodifusión con restricciones en WI-FI

Intencionalmente eliminado

Servicios de videoconferencias Incluido

Servicios de telefonía mejorados Coincidencia

potencial

Servicios de VoIP con restricciones de protocolos de video.

Excluidos desintecionadamente,

esto es una brecha en la Arquitectura

objetivo. Nuevos (NUEVO)

Brecha: Servicios mejorados a ser desarrollados o

producidos.

Brecha: A ser

desarrollada o producida.

3.3 Establecimiento de visión arquitectónica Se debe formalizar el enfoque que tiene la arquitectura actual (la arquitectura informal EA que se lleva) y definir el enfoque que se busca para la EA objetivo. Es decir, en esta sección se deben definir tanto los enfoques línea base así como una breve especificación del enfoque de la arquitectura objetivo. 4 Roles y responsabilidades Se debe delimitar el grupo de trabajo, esto servirá para poder asignar responsabilidades a cada uno de los roles. Un esquema de cómo realizar la asignación de roles y responsabilidades está descrito en la sección 5.1.4 de este capítulo. 4.1 Roles y responsabilidades (RACI) Identifique roles y responsabilidades mediante una tabla RACI Donde sea relevante, agregue una tabla RACI– mostrando claves y actividades a los stakeholders de EA-UTPL, además de quién es el (R) responsable, (A) Contable, (C) Consultado e (Informado en cada caso).


ORIENTADO A LA UTPL

EA – UTPL - 104 - | P á g i n a

Una tabla de asignación de responsabilidades (RACI) relaciona actividades con recursos (individuos o equipos) de trabajo. Con ello se asegura que cada uno de los componentes del alcance esté asignado a un individuo o a un equipo. En el siguiente ejemplo podemos ver la estructura de una matriz RACI adaptable a cualquier segmento del proyecto EA-UTPL:

Rol Descripción

R Responsable Este rol realiza el trabajo y es responsable por su realización. Lo más habitual es que exista sólo un R, si existe más de uno, entonces el trabajo debería ser subdividido a un nivel más bajo, usando para ello las matrices RASCI. Es quien debe ejecutar las tareas.

A Aprobador Este rol se encarga de aprobar el trabajo finalizado y a partir de ese momento, se vuelve responsable por él. Sólo puede existir un A por cada tarea. Es quien debe asegurar que se ejecutan las tareas.

C Consultado Este rol posee alguna información o capacidad necesaria para terminar el trabajo. Se le informa y se le consulta información (comunicación bidireccional).

I Informado Este rol debe ser informado sobre el progreso y los resultados del trabajo. A diferencia del Consultado, la comunicación es unidireccional.

S Soporte Utilizado en la matriz RACI para la validación de la tabla RACI. Este rol proporciona recursos adicionales para realizar el trabajo.

Un ejemplo sencillo de una matriz RACI adaptado a la UPSI por ejemplo podría ser:

Actividad / Recurso Armando Carlos Elizabeth Mariana

Investigación R I I A

Planificación C A R I

Desarrollo A R

Verificación de Errores I R A

5 Restricciones (constraints) Son varios tipos de limitantes que podrían darse para lograr consolidar el establecimiento del contexto organizacional. 5.1 Restricciones organizacionales Son tipos de valor que requieren ceñirse estrictamente a los lineamientos organizacionales para asegurar el buen funcionamiento de la UTPL. Por ejemplo, el “Cumplimiento” es el tipo de valor central usual.


ORIENTADO A LA UTPL

EA – UTPL - 105 - | P á g i n a

5.2 Información presupuestaria y restricciones financieras El financiamiento debería ser considerado en dos niveles:

1. A corto plazo: ¿Cuánto presupuesto está disponible para apoyar inmediatamente al equipo en la creación de los productos del trabajo arquitectónico? (puede ser en $ o en número de días). ¿De qué fuente éste presupuesto será provisto?

2. A largo plazo: ¿Qué nivel aproximado de recursos y presupuesto están disponibles para la implementación definitiva de la arquitectura que se propone?

Se debe tener en cuenta que en este estado (1) se debe abordar, mientras (2) se puede considerar/indicar donde sea posible. 5.3 Restricciones externas y del negocio Se debe establecer si existen otras restricciones; por ejemplo: ¿recursos a ser usados, dependencias externas, regulaciones específicas, etc.? 5.4 Tabla de Restricciones Formaliza en una matriz los tipos de restricciones descritas con anterioridad. Para ello se propone seguir el esquema siguiente: (los ejemplos son generales e hipotéticos)

ID Tipo Nombre Descripción

Severidad

Probabilidad

Mitigación

1. 001_UGTI

Organizacional

Aplicar a toda la UTPL los proyectos de TI

No se puede establecer proyectos de TI segmentados (solo UGTI) sino a toda la institución.

Grave Baja Proponer un plan piloto

2. 002_UGTI

Presupuestaria

Limitación de presupuesto para TI

Limitación de la UTPL para proyectos de TI a $ 20 000

Grave Alta

Obtener auspicio económico externo

3. 003_UGTI

Externa Restricciones gubernamentales

Nuevas leyes que modifiquen el ambiente TI

Grave Baja

Tener una plan de contingencia para una adaptación progresiva

6 Plan presupuestario Es vital para el conocimiento de la alta gerencia (Administración de la EA). En él se deben identificar los recursos humanos, fiscales, físicos, infraestructura, equipo, y demás insumos necesarios para cumplir con los objetivos propuestos en EA-UTPL. Este plan constituye la petición y asignación presupuestaria periódica de cada unidad, por el tiempo establecido del plan. Para levantar esta sección se debe utilizar las recomendaciones dadas en este capítulo. 7 Gobernanza y estrategia de apoyo


ORIENTADO A LA UTPL

EA – UTPL - 106 - | P á g i n a

Delimitar el esquema de gobernanza que se maneja actualmente en la UTPL, describiendo los aspectos críticos del modelo adoptado. Para especificar esta sección se puede tomar como referencia el flujo de proceso dado por el capítulo 5.8 (de gobernanza) así como el anexo 1.1 (Plantilla de levantamiento de arquitectura de TI para EA-UTPL) en la que se hace referencia a COBIT e ITIL a breves rasgos. 7.1 Estructura de gobernanza Definir esquema de gobernanza formal o informal llevado por la UTPL a nivel de TI. El equipo EA deberá especificar el esquema estructural de gobernanza manejado en la UTPL, para ello es necesario especificar el enfoque formal que se maneja, en este caso se debe describir el enfoque híbrido (o informal) que se utiliza. 7.2 Estrategia de apoyo El proyecto de adopción arquitectónica si bien cuenta con un orden cronológico, secuencial y bien estructurado, debe estar amparado por una estrategia de apoyo, en esta sección se debe delimitar los flujos de trabajo alternativos y las medidas pertinentes que garanticen la integridad de EA-UTPL.


ORIENTADO A LA UTPL

EA – UTPL - 107 - | P á g i n a

5.1.10.2 Plantilla para levantamiento de: Principios, Objetivos y Conductores del Negocio

Principios, Objetivos y Conductores del Negocio

Definición de un Framework de Arquitectura Empresarial EA - UTPL

__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito del Documento 2 Principios del Negocio 3 Objetivos del Negocio 4 Conductores del Negocio Información del documento Nombre del Proyecto:


Preparado por:

Número de Versión: 0.1

Título: Principios del Negocio, Objetivos y Manejadores

Fecha de Versión:

Revisado por:

Fecha de Revisión:

Lista de distribución De Fecha Teléfono/Fax/Email

Para Acción* Fecha de

Vencimiento Teléfono/Fax/Email


ORIENTADO A LA UTPL

EA – UTPL - 108 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito del documento Este documento describe los principios, objetivos y conductores del negocio. Los principios del negocio, los objetivos del negocio y los conductores del mismo proveen un contexto para el trabajo arquitectónico, por el que se describen las necesidades y vías para el trabajo empleado por la UTPL. Muchos factores recaen fuera de la consideración de una arquitectura ordenada, puede sin embargo tener implicaciones significativas para el camino de la arquitectura que es desarrollada. El contenido y estructura del contexto de negocio para la arquitectura es probable que varíe considerablemente de una organización a otra. Se debe tener claro el contexto de educación superior para este caso particular. 2 Principios de negocio 2.1 Principios Cada principio arquitectónico de negocio (EA-UTPL_PN) debe especificarse tomando como referencia el esquema planteado a continuación:

Nombre <Nombre> Referencia <Identificador único> (EA-UTPL_PN00) Declaración La declaración debe comunicar de manera sucinta y sin ambigüedades la norma

fundamental. En su mayor parte, las declaraciones de principios para la gestión de la información son similares a los de la UTPL. Es vital que la declaración no tenga ambigüedad en los principios.

Justificación La justificación debe resaltar los beneficios comerciales de la adhesión al principio, utilizando la terminología de negocios. Debe apuntar a la similitud de los principios de información y tecnología y a los principios que rigen las operaciones de negocios. También describen la relación con otros principios, y las intenciones con respecto a una interpretación equilibrada. Describen las situaciones en que sería un principio podría dar precedencia o tener más peso que otro para tomar una decisión.

Implicaciones Las implicaciones deben destacar los requisitos, tanto para el negocio y TI, para llevar a cabo el principio - en términos de recursos, costos, y las actividades o tareas. A menudo, será evidente que los actuales sistemas, normas o prácticas sean incongruentes con el principio después de su aprobación. El impacto para el negocio y las consecuencias de la adopción de un principio debe ser indicado. Se debe discernir fácilmente la respuesta a: "¿Cómo me afecta esto?” es importante no simplificar en exceso, trivializar o juzgar el valor del impacto. Algunas de las consecuencias serán identificadas como posibles efectos meramente informativos y pueden ser especulativas en lugar de hacer un análisis exhaustivo.


ORIENTADO A LA UTPL

EA – UTPL - 109 - | P á g i n a

Mandato / Aviso Razón de revisión del principio Fecha de revisión <Refleja si el principio es obligatorio regulatorio.>

<Circunstancias bajo las cuales el principio debería ser revisado para asegurar su validación.>

<última fecha de revisión

Nombre <Nombre del principio> Referencia Declaración Justificación Implicaciones

2.2 Metas de negocio Provee una vista ligera del contexto de negocio (educación superior), enfocado en describir oportunidades clave de negocio o metas a ser alcanzadas por la UTPL. Se requiere considerar los tópicos: • Declaración de la misión de la institución. • Metas de negocio (y sus cambios). • Planes estratégicos del negocio.

2.3 Declaración de misión de la organización Cada ítem de la misión de la UTPL debe especificarse tomando como referencia el esquema planteado a continuación:

Nombre de vista Declaración de misión Stakeholder Patrocinador Expectativa ¿La arquitectura reconoce claramente la misión de negocio? ¿Está la arquitectura

alineada con la misión de negocio de la UTPL? Descripción La misión de negocio describe la justificación de la existencia de una oportunidad negocio

así como el reto que enfrenta la UTPL en el logro de sus objetivos en términos de: la cultura, la posición en el mercado, las capacidades y el crecimiento. La misión refleja los objetivos deseados de toda la institución, su comportamiento, y lo que es importante. Su objetivo es generar su inspiración y la aspiración dentro de la institución. Si bien una declaración de misión debe existir para la UTPL en general, es posible que las distintas unidades de negocio (CITTES y otras áreas) puedan crear sus propias adaptaciones de la misión que ayudan a identificar su contribución al objetivo global. La mayoría de las declaraciones de misión se expresan como una breve descripción de la meta seguido por una serie de declaraciones que describen la manera en que el objetivo se debe conseguir, por ejemplo: "Mejorar la vida de las personas mediante la creación de la elección." Algunos estatutos se limitan a dar el objetivo, por ejemplo: "No seas malvado". Un ejemplo de declaración de misión es: "Establecer la norma para ayudar a nuestros clientes a administrar su futuro financiero."

Orientación Si las declaraciones de misión pertinentes ya existentes, lo que debe ser cierto para la mayoría de los proyectos, a continuación, esta vista debe ser una simple selección de eso. Si no, los siguientes puntos clave deben ser considerados. En una deconstrucción de una misión de negocio de alto nivel -para formular una


ORIENTADO A LA UTPL

EA – UTPL - 110 - | P á g i n a

declaración de objetivos adecuados a un proyecto o unidad de negocio- hay varios puntos clave, debe darse en base a las interrogantes: • ¿La declaración de misión se alinea totalmente con la misión de negocio de alto nivel? • ¿Los objetivos definidos caben dentro de la jerarquía de los objetivos de la UTPL? Si no, ¿tiene la institución esperar que el proyecto cambie su dirección y la jerarquía de objetivos? • ¿La declaración en el ámbito operativo de la unidad de negocio o proyecto es clara? • ¿Está la declaración formulada dada de forma inequívoca? • ¿Están todos de acuerdo en la definición? • ¿Pueden los principios y las limitaciones que la arquitectura, proyecto o unidad de negocio deban trabajar bajo una estricta relación con la declaración de misión? Cuando una misión de negocio de alto nivel se deconstruye para formular una declaración de objetivos apropiados, para una unidad de negocio, se debe considerar también si la declaración de misión está totalmente alineada con la misión de negocio de más alto nivel.

ID-Referencia Título Declaración de la misión del negocio

2.4 Tabla de metas de negocio (y sus cambios) Cada meta de negocio de la UTPL debe ser puntal especificándose tomando como referencia el esquema planteado a continuación:

ID-Referencia Título Meta de negocio

2.5 Planes estratégicos del negocio Cada estrategia de negocio de la UTPL debe especificarse tomando como referencia el esquema planteado a continuación:

Nombre de vista Estrategia de Negocio Stakeholder Patrocinador Expectativa ¿La estrategia de negocios a los que la arquitectura está alineada, coincide con mis

expectativas?


ORIENTADO A LA UTPL

EA – UTPL - 111 - | P á g i n a

Descripción Especifica cómo la UTPL quiere lograr una visión de negocio en un plazo determinado, y en cierta medida la forma en que se puede lograr. Se trata de un subconjunto concreto de la visión general de la UTPL y los objetivos, con ello da una idea de cuál es el alcance previsible de la arquitectura. La estrategia es el "qué y cómo", vista como traducción de la visión de negocio o de la misión, describiendo cómo la visión del negocio se puede alcanzar. Las estrategias de negocio se refieren a la identificación de las declaraciones que figuran la dirección, los medios y acciones clave para lograr un subconjunto de los objetivos de la organización. La estrategia global de negocio suele ser muy importante tanto para los objetivos a largo y corto plazo para la arquitectura. Una unidad de negocio específica o estratégica es a veces el factor clave para un proyecto. En este caso se trata de una función arquitectónica para garantizar que el proyecto EA se ejecute en una manera que apoye la estrategia global del negocio.

Orientación La estrategia de negocio tiene que ser inteligente y formulada en términos de los resultados que se quieren lograr. Se pueden definir importantes objetivos estratégicos: Áreas de Resultados Clave (KRAs, por sus siglas en inglés). Los objetivos de la UTPL deben estar relacionados con las ARC en el plan de actuación para hacer transparente lo que brindan los beneficios tangibles de un objetivo, como por ejemplo el valor agregado, capacidad de respuesta, la eficacia, etc. Una estructura ARC también se puede aplicar en un esbozo de solución, como parte de la justificación de un proyecto.

ID_Referencia Título Declaración de estrategia de negocio

3 Conductores del negocio Cada conductor de negocio para la UTPL debe especificarse tomando como referencia el esquema planteado a continuación:

Nombre de vista

Conductores del negocio

Conductor Patrocinador Expectativa ¿Los conductores del negocio a los que la arquitectura está alineada, coinciden con mis

expectativas? Descripción Los impactos de las tendencias del entorno en la UTPL se describen como conductores

del negocio. Representan la comprensión del negocio de la forma en que este tiene que cambiar en respuesta a los cambios y tendencias en el ambiente. Los conductores del negocio llevan a la creación de estrategias de negocio, y dan forma a los principios de la arquitectura. La visión de negocio es la estimación de donde un conjunto de cambios se esperan, y cómo las tendencias en el entorno y las respuestas a ellos establecerán la posición de la UTPL en algún momento futuro. La visión de negocio puede ser cristalizada por los conductores del negocio, por lo que la organización está controlado por ellos. Un ejemplo de un cambio del ambiente de negocios la creación de los conductores: "Una nueva aerolínea de bajo costo entra en el mercado vigente, las compañías de alto costo tendrán que cambiar sus estrategias de negocio en el nuevo entorno operativo."


ORIENTADO A LA UTPL

EA – UTPL - 112 - | P á g i n a

Orientación Para ser capaz de encontrar todos los conductores de negocio relevantes para el proyecto EA-UTPL, la siguiente lista puede ayudar: • Entorno competitivo - por ejemplo, la aparición de competidores de gran alcance con diferentes modelos de negocio (otras instituciones de educación superior). • Entorno regulatorio - por ejemplo, el impacto de las regulaciones legislativas con respecto a la educación superior en el Ecuador. • Propiedad medio ambiente - por ejemplo, la aparición de firmas de capital privado, dando lugar a diferentes expectativas de rentabilidad. • Entorno de la demanda - por ejemplo, crecimiento, alta en la aceptación y el uso de canales electrónicos, entre muchos segmentos de clientes. • Suministro para el Medio Ambiente - por ejemplo, M & A en la base de suministro, lo que lleva a un cambio en el poder de negociación. • Entorno de Recursos - por ejemplo, una mayor disponibilidad y capacidad de los centros en determinados lugares del planeta. Los atributos de los propios conductores se describen dentro de la plantilla artefacto apropiado.

ID-Referencia Título Conductor de negocio


ORIENTADO A LA UTPL

EA – UTPL - 113 - | P á g i n a

5.1.10.3 Plantilla para levantamiento de: Principios Arquitectónicos

Principios Arquitectónicos


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito del Documento 2 Plantilla de Principios 3 Resumen de principios 4 Principios (de Negocio, Datos, Aplicaciones, tecnología) Información del documento

Nombre del Proyecto:


Preparado por:


Título: Principios Arquitectónicos Fecha de Versión: Revisado por:

Fecha de Revisión:



vencimiento Teléfono/Fax/Email

* Tipos de Acción: Aprobado, Revisión, Informe, Archivo, Acción Requerida, Asistir a Reunión, Otro (por favor especificar)


ORIENTADO A LA UTPL

EA – UTPL - 114 - | P á g i n a

Historial de revisión del documento

Nro. de Versión

Fecha de Versión


1 Propósito Este documento detalla los Principios Arquitectónicos a los que la UTPL se adhiere. El propósito de éste documento es definir los Principios Arquitectónico para el domino/sub-dominio relevantes. Nota 1: Un principio define las reglas duraderas que gobiernan la arquitectura de un sistema deseado, por ejemplo, la arquitectura objetivo. Este es obligatorio para los principios a ser considerados cuando se diseña arquitecturas. Nota 2: Un equipo de domino EA-UTPL puede desear la creación de un documento de principios para el dominio EA-UTPL, o múltiples comentos de principios –uno por sub-dominio EA-UTPL. Esta sección deberá abarcar el número de documentos de principios que existan en el dominio EA-UTPL. Nota 3: Si este documento contiene todos los principios para el dominio EA-UTPL, la Sección 3 (Principios Arquitectónicos) puede ser dividida en un número de sección, una por cada sub-dominio de EA-UTPL, con cada encabezado de sección incluyendo el nombre de sub-dominio EA-UTPL en su título. Nota 4: Este ejercicio únicamente define la estructura del contenido y plantillas entregables para la Arquitectura de Referencia. No define ninguna gobernanza o aspectos RACI de esos entregables, ningún estado cómo y cuándo estos entregables deben ser completados para esta decisión será necesario haber tomado la Función Arquitectónica FA-N que incluye un equipo específico de dominio EA-UTPL. Nota 5: Esta plantilla entregable está basada en las mejores prácticas de una arquitectura empresarial genérica TOGAF, y el formato de la actual documentación arquitectónica dentro de EA-UTPL. El propósito de esta sección es proveer y soportar el fondo y contexto para éste documento. Obligatoria/Opcional: Esta sección es Obligatoria Esta sección aclarará:

a. Domino/sub-dominio EA-UTPL para cada documento de principios arquitectónicos que sea producido. b. Eventos previos y base/fondo/contexto para este documento. c. Propósito de los principios arquitectónicos y sus documentos. d. Alcance de éste documento con límites claros y principios arquitectónicos, ambos dentro del alcance. e. Stakeholders para los principios arquitectónicos y este documento. f. Límite del conjunto de principios arquitectónicos.

2 Principios Los principios son generalmente reglas y directrices, destinados a ser duraderos y rara vez modificados, esto provee una vía de información y soporte en la cual la UTPL fija el cumplimiento de su misión. A su vez, los principios pueden ser sólo un elemento en un conjunto estructurado de ideas que colectivamente definen y guían la organización hacia el cumplimiento de su misión. Puede ser que los Principios Arquitectónicos sean documentados usando una wiki o algo como una intranet o más bien un documento basado en texto. Cada principio seguirá la plantilla siguiente. El nombre deberá representar la esencia y las reglas tan bien que sea sencillo recordar. La especificación de plataformas tecnologías no deberá ser mencionada en el Nombre o Declaración de un principio. Evitando palabras ambiguas en el nombre o declaraciones como: “apoyo”, “abierto”, “considerar” y la palabra “evitar”. Sea cuidadoso con “administrar (administración)”, y busque adjetivos


ORIENTADO A LA UTPL

EA – UTPL - 115 - | P á g i n a

innecesarios y adverbios.

Nombre <Nombre del Principio> Referencia <Identificador único del principio> Declaración La declaración deberá establecerse brevemente y sin ambigüedad comunicar las reglas

fundamentales. Para la mayor parte, la declaración de principios para administración de información es similar entre instituciones. Es vital que la declaración de principios no sea ambigua.

Justificación La Justificación deberá destacar los beneficios del negocio para adherirlos a los principios, usando terminología del negocio. Apuntando a la similitudes de los principios de información y tecnología, y las intenciones con respecto a interpretaciones balanceadas. Describir situaciones donde un principio podría estar dando precedencia o acarreando más ancho que cualquier otra toma de decisiones.

Implicaciones Las Implicaciones deberán destacar los requerimientos, tanto para el negocio como para la TI, para llevar a cabo el principio—en términos de recursos, costo y actividades/tareas. Éste a menudo puede aparentar ser el sistema actual, estándares o prácticas que pueden ser incongruentes con el principio que será adoptado. El impacto al negocio y las consecuencias de la adopción de un principio pueden ser claramente fijados. Se podrá inmediatamente discernir una respuesta al: ¿Cómo podría esto afectarme?” Es importante no sobre simplificar, trivializar o juzgar el mérito del impacto. Algunas de las implicaciones podrán ser identificadas como impactos potenciales solamente, y pueden ser mejor especulativas si son profundamente analizadas.

4 Resumen de principios El propósito de ésta sección es proveer una lista de los principios de alto nivel (en una lista o en tablas) que sean definidos en este documento. Obligatorio/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección deberá ser clara:

a. Descripciones de los principios de alto nivel en este documento

5 Principios de negocio

Nombre Principios Iniciales Referencia PN00 Declaración Estos principios de administración de información se aplican a todas las áreas dentro de la

UTPL. Justificación La única forma proveer un consistente y mesurable nivel de calidad de información para

quienes toman decisiones será si toda la organización acata estos principios. Implicación Si estos principios, exclusiones, favoritismos e inconsistencias se pueden rápidamente

minar, la administración de información es medible en niveles de calidad. Las iniciativas de administración de la información no empezarán hasta que hayan sido examinadas en conformidad con los principios. Un conflicto con un principio puede ser resuelto cambiando el framework de la iniciativa.


ORIENTADO A LA UTPL

EA – UTPL - 116 - | P á g i n a

Obligatorio/Asesor Razón Principal de Revisión Fecha de Revisión

<Refleja si el principio es obligatorio (ej.: regulatorio) o asesorado. >

<Circunstancias bajo las cuales el principio podrías ser revisado con el fin de asegurar su validez.>

<Última fecha de revisión>

Nombre <Nombre del Principio> Referencia PN00 Declaración Justificación Implicaciones

6 Principios de datos

Nombre <Nombre del Principio> Referencia PD00 Declaración Justificación Implicaciones

7 Principios de aplicaciones

Nombre <Nombre del Principio> Referencia PA00 Declaración Justificación Implicaciones

8 Principios tecnológicos

Nombre <Nombre del Principio> Referencia PT00 Declaración Justificación Implicaciones


ORIENTADO A LA UTPL

EA – UTPL - 117 - | P á g i n a

5.1.10.4 Plantilla para levantamiento de: Solicitud para trabajo arquitectónico

Solicitud para Trabajo Arquitectónico


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de éste documento 2 Solicitud para trabajo arquitectónico 3 Imperativos de Negocio 4 Restricciones Clave 5 Información Adicional Información del documento



Preparado por:


Título: Solicitud para Trabajo Arquitectónico Fecha de Versión: Revisado por:

Fecha de Revisión:






ORIENTADO A LA UTPL

EA – UTPL - 118 - | P á g i n a

Nro. de Versión

Fecha de Versión


1 Propósito Este documento especifica una solicitud para trabajo arquitectónico para el proyecto denominado: Definición de un Framework de Arquitectura Empresarial. EA – UTPL. La solicitud para trabajo arquitectónico es un documento que es enviado desde la parte patrocinadora hasta la arquitectura de la organización (UTPL) como disparador del inicio de un ciclo de desarrollo arquitectónico. La solicitud para trabajo arquitectónico puede ser creada como una salida de una Fase Preliminar, como resultado de la arquitectura aprobado los requerimientos cambian, o los términos de referencia para el trabajo arquitectónico originado del plan de migración. En general, toda la información en este documento puede ser de muy alto nivel. 2 Solicitud para trabajo arquitectónico Una solicitud para trabajo arquitectónico describe los imperativos del negocio detrás del trabajo arquitectónico, así se conduce a los requerimientos y métricas de rendimiento para el trabajo arquitectónico. Esto deberá ser lo suficientemente claro así como el trabajo inicial puede ser emprendido para el alcance de las salidas del negocio y los requerimientos de recursos, y definir el esquema de requerimientos de información y estrategias asociadas al trabajo arquitectónico que será hecho.

2.1 Resumen de la solicitud Se debe llenar con un breve párrafo de un resumen ejecutivo, resaltando la esencia de la solicitud para trabajo arquitectónico planteada. 2.2 Organizaciones auspiciantes Este trabajo arquitectónico es solicitado y auspiciado por: <<Nombre>> <<Posición>> <<Organización>> <<Email>> <<Tel>> 3 Imperativos del negocio Provee una breve perspectiva general del contexto de negocio (educación superior), con especial concentración en la descripción de las oportunidades claves del negocio o los aspectos a ser direccionados en beneficio de la UTPL. Los tópicos a considerar incluyen:


ORIENTADO A LA UTPL

EA – UTPL - 119 - | P á g i n a

• Declaraciones de Misión de la UTPL • Objetivos del negocio (y cambios) • Planes de estrategia del negocio • Cambios en el ambiente operativos • Esquema de las oportunidades específicas o aspectos subyacentes de la necesidad de una trabajo

arquitectónico

3.1 Declaraciones de misión de la organización Debido a que la misión es la razón de ser de la UTPL, el motivo por el cual existe, esta debe estar perfectamente delimitada. Incluye dentro de sí también la determinación de las funciones básicas que la institución va a desempeñar en un entorno determinado para conseguir tal misión. Esta sección debe recoger la información mencionada con el mayor detalle de claridad y especificidad. 3.2 Objetivos del negocio (y sus cambios) Cada objetivo establece un resultado que permite cerrar la distancia entre la situación actual y un estado futuro deseado, por lo que encajan perfecto para poder delimitar las expectativas institucionales con respecto al enfoque EA. Esta descripción servirá para pulir las concepciones conceptuales tanto de la Arquitectura base así como de la arquitectura objetivo. 3.3 Planes estratégicos del negocio Siendo planes administrativos y financieros orientados a proyectar el funcionamiento de un negocio, es de vital importancia tener un listado con los códigos de cada uno de los planes estratégicos de negocio (y una breve descripción de ellos). Por aspectos de confidencialidad dichos planes deben ser accesados por determinadas personas, por lo que no pueden ser de conocimiento de cualquier stakeholder o miembro del equipo EA. 3.4 Cambios en el ambiente del negocio Debido a la existencia de proyecciones estratégicas con plazos determinados, existe dentro de ellas una percepción formal de cómo es y cómo podría ser en el futuro el medio ambiente del negocio y los cambios que este pueda experimentar. Para poder estratificar bien el enfoque EA a ser planificado es necesario tener en cuenta la influencia actual y las variaciones futuras del medio ambiente con respecto a la UTPL. 3.5 Propósito del trabajo arquitectónico En esta sección se debe levantar un esquema del propósito del trabajo arquitectónico, resaltando su anticipada contribución a los aspectos que del negocio descritos anteriormente. Esta justificación es la base sobre la cual se levantarán los argumentos y especificaciones del trabajo arquitectónico. 3.6 Criterios de éxito Indica cómo se verá un “buen” resultado del trabajo arquitectónico. Esto debería ser considerado en dos niveles:

1. A corto plazo – los contenidos deseados y la usabilidad de los productos del trabajo arquitectónico 2. A largo plazo – Las eventualmente nuevas mejoras del negocio son el resultado de este trabajo

arquitectónico Tanto el cualitativo e ideal deben anotar las métricas de satisfacción cualitativa. 3.7 Escala de tiempo ¿Dónde son necesitados los resultados del trabajo arquitectónico? si hay plazo establecido, explicar significado.


ORIENTADO A LA UTPL

EA – UTPL - 120 - | P á g i n a

4 Restricciones clave Son varios tipos de limitantes que podrían darse para lograr consolidar establecer la declaración del trabajo arquitectónico. 4.1 Restricciones organizacionales Describe cuando las unidades de la organización/departamento/negocio son cubiertas por el trabajo y/o cualquier área específica es excluida. 4.2 Información de presupuesto y restricciones financieras El financiamiento debe ser considerado en dos niveles:

1. A corto plazo – ¿cuánto financiamiento está disponible para apoyar inmediatamente al equipo en la creación de los productos del trabajo arquitectónico? (Podrá ser en $ o en número de días). ¿De dónde este financiamiento será provisto?

2. A largo plazo – ¿qué nivel aproximadamente de recursos y financiamiento están disponible para la implementación final de cualquier propósito arquitectónico?

No te en ésta parte (1) DEBE ser direccionado, mientras que (2) puede ser considerado/indicado en la medida de lo posible. 4.3 Restricciones externas y de negocio ¿Existen otras restricciones, por ejemplo: los recursos a ser usados, dependencias externas, regulaciones específicas, etc.? 4.4 Tabla de Restricciones Formaliza en una matriz los tipos de restricciones descritas con anterioridad para el contexto de “Trabajo arquitectónico”. Para ello se propone seguir el esquema siguiente: (los ejemplos son generales e hipotéticos)

ID Tipo Nombre Descripción Severidad Probabilidad Mitigación

1. 001_UGTI Organizacional

Aplicar a toda la UTPL los proyectos de TI

No se puede establecer proyectos de TI segmentados (solo UGTI) sino a toda la institución.

Grave Baja Proponer un plan piloto

2. 002_UGTI Presupuestaria

Limitación de presupuesto para TI

Limitación de la UTPL para proyectos de TI a $ 20 000

Grave Alta

Obtener auspicio económico externo

3. 003_UGTI Externa Restricciones

gubernamentales

Nuevas leyes que modifiquen el ambiente TI

Grave Baja

Un plan de contingencia para una adaptación progresiva


ORIENTADO A LA UTPL

EA – UTPL - 121 - | P á g i n a

5 Información adicional Únicamente si es relevante, se debe proveer cualquier información adicional que pueda ser usada por el equipo de arquitectura. Por ejemplo: • Trabajos previos en ésta área • Documentos de estrategia de negocio • Descripciones del sistema o diagramas de Arquitectura/Negocio/TI actuales • Contactos Clave, etc.

Nota: Trate de hacer la Solicitud de Trabajo Arquitectónico muy breve, esto podría consistir en vínculos a documentos existentes. 5.1 Descripción del actual sistema del negocio Se debe especificar en términos generales como funciona la UTPL, haciendo énfasis en las metas de negocio perseguidas y cómo se busca llegar hacia ellas. 5.2 Descripción de arquitectura / TI actuales Se debe especificar cómo se gestionan las TI actualmente en la UTPL, no existe una arquitectura formal previa, por lo que de manera descriptiva esta sección abarca la especificación de cómo se manejan las TI en la UTPL, denotado a breves rasgos. 5.3 Descripción de la organización en desarrollo Se debe especificar brevemente como ha crecido hasta la actualidad la UTPL y de manera detallada los aspectos que incidirán directamente en su crecimiento (planes de expansión). 5.4 Descripción de los recursos disponibles para la organización en desarrollo Especifica como a través del conjunto de herramientas (recursos) se buscará el progresivo crecimiento de la UTPL.


ORIENTADO A LA UTPL

EA – UTPL - 122 - | P á g i n a

5.1.10.5 Plantilla para levantamiento de: Adaptación de la EA

Adaptación de la Arquitectura Empresarial


___________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de este documento 2 Método de Arquitectura a Medida 3 Contenido de la Arquitectura a Medida 4 Herramientas configuradas y desplegadas 5 Interfaces con Modelos de Gobernanza y Frameworks Información del documento



Preparado por:


Título: Framework Arquitectónico a Medida Fecha de Versión: Revisado por:

Fecha de Revisión:




* Tipos de Acción: Aprobado, Revisión, Informe, Archivo, Acción Requerida, Asistirá a Reunión, Otro (por favor especificar)


ORIENTADO A LA UTPL

EA – UTPL - 123 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito Este documento describe el Framework Arquitectónico a Medida. Primeramente, es necesario un modelo a medida para la integración de la institución. Este proceso incluirá integración con los frameworks de administración de procesos y del proyecto, la terminología de personalización, desarrollo de estilos de presentación, configuración e implementación que se alineen con otros factores contextuales de la UTPL, como cultura, los interesados, modelos comerciales para EA, y los niveles existentes de capacidad arquitectónica. Una vez que el framework haya sido retocado para la institución, más allá de ese retoque es necesario definir un framework a medida para una arquitectura específica del proyecto. La “puesta a punto” a éste nivel será seleccionada de los entregables apropiados y artefactos para conocer el proyecto y las necesidades de los stakeholders. 2 Método de la arquitectura La base del esquema estructural está trazada sobre TOGAF, por lo que está sección debe recoger una breve explicación de TOGAF en términos generales. 2.1 Método de arquitectura a medida El punto de partida es el ADM, más su adaptación al contexto de la educación superior deberá ser especificada en términos particulares, con ello se busca delimitar como objetivo para el establecimiento de la EA a la UTPL, describiendo estructuralmente a los componentes que intervienen en EA-UTPL (Medio ambiente, conductores, áreas involucradas, etc.) 3 Contenido de la arquitectura a medida Abarca un listado de los entregables y artefactos que formarán parte del proyecto EA-UTPL. 3.1 Entregables de la arquitectura Uno o varios artefactos pueden constituir un entregable, es decir a partir de ellos se elabora documentación (informes) que servirán para que los patrocinadores puedan ver y entender tanto el progreso como aspectos relevantes del proyecto EA-UTPL. 3.2 Artefactos de la arquitectura Abarca los productos o herramientas tangibles utilizadas para el levantamiento de una EA. Cada artefacto detalla


ORIENTADO A LA UTPL

EA – UTPL - 124 - | P á g i n a

el diseño deseado para la arquitectura en determinados aspectos, o bien recoge información necesaria hacer los detalles de diseño mencionados. En esta sección se deben listar los artefactos propuestos en la sección 5 y además los que se consideren necesarios desarrollar. 4 Herramientas configuradas e implementadas 4.1 Herramientas Abarca el listado de herramientas utilizadas y a ser usadas en el proyecto y con el estado actual de TI de la UTPL 5 Interfaces con modelos de gobernanza y frameworks 5.1 Framework de administración de la EA Una vez que la EA sea desarrollada es necesario establecer un marco de gobierno y administración, para ello es necesario tener en claro los aspectos mencionados en este capítulo, en la parte 5.8. 5.2 Framework de gestión de la capacidad Especificar el framework de gestión de la capacidad, detallar de manera descriptiva de no existir un framework formal.

La GC es la encargada de que todos los servicios TI se vean respaldados por una capacidad de proceso y almacenamiento suficiente y correctamente dimensionada. Sin ella los recursos no se aprovechan adecuadamente y se realizan inversiones innecesarias que acarrean gastos adicionales de mantenimiento y administración. O aún peor, los recursos son insuficientes con la consecuente degradación de la calidad del servicio. El framework (formal o informal de la UTPL) debe:

• Asegurar que se cubren las necesidades de capacidad TI tanto presentes como futuras. • Controlar el rendimiento de la infraestructura TI. • Desarrollar planes de capacidad asociados a los niveles de servicio acordados. • Gestionar y racionalizar la demanda de servicios TI.

La gestión de la capacidad está dada para las cuatro capas de la EA, pero puede el proceso de gestión puede generalizarse en segmentos (subprocesos) que analicen las necesidades de capacidad TI de la UTPL desde diferentes puntos de vista:

• Gestión de la Capacidad del Negocio: que centra su objeto de atención en las necesidades futuras de usuarios y clientes (estudiantes).

• Gestión de la Capacidad del Servicio: que analiza el rendimiento de los servicios TI con el objetivo de garantizar los niveles de servicio acordados.

• Gestión de la Capacidad de Recursos: que estudia tanto el uso de la infraestructura TI como sus tendencias para asegurar que se dispone de los recursos suficientes y que estos se utilizan eficazmente.

5.3 Framework de gestión de portafolio Especificar el framework de gestión dl portafolio, detallar de manera descriptiva de no existir un framework formal. El framework guará a la respuesta de las preguntas:


ORIENTADO A LA UTPL

EA – UTPL - 125 - | P á g i n a

• ¿Cuáles son los mejores pasos para implementar tomando en cuenta un presupuesto y las capacidades

organizacionales de la UTPL para el proyecto EA-UTPL? • ¿Se está obteniendo lo mejor del potencial del portafolio de proyectos de la UTPL? • ¿Se está sobre-invirtiendo en TI?

Tener un framework robusto de gestión del portafolio se verá reflejado en un 10-25% de reducción de costos, liberando capital para nuevas inversiones, también un 5-40% de incremento en retornos (IRR, NPV, EBIT) con el mismo presupuesto, así como de 5-15% de mejoras en la utilización de los recursos. Por lo expuesto es de vital importancia que exista alguna tecnología formal (la UTPL cuenta con PMO, se debe describir en esta sección) 5.4 Framework de gestión del proyecto Especificar el framework de gestión de proyectos, detallar de manera descriptiva de no existir un framework formal. Se refiere a un framework que permita gestar todas las acciones que deben realizarse para cumplir con una necesidad definida dentro de los plazos. 5.5 Framework de gestión de operaciones Especificar el framework de gestión de operaciones, detallar de manera descriptiva de no existir un framework formal Este framework debe encargarse del manejo de la producción de los bienes y servicios de la UTPL. Debe ayudar a la toma de decisiones para decisiones que se relacionan con la función de operaciones y los sistemas de transformación que se utilizan.


ORIENTADO A LA UTPL

EA – UTPL - 126 - | P á g i n a

5.1.10.6 Plantilla para levantamiento de: Repositorio arquitectónico

Repositorio Arquitectónico


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito del Documento 2 Framework Arquitectónico 3 Información Base de Estándares 4 Paisaje Arquitectónico 5 Arquitecturas de Referencia 6 Apuntes de Gobernabilidad Información del documento



Preparado por:


Título: Repositorio Arquitectónico Fecha de Versión: Revisado por:

Fecha de Revisión:




* Tipos de Acción: Aprobado, Revisión, Informe, Archivo, Acción Requerida, Asistirá a Reunión, Otro (por favor


ORIENTADO A LA UTPL

EA – UTPL - 127 - | P á g i n a

especificar) Historial de revisión del documento

Nro. de Versión

Fecha de Versión


1 Propósito Este documento describe el Repositorio Arquitectónico. El repositorio arquitectónico actúa como un área de contención para todos los proyectos relacionados con la arquitectura dentro de la empresa. El repositorio le permite al proyecto manejar sus entregables, localizar los activos re-usables, y publicar las salidas a los stakeholders y otras partes interesadas. 2 Framework arquitectónico Especificar a breves rasgos la importancia del repositorio arquitectónico con respecto al framework Hablando del framework en términos de su repositorio, permitirá contar con las guías para la creación de modelos formales, es decir la arquitectura de: negocio, datos, aplicaciones e infraestructura tecnológica. 2.1 Información general Describir la a breves rasgos como se desea manejar el repositorio, o qué repositorio formal se desea utilizar Al formalizar el framework dentro de un repositorio se logrará especificar las entidades de negocio y sus relaciones (descritas de manera visual), también como crear los meta-modelos del negocio y de la EA adoptada, y finalmente almacenar el conjunto de entregables y artefactos. 3 Información base de estándares Especificar un concepto sobre el tipo de estándares que se desean incluir en el proyecto EA-UTPL Por ejemplo se debe hacer una breve descripción de estándares existentes y manejados dentro de la UTPL como BPM y los que se erigen sobre el proyecto EA-UTPL, como el ADM de TOGAF. 3.1 Clasificación de estándares Listar la taxonomía de estándares y la orientación que tienen: Negocio, TI en general, EA, etc. 3.2 Estándares de negocio <<Especificar los estándares aplicables a la capa de negocio>> 3.3 Estándares de datos


ORIENTADO A LA UTPL

EA – UTPL - 128 - | P á g i n a

<<Especificar los estándares aplicables a la capa de datos>> 3.4 Estándares de aplicación <<Especificar los estándares aplicables a la capa de aplicaciones>> 3.5 Estándares tecnológicos <<Especificar los estándares aplicables a la capa de tecnología>> 4 Perspectiva arquitectónica (paisaje) 5.2 Arquitecturas estratégicas <<Describir qué arquitecturas usadas dentro de toda la UTPL servirán como apoyo para el levantamiento del proyecto EA-UTPL>> 4.2 Arquitecturas segmentadas <<Especificar que arquitecturas aplicadas a determinados segmentos de la UTPL pueden ser claves para el levantamiento de EA-UTPL>> 4.3 Capacidad arquitectónica <<En base a la medición de la madurez organizacional, al enfoque y alcance del proyecto EA-UTPL se podrá realizar una estimación de la capacidad de adopción del enfoque arquitectónico (EA). Se encuentra involucrada en este punto la disponibilidad de recursos para el proyecto, en base a ellos se puede realizar la estimación>> 5 Arquitecturas de referencia <<Esta sección NO es obligatoria. Especificar si EA-UTPL se construirá en base a una arquitectura preexistente, dado que no es el caso esta sección podría recoger algún ejemplo de arquitectura base utilizada por algún otra institución de educación superior>> 5.1 Información general <<Especificar cómo se estructura la arquitectura de referencia>> 5.2 Organismos de normalización <<Especificar la lista de organismos involucrados con esta arquitectura y su relación>> 5.3 Proveedores de Productos y servicios <<Especificar la lista de proveedores de productos y servicios involucrados dentro de esta arquitectura>> 5.4 Industria, comunidades y foros


ORIENTADO A LA UTPL

EA – UTPL - 129 - | P á g i n a

<<Especificar la lista otros “asociados” involucrados>> 5.5 Plantillas corporativamente definidas <<Describir la cantidad, tipo y forma de las plantillas utilizadas para el levantamiento de artefactos y entregables de esta arquitectura>> 5.6 Mejores prácticas <<Especificar la lista de mejores prácticas establecida dentro de esta arquitectura>> 6 Apuntes de gobernabilidad <<Permitirá brindar una perspectiva clara de cómo está gobernada la UTPL, ello llevará a poder establecer en principio un enfoque de gobernanza formal>> <<Especificar introductoriamente como se encuentra gobernada la UTPL>> 6.1 Información general <<Describir la forma de gobierno, incluyendo los modelos usados y los recursos involucrados>> 6.2 Evaluación del cumplimiento <<Es una evaluación de “madurez” en cuanto al cumplimiento de la gobernanza, precisamente no es formal, pero sin embargo debe ser constante en la forma “informal” de llevarse, de acuerdo a la constancia ante las especificaciones de gobernabilidad se podrá establecer el grado de cumplimiento>> 6.3 Evaluación de la capacidad <<En base a la medición de la madurez organizacional (respecto a la gobernanza), se podrá realizar una estimación de la capacidad de gobierno>> 6.4 Calendario <<Especificar el calendario del proyecto>> 6.5 Portafolio del proyecto <<Especificar el portafolio del proyecto>> 6.6 Métricas de desempeño <<Delimitar qué métricas de desempeño se utilizarán>>


ORIENTADO A LA UTPL

EA – UTPL - 130 - | P á g i n a

5.2 Fase A: Visión Arquitectónica

Esta fase pone en marcha formalmente al ADM, y es de vital importancia porque describe la

capacidad institucional plasmada en términos de objetivos estratégicos, metas, e indicadores del negocio.

Delimita el alcance real de la ejecución del trabajo arquitectónico y brinda una clara

descripción de las restricciones existentes a través de un de un plan de trabajo detallado.

FasePreliminar



de Información

Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio


Fase A:Visión

Arquitectónica

5.2.1 Objetivos

• Asegurase que la evolución del ciclo de desarrollo de la arquitectura tiene un adecuado reconocimiento y respaldo de la alta dirección de la institución, así como el apoyo y el compromiso de la línea de gestión necesaria.

• Definir y organizar un ciclo de desarrollo de la arquitectura dentro del contexto general del framework arquitectónico, según lo establecido en la fase preliminar.

• Validar los principios, objetivos y los conductores estratégicos de negocio de la institución, así como los indicadores clave de desempeño (KPI, por sus siglas en inglés) de la EA.

• Definir stakeholders relevantes, sus expectativas y objetivos.


ORIENTADO A LA UTPL

EA – UTPL - 131 - | P á g i n a

• Definir los requisitos clave del negocio que deben abordarse en el esfuerzo arquitectónico, así como y las limitaciones que deben ser tratadas.

• Articular una visión de arquitectónica y formalizar la propuesta de valor que pueda servir para dar respuesta a los requisitos y limitaciones.

• Crear un plan integral que aborde la programación, asignación de recursos, financiación, comunicación, riesgos, limitaciones, supuestos y dependencias, de acuerdo con los frameworks de gestión de proyectos aprobados por la institución.

• Asegurar la aprobación formal para proceder con la EA. 5.2.2 Enfoque

La Fase A se inicia con la recepción de una solicitud de trabajo arquitectónico. Define lo que es y lo que está fuera del alcance del esfuerzo de la arquitectura, así como las limitaciones que deben ser tratadas. Es por ello que la determinación del alcance debe hacerse sobre la base de una evaluación práctica de los recursos, de la disponibilidad de competencias y del valor que se puede esperar que obtuviera la institución desde ámbito de la arquitectura elegida.

Algunas limitaciones normalmente serán informadas por los principios de negocios y los principios arquitectónicos, que forman parte de la fase preliminar. Los principios arquitectónicos que forman parte de las restricciones sobre el trabajo arquitectónico, se habrán definido en la fase preliminar.

Esta fase de visión arquitectónica describe cómo la nueva competencia será cumplir con las metas y objetivos estratégicos de negocio, así como la dirección de las expectativas de los stakeholders si se aplican. Es una herramienta clave para vender los beneficios de la capacidad de la propuesta EA a los stakeholders y quienes toman las decisiones dentro de la institución. Para ello es necesario:

• Aclarar la aceptación con el acuerdo de la EA. • Clarificar el propósito y la demostración de cómo ello se logrará mediante el desarrollo de la

arquitectura propuesta. • Verificar y comprender la estrategia y objetivos de negocio documentados. • Proporcionar un primer corte de alto nivel de descripción de las arquitecturas “línea base” y

“objetivo”, abarcando dominios de negocio, datos, aplicaciones y tecnología. 5.2.3 Escenarios de Negocio

Son los métodos de identificación y articulación de las necesidades empresariales implicados en la capacidad de las nuevas operaciones para hacer frente a los conductores clave del negocio, y a los requisitos implícitos de la arquitectura. Algunos ejemplos comprenden:

• Un proceso de negocio, una aplicación o conjunto de aplicaciones que se pueden habilitar por la arquitectura.


ORIENTADO A LA UTPL

EA – UTPL - 132 - | P á g i n a

• El ambiente de negocios y tecnología. • La gente y los componentes computacionales (denominados actores) que ejecutan el

escenario. • El resultado deseado de la correcta ejecución.

Un buen escenario de negocio representa a una necesidad o un problema significativo de

negocio, y permite que dar valor a una solución para que sea entendida dentro de la institución.

Identificación del problema

Identificación del ambiente

Identificación de objetivos deseados

Identificación de humanos

participantes

Identificación deParticipantes

automatizados

Definir roles y responsabilidades

Validar y refinar

Identificar, documentar, y clasificar el problema bajo un escenario.

Identificar el ambiente técnico y de negocio del escenario, y documentar este

en modelos de escenario.

Identificar y documentar los objetivos deseados.

Identificar los participantes humanos y su lugar en el modelo de negocio.

Identificar los elementos computacionales y su lugar en el modelo tecnológico.

Identificar y documentar roles, responsabilidades, medidas de éxito por actor, documentar los scripts

por actor, y los resultados de manejo de la situación.

Comprobar de la idoneidad del propósito y refinarlo sólo si es necesario

Figura 19: Esquema de escenario de negocios [1] Un escenario de negocios implica un desarrollo iterativo basado en fases de recolección,

análisis y revisión de la información. En cada fase, cada uno de los pasos anteriores debe ser sucesivamente ampliado. Así, el paso de refinamiento implica decidir si se debe considerar el escenario completo e ir a la siguiente fase o si un refinamiento adicional es necesario.

5.2.4 Entradas 5.2.4.1 No arquitectónicas

• Solicitud de trabajo arquitectónico.


ORIENTADO A LA UTPL

EA – UTPL - 133 - | P á g i n a

• Principios, objetivos y conductores de negocio. 5.2.4.2 Arquitectónicas

• Modelo organizacional para la arquitectura empresarial. o Alcance de las unidades de negocio afectadas. o Evaluación de madurez, de brechas, y enfoque de resolución. o Funciones y responsabilidades para el equipo arquitectónico. o Limitaciones en el trabajo arquitectónico. o Reutilización de requisitos. o Presupuesto de requisitos. o Solicitudes para el cambio. o Gobernanza y estrategia de apoyo.

• Framework arquitectónico a medida. o Método arquitectónico adaptado. o Contenido arquitectónico adaptado. o Principios Arquitectónicos. o Herramientas desplegadas y configuradas.

• Repositorio con la documentación arquitectónica existente (descripción de framework, descripciones arquitectónicas, descripciones de línea de base, etc.)

5.2.5 Salidas

• Estatuto de trabajo arquitectónico aprobado. o Alcance y limitaciones. o Plan para el trabajo arquitectónico. o Funciones y responsabilidades. o Riesgos y actividad de mitigación. o Trabajo con las evaluaciones de desempeño del producto. o Modelo de negocio y métricas KPI.

• Declaraciones refinadas de principios, objetivos y conductores de negocio. • Principios arquitectónicos. • Evaluación de la capacidad. • Framework arquitectónico adaptado (a medida).

o Método arquitectónico adaptado. o Contenido arquitectónico adaptado (presentación de resultados y artefactos). o Herramientas configuradas y desplegadas.

• Visión arquitectónica o Requisitos de stakeholders clave de alto nivel. o Línea base de arquitectura de negocios. o Línea base de arquitectura de tecnología. o Línea Base de arquitectura de datos. o Línea base de arquitectura de aplicaciones.


ORIENTADO A LA UTPL

EA – UTPL - 134 - | P á g i n a

o Arquitectura de negocios objetivo. o Arquitectura de tecnología objetivo. o Arquitectura de datos objetivo. o Arquitectura de aplicaciones objetivo.

• Plan de comunicaciones.


ORIENTADO A LA UTPL

EA – UTPL - 135 - | P á g i n a

5.2.6 Definición del proceso de visión arquitectónica Definición de Procesos

Proceso: FA – VisiónArquitectónica: Establecimiento de la visión arquitectónica. Cod.Doc FA –

VisiónArquitectónicaX Responsable: CIO, DGTI, ADS, DEA, ADD, DTE, CSI Versión: 1.0

Mantenimiento: DGTI, ADS, CSI Estado: Borrador Publicado X

Descripción: Es el proceso mediante el cual se describe la capacidad real de la institución en base a objetivos estratégicos, metas, indicadores de negocio. Para ello hace uso de un plan de trabajo detallado que delimita el alcance de la arquitectura y describe las restricciones para el trabajo arquitectónico.

Alcance: El proceso de la visión arquitectónica, contempla los siguientes procedimientos:

• Formalizar una solicitud de trabajo arquitectónico. • Delimitar el trabajo arquitectónico. • Definir limitaciones. • Vender los beneficios de la capacidad de la propuesta EA. • Aclarar la aceptación con el acuerdo de la EA. • Clarificar el propósito y la demostración de cómo ello se logrará mediante el

desarrollo de la arquitectura propuesta. • Verificar y comprender la estrategia de negocios documentados y objetivos. • Proporcionar un primer corte de alto nivel de descripción de las arquitecturas

“línea base” y “objetivo”, abarcando dominios de negocio, datos, aplicaciones y tecnología.


No aplica




En este documento se usan las siguientes abreviaciones y acrónimos:

• ADS: Arquitectos de soluciones • ADD : Arquitectos de dominio • DTE: Director de tecnologías emergentes • DGTI: Director de gobernanza de TI. • DEA: Director del proyecto EA (Líder). • CIO: Chief Information Officer (Director ejecutivo) • CSI: Coordinador de servicios de investigación.

Listado de Cambios



Descripción

1.0 26/10/2010 DGTI, ADS, DEA, ADD, DTE, CSI

Todo A Emisión Inicial


ORIENTADO A LA UTPL

EA – UTPL - 136 - | P á g i n a



• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar una visión arquitectónica clara.

• Informar sobre la visión que se tiene de la arquitectura a desarrollarse.

Entradas:

Salidas:

• Solicitud de trabajo arquitectónico. • Principios, objetivos y conductores de

negocio. • Modelo organizacional para la EA. • Framework arquitectónico a medida. • Repositorio con la documentación

arquitectónica existente.

• Estatuto de trabajo arquitectónico aprobado. • Declaraciones refinadas de principios,

objetivos y conductores de negocio. • Principios arquitectónicos. • Evaluación de la capacidad. • Framework arquitectónico adaptado. • Visión arquitectónica • Plan de comunicaciones.

Roles:

• ADS: Brindar una línea base y establecer una EA objetivo. • ADD: Delimitar dominio, establecer arquitectura objetivo. • DEA: Integrar resultados. • DGTI: Dar soporte al proceso. • DTE: Brindar soporte para herramientas, tecnología y pruebas en fases posteriores. • CSI: Estudia y analiza la visión en base a metodologías formales.


• Modelo Organizacional. • Framework arquitectónico candidato. • Principios arquitectónicos. • Estrategias, planes de negocio, políticas y marco jurídico. • Repositorio arquitectónico inicial.

Tareas: 1. Establecer el proyecto EA. 2. Identificar stakeholders, sus expectativas y requerimientos del negocio. 3. Confirmar y elaborar objetivos de negocio, los conductores y las limitaciones de negocio. 4. Evaluar las capacidades empresariales de la institución. 5. Evaluar la disposición para que se dé una transformación de negocio. 6. Definir el alcance. 7. Confirmar y principios arquitectónicos, incluidos los principios de negocio. 8. Desarrollar la visión arquitectónica. 9. Definir la proposición de arquitectura objetivo de KPIs. 10. Identificar los riesgos de transformación empresarial y las actividades de mitigación. 11. Elaborar planes de EA, de declaración de trabajo arquitectónico y de aprobación segura.

Métricas: • Capacidad institucional para poder delimitar el alcance de la EA.

B. Definición Detallada del Proceso


ORIENTADO A LA UTPL

EA – UTPL - 137 - | P á g i n a

Establecimiento de la visión arquitectónica. Objetivos del Procedimiento:

• Asegurase que la evolución del ciclo de desarrollo de la arquitectura tiene un adecuado reconocimiento y respaldo de la alta dirección de la institución, así como el apoyo y el compromiso de la línea de gestión necesaria.

• Definir y organizar un ciclo de desarrollo de la arquitectura dentro del contexto general del framework arquitectónico, según lo establecido en la fase preliminar.

• Validar los principios, objetivos y los conductores estratégicos de negocio de la institución, así como los indicadores clave de desempeño (KPIs) de la EA.

• Definir stakeholders relevantes, sus expectativas y objetivos. • Definir los requisitos clave del negocio que deben abordarse en este esfuerzo

arquitectónico, así como y las limitaciones que deben ser tratadas. • Articular una visión de arquitectónica y formalizar la propuesta de valor que

pueda servir para dar respuesta a los requisitos y limitaciones. • Crear un plan integral que aborde la programación, asignación de recursos,

financiación, comunicación, riesgos, limitaciones, supuestos y dependencias, de acuerdo con los frameworks de gestión de proyectos aprobados por la institución.

• Asegurar la aprobación formal para proceder con la EA. Roles y Responsabilidades:


• ADS: Brindar una línea base y establecer una EA objetivo. • ADD: Delimitar dominio, establecer arquitectura objetivo, con ello se obtendrá el

alcance de la EA. • DEA: Integrar resultados de los análisis de los demás responsables y ver si los

entregables se acoplan a los objetivos de negocio. • DGTI: Dar soporte al proceso. • DTE: Brindar soporte para herramientas, tecnología y pruebas en fases

posteriores. • CSI: Estudiar y analizar la visión arquitectónica.

Criterios de Entrada:

Los criterios de entrada asociados a este procedimiento se listan a continuación:

• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar una visión arquitectónica clara.

Entradas: • Solicitud de trabajo arquitectónico. • Principios, objetivos y conductores de negocio. • Modelo organizacional para la EA.

o Alcance de las unidades de negocio afectadas. o Evaluación de madurez, de brechas, y enfoque de resolución. o Funciones y responsabilidades para el equipo arquitectónico. o Limitaciones en el trabajo arquitectónico. o Reutilización de requisitos. o Presupuesto de requisitos. o Solicitudes para el cambio. o Gobernanza y estrategia de apoyo.

• Framework arquitectónico a medida. o Método arquitectónico adaptado. o Contenido arquitectónico adaptado. o Principios Arquitectónicos. o Herramientas desplegadas y configuradas.


ORIENTADO A LA UTPL

EA – UTPL - 138 - | P á g i n a

• Repositorio con la documentación arquitectónica existente (descripción de framework, descripciones arquitectónicas, descripciones de línea de base, etc.)


Los pasos necesarios para este procedimiento se listan a continuación:

1. Establecer el proyecto arquitectónico. El proyecto que involucra la metodología de desarrollo arquitectónico (MDG) debe llevarse a cabo dentro del marco de gestión de proyectos de la institución. Debería ser planeado y manejado utilizando las prácticas aceptadas que son de manejo usual a nivel de instituciones de educación superior.

2. Identificar stakeholders, sus expectativas y requerimientos del negocio.

• Identificar los principales stakeholders, junto con sus expectativas y objetivos. • Definir los requerimientos clave de negocio que deben abordarse en el

emprendimiento de la arquitectura. • Crear un mapa de stakeholders para la contratación, mostrando qué

stakeholders están involucrados con el emprendimiento, su nivel de participación, y sus expectativas clave.

• Este paso busca tres objetivos específicos:

o Identificar los componentes candidatos de la visión y los requisitos para poner a prueba como es desarrollada la visión arquitectónica.

o Identificar los límites del alcance candidato, para con ello limitar el compromiso respecto a la amplitud de los estudios de arquitectura requerida.

o Identificar expectativas de stakeholders, hechos, y los factores culturales que darán forma a cómo la arquitectura se presentará y comunicará.

3. Confirmar y elaborar objetivos de negocio, los conductores y las limitaciones

de negocio.

• Identificar los objetivos de negocio y los conductores estratégicos de la institución.

• Asegurarse de que las definiciones existentes estén al día, y aclarar todas las áreas de ambigüedad.

• Definir las restricciones que deben ser tratadas, incluidas las limitaciones de toda la institución y las limitaciones específicas del proyecto (tiempo, horario, recursos, etc.) 4. Evaluar las capacidades empresariales.

Inicialmente se debe realizar evaluación de la capacidad de negocio para definir las capacidades que la institución va a necesitar para cumplir sus objetivos y conductores de negocio. Además se debe tener en consideración:

• Analizar las capacidades y metas del negocio.


ORIENTADO A LA UTPL

EA – UTPL - 139 - | P á g i n a

• Identificar las opciones para lograr dichas capacidades. • Evaluar posibles consecuencias para la capacidad tecnológica de la institución,

esto se logra creando una imagen inicial de nueva capacidad de TI que será necesaria para apoyar la meta de la visión arquitectónica.

• Documentar los resultados de la evaluación de capacidad.

5. Evaluar la disposición para que se dé una transformación de negocio. Para la correcta ejecución se debe considerar evaluar y cuantificar la disposición de la institución para someterse a un cambio. La evaluación debe estar basada en el análisis y puntuación de una serie de factores de preparación como:

• Capacidad para implementar y operar. • Capacidad departamental de ejecución. • Capacidad TI de ejecución. • Enfoque viable y un modelo de ejecución. • Rendición de cuentas. • Gobernanza. • Patrocinio y liderazgo. • Financiamiento. • Modelo de negocio. • Necesidades. • Deseo / voluntad / resolución. • Visión.

Los resultados se utilizan para dar forma al ámbito de la arquitectura y así identificar las actividades requeridas dentro del proyecto arquitectónico, y para identificar áreas de riesgo que deben abordarse.

6. Definir el alcance. Define lo que está dentro y lo que está fuera del alcance de la línea base arquitectónica y de la arquitectura objetivo. Abarca aspectos como:

• La amplitud de la cobertura de la institución. • El nivel de detalle requerido. • Las características de la partición de la arquitectura. • Los dominios arquitectónicos específicos que deben cubrirse (negocio, datos,

aplicaciones, tecnología). • La extensión del período de tiempo puesto como objetivo para finalizar, más el

número y el alcance de cualquier período de tiempo intermedio. • El patrimonio arquitectónico a ser apalancado, o que se considere para ser

usado.

7. Especificar los principios arquitectónicos, incluidos los principios de negocio.

Se deben revisar los principios según los cuales la arquitectura se va a desarrollar.


ORIENTADO A LA UTPL

EA – UTPL - 140 - | P á g i n a

Normalmente este procedimiento se erige sobre en los principios desarrollados en el marco de la fase preliminar, por lo que es necesario asegurarse que las definiciones existentes sean actuales y clarifiquen cualquier idea de ambigüedad, resolviéndola si es necesario.

8. Desarrollar la visión arquitectónica. Implica crear una vista de alto nivel de las arquitecturas línea base y objetivo, por ello este paso está basado en las expectativas de los stakeholders, requisitos de capacidad de negocio, el alcance, restricciones y principios. Con ello abarca desde un alto nivel a todo el espectro del alcance definido para el proyecto. Como consecuencia crea las primeras definiciones de alto nivel de la línea de base y los entornos de la arquitectura objetivo, desde las perspectivas de negocio, sistemas de información y la tecnología.

9. Definir la proposición de arquitectura objetivo desde KPIs.

• Desarrollar el modelo de negocio para las arquitecturas y cambios requeridos. • Producir la propuesta de valor para cada uno de los grupos de stakeholders. • Evaluar y definir los requisitos de contratación. • Revisar y acordar propuestas de valor con los patrocinadores e stakeholders

interesados. • Definir métricas de rendimiento y medidas que se construirán para la EA, con el

fin de satisfacer las necesidades de negocio. • Evaluar las operaciones de riesgo. • Incorporar un estatuto de trabajo arquitectónico para permitir el rastreo del

rendimiento.

10. Identificar los riesgos de transformación empresarial (institucional) y las actividades de mitigación.

Sirve para identificar los riesgos asociados con la visión arquitectónica y evalúan el nivel inicial de riesgo (catastrófico, crítico, marginal o insignificante), así como la frecuencia potencial. Se incluyen de igual manera actividades de mitigación de riesgo dentro del de trabajo arquitectónico. Existen dos niveles de riesgo:

• Nivel inicial de riesgo: clasificación de riesgo antes de determinar y aplicar medidas de mitigación.

• Nivel de Riesgo residual: categorización de riesgos tras la aplicación de medidas de mitigación (si existen).

11. Elaborar planes de EA, de declaración de trabajo arquitectónico y de aprobación segura.

• Definir el trabajo requerido y el momento de presentación para el conjunto de

requisitos de desempeño de negocio.


ORIENTADO A LA UTPL

EA – UTPL - 141 - | P á g i n a

• Identificar los productos de trabajo nuevos. • Proporcionar dirección en la que los productos existentes de trabajo, incluidos

los bloques constitutivos, tendrán que ser cambiados y garantizar que todas las actividades y dependencias de estos estén coordinados.

• Identificar el impacto del cambio sobre otros productos de trabajo y la dependencia de sus actividades.

• Sobre la base del propósito, enfoque, alcance y limitaciones, determinar qué dominios arquitectura deben ser desarrollados, a qué nivel de detalle, y qué perspectivas arquitectónicas deben ser construidas.

• Evaluar las necesidades de recursos y la disponibilidad para realizar el trabajo en el plazo requerido.

• Estimar los recursos necesarios, desarrollar un plan de actuación y un calendario para el desarrollo propuesto.

• Definir las métricas de rendimiento que deben cumplirse por el equipo EA-UTPL. • Desarrollar el plan de comunicaciones específico de la EA. • Revisar y acordar los planes con los patrocinadores, así como la aprobación

formal del estatuto de trabajo arquitectónico conforme a los procedimientos de gobernanza apropiados.

• Ganancia de cierre de sesión (de fase) para continuar.

Salidas: • Estatuto de trabajo arquitectónico aprobado.

o Alcance y limitaciones. o Plan para la obra arquitectónica. o Funciones y responsabilidades. o Riesgos y actividad de mitigación. o Trabajo de las evaluaciones de desempeño del producto o Modelo de negocio y métricas KPI.

• Declaraciones refinadas de principios, objetivos y conductores de negocio. • Principios arquitectónicos. • Evaluación de capacidad. • Framework Arquitectónico adaptado (a medida).

o Método arquitectónico adaptado. o Contenido arquitectónico adaptado (presentación de resultados y

artefactos). o Herramientas configuradas y desplegadas.

• Visión arquitectónica o Requisitos de stakeholders clave de alto nivel. o Línea base de arquitectura de negocios. o Línea base de arquitectura de tecnología. o Línea Base de arquitectura de datos. o Línea base de arquitectura de aplicaciones. o Arquitectura de negocios objetivo. o Arquitectura de tecnología objetivo. o Arquitectura de datos objetivo. o Arquitectura de aplicaciones objetivo.

• Plan de comunicaciones. Criterios de Los criterios de salida para este procedimiento se listan a continuación:


ORIENTADO A LA UTPL

EA – UTPL - 142 - | P á g i n a

Salida: • Informar sobre la visión que se tiene de la arquitectura a desarrollarse. • Informar los factores que afectan a la visión arquitectónica. • Definir el “por qué” de dichos factores y definir soluciones.

Métricas del Proceso:

Las métricas que deben recopilarse en este procedimiento incluyen: • Capacidad real de la institución en base a objetivos estratégicos, metas,

indicadores de negocio.


ORIENTADO A LA UTPL

EA – UTPL - 143 - | P á g i n a

5.2.7 Plantillas para la fase de visión arquitectónica 5.2.7.1 Plantilla para levantamiento de: Declaración de trabajo arquitectónico

Declaración del Trabajo Arquitectónico


___________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de este documento 2 Declaración de Trabajo de Arquitectura 3 Objetivos y Alcance 4 Roles y Responsabilidades 5 Enfoque Arquitectónico 6 Plan de Trabajo 7 Riesgos y Mitigaciones 8 Criterios de Aceptación y Procedimientos 9 Firmas de Aprobación Información del documento



Preparado por:


Título: Declaración de Trabajo de Arquitectura Fecha de Versión: Revisado por:

Fecha de Revisión:





ORIENTADO A LA UTPL

EA – UTPL - 144 - | P á g i n a

* Tipos de Acción: Aprobado, Revisión, Informe, Archivo, Acción Requerida, Asistirá a Reunión, Otro (por favor especificar) Historial de revisión del documento

Nro. de Versión

Fecha de Versión


1 Propósito de este documento Este documento es la declaración para el trabajo arquitectónico para el proyecto EA-UTPL. La declaración de trabajo de arquitectura define el alcance y enfoque que serán usados para completar el proyecto de arquitectura. En general, toda la información en este documente debe ser de alto nivel. Puede ser que la Declaración de Trabajo de Arquitectura sea documentada usando una wiki o un documento intranet basado en texto, Incluso sería mejor usar una herramienta TOGAF licenciada para capturar esas salidas. Esta plantilla muestra el contenido “típico” de una declaración de trabajo de arquitectura que puede ser adaptado y alineada con cualquier adaptación TOGAF que esté siendo implantada. 2 Declaración de trabajo arquitectónico Conceptualizar brevemente qué se entiende por trabajo arquitectónico y lo que significará este dentro del UTPL. La declaración de trabajo arquitectónico es típicamente el documento contra el cual la ejecución satisfactoria del proyecto será medida y puede ser la base de un acuerdo contractual entre los proveedores y el cliente de servicios arquitectónicos. 3 Requisitos del proyecto y antecedentes Esta sección debe especificar los campos abarcados en la captura de requisitos dados por la plantilla de requisitos arquitectónicos para el proyecto EA-UTPL. Dicha plantilla es un archivo de Microsoft Excel en la que se listan todos los recursos disponibles y necesarios. Se debe referenciar a la plantilla Excel de recolección de requisitos 4 Descripción del proyecto y alcance Describir brevemente de que se trata EA-UTPL y su alcance, para tener con ello una perspectiva de cómo delimitar el alcance del trabajo arquitectónico. Se recomienda revisar la teoría relacionada propuesta en este capítulo (5.2) 5 Estrategia de alineamiento Delimitar los aspectos (hechos) clave que servirán para poner en marcha EA-UTPL y su adhesión al modelo actual de la UTPL.


ORIENTADO A LA UTPL

EA – UTPL - 145 - | P á g i n a

6 Objetivos y alcance del trabajo arquitectónico 6.1 Objetivos Se debe usar la estructura propuesta para listar los objetivos puntuales perseguidos por el negocio así como una breve descripción adicional relevante para cada objetivo. Los objetivos del negocio de este trabajo de arquitectura son los siguientes:

Objetivo de Negocio Notas <<Objetivo de Negocio 1>> <<Notas>> <<Objetivo de Negocio 2>> <<Notas>>

Consulte nuevamente los requisitos (Excel) en la sección de trabajo arquitectónico y refine a criterio.

7 Alcance Describir brevemente de que se trata EA-UTPL y su alcance, para tener con ello una perspectiva de cómo delimitar el alcance del trabajo arquitectónico. Se recomienda revisar la teoría relacionada propuesta en este capítulo (5.2) 8 Interesados, expectativas y Vistas La siguiente tabla muestra los interesados que usarán este documento, sus preocupaciones y como el trabajo de arquitectura cumple sus preocupaciones a través de la entrega de un número de vistas. El siguiente cuadro muestra un ejemplo de la estructura a seguir:

Interesado Expectativas Vista <<Interesado1>> <<Describir que aspecto de la

arquitectura sería de interesa para este interesado.>>

<<Listar cualquier vista que es creada para direccionar las preocupaciones de este interesado>>

Director TI UTPL • Medir la madurez de la UTPL en términos de EA.

• Determinar el porcentaje de alineación de la TI a las estrategias de negocio gracias a la EA

• Modelo de madurez de la EA. • Proyección de alineación en base

a la capacidad y el nivel de madurez.

9 Enfoque de gestión del trabajo arquitectónico ¿Cómo se propone realizar la administración del trabajo para la EA? Describir si se usará alguna metodología formal, revisar si se adoptará TOGAF [1], en la sección de Trabajo Arquitectónico. 10 Cambio de procedimientos de alcance En caso de imprevistos ¿Cómo se platea enfrentarlos orientados al alcance? 11 Roles y responsabilidades


ORIENTADO A LA UTPL

EA – UTPL - 146 - | P á g i n a

Se debe delimitar el grupo de trabajo enfocado netamente al trabajo arquitectónico, esto servirá para poder asignar responsabilidades a cada uno de los roles. Un esquema de cómo realizar la asignación de roles y responsabilidades está descrito en la sección 5.1.4 de este capítulo.

11.1 Estructura de gobierno del equipo Esquema de la estructura del equipo por ejemplo, gráfico de la organización simple mostrando roles y líneas de reporte.>> 12 Procesos del proyecto Esquema de los procesos clave del proyecto, por ejemplo, reuniones regulares, juntas de directivos, repositorios de documentos, administración de configuración, garantías de calidad, procedimientos de escalada, procedimientos de cambio. Este esquema puede especificarse con un modelo WBS. 13 Roles y responsabilidades (RACI) Identifique roles y responsabilidades mediante una tabla RACI Donde sea relevante, agregue una tabla RACI– mostrando claves y actividades a los stakeholders de EA-UTPL, además de quién es el (R) responsable, (A) Contable, (C) Consultado e (Informado en cada caso). Una tabla de asignación de responsabilidades (RACI) relaciona actividades con recursos (individuos o equipos) de trabajo. Con ello se asegura que cada uno de los componentes del alcance esté asignado a un individuo o a un equipo. En el siguiente ejemplo podemos ver la estructura de una matriz RACI adaptable a cualquier segmento del proyecto EA-UTPL:

Rol Descripción

R Responsable Este rol realiza el trabajo y es responsable por su realización. Lo más habitual es que exista sólo un R, si existe más de uno, entonces el trabajo debería ser subdividido a un nivel más bajo, usando para ello las matrices RASCI. Es quien debe ejecutar las tareas.

A Aprobador Este rol se encarga de aprobar el trabajo finalizado y a partir de ese momento, se vuelve responsable por él. Sólo puede existir un A por cada tarea. Es quien debe asegurar que se ejecutan las tareas.

C Consultado Este rol posee alguna información o capacidad necesaria para terminar el trabajo. Se le informa y se le consulta información (comunicación bidireccional).

I Informado Este rol debe ser informado sobre el progreso y los resultados del trabajo. A diferencia del Consultado, la comunicación es unidireccional.

S Soporte Utilizado en la matriz RACI para la validación de la tabla RACI. Este rol proporciona recursos adicionales para realizar el trabajo.

Un ejemplo sencillo de una matriz RACI adaptado a la UPSI por ejemplo podría ser:

Actividad / Recurso Armando Carlos Elizabeth Mariana


ORIENTADO A LA UTPL

EA – UTPL - 147 - | P á g i n a

Investigación R I I A

Planificación C A R I

Desarrollo A R

Verificación de Errores I R A

14 Enfoque arquitectónico 14.1 Procesos arquitectónicos El Método de Desarrollo Arquitectónico (AMD) adaptado para EA-UTPL define una metodología de mejores prácticas para el desarrollo arquitectónico. La tabla a continuación describe el uso de AMD en EA-UTPL.

Fase Entrada/Salida Notas Preliminar A – Visión Arquitectónica B – Arquitectura de Negocio <<¿Línea base o/y Objetivo?>> C – Arquitectura de Sistemas de Información

<<¿Línea base o/y Objetivo?>>

D – Arquitectura Tecnológica <<¿Línea base o/y Objetivo?>> E – Oportunidades y Soluciones F – Planeación de Migración G – Implementación de Gobernanza

H – Gestión del Cambio Arquitectónico

Administración de Requisitos <<Proveer cualquier nota más profunda en el ajusto, iteraciones, etc.>> 14.2 Contenido arquitectónico

FasePreliminar



de Información

Fase D:Arquitectura

De Teconología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica

Gestión deRequerimientos


ORIENTADO A LA UTPL

EA – UTPL - 148 - | P á g i n a

Un Framework de Contenido Arquitectónico (ACF) por ejemplo de TOGAF provee un contenido de categorización de mejores prácticas. Sin embargo, no todos los ítems son necesarios e igualmente relevantes en el proyecto. La tabla siguiente describe el contenido que deberá abarcar EA-UTPL.

Área de Contenido In/Out Notas Principios Arquitectónicos, Visión y Requerimientos

<<Anotar qué sub-categorías serán cubiertas>>

Arquitectura del Negocio << Anotar qué sub-categorías serán cubiertas >> Arquitectura de Sistemas de Información – Datos

<< Anotar qué sub-categorías serán cubiertas >>

Arquitectura de Sistemas de Información – Aplicaciones

<< Anotar qué sub-categorías serán cubiertas >>

Arquitectura Tecnológica << Anotar qué sub-categorías serán cubiertas >> Realización Arquitectónica << Anotar qué sub-categorías serán cubiertas >>

Proveer cualquier percepción de los asuntos de los interesados y cualquier vista particular que pueda ser creada como resultado. 15 Metodologías relevantes y estándares industriales Delimitar las metodologías y estándares asociados a esta sección, para ello tomar la taxonomía de estándares propuesta en la plantilla para el repositorio arquitectónico de la fase preliminar y la de solicitud de trabajo arquitectónico de la misma fase. 16 Apoyo al repositorio de la institución Otros puntos a anotar con respecto al enfoque arquitectónico incluyen: Sección opcional – describir cualquier otro punto clave en términos de categorización en el trabajo arquitectónico. <<Los puntos a considerar incluyen: • Nivel de detalle (estratégico/segmentos/capacidad) • Periodo de Tiempo (¿qué periodo de tiempo cubrirá la arquitectura?) • Tema (¿qué tema de domino se va a cubrir?) • Nivel de Abstracción (por ejemplo: representación concreta de la solución, o más abstracta referencia

arquitectónica) • Línea base versus objetivo (¿es el énfasis en la documentación de la línea base actual, o proponer un

objetivo de arquitectura futuro? ¿En qué secuencia serán estas actividades aproximadas?) • Iteración – ¿cualquier uso de iteración en el AMD? • Particionamiento – ¿cualquier relación a otros trabajos de arquitectura dentro de un ambiente de

particionamiento>> 17 Plan de trabajo Esta sección describe todas las actividades y entregables para el trabajo arquitectónico. <<Proveer un plan de trabajo arquitectónico.>> 17.1 Ítem de trabajo 1…n


ORIENTADO A LA UTPL

EA – UTPL - 149 - | P á g i n a

Actividades Listar las actividades dadas para este ítem Entregables Los siguientes productos de trabajo serán creados como resultado de este trabajo de arquitectura: • <<Producto de Trabajo 1 Nombre>>

<<Descripción del Producto de trabajo 1, etc.>> • <<Producto de Trabajo 2 Nombre>>

<<Descripción del Producto de trabajo 2, etc.>> 18 Planificación de comunicación Tener en cuenta los aspectos: Eventos Canales Formatos Contenidos 19 Colaboración Especificar el plan de colaboración entre los sub-grupos de trabajo, empatando a roles y responsabilidades. 20 Plan del proyecto y horario Describir los puntos críticos del esquema WBS propuesto con anterioridad dentro de esta plantilla. 21 Riesgos y mitigaciones 21.1 Análisis de riesgos Los riesgos pueden ser manejados con el esquema de las restricciones propuestas en la plantilla para la solicitud para el trabajo arquitectónico de la fase preliminar. El esquema planteado allí variaría brevemente quedando así:

ID Riesgo Gravedad Probabilidad Mitigación Propietario 1. 2

<<Nota: La tabla anterior provee una simple evaluación de riesgos para proyectos pequeños. Riesgos más complejos administran metodologías/hojas de cálculo que pueden sustituir la tabla si se considera relevante.>> 21.2 Supuestos La siguiente tabla resume los supuestos par a las declaraciones de trabajo arquitectónico:

ID Supuesto Impacto Propietario


ORIENTADO A LA UTPL

EA – UTPL - 150 - | P á g i n a

1. 21.3 Criterios de aceptación y procedimientos 21.3.1 Métricas y KPIs Se debe listar en la tabla mostrada las métricas que se usarán así como los indicadores clave de proceso. Se podría expresar así: En suma, las siguientes métricas serán usadas para determinar el éxito de este trabajo arquitectónico

Métrica Técnica de Medición Valor Objetivo Justificación/Más notas

Consulte nuevamente a los requisitos para el trabajo de arquitectura y reafirme. 22 Procedimiento de Aceptación Describir los procesos a ser usados para la aceptación/cierre. 23 Firmas de Aprobación

Nombre y Firma Nro. 1…n


ORIENTADO A LA UTPL

EA – UTPL - 151 - | P á g i n a

5.2.7.2 Plantilla para levantamiento de: Evaluación de la capacidad

Evaluación de la Capacidad


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de este documento 2 Evaluación de la capacidad del negocio 3 Evaluación de la capacidad de TI 4 Evaluación de la madurez arquitectónica 5 Evaluación de la disposición para la tranformación del negocio Información del documento



Preparado por:


Título: Evaluación de la capacidad Fecha de Versión: Revisado por:

Fecha de Revisión:

Lista de Distribución De Fecha Teléfono/Fax/Email





ORIENTADO A LA UTPL

EA – UTPL - 152 - | P á g i n a

Historial de Revisión del Documento

Nro. de Versión

Fecha de Versión


1 Propósito << Antes de embarcarse en una Definición Arquitectónica detallada, es valioso entender la línea base y el nivel de capacidad objetivo de la empresa. Esta evaluación de capacidad puede ser examinada de muchas formas: • ¿Cuál es el nivel de capacidad de la empresa en su conjunto? ¿Dónde la empresa desea incrementar u

optimizar su capacidad? ¿Cuáles son las áreas de concentración arquitectónica que serán apoyadas por 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 probables implicaciones de la realización del proyecto de arquitectura empresarial en términos de Gobernanza, Gobernanza Operacional, habilidades, y estructura organizacional? ¿Cuál es un estilo apropiado, nivel de formalización, y cantidad de detalles para el proyecto de arquitectura, para ajustarse con la cultura y capacidad de TI de la organización?

• ¿Cuál es la capacidad y madurez de las funciones arquitectónicas dentro de la empresa? ¿Cuáles activos arquitectónicos son actualmente existentes? ¿Son aún mantenidos y exactos? ¿Qué estándares y modelos de referencia se necesita considerar? ¿Existen probabilidades a ser oportunidades de crear activos re-usables durante el proyecto de arquitectura?

• ¿Dónde las brechas de capacidad existen, para qué extensión está el negocio listo para transformarse con el objetivo de alcanzar la capacidad objetivo? ¿Cuáles son los riesgos de la transformación, barreras culturales, y otras consideraciones a ser direccionadas más allá de la brecha de capacidad básica? >>

2 Evaluaciones de capacidad del negocio 2.1 Capacidades del negocio 2.2 Línea base de evaluación de rendimiento <<Estado de la Línea base de la evaluación del nivel de rendimiento de cada capacidad.>> 2.3 Aspiraciones futuras de rendimiento <<Estado de las futuras aspiraciones para el nivel de rendimiento de cada capacidad.>> 2.4 Evaluación de la capacidad de la línea base <<Estado de evaluación de la línea base para cómo cada capacidad es realizada.>> 2.5 Aspiraciones de capacidades futuras <<Estado de las capacidades futuras para cómo cada capacidad deberá ser realizada.>> 3 Evaluación de capacidad de TI


ORIENTADO A LA UTPL

EA – UTPL - 153 - | P á g i n a

3.1 Nivel de madurez del proceso de cambio <<Estado de la madurez actual para la gestión del cambio dentro de la UTPL>> 3.2 Nivel de madurez objetivos del proceso de cambio <<Estado de la madurez actual para afrontar los objetivos de la gestión del cambio dentro de la UTPL>> 3.3 Nivel de madurez de la línea base del proceso operacional <<Estado de la madurez actual del área operacional>> 3.4 Nivel de madurez objetivo del proceso operacional <<Estado de la madurez actual para afrontar los objetivos del área operacional>> 3.5 Capacidad de la línea base <<Estado de la capacidad de la línea base arquitectónica, dada en contrastación con el alcance>> 3.6 Evaluación de la capacidad <<Valoración de la capacidad cuantificada porcentualmente en relación a la Línea base>> 3.7 Impactos de la Organización de TI <<Evaluación de los posibles impactos de la Organización de TI resultantes de la ejecución del proyecto de arquitectura.>> 4 Evaluación de madurez arquitectónica Evaluar la madurez de la EA en base a los aspectos definidos en la fase preliminar. Para ello considerar:

• Procesos de gobernanza arquitectónica • Organización, roles y responsabilidades • Evaluación de habilidades arquitectónicas • Definición de la perspectiva • Definición de estándares • Definición de modelos de referencia • Evaluación del potencial de re-uso

5 Evaluación de la preparación para la transformación del negocio Para ello considerar:

• Factores de transformación • Visión de cada Factor de transformación • Actuales clasificaciones de transformación • Clasificaciones de la transformación objetivo • Riesgos de la transformación


ORIENTADO A LA UTPL

EA – UTPL - 154 - | P á g i n a

5.2.7.3 Plantilla para levantamiento de: Plan de comunicaciones

Plan de Comunicaciones


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de Contenidos 1 Propósito de este documento 2 Stakeholders 3 Requerimientos de Comunicación 4 Mecanismos de Comunicación 5 Horario de Comunicaciones Información del documento



Preparado por:


Título: Plan de Comunicaciones Fecha de Versión: Revisado por:

Fecha de Revisión:

Lista de distribución

De Fecha Teléfono/Fax/Email





ORIENTADO A LA UTPL

EA – UTPL - 155 - | P á g i n a

Nro. de Versión

Fecha de Versión


1. Propósito <<Este documento describe el plan de comunicaciones para el proyecto: Definición de un Framework de Arquitectura Empresarial EA-UTPL. Las arquitecturas empresariales contienen grandes volúmenes de compleja e interdependiente información. La comunicación efectiva de la información dirigida a los interesados correctos en el tiempo correcto, es un factor crítico de éxito para la arquitectura empresarial. Enterprise architectures contain large volumes of complex and inter-dependent information. El desarrollo de un Plan de Comunicaciones para la arquitectura, permite a su comunicación llevarse a cabo dentro de los procesos planificados y administrados.>> 2. Stakeholders

Nombre de Vista

Stakeholder

Interesado Patrocinador Preocupación ¿Quién será impactado por la arquitectura?

¿Quién deberá ser consultado sobre qué aspectos de la arquitectura? Descripción Existen dos tipos de stakeholders:

• Aquellos que pueden influenciar la actividad del negocio o proyecto • Aquellos que son impactadas por la actividad del negocio o proyecto

Los dos tipos de stakeholders deben ser direccionados separadamente, con cuidados y atenciones particulares, poniendo atención a cualquier stakeholder que pertenezca a ambos grupos. Un entendimiento de los beneficios del caso para los stakeholders es crucial para asegurar el éxito de un proyecto. Si un grupo de stakeholders existente cree que no se beneficiará, o en el peor de los casos que tendrá desventajas con el proyecto, entonces, deberán ser revisados: el alcance del proyecto, la misión, estrategia y objetivos de las unidades/proyecto.

Orientación Para un análisis de interesados los siguientes pasos son necesarios: • Definir todos los stakeholders relevantes • Evaluar la naturaleza de cada interés/preocupación de los stakeholders • Evaluar la influencia de cada stakeholder • Asignar las relaciones entre stakeholders • Asignar las coaliciones de los stakeholders • Construir una matriz de prioridades de stakeholders

Cuando se define stakeholders, la asignación de stakeholders (como representaciones virtuales de stakeholders y sus relaciones con la misión y estrategia) puede ser una herramienta vital. Durante un proyecto es importante monitorear los intereses de los stakeholders, sus relaciones y coalición.

ID-Referencia* Título* Descripción de interesado Preocupación


ORIENTADO A LA UTPL

EA – UTPL - 156 - | P á g i n a

3 Requisitos de Comunicación 3.1 Resumen

Requisito de Comunicación Notas << Requisito de Comunicación 1>> <<Notas>> << Requisito de Comunicación 2>> <<Notas>>

3.2 Enfoque de Gestión 3.3 Mecanismo de Comunicación Especificar para EA-UTPL:

• Eventos • Canales • Formatos • Contenido • Horario de Comunicación • Actividades Clave y Mitos Asociados • Duración, Esfuerzo y Recursos


ORIENTADO A LA UTPL

EA – UTPL - 157 - | P á g i n a

5.2.7.4 Plantilla para levantamiento de: Visión arquitectónica

Visión Arquitectónica


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de este documento 2 Principio de la Plantilla 3 Resumen de Principios 4 Principios del Negocio 5 Principios de Datos 6 Principios de Aplicación 7 Principios Tecnológicos Información del documento



Preparado por:


Título: Visión Arquitectónica Fecha de Versión: Revisado por:

Fecha de Revisión:

Lista de Distribución






ORIENTADO A LA UTPL

EA – UTPL - 158 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito La Visión Arquitectónica es creada temprano en el ciclo de vida del proyecto y provee una vista de aspiración de muy alto nivel para el final del producto arquitectónico. El propósito de la visión es agregar a los principios las salidas deseadas que deberán formar parte de la arquitectura, así los arquitectos podrán entonces concentrarse en las áreas críticas para validad la factibilidad. Proveer una Visión Arquitectónica también aporta a los interesados en la comunicación y prevé una versión del resumen ejecutivo con una definición completa de la Arquitectura. Puede ser que el documento de Visión Arquitectónica sea usado en una wiki o también en una intranet o en su defecto en un documento basado en texto. Incluso sería mucho mejor que se use una herramienta licenciada TOGAF para capturar ésta salida. Esta plantilla muestra el contenido “típico” de una Visión Arquitectónica y puede ser adaptado para alinearse con cualquier adaptación TOGAF que esté siendo implantada. 2 Descripción del problema 2.1 Interesados y sus expectativas <<El propósito de esta sección es describir a los interesados la visión junto con cualquier preocupación que ellos puedan tener Obligatoria/opcional: Esta sección es obligatoria En términos de criterios de calidad, esta sección debe dejar claro: a. Cualquier preocupación de los interesados acerca del negocio b. Cualquier preocupación de los interesados acerca de los ejercicios que están siendo realizados. >> 2.2 Lista de asuntos/escenarios a ser direccionados <<El propósito de ésta sección es definir el contexto del negocio y la descripción de los problemas para los cuales la visión es el objetivo de la arquitectura que será producida. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Declaraciones de visión del negocio para la arquitectura objetivo b. Representación pictórica del contexto del negocio c. Cambio de dirección y oportunidades detrás de esta visión para la arquitectura objetivo >> 2.3 Declaraciones de visión del negocio


ORIENTADO A LA UTPL

EA – UTPL - 159 - | P á g i n a

<<El propósito de ésta sección es definir las declaraciones de visión del negocio para la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro:

a. Declaración(es) de Visión para la arquitectura objetivo >>

2.4 Diagrama de visión del negocio <<El propósito de ésta sección es prever una o más representaciones pictóricas apropiadas que expliquen el contexto y problemas del negocio. Son requeridas estas actividades para obtener compromiso de los ejecutivos senior. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Diagrama(s) explicando las declaraciones de los problemas para la arquitectura objetivo b. Descripción de los diagramas de visión del negocio >> 2.5 Cambios de dirección y oportunidades <<El propósito de ésta sección es identificar el cambio de dirección y oportunidades detrás de la visión para la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Cambios de dirección que puedan impactar en las decisiones tomadas para la arquitectura objetivo b. Oportunidades que pueden ser apalancadas para la arquitectura objetivo >> 3 Objetivos detallados <<El propósito de ésta sección es describir los objetivos detallados que se necesitan para cumplir con la arquitectura objetivo. La sección previa mira hacia el problema del negocio, mientras que ésta sección determina los objetivos, para la solución arquitectónica, para la solución arquitectónica, que resolverá el problema del negocio. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro:

a. Objetivos del negocio para resolver su problema b. Objetivos tecnológicos, tales como el desarme>>

4 Ambiente y modelos de proceso <<El propósito de ésta sección es esbozar el ambiente y los modelos de procesos que están en el alcance de la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Procesos del negocio que están en el alcance de la visión b. Negocio y ambiente tecnológico en el alcance de la visión


ORIENTADO A LA UTPL

EA – UTPL - 160 - | P á g i n a

c. Usuarios que interactúan con el proceso de negocio d. Flujos de información para los proceso del negocio >> 4.1 Descripción de procesos <<El propósito de ésta sección es esbozar los procesos del negocio que están en el alcance y por ende serán impactados por la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Procesos del negocio que están en el alcance de la visión b. Si son requeridos, diagramas de alto nivel de los procesos del negocio c. Descripción de los diagramas de los procesos del negocio >> 4.2 Etapas de Procesos asignados al entorno <<El propósito de ésta sección es crear una referencia cruzada de los procesos de negocio, en el alcance, para el negocio y el entorno tecnológico. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Entorno de negocio en el alcance de la visión b. Entorno tecnológico en el alcance de la visión >> 4.3 Etapas de procesos asignados a la gente <<El propósito de esta sección es crear una referencia cruzada entre los procesos del negocio y los actores del negocio, por ejemplo: usuarios del negocio, Los actores/usuarios del negocio son esos usuarios que interactúan con los procesos del negocio. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro:

a. Usuarios del negocio involucrados con los procesos del negocio en el alcance >>

4.4 Flujo de la información <<El propósito de ésta sección es describir los flujos de información que corresponden a los procesos del negocio en el alcance de la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro:

a. Flujos de información para los procesos del negocio en el alcance >>

5 Actores y sus roles y responsabilidades <<El propósito de esta sección es describir los actores/usuarios del sistema en el alcance de la arquitectura objetivo. Los actores/usuarios del sistema son todos los usuarios que interactúan con el sistema. Pueden ser humanos o un sistema/equipo de cómputo.


ORIENTADO A LA UTPL

EA – UTPL - 161 - | P á g i n a

Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Humano (sistema) actores y roles en el alcance de la arquitectura objetivo. b. Equipo de Computo (sistema) actores y roles en el alcance de la arquitectura objetivo. c. Cualquier sistema orientado a las necesidades de actores en el alcance de la arquitectura objetivo >> 5.1 Actores humanos y roles <<El propósito de estas sección es definir a los actores humanos y sus roles en el alcance de la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro:

a. Actores humanos y sus roles en el alcance de la arquitectura objetivo >>

5.2 Actores computacionales y roles <<El propósito de ésta sección es definir los actores computacionales y sus roles en el alcance de la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro:

a. Actores computacionales y sus roles en la arquitectura objetivo>>

5.3 Requerimientos <<El propósito de esta sección es definir cualquier otro requerimiento orientado a los actores en el alcance del proyecto. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro:

a. Cualquier otro requerimiento orientado a los actores en el alcance de la arquitectura objetivo>>

5.4 Modelo de arquitectura resultante 6 Modelo de arquitectura resultante <<El propósito de ésta sección es describir la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Diagrama(s) de alto nivel de la arquitectura objetivo b. Descripción de diagrama(s) c. Requerimientos para ubicarlos en la arquitectura objetivo d. Restricción que impactan la arquitectura objetivo e. Principios que pueden ser apalancados con el objeto de definir la arquitectura>>


ORIENTADO A LA UTPL

EA – UTPL - 162 - | P á g i n a

6.1 Restricciones <<El propósito de esta sección es describir las restricciones que impactan la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria si la restricción necesitan ser tomadas en consideración En términos de criterios de calidad, esta sección debe dejar claro:

a. Restricciones que impactan la arquitectura objetivo>>

6.2 Principios de IT <<El propósito de esta sección es describir los principios que pueden ser apalancados para definir la arquitectura objetivo. Obligatorio/opcional: Esta sección es obligatoria si existen principios que necesitan ser tomados en consideración. En términos de criterios de calidad, esta sección debe dejar claro:

a. Los principios que pueden ser apalancados para definir la arquitectura objetivo >>

6.3 Procesos de apoyo arquitectónico <<El objetivo de estas sección es describir la arquitectura. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Diagrama(s) de alto nivel de la arquitectura objetivo b. Descripción de los diagramas>> 6.4 Requerimientos asignados a la arquitectura <<El propósito de esta sección es describir los requerimientos de negocio y tecnologías a alto nivel para asignarlos en la arquitectura objetivo. Obligatoria/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección debe dejar claro: a. Requerimientos existentes del negocio como metas y objetivos para asignarlos a la arquitectura objetivo b. Requerimientos tecnológicos existentes para asignarlos a la arquitectura objetivo>> 7 Declaraciones finales de visión <<Un resumen ejecutivo de la declaración final del esfuerzo arquitectónico.>>


ORIENTADO A LA UTPL

EA – UTPL - 163 - | P á g i n a

5.3 Fase B: Arquitectura de Negocio

FasePreliminar


de Información

Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica


Fase B:ArquitecturaDe negocio

El conocimiento de la arquitectura de negocio es un requisito previo para realizar el trabajo arquitectónico en cualquier otro dominio (datos, aplicaciones, tecnología), por consiguiente esta es la primera arquitectura que debe llevarse a cabo obligatoriamente.

Define la estrategia de negocios, la gobernabilidad, la estructura y los procesos clave de la organización, por lo que es necesaria como medio para demostrar el valor comercial del trabajo arquitectónico subsecuente a los principales stakeholders, así como el retorno de la inversión a aquellos stakeholders para que esta contribuya a apoyar y participar en los trabajos posteriores. 5.3.1. Objetivos

• Describir la línea base de la arquitectura de negocio. • Desarrollar una arquitectura empresarial objetivo, describiendo la estrategia del producto y/o

servicio, así como la organización, funcionalidad, procesos, información y aspectos geográficos del entorno de negocio institucional. Para ello se basa en los principios, objetivos y conductores de negocio estratégicos.

• Analizar las diferencias entre la línea de base y arquitectura objetivo de negocio.


ORIENTADO A LA UTPL

EA – UTPL - 164 - | P á g i n a

• Seleccionar y desarrollar los puntos de vista relevantes de arquitectura que permitan al arquitecto demostrar cómo las expectativas de los stakeholders se abordan en la arquitectura de negocios.

• Seleccionar las herramientas y técnicas relevantes para ser utilizadas en asociación con los puntos de vista seleccionados.

5.3.2 Enfoque

El alcance del trabajo arquitectónico en la fase B depende del ambiente de la institución, teniendo como premisa el tratar de reutilizar materiales existentes en la medida de lo posible. A lo anterior contribuye el recopilar y analizar sólo la información que aporte a decisiones informadas, que sean relevantes y guarden relación con el alcance arquitectónico.

Puede ser necesario verificar y actualizar la actual estrategia de negocio documentada así como los planes asociados a esta. Para lograrlo, es necesario ir estableciendo una medición de brechas hecha en base a los conductores de alto nivel, así como mediciones de estrategias, requerimientos y objetivos de negocio que sean relevantes.

Si la institución tiene descripciones de una arquitectura existente (este no es el caso), esta se deberá utilizar como base para la descripción de línea de base. De no haber descripciones, la información deberá ser recopilada y levantada desde donde sea necesario (incluso desde cero). Mas cabe aclarar que la visión arquitectónica de la fase A puede ser a menudo suficiente para lograr una descripción racional de la línea base.

5.3.3 Modelado de negocio

Los modelos de negocio deben ser extensiones lógicas de los escenarios de negocio de la visión arquitectónica, por lo tanto la arquitectura de negocio en si puede ser asignada desde los requisitos empresariales de alto nivel hasta los más detallados. Para brindar soporte a lo anterior existen algunas técnicas y herramientas de modelado:

• Modelos de actividades (modelos de proceso de negocio): describen las funciones asociadas con las actividades de negocio de la institución, los datos y/o la información intercambiada entre las actividades (intercambios internos), y los datos y/o la información intercambiada con otras actividades que están fuera del ámbito de aplicación del modelo (intercambios con el exterior).

• Modelos de casos de uso (de negocio): describen los procesos de negocio de la institución en términos de casos de uso, así como los actores correspondientes a los procesos de negocio y los participantes en dicha institución (personas, otras instituciones, etc.)

• Modelos de clase: describen información estática y las relaciones entre la información y los comportamientos informativos.


ORIENTADO A LA UTPL

EA – UTPL - 165 - | P á g i n a

• Diagramas de conectividad de nodos: describen las ubicaciones (locaciones) del negocio (nodos), las líneas de relación entre ellas, y las características de la información intercambiada vista desde tres niveles: conceptual, lógico y físico.

• Matriz de intercambio de información: Documenta los requisitos de intercambio de información para una EA y expresa las relaciones a través de tres entidades básicas (actividades, nodos de negocio y sus elementos, y el flujo de información), y se centran en las características del intercambio de información, tales como el rendimiento y la seguridad.

5.3.4 Repositorio arquitectónico

Considera que recursos relevantes de la arquitectura de negocio se encuentran disponibles para el uso en el trabajo arquitectónico. Abarca usualmente:

• Los modelos genéricos de negocios de interés para el sector industrial de la institución. • Modelos de negocio comunes, de interés para los dominios de alto nivel del negocio. • Bloques constitutivos útiles para la EA específicos de la institución (componentes de proceso,

reglas de negocio, descripción de trabajadores y roles, etc.) • Estándares aplicables.

Al tener como recurso operativo una capacidad arquitectónica madura dentro de la institución,

se puede crear un gran volumen de producción arquitectónica. La gestión eficaz y el apalancamiento de estos productos de trabajo arquitectónico requieren una estructura formal para diferentes tipos de activos arquitectónicos.

Visto desde un alto nivel, seis clases de información arquitectónica deben ser almacenadas en el repositorio arquitectónico:

• Meta modelo arquitectónico. • Perspectiva arquitectónica. • Estándares base de la Información. • Biblioteca de referencia. • Registro de gobernanza.


ORIENTADO A LA UTPL

EA – UTPL - 166 - | P á g i n a

Figura 20: Esquema de repositorio arquitectónico [1]

5.3.5 Entradas

• Materiales de referencia externos a la institución. 5.3.5.1 No arquitectónicas

• Solicitud de trabajo arquitectónico. • Principios, objetivos y conductores de negocio. • Evaluación de la capacidad. • Plan de comunicaciones.

5.3.5.2 Arquitectónicas

• Modelo organizacional para la EA. o Ámbito de aplicación de unidades de negocio afectadas. o Evaluación de madurez, de brechas, y el enfoque de resolución. o Funciones y responsabilidades para el equipo arquitectónico. o Restricciones sobre el trabajo arquitectónico. o Requisitos de presupuesto. o Gobernanza y estrategia de apoyo.


ORIENTADO A LA UTPL

EA – UTPL - 167 - | P á g i n a

• Framework arquitectónico adaptado o Método arquitectónico adaptado. o Contenido arquitectónico adaptado (entregables y artefactos). o Herramientas configuradas y desplegadas.

• Estatuto aprobado de trabajo arquitectónico. • Principios arquitectónicos incluyendo principios de negocio ( si hay preexistentes) • Continuum arquitectónico. • Repositorio arquitectónico.

o Bloques constitutivos reusables. o Modelos de referencia públicamente disponibles. o Modelos de referencia específicos de la institución. o Estándares manejados en la institución.

• Visión arquitectónica o Requerimientos clave de alto nivel de stakeholders. o Línea base de arquitectura de negocio. o Línea base de arquitectura de tecnología. o Línea base de arquitectura de datos. o Línea base de arquitectura de aplicaciones. o Arquitectura de negocio objetivo. o Arquitectura de tecnología objetivo. o Arquitectura de datos objetivo. o Arquitectura de aplicaciones objetivo.

5.3.6 Salidas

• Versiones actualizadas y refinadas de los entregables de fase de visión arquitectónica. o Estatuto de trabajo arquitectónico. o Principios, objetivos y conductores de negocio validados. o Principios arquitectónicos.

• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de negocio. o Arquitectura de negocio objetivo.

Estructura institucional: identificación de lugares de negocio y que se refieran a las unidades de negocio.

Metas y objetivos de negocio, para la institución y cada unidad de negocio. Funciones de negocio: pasos detallados y recursivos que participan en la

descomposición sucesiva de las principales áreas funcionales en sub-funciones.

Servicios de negocio: los que la institución y cada unidad de ella proporcionan a sus clientes (estudiantes), tanto interna como externamente.

Procesos de negocio, incluidas las medidas y los resultados finales.


ORIENTADO A LA UTPL

EA – UTPL - 168 - | P á g i n a

Roles de negocio, incluyendo el desarrollo y la modificación de los requisitos de habilidades.

Modelo de datos de negocio. La correlación de la institución y sus funciones: relaciona las funciones de

negocio a las unidades de negocio en la forma de un informe de matriz. o Borrador de especificación de requisitos arquitectónicos.

Resultados de análisis de brechas. Requisitos técnicos. Actualización requisitos de negocio.

o Componentes arquitectónicos de negocio de un plan de actuación de EA.


ORIENTADO A LA UTPL

EA – UTPL - 169 - | P á g i n a

5.3.7 Definición del proceso de arquitectura de negocio Definición de Procesos Proceso: FB – ArquitecturaNegocio: Levantamiento de la

arquitectura de negocio. Cod.Doc FB –

ArquitecturaNegocioX Responsable: CIO, DGTI, ADS, DEA, ADD, DTE, CSI Versión: 1.0 Mantenimiento: DGTI, ADS, CSI Estado: Borrador

Publicado X

Descripción: Es el proceso mediante el cual se describe la arquitectura de negocio en busca de demostrar valor comercial para el trabajo arquitectónico. También muestra como retornar la inversión inmersa en el proyecto EA-UTPL.

Alcance: El proceso de la fase de arquitectura de negocio, contempla los siguientes procedimientos:

• Modelar el negocio. • Levantar la línea base de la arquitectura de negocio. • Afianzar los principios de negocio. • Delimitar el trabajo arquitectónico. • Definir limitaciones de negocio. • Reutilizar materiales de negocio. • Afianzar las estrategias de negocio. • Fortalecer la línea base arquitectónica.


No aplica




En este documento se usan las siguientes abreviaciones y acrónimos: • ADS: Arquitectos de soluciones • ADD : Arquitectos de dominio • DTE: Director de tecnologías emergentes • DGTI: Director de gobernanza de TI. • DEA: Director del proyecto EA (Líder). • CIO: Chief Information Officer (Director ejecutivo) • CSI: Coordinador de servicios de investigación.

Listado de Cambios



Descripción

1.0 26/10/2010 DGTI, ADS, DEA, ADD, DTE, CSI




• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar la

• Informar sobre la arquitectura de negocio establecida y brindar soporte a los otros tres


ORIENTADO A LA UTPL

EA – UTPL - 170 - | P á g i n a

arquitectura de negocio. dominios arquitectónicos. Entradas:

Salidas:

• Materiales de referencia externos a la institución.


negocio. • Evaluación de la capacidad. • Plan de comunicaciones. • Modelo organizacional para la EA. • Framework arquitectónico adaptado • Estatuto aprobado de trabajo arquitectónico. • Principios arquitectónicos incluyendo

principios de negocio. • Continuum arquitectónico. • Repositorio arquitectónico.

• Visión arquitectónica

• Versiones actualizadas y refinadas de los entregables de fase de visión arquitectónica.

• Borrador del documento de definición de la arquitectura.

o Línea base de arquitectura de negocio.

o Arquitectura de negocio objetivo. o Borrador de especificación de

requisitos arquitectónicos. o Componentes arquitectónicos de

negocio de un plan de actuación de EA.

Roles:

• ADS: Originar la arquitectura de negocio. • ADD: Originar la arquitectura de negocio. • DEA: Integrar resultados. • DGTI: Dar soporte al proceso. • DTE: Brindar soporte para herramientas y metodologías de modelado de negocio. • CSI: Estudiar y analizar la línea base de negocio en base a metodologías formales adaptables a la

dimensión de negocio.


• Modelo Organizacional. • Framework arquitectónico candidato. • Principios arquitectónicos. • Estrategias, planes de negocio, políticas y marco jurídico. • Repositorio arquitectónico inicial. • Línea base arquitectónica.

Tareas:

1. Seleccionar los modelos de referencia, puntos de vista y herramientas. 2. Desarrollar la descripción de la línea base de arquitectura de negocio. 3. Desarrollar la descripción arquitectura de negocio objetivo. 4. Realizar análisis de brechas. 5. Definir los componentes del plan de actuación. 6. Resolver los impactos a través de la perspectiva arquitectónica. 7. Revisar la conducta oficial de stakeholders. 8. Concluir la arquitectura de negocio. 9. Crear un documento de definición de la arquitectura.

Métricas:


ORIENTADO A LA UTPL

EA – UTPL - 171 - | P á g i n a

• Valor comercial y retorno de inversión. B. Definición Detallada del Proceso

Levantamiento de la arquitectura de negocio. Objetivos del Procedimiento:

• Describir la línea base de la arquitectura de negocio. • Desarrollar una arquitectura empresarial objetivo, describiendo la

estrategia del producto y/o servicio, así como la organización, funcionalidad, procesos, información y aspectos geográficos del entorno de negocio institucional. Para ello se basa en los principios, objetivos y conductores de negocio estratégicos.

• Analizar las diferencias entre la línea de base y arquitectura objetivo de negocio.

• Seleccionar y desarrollar los puntos de vista relevantes de arquitectura que permitan al arquitecto demostrar cómo las expectativas de los stakeholders se abordan en la arquitectura de negocios.

• Seleccionar las herramientas y técnicas relevantes para ser utilizadas en asociación con los puntos de vista seleccionados.



• ADS: Brindar una línea base de negocio y establecer una arquitectura de negocio objetivo.

• ADD: Brindar una línea base de negocio y establecer una arquitectura de negocio objetivo.

• DEA: Integrar resultados. • DGTI: Dar soporte al proceso. • DTE: Brindar soporte para herramientas y metodologías de

modelado de negocio. • CSI: Estudiar y analizar la línea base de negocio en base a

metodologías formales adaptables a la dimensión de negocio. Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a

continuación:

• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar la arquitectura de negocio.

Entradas: • Materiales de referencia externos a la institución. • Solicitud de trabajo arquitectónico. • Principios, objetivos y conductores de negocio. • Evaluación de la capacidad. • Plan de Comunicaciones. • Modelo organizacional para la EA.

o Ámbito de aplicación de unidades de negocio afectadas. o Evaluación de madurez, de brechas, y el enfoque de

resolución. o Funciones y responsabilidades para el equipo

arquitectónico. o Restricciones sobre el trabajo arquitectónico. o Requisitos de presupuesto.


ORIENTADO A LA UTPL

EA – UTPL - 172 - | P á g i n a

o Gobernanza y estrategia de apoyo. • Framework arquitectónico adaptado

o Método arquitectónico adaptado. o Contenido arquitectónico adaptado (entregables y


• Estatuto aprobado de trabajo arquitectónico. • Principios arquitectónicos incluyendo principios de negocio ( si hay

preexistentes) • Continuum arquitectónico. • Repositorio arquitectónico.

o Bloques constitutivos reusables. o Modelos de referencia públicamente disponibles. o Modelos de referencia específicos de la institución. o Estándares manejados en la institución.

• Visión arquitectónica o Requerimientos clave de alto nivel de stakeholders. o Línea base de arquitectura de negocio. o Línea base de arquitectura de tecnología. o Línea base de arquitectura de datos. o Línea base de arquitectura de aplicaciones. o Arquitectura de negocio objetivo. o Arquitectura de tecnología objetivo. o Arquitectura de datos objetivo. o Arquitectura de aplicaciones objetivo.



1. Seleccionar los modelos de referencia, puntos de vista y herramientas.

• Seleccionar recursos relevantes de la arquitectura de negocio

(modelos de referencia, patrones, etc.) desde el repositorio arquitectónico, tomando como base de los conductores del negocio, los stakeholders y sus expectativas.

• Seleccionar los puntos de vista relevantes de la arquitectura de negocio (por ejemplo: operaciones, gestión, financiero), es decir, los que le permitirán al arquitecto a demostrar cómo la expectativas de los stakeholders se están abordando en la arquitectura de negocio.

• Identificar herramientas y técnicas adecuadas a ser utilizadas para la captura, el modelado y análisis.

• Determinar el modelado general de procesos. o Para cada punto de vista, seleccionar los modelos

necesarios para apoyar el punto de vista específico, utilizando la herramienta o método seleccionados.

o Asegurarse que todas las expectativas de los stakeholders están cubiertas.

o Identificar las funciones clave de negocio en el ámbito de la arquitectura, y asignaciones de las funciones en las


ORIENTADO A LA UTPL

EA – UTPL - 173 - | P á g i n a

unidades de negocio dentro de la institución. o Desglosar las funciones de nivel de negocio a través de

agentes y unidades de negocio para permitir que los actores sean identificados en una función.

o Desglosar una función o servicio de negocio a través del modelado de procesos para permitir a los elementos del proceso ser identificados, así como permitir la identificación de servicios o funciones de negocio de menor nivel.

a. De igual manera se debe identificar el nivel de granulidad de

servicios requeridos, límites, y contratos. Para ello es necesario:

• Identificar qué componentes de la arquitectura son funciones y cuáles son servicios:

o Los servicios de negocio son funciones específicas que tienen límites explícitos y definidos, que se rigen de manera explícita.

o Los servicios se distinguen de las funciones a través de la definición explícita de un contrato de servicio.

o Un contrato de servicio cubre la interfaz funcional / de negocio y también l la interfaz de datos / tecnología.

• La arquitectura de negocio definirá en contrato de servicios a nivel funcional / de negocios, el cual será expandido en las fases de arquitectura de aplicaciones y tecnología.

• La granularidad de los servicios de negocio se determinará de conformidad a los conductores de negocios, metas, objetivos y medidas para esta área del negocio.

b. También se debe Identificar los catálogos requeridos de bloques

constitutivos de negocio. Dichos catálogos son:

• Catálogos de captura de inventarios, de los principales activos del negocio.

• Catálogos que van desde la materia prima, sirven para el desarrollo de matrices y puntos de vista, así también estos actúan como un recurso clave para la gestión de portafolio de negocios y la capacidad de TI.

• Se debe tener en consideración el desarrollo de todos o algunos de los siguientes catálogos:

o Catálogo de institución y actores. o Catálogo de conductores, metas y objetivos. o Catálogo de roles. o Catálogo de servicios y funciones de negocio. o Catálogo de ubicación. o Catálogo de procesos, eventos, control y productos o Catálogo de contratos y medidas.

c. Subsecuentemente se debe identificar las matrices requeridas.


ORIENTADO A LA UTPL

EA – UTPL - 174 - | P á g i n a

• Hay que considerar que las matrices muestran las relaciones clave

entre las entidades afines al modelo y constituyen la materia prima para el desarrollo de puntos de vista, así como también actúan como recursos clave para la evaluación de impacto, efectuada como parte del análisis de brechas. Se distinguen dos grandes tipos:

o Matriz de interacción de negocio: muestra la dependencia y la comunicación entre las unidades de negocio y sus actores.

o Matriz de actores y roles: muestra las funciones realizadas por cada actor.

d. El siguiente paso es identificar los diagramas requeridos, para ello

hay que tener claro que un diagrama representa la información de la arquitectura de negocio desde un conjunto de perspectivas diferentes de acuerdo a los requerimientos de los stakeholders. Los diagramas de mayor uso y difusión son:

• Diagrama traza (huella) de negocio. • Diagrama de servicios y/o información de negocio. • Diagrama de descomposición funcional. • Diagrama de meta, objetivo, servicio. • Diagrama de casos de uso. • Diagrama de descomposición de la institución. • Diagrama de flujo de procesos. • Diagrama de eventos.

e. Finalmente se debe identificar los tipos de requerimientos que serán

capturados. Una vez que hayan sido desarrollados los catálogos, las matrices y diagramas de la arquitectura de negocio, el modelado arquitectónico estará completo al formalizar los requerimientos enfocados en el negocio, con ello se podrá implementar la arquitectura objetivo de esta capa.

Cabe especificar que los requisitos deben relatar el dominio de negocio, o deben proveer requisitos de entrada en la arquitectura de datos, de aplicación y de tecnología. Los tipos abarcan:

• Requerimientos funcionales. • Requerimientos no funcionales. • Supuestos. • Restricciones. • Principios arquitectónicos de dominio específico de negocio. • Políticas. • Estándares. • Directrices. • Especificaciones.


ORIENTADO A LA UTPL

EA – UTPL - 175 - | P á g i n a

2. Desarrollar la descripción de la línea base de arquitectura de negocio.

Este desarrollo debe hacerse en la medida necesaria para apoyar la meta de la EA. El ámbito de aplicación y nivel de detalle que se definan dependerán del grado en que los elementos existentes de negocio, tengan probabilidad de ser transferidos a la arquitectura de negocio objetivo.

3. Desarrollar la descripción arquitectura de negocio objetivo. Debe darse en la medida necesaria para apoyar la visión arquitectónica. El ámbito de aplicación y nivel de detalle a definir dependerá de la relevancia de los elementos de negocio para alcanzar la visión arquitectónica objetivo.

4. Realizar análisis de brechas.

• Verificar los modelos de arquitectura para tener coherencia interna y precisión.

• Realizar un análisis de negocio para resolver conflictos (si existen) entre los puntos de vista diferentes.

• Validar que los modelos den apoyo a los principios, objetivos y restricciones.

• Probar modelos arquitectónicos para lograr integridad con los requisitos.

• Identificar las diferencias entre las arquitecturas línea de base y objetivo.

5. Definir los componentes del plan de actuación.

Crear un esquema empresarial formalizado en un plan de actuación sirve para dar prioridad a las actividades sobre las próximas fases. El plan de actuación inicial de la arquitectura de negocio se utilizará como materia prima para apoyar la definición más detallada de un plan de actuación consolidado e interdisciplinario dentro de la fase de oportunidades y soluciones.

6. Resolver los impactos a través de la perspectiva arquitectónica. Implica comprender los impactos más amplios o las implicaciones de la arquitectura de negocios propuesta. Para ello es necesario plantear algunas interrogantes:

• ¿Esta arquitectura de negocios crea un impacto en cualquier arquitectura preexistente?

• ¿Los cambios recientes han hecho que la arquitectura de negocio se vea impactada?

• ¿Hay oportunidades para aprovechar el trabajar desde esta arquitectura de negocio en otras áreas de la organización?

• ¿Tiene la arquitectura de negocio impacto sobre otros proyectos


ORIENTADO A LA UTPL

EA – UTPL - 176 - | P á g i n a

(incluyendo las planeadas, así como los actualmente en curso)? • ¿Esta arquitectura de negocio se verá afectada por otros proyectos

(incluyendo los planeados, así como los actualmente en curso)?

7. Revisar la conducta oficial de stakeholders. Se debe comprobar la motivación original para el proyecto arquitectónico y el estatuto de trabajo arquitectónico contra la arquitectura de negocio propuesta. Debe responderse la interrogante, ¿es apto el resultado arquitectónico actual para el propósito de apoyar al trabajo posterior en otros dominios arquitectónicos?

8. Concluir la arquitectura de negocio.

• Seleccionar estándares para cada uno de los bloques constitutivos, re-usándolos en la medida de lo posible desde modelos de referencia tomados desde el repositorio arquitectónico.

• Documentar cada bloque constitutivo. • Conducir la última validación cruzada de la arquitectura en general

con los objetivos de negocio. • Documentar razones para la construcción de bloques constitutivos

en el documento arquitectónico. • Documentar un informe final trazabilidad de los requisitos. • Documentar la asignación final de la arquitectura dentro del

repositorio arquitectónico y publicarlo vía ese medio. • Completar todos los productos de trabajo, como los resultados de

análisis de brechas.

9. Crear un documento de definición de la arquitectura.

Se debe documentar las razones para la decisión de existencia de bloques constitutivos en el documento de definición de la arquitectura. De la mano es necesario preparar las secciones de negocio del documento de definición. Se deben considerar los aspectos:

• Una traza de negocio (una descripción de alto nivel de la gente y los lugares involucrados en las funciones clave de negocio).

• Una descripción detallada de las funciones de negocio y sus necesidades de información.

• Una traza de gestión (período de exhibición de control y rendición de cuentas).

• Estándares, reglas y directrices que muestren prácticas de trabajo, legislación, medidas financieras, etc.

• Una matriz de competencias y un conjunto de descripciones de trabajos (roles).

Salidas: • Versiones actualizadas y refinadas de los entregables de fase de visión arquitectónica.

o Estatuto de trabajo arquitectónico.


ORIENTADO A LA UTPL

EA – UTPL - 177 - | P á g i n a

o Principios, objetivos y conductores de negocio validados. o Principios arquitectónicos.

• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de negocio. o Arquitectura de negocio objetivo.

Estructura institucional: identificación de lugares de negocio y que se refieran a las unidades de negocio.

Metas y objetivos de negocio, para la institución y cada unidad de negocio.

Funciones de negocio: pasos detallados y recursivos que participan en la descomposición sucesiva de las principales áreas funcionales en sub-funciones.

Servicios de negocio: los que la institución y cada unidad de ella proporcionan a sus clientes, tanto interna como externamente.

Procesos de negocio, incluidas las medidas y los resultados finales.

Roles de negocio, incluyendo el desarrollo y la modificación de los requisitos de habilidades.

Modelo de datos de negocio. La correlación de la organización y funciones:

relaciona las funciones de negocio a las unidades de negocio en la forma de un informe de matriz.

o Borrador de especificación de requisitos arquitectónicos. Resultados de análisis de brechas. Requisitos técnicos. Actualización requisitos de negocio.

o Componentes arquitectónicos de negocio de un plan de actuación de EA.

Criterios de Salida: Los criterios de salida para este procedimiento se listan a continuación:

• Informar sobre la arquitectura de negocio establecida y brindar soporte a los otros tres dominios arquitectónicos.


• Medición del valor comercial para la adopción del enfoque. • Estimación del retorno de la inversión.


ORIENTADO A LA UTPL

EA – UTPL - 178 - | P á g i n a

5.3.8 Plantillas para la fase de arquitectura de negocio 5.3.8.1 Plantilla para levantamiento de: Especificación de requisitos arquitectónicos

Especificación de Requisitos Arquitectónicos


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propóstito de este documento 2 Requisitos arquitectónicos 3 Contrato de servicios 4 Implementación Información del documento



Preparado por:


Título: Especificación de Requisitos de la Arquitectura

Fecha de Versión:

Revisado por:

Fecha de Revisión:







ORIENTADO A LA UTPL

EA – UTPL - 179 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito Este documento busca especificar los requisitos necesarios para la arquitectura, provee un conjunto de declaraciones cuantitativas que esbozan lo que el proyecto de implementación de EA-UTPL debería hacer para cumplir con la arquitectura. Una Especificación de Requisitos de la Arquitectura será típicamente un componente mayor para un contrato de implementación o contrato a más detalle de la Definición Arquitectónica. Como se mencionó anteriormente, La especificación de requerimientos de la arquitectura es un acompañante para el Documento de Definición Arquitectónica con un objetivo complementario: El Documento de Definición Arquitectónica provee una visión cualitativa de la solución y tiene como objetivo comunicar las intenciones del arquitecto. 2 Requisitos arquitectónicos La Especificación de Requerimientos de la Arquitectura provee una visión cualitativa de la solución, empezando con un criterio medible que debe ser conocido durante la implementación de la misma. Si bien esta sección debe mencionar la estructura de los requisitos, en el punto 2.1 se deben listar los más relevantes (principalmente los enfocados al negocio) 2.1 Requisitos arquitectónicos En esta sección se deben especificar los requisitos capturados en la plantilla de Excel (cuya estructura se menciona en el Anexo 2.2). Se propone seguir el esquema de los catálogos:

2.2 Requisitos de interoperabilidad En esta sección deben listar los requisitos de interoperabilidad, usando el mismo esquema de la sección 2.1 para la arquitectura, teniendo en cuenta que: Los principios de interoperabilidad definen la manera en como la arquitectura interactuará con otras arquitecturas y componentes (sistemas) de la UTPL.

Mapa de Requisitos

Requisito Stakeholder Nombre Clase Nivel de interés Expectativas RQS_01 STK_01 RQS_02 STK _02 RQS_nN STK _nN


ORIENTADO A LA UTPL

EA – UTPL - 180 - | P á g i n a

2.3 Restricciones Son varios tipos de limitantes que podrían darse para lograr consolidar un adecuado levantamiento de requisitos arquitectónicos 2.3.1 Restricciones organizacionales Son tipos de valor que requieren el ceñirse estrictamente a los lineamientos organizacionales para asegurar el buen funcionamiento de la UTPL. Por ejemplo, el “Cumplimiento” es el tipo de valor central usual.

2.3.2 Información presupuestaria y restricciones financieras El financiamiento debería ser considerado en dos niveles:

• A corto plazo: ¿Cuánto presupuesto está disponible para apoyar inmediatamente al equipo en la creación de los productos del trabajo arquitectónico? (puede ser en $ o en número de días). ¿De qué fuente éste presupuesto será provisto?

• A largo plazo: ¿Qué nivel aproximado de recursos y presupuesto están disponibles para la implementación definitiva de la arquitectura que se propone?

Se debe tener en cuenta que en este estado (1) se debe abordar, mientras (2) se puede considerar/indicar donde sea posible. 2.3.3 Restricciones externas y del negocio Se debe establecer si existen otras restricciones; por ejemplo: ¿recursos a ser usados, dependencias externas, regulaciones específicas, etc.? 2.3.4 Tabla de Restricciones Formaliza en una matriz los tipos de restricciones descritas con anterioridad. Para ello se propone seguir el esquema siguiente: (los ejemplos son generales e hipotéticos)

ID Tipo Nombre Descripción Severidad

Probabilidad Mitigación

1. 001_UGTI

Organizacional

Confidencialidad por niveles

Aéreas afines no tienen permiso para conocer determinada información. Esto llevará a que los requisitos capturados sean inconsistentes

Grave Baja

Consolidar el levantamiento de requisitos por reuniones para todas las áreas que deberían tener acceso a la misma información.

2. 002_UGTI

Presupuestaria

Fala de recursos

Debido a un presupuesto demasiado bajo se deberán obviar áreas y

Grave Alta

Hacer un estudio inicial de stakeholders


ORIENTADO A LA UTPL

EA – UTPL - 181 - | P á g i n a

stakeholders “no-claves” para levantar la EA.

clave.

3. 003_UGTI Externa

Desconocimiento del medio ambiente

Desconocimiento de regulaciones nuevas o renuncia de stakeholders clave.

Grave Baja

Encargar un estudio del ambiente a miembros del equipo EA.

2.4 Asunciones La siguiente tabla resume las asunciones para los requisitos:

ID Supuesto Impacto Propietario 1.

2.5 Medidas de éxito <<Delimitar qué métricas de desempeño se utilizarán utilizando el esquema propuesto>> En suma, las siguientes métricas serán usadas para determinar el éxito de este trabajo arquitectónico

Métrica Técnica de Medición Valor Objetivo Justificación/Más notas

3 Contratos de Servicios Esta sección debe especificar una lista de servicios contratados a vendedores externos, o los subcontratados dentro de la institución, para ello se propone seguir el esquema:

ID Nombre de Servicio

Tipo Propietario Descripción

1. 4 Implementación Esta sección debe listar y describir de manera concisa las acciones clave que servirán para poder cumplir con todos los requisitos arquitectónicos. Esta será una base que luego será utilizada en el plan de actuación (Roadmap). Para dicho levantamiento se recomienda especificar:

• Directrices de implementación: Los lineamientos para llegar una implementación sólida de los requisitos. • Especificaciones de implementación: El detalle de cómo se buscará consolidar dicha implementación. • Estándares de implementación: Los estándares formales usados para ella o el procedimiento creado a

medida.


ORIENTADO A LA UTPL

EA – UTPL - 182 - | P á g i n a

5.3.8.2 Plantilla para levantamiento de: Plan de actuación (Roadmap) para la arquitectura

Plan de actuación para la Arquitectura


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de este documento 2 Lista del proyecto 3 Plan de migración orientado al tiempo 4 Recomendaciones de implementación Información del documento



Preparado por:


Título: Roadmap de la Arquitectura Fecha de Versión: Revisado por:

Fecha de Revisión:

Lista de Distribución De Fecha Teléfono/Fax/Email





ORIENTADO A LA UTPL

EA – UTPL - 183 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito <El Roadmap de la Arquitectura lista los incrementos de cambio individuales y los predispone en una línea de tiempo para mostrar la progresión desde la Arquitectura de Línea Base hasta la Arquitectura Objetivo. El Roadmap de la Arquitectura va desde los componentes clave de Transición de Arquitecturas y es incrementalmente desarrollado a través de las fases B, C, D, E, y F dentro de ADM. El propósito de este documento es definir uno o más roadmaps arquitectónicos para el domino/sub-dominio relevantes. Nota 1: El Roadmap también necesita ser sincronizado con los más amplios programas/proyectos o más roadmaps estratégicos. Nota 2: El rol de las funciones de planeación actuales determinará el nivel de detalle y amplitud de información en los roadmaps de la arquitectura. Nota 3: Debe tener cuidado de minimizar la duplicación de escuerzo y contenido cuando los planes/roadmaps son producidos. El propósito de ésta sección es describir el contexto alrededor del documento de Roadmap de la Arquitectura. Este necesita dar una indicación si este documento es el único documento de Roadmap de arquitectura para un dominio, o uno de un conjunto, y si es así, como éste se ajusta al conjunto completo de documentos. Obligatorio/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección deberá dejar claro: • Dominio/sub-dominio para cada documento de Roadmap de la Arquitectura que haya sido producido • Eventos previos y la razón de ser/antecedente/contexto de este documento • Propósito del Roadmap de la Arquitectura y por qué este documento – deberá responder preguntas como

su uso, acciones que va a conducir, y dependencias • Alcance de este documentos el cual claramente esbozará los aspectos del Roadmap de la arquitectura que

está tanto fuera como dentro del alcance • Interesados para el Roadmap de la Arquitectura en este documento • Si es relevante, un esquema de la documentación del Roadmap de la Arquitectura >>

2 Lista del proyecto <<El propósito de esta sección es listar y brevemente describir los proyectos que serán entregados la arquitectura objetivo para un dominio; por ejemplo, el proyecto tiene unas salidas significantes por lo tanto son ilustrados en la vista del Roadmap en la sección precedente. Obligatorio/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección deberá dejar claro: • Todos los proyectos resultan en un cambio significativo en la arquitectura • Nombres únicos para estos proyectos • Dependencias entre estos proyectos


ORIENTADO A LA UTPL

EA – UTPL - 184 - | P á g i n a

• Beneficios de la implementación de estos proyectos (incluyendo asignación para los requerimientos del negocio)

• Estimación de costos para el proyecto>>

2.1 Proyectos

Nombre del Proyecto Descripción

Dependencias entre estos proyectos

Estimación de costo para el proyecto

2.2 Objetivos del proyecto Listar los objetivos del proyecto EA-UTPL definidos en plantillas de la fase preliminar. 2.3 Beneficios Listar los beneficios potenciales del proyecto EA-UTPL definidos en plantillas de la fase preliminar. 2.4 Lista de priorización de proyectos impactados Lista priorizada de proyectos involucrados al implementar la arquitectura propuesta. 3 Plan de migración orientado al tiempo El propósito de esta sección es proveer una vista del plan (diagrama) ilustrando los proyectos que necesitan ser completados para realizar la arquitectura objetivo. Esta sección solamente necesita la lista de proyectos que tienen una salida arquitectónica significativa Obligatorio/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección deberá dejar claro: • Vista(s) del Roadmap proveyendo una indicación de:

o Escalas de tiempo del proyecto como cuando será entregado o Categoría de alto nivel o grupos para los cuales el proyecto es caracterizado

Nota: han mencionado invertir, apoyar y apostar “Sustain, and Sunset” como categorías a través de los que desean ver sus iniciativas/proyectos. Un Ejemplo de Vista de Roadmap de la Arquitectura: Esta sección necesita proveer una o más vistas para el Roadmap de la Arquitectura. Los diagramas a continuación proveen (ejemplo) una vista del Roadmap de la Arquitectura. En los diagramas, los proyectos son categorizados en el Roadmap por sus características como sus objetivos primarios en el negocio, tipo de tecnologías, propietario TI, o salidas de negocio. Los planes del Proyecto (diagramas de Gantt) o planes textuales pueden también ser considerados como vistas válidas. El texto describiendo los conceptos clave y la notación usada dentro de los diagramas también necesitará ser incluidos para que los usuarios puedan fácilmente entender las vistas. 3.1 Plan de migración <Ejemplo de Vista del Roadmap de la Arquitectura: Esta sección necesita proveer una o más vistas para el Roadmap de la Arquitectura. Los diagramas siguientes provén (ejemplo) vistas de los Roadmap de la


ORIENTADO A LA UTPL

EA – UTPL - 185 - | P á g i n a

Arquitectura. En los diagramas, los proyectos son categorizados sobre el Roadmap por sus características como sus objetivos primarios en el negocio, tipo de tecnologías, propietario TI, o salidas del negocio. Los planes del proyecto (diagramas Gantt) o planes textuales pueden también ser considerados como vistas válidas. El texto describiendo los conceptos clave y la notación usada dentro de los diagramas necesitará ser incluida para que los usuarios puedan fácilmente entender la vista.>> 3.2 Opciones de migración <<Definir el esquema de alternativas de migración aplicables>>

3.3 Beneficios de la migración <<Determinado (Incluyendo asignación a los requerimientos del negocio).>> 3.4 Estimación de costos de las opciones de migración 4 Recomendaciones de Implementación <<El propósito de esta sección es determinar las medidas críticas, cuestiones, y riesgos conocidos para cada uno de estos proyectos. Obligatorio/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección deberá dejar claro: • Medidas críticas que necesitan ser capturadas para el proyecto • Asuntos que pueden impactar la calidad o la entrega de estos proyectos • Riesgos conocidos que impactan la calidad o entrega de estos proyectos • Bloques de construcción de la solución que se harán disponibles para cada uno de estos proyectos >>

4.1 Criterios medibles o efectividad de proyectos <<El propósito de esta sección es determinar los criterios medibles para cada uno de estos proyectos. Obligatorio/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección deberá dejar claro: • Criterios medibles que necesitan ser capturados para los proyectos >>

<<Esta sección define las medidas que necesitan ser monitoreadas y evaluadas durante el curos (y hasta el final) de una iniciativa arquitectónica para asegurar que los objetivos, inversiones y las restricciones de tiempo estén en buen camino.>> 4.2 Riesgos y asunciones (issues) << El propósito de esta sección es determinar los asuntos y riesgos conocidos para cada uno de estos proyectos Obligatorio/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección deberá dejar claro: • Asuntos(Issues) que pueden impactar la calidad o entrega de estos proyectos • Riesgos conocidos que impactan la calidad o entrega de estos proyectos >>


ORIENTADO A LA UTPL

EA – UTPL - 186 - | P á g i n a

4.3 Bloques constitutivos de soluciones (SBBs) (Modelo y Descripción.) <<El propósito de esta sección es determinar los bloques de construcción de soluciones que estarán disponibles para cada uno de estos proyectos. Obligatorio/opcional: Esta sección es obligatoria. En términos de criterios de calidad, esta sección deberá dejar claro: • Bloques de construcción de soluciones que estarán disponibles para cada uno de estos proyectos >>


ORIENTADO A LA UTPL

EA – UTPL - 187 - | P á g i n a

5.4 Fase C: Arquitectura de Sistemas de Información

FasePreliminar


Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica



de Información

La arquitectura de sistemas de información se centra en la identificación y la definición de las

aplicaciones y los datos de las consideraciones que apoyan las entradas de la arquitectura de negocio.

La fase C implica una combinación de arquitecturas de datos y aplicaciones tratadas como

dos sub fases, cada una de ellas constituida por un conjunto de pasos similares a los establecidos en la fase B. 5.4.1 Objetivos

• Desarrollar arquitecturas objetivo, sea cualquiera de los dos o ambos (dependiendo del alcance del proyecto) dominios de los sistemas a nivel de datos y de aplicaciones.

• Centrarse en la identificación y la definición de las consideraciones acerca de las aplicaciones y los datos que apoyan a una arquitectura de negocio de la institución.

5.4.2 Enfoque

El levantamiento de la arquitectura de las aplicaciones clave forma un núcleo de misión crítica que apoya a los procesos del negocio, siendo el principal objetivo del esfuerzo arquitectónico en esta


ORIENTADO A LA UTPL

EA – UTPL - 188 - | P á g i n a

fase enfocarse a descripción de la implementación e integración del núcleo de dichas aplicaciones, debido a que los hechos de integración de ellas a menudo constituyen un mayor reto.

La implementación de estas dos arquitecturas (datos, aplicaciones) no necesariamente debe seguir un mismo orden y pueden estar apalancadas en fases de diseño e implementación con esquemas como:

• Diseño. o Diseño de arquitectura de negocio. o Diseño de arquitectura de datos (o aplicaciones). o Diseño de arquitectura de aplicaciones (o datos). o Diseño de arquitectura de tecnología.

• Implementación. o Implementación de arquitectura de tecnología. o Implementación de arquitectura de datos (o aplicaciones). o Implementación de arquitectura de aplicaciones (o datos). o Implementación de arquitectura de negocio.

5.4.3 Entradas

• Materiales de referencia externos a la institución. 5.4.3.1 No Arquitectónicas

• Solicitud de trabajo arquitectónico. • Evaluación de capacidad. • Plan de comunicaciones.


• Modelo organizacional para la EA. o Ámbito de aplicación de unidades de negocio afectadas. o Evaluación de madurez, brechas, y el enfoque de la resolución. o Funciones y responsabilidades para el equipo arquitectónico. o Restricciones sobre el trabajo arquitectónico. o Requisitos presupuestados. o Gobernanza y la estrategia de apoyo.

• Framework arquitectónico adaptado. o Método arquitectónico adaptado. o Contenido arquitectónico adaptado (Entregables y artefactos). o Herramientas configuradas y desplegadas.

• Principios de aplicaciones.


ORIENTADO A LA UTPL

EA – UTPL - 189 - | P á g i n a

• Principios de datos. • Estatuto de trabajo arquitectónico. • Visión arquitectónica.

o Repositorio arquitectónico. o Bloques constitutivos reutilizables. o Modelos de referencia específicos de la institución. o Estándares manejados en la institución.

• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de negocio. o Arquitectura de negocio objetivo. o Línea base de arquitectura de datos. o Arquitectura de datos objetivo. o Línea base de arquitectura de aplicaciones. o Arquitectura de aplicaciones objetivo.

• Borrador de la especificación de requerimientos de la arquitectura. o Resultados de análisis de brechas (de arquitectura de negocio). o Requisitos técnicos relevantes que se aplicarán a la Fase C.

• Componentes de arquitectura de negocio de un plan de actuación arquitectónico. 5.4.4 Fase C1: Arquitectura de Datos

Va de la mano con la arquitectura de aplicaciones y mediante la descripción de fuentes de datos aporta dándole valor al negocio (desde esta dimensión), también ayuda a establecer una correcta alienación de las TI (de esta capa) con los objetivos de negocio. Puntualmente debe describir la estructura de los datos físicos y lógicos de la institución, y los recursos de gestión de estos datos.


ORIENTADO A LA UTPL

EA – UTPL - 190 - | P á g i n a

FasePreliminar


Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica


Fase C1:Arquitectura

de Datos

5.4.4.1 Objetivos

• Definir los principales tipos y fuentes de datos necesarias para apoyar al negocio, de una manera que sea:

o Comprensibles para los stakeholders. o Completa y coherente. o Estable.

• Definir las entidades de datos relevantes para la institución. • No dedicada al diseño de sistemas de almacenamiento lógico o físico, o de bases de datos.

5.4.4.2 Enfoque

Existen algunas consideraciones para el enfoque que son clave deben cumplirse en la arquitectura de datos, básicamente abarcan aspectos de gestión, migración y gobernanza.

1. Gestión de datos

• Importante para comprender y abordar los hechos de gestión de datos. • Un enfoque estructurado y global para la gestión de datos permite el uso eficaz de dichos

datos para aprovechar sus ventajas competitivas. • Una definición clara de cuales componentes de aplicación yacen en el panorama servirá

como el sistema de registro o de referencia para los datos maestros de la institución.


ORIENTADO A LA UTPL

EA – UTPL - 191 - | P á g i n a

• Debería haber un estándar en toda la institución que todos los componentes de aplicaciones, incluyendo paquetes de software.

• Se debe entender cómo las entidades de datos son utilizadas por las funciones empresariales, por los procesos y servicios.

• Es necesario entender cómo y cuando las entidades de datos de la institución se crean, almacenan, transportan y son reportadas.

• Se necesita de un nivel de complejidad de las transformaciones de datos, esto se requiere para dar soporte al intercambio de información entre aplicaciones.

• Un requisito para el software en el apoyo a la integración de datos con las organizaciones externas.

2. Migración de datos

• Identificar los requisitos de migración de datos y establecer indicadores sobre el nivel de

transformación para las aplicaciones nuevas o cambiadas. • Garantizar que la aplicación de destino tiene datos de calidad cuando es llenada. • Asegurarse que la definición común para todos los datos se dio en toda la institución, con ello

se pretende apoyar a la transformación de los mismos.

3. Gobernanza de datos

Asegura que la institución tiene las dimensiones necesarias que permitan la transformación de datos. La gobernanza debe abarcar tres aspectos:

• Estructura: se asegura que la institución tiene la estructura necesaria y los organismos de estandarización para gestionar aspectos de identidad de los datos en la transformación.

• Gestión del sistema: asegura que la institución tenga el sistema de gestión necesario y los programas relacionados con los datos para gestionar los aspectos de la gobernanza de las entidades de datos a lo largo de su ciclo de vida.

• Personas: Direcciona qué habilidades relacionadas con los datos y qué funciones requeridas por la institución son necesarias para la transformación.

5.4.4.3 Entradas

• Materiales de referencia externos a la institución. 5.4.4.3.1 No Arquitectónicas



ORIENTADO A LA UTPL

EA – UTPL - 192 - | P á g i n a

5.4.4.3.2 Arquitectónicas







• Componentes de arquitectura de negocio de un plan de actuación arquitectónico.

5.4.4.4 Salidas

• Versiones actualizadas y refinadas de los entregables de fase de visión arquitectónica. o Estatuto de trabajo arquitectónico. o Principios, objetivos y conductores de negocio validados.

• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de datos. o Arquitectura de datos objetivo.

Modelo de datos de negocio. Modelo lógico de datos.


ORIENTADO A LA UTPL

EA – UTPL - 193 - | P á g i n a

Modelos de proceso de gestión de datos. Matriz de entidades de datos y funciones de negocio. Vistas correspondientes a los puntos de vista seleccionados apuntando a las

expectativas de los stakeholders. o Borrador de especificación de requisitos arquitectónicos.

Resultados de análisis de brechas Requisitos de interoperabilidad de datos. Requisitos técnicos relevantes. Restricciones en la arquitectura de tecnología que serán diseñados. Requisitos de negocio actualizados. Requisitos de aplicación actualizados.

o Componentes arquitectónicos de datos de un plan de actuación de EA.


ORIENTADO A LA UTPL

EA – UTPL - 194 - | P á g i n a

5.4.4.5 Definición del proceso de la arquitectura de datos

El nivel de detalle en la en la arquitectura de aplicaciones de la fase C (C1) dependerá del alcance y los objetivos de los esfuerzos de la arquitectura en general. Para conocer dicho nivel de detalle se debe considerar que los pasos propuestos a continuación se pueden adaptar, es decir, los pasos y su orden están dados para satisfacer requisitos específicos, por lo que hay flexibilidad en el uso de los mismos dentro de EA-UTPL.

Definición de Procesos Proceso: FC1 – ArquitecturaDatos: Levantamiento de la arquitectura

de datos. Cod.Doc FC1 –

ArquitecturaDatosX Responsable: ADD, ADS, DTE Versión: 1.0 Mantenimiento: DGTI, ADD Estado: Borrador

Publicado X

Descripción: Es el proceso mediante el cual se describe la arquitectura de datos mediante la definición de las fuentes, entidades y tipos de datos manejados por la institución.

Alcance: El proceso de la fase de arquitectura de datos, contempla los siguientes procedimientos:

• Analizar la gestión de datos • Analizar la migración de datos. • Analizar la gobernanza de datos. • Definir fuentes, entidades y tipos de datos más relevantes (no es orientado al

diseño).


No aplica





• ADS: Arquitectos de soluciones • ADD : Arquitectos de dominio • DTE: Director de tecnologías emergentes • DGTI: Director de gobernanza de TI.

Listado de Cambios



Descripción

1.0 26/10/2010 DGTI, ADS, ADD, DTE,




• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar la

• Informar sobre la arquitectura de datos establecida y brindar soporte a la


ORIENTADO A LA UTPL

EA – UTPL - 195 - | P á g i n a

arquitectura de datos. arquitectura de negocio. Entradas:

Salidas:



negocio. • Evaluación de la capacidad. • Plan de comunicaciones. • Modelo organizacional para la EA. • Framework arquitectónico adaptado. • Estatuto aprobado de trabajo arquitectónico. • Principios arquitectónicos de datos. • Visión arquitectónica. • Borrador del documento de definición de la

arquitectura. • Borrador de la especificación de

requerimientos de la arquitectura. • Componentes de arquitectura de negocio de

un plan de actuación arquitectónico.



o Línea base de arquitectura de datos.

o Arquitectura de datos objetivo. o Borrador de especificación de

requisitos arquitectónicos. o Componentes arquitectónicos de

datos de un plan de actuación de EA.

Roles:

• ADS: Originar la arquitectura de datos. • ADD: Originar la arquitectura de datos. • DGTI: Dar soporte al proceso. • DTE: Brindar soporte para herramientas y metodologías de modelado de datos.


• Modelo Organizacional. • Framework arquitectónico. • Principios arquitectónicos de datos. • Estrategias, planes de negocio, políticas y marco jurídico relacionados a los datos. • Repositorio arquitectónico. • Línea base arquitectónica.

Tareas:

1. Seleccionar los modelos de referencia, puntos de vista y herramientas. 2. Desarrollar la descripción de la línea base de arquitectura de datos. 3. Desarrollar la descripción arquitectura de datos objetivo. 4. Realizar análisis de brechas. 5. Definir los componentes del plan de actuación. 6. Resolver los impactos a través de la perspectiva arquitectónica. 7. Realizar una revisión formal de los stakeholders. 8. Concluir la arquitectura de datos. 9. Crear un documento de definición de la arquitectura.

Métricas:


ORIENTADO A LA UTPL

EA – UTPL - 196 - | P á g i n a

• Capacidad de gestión de datos. B. Definición Detallada del Proceso

Levantamiento de la arquitectura de datos. Objetivos del Procedimiento:

• Definir los principales tipos y fuentes de datos necesarias para apoyar el negocio, de una manera que sea:

o Comprensibles para los stakeholders. o Completa y coherente. o Estable.

• Definir las entidades de datos relevantes para la institución. Roles y Responsabilidades:


• ADS: Brindar una línea base de datos y establecer una arquitectura de datos objetivo.

• ADD: Brindar una línea base de datos y establecer una arquitectura de datos objetivo.

• DGTI: Dar soporte al proceso. • DTE: Brindar soporte para herramientas y metodologías de

modelado de datos. Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a

continuación:

• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar la arquitectura de datos.

Entradas: • Materiales de referencia externos a la institución. • Solicitud de trabajo arquitectónico. • Principios, objetivos y conductores de negocio. • Evaluación de la capacidad. • Plan de comunicaciones. • Modelo organizacional para la EA.

o Ámbito de aplicación de unidades de negocio afectadas. o Evaluación de madurez, brechas, y el enfoque de la


arquitectónico. o Restricciones sobre el trabajo arquitectónico. o Requisitos presupuestados. o Gobernanza y la estrategia de apoyo.

• Framework arquitectónico adaptado. o Método arquitectónico adaptado. o Contenido arquitectónico adaptado (Entregables y



o Repositorio arquitectónico. o Bloques constitutivos reutilizables.


ORIENTADO A LA UTPL

EA – UTPL - 197 - | P á g i n a

o Modelos de referencia específicos de la institución. o Estándares manejados en la institución.


• Borrador de la especificación de requerimientos de la arquitectura. o Resultados de análisis de brechas (de arquitectura de

negocio). o Requisitos técnicos relevantes que se aplicarán a la Fase

C.




1. Seleccionar modelos de referencia, puntos de vista, y herramientas.

a. Seleccionar los recursos pertinentes a la arquitectura de datos (modelos de referencia, patrones, etc.) desde el repositorio arquitectónico, en base a los conductores de negocio, stakeholders y sus expectativas.

b. Seleccionar puntos de vista relevantes de la arquitectura de datos (por ejemplo, operaciones, gestión, financiero), es decir, los que le permitirán al arquitecto demostrar cómo las expectativas de los stakeholders se están abordando en la arquitectura de datos.

c. Identificar las herramientas y técnicas adecuadas a ser utilizadas para la captura, modelado y análisis de datos.

d. Determinar el proceso de modelado general. o Para cada punto de vista, seleccionar los modelos necesarios

para apoyar el punto de vista específico necesario, utilizando la herramienta o método seleccionados.

o Asegurarse de que todas las expectativas de los stakeholders están cubiertas.

o Recopilar datos relacionados desde la arquitectura de negocio existente, así como de materiales de la arquitectura de aplicaciones.

o Racionalizar los requisitos de datos y alinearlos con los catálogos y los modelos de datos existentes en la institución. Esto permite el desarrollo de un inventario de datos y relaciones de entidades.

o Actualizar y desarrollar matrices a través de la arquitectura, relacionando los datos al servicio de negocio, función de negocio, derechos de acceso, y aplicaciones.

o Elaborar vistas de arquitectura de datos mediante el examen de la cantidad de datos que se crean, distribuyen, emigran,


ORIENTADO A LA UTPL

EA – UTPL - 198 - | P á g i n a

aseguran, y se archivan. e. Identificar catálogos requeridos de bloques constitutivos.

o Capturar el inventario de datos de la institución como un catálogo dentro del repositorio arquitectónico.

o Crear un inventario de los datos necesario para apoyar la visión arquitectónica.

o Consultar el diagrama de servicios e información de negocio creado durante la fase de arquitectura de negocio. Esto mostrará las entidades de datos claves requeridas por los principales servicios de negocios.

o Consolidar los requerimientos de datos en un solo lugar. o Refinar el inventario de datos para lograr una coherencia

semántica y eliminar brechas y superposiciones. f. Identificar las matrices requeridas. Las matrices muestran las

relaciones básicas entre las entidades relacionadas con el modelo, constituyendo así la materia prima para la elaboración de diagramas y también actúan como un recurso clave para la evaluación del impacto. Las consideraciones a tomarse son: o Entender cómo los datos se crean, mantienen, transforman, y

se pasan a otras aplicaciones, o son utilizados por otras aplicaciones.

o Tener en cuenta las brechas como si fuesen entidades que no parecen ser creadas por una aplicación o datos, pero tampoco nunca se utilizan.

o Actualizar y perfeccionar los diagramas arquitectónicos de cómo los datos se refieren a otros aspectos de la arquitectura.

o Matrices sugeridas: Función entidad de datos / negocio (muestra qué datos

apoyan a funciones de negocio, y que funciones de negocio poseen los datos).

Servicio / Información de negocio (desarrollada durante la fase de arquitectura de negocio).

Sistema / Datos (desarrollada a través de las fases de arquitectura de aplicaciones y de datos).

g. Identificar los diagramas necesarios. Una vez que las entidades de datos se han ido perfeccionando, se puede producir un diagrama de las relaciones entre las entidades y sus atributos. Tales diagramas pueden ser de tipo: o Diagrama de clase. o Diagrama de divulgación de datos. o Diagrama de ciclo de vida de datos. o Diagrama de seguridad de datos. o Diagrama de migración de datos. o Diagrama de jerarquía de clases.

h. Identificar los tipos de requisitos a ser recogidos. Una vez que los

catálogos, matrices y diagramas de la arquitectura de datos han sido desarrollados, el modelado de arquitectura se completa con la formalización de los requisitos centrados en el negocio, para apoyar


ORIENTADO A LA UTPL

EA – UTPL - 199 - | P á g i n a

la implementación de la arquitectura objetivo. Los tipos de requisitos abarcan:

o Requisitos funcionales. o Requisitos no funcionales. o Supuestos. o Restricciones. o Principios de dominio específico de arquitectura de datos. o Políticas. o Estándares. o Directrices. o Especificaciones.

2. Desarrollar la descripción de la línea base de la arquitectura de

datos. Sirve de soporte para apoyar a la arquitectura de negocio objetivo y su ámbito de aplicación y nivel de detalle -a ser definido- dependerán del grado con el que los elementos de datos existentes sean probables ser incorporados en la arquitectura de datos objetivo.

3. Desarrollar la descripción de la arquitectura de datos objetivo. Apoya en la medida necesaria a la visión arquitectónica. Su ámbito de aplicación y nivel de detalle –a definirse- dependerán de la relevancia de los elementos de negocio para alcanzar la visión arquitectónica objetivo.


• Verificar los modelos arquitectónicos para la coherencia y precisión interna.

• Realizar el análisis de equilibrio para resolver los conflictos (si existen), entre los puntos de vista diferentes.

• Validar que los modelos apoyen a los principios, objetivos y restricciones.

• Probar los modelos arquitectónicos para medir la integridad de los requisitos.

• Identificar las brechas entre la línea base y el objetivo. o Crear matriz de brechas. o Identificar los bloques constitutivos a ser prorrogados,

clasificándolos como modificado o sin cambios. o Identificar bloques constitutivos eliminados. o Identificar nuevos bloques constitutivos. o Identificar y clasificar brechas como aquellas que se deben

desarrollar y las que deben obtenerse.

5. Definir los componentes del plan de actuación. Sirve como base a la creación de un plan de actuación de datos de negocio


ORIENTADO A LA UTPL

EA – UTPL - 200 - | P á g i n a

para dar prioridad a las actividades sobre las próximas etapas. El plan de actuación inicial será usado como materia prima, para apoyar la definición más detallada de un plan actuación consolidada e interdisciplinaria dentro de la fase de oportunidades y soluciones.

6. Resolver los impactos a través de la perspectiva arquitectónica. Implica comprender los impactos más amplios o las implicaciones de la propuesta de arquitectura de datos. Es necesario tener en consideración los razonamientos:

• ¿Esta arquitectura de datos crea un impacto en cualquier arquitectura pre-existente?

• ¿Se han hecho cambios recientes que han impactado la arquitectura de datos?

• ¿Hay oportunidades para apalancar el trabajo de esta arquitectura de datos en otras áreas de la institución?

• ¿Tiene impacto esta arquitectura de datos en otros proyectos (incluidos los planeados, así como los actualmente en curso)?

• ¿Esta arquitectura de datos se verá afectada por otros proyectos (incluidos los planeados, así como los actualmente en curso)?

7. Realizar una revisión formal de los stakeholders.

Comprueba la motivación original para el proyecto de EA y para el estatuto de trabajo arquitectónico con respecto a la propuesta de arquitectura de datos. Mide si dicha motivación es adecuada para el propósito de apoyar al trabajo arquitectónico subsecuente en otros dominios. Así se puede Identificar las áreas donde la arquitectura de la aplicación (si se generan en este punto - Fase C2) pueden tener que cambiar para hacer frente a los cambios en la arquitectura de datos (o para determinar las limitaciones en la arquitectura de aplicaciones respecto a ser diseñada).

8. Finalizar la arquitectura de datos. Selecciona las normas para cada uno de los bloques constitutivos re-usándolos cuanto más sea posible desde los modelos de referencia seleccionados, desde el repositorio arquitectónico. Este paso permite:

• Documentar cada bloque constitutivo. • Conducir una comprobación cruzada final de la arquitectura global

contra los objetivos de negocio. • Documentar las razones para construir las decisiones por bloques

constitutivos en el documento arquitectónico. • Documentar un reporte de trazabilidad de requisitos finales. • Documentar la asignación final de la arquitectura dentro del

repositorio arquitectónico y publicarlo a través de este.


ORIENTADO A LA UTPL

EA – UTPL - 201 - | P á g i n a

• Completar todos los productos de trabajo, tales como resultados de análisis de brechas.

9. Crear un documento de definición arquitectónica.

Implica documentar las razones para las decisiones para la existencia de bloques constitutivos en el documento de definición de la arquitectura. Con ello prepara las secciones de arquitectura de datos del documento de definición de arquitectura mediante la especificación de:

• Modelo de datos de negocio. • Modelo de datos lógico. • Modelo de proceso gestión de datos. • Matriz de entidades de datos y funciones de negocio.

• Requisitos de interoperabilidad de datos.


o Estatuto de trabajo arquitectónico. o Principios, objetivos y conductores de negocio validados.

• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de datos. o Arquitectura de datos objetivo.

Modelo de datos de negocio. Modelo lógico de datos. Modelos de proceso de gestión de datos. Matriz de entidades de datos y funciones de

negocio. Vistas correspondientes a los puntos de vista

seleccionados apuntando a las expectativas de los stakeholders.

o Borrador de especificación de requisitos arquitectónicos. Resultados de análisis de brechas Requisitos de interoperabilidad de datos. Requisitos técnicos relevantes. Restricciones en la arquitectura de tecnología que

serán diseñados. Requisitos de negocio actualizados. Requisitos de aplicación actualizados.


Criterios de Salida: • Informar sobre la arquitectura de datos establecida y brindar soporte a la arquitectura de negocio.

Métricas del Proceso:

• Capacidad de gestión de datos.


ORIENTADO A LA UTPL

EA – UTPL - 202 - | P á g i n a

5.4.4.6 Plantillas para la fase de arquitectura de datos 5.4.4.6.1 Plantilla para especificación de la arquitectura de datos

Especificación de Arquitectura de Datos


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propóstito de este documento 2 Modelo de datos 3 Mecanismos de respaldo y recuperación 4 Manejo de seguridad 5 Pruebas de rendimiento Información del documento



Preparado por:


Título: Especificación de Arquitectura de Datos Fecha de Versión: Revisado por:

Fecha de Revisión:







ORIENTADO A LA UTPL

EA – UTPL - 203 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito Este documento tiene por objetivo representar de manera concisa la estructura arquitectónica del manejo de la datos de la UTPL, direccionarás así de manera general hechos de alto nivel relativos a la generación, almacenamiento y difusión de datos dentro de la institución, de igual manera se hará una breve especificación de la tecnología usada para estos procesos (concerniente a datos), pero la misma deberá ser tratada a fondo en la plantilla para levantamiento de la capa de infraestructura tecnológica. 2 Modelo de Datos La Especificación de la arquitectura de datos requiere un levantamiento de cómo se gestiona información altamente estructurada: como la concerniente a los estudiantes, las transacciones financieras de la UTPL, correos electrónicos, apuntes académicos, investigaciones, etc. Los cuales son almacenados en sistemas de gestión centralizados mayoritariamente. 2.1 Arquitectura lógica de bases de datos El primer aspecto a cubrir es la organización formal (software) utilizada para el manejo de datos. Para ello es necesario utilizar el esquema propuesto con el fin de hacer un levantamiento de los sistemas de gestión de bases de datos existentes.

Elemento Base de Datos Descripción Sistema de Gestión de Base de Datos Clase Producto Notas Preferido Listar los sistemas de bases de datos más

usados (de manera generalizada)

Soportado Listar los sistemas de bases de datos usados pero que no son de uso difundido.

Prohibido Listar los sistemas de bases de datos que no se utilicen, debido a problemas varios (seguridad, incompatibilidad, políticas del negocio, etc.)

2.2 Arquitectura física de bases de datos Igual de importante que el ítem anterior se debe cubrir la tecnología (hardware) utilizada para el manejo de datos. Para ello es necesario utilizar el esquema propuesto con el fin de hacer un levantamiento de la infraestructura


ORIENTADO A LA UTPL

EA – UTPL - 204 - | P á g i n a

tecnológica sobre la que se erigen los sistemas de gestión de bases de datos existentes.

Elemento Servidor Almacenamiento de Datos Descripción Almacenamiento Físico Clase Producto Notas Preferido Listar la tecnología predominante, que es de

uso extendido y robusto dentro de la UTPL

Aceptable Listar la tecnología que es de uso secundarios (usado en ciertas áreas) de la UTPL y para fines particulares.

3 Mecanismos de respaldo y recuperación Especificar los mecanismos de almacenamiento redundante, los de recuperación de archivos, en fin, los se sirvan para conservar la integridad de los datos.

Elemento Respaldo y Recuperación de Datos Descripción Respaldo, archivo y recuperación de Datos Clase Producto Tipo Notas Preferido Hardware /

Software

Aceptable

4 Manejo de seguridad 4.1 Manejo de identidad de usuarios Especificar los mecanismos usados para salvaguardar la identidad de los usuarios con acceso a los datos.

Elemento Manejo de Identidad Descripción Métodos de integridad de usuarios Clase Producto /

Procedimiento Notas

Preferido Soportado Candidato

4.2 Mecanismos de red de seguridad para los datos Especificar los mecanismos usados para salvaguardar la gestión de los datos dentro de la red de la UTPL y desde fuera de ella.

Elemento Manejo de Identidad Descripción Métodos o Protocolos para autenticación y acceso de usuario a los

recursos dentro de la red


ORIENTADO A LA UTPL

EA – UTPL - 205 - | P á g i n a

Clase Producto Notas Preferido Soportado Candidato

4.3 Estándares de seguridad Listar los estándares aplicados de manera limpia o que estén incluidos en los paquetes de software encargados de la gestión de la seguridad. 5 Pruebas de rendimiento Listar los mecanismos aplicados para realizar pruebas a nivel de arquitectura lógica y física de los datos.

Elemento Pruebas Automatizadas Descripción Pruebas al Software / Hardware para asegurar el rendimiento y la

flexibilidad adecuadas (sobrecarga de transacciones) Clase Producto Notas Preferido Aceptable


ORIENTADO A LA UTPL

EA – UTPL - 206 - | P á g i n a

5.4.5 Fase C2: Arquitectura de Aplicaciones

Va de la mano con la arquitectura de datos y mediante la descripción de las aplicaciones preponderantes de la institución aporta dándole valor al negocio (desde esta dimensión), también ayuda a establecer una correcta alienación de las TI (de esta capa) con los objetivos de negocio. Puntualmente debe proveer un plano (blueprint) para cada uno de los sistemas de aplicación que se requiere implantar, las interacciones entre estos sistemas y sus relaciones con los procesos de negocio centrales de la institución.

FasePreliminar


Fase D:Arquitectura

De Teconología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica


Fase C2:Arquitectura de

Aplicaciones

5.4.5.1 Objetivos

• Definir los tipos principales de sistemas de aplicaciones necesarios para procesar los datos y dar apoyo al negocio.

• Definir qué tipos de sistemas de aplicación son relevantes para la organización y qué tienen que hacer estas aplicaciones con el fin de gestionar los datos y presentar la información a los actores humanos e informáticos de la institución.

• Definir grupos lógicos de capacidades que manejen los objetos de datos en la arquitectura de datos y apoyan las funciones de negocio en la arquitectura de negocio. Considerar:


ORIENTADO A LA UTPL

EA – UTPL - 207 - | P á g i n a

o No hacer referencia a tecnologías particulares. o Las aplicaciones tienden a ser relativamente estables e inmutables en el tiempo,

mientras que la tecnología utilizada para ponerlas en práctica va a cambiar con el tiempo, basado en las tecnologías actualmente disponibles y las necesidades cambiantes de negocios.

5.4.5.2 Entradas

• Materiales de referencia externos a la institución. 5.4.5.2.1 No Arquitectónicas


5.4.5.2.2 Arquitectónicas



• Principios de aplicaciones. • Estatuto de trabajo arquitectónico. • Visión arquitectónica.


• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de negocio. o Arquitectura de negocio objetivo. o Línea base de arquitectura de datos. o Arquitectura de datos objetivo. o Línea base de arquitectura de aplicaciones.


ORIENTADO A LA UTPL

EA – UTPL - 208 - | P á g i n a

o Arquitectura de aplicaciones objetivo. • Borrador de la especificación de requerimientos de la arquitectura.

o Resultados de análisis de brechas (de arquitectura de negocio). o Requisitos técnicos relevantes que se aplicarán a la Fase C2.

• Componentes de arquitectura de negocio de un plan de actuación arquitectónico. 5.4.5.3 Salidas

• Versiones actualizadas y refinadas de los entregables de fase de visión arquitectónica. o Estatuto de trabajo arquitectónico. o Principios, objetivos y conductores de negocio validados.

• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de aplicaciones. o Arquitectura de aplicaciones objetivo.

Modelo de procesos de sistemas. Modelo de lugares del sistemas. Modelo de tiempos del sistemas. Modelo de personas de sistemas.

o Borrador de especificación de requisitos arquitectónicos. Resultados de análisis de brechas Requisitos de interoperabilidad de datos. Requisitos técnicos relevantes. Restricciones en la arquitectura de tecnología que serán diseñados. Requisitos de negocio actualizados. Requisitos de aplicación actualizados.



ORIENTADO A LA UTPL

EA – UTPL - 209 - | P á g i n a

5.4.5.4 Definición de proceso para la arquitectura de aplicaciones

El nivel de detalle dirigido en la fase C2 dependerá del alcance y los objetivos de los esfuerzos de la arquitectura en general. Se deberá adaptar los pasos y su orden para satisfacer requisitos específicos. Definición de Procesos Proceso: FC2 – ArquitecturaAplicaciones: Levantamiento de la

arquitectura de aplicaciones. Cod.Doc FC2 –

ArquitecturaAplicacionesX Responsable: ADD, ADS, DTE Versión: 1.0 Mantenimiento: DGTI, ADD Estado: Borrador

Publicado X

Descripción: Es el proceso mediante el cual se describe la arquitectura de aplicaciones mediante la definición de sistemas principales de la institución.

Alcance: El proceso de la fase de arquitectura de aplicaciones, contempla los siguientes procedimientos:

• Definir aplicaciones preponderantes de la institución. • Analizar como dichas aplicaciones gestionan los datos. • Analizar la gobernanza de datos. • Definir grupos lógicos de capacidades (en términos de aplicaciones) que

gestionen los datos.


No aplica






Listado de Cambios



Descripción

1.0 26/10/2010 DGTI, ADS, ADD, DTE,


A. Resumen del Proceso



• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar la arquitectura de aplicaciones.

• Informar sobre la arquitectura de aplicaciones establecida y brindar soporte a la arquitectura de negocio.

Entradas: Salidas:


ORIENTADO A LA UTPL

EA – UTPL - 210 - | P á g i n a

• Materiales de referencia externos a la

institución. • Solicitud de trabajo arquitectónico. • Evaluación de la capacidad. • Plan de Comunicaciones. • Modelo Organizacional para la EA. • Framework arquitectónico adaptado. • Estatuto aprobado de trabajo arquitectónico. • Principios arquitectónicos de aplicaciones. • Visión arquitectónica. • Borrador del documento de definición de la



un plan de actuación arquitectónico.



o Línea base de arquitectura de aplicaciones.

o Arquitectura de aplicaciones objetivo.

o Borrador de especificación de requisitos arquitectónicos.


Roles:

• ADS: Originar la arquitectura de aplicaciones. • ADD: Originar la arquitectura de aplicaciones. • DGTI: Dar soporte al proceso. • DTE: Brindar soporte para herramientas y metodologías de modelado de aplicaciones.


• Modelo Organizacional. • Framework arquitectónico. • Principios arquitectónicos de aplicaciones. • Estrategias, planes de negocio, políticas y marco jurídico relacionados a las aplicaciones. • Repositorio arquitectónico. • Línea base arquitectónica.

Tareas:

1. Seleccionar los modelos de referencia, puntos de vista y herramientas. 2. Desarrollar la descripción de la línea base de arquitectura de aplicaciones. 3. Desarrollar la descripción arquitectura de aplicaciones objetivo. 4. Realizar análisis de brechas. 5. Definir los componentes del plan de actuación. 6. Resolver los impactos a través de la perspectiva arquitectónica. 7. Realizar una revisión formal de los stakeholders. 8. Concluir la arquitectura de aplicaciones. 9. Crear un documento de definición de la arquitectura.

Métricas:

• Ponderación de aplicaciones. • Capacidad de gestión de datos.



ORIENTADO A LA UTPL

EA – UTPL - 211 - | P á g i n a

Levantamiento de la arquitectura de aplicaciones. Objetivos del Procedimiento:

• Definir los tipos principales de sistema de aplicaciones necesarios para procesar los datos y dar apoyo al negocio.

• Definir qué tipos de sistemas de aplicación son relevantes para la organización y qué tienen que hacer estas aplicaciones con el fin de gestionar los datos y presentar la información a los actores humanos e informáticos de la institución.

• Definir grupos lógicos de capacidades que manejen los objetos de datos en la arquitectura de datos y apoyar las funciones de negocio en la arquitectura de negocio.

o Sin hacer referencia a tecnologías particulares. o Las aplicaciones tienden a ser relativamente estables e

inmutable en el tiempo, mientras que la tecnología utilizada para ponerlas en práctica va a cambiar con el tiempo, basado en las tecnologías actualmente disponibles y las necesidades cambiantes de negocios.



• ADS: Brindar una línea base de aplicaciones y establecer una arquitectura de aplicaciones objetivo.

• ADD: Brindar una línea base de aplicaciones y establecer una arquitectura de aplicaciones objetivo.


modelado de aplicaciones. Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a

continuación:

• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar la arquitectura de aplicaciones.

Entradas: • Materiales de referencia externos a la institución. • Solicitud de trabajo arquitectónico. • Principios, objetivos y conductores de negocio. • Evaluación de la capacidad. • Plan de Comunicaciones. • Modelo organizacional para la EA.





artefactos).


ORIENTADO A LA UTPL

EA – UTPL - 212 - | P á g i n a

o Herramientas configuradas y desplegadas. • Principios de aplicaciones. • Estatuto de trabajo arquitectónico. • Visión arquitectónica.





C2.





• Revisar y validar (o generar, si es necesario) el conjunto de principios de aplicación.

• Seleccionar recursos relevantes de arquitectura de aplicaciones (modelos de referencia, patrones, etc.) desde el repositorio arquitectónico, sobre la base de los conductores del negocio y las expectativas de stakeholders.

• Seleccionar los puntos de vista relevantes de la arquitectura de aplicaciones (por ejemplo, stakeholders de las aplicaciones, puntos de vista relevantes para los usuarios funcionales e individuales de las aplicaciones, etc.), es decir, los que le permitirán el arquitecto demostrar cómo las expectativas de los stakeholders se están abordando en la arquitectura de aplicaciones.

• Identificar las herramientas y técnicas adecuadas para ser utilizadas en la captura, modelado y análisis de datos.

• Considerar el uso de descripciones independientes de plataforma de la lógica de negocio.

o Aislar la lógica de negocio a un cambio de la plataforma subyacente y tecnología de implementación de la misma.

a. Luego de lo descrito se debe determinar el modelado de procesos

globales. Esto implica seleccionar los modelos necesarios para apoyar a cada punto de vista específico requerido, utilizando la


ORIENTADO A LA UTPL

EA – UTPL - 213 - | P á g i n a

herramienta o método seleccionado. Se debe asegurar que todas las expectativas de stakeholders son cubiertas, para ello se pueden usar los recursos:

• Entender la lista de aplicaciones o componentes de aplicación que

son requeridos, basado en portafolio de aplicación de la línea base, en cuáles son los requisitos y el ámbito empresarial arquitectura.

• Identificar las aplicaciones lógicas y las aplicaciones físicas más adecuadas.

• Desarrollar matrices a través de la arquitectura mediante la relación de aplicaciones a servicios de negocio, la funciones de negocio, datos, procesos, etc.

• Elaborar un conjunto vistas de arquitectura de aplicaciones examinando cómo la aplicación funcionará, capturando integración, migración, desarrollo, y expectativas operacionales.

El nivel de granularidad debe ser suficiente para permitir la identificación de brechas y el alcance de los paquetes de trabajo candidatos.

b. A continuación se deben identificar los catálogos de bloques constitutivos de aplicaciones. El repositorio arquitectónico captura el portafolio de las aplicaciones de la institución como un catalogo, por lo que puede dichos catálogos pueden ser fácilmente recuperados y analizados.

c. Al igual que con la sub fase anterior, para la arquitectura de

aplicaciones también se requiere identificar matrices requeridas, para ellos se debe considerar que:

• Las matrices muestran las relaciones básicas entre las entidades

relacionadas con el modelo. • Constituyen la materia prima para la elaboración de diagramas y

también actuar como un recurso clave para la evaluación del impacto.

• Una vez que la línea de base del portafolio de aplicaciones ha sido montada, es necesario asignar las aplicaciones a su propósito en el apoyo al negocio.

• Una vez que las aplicaciones se asignan a los servicios de negocio, también será posible realizar las asociaciones desde las aplicaciones a los datos.

• Hay que identificar los usuarios y las dependencias de organización sobre las aplicaciones, hay que considerar especialmente el apoyo a unidades de negocio.

• Es necesario también actualizar y perfeccionar los diagramas arquitectónicos de cómo los datos se refieren a otros aspectos de la arquitectura.

• Luego se examinan las dependencias de aplicación para compartir las capacidades de las operaciones y elaborar un diagrama de la


ORIENTADO A LA UTPL

EA – UTPL - 214 - | P á g i n a

forma en que cada solicitud es operada y administrada con eficacia.

Se sugiere hacer uso de matrices de tipo:

• Matriz de sistema / de unidad de negocios. • Matriz de roles / sistema. • Matriz de interacción de aplicaciones. • Matriz de sistema / funciones.

d. Lo siguiente es identificar los diagramas requeridos, para ello se

parte del hecho de conocer que los diagramas presentan información de la arquitectura desde un conjunto de perspectivas distintas que están dadas por los requisitos de los stakeholders.

e. Un vez conocida las funcionalidad deseada de una aplicación, es

necesario realizar una evaluación interna de cómo la aplicación debería ser mejor estructurada para cumplir con los requisitos. Luego deben refinarse las entidades de aplicación para a partir de ello poder generar un diagrama de relaciones entre las entidades y sus atributos. Los diagramas que se ajustan a este contexto son:

• Diagrama de comunicaciones de aplicaciones. • Diagrama de aplicación y ubicación de usuarios. • Diagrama de capacidad de gestión institucional. • Diagrama de procesos / realización de sistema. • Diagrama de migración de aplicaciones. • Diagrama de distribución de software. • Diagrama de ingeniería de software.

f. Para finalizar este paso se deben identificar los tipos de requisitos

que se desean recolectar. Con los pasos realizados anteriormente el modelado arquitectónico habrá terminado al formalizar los requisitos basados en aplicaciones para a partir de ello poder implementar la arquitectura objetivo. Los tipos de requisitos son los mismos especificados en la sub fase antecesora a la presente.

2. Desarrollar la descripción de la línea base de la arquitectura de

aplicaciones. Desarrollar una descripción de la línea base de la actual arquitectura de aplicaciones, en la medida necesaria para apoyar a la arquitectura de negocio objetivo. El ámbito y nivel de detalle que se definan dependerán del grado en que los elementos de datos existentes puedan ser transferidos a la arquitectura de aplicación objetivo.

3. Desarrollar la descripción de la arquitectura de aplicaciones objetivo. Desarrollar una descripción del objetivo para la arquitectura de aplicaciones,


ORIENTADO A LA UTPL

EA – UTPL - 215 - | P á g i n a

en la medida necesaria para apoyar la visión arquitectónica, a la arquitectura de negocio objetivo y arquitectura de datos objetivo. El ámbito de aplicación y nivel de detalle a definir dependerá de la relevancia de los elementos de negocio para alcanzar la visión arquitectónica objetivo.





clasificándolos como modificado o sin cambios. o Identificar bloques constitutivos eliminados. o Identificar nuevos bloques constitutivos. o Identificar y clasificar brechas como aquellas que se deben


5. Definir los componentes del plan de actuación. Crea de un plan de actuación de negocios para dar prioridad a las actividades sobre las próximas etapas. El plan de actuación inicial de la arquitectura de aplicaciones será usado como materia prima, para apoyar la definición más detallada de un plan actuación consolidada e interdisciplinaria dentro de la fase de oportunidades y soluciones.

6. Resolver los impactos a través de la perspectiva arquitectónica. Implica comprender los impactos más amplios o las implicaciones de la propuesta de arquitectura de aplicaciones. Es necesario tener en consideración los razonamientos:

• ¿Esta arquitectura de aplicaciones crea un impacto en cualquier arquitectura pre-existente?

• ¿Se han hecho cambios recientes que han impactado la arquitectura de aplicaciones?

• ¿Hay oportunidades para apalancar el trabajo de esta arquitectura de aplicaciones en otras áreas de la institución?

• ¿Tiene impacto esta arquitectura de aplicaciones en otros proyectos (incluidos los planeados, así como los actualmente en curso)?

• ¿Esta arquitectura de Aplicaciones se verá afectada por otros proyectos (incluidos los planeados, así como los actualmente en curso)?



ORIENTADO A LA UTPL

EA – UTPL - 216 - | P á g i n a

Comprueba la motivación original para el proyecto de EA, así como el estatuto de trabajo arquitectónico con respecto a la propuesta de arquitectura de aplicaciones. Mide si dicha motivación es adecuada para el propósito de apoyar al trabajo arquitectónico subsecuente en otros dominios. Así se puede Identificar las áreas donde las arquitecturas de negocio y de datos (por ejemplo, prácticas de negocio) pueden tener que cambiar para hacer frente a los cambios en la arquitectura de aplicaciones (por ejemplo, cambios en procedimientos, sistemas o bases de datos).

8. Finalizar la arquitectura de aplicaciones. Selecciona las normas para cada uno de los bloques constitutivos re-usándolos cuanto más sea posible desde los modelos de referencia seleccionados desde el repositorio arquitectónico. Este paso permite:

• Documentar cada bloque constitutivo. • Conducir una validación cruzada final de la arquitectura global contra

los objetivos de negocio. • Documentar las razones para especificar las decisiones por bloques

constitutivos en el documento arquitectónico. • Documentar un reporte de trazabilidad de requisitos finales. • Documentar la asignación final de la arquitectura dentro del

repositorio arquitectónico y publicarlo a través de este. • Completar todos los productos de trabajo, tales como resultados de


9. Crear un documento de definición arquitectónica. Implica documentar las razones para la existencia de las decisiones de bloques constitutivos en el documento de definición de la arquitectura. Con ello prepara las secciones de arquitectura de datos del documento de definición de arquitectura.


ORIENTADO A LA UTPL

EA – UTPL - 217 - | P á g i n a


o Estatuto de trabajo arquitectónico. o Principios, objetivos y conductores de negocio validados.

• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de aplicaciones. o Arquitectura de aplicaciones objetivo.

Modelo de procesos de sistemas. Modelo de lugares del sistemas. Modelo de tiempos del sistemas. Modelo de personas de sistemas.

o Borrador de especificación de requisitos arquitectónicos. Resultados de análisis de brechas Requisitos de interoperabilidad de datos. Requisitos técnicos relevantes. Restricciones en la arquitectura de tecnología que

serán diseñados. Requisitos de negocio actualizados. Requisitos de aplicación actualizados.



• Informar sobre la arquitectura de aplicaciones establecida y brindar soporte a la arquitectura de negocio.


• Capacidad de gestión de datos. • Ponderación de aplicaciones.


ORIENTADO A LA UTPL

EA – UTPL - 218 - | P á g i n a

5.4.5.5 Plantillas para la fase de arquitectura de aplicaciones 5.4.5.5.1 Plantilla para especificación de la arquitectura de aplicaciones

Especificación de Arquitectura de Aplicaciones


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propóstito de este documento 2 Matriz de sistemas existentes 3 Modelo de aplicaciones 4 Manejo de seguridad Información del documento



Preparado por:


Título: Especificación de Arquitectura de Aplicaciones

Fecha de Versión:

Revisado por:

Fecha de Revisión:






ORIENTADO A LA UTPL

EA – UTPL - 219 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito Este documento tiene por objetivo representar de manera concisa la estructura arquitectónica en términos de las aplicaciones de la UTPL, direccionarás así de manera general hechos de alto nivel relativos a ellas. De igual manera se hará una breve especificación de la tecnología usada como plataforma de dicho software, pero la misma deberá ser tratada a fondo en la plantilla para levantamiento de la capa de infraestructura tecnológica. 2 Matriz de sistemas existentes La especificación de la arquitectura de aplicaciones requiere un conocimiento previo de los sistemas preponderantes de la UTPL, así como información de en base a qué plataformas fueron desarrollados / adquiridos, esto servirá para dilucidar qué tipos de tecnologías son preponderantes en la institución, y determinar si van a la par con la tendencia del modelo actual de la UTPL usado para el desarrollo y uso de software. Dichos sistemas deberán ser tratados en una matriz siguiendo los esquemas propuestos a continuación: 2.1 Matriz de aplicaciones primarias El primer aspecto a conocer son las aplicaciones más grandes manejadas en la institución y que son de uso globalizado, ejemplos claros de ello son el sistema académico o el sistema financiero. El siguiente esquema servirá para la captura de los aspectos clave de dichos sistemas.

Elemento Sistemas Primarios Descripción Sistemas preponderantes y de uso generalizado en la UTPL Nombre Lenguaje de

desarrollo Creador Licenciamiento Descripción

2.2 Matriz de software secundario Es necesario también capturar información sobre sistemas usados de manera minoritaria, por determinadas áreas en la institución y que no son generalmente de uso globalizado, pero son de importancia para ciertas dependencias. Ejemplos claros de ello son el antivirus generalizado, -en redes- el software para filtrados de spam, -en el área de desarrollo- software para pruebas de software, etc. El siguiente esquema servirá para la captura de los aspectos clave de dicho software.


ORIENTADO A LA UTPL

EA – UTPL - 220 - | P á g i n a

Elemento Software secundario Descripción Productos de software o sistemas usados por áreas específicas o dentro de

sistemas primarios. Nombre de producto

Lenguaje de desarrollo

Creador Licenciamiento Descripción

3 Modelo de aplicaciones Especificará la estructura de la arquitectura del software en base a las tecnologías de uso actual en la UTPL. 3.1 Consolidación del lenguaje Esta sección permitirá especificar los productos usados para el desarrollo de software. Se entiende por preferidos a los productos de mayor uso y de difusión general dentro de la institución (Ejemplo: Microsoft.net), en cambio los soportados son tecnologías igualmente importantes pero sin uso tan robusto como las primarias (Ejemplo: PHP), y finalmente los soportados son tecnologías no preferidas pero que se utilizan de manera aislada (ejemplo: java JSPs)

Elemento Lenguaje de Desarrollo de Aplicaciones Descripción Clase Producto Notas Preferido Soportado Aceptable

3.2 Manejo de versión de código fuente Esta sección permitirá listar los productos de software o los mecanismos formales establecidos para realizar un control adecuado del verisonamiento del código fuente.

Elemento Manejo de Código Fuente Descripción Repositorio de manejo y rastreo de Código Fuente Clase Producto Notas Preferido Soportado Mantenimiento

3.3 Pruebas de código Las pruebas de código son esenciales puesto que permiten establecer métricas tanto de funcionalidad así como de calidad del mismo. Esta sección deberá recoger una lista de los paquetes de software y mecanismo utilizados para realizar pruebas (auditoria) del software desarrollado en la UTPL.

Elemento Pruebas Automatizadas Descripción Pruebas al Software para asegurar el rendimiento y la flexibilidad

adecuadas


ORIENTADO A LA UTPL

EA – UTPL - 221 - | P á g i n a

Clase Producto Notas Preferido Aceptable

3.4 Control de acceso La mayoría (por no decir la totalidad) de las aplicaciones desarrolladas manejan esquemas cliente/servidor y son manejadas como servicios web. Es por ello que se debe tomar también en cuenta los métodos formales de control de acceso utilizados por los desarrolladores para los usuarios (este es un aspecto clave de seguridad). El siguiente esquema puede ser tomado:

Elemento Manejo de Identidad Descripción Métodos o Protocolos para autenticación y acceso de usuario a las

aplicaciones Clase Producto Notas Preferido Soportado Candidato

3.5 Servidores de aplicaciones A nivel de servidores es necesario enlistar a alto nivel los tipos de tecnologías preferidos en la UTPL. Se entiende por preferidos a los productos de mayor uso en la institución (Ejemplo de referencia: Servidor web Tivoli, con un SO CentOS, plataforma x64, etc.), en cambio los soportados son tecnologías igualmente importantes pero sin uso tan robusto como las primarias, y finalmente los soportados son tecnologías no preferidas pero que se utilizan de manera aislada.

Elemento Modelo de software de Servidores Descripción El esquema de software usado para los Servidores Clase

Producto SO Plataforma de

hardware Descripción

Preferido Aceptable Soportado Prohibido

3.6 Clientes de aplicaciones A nivel de clientes es necesario enlistar a alto nivel los tipos de tecnologías preferidos en la UTPL. Se sigue el mismo criterio de clasificación para los clientes, con la diferencia de que por ejemplo uno de los productos preferidos es el SO Microsoft Windows XP, con plataforma x86 en computadores Xtratech, HP, etc.

Elemento Modelo de software de Clientes Descripción El esquema de software que manejan los clientes Clase

Producto SO Plataforma de

hardware Descripción

Preferido Aceptable Soportado


ORIENTADO A LA UTPL

EA – UTPL - 222 - | P á g i n a

Prohibido 4 Manejo de seguridad 4.2 Mecanismos de red de seguridad para los datos Especificar los mecanismos usados para salvaguardar la gestión de los datos tratados en las aplicaciones dentro de la red de la UTPL y desde fuera de ella. Dichos mecanismos incluyen cifrados por ejemplo. Se propone seguir el siguiente esquema:

Elemento Manejo de Identidad Descripción Métodos o Protocolos para autenticación y acceso de usuario a los

recursos dentro de la red usada por las aplicaciones Clase Producto Notas Preferido Soportado Candidato

4.3 Estándares de desarrollo Listar los estándares aplicados de manera limpia o que estén incluidos en los paquetes de software encargados de la gestión de la seguridad de las aplicaciones.


ORIENTADO A LA UTPL

EA – UTPL - 223 - | P á g i n a

5.5 Fase D: Arquitectura de Tecnología Al igual que las dos arquitecturas anteriores debe aportar a los objetivos de negocio mediante la descripción de la estructura de hardware, software y redes requerida para dar soporte a la implantación de las aplicaciones principales, de misión crítica, de la institución.

FasePreliminar



de Información

Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica


Fase D:Arquitectura

De Tecnología

5.5.1 Objetivos

• Asignar los componentes de aplicaciones (definidos en la fase C2) a un conjunto de componentes de tecnología, que representan los componentes de software y hardware.

• Definir la consolidación física de una solución arquitectónica. • Definir las vistas de portafolio tecnológico de línea base (actual) y la que se tiene por objetivo,

detallando el plan de actuación hacia la arquitectura objetivo. • Identificar los paquetes principales de trabajo en el plan de actuación. • Completar el conjunto de información arquitectónica y por lo tanto apoyar a la evaluación de

costos, en particular para los escenarios de migración. 5.5.2 Repositorio arquitectónico

Se debe considerar la relevancia de los recursos de arquitectura de tecnología que se encuentran disponibles en la institución. Deben existir servicios de TI y modelos dentro del repositorio,


ORIENTADO A LA UTPL

EA – UTPL - 224 - | P á g i n a

en el caso de los servicios son documentados en catálogos de servicios junto con modelos relevantes de tecnología y modelos técnicos referenciales. 5.5.3 Modelo técnico referencial

Interfaz de plataforma de Aplicaciones

Interfaz de Infraestructura de Comunicaciones

Aplicaciones Plataforma de Aplicaciones

Infraestructura de Comunicaciones

Figura 21: Modelo técnico referencial [1]

Partiendo desde una vista de alto nivel se evidencian tres entidades principales: software y plataforma de aplicaciones e infraestructura de comunicaciones; estas se encuentran conectadas por dos interfaces: la plataforma de aplicaciones y la infraestructura de comunicaciones. En base a esa estructura de comunicación el modelo técnico referencial pretende hacer hincapié en dos de los principales objetivos arquitectónicos comunes:

• Portabilidad: a través de la interfaz de la plataforma de aplicaciones identificar el conjunto de servicios que van a estar disponibles en una forma estándar de aplicaciones, a través de la plataforma.

• Interoperabilidad: a través de la interfaz de la infraestructura de comunicaciones, que identifica el conjunto de servicios de infraestructura de comunicaciones, éstos van a aprovecharse de una manera estándar por la plataforma.

Los objetivos son esenciales para permitir la integración dentro de la institución y la

interoperabilidad de confianza entre las instituciones (organizaciones). Para lograr lo propuesto en los objetivos es necesario tener un modelo técnico referencial detallado con un nivel de granulidad alto; así, se desprenden los componentes: modelo genérico, un conjunto idealizado de categorías de servicios, servicios adicionales que dan soporte a aplicaciones nativas de la institución, y demás que pueden observados en la siguiente ilustración.


ORIENTADO A LA UTPL

EA – UTPL - 225 - | P á g i n a

Figura 21: Modelo técnico referencial detallado [1]

5.5.4 Entradas

• Materiales arquitectónicos referenciales. • Información sobre productos candidatos.

5.5.4.1 No arquitectónicas



• Modelo organizacional para la EA. o Ámbito de aplicación de unidades de negocio afectadas. o Evaluación de madurez, brechas, y el enfoque de la resolución. o Funciones y responsabilidades para el equipo arquitectónico. o Restricciones sobre el trabajo arquitectónico. o Requisitos presupuestados.


ORIENTADO A LA UTPL

EA – UTPL - 226 - | P á g i n a

o Gobernanza y la estrategia de apoyo. • Framework arquitectónico adaptado.

o Método arquitectónico adaptado. o Contenido arquitectónico adaptado (Entregables y artefactos). o Herramientas configuradas y desplegadas.

• Principios de tecnología. • Estatuto de trabajo arquitectónico. • Visión arquitectónica. • Repositorio arquitectónico.

o Bloques constitutivos reutilizables. o Modelos de referencia disponibles públicamente. o Modelos de referencia específicos de la institución. o Estándares manejados en la institución.

• Borrador del documento de definición de la arquitectura. o Línea base de arquitectura de negocio. o Arquitectura de negocio objetivo. o Línea base de arquitectura de datos. o Arquitectura de datos objetivo. o Línea base de arquitectura de tecnología. o Arquitectura de tecnología objetivo.



5.5.5 Salidas

• Versiones actualizadas y refinadas de los entregables de fase de visión arquitectónica. o Estatuto de trabajo arquitectónico. o Principios, objetivos y conductores de negocio validados. o Principios arquitectónicos.

• Borrador del documento de definición de la arquitectura. o Arquitectura de tecnología objetivo. o Componentes tecnológicos y sus relaciones con los sistemas de información:

Plataformas tecnológicas y su descomposición: mostrando las combinaciones de la tecnología necesaria para adoptar una determinada “pila” de tecnología.

Ambientes y lugares: una agrupación de la tecnología necesaria en entornos de computación (por ejemplo, el desarrollo, producción).

Carga de procesamiento esperada y distribución de carga a través de componentes de tecnología.

Comunicaciones físicas (red). Especificaciones de hardware y de red.

o Línea base de arquitectura de tecnología.


ORIENTADO A LA UTPL

EA – UTPL - 227 - | P á g i n a

o Vistas correspondientes a los puntos de vista seleccionados que empaten con las expectativas clave de los stakeholders.

o Borrador de especificación de requisitos arquitectónicos. Resultados de análisis de brechas. Salida de requerimientos de las fases B y C. Requisitos de tecnología actualizados.

o Componentes arquitectónicos de tecnología de un plan de actuación de EA.


ORIENTADO A LA UTPL

EA – UTPL - 228 - | P á g i n a

5.5.6 Definición del proceso para la arquitectura de tecnología

El nivel de detalle dirigido en la fase D dependerá del alcance y los objetivos de los esfuerzos

de la arquitectura en general. Se deberá adaptar los pasos y su orden para satisfacer requisitos específicos de la institución. Definición de Procesos Proceso: FD – ArquitecturaTecnología: Levantamiento de la

arquitectura de tecnología Cod.Doc FD –

ArquitecturaTecnologíaX Responsable: ADD, ADS, DTE Versión: 1.0 Mantenimiento: DGTI, ADD Estado: Borrador

Publicado X

Descripción: Es el proceso por el cual se especifica la arquitectura de tecnología mediante la descripción de la estructura de hardware, software y redes requerida para dar soporte a la implantación de las aplicaciones principales, de misión crítica, de la institución.

Alcance: El proceso de la fase de arquitectura de tecnología, contempla los siguientes procedimientos:

• Describir la estructura de hardware. • Describir la estructura de software. • Describir la estructura de redes. • Consolidar el repositorio arquitectónico en base a las 4 dimensiones. • Especificar el portafolio tecnológico. • Identificar paquetes de trabajo. • Apoyar a la evaluación de costos.


No aplica






Listado de Cambios



Descripción

1.0 26/10/2010 DGTI, ADS, ADD, DTE,





ORIENTADO A LA UTPL

EA – UTPL - 229 - | P á g i n a

• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar la arquitectura de tecnología.

• Informar sobre la arquitectura de tecnología establecida y brindar soporte a la arquitectura de negocio.

Entradas:

Salidas:


• Información de producto sobre productos candidatos.

• Solicitud de trabajo arquitectónico. • Evaluación de la capacidad. • Plan de Comunicaciones. • Modelo Organizacional para la EA. • Framework arquitectónico adaptado. • Estatuto aprobado de trabajo arquitectónico. • Principios arquitectónicos de tecnología. • Visión arquitectónica. • Borrador del documento de definición de la



un plan de actuación arquitectónico. • Repositorio arquitectónico.



o Arquitectura de tecnología objetivo. o Componentes tecnológicos y sus

relaciones con los sistemas de información.

o Línea base de la arquitectura tecnológica.

o Vistas de los puntos de vista seleccionados que empaten con las expectativas clave de los stakeholders.

o Borrador de especificación de requisitos arquitectónicos.


Roles:

• ADS: Originar la arquitectura de tecnología. • ADD: Originar la arquitectura de tecnología. • DGTI: Dar soporte al proceso. • DTE: Brindar soporte para herramientas y metodologías de modelado de tecnología.


• Modelo Organizacional. • Framework arquitectónico. • Principios arquitectónicos de tecnología. • Estrategias, planes de negocio, políticas y marco jurídico relacionados a la tecnología. • Repositorio arquitectónico. • Línea base arquitectónica.

Tareas:

1. Seleccionar los modelos de referencia, puntos de vista y herramientas. 2. Desarrollar la descripción de la línea base de arquitectura de tecnología. 3. Desarrollar la descripción arquitectura de tecnología objetivo. 4. Realizar análisis de brechas. 5. Definir los componentes del plan de actuación. 6. Resolver los impactos a través de la perspectiva arquitectónica. 7. Realizar una revisión formal de los stakeholders. 8. Concluir la arquitectura de tecnología.


ORIENTADO A LA UTPL

EA – UTPL - 230 - | P á g i n a

9. Crear un documento de definición de la arquitectura.

Métricas:

• Capacidad de soporte para aplicaciones y datos. • Robustez del portafolio tecnológico.


Levantamiento de la arquitectura de tecnología. Objetivos del Procedimiento:

• Asignar los componentes de aplicación (definidos en la fase de arquitectura de aplicación) a un conjunto de componentes de tecnología, que representan los componentes de software y hardware

• Definir la realización física de una solución arquitectónica. • Definir las vistas de portafolio tecnológico de línea base (actual) y la

que se tiene por objetivo, detallando el plan de actuación hacia la arquitectura objetivo.

• Identificar los paquetes principales de trabajo en el plan de actuación.

• Completar el conjunto de información arquitectónica y por lo tanto apoyar a la evaluación de costos para los escenarios de migración en particular.



• ADS: Brindar una línea base de tecnología y establecer una arquitectura de tecnología objetivo.

• ADD: Brindar una línea base de tecnología y establecer una arquitectura de tecnología objetivo.


modelado de tecnología. Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a

continuación:

• Recoger, distribuir y delimitar información (artefactos) que lleven a consolidar la arquitectura de tecnología.

Entradas: • Materiales arquitectónicos referenciales. • Información de producto sobre productos candidatos. • Solicitud de trabajo arquitectónico. • Evaluación de capacidad. • Plan de comunicaciones. • Modelo organizacional para la EA.



arquitectónico. o Restricciones sobre el trabajo arquitectónico.


ORIENTADO A LA UTPL

EA – UTPL - 231 - | P á g i n a

o Requisitos presupuestados. o Gobernanza y la estrategia de apoyo.








C.





• Revisar y validar el conjunto de principios de tecnología. • Seleccionar recursos relevantes de arquitectura de tecnología

(modelos de referencia, patrones, etc.) desde el repositorio arquitectónico.

• Seleccionar los puntos de vista relevantes de la arquitectura de tecnología que le permitirán el arquitecto demostrar cómo las expectativas de los stakeholders se están abordando en esta capa arquitectónica.

• Identificar las herramientas y técnicas adecuadas para ser utilizadas en la captura, modelado y análisis de datos, en asociación con los puntos de vista seleccionados.

a. Luego se debe determinar el modelado de procesos globales a

través de la selección de los modelos necesarios para apoyar a cada punto de vista específico requerido, utilizando la herramienta o


ORIENTADO A LA UTPL

EA – UTPL - 232 - | P á g i n a

método seleccionado.

b. En base a lo anterior se desarrolla la arquitectura de tecnología que abarca:

• Definir una clasificación de servicios de plataforma y componentes

lógicos de tecnología (incluyendo estándares). • Identificar las locaciones relevantes en donde la tecnología es

desplegada. • Realizar un inventario físico de la tecnología desplegada y abstraerla

hasta que encaje con la clasificación. • Observar los requisitos de aplicaciones y de negocio para la

tecnología. • Analizar si está la tecnología en el lugar apto para el propósito de

satisfacer los nuevos requisitos. • Determinar la configuración de la tecnología seleccionada. • Determinar el impacto.

o Dimensionamiento y cálculo de costos. o Capacidad de planificación. o Instalación / gobierno / Impactos de migración.

c. Subsecuentemente se debe determinar el proceso de modelización

global en el que la arquitectura de tecnología puede ser impactada por decisiones anteriores realizadas en torno a la granularidad de servicio y nivel de detalle, así como los límites de servicio. Se debe considerar en este punto aspectos como:

• Rendimiento: servicios pesados (gruesos) contienen varias unidades

de funcionalidad con requisitos no funcionales potencialmente variables, por esta razón el rendimiento de plataforma debe ser considerada.

• Mantenimiento: si la granularidad de servicio es demasiada gruesa, se dificulta la introducción de cambios en los servicios y se afecta al mantenimiento del servicio, así como la plataforma en la que se encuentra.

• Ubicación y latencia: los servicios pueden interactuar entre sí a través de enlaces a distancia y la comunicación entre éstos está sometida siempre a latencia.

• Disponibilidad: la invocación de servicios está sujeta a fallas de red o de servicio, por ello un servicio para comunicaciones de alta disponibilidad es un factor importante durante la descomposición de servicios y la definición de granularidad de los mimos.

d. Algunos procesos de selección de productos pueden ocurrir dentro

de la fase de arquitectura de tecnología, así, productos existentes se vuelven a utilizar, la capacidad incremental se agrega, o las decisiones de selección de productos son restricciones durante el inicio del proyecto. Cuando la selección del producto se desvíe de


ORIENTADO A LA UTPL

EA – UTPL - 233 - | P á g i n a

las normas existentes, implique un gran esfuerzo, o tenga un impacto de amplio alcance, esta actividad deberá ser marcada (etiquetada) como una oportunidad y se dirigirá a través de la fase de oportunidades y soluciones.

Dentro de este mismo paso se debe identificar los catálogos requeridos de bloques constitutivos con respecto a la tecnología. Para ello deben considerarse que:

• Los catálogos son los inventarios de los activos principales de la institución.

• Los catálogos forman la materia prima para el desarrollo de matrices y diagramas, también actúan como un recurso clave para la gestión del portafolio de negocio y de la capacidad de TI.

• Se debe recoger una lista de los productos en uso, basada en los catálogos de tecnología existente así como el análisis de las aplicaciones realizado en la fase de arquitectura de aplicaciones.

• Si los requisitos identificados en la arquitectura de aplicaciones no son satisfechos por los productos existentes, se debe ampliar la lista de productos examinando los productos disponibles en el mercado que proporcionen la funcionalidad y cumplan con los estándares requeridos.

• Si las normas de la tecnología están en vigor, se aplican al catálogo de componentes de tecnología para obtener una visión inicial del cumplimiento de los estándares de tecnología.

• Crear catálogos. o Estándares de tecnología. o Portafolio de tecnología.

e. Al igual que con la fase anterior, para la arquitectura de tecnología

también se requiere identificar matrices requeridas, para ellos se debe tener en cuenta las mismas consideraciones planteadas en la fase C con respecto a las matrices.

f. Lo siguiente es identificar los diagramas requeridos, Al igual que en

la fase anterior se parte del hecho de conocer que los diagramas presentan información de la arquitectura de información desde un conjunto de perspectivas distintas que están dadas por los requerimientos de los stakeholders. La identificación debe estar fundada en tres aspectos:

• Para aplicaciones de línea de base principales o plataformas de

aplicaciones (donde múltiples aplicaciones se alojan en la misma pila de infraestructura), se debe producir un diagrama de pila que muestre cómo se combinan el hardware, sistema operativo, software de infraestructura y aplicaciones empaquetadas.

• Para cada entorno, se debe producir un diagrama lógico de la infraestructura de hardware y software que muestre el contenido del


ORIENTADO A LA UTPL

EA – UTPL - 234 - | P á g i n a

medio ambiente y de la comunicación lógica entre los componentes. De ser posible, cuando esté disponible, se debe recolectar la capacidad de recopilar información sobre la infraestructura desplegada.

• Para cada entorno, hay que producir un diagrama físico de la infraestructura de comunicaciones, tales como routers, switches, firewalls y los enlaces de red. De ser posible, se deberá recolectar la capacidad de recopilar información sobre la infraestructura de comunicaciones.

Los aspectos se resumen en un conjunto de diagramas a elaborarse:

• Diagrama de ambientes y lugares. • Diagrama de descomposición de la plataforma. • Diagrama de procesamiento. • Diagrama de red informática y de hardware. • Diagrama de ingeniería de comunicaciones.

g. La penúltima tarea dentro de este proceso es identificar los tipos de

requisitos que serán recogidos. Para ello es necesario tener desarrollados los catálogos, matrices y diagramas de la arquitectura de tecnología, así el modelado de arquitectura se verá completado con la formalización de los requisitos enfocados a los datos, implementando la arquitectura objetivo.

La implementación arquitectónica deberá recoger los mismos tipos de requerimientos especificados en las fases anteriores.

h. Finalmente se deben seleccionar los servicios tomando en consideración que los portafolios de servicios son combinaciones de servicios básicos que no causan conflictos, y están dados desde las categorías de servicios del modelo técnico referencial. Esto corresponde a:

• Requisitos para los elementos específicos de la institución o

decisiones pre-existentes. • Elementos pre-existentes e inmutables de la institución. • Restricciones heredadas del entorno externo.

Para cada bloque constitutivo, es necesario construir un portafolio de descripción de servicio como un conjunto de servicios no conflictivos. Dicho conjunto debe ser probado para asegurar que la funcionalidad proporcionada cumple con los requisitos de aplicación.

2. Desarrollar la descripción de la línea base de la arquitectura de tecnología.


ORIENTADO A LA UTPL

EA – UTPL - 235 - | P á g i n a

Se debe realizar en la medida necesaria para apoyar a la arquitectura de tecnología objetiva. El ámbito y nivel de detalle que se definan dependerán del grado en que los elementos de negocio existentes puedan ser transferidos a la arquitectura de negocio objetivo. Es necesario de igual manera identificar los bloques constitutivos relevantes de la arquitectura de tecnología, así como convertir la descripción del ambiente existente en términos de la arquitectura que busca la organización. Finalmente se debe establecer una lista de preguntas clave que puedan ser usadas luego en el proceso de desarrollo para medir la efectividad de la nueva arquitectura. Se logra una lista robusta a partir de hacer uso como guías los modelos identificados en el paso 1 de esta fase D, así se podrá crear nuevo contenido arquitectónico para describir la línea base arquitectónica.

3. Desarrollar la descripción de la arquitectura de tecnología objetivo. Desarrollar una descripción del objetivo para la arquitectura de tecnología sirve para apoyar la visión arquitectónica, a la arquitectura de negocio objetivo y arquitectura de sistemas de información objetivo. El ámbito de aplicación y nivel de detalle a definir dependerá de la relevancia de los elementos de negocio para alcanzar la visión arquitectónica objetivo. La conceptualización de bloques constitutivos es el proceso en la creación de un modelo arquitectónico amplio del sistema objetivo. Dichos bloques describen la funcionalidad y cómo éstos deben ser implementados sin un detalle dado por la configuración o el diseño detallado. Al igual que en el paso anterior, se podrá crear nuevo contenido arquitectónico para describir la línea base arquitectónica, al hacer uso de los modelos definidos en el paso 1 como guía, de esta forma, se pueden desarrollar nuevos modelos arquitectónicos para satisfacer a nuevas expectativas de los stakeholders (si fuese necesario).



• Analizar y dar importancia a los cambios de los puntos de vista representados en los modelos seleccionados desde el repositorio arquitectónico.



clasificándolos como modificado o sin cambios. o Identificar bloques constitutivos eliminados.


ORIENTADO A LA UTPL

EA – UTPL - 236 - | P á g i n a

o Identificar nuevos bloques constitutivos. o Identificar y clasificar brechas como aquellas que se deben


5. Definir los componentes del plan de actuación. Crea de un plan de actuación de negocios para dar prioridad a las actividades sobre las próximas etapas. El plan de actuación inicial de la arquitectura de tecnología será usado como materia prima, para apoyar la definición más detallada de un plan actuación consolidada e interdisciplinaria dentro de la fase de oportunidades y soluciones.

6. Resolver los impactos a través de la perspectiva arquitectónica. Implica comprender los impactos más amplios o las implicaciones de la propuesta de arquitectura de tecnología. Es necesario tener en consideración las preguntas:

• ¿Esta arquitectura de tecnología crea un impacto en cualquier arquitectura pre-existente?

• ¿Se han hecho cambios recientes que han impactado la arquitectura de tecnología?

• ¿Hay oportunidades para apalancar el trabajo de esta arquitectura de tecnología en otras áreas de la institución?

• ¿Tiene impacto esta arquitectura de tecnología en otros proyectos (incluidos los planeados, así como los actualmente en curso)?

• ¿Esta arquitectura de tecnología se verá afectada por otros proyectos (incluidos los planeados, así como los actualmente en curso)?


Comprueba la motivación original para el proyecto de EA, así como el estatuto de trabajo arquitectónico con respecto a la propuesta de arquitectura de tecnología. Mide si dicha motivación es adecuada para el propósito de apoyar al trabajo arquitectónico subsecuente en otros dominios.

8. Finalizar la arquitectura de tecnología. Selecciona las normas para cada uno de los bloques constitutivos re-usándolos cuanto más sea posible desde los modelos de referencia seleccionados desde el repositorio arquitectónico. Este paso permite:

• Documentar cada bloque constitutivo. • Conducir una validación cruzada final de la arquitectura global contra

los objetivos de negocio. • Documentar las razones para formalizar las decisiones por bloques

constitutivos en el documento arquitectónico. Identificar qué bloques


ORIENTADO A LA UTPL

EA – UTPL - 237 - | P á g i n a

especificados pueden ser reutilizados (prácticas de trabajo, roles, relaciones de negocio, descripciones de roles, etc.).

• Documentar un reporte de trazabilidad de requisitos finales. • Documentar la asignación final de la arquitectura dentro del

repositorio arquitectónico y publicarlo a través de este. • Completar todos los productos de trabajo, tales como resultados de


9. Crear un documento de definición arquitectónica. Implica documentar las razones para la existencia de las decisiones de bloques constitutivos en el documento de definición de la arquitectura. Prepara las secciones de negocio del documento de definición de arquitectura abarcando:

• Atributos y funcionalidad fundamentales: semántica sin ambigüedades, incluyendo capacidad de seguridad y manejabilidad.

• Bloques constitutivos dependientes con la funcionalidad requerida y las interfaces nombradas.

• Interfaces: la configuración elegida, suministrada por (APIs, datos de mercado, protocolos, interfaces de hardware, estándares).

• Asignación de entidades de negocio y organizativas, así como políticas.

Para demostrar las vistas clave de la arquitectura es necesario hacer uso de reportes o modelos gráficos generados por herramientas EA. Esto sustentará el hecho de encaminar al documento para su revisión por stakeholders relevantes, obteniendo como beneficio una retroalimentación robusta.


o Estatuto de trabajo arquitectónico. o Principios, objetivos y conductores de negocio validados. o Principios arquitectónicos.

• Borrador del documento de definición de la arquitectura. o Arquitectura de tecnología objetivo. o Componentes tecnológicos y sus relaciones con los

sistemas de información: Plataformas tecnológicas y su descomposición:

mostrando las combinaciones de la tecnología necesaria para adoptar una determinada “pila” de tecnología.

Ambientes y lugares: una agrupación de la tecnología necesaria en entornos de computación (por ejemplo, el desarrollo, producción).

Carga de procesamiento esperada y distribución de carga a través de componentes de tecnología.

Comunicaciones físicas (red).


ORIENTADO A LA UTPL

EA – UTPL - 238 - | P á g i n a

Especificaciones de hardware y de red. o Línea base de arquitectura de tecnología. o Vistas correspondientes a los puntos de vista seleccionados

que empaten con las expectativas clave de los stakeholders.

o Borrador de especificación de requisitos arquitectónicos. Resultados de análisis de brechas. Salida de requerimientos de las fases B y C. Requisitos de tecnología actualizados.



• Informar sobre la arquitectura de aplicaciones establecida y brindar soporte a la arquitectura de tecnología.


• Capacidad de soporte para aplicaciones y datos. • Robustez del portafolio tecnológico.


ORIENTADO A LA UTPL

EA – UTPL - 239 - | P á g i n a

5.5.7 Plantillas para la fase de la arquitectura tecnológica

5.5.7.1 Plantilla para especificación de la arquitectura de tecnología

Especificación de Arquitectura Tecnológica


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propóstito de este documento 2 Matriz de sistemas existentes 3 Modelo de aplicaciones 4 Manejo de seguridad Información del documento



Preparado por:


Título: Especificación de Arquitectura de Aplicaciones

Fecha de Versión:

Revisado por:

Fecha de Revisión:






ORIENTADO A LA UTPL

EA – UTPL - 240 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito Este documento tiene por objetivo representar de manera concisa la estructura arquitectónica tecnológica la cual describe la estructura de hardware, software y redes requerida para dar soporte a la implantación de las aplicaciones principales de la UTPL, de misión crítica dentro de la institución. 2 Infraestructura tecnológica de software Esta información debe estar especificada tanto para la arquitectura de aplicaciones como para de la de tecnología, el desglose de esta sección se refiere solo a tecnologías preponderantes de la UTPL (a diferencia de la plantilla de arquitectura de aplicaciones que lleva un listado más amplio), así como información de en base a qué plataformas fueron desarrollados / adquiridos, esto servirá para dilucidar qué tipos de tecnologías son preponderantes en la institución, y determinar si van a la par con la tendencia del modelo tecnológico que se propone con EA-UTPL. Dichos sistemas deberán ser tratados en una matriz siguiendo los esquemas propuestos a continuación:

Elemento Tecnologías de software primario Descripción Tecnologías de software usadas por sistemas preponderantes y de uso

generalizado en la UTPL Clase Producto Notas Preferido Aceptable Soportado

3 Infraestructura tecnológica de hardware Especificará la estructura de la arquitectura del software en base a las tecnologías de uso actual en la UTPL. Es una ampliación de la breve especificación de estructura física propuesta en la arquitectura de aplicaciones. 3.1 Servidores de aplicaciones A nivel de servidores es necesario enlistar a alto nivel los tipos de tecnologías preferidos en la UTPL. Esta sección abarca netamente aspectos físicos (de hardware) y para cada uno de los tipos de servidores se debe llena el esquema propuesto por la tabla a continuación:

Elemento Servidor de Aplicaciones, Web , de Archivos, etc. Descripción


ORIENTADO A LA UTPL

EA – UTPL - 241 - | P á g i n a

Clase Producto Notas Preferido Aceptable Soportado solo por aplicaciones aprobadas

De igual manera es necesario conocer a nivel de servidores las arquitecturas -de software base- más utilizadas así como el nombre de los sistemas operativos preferidos. Para ello es necesario utilizar la estructura propuesta a continuación:

Elemento Sistema Operativo de Servidores Descripción El Usado para los Servidores Clase Producto Arquitectura Notas Preferido Aceptable Soportado Mantenimiento Prohibido

3.6 Clientes de aplicaciones A nivel de clientes es necesario enlistar a alto nivel los tipos de tecnologías preferidos en la UTPL. Se sigue el mismo criterio de clasificación para los clientes, con la diferencia de que por ejemplo uno de los productos preferidos es el SO Microsoft Windows XP, con plataforma x86 en computadores Xtratech, HP, etc.

Elemento Computadoras clientes Descripción Computadoras personas que consumen y/o accesan a las aplicaciones /

datos Clase Producto Notas Preferido Aceptable Soportado solo por aplicaciones aprobadas

De igual manera es necesario conocer a nivel de clientes las arquitecturas -de software base- más utilizadas así como el nombre de los sistemas operativos preferidos. Para ello es necesario utilizar la estructura propuesta a continuación:

Elemento Sistema Operativo de Clientes Descripción El Usado para los Clientes Clase Producto Arquitectura Notas Preferido Aceptable Soportado Mantenimiento Prohibido


ORIENTADO A LA UTPL

EA – UTPL - 242 - | P á g i n a

4 Infraestructura tecnológica de red 4.1 Modelo de Red Especificar el esquema estructural (diagrama) de red manejado en la UTPL. 4.2 Protocolos de Red Listar los principales protocolos utilizados junto con una breve descripción de cada uno de ellos.

Elemento Protocolos de red Descripción Clase Producto Notas Preferido Aceptable Soportado solo por aplicaciones aprobadas

4.3 Dispositivos y administración de Dominios y Subdominios

Elemento Mecanismo de administración de dominios y subdominios Descripción Clase Producto Notas Preferido Aceptable Soportado solo por aplicaciones aprobadas

4.4 Servidores, otros dispositivos no de usuario final y aplicaciones intensivas de Red

Elemento Otros mecanismos de red Descripción Clase Producto Notas Preferido Aceptable Soportado solo por aplicaciones aprobadas

4.5 Manejo de Acceso a la Red Especificar mecanismo de acceso.


ORIENTADO A LA UTPL

EA – UTPL - 243 - | P á g i n a

4.6 Cableado de Red Especificar le tipo de cableado. 4.7 Red Inalámbrica Especificar el esquema de manejo de la red inalámbrica de la UTPL 4.8 Servicio de Telefonía Especificar cómo se maneja la central PBX de la UTPL a breves rasgos y como el sistema Asterix gestiona todo lo referente a este punto


ORIENTADO A LA UTPL

EA – UTPL - 244 - | P á g i n a

5.6 Fase E: Oportunidades y Soluciones

Esta fase principalmente permite determinar qué partes se comprarán, construirán o reutilizarán y cómo se implementará la arquitectura establecida en la fase D.

FasePreliminar



de Información

Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica


Fase E:Oportunidades y Soluciones

5.6.1 Objetivos

• Revisar los objetivos de la arquitectura de negocio objetivo y las capacidades, la consolidación de las brechas de las fases B a la D, y luego organizar grupos de bloques constitutivos para hacer frente a estas capacidades.

• Revisar y confirmar los parámetros actuales de la institución y la capacidad de absorber el cambio.

• Derivar una serie de arquitecturas de transición que proporcionen un continuo valor de negocio (por ejemplo, incrementos de capacidad) a través del aprovechamiento de las oportunidades para realizar los bloques constitutivos.

• Generar y obtener un consenso sobre un esquema de implementación y estrategia de migración.

5.6.2 Entradas

• Materiales arquitectónicos referenciales. • Información de producto sobre productos candidatos.


ORIENTADO A LA UTPL

EA – UTPL - 245 - | P á g i n a

5.6.2.1 Entradas no arquitectónicas


5.6.2.2 Entradas arquitectónicas







• Componentes de arquitectura de negocio de un plan de actuación arquitectónico. 5.6.3 Salidas


ORIENTADO A LA UTPL

EA – UTPL - 246 - | P á g i n a

• Versiones actualizadas y refinadas de los entregables de la visión arquitectónica, arquitectura de negocio, de sistemas de información, y de tecnología.

o Declaración de trabajo arquitectónico. o Visión arquitectónica, incluida la definición de tipos y grados de interoperabilidad. o Borrador del documento de definición de la arquitectura.

Identificación de los incrementos. Interoperabilidad y co-existencia de requisitos. Inclusión de la lista de proyectos y cartas proyecto.

• Plan de actuación de la arquitectura consolidado y validado. • Evaluación de la capacidad. • Perfil de madurez de la EA. • Reporte de preparación para transformación. • Arquitectura de transición.

o Brechas consolidadas, soluciones y evaluación de dependencias. o Registro de riesgos. o Análisis del impacto. o Reporte de análisis de dependencia. o Evaluación del factor de implementación y de la matriz de deducción.

• Implementación y plan de migración incluyendo la estrategia de implementación y migración.


ORIENTADO A LA UTPL

EA – UTPL - 247 - | P á g i n a

5.6.4 Definición del proceso de la fase de oportunidades y soluciones Definición de Procesos Proceso: FE – OportunidadesSoluciones: Delimitación de

oportunidades y soluciones. Cod.Doc FE –

OportunidadesSolucionesX Responsable: CIO, DEA, ADD, ADS, DTE , CSI Versión: 1.0 Mantenimiento: DGTI, ADD, ADS, DTE, CSI Estado: Borrador

Publicado X

Descripción: Es el proceso por el cual se describe las oportunidades y soluciones inherentes a la arquitectura que permitirán determinar qué partes se comprarán, construirán o reutilizarán y cómo se implementará la arquitectura establecida en la fase D.

Alcance: El proceso de la fase de oportunidades y soluciones, contempla los siguientes procedimientos:

• Determinar que componentes (artefactos) se comprarán, construirán o reutilizarán.

• Definir como se implementarán las 4 capas arquitectónicas. • Organizar los bloques constitutivos. • Consolidar las brechas de las fases anteriores. • Consolidar la arquitectura de negocio objetivo y las capacidades institucionales. • Validar los parámetros institucionales y la capacidad para absorber el cambio. • Generar una estrategia de migración.


No aplica






Listado de Cambios



Descripción

1.0 26/10/2010 DGTI, ADS, ADD, DTE, DEA, CSI




• Recoger, distribuir y delimitar información (artefactos) que lleven a un adecuado

• Generar un plan de implementación y un esquema inicial de migración robustos que


ORIENTADO A LA UTPL

EA – UTPL - 248 - | P á g i n a

esquema de implementación de la EA así como una buena estrategia de migración.

permitan cumplir los objetivos de negocio.

Entradas:

Salidas:

• Materiales arquitectónicos referenciales. • Información de producto sobre productos

candidatos. • Solicitud de trabajo arquitectónico. • Evaluación de capacidad. • Plan de comunicaciones. • Modelo organizacional para la EA. • Framework arquitectónico adaptado. • Principios de tecnología. • Estatuto de trabajo arquitectónico. • Visión arquitectónica. • Repositorio arquitectónico. • Borrador del documento de definición de la



un plan de actuación arquitectónico

• Versiones actualizadas y refinadas de los entregables de la visión arquitectónica, arquitectura de negocio, de sistemas de información, y de tecnología.

• Plan de actuación de la arquitectura consolidado y validado.

• Evaluación de la capacidad. • Perfil de madurez de la EA. • Reporte de preparación para transformación. • Arquitectura de transición.


Roles:

• ADS: Consolidar la arquitectura para su implementación. • ADD: Consolidar la arquitectura para su implementación. • DGTI: Dar soporte al proceso, preparar el esquema de gobernanza. • DTE: Brindar soporte para herramientas y metodologías que ayuden a la implementación y migración. • CSI: Analizar y evaluar los mecanismos más adecuados para dar soporte a la implementación y

migración. • DEA: Consolidar los aspectos anteriores y empatarlos (pulirlos) para que se alineen mejor a los

objetivos del negocio.


• Modelo Organizacional. • Framework arquitectónico. • Principios arquitectónicos detallados. • Repositorio arquitectónico. • Línea base arquitectónica. • Arquitectura objetivo.

Tareas:

1. Determinar o confirmar los atributos clave de cambio corporativo. 2. Determinar las restricciones de negocio para la implementación. 3. Revisar y consolidar los resultados del análisis de brechas desde las fases B hasta la D. 4. Revisión de los requisitos de TI desde una perspectiva funcional. 5. Consolidar y conciliar los requisitos de interoperabilidad. 6. Refinar y validar las dependencias. 7. Confirmar la preparación y el riesgo de transformación del negocio.


ORIENTADO A LA UTPL

EA – UTPL - 249 - | P á g i n a

8. Formular una estrategia de alto nivel para implementación y migración. 9. Identificar y agrupar los paquetes de trabajo principales. 10. Identificar arquitecturas de transición. 11. Crear cartas de portafolio y de proyectos, y actualizar arquitecturas.

Métricas:

• Capacidades de reutilización de componentes, de absorción del cambio y de implementación de capas.

• Grado de consolidación de brechas, de la EA objetivo y las capacidades institucionales.


Delimitación de oportunidades y soluciones. Objetivos del Procedimiento:

• Revisar los objetivos de la arquitectura de negocio objetivo y las capacidades, la consolidación de las brechas de las fases B a la D, y luego organizar grupos de bloques constitutivos para hacer frente a estas capacidades.

• Revisar y confirmar los parámetros actuales de la institución y la capacidad de absorber el cambio.

• Derivar una serie de arquitecturas de transición que proporcionen un continuo valor de negocio (por ejemplo, incrementos de capacidad) a través del aprovechamiento de las oportunidades para realizar los bloques constitutivos.

• Generar y obtener un consenso sobre un esquema de implementación y estrategia de migración.



• ADS: Consolidar la arquitectura para su implementación. • ADD: Consolidar la arquitectura para su implementación. • DGTI: Dar soporte al proceso, preparar el esquema de gobernanza. • DTE: Brindar soporte para herramientas y metodologías que ayuden

a la implementación y migración. • CSI: Analizar y evaluar los mecanismos más adecuados para dar

soporte a la implementación y migración. • DEA: Consolidar los aspectos anteriores y empatarlos (pulirlos) para

que se alineen mejor a los objetivos del negocio. Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a

continuación:

• Recoger, distribuir y delimitar información (artefactos) que lleven a un adecuado esquema de implementación de la EA así como una buena estrategia de migración.

Entradas: • Materiales arquitectónicos referenciales. • Información de producto sobre productos candidatos. • Solicitud de trabajo arquitectónico. • Evaluación de capacidad. • Plan de comunicaciones. • Modelo organizacional para la EA.


ORIENTADO A LA UTPL

EA – UTPL - 250 - | P á g i n a











C.




1. Determinar o confirmar los atributos clave de cambio corporativo.

a. Crear una evaluación del factor de implementación y una matriz de deducción.

La matriz debe incluir una lista de los factores a ser considerados, sus descripciones, y las deducciones que indiquen las acciones o restricciones que deben ser tomadas en consideración al momento de formular los planes. Eso asegura que los factores relevantes son considerados y documentados, integrándolos como parte del plan de implementación y migración, aportando


ORIENTADO A LA UTPL

EA – UTPL - 251 - | P á g i n a

al especificar en el documento el por qué de las razones para las decisiones clave tomadas en la arquitectura.

b. Evaluar las capacidades de transición institucionales y de organizaciones asociadas.

• Evaluar el impacto institucional en la configuración de la arquitectura

de transición. • Evaluar la asignación de responsabilidades dentro de la institución

para la implementación, por lo que la EA se atrinchera dentro de la institución.

• Evaluar las influencias culturales de la institución para el manejo de cambio.

• Documentar en la evaluación del factor de implementación y en la matriz de deducción.

c. Evaluar las capacidades de transición de la institución y de

las unidades TI de negocio. Es necesario establecer una revisión de los planes estratégicos corporativos y de negocios con el fin de validar los conductores fundamentales de negocio para la EA, así esta explícitamente puede enfocarse en cada uno de ellos. Se podría tener un impacto importante en las arquitecturas de transición y el correspondiente plan de implementación y migración asociado a ellas. Cada uno de los conductores de negocio debe ser evaluado con respecto a los hechos de implementación, y documentado en la evaluación del factor de implementación y en la matriz de deducción.

2. Determinar las restricciones de negocio para la implementación.

a. Revisión del plan estratégico corporativo.

• Realizar una evaluación de la institución y en concreto la unidad de negocio de TI.

• Evaluar la institución, su cultura y la unidad de negocio de TI. • Evaluar el conjunto de habilidad personal de la institución para

determinar si el entrenamiento y/o asistencia contratada y/o subcontratación puede ser necesaria en ciertas áreas.

• Realizar un análisis de brecha entre la línea de base de la arquitectura y la arquitectura objetivo.

• Documentar en la evaluación del factor de implementación y en la matriz de deducción.

b. Revisión de la evaluación de madurez de la EA.

• Revisar la evaluación de madurez de la EA que se llevó a cabo en la

fase preliminar.


ORIENTADO A LA UTPL

EA – UTPL - 252 - | P á g i n a

• Actualizar la evaluación del factor de implementación y la matriz de deducción con las acciones, actividades, iniciativas y proyectos que tienen llevarse a cabo.

c. Revisión corporativa de línea de los planes estratégicos de

negocio.

• Realizar una revisión de la línea de negocios estratégica y de los planes de negocio con el fin de identificar las iniciativas, portafolios, proyectos o actividades que podrían ser aprovechados para acelerar el paso a la arquitectura.

• Determinar si existen iniciativas que podrían crear problemas para la implementación de la EA.

• Documentar todos los factores y las acciones deducidas en la evaluación del factor de implementación y en la matriz de deducción.

3. Revisar y consolidar los resultados del análisis de brechas desde las fases B hasta la D.

a. Crear brechas consolidadas, soluciones y una matriz de dependencias.

Se debe agrupar las brechas identificadas en los resultados del análisis de brechas para el dominio de la arquitectura y evaluar las posibles soluciones, así como las dependencias para una o varias brechas. Lo anterior permite la identificación de bloques constitutivos de solución (SBBs, por sus siglas en inglés), los cuales podrían potencialmente abordar una o más de las brechas y sus asociados bloques constitutivos arquitectónicos (ABBs, por sus siglas en inglés).

b. Revisar la Fase B, C, D y sus resultados de análisis de brechas.

• Consolidar los resultados de análisis de brechas de cada una de las

fases de la arquitectura en una larga lista que se convertirá en la base de la estructura de división del trabajo.

• Identificar posibles soluciones a las deficiencias y dependencias.

c. Racionalizar las brechas consolidadas, soluciones, la matriz de dependencias.

• Reorganizar la lista de brechas y colocarlas como ítems juntos.

4. Revisión de los requisitos de TI desde una perspectiva funcional.

a. Evaluar los requisitos de TI desde una perspectiva


ORIENTADO A LA UTPL

EA – UTPL - 253 - | P á g i n a

funcional.

• Revisar toda la información adquirida hasta ahora para determinar si las soluciones a las brechas pueden ser funcionalmente consolidadas.

• Evaluar la arquitectura objetivo, las brechas consolidadas, soluciones, la matriz de dependencias, y la evaluación del factor de implementación para la verificación y revisión respectiva.

• Consolidar los requisitos funcionales y los grupos al mismo tiempo a actuar como la base de paquetes de trabajo.

• Acotar las brechas consolidadas, soluciones y matriz de dependencias, listando las nuevas brechas que formarán la base de paquetes de trabajo.

b. Determinar cuestiones (hechos) asociados con la

integración funcional.

• Evaluar los requisitos para determinar si misma funcionalidad es requerida (y posiblemente la entregada) en muchos lugares diferentes.

• Analizar la arquitectura objetivo, pues ofrece una solución integrada con poco o ninguna redundancia, pero puede ser problemática la integración de los requisitos y la financiación asociada a menudo por las líneas de negocio.

• Deben documentarse en la evaluación del factor de implementación y en la matriz de deducción.

5. Consolidar y conciliar los requisitos de interoperabilidad.

a. Consolidar los requisitos de interoperabilidad.

• Consolidar la visión arquitectónica y la arquitectura objetivo, así como la evaluación del factor de implementación, matriz de deducción, brechas consolidadas, soluciones, y la matriz de dependencias.

• Revisar para buscar todas las limitaciones sobre la interoperabilidad requerida por el conjunto de posibles soluciones.

b. Conciliar los requisitos de interoperabilidad con soluciones

potenciales.

• Asegurarse de que no hay conflictos de interoperabilidad. • Centrarse en el hecho más significativo: interoperabilidad de

negocio. • Revisar los procesos de negocio integrados en la arquitectura

objetivo y ver si pueden ser alineados con los procesos de otro fabricante/proveedor de productos o servicios.

• Analizar que los cambios en los procesos de negocio integrados a menudo requieren mucho trabajo, con respecto a las ventajas de la


ORIENTADO A LA UTPL

EA – UTPL - 254 - | P á g i n a

reutilización de soluciones, estas se perderán. • Asegurarse de que cualquier cambio en la arquitectura objetivo, o

producto de otro fabricante/proveedor de servicios, sea firmado por los arquitectos de negocio y los patrocinadores de arquitectura en un estatuto revisado de trabajo arquitectónico.

6. Refinar y validar las dependencias.

a. Evaluar dependencias de negocio.

Las dependencias de negocios son asuntos fuera del dominio de TI que afectan a la prestación exitosa de servicios de TI. Para manejarlas se debe considerar el desarrollo profesional y capacitación para implementar, operar y mantener la capacidad de TI, tanto en el contexto técnico como en el de negocio. En esta fase se deben manejar procesos que permitan el uso de la capacidad de TI (en términos de negocio) mediante la creación de flujos de trabajo, procesos y mecanismos de gobernanza para garantizar que los recursos de TI puedan ser debidamente aprovechados. Es importante recalcar que el desarrollo y uso de los recursos de TI también es guiado por políticas, incluso de carácter legislativo.

b. Evaluar dependencias de la Información. Se debe evaluar las dependencias de información para garantizar que los recursos de TI y los sistemas que crean los datos correspondan a los que utilizan los datos. Esto se puede lograr a través del desarrollo de una secuencia de información para los proyectos.

c. Evaluar dependencias de flujo de trabajo. Las dependencias de flujo de trabajo de negocio incluyen aquellos que garantizan que los procesos de trabajo se apoyen de una manera lógica, para dichos flujos puedan ser implementadas de manera gradual. Para lograrlo se requiere coordinar una serie de proyectos y los incrementos de proyecto para ofrecer un valor de negocio de forma continua. Un flujo de trabajo completamente implementado e ideal podría ser precedido por un flujo abreviado, centrado en lo crítico o de alto rendimiento de los procesos de inversión.

d. Evaluar dependencias de TI. Las dependencias de TI incluyen las actividades fuera del portafolio de TI, donde los recursos de TI y los sistemas son fundamentales para el logro de las capacidades de negocio. Con este paso se consolida una evaluar de dependencias que como salida devolverá la validación de las mismas.


ORIENTADO A LA UTPL

EA – UTPL - 255 - | P á g i n a

e. Evaluar las dependencias de fondo y capacidades

temporales. Las dependencias de fondo incluyen la evaluación de los recursos necesarios, determinando la manera de implementación óptima dentro de las limitaciones de la capacidad de la institución para crear y absorber el cambio. Una provisión continua de las capacidades de negocio puede requerir la creación de SBBs provisionales o parciales. A este nivel la EA implica un diseño de arriba hacia abajo y un implementación de abajo hacia arriba. Así, las dependencias de fondo resaltarán el impacto de las decisiones hechas, y el alcance de rehacer el trabajo que deben tenerse en cuenta en el proyecto EA final formalmente establecido.

f. Racionalizar y consolidar dependencias.

• Integrar las dependencias, muchas de las cuales se han repetido en las diferentes áreas.

• Incluir dichas dependencias en un reporte de análisis de dependencias que será parte de la documentación de la implementación y del plan de migración.

7. Confirmar la preparación y el riesgo de transformación del negocio.

Siempre se deben estimar los riesgos asociados con cualquier esfuerzo de transformación, es importante identificar, clasificar y mitigarlos antes de empezar, para que puedan ser rastreados a través de cualquier esfuerzo de transformación específica. En la EA, la distancia más corta entre dos puntos (la línea de base y arquitectura objetivo) no puede ser una línea recta, sino una vía más indirecta que la institución puede negociar de manera realista. Para ello es necesario considerar:

• Evaluar la disposición de la institución para someterse a los cambios

de transformación de negocio necesarios para aprovechar la EA. • Evaluar la capacidad de la institución para adaptarse al cambio y la

captura de los riesgos asociados. La evaluación de la preparación para la transformación de negocio debió haberse llevado a cabo en la Fase A.

• Revisar los resultados y determinar el impacto de éstos sobre la transición de la arquitectura.

• Determinar enfoques de implementación que serán cultural y técnicamente viables, tanto para el éxito táctico como el estratégico.

8. Formular una estrategia de alto nivel para implementación y


ORIENTADO A LA UTPL

EA – UTPL - 256 - | P á g i n a

migración.

a. Determinar la dirección general de ejecución estratégica.

• Determinar qué enfoque estratégico será tomado para implementar la arquitectura objetivo. Los stakeholders necesitan saber cómo se van a alcanzar los objetivos estratégicos.

• Asegurarse de que arquitectura objetivo no se descompone en una serie de proyectos que proceden de manera independiente con resultados desafortunados.

• En este punto existen tres enfoques básicos: o Desde cero (greenfield): empezar desde el principio. o Revolucionario: aplicar un cambio radical (encender,

apagar), para ello necesita de aumento importante de recursos (un sistema doble/sombra).

o Evolutivo: incluye la estrategia de convergencia, en el cual un enfoque por fases es necesario para introducir la mayoría de las capacidades.

• Colaborar con los stakeholders institucionales para seleccionar un enfoque de transformación y, a continuación para asegurar que los recursos serán proveídos para apoyar su implementación.

b. Determinar el enfoque de implementación.

Un enfoque de implementación aborda cómo la dirección estratégica de implementación se va a ejecutar, para proporcionar orientación tanto a los arquitectos y líderes de proyecto o portafolio por igual. Una recomendación común de metodología de implementación incluye:

• Éxito rápido (instantáneas). • Objetivos alcanzables. • Método del valor de cadena. • Llegar a un acuerdo sobre la implementación y la estrategia de

migración para la institución.

9. Identificar y agrupar los paquetes de trabajo principales.

a. Identificar los paquetes de trabajo principales.

• Examinar la evaluación del factor de implementación y la matriz de deducción, así como brechas consolidadas, soluciones, la matriz de dependencias y añadir detalles sobre mecanismo de solución propuesto.

• Tener una sesión de trabajo con los arquitectos de dominio y el personal de gestión de operaciones para determinar la que potencialmente sería la mejor solución.

• Indicar por cada brecha o actividad si la solución debe estar orientada hacia:


ORIENTADO A LA UTPL

EA – UTPL - 257 - | P á g i n a

o Nuevo desarrollo. o Un producto y/o solución existente que se puede comprar y

sobre la cual se puede basar la solución. • Actualizar brechas consolidadas, soluciones y la matriz de

dependencias a detalle, abarcando a las soluciones propuestas. • Clasificar todos los sistemas actuales como:

o Sistemas comerciales: parte del sistema de información en el futuro.

o Sistemas de contención: que se espera sean reemplazados o modificados en el horizonte de planificación (tres años).

o Reemplazar sistemas: para ser reemplazados en el horizonte de planificación.

b. Analizar los paquetes de trabajo con respecto a la

transformación del negocio.

• Evaluar las actividades relacionadas a la transformación de negocio y agruparlas como posibles proyectos.

• Reagrupar paquetes de trabajo con respecto a las dependencias (incluyendo flujo de trabajo) y usar ese análisis final como base para la identificación de proyectos.

• Escribir la carta de proyecto y los estatutos del alcance, completar la estimación inicial de recursos (por ejemplo, magnitud). Ello se debe hacer una vez que los proyectos hayan sido identificados.

• Buscar un alto retorno de proyectos de inversión, para identificarlos como potenciales conquistadores que devuelvan éxito temprano.

• Verificar que los requisitos específicos de la organización han sido cumplidos.

• Contrastar los paquetes con el escenario de negocios original, conduciendo al alcance de los proyectos.

10. Identificar arquitecturas de transición.

a. Identificar la arquitectura de transición e incrementos de

capacidad. La mayoría de los desafíos en la creación y absorción de cambio, son desafíos basados en la madurez de la institución, éstos son expresados en las barreras culturales y de la institución ante el cambio. La creación de incrementos de capacidad le permitirá a la institución identificar las actividades y los resultados que se pueden agrupar, así como en qué orden deben ser entregados. La consecución debe estar conformada por:

• Revaluar las capacidades de negocios pendientes, señalados en la visión arquitectónica y arquitectura objetivo.

• Desglosar esas capacidades objetivo en incrementos de capacidad, teniendo cada uno valores de negocio claramente identificados y mesurables.


ORIENTADO A LA UTPL

EA – UTPL - 258 - | P á g i n a

• Desglosar el apoyo a proyectos de alto nivel en incrementos para ofrecer incrementos de capacidad.

• Determinar dónde se encuentran las actividades más difíciles. • Centrarse en actividades que más fácil entreguen falta de capacidad,

para poder resolverlas.

b. Agrupar portafolios y proyectos en incrementos.

• Tomar la secuencia de actividades, los resultados y los grupos de los medios de entrega (de portafolios y proyectos) en incrementos, especificando lo que debe ser entregado en cada incremento. Los proyectos deben dividirse en incrementos, basados en las prestaciones requeridas, para cada una de las arquitecturas de transición.

11. Crear cartas de portafolio y de proyectos, y actualizar arquitecturas.

a. Crear cartas de portafolio.

Para ello se debe revisar y consolidar el portafolio, las cartas proyecto potencialmente importantes y garantizar que sus resultados arquitectónicos estén claramente definidos. Dichos resultados arquitectónicos brindarán portafolios en un contexto institucional y determinarán el ajuste y el valor de los entregables para ser usados en la gobernanza.

b. Crear cartas del proyecto.

• Revisar y consolidar las cartas de proyecto. • Asegurarse de que sus resultados arquitectónicos están claramente

definidos.

c. Crear arquitecturas de transición. Las arquitecturas de transición será la base para el planeamiento de migración en la Fase C. Deben tener un conjunto claro de los resultados y una especificación medio de entrega usado, por ello debe ser expresada en un nivel similar de detalle como el documento de definición de la arquitectura.

d. Realizar actualizaciones generales de la arquitectura.

• Actualizar la visión arquitectónica con las decisiones de políticas de interoperabilidad.

• Identificar todas las capacidades de negocio que se implementarán.


ORIENTADO A LA UTPL

EA – UTPL - 259 - | P á g i n a

Salidas: • Versiones actualizadas y refinadas de los entregables de la visión arquitectónica, arquitectura de negocio, de sistemas de información, y de tecnología.

o Declaración de trabajo arquitectónico. o Visión arquitectónica, incluida la definición de tipos y grados

de interoperabilidad. o Borrador del documento de definición de la arquitectura.

Identificación de los incrementos. Interoperabilidad y co-existencia de requisitos. Inclusión de la lista de proyectos y cartas proyecto.

• Plan de actuación de la arquitectura consolidado y validado. • Evaluación de la capacidad. • Perfil de madurez de la EA. • Reporte de preparación para transformación. • Arquitectura de transición.

o Brechas consolidadas, soluciones y evaluación de dependencias.

o Registro de riesgos. o Análisis del impacto. o Reporte de análisis de dependencia. o Evaluación del factor de implementación y de la matriz de

deducción.



• Generar un plan de implementación y servir como base para crear un esquema de migración robusto que permitan cumplir los objetivos de negocio.


• Capacidad de reutilización de componentes. • Capacidad de implementación de las 4 capas arquitectónicas. • Grado de consolidación de brechas. • Grado de consolidación de la arquitectura de negocio objetivo y las

capacidades institucionales. • Capacidad de absorción del cambio.


ORIENTADO A LA UTPL

EA – UTPL - 260 - | P á g i n a

5.6.5 Plantillas para la fase de oportunidades y soluciones

5.6.5.1 Plantilla para levantamiento de: Arquitectura de transición

Arquitectura de Transición


_________________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito 2 Portafolio de Oportunidades 3 Portafolio de Paquetes de Trabajo 4 Hitos e Hitos de Transición Arquitectónica 5 Evaluación de Factores de Implementación 6 Consolidación, Carencias y Soluciones Información del documento



Preparado por:


Título: Arquitectura de Transición Fecha de Versión: Revisado por:

Fecha de Revisión:






ORIENTADO A LA UTPL

EA – UTPL - 261 - | P á g i n a

Historial de Revisión del Documento Nro. de Versión

Fecha de Versión


1 Propósito Una Arquitectura de Transición muestra la empresa en sus estados incrementales reflejando periodos de transición que quedan entre la línea base y la arquitectura objetivo. Las Arquitecturas de Transición son usadas para permitir que los paquetes de trabajos individuales y proyectos sean agrupados en portafolios administrados, ilustrando el valor del negocio en cada etapa. 2 Portafolio de Oportunidades 2.1 Brechas consolidadas Una vez identificados en las fases anteriores claramente los desafíos que existen actualmente en la TI actual de la UTPL y que obstaculizan la capacidad de la universidad para cumplir su plan estratégico de negocios, se determina las diferencias entre la solución básica de los productos / servicios de uso de la UTPL y las necesidades de la misma, especificando las brechas críticas y planteando una solución para cada una. En este aspecto se puede tomar como ejemplo tres errores cometidos por la institución cuando adquiere una herramienta de software:

• Adquirir tecnología que no cumple con los requerimientos y por lo tanto es insuficiente para cumplir su labor. • Adquirir tecnología que excede los requerimientos y por lo tanto es desperdiciada en la compañía. • Adquirir tecnología que combina los dos males anteriores en uno solo. Este es el más común.

Mayor información disponible en la parte 5.1.6 de este capítulo. 2.2 Descripción de oportunidades

Implica listar todos aquellos eventos del medio ambiente externo que de presentarse, facilitarían el logro de los objetivos propuestos para el levantamiento de la EA.

2.3 Evaluación de beneficio Se define como una disciplina formal (técnica) a utilizarse para evaluar, o ayudar a evaluar, en este caso a EA-UTPL, y en sí es un proceso conocido como evaluación de proyectos. Esta sección debe listar los beneficios identificados para los usuarios del proyecto. Es recomendable adoptar un análisis costo – beneficio para esta sección, se identifican todos los beneficios del proyecto (resultados favorables) y sus perjuicios o contrabeneficios (resultados no favorables) para el usuario. También debemos considerar las consecuencias indirectas relacionadas con el proyecto, los llamados efectos secundarios. 2.4 Capacidades e incrementos de capacidad Como se dijo en secciones anteriores se utilizan las evaluaciones de capacidad para analizar las cargas de capacidad de la UTPL. Para esta sección se debe determinar como a través del proyecto se ha visto la evolución y el incremento de la


ORIENTADO A LA UTPL

EA – UTPL - 262 - | P á g i n a

capacidad institucional, así, la capacidad disponible y la necesidad de capacidad / incremento de capacidad se pueden seleccionar según los diversos criterios y acumulaciones utilizando una retícula de período. 3 Portafolio de Paquetes de Trabajo Un paquete de trabajo es una descripción cuantitativa y cualitativa de una operación que va a llevarse a cabo en el proyecto, por ejemplo, el trabajo que se ha de realizar y el resultado que se desea obtener en una tarea claramente definida dentro del proyecto. 3.1 Descripción del Paquete de Trabajo Se deben listar los paquetes de trabajo, tomando como esquema:

ID Nombre Descripción Objetivos Entregables

PQT_001

PQT_002

PQT_nN

3.2 Requerimientos Funcionales Se deben listar los requerimientos funcionales asociados a los paquetes de trabajo, para ello es necesario tomar el esquema del catálogo de los artefactos inherentes a esta fase, para ello se recomienda ver el Anexo 1.2. Sin embargo el esquema es similar al de los paquetes de trabajo anteriores. 3.3 Dependencias Se deben listar las dependencias existentes entre los paquetes de trabajo, usando el mismo esquema anterior. 3.4 Relaciones con las oportunidades Se deben trazar las relaciones existentes entre los paquetes de trabajo con respecto a las oportunidades descritas en esta misma plantilla. 3.5 Relaciones con el documento de definición arquitectónica Se deben trazar las relaciones existentes entre los paquetes de trabajo con respecto a los objetivos propuestos en el documento de definición arquitectónica. 3.6 Relaciones con la especificación de requisitos de la arquitectura Se deben trazar las relaciones existentes entre los paquetes de trabajo con respecto a los requisitos capturados para la arquitectura. 4 Hitos e Hitos de transición arquitectónica


ORIENTADO A LA UTPL

EA – UTPL - 263 - | P á g i n a

4.1 Definición de estados de transición Se deben listar los estados inherentes a la transición, para ello es recomendable utilizar marcas para el esquema WBS especificado en secciones anteriores. 4.2 Arquitectura del negocio para cada estado de transición Se debe trazar y especificar cómo se verá afectada la arquitectura de negocio para cada estado en el cual la arquitectura sea levantada progresivamente, para lograr la transición línea base – arquitectura objetivo. Se recomienda usar el siguiente esquema:

Ítem de negocio afectado Estado de transición Fecha <Especifica el área de negocio o aspecto afectado.>

<Puntualiza un estado concreto de la transición que ha producido algún efecto sobre la arquitectura de negocio.>

<de revisión>

4.3 Arquitectura de datos para cada estado de transición Se debe trazar y especificar cómo se verá afectada la arquitectura de datos para cada estado en el cual la arquitectura sea levantada progresivamente, para lograr la transición línea base – arquitectura objetivo (de arquitectura de datos). Se recomienda usar el siguiente esquema:

Ítem de datos afectado Estado de transición Fecha <Especifica el área de datos o aspecto afectado.>

<Puntualiza un estado concreto de la transición que ha producido algún efecto sobre la arquitectura de datos.>

<de revisión>

4.4 Arquitectura de aplicaciones para cada estado de transición Se debe trazar y especificar cómo se verá afectada la arquitectura de aplicaciones para cada estado en el cual la arquitectura sea levantada progresivamente, para lograr la transición línea base – arquitectura objetivo (de arquitectura de aplicaciones). Se recomienda usar el siguiente esquema:

Ítem de negocio afectado Estado de transición Fecha <Especifica el área de aplicaciones o aspecto afectado.>

<Puntualiza un estado concreto de la transición que ha producido algún efecto sobre la arquitectura de aplicaciones.>

<de revisión>

4.5 Arquitectura tecnológica para cada estado de transición Se debe trazar y especificar cómo se verá afectada la arquitectura tecnológica para cada estado en el cual la arquitectura sea levantada progresivamente, para lograr la transición línea base – arquitectura objetivo (de la arquitectura tecnológica). Se recomienda usar el siguiente esquema:

Ítem de tecnología afectado Estado de transición Fecha <Especifica el área de tecnología o aspecto afectado.>

<Puntualiza un estado concreto de la transición que ha producido algún efecto sobre la arquitectura de tecnología.>

<de revisión>


ORIENTADO A LA UTPL

EA – UTPL - 264 - | P á g i n a

5 Evaluación de factores de implementación Especifica cada uno de los motivos por los cuales se verá determinara y directamente afecta la implementación de la EA a través de la ejecución secuencial y ordenada de los paquetes de trabajo. Estos factores incluyen: 5.1 Riesgos Especificar cada uno de los riesgos que vayan a darse durante la implementación. 5.2 Supuestos Especificar cada uno de los supuestos que vayan a darse durante la implementación. 5.3 Dependencias Especificar cada una de las dependencias existentes entre los recursos que vayan a servir dentro de la fase de implementación de la EA. 5.4 Acciones Especificar a manera de lista cada uno de los procedimientos que se ejecutarán para llevar a cabo la tarea de la implementación. 6 Brechas consolidadas y soluciones Ayudará a superar las brechas existentes y a estar preparados para afrontar supuestas brechas que afronte la institución en el futuro. 6.1 Dominio de la arquitectura Especificar el dominio de la arquitectura descrito en fases anteriores, modificando las áreas en las que una brecha haya causado influencia en algún hecho. 6.2 Brechas Listar las brechas que son susceptibles de solución inmediata 6.3 Soluciones potenciales Listar las potenciales soluciones globales para una / un grupo de brechas. 6.4 Matriz de dependencias Un modelo puede tener docenas o cientos de paquetes y miles de clases. La cantidad de dependencias en un modelo mediano o grande por lo tanto es muy alta (miles o más). Para simplificar la representación e interpretación de las dependencias en un modelo, se define la Matriz de Dependencias (MD).


ORIENTADO A LA UTPL

EA – UTPL - 265 - | P á g i n a

Las filas y las columnas de la MD corresponden a los paquetes y/o las clases del modelo. El número en las celdas representan los pesos de dependencias entre los elementos-columnas y elementos-filas.


ORIENTADO A LA UTPL

EA – UTPL - 266 - | P á g i n a

5.6.5.2 Plantilla para levantamiento de: Plan de implementación y migración

Plan de Implementación y Migración


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de este documento 2 Estrategia de Implementación y Migración 3 Interacción con otras Gestiones de Frameworks 4 Cartas del Proyecto 5 Plan de Implementación Información del documento



Preparado por:


Título: Plan de Implementación y Migración Fecha de Versión: Revisado por:

Fecha de Revisión:







ORIENTADO A LA UTPL

EA – UTPL - 267 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito de este documento <<Proveer un horario de implementación de la solución descrita por una Arquitectura de Transición. La Implementación y Plan de Migración incluyen sincronización, costo, recursos, beneficio e hitos de la implementación.>> 2 Estrategias de implementación y migración Esta sección debe ser llenada con una introducción a lo referente a este punto, por ejemplo: Consiste en la planificación de mecanismos que garanticen la implementación de la arquitectura y la migración de la misma, logrando con ello una adecuada adopción y un reajuste cíclico a nuevas expectativas arquitectónicas. 2.1 Dirección de implementación estratégica Abordar cómo se va a llevar a cabo la implementación resaltando aspectos estratégicos orientados a salvaguardar la integridad de la EA durante su proceso de implementación. 2.2 Aproximación de Secuencias de implementación Modelar el flujo de trabajo con cada una de las iteraciones dadas para la fase de implementación. 2.3 Delimitación de enfoque de migración Sugerir el esquema de migración que mejor se adapte al proyecto EA-UTPL. 3 Integración con otros frameworks de gestión 3.1 Alineación de arquitectura y planificación del negocio Delimitar el enfoque de la alineación de arquitectura al modelo actual de la UTPL para que no hayan dependencias ni brechas en el momento de implementar, también dicho enfoque deberá asegurar que la EA se acomode a la planeación estratégica del negocio con vista a futuro. 3.2 Alineación de arquitectura y administración de portafolio / proyecto Delimitar el enfoque de la alineación de arquitectura al modelo actual de gestión de portafolio y de proyectos de la UTPL. Esta sección debe especificar cómo la EA empatará dentro de la gestión de proyectos y de portafolio


ORIENTADO A LA UTPL

EA – UTPL - 268 - | P á g i n a

institucional. 3.3 Alineación de arquitectura y administración de operaciones Delimitar el enfoque de la alineación de arquitectura al modelo actual de gestión de operaciones de la UTPL. 4 Plan de Implementación Esta sección está descrita en el capítulo, en donde se sugiere un plan de implementación. Por lo que se sugiere remitirse a dicho capítulo para mayor información. 4. 1 Fases y desglose de flujo de trabajo Copiar la matriz de implementación dada en el capítulo 6, o de ser necesario reestructurarla como se considere conveniente. 4.2 Ubicación de paquetes de trabajo EN base a la matriz, sacar los paquetes de trabajo requeridos durante la implementación. 4.3 Hitos y Sincronización Revisar matriz de implementación del capítulo 6. 4.4 Estructura del desglose de trabajo Revisar matriz de implementación del capítulo 6. 4.5 Requerimientos de recursos y costos

Revisar matriz de implementación del capítulo 6.


ORIENTADO A LA UTPL

EA – UTPL - 269 - | P á g i n a

5.7 Fase F: Plan de Migración

Esta fase sirve como base para poder priorizar los proyectos y mediante esa estratificación jerárquica poder desarrollar el plan de migración final.

FasePreliminar



de Información

Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica


Fase F:Plan de

Migración

5.7.1 Objetivos

• Garantizar que el plan de implementación y migración se coordina con los frameworks de gestión diferentes en uso dentro de la institución.

• Dar prioridad a todos los paquetes de trabajo, proyectos y bloques constitutivos mediante la asignación de valor de negocio a todos y llevar a cabo un análisis de coste/negocio.

• Finalizar los documentos de la visión arquitectónica y de definición de la arquitectura, de acuerdo con el enfoque de implementación acordado.

• Confirmar las arquitecturas de transición definidas en la fase E con los stakeholders relevantes.

• Crear, desarrollar y supervisar el plan detallado de implementación y migración que proporcione los recursos necesarios para permitir la realización de las arquitecturas de transición, tal como se definen en la Fase E.

• Centrarse en la creación de un plan de implementación y migración viables, en colaboración con los gestores de portafolio y de proyectos.

• Evaluar las dependencias, los costos y beneficios de los proyectos de migración.


ORIENTADO A LA UTPL

EA – UTPL - 270 - | P á g i n a

• Tener una lista de proyectos priorizados, esta formará la base del plan de implementación y migración detallado.

• Suplementar la arquitectura con el portafolio y los detalles a nivel del proyecto, para asignar tareas a los recursos específicos.

• Coordinar de manera estricta el plan de implementación y migración, con ello se logrará darle el valor de negocio requerido a la institución, y que los recursos estén disponibles para completar el trabajo necesario.

• Establecer ciclo de evolución de la arquitectura para garantizar que esta se mantiene relevante, y con ello se debe documentar las lecciones aprendidas durante el proyecto para permitir la mejora continua de procesos.

5.7.2 Entradas

• Materiales arquitectónicos referenciales externos a la institución. • Materiales arquitectónicos de referencia.

5.7.2.1 No arquitectónicas




• Modelos y frameworks de gobernanza. o Framework de gestión de la EA. o Framework de gestión de la capacidad. o Framework de gestión de portafolio. o Framework de gestión de proyecto. o Framework de gestión de operaciones.


• Principios de tecnología.


ORIENTADO A LA UTPL

EA – UTPL - 271 - | P á g i n a

• Estatuto de trabajo arquitectónico. • Visión arquitectónica. • Repositorio arquitectónico.


• Borrador del documento de definición de la arquitectura. o Plan estratégico de migración. o Línea base de arquitectura de negocio. o Arquitectura de negocio objetivo. o Línea base de arquitectura de datos. o Arquitectura de datos objetivo. o Línea base de arquitectura de aplicaciones. o Arquitectura de aplicaciones objetivo. o Línea base de arquitectura de tecnología. o Arquitectura de tecnología objetivo. o Análisis de impacto: cartas y listas de proyecto.

• Borrador de la especificación de requerimientos de la arquitectura. o Requerimientos arquitectónicos. o Resultados de análisis de brechas (de arquitectura de negocio, datos, aplicaciones y

tecnología). • Gestión de integración de requisitos de TI. • Solicitud de cambio para los programas de negocios y proyectos existentes. • Plan de actuación arquitectónico. • Evaluación de la capacidad.

o Perfil de madurez de la EA. o Informe de preparación para la transformación.

• Arquitectura de transición. o Brechas consolidadas, soluciones y evaluación de las dependencias. o Registro de riesgos. o Análisis del impacto: lista de proyecto. o Informe análisis de la dependencia. o Evaluación del factor de implementación y de la matriz de deducción.

• Plan de implementación y migración incluyendo las estrategias de implementación y migración a un alto nivel.

5.7.3 Salidas

• Plan de implementación y migración. • Documento terminado de definición de la arquitectura. • Especificación terminada de requerimientos de la EA. • Plan de actuación de la EA terminado.


ORIENTADO A LA UTPL

EA – UTPL - 272 - | P á g i n a

• Arquitectura de transición terminada. • Bloques constitutivos arquitectónicos reutilizables. • Solicitudes de trabajo arquitectónico para los aspectos de la arquitectura en cuanto a

implementación de proyectos. • Acuerdos (contratos) de la arquitectura para implementación de proyectos. • Modelo de Implementación de gobernanza. • Solicitudes de cambio que surgen de las lecciones aprendidas.


ORIENTADO A LA UTPL

EA – UTPL - 273 - | P á g i n a

5.7.4 Definición de proceso para la fase de migración

Definición de Procesos Proceso: FF – PlanMigración: Definición del plan de migración. Cod.Doc FF –

PlanMigraciónX Responsable: CIO, DEA, ADD, ADS, DTE , CSI Versión: 1.0 Mantenimiento: DGTI, ADD, ADS, DTE, CSI Estado: Borrador

Publicado X

Descripción: Es el proceso por el cual se describe como se debe definir el plan de migración de la arquitectura.

Alcance: El proceso de la fase de migración, contempla los siguientes procedimientos:

• Coordinar, evaluar y validar la coordinación del plan de implementación y migración con los frameworks de gestión.

• Priorizar paquetes de trabajo, proyectos y bloques constitutivos. • Finalizar la visión arquitectónica. • Finalizar la definición de la arquitectura. • Establecer un ciclo de evolución arquitectónico. • Confirmar las arquitecturas de transición de la fase E.


No aplica






Listado de Cambios



Descripción

1.0 26/10/2010 DGTI, ADS, ADD, DTE, DEA, CSI


A. Resumen del Proceso



• Validar la información (artefactos) recogidos por las arquitecturas de transición para la implementación y migración exitosa.

• Generar un plan de de migración robusto que permita hacer un uso adecuado de la gobernanza a establecerse en la siguiente fase.

Entradas: Salidas:


ORIENTADO A LA UTPL

EA – UTPL - 274 - | P á g i n a

• Materiales arquitectónicos referenciales

externos a la institución. • Materiales arquitectónicos de referencia. • Solicitud de trabajo arquitectónico. • Evaluación de capacidad. • Plan de comunicaciones. • Modelo organizacional para la EA. • Modelos y frameworks de gobernanza. • Framework arquitectónico adaptado. • Principios de tecnología. • Estatuto de trabajo arquitectónico. • Visión arquitectónica. • Repositorio arquitectónico. • Borrador del documento de definición de la


requerimientos de la arquitectura. • Gestión de integración de requisitos de TI. • Solicitud de cambio para los programas de

negocios y proyectos existentes. • Plan de actuación arquitectónico. • Evaluación de la capacidad. • Arquitectura de transición.


• Plan de implementación y migración. • Documento terminado de definición de la

arquitectura. • Especificación terminada de requerimientos

de la EA. • Plan de actuación de la EA terminado. • Arquitectura de transición terminada. • Bloques constitutivos arquitectónicos

reutilizables. • Solicitudes de trabajo arquitectónico para los

aspectos de la arquitectura en cuanto a implementación de proyectos.

• Acuerdos (contratos) de la arquitectura para implementación de proyectos.

• Modelo de Implementación de gobernanza.

• Solicitudes de cambio que surgen de las lecciones aprendidas.

Roles:

• ADS: Consolidar la arquitectura para su migración. • ADD: Consolidar la arquitectura para su migración. • DGTI: Dar soporte al proceso, preparar el esquema de migración y gobernanza. • DTE: Brindar soporte para herramientas y metodologías que ayuden al plan de migración. • CSI: Analizar y evaluar los mecanismos más adecuados para dar soporte al plan de migración. • DEA: Consolidar los aspectos anteriores y empatarlos (pulirlos) para que se alineen mejor a los

objetivos del negocio. • CIO: Difundir el proyecto de migración de la arquitectura.


• Modelo Organizacional. • Framework arquitectónico. • Documento de definición de la arquitectura. • Repositorio arquitectónico. • Arquitectura objetivo.

Tareas:

1. Confirmar las interacciones del framework de gestión para el plan de integración y migración. 2. Darle un valor de negocio a cada proyecto.


ORIENTADO A LA UTPL

EA – UTPL - 275 - | P á g i n a

3. Estimar las necesidades de recursos, tiempos del proyecto, y la disponibilidad así como los medios de entrega.

4. Priorizar la migración de proyectos a través de una evaluación y validación de riegos a nivel de costo/beneficio.

5. Confirmar los incrementos y fases de la arquitectura de transición y actualizar los documentos de definición de la arquitectura.

6. Generar un plan de actuación para la implementación de la EA y el plan de migración. 7. Establecer el ciclo de evolución de la EA y documentar las recomendaciones producto de la

experiencia con el proyecto.

Métricas:

• Capacidad de coordinación. • Grados de satisfacción de la EA.


Definición del plan de migración. Objetivos del Procedimiento:

• Garantizar que el plan de implementación y migración se coordina con los frameworks de gestión diferentes en uso dentro de la institución.

• Dar prioridad a todos los paquetes de trabajo, proyectos y bloques constitutivos mediante la asignación de valor de negocio a todos y llevar a cabo un análisis de coste/negocio.

• Finalizar los documentos de la visión arquitectónica y de definición de la arquitectura, de acuerdo con el enfoque de implementación acordado.

• Confirmar las arquitecturas de transición definidas en la fase E con los stakeholders relevantes.

• Crear, desarrollar y supervisar el plan detallado de implementación y migración que proporciona los recursos necesarios para permitir la realización de las arquitecturas de transición, tal como se definen en la Fase E.

• Centrarse en la creación de un plan de implementación y migración viables, en colaboración con los gestores de portafolio y de proyectos.

• Evaluar las dependencias, los costos y beneficios de los proyectos de migración de varios.

• Tener una lista de proyectos priorizados, esta formará la base del plan de Implementación y migración detallado.

• Suplementar de la arquitectura con el portafolio y los detalles a nivel del proyecto, para asignar tareas a los recursos específicos.

• Coordinar de manera estricta el plan de implementación y migración, con ello se logrará darle el valor de negocio requerido a la institución, y que los recursos estén disponibles para completar el trabajo necesario.

• Establecer ciclo de evolución de la arquitectura para garantizar que esta se mantiene relevante, y con ello se debe documentar las lecciones aprendidas durante el proyecto para permitir la mejora


ORIENTADO A LA UTPL

EA – UTPL - 276 - | P á g i n a

continua de procesos. Roles y Responsabilidades:


• ADS: Consolidar la arquitectura para su migración. • ADD: Consolidar la arquitectura para su migración. • DGTI: Dar soporte al proceso, preparar el esquema de migración y

gobernanza. • DTE: Brindar soporte para herramientas y metodologías que ayuden

al plan de migración. • CSI: Analizar y evaluar los mecanismos más adecuados para dar

soporte al plan de migración. • DEA: Consolidar los aspectos anteriores y empatarlos (pulirlos) para

que se alineen mejor a los objetivos del negocio. • CIO: Difundir el proyecto de migración de la arquitectura.

Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a continuación:

• Validar la información (artefactos) recogidos por las arquitecturas de transición para la implementación y migración exitosa.

Entradas: • Materiales arquitectónicos referenciales externos a la institución. • Materiales arquitectónicos referenciales. • Solicitud de trabajo arquitectónico. • Evaluación de capacidad. • Plan de comunicaciones.

• Modelo organizacional para la EA. o Ámbito de aplicación de unidades de negocio afectadas. o Evaluación de madurez, brechas, y el enfoque de la



• Modelos y frameworks de gobernanza. o Framework de gestión de la EA. o Framework de gestión de la capacidad. o Framework de gestión de portafolio. o Framework de gestión de proyecto. o Framework de gestión de operaciones.




o Bloques constitutivos reutilizables.


ORIENTADO A LA UTPL

EA – UTPL - 277 - | P á g i n a

o Modelos de referencia disponibles públicamente. o Modelos de referencia específicos de la institución. o Estándares manejados en la institución.

• Borrador del documento de definición de la arquitectura. o Plan estratégico de migración. o Línea base de arquitectura de negocio. o Arquitectura de negocio objetivo. o Línea base de arquitectura de datos. o Arquitectura de datos objetivo. o Línea base de arquitectura de aplicaciones. o Arquitectura de aplicaciones objetivo. o Línea base de arquitectura de tecnología. o Arquitectura de tecnología objetivo. o Análisis de impacto: cartas y listas de proyecto.

• Borrador de la especificación de requerimientos de la arquitectura. o Requerimientos arquitectónicos. o Resultados de análisis de brechas (de arquitectura de

negocio, datos, aplicaciones y tecnología). • Gestión de integración de requisitos de TI. • Solicitud de cambio para los programas de negocios y proyectos

existentes. • Plan de actuación arquitectónico. • Evaluación de la capacidad.

o Perfil de madurez de la EA. o Informe de preparación para la transformación.

• Arquitectura de transición. o Brechas consolidadas, soluciones y evaluación de las

dependencias. o Registro de riesgos. o Análisis del impacto: lista de proyecto. o Informe análisis de la dependencia. o Evaluación del factor de implementación y de la matriz de

deducción.



Los pasos necesarios para este procedimiento se listan a continuación: 1. Confirmar las interacciones del framework de gestión para el plan de

implementación y migración. En principio se debe establecer lo que el plan de implementación y migración debe incluir y garantizar que su especificación coordine con los frameworks. Para poder lograr esto, es necesario que cuatro frameworks de gestión trabajen conjuntamente:

• Planeación de negocios: concibe, dirige y proporciona los recursos para todas las actividades necesarias que permitirán alcanzar los objetivos y resultados de negocio.

• Arquitectura empresarial: estructura y da contexto a todas las actividades institucionales obteniendo resultados concretos de


ORIENTADO A LA UTPL

EA – UTPL - 278 - | P á g i n a

negocio, principalmente pero no exclusivamente en el dominio de TI. La gobernanza de TI aborda muchos de estos requisitos.

• Gestión de proyectos/portafolio: coordina, diseña y construye los sistemas de negocio que entregan los resultados concretos de negocio.

• Gestión de operaciones: integra, opera y mantiene los entregables que ofrecen los resultados concretos de negocio.

El plan de implementación y migración tendrán impacto en todos los frameworks, por lo tanto, tiene que estar reflejado en cada uno de ellos. De ello deriva la importancia de entender los frameworks dentro de la organización y asegurar que los planes están coordinados e insertados dentro de los planes de cada uno de estos frameworks.

a. Alinear en plan de implementación y migración con la planeación de negocio/capacidad.

• Alinear el plan con la estrategia de negocio y los planes de todos los

aspectos de la organización. • Ver los planes estratégicos y de negocio desde la perspectiva de la

arquitectura para determinar la aptitud para este propósito. • Determinar lo que se puede aprovechar de los planes estratégicos y

de negocio, así como lo que tiene que ser insertado como una adición a estos planes en el ciclo de próximo lanzamiento.

• Centrarse en la entrega de valor mensurable, así como en un valor de negocio incremental al final de cada arquitectura de transición.

b. Examinan los aspectos transformación del negocio.

• Abordar la transformación del negocio empatada con la planeación

estratégica de negocio. • Enfocarse en dos componentes principales: la transformación del

negocio dentro y fuera de la línea de servicio. • Considerar que los cambios en el impacto de las infraestructuras

operacionales de TI impactarán al plan de implementación y migración.

• El capital humano es fundamental en una economía basada en el conocimiento y la aceptación de los cambios no puede darse por sentada implícitamente.

• Nuevos procesos, consultas del personal y el reentrenamiento son críticos para el éxito de la EA.

c. Evaluar la sincronización de la EA y del framework de

planificación de TI existente. El plan de implementación y migración es a menudo un subconjunto de los planes corporativos estratégicos de TI de negocios. La sincronización es esencial y la necesidad de que continúe alineado el proyecto, desembocará


ORIENTADO A LA UTPL

EA – UTPL - 279 - | P á g i n a

en un cambio importante en el enfoque de trabajo para los planificadores de proyectos acostumbrados a trabajar sin un framework EA. El enfoque EA proporcionará un contexto para las actividades y los criterios de gobernanza esenciales que deben aplicarse, es crítico asegúrese de que el plan de implementación y migración estén bien posicionados dentro del plan de negocio de TI.

d. Alinear el plan de implementación y migración con el framework de gestión de proyectos.

Cada organización tiene una metodología de entrega y la mayoría tiene algún tipo de framework de gestión de portafolio y de proyectos a diferentes niveles de madurez. El plan de implementación y migración adhiere más detalle a cómo la arquitectura objetivo se logrará a través de la gestión de cambio. Es vital recordar en este paso que el documento de definición de la arquitectura proporciona un análisis de brechas, la línea base arquitectónica, arquitectura objetivo, y las dependencias entre los bloques constitutivos.

e. Alinear el plan de implementación y migración con un framework de gestión de operaciones.

La función de gestión de operaciones ejecuta la infraestructura de la organización y el tiempo en que un artefacto es manejado por dicha infraestructura, esto se da a nivel de control y gestión de la configuración. Dicha función ha estado estrechamente involucrada en el establecimiento de la línea de base arquitectónica y han sido solicitadas para emitir recomendaciones para la arquitectura objetivo. El plan de implementación y migración tiene que atender al grupo de gestión de operaciones y se encargará de la coordinación de la gestión de la configuración de artefactos.

f. Establecer planes para la gestión de la EA. El plan de implementación y migración se encuentra en la intersección de numerosos frameworks técnicos y de gestión. Es por ello que el framework EA (establecido en la fase preliminar) debe reflejar las interacciones así como la necesidad de declarar explícitamente cómo la arquitectura ha de implementarse y luego migrarse.

2. Darle un valor de negocio a cada proyecto.

a. Confirmar el valor de negocio institucional, el retorno de la Inversión, y otros parámetros de medición del rendimiento.

• Garantizar que los parámetros de valor de negocio estén bien

entendidos y sirvan de base para la creación y seguimiento del plan


ORIENTADO A LA UTPL

EA – UTPL - 280 - | P á g i n a

de implementación y migración. • Habilitar la generación de continuo valor de negocio, aun admitiendo

que esto podría implicar rehacer conjuntos subsecuentes de entregables.

• Establecer un conjunto concreto de criterios con los que evaluar el valor de negocio, el retorno de la inversión, y las medidas para determinar cómo el proyecto está cumpliendo con sus objetivos. Esto implica considerar:

o Criterios de evaluación de rendimiento, los cuales son utilizados por los gestores de portafolios y de capacidad, para aprobar y supervisar el progreso de la transformación de la arquitectura.

o Criterio de retorno de la inversión, tiene que ser detallado y firmado por stakeholders ejecutivos.

o El valor de negocio tiene que ser bien definido. o Factores Clave de Éxito (CSF, por sus siglas en inglés),

deben ser establecidos para definir el éxito de un proyecto y / o incremento de los proyectos.

o Medidas de Efectividad (MOE), a menudo son criterios de rendimiento y muchas instituciones los incluyen los CSFs.

o Encaje estratégico basado en la EA en general (todos los niveles), será el factor crítico para permitir la aprobación de cualquier nueva iniciativa (proyecto o iniciativa) para determinar el valor de cualquier entregable.

b. Asignar de riesgos a los proyectos y a los incrementos del proyecto.

Abarca agregar la totalidad de riesgos asociados a cada actividad para los proyectos y sus posibles incrementos en las brechas consolidadas, soluciones, y evaluación de dependencias (de la fase E).

c. Darle valor de negocio a los proyectos y los incrementos del proyecto.

Ayuda a desarrollar un valor estimado al negocio para cada proyecto. Debe ser completado con una entrada de gestión de negocio, dada por el arquitecto empresarial, asegurando con ello dar un alto valor de negocio, lo que segura que la infraestructura de TI sea bien entendida.

d. Determinar una técnica de evaluación del valor continuo de

negocio. La evaluación debe ser desarrollada a través del uso de matrices basadas en una dimensión de valores con índices y una dimensión de riegos con índices respectivamente. Ello ha de aplicarse para ambos casos, tanto clientes como la TI.


ORIENTADO A LA UTPL

EA – UTPL - 281 - | P á g i n a

3. Estimar las necesidades de recursos, tiempos del proyecto, y la disponibilidad así como los medios de entrega.

a. Determinar costos de personal e infraestructura (capital).

• Determinar qué costos serán dados en términos de personal e

infraestructura. • Asegúrese de que todos los costos de infraestructura son

capturados, incluyendo el espacio de oficina, mobiliario, etc., así como la carga contra las actividades o en contra del proyecto.

• Agregar los costos de SBBs para llegar a un total de gastos de capital, con esto se alimenta al proyecto y al incremento del mismo, a continuación se debe añadir este costo de capital del proyecto a la lista de proyectos.

b. Determinar costos de operación y mantenimiento.

• Los costos están asociados con el costo total de la propiedad para

los SBBs. • Se debe activar después de que los SBBs han sido entregados a la

gestión de operaciones desde la organización de la entrega del proyecto.

• Hay que asegurarse que la estimación de costes proporcionará recursos suficientes disponibles para atender a los SBBs, por lo que debería abordar todo el ciclo de vida de los mismos.

• Deben añadirse los costos de operación y mantenimiento, a los costos de construcción los SBBs para dar un costo total de la propiedad.

• El costo total de la propiedad deberá añadirse a la lista de proyectos.

c. Determinar la arquitectura de transición y los tiempos de los incrementos del proyecto.

Crea una estimación inicial del periodo de tiempo en el que los proyectos y los incrementos de los mismos, tendrán lugar.

d. Evaluar mejor medio de entrega.

Haciendo uso de esta estimación se puede observar los recursos disponibles dentro de la organización y así se puede determinar si el medio de entrega debería ser interno, externo, híbrido.

4. Priorizar la migración de proyectos a través de una evaluación y

validación de riegos a nivel de costo/beneficio.

a. Obtener el análisis costo/beneficio para los proyectos de migración.


ORIENTADO A LA UTPL

EA – UTPL - 282 - | P á g i n a

Abarca iniciar el análisis de costo / beneficio y conduce el retorno de la inversión. Dicho retorno tiene que ser claro y tomado en cuenta en base a los stakeholders para los que está siendo preparado. Dos consideraciones son vitales:

• Sensibilidad a las expectativas de los stakeholders. • Descubrimiento de todos los costos, y asegurarse de que el negocio

oferte un beneficio neto (ahorrar costos sobre tiempo, iniciativa de costos sobre tiempo, etc.).

b. Validar la evaluación de riesgos.

• Revisar los riesgos documentados en el informe de brechas, las soluciones y de dependencias.

• Asegúrese de que los riesgos para los artefactos del proyecto se han mitigado en lo posible.

• Actualizar de la lista de proyectos con los comentarios relacionados a los riesgos.

c. Priorizar los proyectos.

• Llegar a un consenso entre los stakeholders para acordar la

priorización de proyectos, esto se logra haciendo uso de los beneficios netos, las brechas, las soluciones, y análisis de las dependencias calculados previamente.

• Incluir criterios de priorización en los conductores clave del negocio identificados en la fase E, así como los relativos a las agendas de los stakeholders individuales. Se debe abordar para ello:

o Reducción de los costes. o Consolidación de servicios. o Capacidad para manejar el cambio. o Un objetivo de tener un mínimo de soluciones provisionales

(ya que a menudo se convierten a largo plazo o estratégicas).

• Asegúrese de que los proyectos de fondo se identifican. A menudo son invisibles para el cliente final pero son un intermediario esencial para obtener entendimiento y apoyo de la alta dirección.

• La lista de proyectos debe claramente destacar las dependencias. • Hacer revisar por las partes interesadas la evaluación del riesgo,

revisándolo cuanto sea necesario garantizar que haya una comprensión completa del riesgo residual asociado con el establecimiento de prioridades y la línea de financiación prevista.

• Actualizar y reordenar la lista de proyectos de acuerdo a su prioridad.

5. Confirmar los incrementos y fases de la arquitectura de transición y

actualizar los documentos de definición de la arquitectura.


ORIENTADO A LA UTPL

EA – UTPL - 283 - | P á g i n a

a. Confirmar los periodos de tiempo de la arquitectura de transición.

• Estar de acuerdo en un tiempo útil de un incremento. • Considerar la zona donde la arquitectura tiene que ser aplicada y los

resultados del análisis de la lista de eventos y horarios de la institución.

• Estimar que los tiempos están afectados por la planificación, presupuestario, ciclos de adquisiciones y pre-requisitos.

b. Confirmar el valor de negocio entregado por los

incrementos.

• Revisar el análisis de brechas, de dependencias, al igual que portafolios y proyectos prioritarios.

• Validar que los resultados discretos del negocio puedan ser entregados en incrementos.

• Realizar a nivel de cartera de proyectos cómo pueden ser reprogramados para permitir a otros avanzar más rápidamente.

• Alinear las arquitecturas de los proyectos de fondo para garantizar que su flexibilidad ofrece el apoyo necesario para el logro de los resultados de negocio.

c. Actualizar los entregables arquitectónicos creados

previamente.

• Si el enfoque de implementación ha cambiado como resultado de la confirmación de los incrementos de implementación, se debe actualizar las arquitecturas de transición para reflejar la dirección revisada.

• Actualizar la definición de la arquitectura, asignando los objetivos del proyecto, alineando proyectos y sus entregables con los incrementos de la EA.

• Considerar que la definición de la EA es la orientada a la tecnología, pero, en la medida de lo posible es independiente de la tecnología.

6. Generar un plan de actuación para la implementación de la EA y el

plan de migración.

a. Confirmar la evolución de la EA.

• Confirmar la evolución real de la arquitectura para coordinar el desarrollo de varias instancias simultáneas de las arquitecturas diferentes.

• Los recursos deben asignarse para dirigir las arquitecturas por delante de una manera coherente.

• Aprovechar las oportunidades e innovaciones, así como hacer frente a eventos de negocios importantes.


ORIENTADO A LA UTPL

EA – UTPL - 284 - | P á g i n a

b. Confirmar el estado de evolución de la EA.

• El plan de aplicación y migración mostrará el estado de las

arquitecturas propuestas en los distintos niveles de detalle, dependiendo de lo lejos que se haya detallado en la perspectiva arquitectónica.

• Se debe utilizar un modelo técnico referencial para mostrar cómo las capacidades en cada área evolucionan a través de las arquitecturas de transición.

c. Confirmar el plan de implementación y migración detallado.

• En la fase E y en los pasos anteriores en la fase F, la mayor parte de

las acciones del portafolio de planificación se han completado, este paso, trae todos los detalles especificados a modo de un plan general.

• Se debe integrar formalmente todos los proyectos, los incrementos y actividades de los mismos, así como las dependencias existentes en un plan de proyecto.

• Asegurarse de que todas las dependencias externas son capturadas e incluidas.

• Conducir la nivelación de recursos para determinar la disponibilidad general de recursos, esto se da con precedencia en base a prioridades asignadas previamente.

• Determinar qué se puede hacer internamente o externamente soporte de la declaración (contrato arquitectónico).

d. Incorporar horarios del proyecto.

• Enrolar planes (parcialmente o en su totalidad) en el plan de

implementación y migración • Evaluarlo y ajustarlo para asegurar que el plan tiene la mejor

oportunidad para su éxito. • Crear el plan de implementación y migración finalizado.

e. Detalles del plan de migración.

• Un bloque constitutivo es entregado cuando este se convierte en

parte de la infraestructura corporativa y es manejado sobre la función de gestión de operaciones.

• Este plan se centra en la entrega real de los bloques constitutivos construidos y su integración a la infraestructura.

• El plan de migración debe atender a las operaciones en curso y al mantenimiento de los bloques constitutivos entregados.

• Asegura que el proyecto o la gestión de operaciones tengan los recursos para garantizar que un bloque constitutivo es realmente sostenible.


ORIENTADO A LA UTPL

EA – UTPL - 285 - | P á g i n a

• Es importante que los resultados sean rápidamente, pero de forma sistemática, puestos en servicio.

7. Establecer el ciclo de evolución de la EA y documentar las

recomendaciones producto de la experiencia con el proyecto.

a. Confirmar el ciclo de evolución de la EA. Para ello es necesario asegurarse de que la arquitectura siga siendo pertinente y proporcione la guía fundamental para el diseño de proyectos y la entrega de SBBs. No tiene sentido la creación de una familia de artefactos arquitectónicos que no se mantengan, ya que se volverán obsoletos con relativa rapidez. Para evitar esto tiene que haber un mecanismo de actualización periódica integrado en el proceso de transformación de la arquitectura.

b. Confirmar la gestión de procesos de la EA.

La gestión de lanzamientos es importante para que todas las partes sean capaces de contribuir de manera oportuna. De la mano va importancia de la gestión de la configuración, pues asegura que el continuum y las arquitecturas estén coordinadas y que reflejen la realidad actual planeada.

c. Documentar las lecciones aprendidas. Al documentarlas se las debe tratar como si fuesen artefactos de gobernanza. Es necesario tomar acción vía solicitudes de cambio, cambios en procesos o unidades de negocio, para con ello mejorar el desarrollo e implementación de la EA:

d. Documentar las recomendaciones dadas por la experiencia.

Salidas: • Plan de implementación y migración. • Documento terminado de definición de la arquitectura. • Especificación terminada de requerimientos de la EA. • Plan de actuación de la EA terminado. • Arquitectura de transición terminada. • Bloques constitutivos arquitectónicos reutilizables. • Solicitudes de trabajo arquitectónico para los aspectos de la

arquitectura en cuanto a implementación de proyectos. • Acuerdos (contratos) de la arquitectura para implementación de

proyectos. • Modelo de Implementación de gobernanza.

• Solicitudes de cambio que surgen de las lecciones aprendidas. Criterios de Salida: Los criterios de salida para este procedimiento se listan a continuación:

• Generar un plan de de migración robusto que permita hacer un uso

adecuado de la gobernanza a establecerse en la siguiente fase.


ORIENTADO A LA UTPL

EA – UTPL - 286 - | P á g i n a


• Capacidad de coordinación del plan de implementación y migración con los frameworks de gestión.

• Grado de satisfacción para la visión arquitectónica. • Grado de satisfacción para la definición de la arquitectura.


ORIENTADO A LA UTPL

EA – UTPL - 287 - | P á g i n a

5.7.5 Plantillas para la fase de establecimiento del plan de migración

5.7.5.1 Plantilla para levantamiento de: Bloques constitutivos de la arquitectura

Bloques Constitutivos de la Arquitectura


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de este Documento 2 Portafolio de Oportunidades 3 Portafolio de Paquetes de Trabajo 4 Hitos e Hitos de Transición de Arquitecturas 5 Evaluación de Factores de Implementación 6 Brechas Consolidadas y Soluciones Información del documento



Preparado por:


Título: Bloques de Construcción Arquitectónica Fecha de Versión: Revisado por:

Fecha de Revisión:






ORIENTADO A LA UTPL

EA – UTPL - 288 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito Los bloques constitutivos arquitectónicos (ABBs por sus siglas en inglés) se relacionan con el repositorio de la arquitectura, y están definidos o seleccionados como resultados de la aplicación del modelo de desarrollo arquitectónico. Sus características son: • Capturar requerimientos de arquitectura; por ejemplo: negocio, datos, aplicación, y requerimientos de

tecnología • Dirigir y Guiar el desarrollo de bloques constitutivos de solución (SBBs)

2 Bloques constitutivos El propósito de esta sección es delinear la funcionalidad fundamentar y los atributos: semánticos, sin ambigüedad, incluyendo seguridad, capacidad y manejabilidad. Los bloques constitutivos pueden ser definidos a diferentes niveles de detalle, dependiendo de en qué etapa de desarrollo de la arquitectura se ha alcanzad, para esta etapa la definición es formal. Un bloque constitutivo es simplemente un paquete definido de funcionalidad para satisfacer las necesidades del negocio. La forma en que se reúnen funcionalidad, los productos y desarrollos a medida en bloques constitutivos pueden variar ampliamente entre arquitecturas individuales.

• Un bloque constitutivo es un paquete de funcionalidad definido para satisfacer las necesidades de negocio a través de la institución.

• Un bloque constitutivo tiene interfaces publicadas para acceder a la funcionalidad. • Un bloque constitutivo puede interoperar con otros bloques, interdependendientes. • Un buen bloque constitutivo tiene las siguientes características:

• Considera la aplicación y uso, y evoluciona para explotar la tecnología y los estándares. • Puede ser montado a partir de otros bloques constitutivos. • Puede ser sub-armado a partir de otros bloques constitutivos. • Lo ideal sería que un bloque constitutivo sea reutilizable y reemplazable, y especificado de

manera correcta. • Un bloque constitutivo puede tener múltiples implementaciones, pero con diferentes bloques

interdependientes. Una buena elección de bloques constitutivos puede conducir a mejoras en la integración de sistemas heredados, interoperabilidad y flexibilidad en la creación de nuevos sistemas y aplicaciones. Los sistemas se construyen a partir de colecciones de bloques constitutivos, por lo que la mayoría de bloques tienen que interactuar con otros. 2.1 Funcionalidad fundamental


ORIENTADO A LA UTPL

EA – UTPL - 289 - | P á g i n a

Describe la funcionalidad de cada bloque traducida en base a los requerimientos asociados al mismo. 2.2 Atributos Delimitar los atributos de los bloques tomando en consideración:

• Semántica • Capacidad de seguridad • Manejabilidad

3 Interfaces Esta sección permite describir las Interfaces, es decir, el conjunto seleccionado, suministrado de uso en la EA. 3.1 Resumen Describir en esta sección a breves rasgos el funcionamiento de las interfaces. 3.2 Interoperabilidad Describir la interoperabilidad y relaciones con otros bloques constitutivos. 3.3 Bloques constitutivos dependientes Describe los bloques constitutivos dependientes con otros requisitos funcionales y llamadas interfaces de usuario. 4 Asignación Asigna al negocio/organización entidades y políticas. 7.1 Asignación de Entidades al Negocio/Organización El propósito de esta sección es una referencia cruzada de los bloques de construcción de las entidades del negocio/organización. Obligatorio/opcional: Esta sección es obligatoria. 7.2 Asignación de Políticas al Negocio/Organización El propósito de ésta sección es una referencia cruzada de los bloques de construcción de las políticas del negocio/organización. Obligatorio/opcional: Esta sección es obligatoria.


ORIENTADO A LA UTPL

EA – UTPL - 290 - | P á g i n a

5.7.5.2 Plantilla para levantamiento de: Contrato (acuerdo) arquitectónico con socios desarrolladores

Acuerdo arquitectónico con Socios Desarrolladores


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de Contenidos 1 Propósito 2 Contrato de la arquitectura 3 Objetivos y alcance 4 Entregables arquitectónicos 5 Plan de establecimiento de trabajo conjunto 6 Plan de comunicaciones 7 Riegos y mitigaciones 8 Criterios de aceptación y procedimientos 9 Firmas de aprobación Información del documento



Preparado por:


Título: Contrato de Arquitectura con los Socios Desarrolladores

Fecha de Versión:

Revisado por:

Fecha de Revisión:





ORIENTADO A LA UTPL

EA – UTPL - 291 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito de este Documento Los contratos de la arquitectura son los acuerdos entre los responsables del proyecto y los patrocinadores sobre los entregables, calidad, y adecuación de los objetivos de la arquitectura. La implementación satisfactoria de estos acuerdos serán entregados a través de una gobernanza arquitectónica efectiva. Para la implementación de un enfoque de gobierno para administrar los contratos, los siguiente debe ser asegurado: • Un sistema de monitoreo continuo para verificar integridad, cambios, toma de decisiones y auditoria para

todas las actividades relacionadas a la arquitectura dentro de la UTPL. • Adherencia a los principios, estándares y requerimientos de la arquitectura en desarrollo. • Identificación de riesgos y todos los aspectos de las arquitecturas implementadas o en desarrollo, cubriendo

el desarrollo interno contra los estándares aceptados, políticas, tecnologías, y productos tan bien como los aspectos operacionales de la arquitectura.

• Un conjunto de procesos y prácticas para asegurar rendición de cuentas, responsabilidad y disciplina con lo que se refiere al desarrollo y uso de artefactos de la arquitectura.

• Un entendimiento formal de la gobernanza de la UTPL, su nivel de autoridad, y alcance de la arquitectura bajo este cuerpo de gobernanza.

Esta es una declaración firmada de la intención en el diseño y desarrollo de la EA, o partes significativas de esta, de los socios de la institución incluyendo sistemas integrados, proveedores de aplicaciones y proveedores de servicios. Cada vez más, el desarrollo de uno o más dominios de arquitectura (negocios, datos, aplicación, tecnologías) pueden ser contratados, con las funciones de EA proveyendo supervisión de toda la arquitectura, y coordinando y controlando el esfuerzo total. 2 Contrato arquitectónico Cualquiera que sea la especificación de acuerdos de subcontratación, los acuerdos a sí mismos serán normalmente gobernados por un Contrato de Arquitectura que defina los entregables, calidad y adecuación de los objetivos para la arquitectura desarrollada, y los procesos por los cuales los socios en la arquitectura desarrollada trabajarán juntos. 2.1 Resumen Especificar brevemente la naturaleza del contrato arquitectónico. 2.2 Requisitos estratégicos


ORIENTADO A LA UTPL

EA – UTPL - 292 - | P á g i n a

Especificar sobre qué aspectos estratégicos se debe erigir el contrato arquitectónico, de igual manera se debe especificar detalladamente el conjunto de requisitos (especificaciones) para el contrato. 3 Objetivos y alcance Especificar los objetivos y delimitar el alcance del contrato arquitectónico. 3.1 Objetivos Los objetivos de negocio para el trabajo arquitectónico son los siguientes:

Objetivo de Negocio Notas <<Objetivo de Negocio 1>> <<Notas>> <<Objetivo de Negocio 2>> <<Notas>>

Se recomienda hacer revisiones sucesivas para poder refinar adecuadamente esta sección. 3.2 Alcance Delimitar el alcance del contrato arquitectónico. 3.3 Interesados, expectativas y vistas La siguiente tabla muestra los interesados que usarán este documento, sus expectativas, y cómo el trabajo arquitectónico logrará satisfacer estas expectativas a través de la entrega de un número de vistas.

Interesado Preocupación Vista <<Interesado1>> <<Describir qué aspectos de la

arquitectura serán de interés para este interesado.>>

<<Listar cualquier vista que será creada para direccionar esta preocupación del interesado.>>

. 3.4 Cambios de los procedimientos para el alcance Sirve para afrontar cambios para el alcance del contrato que se den en el proyecto durante su ejecución. En esta sección se deberá especificarlos procedimientos alternos (contingencias) a tomarse en caso de darse algún cambio. 4 Entregables arquitectónicos En esta sección se debe listar los entregables arquitectónicos que satisfagan los requerimientos del negocio. Es decir los entregables asociados a las tres primeras fases del capítulo 5 que correspondan netamente al negocio. 4.1 Desarrollo de la arquitectura Especificar cómo se dará el plan de desarrollo de la arquitectura. Describir las fases más grandes (ADM) y qué tiempo y recursos se necesitarían para cada una. 4.2 Medidas de la arquitectura objetivo


ORIENTADO A LA UTPL

EA – UTPL - 293 - | P á g i n a

Especificar en esta sección cuales serán las medidas arquitectónicas que servirán para contrastar y validar si la arquitectura objetivo será o no consolidada. Es decir para comparar si la visión arquitectónica de la arquitectura objetivo logra implementarse. 4.3 Medidas del negocio Especificar en esta sección cuales serán las medidas que servirán para contrastar y validar si la arquitectura objetivo será o no consolidada 4.4 Fases definidas de entregables Para ello es necesario considerar el WBS sugerido en plantillas anteriores. Y dentro de dicho WBS, o dentro del plan de acción del capítulo 6 se puede especificar las fechas y las versiones de cada entregable dentro de cada fase. 5 Plan de Establecimiento de trabajo Continuo <<Esta sección describe todas las actividades y entregables para el trabajo de la arquitectura.>> <<Busca proveer un plan para el trabajo de arquitectura.>> 5.1 Ítem de Trabajo 1 5.1.1 Actividades <<Especificar detalle>> 5.1.2 Entregables <<Los siguientes productos de trabajo serán creados como resultado de este trabajo de arquitectura:>> • <<Producto de Trabajo 1 Nombre>>

<<Descripción del Producto de Trabajo 1, etc.>> • <<Producto de Trabajo 2 Nombre>>

<<Descripción del Producto de Trabajo, etc.>> 5.2 Ítem de Trabajo n

5.2.1 Actividades <<Especificar detalle>> 5.2.2 Entregables <<Los siguientes productos de trabajo serán creados como resultado de este trabajo de arquitectura:>> • <<Producto de Trabajo 1 Nombre>>

<<Descripción del Producto de Trabajo 1, etc.>> • <<Producto de Trabajo 2 Nombre>>

<<Descripción del Producto de Trabajo, etc.>>


ORIENTADO A LA UTPL

EA – UTPL - 294 - | P á g i n a

6 Plan de Comunicaciones Este debe incluir principalmente:

o Eventos: La cadena de sucesos a nivel de cronograma. o Canales: Los medios a través de los cuales la información será difundida. o Formatos: Las especificaciones formales bajo las cuales deben ser levantados los documentos

orientados a informar (entregables). o Contenidos: El tipo de contenidos que deberán ser mostrados, a quienes, a qué nivel de detalle,

etc. 7 Riesgos y mitigaciones Listar los riesgos que pueden darse para el proyecto con respecto al contrato. 7.1 Estructura de gobernanza Definir como la gobernanza deberá enfocarse para incluir y gestionar los contratos arquitectónicos. 7.2 Análisis de riesgos

ID Riesgo Severidad Probabilidad Mitigación Propietario 1. 2

Nota: La siguiente tabla provee una simple Evaluación de Riesgos para proyectos pequeños. Metodologías/hojas de cálculo más complejas para administración de riesgos pueden ser sustituidos donde sea relevante. 7.3 Supuestos La siguiente tabla resume los supuestos para esta declaración de Trabajo Arquitectónico.


8 Criterios de Aceptación y procedimientos 8.1 Métricas e indicadores clave de procesos (KPIs) Las siguientes métricas deben ser establecidas para medir el trabajo arquitectónico.

Métrica Técnica de medición Valor objetivo Justificación / Notas

8.2 Procedimientos de Aceptación


ORIENTADO A LA UTPL

EA – UTPL - 295 - | P á g i n a

Describir los procesos a ser usados para aceptación/cancelación. 8.3 Plazos Listar los plazos para cada fase del proyecto y su holgura, así como para todo el proyecto. 9 Firmas de Aprobación

Nombre y firma Nro. n


ORIENTADO A LA UTPL

EA – UTPL - 296 - | P á g i n a

5.7.5.3 Plantilla para levantamiento de: Contrato (acuerdo) arquitectónico con usuarios del negocio

Acuerdo arquitectónico con Usuarios


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito 2 Contrato de la arquitectura 3 Objetivos y alcance 4 Entregables arquitectónicos 5 Riesgos y mitigación 6 Plan de comunicaciónes 7 Procedimientos y criterios de aceptación 8 Firmas de aprobación Información del documento



Preparado por:


Título: Contrato de Arquitectura con los Usuarios del Negocio

Fecha de Versión:

Revisado por:

Fecha de Revisión:






ORIENTADO A LA UTPL

EA – UTPL - 297 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito Los Contratos Arquitectónicos son los acuerdos entre los socios y los auspiciantes de los entregables, calidad, y adecuación de los objetivos de la arquitectura. La implementación satisfactoria de estos acuerdos será entregada a través de una gobernanza. Para la implementación de un enfoque gobernado para administrar los contratos, los siguiente debe ser asegurado: • Un sistema de monitoreo continuo para verificar integridad, cambios, toma de decisiones y auditoria para

todas las actividades relacionadas a la arquitectura dentro de la UTPL. • Adherencia a los principios, estándares y requerimientos de la arquitectura en desarrollo. • Identificación de riesgos y todos los aspectos de las arquitecturas implementadas o en desarrollo, cubriendo

el desarrollo interno contra los estándares aceptados, políticas, tecnologías, y productos tan bien como los aspectos operacionales de la arquitectura tanto como la institución que continúa su negocio dentro del ambiente flexible.

• Un conjunto de procesos y prácticas para asegurar rendición de cuentas, responsabilidad y disciplina con lo que se refiere al desarrollo y uso de artefactos de la arquitectura.

• Un entendimiento formal de la gobernanza de la UTPL, su nivel de autoridad, y alcance de la arquitectura bajo este cuerpo de gobernanza.

Esta es una declaración firmada de intención de conformidad con la EA, emitida por los usuarios de alto nivel del negocio. Cuando la EA haya sido implementada (al final de la Fase F), un Contrato Arquitectónico será normalmente elaborado entre las funciones de arquitectura (o las funciones de gobernanza de TI,) y los usuarios de negocio que subsecuentemente serán construidos, desplegando sistemas de aplicación en el ambiente arquitectónico. 2 Contrato de arquitectura Cualquiera que sea la especificación de acuerdos de subcontratación, los acuerdos a sí mismos serán normalmente gobernados por un Contrato de Arquitectura que defina los entregables, calidad y adecuación de los objetivos para la arquitectura desarrollada, y los procesos por los cuales los socios en la arquitectura desarrollada trabajarán juntos. 2.1 Resumen Especificar brevemente la naturaleza del contrato arquitectónico. 2.2 Requisitos estratégicos Especificar sobre qué aspectos estratégicos se debe erigir el contrato arquitectónico, de igual manera se debe especificar detalladamente el conjunto de requisitos (especificaciones) para el contrato.


ORIENTADO A LA UTPL

EA – UTPL - 298 - | P á g i n a

3 Objetivos y alcance Especificar los objetivos y delimitar el alcance del contrato arquitectónico. 3.1 Objetivos Los objetivos del negocio del Trabajo de Arquitectura son los siguientes

Objetivos del Negocio Notas <<Objetivo del Negocio 1>> << Notas >> <<Objetivo del Negocio 2>> << Notas >>

3.2 Alcance Delimitar el alcance del contrato arquitectónico. 3.3 Interesados, expectativas y vistas La siguiente tabla muestra los interesados que usarán este documento, sus stakeholders, y cómo el trabajo de arquitectura, logrará satisfacer estas preocupaciones a través de la entrega de un número de vistas.

Stakeholder Expectativa Vista <<Stakeholder 1>> <<Describir qué aspectos de la

arquitectura serán de interés para este stakeholder.>>

<<Listar cualquier vista que será creada para direccionar esta preocupación del stakeholder.>>

3.4 Cambio de los procedimientos del alcance Sirve para afrontar cambios para el alcance del contrato que se den en el proyecto durante su ejecución. En esta sección se deberá especificarlos procedimientos alternos (contingencias) a tomarse en caso de darse algún cambio. 4 Entregables arquitectónicos En esta sección se debe listar los entregables arquitectónicos que satisfagan los requerimientos del negocio. Es decir los entregables asociados a las tres primeras fases del capítulo 5 que correspondan netamente al negocio. 4.1 Adoptantes de la arquitectura Describir el entorno y las principales características de los usuarios de la institución. 4.2 Arquitectura de servicios Especificar la arquitectura de gestión de servicios, incluyendo Acuerdos a Nivel de Servicios (SLA). 5 Riesgos y mitigaciones


ORIENTADO A LA UTPL

EA – UTPL - 299 - | P á g i n a

Listar los riesgos que pueden darse para el proyecto con respecto al contrato. 5.1 Estructura de gobernanza Definir como la gobernanza deberá enfocarse para incluir y gestionar los contratos arquitectónicos. A nivel de usuarios para este caso. 5.2 Análisis de riesgos

ID Riesgo Severidad Probabilidad Mitigación Propietario 1. 2

Nota: La siguiente tabla provee una simple Evaluación de Riesgos para proyectos pequeños. Para EA-UTPL se debe hacer uso de metodologías/hojas de cálculo más complejas para administración de riesgos donde sea relevante dicho uso. 5.3 Supuestos La siguiente tabla resume los supuestos para esta declaración de trabajo arquitectónico.


6 Plan de Comunicaciones Este debe incluir principalmente:

o Eventos: La cadena de sucesos a nivel de cronograma. o Canales: Los medios a través de los cuales la información será difundida. o Formatos: Las especificaciones formales bajo las cuales deben ser levantados los documentos

orientados a informar (entregables). o Contenidos: El tipo de contenidos que deberán ser mostrados, a quienes, a qué nivel de detalle,

etc. 7 Criterios de Aceptación y Procedimientos 7.1 Métricas e indicadores clave de procesos (KPIs) Las siguientes métricas deben ser establecidas para medir el trabajo arquitectónico.

Métrica Técnica de medición Valor objetivo Justificación / Notas

7.2 Procedimientos de aceptación Describir los procesos a ser usados para aceptación/cancelación.


ORIENTADO A LA UTPL

EA – UTPL - 300 - | P á g i n a

7.3 Plazos Listar los plazos para cada fase del proyecto y su holgura, así como para todo el proyecto. 8 Firmas de aprobación

Nombre y firma Nro. n


ORIENTADO A LA UTPL

EA – UTPL - 301 - | P á g i n a

5.8 Fase G: Implementación de Gobernanza

Permite establecer control sobre la implementación de la EA mediante la ejecución de proyectos para construir soluciones de TI a través de ellos.

FasePreliminar



de Información

Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica



5.8.1 Objetivos

• Formular recomendaciones para cada implementación de proyectos. • Gobernar y administrar un contrato de arquitectura que abarque la totalidad de los procesos

de desarrollo e implementación. • Llevar a cabo funciones de gobierno apropiadas mientras la solución está siendo

implementada y desplegada. • Asegurar la conformidad con la arquitectura mediante la implementación de proyectos. • Asegurar que el programa de soluciones se ha implementado con éxito como se especificó

en el programa de trabajo previsto. • Garantizar el cumplimiento de la solución implementada en la arquitectura objetivo. • Movilizar a las operaciones de apoyo que sustentarán la línea de vida del trabajo futuro de la

solución implementada.


ORIENTADO A LA UTPL

EA – UTPL - 302 - | P á g i n a

5.8.2 Enfoque

Busca reunir información para la gestión exitosa de la implementación de proyectos diferentes. Para ello debe desplegar la arquitectura objetivo como una serie de transiciones que permitan la rápida obtención de valor de negocio y beneficios, y permitan reducir al mínimo el riesgo. Para el enfoque general debe considerarse:

• Establecer un programa de implementación que permita la entrega de la transición. • Usar un convenio de arquitecturas para la implementación durante la fase de planeación de la

migración. • Adoptar un plan de despliegue por fases que refleje las prioridades de negocio contenidos en

el plan de actuación de la arquitectura. • Seguir las normas y estándares de la institución a nivel colectivo (corporativo), de TI, y

gobernanza de la arquitectura. • Usar el portafolio establecido y el enfoque de gestión de programas de la institución. • Definir un framework de operaciones para garantizar la larga vida útil de la solución

implementada. Finalmente es necesario establecer la conexión entre la arquitectura y la organización de la implementación de la misma, esto se logra a través del contrato de arquitectura. De igual manera hay que garantizar el cumplimiento de la arquitectura definida, no sólo por las implementaciones de proyectos, sino también por otros proyectos en curso dentro de la institución. 5.8.3 Entradas

• Materiales de referencia externos a la institución. 5.8.3.1 No arquitectónicas

• Solicitud de trabajo arquitectónico. • Evaluación de capacidad.



• Framework arquitectónico adaptado.


ORIENTADO A LA UTPL

EA – UTPL - 303 - | P á g i n a

o Método arquitectónico adaptado. o Contenido arquitectónico adaptado. o Herramientas configuradas y desplegadas.



• Documento de definición de la arquitectura. • Especificación de requisitos de la arquitectura.

o Requisitos arquitectónicos. o Resultados de análisis de brechas (para las cuatro capas).

• Plan de actuación arquitectónico. • Arquitectura de transición. • Implementación del modelo de gobernanza. • Contrato arquitectónico. • Solicitud de trabajo arquitectónico. • Plan de implementación y migración.

5.8.4 Salidas

• Contrato de la arquitectura. • Evaluaciones de cumplimiento. • Solicitud de cambio. • Soluciones desplegables compatibles a la arquitectura, incluyendo:

o El sistema compatible implementado de la arquitectura. o Repositorio arquitectónico poblado. o Recomendaciones conforme a recomendaciones dispensaciones de la arquitectura. o Recomendaciones sobre requisitos de entrega (prestación) de servicios. o Recomendaciones sobre medidas de rendimiento. o Acuerdos a nivel de servicio (SLAs, por sus siglas en inglés). o Visión arquitectónica, actualizada después de la implementación. o Documento de definición de la arquitectura, actualizado después de la

implementación. o Arquitectura de transición, actualizada después de la aplicación. o Modelos operativos de negocio y TI para la solución implementada.


ORIENTADO A LA UTPL

EA – UTPL - 304 - | P á g i n a

5.8.5 Definición de proceso para la fase de gobernanza

Definición de Procesos

Proceso: FG – Gobernanza: Implementación de gobernanza para la arquitectura. Cod.Doc FG –

GobernanzaX Responsable: DGTI, CSI Versión: 1.0

Mantenimiento: DGTI Estado: Borrador Publicado X

Descripción: Es el proceso por el cual se describe como establecer control sobre la implementación de la EA haciendo uso de un esquema de gobernanza adecuado.

Alcance: El proceso de la fase de implementación de gobernanza, contempla los siguientes procedimientos:

• Establecer un programa de implementación que permita la entrega de la transición.

• Usar un convenio de arquitecturas para la implementación durante la fase de planeación de la migración.

• Adoptar un plan de despliegue por fases que refleje las prioridades de negocio contenidos en el plan de actuación de la arquitectura.

• Seguir las normas y estándares de la institución a nivel colectivo (corporativo), de TI, y gobernanza de la arquitectura.

• Usar el portafolio establecido y el enfoque de gestión de programas de la institución.

• Definir un framework de operaciones para garantizar la larga vida útil de la solución implementada.


No aplica





• DGTI: Director de gobernanza de TI. • CSI: Coordinador de servicios de investigación.

Listado de Cambios



Descripción

1.0 26/10/2010 DGTI y CSI Todo A Emisión Inicial



• Validar los artefactos de implementación y migración finalizados en las dos fases anteriores.

• Generar un modelo de gobernanza sustentable que pueda hacer que el proyecto EA-UTPL perdure.


ORIENTADO A LA UTPL

EA – UTPL - 305 - | P á g i n a

Entradas:

Salidas:

• Materiales arquitectónicos referenciales externos a la institución.

• Solicitud de trabajo arquitectónico. • Evaluación de capacidad. • Modelo organizacional para la EA. • Framework arquitectónico adaptado. • Estatuto de trabajo arquitectónico. • Visión arquitectónica. • Repositorio arquitectónico. • Documento de definición de la arquitectura. • Especificación de requisitos de la

arquitectura. • Plan de actuación arquitectónico. • Arquitectura de transición. • Implementación del modelo de gobernanza. • Contrato arquitectónico. • Solicitud de trabajo arquitectónico.

• Plan de implementación y migración.

• Contrato de la arquitectura. • Evaluaciones de cumplimiento. • Solicitud de cambio. • Soluciones desplegables compatibles a la

arquitectura.

Roles:

• DGTI: Dar soporte al proceso, definir el esquema gobernanza. • CSI: Analizar y evaluar los mecanismos más adecuados para dar soporte a la gobernanza.


• Plan de implementación y migración. • Framework arquitectónico. • Documento de definición de la arquitectura. • Repositorio arquitectónico.

Tareas:

1. Confirmar el ámbito y las prioridades para el despliegue con gestión de desarrollo. 2. Identificar los recursos y habilidades de despliegue. 3. Guiar el desarrollo del despliegue de soluciones. 4. Realizar revisiones de cumplimiento de la EA. 5. Implementar operaciones de TI y de negocio. 6. Realizar estudio de seguimiento (post-implementación) y cerrar la implementación.

Métricas:

• Capacidad de despliegue de la EA. • Grado de cumplimiento de normas.


Implementación de gobernanza para la arquitectura. Objetivos del Procedimiento:

• Formular recomendaciones para cada implementación de proyectos.


ORIENTADO A LA UTPL

EA – UTPL - 306 - | P á g i n a

• Gobernar y administrar un contrato de arquitectura que abarque la totalidad de los procesos de desarrollo e implementación.

• Llevar a cabo funciones de gobierno apropiadas mientras la solución está siendo implementada y desplegada.

• Asegurar la conformidad con la arquitectura mediante la implementación de proyectos.

• Asegurar que el programa de soluciones se ha implementado con éxito como se especificó en el programa de trabajo previsto.

• Garantizar el cumplimiento de la solución implementada en la arquitectura objetivo.

• Movilizar a las operaciones de apoyo que sustentarán la línea de vida del trabajo futuro de la solución implementada.



• DGTI: Dar soporte al proceso, definir el esquema gobernanza. • CSI: Analizar y evaluar los mecanismos más adecuados para dar

soporte a la gobernanza. Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a

continuación:

• Validar los artefactos de implementación y migración finalizados en las dos fases anteriores.

Entradas: • Materiales arquitectónicos referenciales externos a la institución. • Solicitud de trabajo arquitectónico. • Evaluación de capacidad. • Modelo organizacional para la EA.




• Framework arquitectónico adaptado. o Método arquitectónico adaptado. o Contenido arquitectónico adaptado. o Herramientas configuradas y desplegadas.




o Requisitos arquitectónicos.


ORIENTADO A LA UTPL

EA – UTPL - 307 - | P á g i n a

o Resultados de análisis de brechas (para las cuatro capas). • Plan de actuación arquitectónico. • Arquitectura de transición. • Implementación del modelo de gobernanza. • Contrato arquitectónico. • Solicitud de trabajo arquitectónico.

• Plan de implementación y migración. Pasos y Actividades del Procedimiento:


1. Confirmar el ámbito y las prioridades para el despliegue con gestión del desarrollo.

• Revisar los resultados (salidas) de la planificación de migración y producir recomendaciones sobre el despliegue.

• Identificar las prioridades de la EA para los equipos de desarrollo. • Identificar los problemas de despliegue y elaborar recomendaciones. • Identificar bloques constitutivos para el reemplazo, actualización, etc. • Realizar un análisis de brechas en el framework de EA y de

soluciones. o Identificar las brechas en el framework existente de

soluciones arquitectónicas. o Identificar las soluciones específicas de los SBBs

necesarias para cubrir dichas brechas, las cuales serán determinadas por los arquitectos de soluciones.

• Elaborar un informe de análisis de brechas.

2. Identificar los recursos y habilidades de despliegue.

• Educar a los recursos de desarrollo en los entregables totales de la EA y en las expectativas de proyectos específicos de desarrollo y de implementación.

• Identificar los métodos de desarrollo de sistemas necesarios para el desarrollo de soluciones.

• Asegúrese de que el método de desarrollo de sistemas permite una retroalimentación al equipo de arquitectura sobre los diseños.

3. Guiar el desarrollo del despliegue de soluciones.

• Formular recomendaciones del proyecto. • Para cada implementación y despliegue de proyecto:

o Documentar el ámbito del proyecto individual en el análisis de impacto.

o Documentar requisitos estratégicos (desde el punto de vista arquitectónico) en el análisis de impacto.

o Documentar de las solicitudes de cambio (como el soporte para una interfaz estándar) en el análisis de impacto.

o Documentar las reglas para el cumplimiento en el análisis de impacto.


ORIENTADO A LA UTPL

EA – UTPL - 308 - | P á g i n a

o Documentar la línea de tiempo de requisitos desde el plan de actuación, igualmente en el análisis de impacto.

• Documentar el contrato arquitectónico: obteniendo la firma de todas las instituciones de desarrollo y la institución patrocinadora (UTPL).

• Actualizar el repositorio y directorio de soluciones del continuum arquitectónico.

• Guiar el desarrollo de modelos operativos de negocio y de TI, para los servicios.

• Proporcionar los requisitos de servicio derivados de la EA. • Guiar la definición de requisitos operacionales de negocio y de TI. • Llevar a cabo análisis de brechas entre la arquitectura solución y las

operaciones. • Elaborar el plan de implementación.

4. Realizar revisiones de cumplimiento de la EA.

• Revisar la implementación de gobernanza en curso y el

cumplimiento de la arquitectura para cada bloque constitutivo. • Llevar a cabo revisiones posteriores al desarrollo. • Cerrar la parte de desarrollo de del despliegue.

5. Implementar operaciones de TI y de negocio.

• Llevar a cabo un despliegue que incluya: o Implementación de entrega de servicios de TI. o Implementación de entrega de servicios de negocio. o Implementación de desarrollo de competencias y

entrenamiento. o Publicación de documentación de comunicaciones.

• Publicar nuevas arquitecturas de referencia (líneas base) para el repositorio de EA y actualizar otros repositorios impactados, tales como tiendas de gestión de configuración operacional.

6. Realizar estudio de seguimiento (post-implementación) y cerrar

la implementación.

• Llevar a cabo revisiones posteriores a la implementación.

• Publicar las revisiones y cerrar los proyectos. Salidas: • Contrato de la arquitectura.

• Evaluaciones de cumplimiento. • Solicitud de cambio. • Soluciones desplegables compatibles a la arquitectura, incluyendo:

o El sistema compatible implementado de la arquitectura. o Repositorio arquitectónico poblado. o Recomendaciones conforme a recomendaciones

dispensaciones de la arquitectura. o Recomendaciones sobre requisitos de entrega (prestación)


ORIENTADO A LA UTPL

EA – UTPL - 309 - | P á g i n a

de servicios. o Recomendaciones sobre medidas de rendimiento. o Acuerdos a nivel de servicio (SLAs, por sus siglas en

inglés). o Visión arquitectónica, actualizada después de la

implementación. o Documento de definición de la arquitectura, actualizado

después de la implementación. o Arquitectura de transición, actualizada después de la

aplicación. o Modelos operativos de negocio y TI para la solución

implementada. Criterios de Salida: Los criterios de salida para este procedimiento se listan a continuación:

• Generar un modelo de gobernanza sustentable que pueda hacer que

el proyecto EA-UTPL perdure.

Métricas del Proceso: Las métricas que deben recopilarse en este procedimiento incluyen: • Capacidad de despliegue de la EA. • Grado de cumplimiento de normas y estándares establecidos en la

EA y de la institución a nivel colectivo (corporativo), de TI, y gobernanza de la arquitectura.


ORIENTADO A LA UTPL

EA – UTPL - 310 - | P á g i n a

5.8.6 Plantillas para la fase de implementación de la gobernanza

5.8.6.1 Plantilla para levantamiento de: Bloques constitutivos de soluciones

Bloques Constitutivos de Soluciones


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito 2 Bloques Constitutivos 3 Interfaces 4 Asignación Información del documento



Preparado por:


Título: Bloques Constitutivos de Soluciones Fecha de Versión: Revisado por:

Fecha de Revisión:







ORIENTADO A LA UTPL

EA – UTPL - 311 - | P á g i n a


Nro. de Versión

Fecha de Versión


9 Propósito <<Los Bloques Constitutivos de Soluciones [Solution Building Blocks (SBBs)] se relacionan con las Soluciones del repositorio arquitectónico, y puede también ser adquiridos o desarrollados. Las características de los SBB son: • Definir qué productos y componentes implementarán la funcionalidad • Definir la implementación • Cumplir los requerimientos del negocio • Ser producto o vendedor cuidados>>

10 Bloques constitutivos <<El propósito de esta sección es definir la funcionalidad específica y atributos: semánticos, sin ambigüedad, incluyendo capacidad de seguridad y capacidad de gestión.>> Un bloque constitutivo es simplemente un paquete definido de funcionalidad para satisfacer las necesidades del negocio. La forma en que se reúnen funcionalidad, los productos y desarrollos a medida en bloques constitutivos pueden variar ampliamente entre arquitecturas individuales.

• Un bloque constitutivo es un paquete de funcionalidad definido para satisfacer las necesidades de negocio a través de la institución.

• Un bloque constitutivo tiene interfaces publicadas para acceder a la funcionalidad. • Un bloque constitutivo puede interoperar con otros bloques, interdependendientes. • Un buen bloque constitutivo tiene las siguientes características:

• Considera la aplicación y uso, y evoluciona para explotar la tecnología y los estándares. • Puede ser montado a partir de otros bloques constitutivos. • Puede ser sub-armado a partir de otros bloques constitutivos. • Lo ideal sería que un bloque constitutivo sea reutilizable y reemplazable, y especificado de

manera correcta. • Un bloque constitutivo puede tener múltiples implementaciones, pero con diferentes bloques

interdependientes. Una buena elección de bloques constitutivos puede conducir a mejoras en la integración de sistemas heredados, interoperabilidad y flexibilidad en la creación de nuevos sistemas y aplicaciones. Los sistemas se construyen a partir de colecciones de bloques constitutivos, por lo que la mayoría de bloques tienen que interactuar con otros. 10.1 Especificación de funcionalidad Especificar la funcionalidad correspondiente a cada tipo de bloque constitutivo. 10.2 Atributos


ORIENTADO A LA UTPL

EA – UTPL - 312 - | P á g i n a

Está sección recoge especificaciones de los atributos compartidos a través del ambiente (no confundir con funcionalidad) como la seguridad, capacidad de gestión, localización y escalabilidad. 10.3 Rendimiento Especificar en términos de rendimiento la utilidad de los boques constitutivos. 10.4 Configurabilidad Especificar en términos de complejidad de configuración la utilidad de los boques constitutivos. 10.5 Controladores y restricciones Especificar el diseño de controladores y restricciones, incluyendo la arquitectura física. 11 Interfaces Esta sección recoge las Interfaces: Seleccionar el conjunto, suministrarlo, etc. 11.1 Interoperabilidad Describir la interoperabilidad y relaciones con otros bloques constitutivos. 11.2 Dependencia entre Bloques Constitutivos Describir los bloques constitutivos dependientes con la funcionalidad requerida y nombrando las interfaces de usuario. 11.3 Bloques Constitutivos de soluciones requeridos Describir los SBBs requeridos usados con la funcionalidad requerida y los nombres de la interfaces de usuario usados para los mismos. 12 Asignación El propósito de esta sección es describir la asignación de los SBBs para la topología de TI y las políticas operacionales. 12.1 Relaciones Entre SBBs y ABBs El propósito de esta sección es describir las relaciones entre los SBBs y ABBs.


ORIENTADO A LA UTPL

EA – UTPL - 313 - | P á g i n a

5.8.6.2 Plantilla para levantamiento de: Evaluación del cumplimiento

Evaluación del cumplimiento


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito 2 Resumen 3 Lista de verificación de la arquitectura completada Información del documento



Preparado por:


Título: Evaluación del Cumplimiento Fecha de Versión: Revisado por:

Fecha de Revisión:







ORIENTADO A LA UTPL

EA – UTPL - 314 - | P á g i n a

Nro. de Versión

Fecha de Versión


1 Propósito Este documento tiene por objetivo establecer un control mediante la evaluación de algunos aspectos en cuanto a la arquitectura se refiere. Mediante este entregable se podrá validar la visión arquitectónica. 2 Resumen Una vez que una arquitectura ha sido definida, es necesario gobernar esa arquitectura a través de la implementación para asegurar que la Visión original de dicha Arquitectura esté apropiadamente realizada y que cualquier aprendizaje de implementación sea retro alimentada dentro de los procesos de arquitectura. Las revisiones del periodo de cumplimiento de los proyectos proveen un mecanismo para revisar los progresos de los proyectos y asegurar que el diseño e implementación estén procediendo “en línea” con los objetivos arquitectónicos y de estrategia. 2.1 Resumen del progreso del proyecto y del estado Especificar en esta sección el avance del proyecto, para ello es necesario puntualizarlo en base al WBS sugerido o al plan de acción del capítulo 6. Lo anterior servirá para generar un estado actual del proyecto EA-UTPL en un determinado momento de ejecución, en términos porcentuales. 2.2 Resumen del diseño/arquitectura del proyecto Especificar en esta sección el estado actual del diseño, es decir en qué instante se encuentra el proyecto. 3 Lista de verificación de la arquitectura Sirve para especificar el estado actual del diseño, es usada mayoritariamente para la arquitectura terminada, pues se puede levantar un estado final de la arquitectura objetivo a la que se ha llegado, pero también sirve para gradualmente ir viendo el progreso de lo mencionado. 3.1 Lista de verificación del hardware y sistema operativo Especificar en una lista si se llegó a la arquitectura objetivo en aspectos de hardware y SO. (Es decir si se resolvieron todas las brechas en este aspecto). 3.2 Lista de verificación de aplicaciones Especificar en una lista si se llegó a la arquitectura objetivo en aspectos de aplicaciones. (Es decir si se resolvieron todas las brechas en este aspecto). 3.3 Lista de verificación de gestión de la información Especificar en una lista si se llegó a la arquitectura objetivo en aspectos de gestión de la información. (Es decir si se resolvieron todas las brechas en este aspecto).


ORIENTADO A LA UTPL

EA – UTPL - 315 - | P á g i n a

3.4 Lista de verificación de seguridad Especificar en una lista si se llegó a la arquitectura objetivo en aspectos de seguridad. (Es decir si se resolvieron todas las brechas en este aspecto). 3.5 Lista de verificación de gestión de sistemas Especificar en una lista si se llegó a la arquitectura objetivo en aspectos de gestión de sistemas. (Es decir si se resolvieron todas las brechas en este aspecto). 3.6 Lista de verificación de ingeniería de sistemas Especificar en una lista si se llegó a la arquitectura objetivo en aspectos de ingeniería de sistemas. (Es decir si se resolvieron todas las brechas en este aspecto). 3.7 Lista de verificación de métodos y herramientas Especificar en una lista si se llegó a la arquitectura objetivo en aspectos de métodos y herramientas. (Es decir si se resolvieron todas las brechas en este aspecto).


ORIENTADO A LA UTPL

EA – UTPL - 316 - | P á g i n a

5.9 Gestión del Cambio de la Arquitectura

Implica monitorear y evaluar los sistemas existentes para determinar cuándo se debe iniciar un nuevo ciclo de ADM en búsqueda de una nueva EA objetivo para la institución.

FasePreliminar



de Información

Fase D:Arquitectura

De Tecnología


Fase F:Plan de

Migración


Fase H:Gestión del

Cambio

Fase A:Visión

Arquitectónica


Fase H:Gestión

Del Cambio

5.9.1 Objetivos

• Garantizar que las arquitecturas de referencia (líneas base) seguirán siendo aptas para el propósito.

• Evaluar el rendimiento de la arquitectura y hacer recomendaciones para el cambio. • Evaluar los cambios a la estructura y principios establecidos en las anteriores fases. • Establecer un proceso arquitectónico de gestión de cambio para la nueva línea base de EA

que es lograda al completar la fase G. • Maximizar el valor de negocio de la arquitectura y de las operaciones en curso. • Operar el framework de gobernanza.

5.9.2 Enfoque

• Asegurarse de que la arquitectura alcanza su original objetivo de valor de negocio. • Gestionar los cambios a la arquitectura de una manera coherente y arquitectónica.


ORIENTADO A LA UTPL

EA – UTPL - 317 - | P á g i n a

• Asegurar el seguimiento continuo de algunos aspectos como las solicitudes de gobierno, nuevos avances tecnológicos, así como los cambios en el entorno del negocio.

• Establecer y apoyar la EA implementada como una arquitectura dinámica. • Controlar el crecimiento del negocio y los cambios. • Poner en práctica la capacidad de medición y las recomendaciones para la planificación. • Establecer un valor y un proceso de gestión del cambio.

5.9.3 Conductores del cambio

La EA puede operar sobre el “vacío”, en general, aunque no siempre de manera formal, hay una infraestructura y un negocio existente que ya está proporcionando valor. Es necesario conocer a nivel de conductores qué enfoques sirven al cambio:

• Estratégico: de arriba hacia abajo, es dirigido el cambio para mejorar o crear nueva capacidad (de capital).

• De abajo hacia arriba: usado para corregir o mejorar la capacidad (operaciones y mantenimiento) para la infraestructura en la gestión de operaciones.

• Experiencias: con los incrementos de proyecto previamente entregados en el cuidado de la gestión de operaciones, pero aún siendo entregados por los proyectos en curso.

La EA adopta un enfoque estratégico de arriba hacia abajo para manejar el cambio. Las

experiencias obtenidas con las lecciones aprendidas del proyecto EA asegurarán que los errores se cometan una sola vez. Algunos conductores relacionados con la tecnología para el cambio de EA son:

• Nuevos informes de tecnología. • Reducciones de los activos de gestión de costes. • Retirada de tecnología (obsoleta). • Iniciativas de estándares.

Los conductores del negocio para el cambio arquitectónico abarcan:

• Desarrollos usuales del negocio. • Excepciones del negocio. • Innovaciones del negocio. • Innovaciones tecnológicas del negocio. • El cambio estratégico.

5.9.3.1 Proceso de gestión de cambio de la EA


ORIENTADO A LA UTPL

EA – UTPL - 318 - | P á g i n a

Este proceso necesita determinar cómo los cambios han de ser gestionados, qué técnicas se van a aplicar, y qué metodologías serán utilizadas. Por esto el proceso necesita una función de filtro que determine qué fases del proceso de desarrollo de la arquitectura se ven afectadas por los requisitos. Para ello se debe clasificar los cambios arquitectónicos requeridos en una de tres categorías:

• Cambio simplificado: Normalmente puede ser manejados a través de técnicas de gestión del cambio.

• Cambio incremental: Puede ser capaz de ser manejado a través de técnicas de gestión del cambio, o puede requerir un rediseño parcial, dependiendo de la naturaleza del cambio.

• Cambio con re-arquitectura: Requiere someter toda la arquitectura de nuevo a través del ciclo de desarrollo arquitectónico.

5.9.3.2 Directrices para lograr dar mantenimiento en lugar de hacer un rediseño arquitectónico

Si el cambio impacta a dos stakeholders o más, entonces es probable que requiera un rediseño de la arquitectura y el reingreso a la metodología de desarrollo arquitectónico. Si el cambio afecta sólo a un stakeholder, entonces es más probable que sea un caso candidato para la gestión del cambio. Por otra parte, si el cambio puede ser permitido por dispensación (consentimiento), entonces es más probable que sea también un caso candidato para la gestión del cambio.

Se podría requerir revitalizar el ciclo (parcial o total re-arquitectura) si: • La arquitectura de fondo tiene que ser re-alineada con la estrategia de negocio. • Cambios sustanciales son requeridos a los componentes y las directrices para el uso en el

despliegue de la arquitectura. • Se busca hacer uso de estándares importantes en el producto.

5.9.4 Entradas

• Materiales arquitectónicos de referencia. 5.9.4.1 No arquitectónicas

• Solicitud para trabajo arquitectónico identificado durante las fases E y F.


• Modelo organizacional para la EA. o Ámbito de aplicación de unidades de negocio afectadas. o Evaluación de madurez, brechas, y el enfoque de la resolución. o Funciones y responsabilidades para el equipo arquitectónico.


ORIENTADO A LA UTPL

EA – UTPL - 319 - | P á g i n a

o Restricciones sobre el trabajo arquitectónico. o Requisitos presupuestados. o Gobernanza y la estrategia de apoyo.






• Plan de actuación arquitectónico. • Solicitud de cambio – Cambios tecnológicos:

o Informes de nuevas tecnologías. o Iniciativas de gestión de activos para reducción de costos. o Informes de retracción de tecnologías. o Iniciativas de estándares.

• Solicitud de cambio – Cambios de negocio: o Desarrollos de negocio. o Excepciones de negocio. o Innovaciones de negocio. o Innovaciones de de negocio en términos de tecnología. o Desarrollos de cambio estratégico.

• Solicitud de cambio. • Arquitectura de transición. • Implementación del modelo de gobernanza. • Contrato arquitectónico. • Solicitud de trabajo arquitectónico. • Plan de implementación y migración.

5.9.5 Salidas

• Actualizaciones de la arquitectura (para cambios de mantenimiento). • Cambios en el framework arquitectónico y en los principios (para cambios de

mantenimiento).


ORIENTADO A LA UTPL

EA – UTPL - 320 - | P á g i n a

• Hacer una nueva solicitud de trabajo arquitectónico para pasar a otro ciclo (por cambios importantes).

• Estatuto de trabajo arquitectónico actualizado, si es necesario. • Contrato arquitectónico actualizado, si es necesario. • Cumplimiento de las evaluaciones actualizado, si es necesario.


ORIENTADO A LA UTPL

EA – UTPL - 321 - | P á g i n a

5.9.6 Definición del proceso para la fase de gestión del cambio Definición de Procesos Proceso: FH – GestionCambio: Gestión del cambio de la

arquitectura. Cod.Doc FH –

GestionCambioX Responsable: DGTI, ADS, DEA, CIO, ADD, DTE, CSI Versión: 1.0 Mantenimiento: DGTI, ADS, ADD, DEA, CSI, DTE Estado: Borrador

Publicado X

Descripción: Es el proceso por el cual se describe monitorear y evaluar los sistemas para determinar cuándo debe aplicarse nuevamente el ADM en busca de una EA objetivo.

Alcance: El proceso de la fase de gestión del cambio, contempla los siguientes procedimientos:

• Asegurarse de que la arquitectura alcanza su original objetivo de valor de negocio.

• Gestionar los cambios a la arquitectura de una manera coherente y arquitectónica.

• Asegurar el seguimiento continuo de algunos aspectos como las solicitudes de gobierno, nuevos avances tecnológicos, así como los cambios en el entorno del negocio.

• Establecer y apoyar la EA implementada como una arquitectura dinámica. • Controlar el crecimiento del negocio y los cambios.

• Poner en práctica la capacidad de medición y las recomendaciones para la planificación.


No aplica





• DGTI: Director de gobernanza de TI. • CSI: Coordinador de servicios de investigación. • ADS: Arquitectos de soluciones • ADD : Arquitectos de dominio • DTE: Director de tecnologías emergentes • CIO: Chief Information Officer • DEA: Director del proyecto EA.

Listado de Cambios



Descripción

1.0 26/10/2010 DGTI, ADS, ADD, DEA, CSI, DTE





ORIENTADO A LA UTPL

EA – UTPL - 322 - | P á g i n a

• Evaluar la EA para poder determinar si requiere redefinirse una nueva arquitectura objetivo para poder aplicar nuevamente el ADM.

• Generar un modelo que facilite la ejecución del ADM y que mantenga lista la arquitectura para someterse a cambios.

Entradas:

Salidas:

• Materiales arquitectónicos referenciales externos a la institución.

• Solicitud de trabajo arquitectónico identificado en las fases E y F.

• Modelo organizacional para la EA. • Framework arquitectónico adaptado. • Estatuto de trabajo arquitectónico. • Visión arquitectónica. • Repositorio arquitectónico. • Documento de definición de la arquitectura. • Especificación de requisitos de la

arquitectura. • Plan de actuación arquitectónico. • Solicitud de cambio – Cambios tecnológicos: • Solicitud de cambio – Cambios de negocio. • Solicitud de cambio. • Arquitectura de transición. • Implementación del modelo de gobernanza. • Contrato arquitectónico. • Solicitud de trabajo arquitectónico.

• Plan de implementación y migración.

• Actualizaciones de la arquitectura (para cambios de mantenimiento).

• Cambios en el framework arquitectónico y en los principios (para cambios de mantenimiento).


• Estatuto de trabajo arquitectónico actualizado, si es necesario.

• Contrato arquitectónico actualizado, si es necesario.

• Cumplimiento de las evaluaciones actualizado, si es necesario.

Roles:

• ADS: Analizar nuevas perspectivas generales de EAs objetivo (si se requiere). • ADD: Analizar unidades de negocio afectadas (por si se requiere modificarlas), así como el

comportamiento de cada uno de los dominios arquitectónicos. • DGTI: Dar soporte al proceso, preparar el esquema para iniciar el ADM. • DTE: Brindar soporte para herramientas y metodologías que ayuden a la nueva ejecución del ADM. • CSI: Analizar y evaluar los mecanismos más adecuados para dar soporte a la nueva ejecución del

ADM. • DEA: Consolidar los aspectos anteriores y empatarlos (pulirlos) para que se alineen mejor a los

objetivos del negocio (asumiendo que han cambiado), y en base a ello ejecutar nuevamente el ADM.


• Plan de implementación y migración. • Framework arquitectónico. • Documento de definición de la arquitectura. • Repositorio arquitectónico. • Esquema de gobernanza.

Tareas:

1. Establecer el proceso de realización del valor.


ORIENTADO A LA UTPL

EA – UTPL - 323 - | P á g i n a

2. Desplegar herramientas de monitoreo. 3. Gestionar riesgos. 4. Proporcionar un análisis para la gestión del cambio de la arquitectura. 5. Desarrollar requisitos de cambio para cumplir los objetivos de rendimiento 6. Administrar el proceso de gobernanza. 7. Activar el proceso de la arquitectura para implementar el cambio

Métricas: • Grados de cumplimiento de la EA y de crecimiento del negocio. • Nivel de preparación de la EA para una nueva ejecución de ADM, de flexibilidad y dinamismo de la

misma.


Gestión del cambio de la arquitectura. Objetivos del Procedimiento:

• Garantizar que las arquitecturas de referencia (líneas base) seguirán siendo aptas para el propósito.

• Evaluar el rendimiento de la arquitectura y hacer recomendaciones para el cambio.

• Evaluar los cambios a la estructura y principios establecidos en las anteriores fases.

• Establecer un proceso arquitectónico de gestión de cambio para la nueva línea base de EA que es lograda al completar la fase G.

• Maximizar el valor de negocio de la arquitectura y de las operaciones en curso.

• Operar el framework de gobernanza. Roles y Responsabilidades:


• ADS: Analizar nuevas perspectivas generales de EAs objetivo (si se requiere).

• ADD: Analizar unidades de negocio afectadas (por si se requiere modificarlas), así como el comportamiento de cada uno de los dominios arquitectónicos.

• DGTI: Dar soporte al proceso, preparar el esquema para iniciar el ADM.

• DTE: Brindar soporte para herramientas y metodologías que ayuden a la nueva ejecución del ADM.

• CSI: Analizar y evaluar los mecanismos más adecuados para dar soporte a la nueva ejecución del ADM.

• DEA: Consolidar los aspectos anteriores y empatarlos (pulirlos) para que se alineen mejor a los objetivos del negocio (asumiendo que han cambiado), y en base a ello ejecutar nuevamente el ADM.

Criterios de Entrada: Los criterios de entrada asociados a este procedimiento se listan a continuación:

• Evaluar la EA para poder determinar si requiere redefinirse una nueva arquitectura objetivo para poder aplicar nuevamente el ADM.


ORIENTADO A LA UTPL

EA – UTPL - 324 - | P á g i n a

Entradas: • Materiales arquitectónicos de referencia. • Solicitud para trabajo arquitectónico identificado durante las fases E

y F. • Modelo organizacional para la EA.









• Plan de actuación arquitectónico. • Solicitud de cambio – Cambios tecnológicos:

o Informes de nuevas tecnologías. o Iniciativas de gestión de activos para reducción de costos. o Informes de retracción de tecnologías. o Iniciativas de estándares.

• Solicitud de cambio – Cambios de negocio: o Desarrollos de negocio. o Excepciones de negocio. o Innovaciones de negocio. o Innovaciones de de negocio en términos de tecnología. o Desarrollos de cambio estratégico.

• Solicitud de cambio. • Arquitectura de transición. • Implementación del modelo de gobernanza. • Contrato arquitectónico. • Solicitud de trabajo arquitectónico.

• Plan de implementación y migración. Pasos y Actividades Los pasos necesarios para este procedimiento se listan a continuación:


ORIENTADO A LA UTPL

EA – UTPL - 325 - | P á g i n a

del Procedimiento: 1. Establecer el proceso de realización del valor.

• Influenciar proyectos de negocio para explotar la EA para

la realización del valor.

2. Desplegar herramientas de monitoreo.

Es necesario para ello asegurarse que las herramientas de seguimiento sean desplegadas y aplicadas para permitir:

• Monitorear los cambios tecnológicos que podrían afectar a la línea de base de la arquitectura.

• Monitorear los cambios del negocio que podrían afectar a la línea base.

• Dar seguimiento al valor de negocio, por ejemplo, con el método de valoración de las inversiones, para determinar las cifras de valor para los objetivos de negocio.

• Monitorear la capacidad de madurez de la EA. • Dar seguimiento y evaluación de programas de gestión de

activos. • Dar seguimiento de la calidad del funcionamiento del

servicio y su uso. • Determinar y realizar el seguimiento de continuidad de los

requisitos de negocio. 3. Gestionar los riesgos.

• Gestionar los riesgos de la EA y proveer recomendaciones para una estrategia de TI.

4. Proporcionar un análisis para la gestión del cambio de la

arquitectura.

• Analizar el rendimiento. • Dirigir revisiones del rendimiento de la EA usando gestión de

servicios. • Evaluar las solicitudes de cambio e informes para asegurar que

las expectativas de los clientes son cumplidas, con respecto a la realización del valor esperado y del acuerdo de nivel de servicio (SLA, por sus siglas en inglés).

• Resaltar un análisis de brechas de rendimiento de la EA. • Asegurarse que las solicitudes de gestión del cambio se

adhieren a la gobernanza de la EA y su framework. 5. Desarrollar requisitos de cambio para cumplir los objetivos de

rendimiento.


ORIENTADO A LA UTPL

EA – UTPL - 326 - | P á g i n a

• Hacer recomendaciones sobre los requisitos de cambios para cumplir con los objetivos de rendimiento así como de desarrollo.

6. Administrar el proceso de gobernanza.

• Organizar reuniones de la junta de la arquitectura. • Mantener reuniones de la Junta de Arquitectura con el objetivo

de decidir sobre el manejo de los cambios (tecnológicos, empresariales y dispensaciones).

7. Activar el proceso de la arquitectura para implementar el cambio.

• Producir una nueva solicitud de trabajo arquitectónico, así como

una solicitud para la inversión.

• Asegurarse de que todos los cambios implementados en esta fase son capturados y documentados en el repositorio arquitectónico.

Salidas: • Actualizaciones de la arquitectura (para cambios de mantenimiento).

• Cambios en el framework arquitectónico y en los principios (para cambios de mantenimiento).


• Estatuto de trabajo arquitectónico actualizado, si es necesario. • Contrato arquitectónico actualizado, si es necesario.

• Cumplimiento de las evaluaciones actualizado, si es necesario. Criterios de Salida: Los criterios de salida para este procedimiento se listan a continuación:

• Generar un modelo que facilite la ejecución del ADM y que

mantenga lista la arquitectura para someterse a cambios.

Métricas del Proceso: Las métricas que deben recopilarse en este procedimiento incluyen: • Grado de cumplimiento de la EA con su objetivo principal objetivo:

dar valor al negocio. • Nivel de preparación de la EA para una nueva ejecución de ADM. • Nivel de flexibilidad y dinamismo de la EA. • Grado de crecimiento del negocio y los cambios.


ORIENTADO A LA UTPL

EA – UTPL - 327 - | P á g i n a

5.9.7 Plantillas para la fase de gestión del cambio de la arquitectura

5.9.7.1 Plantilla para levantamiento de: Evaluación del impacto de los requisitos

Evaluación del Impacto de los Requisitos


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de éste documento 2 Detalles básicos 3 Evaluación de impacto 4 Recomendaciones Información del documento



Preparado por:


Título: Evaluación de Impacto de Requisitos Fecha de Versión: Revisado por:

Fecha de Revisión:







ORIENTADO A LA UTPL

EA – UTPL - 328 - | P á g i n a


Nro. de Versión

Fecha de Versión


1 Propósito Este documento detalla la Evaluación del Impacto de Requerimientos para el proyecto denominado EA-UTPL. A través del ciclo arquitectónico (fases), la nueva información es recolectada relacionándola a una arquitectura. Como esta información es encontrada, nuevas realidades pueden salir a la luz que invaliden aspectos existentes en dicha arquitectura. Esta plantilla muestra el contenido “de una Evaluación del Impacto de Requerimientos y puede ser adaptada para alinearse con EA-UTPL. 2 Detalles básicos Abordar cuales requisitos se relacionan en mayor grado con las metas de negocio de la institución. 2.1 Referencia a requerimientos específicos Listar los requerimientos más preponderantes dados para el proyecto EA-UTPL desde la perspectiva del equipo Arquitectónico. 2.2 Prioridad de requerimientos de stakeholders (actualizada) Listar los requerimientos más preponderantes desde el punto de vista de los interesados (stakeholders) 3 Evaluación de Impacto Una Evaluación del Impacto de Requerimientos evalúa los requerimientos actuales de la arquitectura y especificación para identificar los cambios que deben ser hechos y las implicaciones de estos cambios. 3.1 Fases revisadas Listar las fases que han sido terminadas y revisadas en base al cumplimiento de los requisitos especificados en la sección 2 de esta plantilla. 3.2 Priorización de requisitos De haber hechos fuera de lo esperado, como por ejemplo un requisito no cumplido en su totalidad a pesar de haber sido tratado en una fase específica, especificar cómo se puede consolidar ese requisito para no impactar a otras fases de manera significativa. (revisar flujos alternos de trabajo, de contingencia)


ORIENTADO A LA UTPL

EA – UTPL - 329 - | P á g i n a

3.3 Resultados de la fase de investigaciones y prioridades revisadas

4 Recomendaciones Para la gestión de los requisitos es necesario llevar a cabo los procesos propuestos y adoptar métodos formales, pero también es importante considerar un conjunto de buenas prácticas (recomendaciones) en dos aspectos principales: 4.1 Recomendaciones de administración de requerimientos Listar las recomendaciones dadas para una adecuada gestión administrativa de requerimientos. 4.2 Número de referencia en el repositorio Tener una referencia coherente y consistente en el repositorio asegura que cada uno de los recursos (en este caso los requisitos) estén enlazados debidamente con otros recursos de su competencia y sean priorizados adecuadamente.


ORIENTADO A LA UTPL

EA – UTPL - 330 - | P á g i n a

5.9.7.2 Plantilla para levantamiento de: Solicitud de cambio arquitectónico

Solicitud de Cambio Arquitectónico


__________________________________________________________________________________________

<<Nota: Este documento provee una plantilla base. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Propósito de este documento 2 Detalles básicos 3 Descrición de cambios 4 Justificación del cambio e impactos Información del documento



Preparado por:


Título: Solicitud de Cambio de Arquitectura Fecha de Versión: Revisado por:

Fecha de Revisión:







ORIENTADO A LA UTPL

EA – UTPL - 331 - | P á g i n a

Nro. de Versión

Fecha de Versión


1 Propósito Limitar la evaluación y aprobación de la solicitud de cambio para la arquitectura. 2 Detalles básicos La meta de un proceso de gestión de cambio de arquitectura es asegurar que los logros arquitectónicos mantengan el objetivo del valor original del negocio. Esto incluye la gestión de cambios de la arquitectura en una vía cohesiva y arquitectónica. La gestión de procesos de cambio determinará: • Las circunstancias bajo las cuales la arquitectura empresarial, o partes de ella, serán permitidas para

cambiar después de la implementación, y los procesos por los cuales esto sucederá. • Las circunstancias bajo las cuales el ciclo de desarrollo de la arquitectura (ADM) será inicializado otra vez

en un nuevo desarrollo arquitectónico Los cambios pueden ser especificados siguiendo la estructura:

ID del Cambio <<ID para identificar únicamente la solicitud de cambio >> Título del Cambio <<Título del resumen en línea para el cambio >> Solicitante del Cambio

<<Nombre>> <<Posición>> <<Organización>> <<email>> <<Tel>>

Patrocinadores(s) del Cambio

<<Detalles del auspiciante de este cambio >>

Línea de Tiempo <<Cualquier línea de tiempo para la implementación de cambios, incluyendo la razón>>

3 Descripción de cambios En esta sección se debe describir el cambio y su propósito (Otros documentos pueden ser referenciados donde sea necesario.) 4 Justificación de los cambios e Impacto Esta sección recoge la justificación formal para cada uno de los cambios solicitados para la EA, así como el impacto que cada uno de ellos tendrá en EA-UTPL, de adoptarse dichos cambios. 4.1 Controladores de Cambios Para listar los cambios se recomienda seguir la siguiente estructura:


ORIENTADO A LA UTPL

EA – UTPL - 332 - | P á g i n a

Los siguientes controladores de cambios son relevantes:

Conductores del Negocio Desarrolladores de Negocio usuales Excepciones del Negocio Innovaciones del Negocio Innovaciones Tecnológicas del Negocio Cambios Estratégicos Conductores Tecnológicos Reportes de Nuevas Tecnologías Evaluación de administración de reducción de costos

Tecnología obsoleta Iniciativas de Estándares Conductores Operaciones Implementaciones basadas en experiencia operacional

Planeación de la capacidad

4.2 Justificación de cambios Cualquier justificación más profunda de cambios. Incluyendo un análisis de implicaciones explicando que pasa si no se adoptan los cambios. 4.3 Impactos Anticipados Proveer, tanto como sea posible, una breve vista inicial de los impactos probables derivados del cambio. Por ejemplo, Reconstrucciones anticipadas de arquitectura, cambios probables del sistema de acuerdo al resultado, áreas del negocio afectadas para la UTPL.


ORIENTADO A LA UTPL

EA – UTPL - 333 - | P á g i n a

6.0 PLAN DE ACCIÓN PARA LA IMPLANTACION DEL PROYECTO EA-UTPL

6.1 Refinamiento del framework

Una vez estructurado el framework arquitectónico y con la finalidad de dar visibilidad del trabajo realizado, se propone realizar la puesta en marcha del proyecto EA-UTPL para levantar la estructura arquitectónica de la institución, haciendo uso de los artefactos, métodos y procesos establecidos en los capítulos anteriores.

Si se opta por la ejecución de un plan piloto, a través de él se podrá obtener un mejor

refinamiento del framework de acuerdo a las sugerencias dadas por los stakeholders involucrados en el proyecto (ya desde un enfoque netamente práctico).

De lo anterior deriva la recomendación de aprovechar la naturaleza federada y de

segmentación del framework para aplicarlo a una sección de la organización. La implementación del plan piloto brindará la retroalimentación necesaria para el refinamiento del framework, con lo que podrá ser expandido a un dominio global de la organización.

Para lograr la ejecución se han establecido las siguientes actividades a realizar: • Capacitar de las nuevas funciones y responsabilidades definidas en el área (tanto miembros

del equipo de EA como stakeholders afectados) para cada uno de los procesos EA. • Implementar los entregables y artefactos de los procesos correspondientes a cada fase. • Obtener resultados parciales para evaluar algunos factores del framework definido. • Definir soluciones para corregir los problemas presentados en el framework (si fuese

necesario).

Una vez implementado el plan piloto, recopiladas sugerencias sobre dicha implementación y a través de reuniones (con stakeholders clave) de aprobación del refinamiento; se procederá a la validación final del framework y puesta en marcha del mismo en el levantamiento arquitectónico de toda la institución. 6.2 Implementación de la solución EA

El refinamiento anterior asegurará la correcta operatividad de cada una de las fases del ADM, permitiendo dar paso a la implementación de la EA en toda la institución. A continuación se especifica una matriz FODA desde la perspectiva EA-UTPL, y en formato de cronogramas se plantean los planeas de acción que engloban el proceso de ejecución.


ORIENTADO A LA UTPL

EA – UTPL - 334 - | P á g i n a

6.2.1 Plan de acción

El plan de acción especificado en la sección 7.2.3 aborda las tareas, responsables, tiempos,

recursos, costos, e indicadores necesarios para la ejecución del proyecto EA-UTPL. Para la adaptación del plan de acción a una implementación piloto se deben considerar todos los pasos de la matriz pero estableciendo tiempos y costos menores para cada una de las tareas; dichos tiempos y costos deben estimarse en relación al tamaño del área (segmento), sobre el cual se buscará implementar el plan piloto, con respecto al tamaño de toda la institución.

6.2.2 Análisis FODA

Previo a la ejecución del poyecto se dederá realizar un anásis FODA enfocado a la EA y a

nivel institucional, tanto para el ambiente micro como macro de la UTPL. El esquema a de análisis puede ser representado en una matriz como la siguiente:

Tabla 16: Esquema de FODA

FACTORES INTERNOS FACTORES EXTERNOS

FORTALEZAS (Maxi)

DEBILIDADES (Mini)

OPORTUNIDADES (Maxi)

Estrategia FO Maxi - Maxi Potenciar las fortalezas para aprovechar las oportunidades.

Estrategia DO Mini - Maxi Superar las debilidades para aprovechar las oportunidades.

AMENZAS (Mini)

Estrategia FA Maxi - Mini Usar las fortalezas para enfrentar las amenazas.

Estrategia DA Mini - Mini Superar las debilidades para enfrentar las amenazas.

6.2.3 Plan de acción

Tabla 17: Plan de acción


ORIENTADO A LA UTPL

EA – UTPL - 335 - | P á g i n a

NOMBRE DEL PROGRAMA: Implementación del proyecto EA-UTPL mediante el uso del framework arquitectónico definido en el presente proyecto de tesis: “Integración de buenas prácticas para la definición de un framework de arquitectura empresarial para la UTPL” Nota1: La columna “Acciones” abarca cada uno de los procesos descritos en las especificaciones de flujos de procesos del capítulo 5, mientras que la columna “Tareas” describe el subconjunto de tareas (subprocesos) necesarias para consolidar cada uno de dichos procesos (fases). Nota 2: Se denominan “Entregables” en la columna “Producto de trabajo relacionado” al conjunto de documentos que se obtendrán al hacer uso de cada una de las plantillas de levantamiento (y especificación) de información descritos luego de cada flujo de proceso (capítulo 5), por ello el término “entregables” debe entenderse como análogo a “plantillas”. En cambio las palabras mencionadas “catálogo, matriz, etc.” hacen referencia a “artefactos arquitectónicos”, los cuales servirán como información técnica (del equipo EA) para el levantamiento de la arquitectura, dichos artefactos se encuentran estructuralmente definidos en el Anexo 1.1. Nota 3: Debe entenderse que si bien los catálogos son generalmente estáticos, pueden sufrir cambios durante el proceso EA, mientras que los Entregables sufrirán cambios constantes (versiones) dependiendo de la fase en la que sean utilizados (ejemplo: el entregable de Visión arquitectónica es mencionado como artefacto de otras fases debido a que esta visión debe ir refinándose y estableciéndose en cada). Nota 4: Para tener una visión clara de la información especificada en las columnas, “responsable de la tarea” y “responsable de seguimiento” es necesario tener clara la asignación de roles para el equipo EA descrita en el capítulo 5.1.4 Nota 5: Cuando se habla de “entregable de contenido en repositorio arquitectónico” o “especificación en contenido arquitectónico” implica el levantamiento de dicha información dentro del repositorio arquitectónico. De manera ideal todos los entregables, artefactos y demás recursos deberían estar contenidos en el repositorio, pero cuando se habla de “entregable de contenido en repositorio arquitectónico” se hace mención a la obligatoriedad de cierto recurso para ser contenido en el repositorio. Nota 6: Para referencias a los recursos necesarios en la columna “producto de trabajo relacionado” y “recursos necesarios”, se usará la nomenclatura “ver cap.n.n” cuando se hable de entregables (plantillas), para especificar la plantilla específica que debe usarse; mientras que para los catálogos, matrices y demás artefactos se usará la nomenclatura de referencia “ver anx. n.n”, cuya fuente son los anexos al final de la tesis.

SECTOR ESTRATÉGICO: UTPL

Acciones Tareas Responsable de la Tarea

Tiempos Recursos necesarios Cos-

tos Producto de trabajo

relacionado Responsable del seguimiento Inicio Final

DEFINIR Y LEVANTAR LOS RECURSOS

Enlistar y consolidar el equipo de trabajo. - DEA. Día 1 Día 8

- Perfiles de candidatos a miembros del grupo

- Catálogo de miembros del proyecto. (ver anx.1.1.1)

- Líder de TI de la UTPL (CIO)

- DEA


ORIENTADO A LA UTPL

EA – UTPL - 336 - | P á g i n a

ESPECIFICADOS EN LA FASE PRELIMINAR (Revisar el capítulo 5.1 para información general. Para levantar los entregables, las plantillas se encuentran descritas en la sección 5.1.10. Mientras que los artefactos están descritos en el Anexo 1.1.1)

- Entregable de contenido en repositorio arquitectónico. (ver cap. 5.1.10.6)

- Director de DGTIs

Recoger y analizar modelos pre-existentes pueden ser usados como línea base para poner en marcha el proyecto EA.

- Directores de CSIs, ADSs y ADDs.

Día 9 Día 16 - Especificación de

modelos usados por la institución

- Entregable del modelo organizacional de la EA. (ver cap. 5.1.10.1)

- Entregable de contenido en repositorio arquitectónico.

(ver cap. 5.1.10.6)


- DEA - Director de

DGTIs

Especificar y analizar planes, estrategias, principios y objetivos de negocio de la institución.

- Directores de CSIs, ADSs y ADDs

Día 17 Día 24 - Especificación de

negocio de la institución.


- Entregable de principios de negocio. (ver cap. 5.1.10.2)

- Catálogo de principios. (ver anx.1.1.1)



- DEA - Director de

DGTIs

Especificar y analizar la estrategia de gobernanza actual así como las políticas y normas de la

- Director es de DGTIs. Y ADSs, DEA

Día 25 Día 32

- Esquema de gobernanza.

- Estatuto de políticas y normas institucionales.

- Entregable de principios de negocio. (ver cap. 5.1.10.2)

- Entregable de


- DEA - Director de


ORIENTADO A LA UTPL

EA – UTPL - 337 - | P á g i n a

institución. contenido en repositorio arquitectónico. (ver cap. 5.1.10.6)

DGTIs

Especificar y analizar los principales frameworks del negocio (ej.: de gestión de portafolios / proyectos).

- Director de DGTIs, ADSs, ADDs,

Día 33 Día 40

- Especificación de frameworks de gestión usados en la institución.

- Entregable del modelo organizacional de la UTPL con respecto a la EA (adaptación). (ver cap. 5.1.10.5)



- DEA - Director de

DGTIs

Recoger y analizar los resultados de la aplicación del plan piloto (si este fue implementado).

- Directores de ADSs, ADDs, DTEs y CSIs.

Día 41 Día 48 - Informe de resultados

de la implementación de la EA piloto.



- DEA - Director de

DGTIs

Especificar, analizar y levantar la estrategia de TI, así como un esbozo de principios arquitectónicos.

- Directores de DTEs, CSIs, ADSs y ADDs

Día 49 Día 56

- Especificación de principios institucionales.

- Estrategia de TI actual.

- Entregable de adaptación de la EA. (ver cap. 5.1.10.5)

- Entregable de principios arquitectónicos.

- (ver cap. 5.1.10.3) - Catálogo de

principios. (ver anx.1.1.1)

- Entregable de contenido en repositorio arquitectónico.


- DEA - Director de

DGTIs


ORIENTADO A LA UTPL

EA – UTPL - 338 - | P á g i n a

(ver cap. 5.1.10.6)

Seleccionar las herramientas arquitectónicas.

- Director de DTEs y ADSs.

Día 57 Día 62

- Análisis de herramientas establecido en el capítulo 3.



- DEA - Director de

DGTIs - Director de

DTEs

Determinar el presupuesto estimado para el alcance del proyecto.

- Director de ADSs.

- DEA. Día 63 Día 65 - Plan de acción para

la EA.

- Incluir en Entregable de solicitud de trabajo arquitectónico. (ver cap. 5.1.10.4)


- DEA

Realizar un análisis FODA para el proyecto en proporciones micro y macro.

- DEA. - CIO. - Directores de

ADSs, ADDs y CSIs.

Día 66 Día 75

- Especificación de negocio (modelo, principios, objetivos, dominio, etc.)

- Incluir en Entregable de solicitud de trabajo arquitectónico. (ver cap. 5.1.10.4)


- Director de CSIs

Preparar el framework para la ejecución de la fase A. (Establecer la solicitud de trabajo arquitectónico)

- DEA. - CIO - Directores de

DGTIs y DTEs.

Día 76 Día 90

- Repositorio arquitectónico.

- Artefactos y entregables especificados hasta ahora.

- Entregable de solicitud para trabajo arquitectónico. (ver cap. 5.1.10.4)


- DEA - Director de

DGTI

FASE A: ESTABLECER LA VISION ARQUITECTONICA (Revisar el capítulo 5.2 para información general. Para levantar los entregables, las

Identificar stakeholders principales y secundarios, así como sus expectativas y requerimientos del negocio

- Directores de CSIs y DTEs.

- DEA. Día 91 Día 102

- Modelo organizacional con descripción de personal

- Entregable de plan de comunicaciones. (ver cap. 5.2.7.3)

- Matriz de stakeholders (ver anx.1.1.2)

- DEA

Formalizar la especificación de los objetivos, conductores

- DEA, CIO. - Director de

CSIs. Día 103 Día 110

Entregable del modelo organizacional de la

Entregable de visión arquitectónica.

- DEA


ORIENTADO A LA UTPL

EA – UTPL - 339 - | P á g i n a

plantillas se encuentran descritas en la sección 5.2.7 mayoritariamente. Mientras que los artefactos están descritos en el Anexo 1.1.2)

y limitaciones del negocio.

UTPL respecto a la EA. (ver cap. 5.1.10.1)

(ver cap. 5.2.7.4)

Evaluar la capacidad empresarial de la institución.

- DEA, CIO. - Director de

CSIs. Día 111 Día 115

- Análisis de rendimiento, procesos de cambio y procesos operacionales de la institución. (ver cap. 5.1.10.5)

Entregable de plan de evaluación de la capacidad. (ver cap. 5.2.7.2)

- DEA

Evaluar la disposición para la transformación del negocio.

- DEA. - Directores de

DTEs, CSIs y ADDs.

Día 116 Día 125

- Indicadores de

transformación de negocio. (ver cap. 5.1.10.1) (ver cap. 5.1.10.2)

- Entregable de plan de evaluación de la capacidad. (ver cap. 5.2.7.2)

- Entregable de visión arquitectónica. (ver cap. 5.2.7.4)

- DEA

Definir la línea base y el alcance de la EA.


ADSs, ADDs, DTEs y CSIs.

-

Día 126 Día 140


- Entregable del modelo organizacional de la UTPL respecto a la EA. (ver cap. 5.1.10.1)

- Entregable de principios organizacionales. (ver cap. 5.1.10.2)

- Entregable de principios arquitectónicos. (ver cap. 5.1.10.3)

Entregable de visión arquitectónica refinado. (ver cap. 5.2.7.4) Entregable declaración de trabajo arquitectónico refinado. (ver cap. 5.2.7.1)

- DEA


ORIENTADO A LA UTPL

EA – UTPL - 340 - | P á g i n a

Confirmar los principios arquitectónicos.

- DEA. - Director de

ADDs y de ADSs.

Día 141 Día 150

- Catálogo de principios (incluye los institucionales como los arquitectónicos).

(ver anx.1.1.1)

- Entregable de principios arquitectónicos refinado. (ver cap. 5.1.10.3)

- Catálogo de principios. ver anx.1.1.1)

- DEA

Definir la visión arquitectónica. (considerar KPIs)


ADDs y de ADSs.

Día 151 Día 170


- Entregable del modelo organizacional. (ver cap. 5.1.10.1).

- Entregable de principios organizacionales. (ver cap. 5.1.10.2)

- Entregable de principios arquitectónicos. (ver cap. 5.1.10.3)

- Entregable de visión arquitectónica refinado. (ver cap. 5.2.7.4)

- DEA

Identificar los riesgos de transformación empresarial y establecer actividades de mitigación.

- Directores de CSIs, ADSs, DGTIs y DTEs.

- DEA.

Día 171 Día 180



- Matriz de riesgos dada en Declaración de trabajo Arquitectónico. (ver cap. 5.2.7.1)

- DEA

Formalizar la solicitud de trabajo arquitectónico y de aprobación de la EA


DGTIs y DTEs.

- CIO

Día 181 Día 190


- Entregable de visión arquitectónica. (ver

- Entregable de declaración de trabajo arquitectónico refinado. (ver cap. 5.2.7.1)

- DEA


ORIENTADO A LA UTPL

EA – UTPL - 341 - | P á g i n a

cap. 5.2.7.4) - Entregable de plan de evaluación de la capacidad. (ver cap. 5.2.7.2)


FASE B: DEFINIR LA ARQUITECTURA DE NEGOCIO (Revisar el capítulo 5.3 para información general. Para levantar los entregables, las plantillas se encuentran descritas en la sección 5.3.8 mayoritariamente. Mientras que los artefactos están descritos en el Anexo 1.1.3)

Seleccionar los modelos de referencia, puntos de vista y herramientas de modelado de negocio.

- Directores de ADDs, ADSs, CSIs y DTEs.

Día 191 Día 200


- Especificación de modelos usados por la institución.



- Matriz de interacciones de negocio. (ver anx. 1.1.3)

- Catálogo de roles. (ver anx. 1.1.3)

- Catálogo de productos. (ver anx. 1.1.3)

- Directores de ADDs y ADSs

Levantar una descripción de la línea base de la arquitectura de negocio.

- Directores de ADSs y de ADDs.

Día 201 Día 220


- Entregable del modelo organizacional. (ver cap. 5.1.10.1)

- Catálogo de principios. (ver anx. 1.1.1)


Levantar una descripción de arquitectura de negocio objetivo.


Día 221 Día 240






ORIENTADO A LA UTPL

EA – UTPL - 342 - | P á g i n a

Realizar un análisis de brechas entre las dos tareas anteriores.

- Director de CSIs.


DTEs.

Día 241 Día 250


- Especificación de requisitos arquitectónicos. (ver cap. 5.3.8.1)

- Director de CSIs

- DEA

Definir los componentes de negocio para el Roadmap.

- Directores de CSIs, ADSs y de ADDs.

- DEA

Día 251 Día 255


- Artefactos descritos en la sección 5.2 para esta fase.

- Entregable de Roadmap de la arquitectura. (ver cap. 5.3.8.2)


Resolver los impactos para esta fase.

- Director de CSIs, DTEs y ADSs.

- DEA.

Día 256 Día 260

- Entregable de evaluación de la capacidad (Análisis de impactos). (ver cap. 5.2.7.2)

- Entregable de evaluación de la capacidad refinado. (ver cap. 5.2.7.2)

- Director de CSIs.

Revisar la posición actual de los stakeholders con respecto al avance de proyecto.



- Catálogo de stakeholders. (ver anx. 1.1.2)

- Entregable de declaración de trabajo arquitectónico. (ver cap. 5.2.7.1)

- Entregable de declaración de trabajo arquitectónico actualizado. (ver cap. 5.2.7.1)

- DEA

Documentar la definición de la arquitectura de negocio y finalizar esta fase.

- Directores de ADDs y ADSs.

Día 266 Día 280


- Entregables y artefactos para esta fase, descritos en la sección 5.3


- Entregable de especificación del Roadmap de la arquitectura. (ver cap. 5.3.8.2)



ORIENTADO A LA UTPL

EA – UTPL - 343 - | P á g i n a

FASE C1: DEFINIR LA ARQUITECTURA DE DATOS (Revisar el capítulo 5.4.1 para información general. Para levantar los entregables, la plantilla clave se encuentra descrita en la sección 5.4.4.6. Mientras que los artefactos están descritos en el Anexo 1.1.4.1)

Seleccionar los modelos de referencia, puntos de vista y herramientas de modelado de datos.


Día 281 Día 290



- Entregable del modelo organizacional para la EA. (ver cap. 5.1.10.1)

- Entregable de visión arquitectónica. . (ver cap. 5.2.7.4)

- Entregable de especificación de la arquitectura de datos (ver cap. 5.4.4.6.1)

- Catálogo de componentes de datos. (ver anx. 1.1.4.1)

- Matriz de datos. (ver anx. 1.1.4.1)

- Matriz de funciones de negocio. (ver anx. 1.1.4.1)


Levantar una descripción de la línea base de la arquitectura de datos.


Día 291 Día 310





Levantar una descripción de arquitectura de datos objetivo.


Día 311 Día 330






- Director de CSIs.


DTEs.

Día 331 Día340


- Especificación de requisitos arquitectónicos (sección datos). (ver cap. 5.3.8.1)

- Director de CSIs

- DEA

Definir los componentes de datos para el Roadmap.


- DEA

Día 341 Día 345


- Artefactos descritos

- Entregable de Roadmap de la arquitectura. (parte de datos)



ORIENTADO A LA UTPL

EA – UTPL - 344 - | P á g i n a

en la sección 5.2 para esta fase.

(ver cap. 5.3.8.2)



- DEA.

Día 346 Día 350

- Entregable de evaluación de la capacidad. (ver cap. 5.2.7.2)


- Director de CSIs.







- DEA

Documentar la definición de la arquitectura de datos y finalizar esta fase.


Día 356 Día 370


- Entregables y artefactos para esta fase, descritos en la sección 5.4.1

- Entregable de especificación de la arquitectura de datos (ver cap. 5.4.4.6.1)


- Entregable de especificación del Roadmap de la arquitectura (parte de datos). (ver cap. 5.3.8.2)


FASE C2: DEFINIR LA ARQUITECTURA DE APLICACIONES (Revisar el capítulo 5.4.2 para

Seleccionar los modelos de referencia, puntos de vista y herramientas de modelado de aplicaciones.


Día 371 Día 380



- Entregable de

visión arquitectónica refinado. . (ver



ORIENTADO A LA UTPL

EA – UTPL - 345 - | P á g i n a

información general. Para levantar los entregables, la plantilla clave se encuentra descrita en la sección 5.4.5.5. Mientras que los artefactos están descritos en el Anexo 1.1.4.2)

cap. 5.2.7.4) - Entregable

declaración de trabajo arquitectónico. (ver cap. 5.2.7.1)

- Entregable de especificación de arquitectura de aplicaciones. (ver cap. 5.4.5.5.1)

- Catálogos de interfaces y de portafolio de aplicaciones. (ver anx. 1.1.4.2)

Levantar una descripción de la línea base de la arquitectura de aplicaciones.


Día 381 Día 400





Levantar una descripción de arquitectura de aplicaciones objetivo.


Día 401 Día 420






- Director de CSIs.


DTEs.

Día 421 Día 430



- Director de CSIs

- DEA

Definir los componentes de aplicaciones para el Roadmap.


- DEA

Día 431 Día 435







- DEA.

Día 436 Día 440



- Director de CSIs.


ORIENTADO A LA UTPL

EA – UTPL - 346 - | P á g i n a







- DEA

Documentar la definición de la arquitectura de aplicaciones y finalizar esta fase.


Día 446 Día 460


- Entregables y artefactos para la fase C2, descritos en el capítulo 5.4.2.

- Entregable de especificación de arquitectura de aplicaciones. (ver cap. 5.4.5.5.1)


- Entregable de especificación del Roadmap de la arquitectura (parte de apps). (ver cap. 5.3.8.2)


FASE D: DEFINIR LA ARQUITECTURA DE TECNOLOGIA (Revisar el capítulo 5.5 para información general. Para levantar los entregables, la plantilla central se encuentra descrita en la sección 5.5.7. Mientras que los

Seleccionar los modelos de referencia, puntos de vista y herramientas de modelado de tecnología.


Día 461 Día 470





- Entregable de especificación de arquitectura


Levantar una descripción de la línea base de la arquitectura de tecnología


Día 471 Día 490


- Entregable del modelo organizacional. (ver



ORIENTADO A LA UTPL

EA – UTPL - 347 - | P á g i n a

artefactos están descritos en el Anexo 1.1.5)

cap. 5.1.10.1) - Catálogo de

principios. (ver anx. 1.1.1)

tecnológica. (ver cap. 5.5.7.1)

- Matriz de tecnología. (ver anx. 1.1.5)

- Catálogos de portafolio tecnológico, de tecnologías estándar, de procesamiento, de rede de datos y hardware. (ver anx. 1.1.5)

Levantar una descripción de arquitectura de tecnología objetivo.


Día 491 Día 510






- Director de CSIs.


DTEs.

Día 511 Día 520



- Director de CSIs

- DEA

Definir los componentes tecnológicos para el Roadmap.


- DEA

Día 521 Día 525







- DEA.

Día 526 Día 530



- Director de CSIs.





- Entregable de declaración de

- Entregable de declaración de trabajo arquitectónico actualizado. (ver

- DEA


ORIENTADO A LA UTPL

EA – UTPL - 348 - | P á g i n a

trabajo arquitectónico. (ver cap. 5.2.7.1)

cap. 5.2.7.1)

Documentar la definición de la arquitectura tecnológica y finalizar esta fase.


Día 536 Día 550


- Entregables y artefactos para la fase D, descritos en el capítulo 5.5.

- Entregable de especificación de arquitectura tecnológica. (ver cap. 5.5.7.1)


- Entregable de especificación del Roadmap de la arquitectura (parte de tecnología). (ver cap. 5.3.8.2).


FASE E: ESTABLECER OPORTUNIDADES Y SOLUCIONES (Revisar el capítulo 5.6 para información general. Para levantar los entregables, las plantillas centrales se encuentran descritas en la sección 5.6.5 mayoritariamente. Mientras que los artefactos están descritos en el Anexo 1.1.6)

Establecer los atributos clave para el cambio institucional.

- Directores de CSIs, DTEs, DGTIs.

- DEA.

Día 551 Día 557

- Entregable de requisitos arquitectónicos. (ver cap. 5.3.8.1)



- Entregable de arquitectura de transición. (ver cap. 5.6.5.1)

- Director de CSIs.

Determinar restricciones del negocio ante la implementación.

- Directores de ADSs, ADDS, DTEs y CSIs.

- DEA.

Día 557 Día 563



- Plan de implementación y migración. (ver cap. 5.6.5.2)


- DEA


ORIENTADO A LA UTPL

EA – UTPL - 349 - | P á g i n a


Realizar un análisis y evaluación de la madurez de la EA.

- DEA. - CIO. - Directores de

ADSs, DTEs y CSIs.

Día 563 Día 570






- DEA

Revisión de alineamiento a los planes estratégicos del negocio.

- CIO. - DEA. Día 571 Día 575

- Especificación del negocio.

- Entregable de principios, de requisitos y la visión arquitectónica.


- CIO - DEA

Consolidar los resultados de los análisis de brechas de las fases B, C y D.

- Director de CSIs.


DTEs.

Día 576 Día 582

- Especificación de requisitos arquitectónicos de las fases B, C y D. (ver cap. 5.3.8.1)

- Especificación de requisitos arquitectónicos refinada y finalizada. (ver cap. 5.3.8.1)

Revisar los requisitos de TI de manera funcional

- Directores de ADDs, ADSs y DTEs.

- DEA.

Día 583 Día 588

- Entregable de requisitos arquitectónicos. . (ver cap. 5.3.8.1)


- Entregable de especificación de requisitos arquitectónicos (ver cap. 5.3.8.1)


Consolidar los requisitos de interoperabilidad (base y objetivo).


Día 589 Día 595

- Entregable de requisitos arquitectónicos. Entregable de

- Entregable de especificación de requisitos arquitectónicos



ORIENTADO A LA UTPL

EA – UTPL - 350 - | P á g i n a

especificación de requisitos arquitectónicos (ver cap. 5.3.8.1)

- Catálogo de requisitos. (ver anx. 1.1.2)


(ver cap. 5.3.8.1) - Catálogo de

requisitos (ver anx. 1.1.2)

Refinar y formalizar dependencias.


DGTIs, ADDs y CSIs.

Día 596 Día 600


- Documento de declaración del trabajo arquitectónico (ver cap. 5.2.7.1).

- Entregable Plan de implementación y migración. (ver cap. 5.6.5.2)


- Entregable de visión arquitectónica refinado. (ver cap. 5.2.7.4)

- DEA

Confirmar la preparación y el riesgo de transformación del negocio.

- Directores de CSIs, ADSs, DGTIs y DTEs.

- DEA.

Día 601 Día 605



- Entregable declaración del trabajo arquitectónico. (ver cap. 5.2.7.1)



- Entregable Plan de implementación y migración. (ver cap. 5.6.5.2)

- DEA y Director de CSIs.


ORIENTADO A LA UTPL

EA – UTPL - 351 - | P á g i n a

- Entregable declaración del trabajo arquitectónico.

- (ver cap. 5.2.7.1)

Formular una estrategia de implementación y migración (alto nivel).


CSIs, ADSs, ADDs, DGTIs y DTEs.

Día 606 Día 615

- Entregable de plan de implementación y migración. (ver cap. 5.6.5.2)

- Entregable de plan de implementación y migración refinado. (ver cap. 5.6.5.2)

- DEA

Identificar y agrupar paquetes de trabajo.

- Director de ADSs y ADDs.

- DEA.

Día 616 Día 620


- Entregable de de declaración e trabajo arquitectónico. (ver cap. 5.2.7.1)

- Entregable de plan de implementación y migración refinado. (ver cap. 5.6.5.2)

- DEA - Director de ADSs

Identificar la arquitectura de transición.

- Directores de ADSs, CSIs, DTEs y ADDs.

Día 621 Día 630




- DEA

Crear cartas y portafolio de proyectos. (Actualizar la EA)


CSIs, ADSs y DTEs.

- Entregable de visión

arquitectónica. (ver cap. 5.2.7.4)

- Entregable adaptación de la EA. (ver cap. 5.10.1.5)

- Entregable plan de implementación y migración.

- DEA

Confirmar las iteraciones del framework


Día 631 Día 640 - Entregable plan de

implementación y migración. (ver cap.

- Entregable plan

de implementación y

- DEA - Director de ADSs


ORIENTADO A LA UTPL

EA – UTPL - 352 - | P á g i n a

FASE F: PLANEAR LA MIGRACION (Revisar el capítulo 5.7 para información general. Para levantar los entregables, las plantillas centrales se encuentran descritas en la sección 5.7.5 mayoritariamente. Mientras que los artefactos están descritos en el Anexo 1.1.7)

5.6.5.2) - Entregable de

arquitectura de transición. (ver cap. 5.6.5.1)

migración validado. (ver cap. 5.6.5.2)


- Entregable de ABBs. (ver cap. 5.7.5.1)

Especificar el valor de negocio de cada sub proyecto.

- DEA. - Director es

de ADSs, ADDs y CSIs.

Día 641 Día 650


- Entregable de declaración de trabajo arquitectónico refinado. (ver cap. 5.2.7.1)

- Entregables de contratos de la arquitectura (ver cap. 5.7.5.2) (ver cap. 5.7.5.3)

- DEA

Estimar los recursos, tiempos, disponibilidad y demás medios necesarios para la migración.


CSIs, ADSs y ADDs.

Día 651 Día 660

- Entregable plan de implementación y migración. (ver cap. 5.6.5.2)


- Plan de acción (ver cap. 6, este capítulo).

- Entregable plan de implementación y migración refinado. (ver cap. 5.6.5.2)

- Entregables de contratos de la arquitectura (ver cap. 5.7.5.2) (ver cap. 5.7.5.3)

- CIO y DEA

Formalizar la arquitectura de transición y actualizar los documentos de definiciones

- Directores de ADSs, CSIs, DTEs y ADDs.

Día 661 Día 670

- Entregable plan de implementación y migración refinado. (ver cap. 5.6.5.2)

- Entregable de

- Entregable de arquitectura de transición finalizado. (ver cap. 5.6.5.1)

- DEA - ADSs


ORIENTADO A LA UTPL

EA – UTPL - 353 - | P á g i n a

arquitectónicas. arquitectura de transición. (ver cap. 5.6.5.1)



Generar un Roadmap para la implementación y migración de la EA.


CSIs, ADSs y de ADDs.

Día 671 Día 680



- Artículo adjunto a este proyecto de tesis

- Entregable de Roadmap de la arquitectura (con implementación y migración). (ver cap. 5.3.8.2)

- Entregable plan de implementación y migración. (ver cap. 5.6.5.2)

- DEA

Establecer el ciclo evolutivo de la EA.

- Director de CSIs y DTEs.



- Entregable de solicitud de trabajo arquitectónico. (ver cap. 5.1.10.4)


- Director de CSIs y DTEs

Formalizar el ámbito y prioridades para el despliegue de la EA.

- Directores de DGTIs, CSIs, y ADSs.

Día 691 Día 700

- Visión arquitectónica. (ver cap. 5.2.7.4)


- Modelo de despliegue (dentro de plan de implementación) (ver cap. 5.6.5.2)

- DEA - Directores de DGTIs, CSIs

Identificar recursos y - Directores de Día 701 Día 710 - Visión arquitectónica. - Entregable DEA


ORIENTADO A LA UTPL

EA – UTPL - 354 - | P á g i n a

FASE G: IMPLEMENTAR LA GOBERNANZA (Revisar el capítulo 5.8 para información general. Para levantar los entregables, las plantillas centrales se encuentran descritas en la sección 5.8.6 mayoritariamente. Mientras que los artefactos están descritos en el Anexo 1.1.8)

habilidades de despliegue.

DGTIs, CSIs, ADDs y ADSs.

(ver cap. 5.2.7.4) Roadmap de implementación. (ver cap. 5.3.8.2)

- Entregable de ABBs (Ver cap. 5.7.5.1) y SBBs. (ver cap. 5.8.6.1)


- Directores de DGTIs, CSIs

Guiar el despliegue de soluciones (la EA).


DGTIs y ADSs

Día 711 Día 725

- Modelo de despliegue (Plan de implementación y migración). (ver cap. 5.6.5.2)

- Entregable Roadmap de implementación. (ver cap. 5.3.8.2)

- DEA

Revisar el cumplimiento de la EA.

- CIO. - DEA. - Directores de

ADSs y DTEs.

Día 726 Día 730 - Entregable Roadmap

de implementación. (ver cap. 5.3.8.2)

- Entregable de evaluación del cumplimiento. (ver cap. 5.8.6.2)

- DEA - CIO

Implementar operaciones de TI y de negocio (Modelo de gobernanza)

- Director de DGTI.


CSIs y DTEs.

Día 731 Día 745

- Entregable de modelo organizacional. (ver cap. 5.1.10.1 y 5.1.10.2)

- Entregables de modelo organizacional (ver cap. 5.1.10.1), plan de implementación y migración (ver cap. 5.6.5.2) y declaración de trabajo arquitectónico (ver cap. 5.2.7.1).

- Entregable de plan de

- Director de DGTIs - DEA


ORIENTADO A LA UTPL

EA – UTPL - 355 - | P á g i n a

comunicaciones. (ver cap. 5.2.7.3)

Realizar un seguimiento post-implementación se cerrar la implementación.

- Director de DGTIs.

- Director de ADSs.

- DEA.

Día 746 Día 750


- Entregable de evaluación de cumplimiento. (ver cap. 5.8.6.2)

- Entregable Roadmap de implementación (ver cap. 5.3.8.2) y plan de implementación y migración. (ver cap. 5.6.5.2)

- Director de DGTIs - DEA

FASE H: GESTIONAR EL CAMBIO DE LA ARQUITECTURA (Revisar el capítulo 5.9 para información general. Para levantar los entregables, las plantillas centrales se encuentran descritas en la sección 5.9.7 mayoritariamente. Mientras que los artefactos están descritos en el Anexo 1.1.9)

Establecer el proceso de consecución de valor de negocio.


DGTIs y ADDS.

Día 751 Día 755


- Entregable de declaración de trabajo arquitectónico. . (ver cap. 5.2.7.1)

- Ponderación de arquitectura de transición (en su respectivo entregable). (ver cap. 5.6.5.1)

- DEA

Desplegar herramientas de monitoreo.

- Directores de DGTIs y ADSs.

Día 756 Día 770



- Entregable de plan de comunicaciones. (ver cap. 5.2.7.3)

- Directores de DGTIs y ADSs.

- DEA - CIO

Gestionar los riesgos. - Director de CSIs y Día 771 Día 775 - Entregable de

evaluación de la - Evaluación de impacto de

- Director de CSIs y


ORIENTADO A LA UTPL

EA – UTPL - 356 - | P á g i n a

Nota: No se especifican costos y la estimación planteada para el proyecto es de 27 meses.

DGTIs. - DEA.

capacidad. (ver cap. 5.2.7.2)

requisitos. (ver cap. 5.9.7.1)

DGTIs. - DEA.

Analizar la gestión del cambio de la EA:


ADSs, DTEs, DGTIs y ADDs.

Día 776 Día 785

- Evaluación de impacto de requisitos. (ver cap. 5.9.7.1)

- Entregable de solicitud de cambio arquitectónico. (ver cap. 5.9.7.2)

- DEA

Definir requisitos de cambio (periódicamente)

- Directores de CSIs, ADSs, ADDs y DTEs

Día 786 Día 790

- Entregable de requisitos. (ver cap. 5.3.8.1)

- Entregable de evaluación de impacto de requisitos. (ver cap. 5.9.7.1)


- Entregable de evaluación de impacto de requisitos. (ver cap. 5.9.7.1)

- DEA

Administrar la gobernanza de la EA.

- Director de DGTIs. Día 791 Día 810


- Entregable de evaluación del cumplimiento gobernanza. (ver cap. 5.8.6.2)

- Entregable evaluación de impacto en requisitos (ver cap. 5.9.7.1)

- Director de DGTIs.

Activar el proceso de la EA que estará listo a implementar el cambio (de ser necesario).


ADSs.




ORIENTADO A LA UTPL

EA – UTPL - 357 - | P á g i n a

7.0 CONCLUSIONES Y RECOMENDACIONES

7.1 Conclusiones

• El proyecto EA-UTPL es un factor si la institución quiere establecer una perspectiva clara de la relación entre el portafolio de TI y los procesos de negocio, si se quiere estructurar el contenido institucional por procesos centralizados de gobernanza, y si se busca gestionar el cambio de los procesos de negocio existentes en la institución.

• Se debe tener claro que la EA es un proceso largo. El período de un año para el proyecto de EA-UTPL, no se considera un perdido natural para una evaluación total dentro de un proyecto de Arquitectura Empresarial, sino para una formalización de la adopción de un framework y la implementación de un plan piloto (si el equipo arquitectónico estuviese consolidado).

• El ADM debido a su flexibilidad puede ser combinado con componentes, modelos y otras metodologías. Para el caso particular, se restaron las limitaciones de los 5 grandes frameworks en cuanto a que no cubrían aspectos de diseño y desarrollo de software. El framework EA-UTPL a diferencia de los 5 grandes abarca aspectos de ingeniería de software.

• La especificación de la EA es tan grande como el grupo de trabajo o los stakeholders lo requieran, el nivel de especificación puede llegar a grados de granulidad muy finos. El levantamiento y especificación de todos los componentes y artefactos involucrados es esencial para determinar el grado de especificación.

7.2 Recomendaciones

• Para garantizar la operatividad correcta de la totalidad del framework es recomendable realización una ejecución piloto en un segmento de la institución. Dicha ejecución garantizará el adecuado refinamiento del framework para poder ser implementado en la totalidad de de la UTPL.

• Para poder ejecutar de nuevo el ADM no solo se debe considerar la gestión del cambio (los requisitos para la gestión de la misma), también hay que analizar la planeación estratégica de la EA (ver parte final del paper adjunto), ya que la solicitud de cambio podrá ser validada si se acopla a los periodos de validez de la EA establecidos en la planeación mencionada. Es recomendable optar por aplicar la gestión entre periodos de 2 a 5 años, dependiendo de los factores determinantes del negocio.

• El uso de herramientas arquitectónicas es abierto y se pueden levantar los modelos haciendo uso de varios lenguajes, pero se recomienda incluir Archimate en la sección de modelado, pues es un lenguaje en auge que ya ha logrado un alto nivel de robustez y es la tendencia de lenguaje “oficial” de modelado arquitectónico.

• Un posible enfoque deberá incluirse en los modelos de especificación de Arquitectura Empresarial, dicho enfoque ha sido dado para algunas secciones pero deberá ampliarse para cada uno de los componentes del ADM.


ORIENTADO A LA UTPL

EA – UTPL - 358 - | P á g i n a

ANEXOS [f1]


ORIENTADO A LA UTPL

EA – UTPL - 359 - | P á g i n a

ANEXO 1: RECURSOS PARA EA-UTPL

1.1 ARTEFACTOS PARA EA-UTPL 1.1.1 Especificación de artefactos para la fase preliminar

_____________________________________________________________________________________________

Catálogo de Artefactos para la Fase Preliminar


_____________________________________________________________________________________________

<<Nota: Este documento provee un catálogo a manera de plantilla en el que se listan los artefactos correspondientes a la actual fase del ADM. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos

1 Catálogo Información del documento Nombre del Proyecto:


Preparado por:


Título: Catálogo de artefactos para la Fase Preliminar

Fecha de Versión:

Revisado por: Fecha de Revisión: Lista de distribución



Teléfono/Fax/Email


ORIENTADO A LA UTPL

EA – UTPL - 360 - | P á g i n a

1 Catálogo

1.1 Catálogo de principios arquitectónicos

Principios Arquitectónicos

ID Nombre Descripción Fecha Categoría Prioridad Recurso Motivación/ Conductor

Implicación del Diseño

de la Arquitectura

Creado / Modificad

o

Propietari

o

PRN_ARQ_01

PRN_ARQ_02

PRN_ARQ_03

PRN_ARQ_04

PRN_ARQ_05

PRN_ARQ_06

PRN_ARQ_07

PRN_ARQ_08

PRN_ARQ_09

PRN_ARQ_nN

INTEGRACIÓN DE BUENAS PRACTICAS PARA LA DEFINICIÓN DE UN FRAMEWORK DE ARQUITECTURA

EMPRESARIAL ORIENTADO A LA UTPL

EA – UTPL - 361 - | P á g i n a

1.1.2 Especificación de artefactos para la Fase A: Visión arquitectónica

_____________________________________________________________________________________________

Catálogo de Artefactos para la Fase A


_____________________________________________________________________________________________

<<Nota: Este documento provee un catálogo a manera de plantilla en el que se listan los artefactos correspondientes a la actual fase del ADM. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos

1 Catálogos 2 Matrices

Información del documento Nombre del Proyecto:


Preparado por:


Título: Catalogo de artefactos para la Visión Arquitectónica

Fecha de Versión:




Teléfono/Fax/Email



EA – UTPL 362 | P á g i n a

1. Catálogos

1.1 Catálogo de requisitos

2. Matrices

1.1 Matriz de especificación de stakeholders

Catálogo de Requisitos

ID Restricción Comentarios Recurso Propietario Estado Probabilida

d Impacto CR_REQ_01 CR_REQ_02 CR_REQ_03 CR_REQ_nN

Mapa de Stakeholders

Stakeholder Participació

n Clase Poder Nivel de interés Expectativas

Plan de comunicació

n Puntos de Vista

STK_01 STK _02 STK _nN




1.1.3 Especificación de artefactos para la fase B: Visión arquitectura de negocio

____________________________________________________________________________________

Catálogo de Artefactos para la Fase B


____________________________________________________________________________________

<<Nota: Este documento provee un catálogo a manera de plantilla en el que se listan los artefactos correspondientes a la actual fase del ADM. Puede requerir adaptaciones para aplicarlo a clientes específicos y situaciones puntuales en el proyecto EA-UTPL>> Tabla de contenidos 1 Catálogos 2 Matrices Información del documento



Preparado por:


Título: Catálogo de artefactos para la Arquitectura de Negocio

Fecha de Versión:





1 Catálogos

Catálogo de localización

Localización (Consolidación de Extensión de Infraestructura)

ID Nombre Descripción Categoría Recurso Propietario

AN_LOC_01

AN_LOC_02 AN_LOC_03




AN_LOC_nN

Catálogo de roles

Rol (Núcleo)


FTEs (equivalencia

En tiempo Completo)

AN_ROL_01 AN_ROL_02 AN_ROL_03 AN_ROL_nN

Conductor - catálogo de objetivos

Objetivo (Extensión de motivación)

ID Nombre Descripción Categoría Recurso Propietario AN_OBJ_01 AN_OBJ_02 AN_OBJ_03 AN_OBJ_nN

Contrato – catálogo de actores

Actor (núcleo)

ID Nombre Descripción Categoría Recurso Propietario #FTEs su

Objetivo Tareas

AN_CDS_01 AN_CDS_02 AN_CDS_03 AN_CDS_nN

Organización – catálogo de medidas

Calidad de Servicios (Extensión de gobernanza)


AN_ACT_01 AN_ACT_02 AN_ACT_03 AN_ACT_nN

Procesos/evento/control – catálogo de productos

Producto (Extensión del proceso)




ID Nombre Descripción Categoría Recurso Propietario AN_PRD_01 AN_PRD_02 AN_PRD_03 AN_PRD_nN

Servicio – catálogo de funciones

Función (núcleo)


Clases STD Fechas de (creación,

revisiones, cierre) AN_FNC_01 AN_FNC_02 AN_FNC_03 AN_FNC_nN

2 Matrices

Matriz de interacciones del negocio

Consumo de

Servicios Empresariales Ingeniería Adquisiciones Manufactura

Ventas y Distribución

Atención al Cliente

Ingeniería

Adquisiciones

Manufactura Contrato para suministro de Materiales

Contrato para suministro de pronósticos de ventas

Ventas y Distribución

Contrato para suministro de especificación de producto

Contrato para suministro de productos

Atención al Cliente

Contrato para el cumplimiento de órdenes de clientes

Matriz de roles de actores

Actores de la Unidad del Negocio Actores

de Actores de Implementación




Terceros

Actividad Equipo de proyecto

Equipo de arquitectura

Procurador comercial

proveedor de

soluciones

Autoridad de diseño

técnico Introducción de servicio

Gestión de servic

io Requerimiento Funcional Público AR C Requerimiento No Funcional Público AR C C C I Arquitectura Lógica Pública A C R I Directrices y Arquitectura de Referencia Provista AR Issue RFP o especificación (según proceda) R C A I C Lista de Verificación Completa QG2 C C I C AR I




1.1.4. Especificación de artefactos para la Arquitectura de Sistemas de Información 1.1.4.1 Especificación de artefactos para la fase C1: Arquitectura de Datos

____________________________________________________________________________________

Catálogo de Artefactos para la Fase C1


____________________________________________________________________________________




Preparado por:


Título: Catalogo de artefactos para la Arquitectura de Negocio

Fecha de Versión:





1 Catálogos

Catálogo de componente de datos

Sistema de información (datos)

ID Nombre Descripción Categoría Recurso De datos Propietario

Privacidad

Retención

AN_FNC_01 AN_FNC_02




AN_FNC_03 AN_FNC_nN

2 Matrices

Matriz de función de negocio

Mapa de Componentes de Datos Físicos para las Funciones del Negocio

Función del Negocio 1 Función del Negocio 2

Dato Entidad Físico 1



Dato Entidad Físico n

Matriz de datos

Mapa de Componentes de Aplicación Física para Entidades de Datos

Componente de Apl. Física 1



Componente de Apl. Física n




Dato Entidad Físico n




1.1.4.2 Especificación de artefactos para la fase C2: Arquitectura de aplicaciones

____________________________________________________________________________________

Catálogo de Artefactos para la Fase C2


____________________________________________________________________________________




Preparado por:


Título: Catálogo de artefactos para la Arquitectura de Negocio

Fecha de Versión:





1 Catálogos

Catálogo de interfaces

Mapa de Componentes de Aplicaciones Físicas

Comp de Apl. Física 1 Comp de Apl. Física 2

Comp de Apl. Física 3





Comp de Apl. Física 1 se comunica con



Comp de Apl. Física n

2 Matrices Matriz de interacción de aplicaciones

Mapa de interacción de Componentes de Aplicación Lógica

Comp de Apl. Lógica 1




Comp de Apl. Lógica 1 se comunica con



Comp de Apl. Lógica n

Matriz del sistema

Mapa de Roles de Componentes de Aplicación Física

ID Rol 1 Rol 2 Rol 3 Rol 4 Rol n Comp de Apl. Física

1




Matriz de función

Mapa de Funciones de Negocio de Componentes de Aplicación Lógica

ID

Función de negocio 1




Función de negocio n


Comp de Apl. Lógica




2 Comp de Apl. Lógica

3

Comp de Apl. Lógica n

Matriz de la institución

Mapa de Unidades de Organización de Componentes de Aplicación Física

ID

Unidad de organización

1


2


3


4


n Comp de Apl. Física

1







1.1.5 Especificación de artefactos para la fase D: Arquitectura de tecnología

____________________________________________________________________________________

Catálogo de Artefactos para la Fase D


____________________________________________________________________________________




Preparado por:


Título: Catalogo de artefactos para la Arquitectura de Negocio

Fecha de Versión:





1 Catálogos

Catálogo de portafolio tecnológico

Plataforma de servicios


Fechas de creación y

modificación

Clases

estándar

AT_PS_01 AT_PS_02 AT_PS_03




AT_PS_nN Catálogo de tecnologías estándar

Tecnologías estándar


Fechas de creación y

modificación

Clases

estándar

AT_PS_01 AT_PS_02 AT_PS_03 AT_PS_nN

2 Matrices Matriz de tecnológica

Componentes de aplicaciones lógicas / mapa de componentes de aplicaciones lógicas





Comp Tecno. Lógica 1 se comunica con



Comp Tecno. Lógica n




1.2 PLANTILLA PARA LEVANTAMIENTO DE ARQUITECTURA DE TI DE LA UTPL

UTPL - ITA

(USADA PARA ESTABLECER LA LINEA BASE) Tabla de contenido

1. Resumen Ejecutivo

1.1. Audiencia 1.2. Introducción 1.3. Historial 1.4. Ámbito 1.5. Estructura de la Arquitectura de la Tecnología de Información de la UTPL 1.5.1. Marco de Trabajo 1.6. Gobernanza 1.6.1. Gestión de Información 1.6.2. Gestión de servicios 1.7. Revisión

2. Principios 2.1. Guía de objetivos estratégicos de la Universidad en decisiones IT 2.2. Sistemas Seguros 2.3. Objetivos de diseño de alta disponibilidad y fiabilidad 2.4. Políticas para Salvaguardar Sistemas y Propiedad Intelectual 2.5. Uso de fuentes autorizadas de datos en los Sistemas 2.6. Plataforma de entorno de usuario independiente accesible a nivel global 2.7. Software preferido en el desarrollo interno 2.8. Productos estándar y plataformas adoptadas para limitar la diversidad 2.9. Aplicaciones para compartir recursos 2.10. Estructura de los Sistemas para una fácil extensión 2.11. Fácil delegación de la Gestión de los Sistemas

3. Visión General de la Arquitectura 4. Arquitectura de Negocio 5. Arquitectura de Información

5.1. Modelos de datos, diccionario de datos y manejo de los mismos 6. Arquitectura de Aplicaciones

6.1. Arquitectura de Presentación 6.2. Arquitectura de Base de Datos 6.3. Desarrollo de Aplicaciones 6.4. Soporte de las Aplicaciones para Servicios y Estándares 6.5. Aplicaciones de Escritorio 6.6. Aplicaciones Cliente 6.7. Soporte de Servicios de Estación de Trabajo

7. Arquitectura de Infraestructura 7.1. Arquitectura de Plataforma de Cliente 7.2. Arquitectura plataforma del Servidor 7.3. Arquitectura de Servidor de almacenamiento de datos 7.4. Arquitectura de Red 7.5. Infraestructura del ambiente

8. Trabajo Futuro 9. Apéndice I: Clasificación 10. Apéndice II. Glosario




11. Apéndice III: Marcos de Trabajo y Metodologías

1. Resumen Ejecutivo

1.1. Audiencia

Este documento está enfocado hacía dos audiencias mayoritarias: “Alta dirección”, para que a través del mismo pueda entender el contexto en el manejo de decisiones de tecnología; así como al “Personal de Tecnología de Información y Comunicación”, para la adquisición, gestión, entrega y mantenimiento de los sistemas actuales de la U.T.P.L., optimizando así el balance entre costo-beneficio de la Universidad.

1.2. Introducción Las empresas y organizaciones en general pueden ser descritos en términos de su la arquitectura. Esta arquitectura es el resultado de determinada planeación. Virtualmente todas las empresas (la Universidad en este caso) cuentan con una división suficientemente grande de Tecnología de la Información que tiene acceso a planes de: modelos de datos, modelos de procesos de negocios, componentes de dichos modelos, diagramas de estructura, planos de la red, listas de inventarios, planes de infraestructura, listas de hardware, árboles de la función, etc. Incluso, sin TI las empresas tienen planes de: tablas organizacionales, descripciones del lugar de trabajo, procedimientos, estrategias, etc. Los planes son necesarios para la creación y funcionamiento de sistemas complejos. Es sólo con la ayuda de esos planes que podemos entender los grandes sistemas, así la TI que se utilizar para brindar soporte a una organización es usualmente un gran sistema compuesto de una compleja agregación de sistemas. La arquitectura empresarial se compone de un conjunto de planes, es por ello que se debe destacar la importancia de estos. La arquitectura empresarial es la organización de los procesos de negocio y la infraestructura de TI que refleja la integración y la normalización de los requisitos del modelo de funcionamiento de la empresa. Se basa como disciplina científica en el diseño de los elementos de la tecnología de una empresa, orientado a los principios, marcos de trabajo, metodologías, necesidades, herramientas, estándares y modelos de referencia.

La UTPL-ITA describirá como se articula la racionalización de los procesos, servicios y tecnologías con el objetivo de buscar las mejores prácticas en la organización.

El resultado de esta línea base (UTPL-ITA) será la materialización de un plan formal de Arquitectura de Tecnología de la Información (UTPL-ITA final) que a su vez servirá como soporte en el desarrollo de un Marco de Arquitectura Empresarial, actuará como una fuerza de colaboración entre los diferentes aspectos de la planificación empresarial: metas, visiones, estrategias y principios de la gobernanza; de las operaciones empresariales: los tratos comerciales, estructuras de organización, procesos y datos; de automatización: los sistemas de información, bases de datos; y la infraestructura tecnológica (computadoras, sistemas operativos y redes).

1.3. Historial




La U.T.P.L. busca la formalización de su Arquitectura Empresarial (UTPL-EA), para ello necesitas algunos artefactos en los que debe basarse. Este documento UTPL-ITA tiene por objetivo servir para la especificación de formatos y plantillas para el levantamiento de la “línea base de TI” cuya primera edición será lanzada como UTPL-ITA 2010. Esta versión inicial formaliza cuales son los cimientos y la visión específica de la TI, separando ambos componentes y promoviendo su normalización. 1.4. Ámbito

Este documento tendrá como objetivo identificar las herramientas, tecnologías y procesos, así como proporcionar orientaciones de alto nivel para aplicar nuevas tecnologías. La implementación de una arquitectura eficaz reducirá el tiempo y costo en la adquisición, implementación y mantenimiento.

Este documento se aplicará a todo el ciclo de vida de la tecnología, desde su concepción y diseño de proyectos, hasta la implementación de servicios, gestión y mantenimiento. Además, incluirá la gestión de los ciclos de actualización de hardware, software y firmware, hasta la de una eventual puesta en marcha de un servicio. 1.5. Estructura de la Arquitectura de la Tecnología de Información de la UTPL

La UTPL-ITA se compondrá de tres secciones: los principios (los principios son normas y directrices, destinadas a ser duraderas y que rara vez son modificados, además, de apoyar al cumplimiento de la misión organizacional), la arquitectura (que describe las prioridades y recomendaciones específicas) y mayor detalle (siempre en los Apéndices o sitios web de consulta), que proporcionan información sobre la ejecución para las personas interesadas en partes específicas de la arquitectura.

1.5.1. Marco de Trabajo (Framework)

TOGAF (The Open Group Architecture Framework) es un estándar nacido en 1995, “enfocado hacia el diseño, definición, planificación, implantación y mantenimiento (gobernanza) de la Arquitectura Empresarial (EA)” [2], de esta forma tiene como punto principal la gestión de requerimientos. La arquitectura es modelada en cuatro niveles o dimensiones: Negocios, Tecnología (TI), Datos y Aplicaciones. Además cuenta con un conjunto de arquitecturas base que buscan facilitar al equipo de arquitectos definir el estado actual y futuro de la arquitectura.

• “La arquitectura de negocio define la estrategia de negocios, la gobernanza, la organización y procesos claves del negocio.

• La arquitectura de datos describe la estructura de los activos de datos lógicos y

físicos de la organización y datos de gestión de los recursos.

• La arquitectura de aplicaciones proporciona un modelo para los sistemas de aplicación individual a desplegar, sus interacciones y sus relaciones con los procesos de negocio centrales de la organización.




• La arquitectura de la tecnología describe el software de lógica y las capacidades de hardware que son necesarias para apoyar el despliegue de negocios, datos y servicios de aplicación. Esto incluye la infraestructura de TI, de middleware, redes, comunicaciones, procesamiento, estándares, etc.” [2]

El núcleo de TOGAF se sustenta en un Método de Desarrollo de Arquitectura (ADM), el cual provee un proceso probado y repetible para el desarrollo de arquitecturas. El ADM incluye el establecimiento de un Framework Arquitectónico, así como el desarrollo del contenido de la arquitectura, la transición de la misma, y la gobernanza para la realización de dichas arquitecturas. Todas estas actividades se llevan a cabo dentro de un ciclo iterativo de definición de la arquitectura y la realización continua de estas actividades permite a las organizaciones transformar sus empresas de una manera controlada, en respuesta a los objetivos de negocio y oportunidades. “La figura I [2] ilustra las Fases del ADM:

• Framework y principios para la preparación e

iniciación de las actividades • Visión de la arquitectura • Arquitectura de negocio • Arquitectura de Sistemas de Información • Arquitectura Tecnológica • Oportunidades y soluciones • Plan de migración • Implementación de la Gobernanza • Administración del cambio de la

Arquitectura” [2]

1.6. Gobernanza

Siempre la alta dirección se interesa en conseguir objetivos de negocio, por ello es fundamental que la arquitectura sea clara ante ellos. La arquitectura empresarial deberá articular los factores estratégicos para el cambio, también definir la visión del escenario futuro para dar soporte a esos factores estratégicos, ofreciendo además el “Roadmap” para conseguir ese escenario futuro. Pero la arquitectura empresarial no puede dejar de ir de la mano con la Gobernabilidad, porque “la EA identifica los cambios de negocio que son prioritarios, y mientras eso sucede: la gobernabilidad asegura que tales cambios ocurran.” [3]

La gobernanza de arquitectura se sustentará en la gobernanza de las TIC y operará para ambas gobernanzas en múltiples niveles. Las áreas que deseen establecer o mejorar su nivel de gobierno podrán referirse a los Objetivos de Control de la Información y tecnologías relacionadas como COBIT, que es un marco para la gestión de información (TIC) con un enfoque similar a PMBOK para la gestión de proyectos e ITIL para la gestión de servicios.

1.6.1. Gestión de Información




COBIT ofrece buenas prácticas para la gestión de los procesos de TI en una estructura manejable y lógica, esto favorece al esfuerzo de las múltiples necesidades de la gestión de información -en la empresa- por reducir las diferencias entre los riesgos empresariales, las cuestiones técnicas, las necesidades de requisitos de control y medición del desempeño. [3] 1.6.2. Gestión de servicios

Los procesos de Gestión de Servicios son el corazón de ITIL, y se subdividen en dos áreas bien diferenciadas:

• Soporte a los Servicios generalmente se concentra en las operaciones cotidianas, así como en dar soporte a los servicios de TI.

• En cambio, la Prestación de Servicios se ocupa de la planificación a largo plazo y del perfeccionamiento de la provisión de estos servicios.

Ambas áreas persiguen fines específicos:

• Alinear los servicios de TI con las necesidades actuales y futuras de su negocio y sus clientes.

• Maximizar la calidad de los servicios prestados • Reducir el coste de la provisión de servicios a largo plazo. [3]

1.7. Revisión La Arquitectura de Tecnología de Información de la U.T.P.L. será revisada cada dos años en consolidación con los CITTES, otras divisiones y áreas. 2. Principios La Arquitectura de Tecnología de Información de la U.T.P.L. se establecerá sobre un conjunto de principios (a desarrollar) que estarán orientados a guiar a la Universidad a través de la toma de decisiones de TI, así como la planeación e implementación de los sistemas de información. Los principios deberán estar descritos en el documento de especificación de principios, estando basados también en el Plan estratégico de las TIC (por establecer). Dichos principios describirán las características de objetivos de negocio de universidad con respecto a la arquitectura de TI, los que serán ordenados jerárquicamente en términos e importancia. Los principios (y la arquitectura) serán fundamentales para desarrollar la mejor solución arquitectónica, en relación coste/beneficio para poder adoptar una solución particular en contraste a la o las otras. 2.1. Guía de objetivos estratégicos de la Universidad en decisiones IT La información es almacenada y gestionada en apoyo de los objetivos de negocio de la universidad. La tecnología de la Información se empleará para ayudar a las entidades de la Universidad para alcanzar sus objetivos en la forma más eficiente y eficaz. Las decisiones de tecnología deberán tener en cuenta factores de negocio. 2.2. Seguridad de Sistemas




La U.T.P.L. necesita para proteger su información. Esto requiere una cuidadosa atención en la planificación, ejecución y gestión de una serie de medidas físicas y lógicas a través de sistemas, gestión de estos y de datos.

• Las políticas de seguridad de TI así como los documentos del Framework de seguridad de TI de la Universidad contendrán todas las especificaciones de las actividades concernientes a la seguridad de TI.

• La seguridad de información, y la amplitud de acceso a la información, deberán formar parte de la planificación, desarrollo y operación de todos los sistemas.

• Disposiciones de la integridad de datos adecuados, deberán incluirse en la planificación de cada sistema.

• Los sistemas que acceden a la información en otros sistemas deberán seguir las reglas de negocio asociadas con esa información en el sistema original;

• La seguridad será responsabilidad de todos los usuarios autorizados.

2.3. Objetivos de diseño de alta disponibilidad y fiabilidad

Las actividades centrales de la Universidad dependen de sistemas de información. La planificación y diseño de sistemas deberá proporcionar sistemas cuya fiabilidad sea equiparable con la importancia del servicio, y las necesidades de los usuarios. La continuidad probada del negocio y los mecanismos de recuperación de desastres adecuados -para las necesidades del negocio- deberían estar en funcionamiento en todo momento. 2.4. Políticas para Salvaguardar Sistemas y Propiedad Intelectual En el desarrollo y aplicación de sistemas, el personal deberá estar seguro de seguir las políticas y leyes pertinentes (véase apartado Creative Commons U.T.P.L) para garantizar que la información proporcionada a un propósito específico no se utilice para otros fines sin el consentimiento explícito de la persona a quien esos datos se refiere. La Universidad es productor y consumidor a la vez de propiedad intelectual. Como productor, los sistemas de información de esta necesitan respetar los lineamientos institucionales con respecto a la propiedad intelectual ya sea para la creación, almacenamiento, acceso, uso y eliminación. Esto incluye la provisión de derechos de autor apropiados y declaraciones de renuncia de propiedad intelectual creada/adquirida en la U.T.P.L. Como consumidor la U.T.P.L. compra o licencia el uso de propiedad intelectual cuando ello se ajusta a los objetivos y metas de la Universidad. Así ella debe almacenar, usa o proveer acceso a esta información de acuerdo a arreglos del acceso apropiado y licenciamiento. El manejo de derechos debe usar mecanismos de acceso estándares y deben ser descentralizados en donde sea posible. Para obtener directrices sobre la protección de la privacidad y la gestión de la propiedad intelectual, se deberá remitirse a la documentación de la estrategia de gestión de la información de la U.T.P.L. 2.5. Uso de fuentes autorizadas de datos en los Sistemas




Uno de los principios que rigen los sistemas de información de gestión es mantener una fuente primaria para cada pieza de datos. Hay un riesgo de que los datos obtenidos de una fuente no autorizada puedan estar fuera de fecha o ser incorrectos. Los datos nunca deberían introducirse más de una vez, otros sistemas que los necesitan deben recibir dichos datos por vía electrónica, desde una fuente para rastrear de regreso a la copia maestra y no por volver a teclear los datos. Cuando el acceso debe ser posible a través de una operación en vivo en el repositorio maestro. 2.6. Plataforma de entorno de usuario independiente accesible a nivel global

La Universidad cuenta con un enfoque cada vez más global, basándose en la gente de una diversa gama de costumbres y conocimientos. La mayoría de las personas, deben ser capaces de acceder a un conjunto común de servicios que proporcionan una interfaz intuitiva para sus necesidades, y estos servicios deben ser accesibles desde una variedad de plataformas, ya sea desde PCs con sistemas operativos distintos, a través de los teléfonos móviles y PDAs, etc. Para lograr los beneficios de un entorno tan homogéneo, los componentes arquitectónicos deberán ser buscados para proveer un núcleo, comúnmente usando la funcionalidad a través de interfaces publicadas (Servicios WEB o APIs), así como una interface independiente de plataforma (portal con soporte multiplataforma). Toda esta planeación debe incluir hacer accesibles a los servicios para grupos especiales, incluyendo a grupos de personas que cuenten con algún tipo de discapacidad. 2.7. Software preferido para el desarrollo interno

Las políticas actuales señalan que se busque desarrollar los productos en la medida de lo posible, siendo preferente esta política en lugar de la compra de un producto. En caso de de requerir estrictamente comprar uno o varios productos, estos deberán ser elegidos para complementar los productos y servicios existentes, y deberán ofrecer una ventaja clara de precio, rápido tiempo de implementación y costes de mantenimiento reducidos. Los proveedores deberán estar comprometidos con principios similares a los que estarán establecidos en el UTPL-ITA, y estar en condiciones de apoyar, mantener y mejorar el producto. 2.8. Productos estándar y plataformas adoptadas para limitar la diversidad

Con el fin de reducir el coste de propiedad, los proyectos deberán seleccionar, siempre que sea posible, desde el conjunto de los productos preferidos publicado en el UTPL-ITA, o en entornos estándar de operación de la Universidad (SOEs).

La estandarización de los entornos de TI reducirá los costos a través de: • Capacitación más centrada para personal de apoyo y los usuarios.

• Mayor flexibilidad y el inter-funcionamiento de los medios debido a la eliminación de las incompatibilidades y de las interacciones nocivas.

• Aumento del poder adquisitivo.




2.9. Aplicaciones para compartir recursos Existe un potencial para ahorrar costes compartiendo recursos comunes (plataforma de hardware, almacenamiento, modelo de datos, marco de aplicación, etc.) a través de las aplicaciones. La distribución de recursos deberá ser balanceada contra otros costos y beneficios de negocio, incluyendo la continuidad operacional, la seguridad y manejo de servicio/cambio/lanzamiento. Siempre que sea posible, sin embargo, las aplicaciones deberán compartir recursos para ahorrar costos. 2.10. Estructura de los Sistemas para una fácil extensión Cuando sea necesario desarrollar aplicaciones internas, el objetivo deberá ser la construcción de módulos genéricos que puedan ser reutilizados o modificados fácilmente para proveer ampliaciones y adiciones a las especificaciones originales. La construcción de bloques reusables incluirá elementos de todos los niveles de la arquitectura, desde información a través de de modelos de datos y lógica de negocio hasta los procedimientos y plantillas. 2.11. Delegación de la Gestión de los Sistemas El tamaño y la estructura de la U.T.P.L, pide sistemas cuya gestión pueda ser descentralizada para las escuelas y CITTEs, y cuyas interfaces de gestión deben ser fáciles, rápidas e intuitivas de usar. 3. Visión General de la Arquitectura La arquitectura se extenderá desde información general y arquitecturas de negocio, a través de aplicaciones e infraestructura aplicaciones (servidores de aplicaciones y Frameworks) hasta una infraestructura técnica (redes, almacenamiento y plataformas). En el siguiente diagrama, partes de la arquitectura "preferidas" (recomendado para uso general) están marcadas en verde, lo 'soportado' (para las zonas específicas de uso) se describe en componentes de color amarillo y lo 'obsoleto' se describe con rayas rojas. La arquitectura es un esbozo general y será analizada/desarrollada en la versión final de UTPL-ITA.

Negocio …

x n

… x n

Leyenda _____ Preferido _____ Soportado ……… Depreciado Información

… x n

… x n

Aplicaciones

… x n

… x n

… x n

Framework de Apps .NET PHP Java IIS …




Servidores de Apps IIS Apache Oracle

Base de Datos Oracle MySQL

MS Access

Plataforma OS

Windows

SuSE Linux

Plataforma HW X86 x64

Almacenamiento Raid Desktop CD/DVD

Red LAN Wireless

Servidor Privado

4. Arquitectura de Negocio Existirán planes operacionales para las escuelas, divisiones de soporte y un número de planes existentes de los cuales el plan estratégico de las TIC será uno. El plan estratégico de las TIC articulará las direcciones y estrategias que soporten los requerimientos de la Universidad para los sistemas de información y la infraestructura que trascenderán los límites de escuelas y CITTEs. La primera edición será publicada junto con la versión 1.0 de UTPL-ITA y será revisada anualmente. 5. Arquitectura de Información

La Estrategia de Gestión de la Información describirá una arquitectura de alto nivel de información y gestión de la información en la Universidad U.T.P.L. La estrategia hará hincapié en la importancia de la información centrada en soluciones de tecnología, centrada en el usuario y sus necesidades de información. La Figura 2 representa este diagrama: La parte superior es el usuario y sus necesidades de información. Éstos son soportados por los servicios, enviados por las aplicaciones, se ejecutan en la infraestructura. La Estrategia de Gestión de la Información se ocupa principalmente de los tres niveles superiores de esta figura. El Plan Estratégico de TIC se ocupará de la parte inferior con los dos niveles. La arquitectura se centrará principalmente en la parte inferior de los dos niveles, pero abiertamente direcciona todos los niveles y sus interrelaciones. La arquitectura de la información direccionará de manera general hechos de alto nivel relativos a la generación, manejo, almacenamiento y difusión de la información corporativa de la Universidad, junto con la tecnología usada para esos procesos. En un sentido amplio esta información corporativa podrá referenciar elementos no de propiedad de la Universidad, pero abiertamente accesados por miembros de la Universidad mientras cumplan con negocios de la misma. Las categorías de información corporativa para ser incluidas a futuro dentro de la arquitectura son:




• Información altamente estructurada, como registros de los estudiantes y las transacciones financieras.

• Información no estructurada como el correo electrónico, apuntes y trabajos de investigación que pueden contener datos ricos elementos tales como animaciones, simulaciones de vídeo y clips de audio.

• Toda la información corporativa debe ser almacenada principalmente en los sistemas de gestión centralizada. La UTPL-ITA desaprobará el almacenamiento de datos importantes en estaciones de trabajo o computadores portátiles localizados en oficinas o casas de los miembros del personal.

5.1. Modelos de datos, diccionario de datos y manejo de los mismos En un nivel inferior, arquitectura de información también recogerá las normas y estructuras en torno a piezas claves de información empresarial. Campos tales como números de identificación, número de centro de organización, construcción y números de sala (y muchos otros), porque todos necesitamos reglas claras de propiedad, acceso y uso. Estas normas garantizarán que dicha información se utilizará para los fines previstos y gestionados en la alineación con mayores procedimientos, políticas y normas empresariales de alto nivel. 6. Arquitectura de Aplicaciones La integración entre los sistemas es de mayor costo en la implementación y mantenimiento de las aplicaciones. El modelo arquitectónico que persigue la Universidad está por definirse pero en cuanto a desarrollo se puede rescatar la supremacía de la orientación a objetos. Un objetivo importante de UTPL-ITA será fomentar el desarrollo discreto, componentes reutilizables, en lugar de silos de aplicaciones independientes (que no puede compartir o re-usar funcionalidad). Al centrarse principalmente en el aspecto del 'valor agregado' de los componentes de la nueva lógica de negocios, el personal de las TIC permitirá a las otras capas de la arquitectura incrementarse de recursos de productos básicos como:

• Los sistemas de empresa se convertirán en repositorios de componentes, de datos asociados y de la información.

• Los recursos de cálculo y almacenamiento podrán ser accesados cuando sea necesario para ejecutar y almacenar las transacciones.

• Los usuarios accederán a los flujos de trabajo consolidados en uno centralizado, interfaz personalizada con el diseño coherente y la navegación.

La estructura de la arquitectura de la aplicación de

destino que se persigue a futuro se describe a continuación.

Las características importantes son:

Comunidad Externa

Comunidad UTPL

Extranet PORTAL Aplicaciones Propietarias

Componentes y Flujos de Lógica de Negocio

Repositorios

Estructurados No Estructurados

Recursos de Cómputo y Almacenamiento

Rec

urso

s co

mpa

rtido

sR

ecur

sos

Des

arro

llado

sC

apa

de

Pre

sent

ació

n




• Un usuario-centrado en la capa de presentación dirigida a un público específico que permitirá el acceso a la información a través de una variedad de interfaces y tecnologías.

• La lógica de negocio se definirá en objetos discretos ("componentes") que podrán ser reutilizados en diferentes flujos de trabajo, servicios y aplicaciones como parte de una "arquitectura orientada a objetos (OOA).

• Repositorios estructurados y no estructurados de datos consolidados que fomentarán modelos de apoyo a un acceso dinámico, modificación y la reutilización de los datos en los componentes anteriores.

• Recursos de cómputo y almacenamiento provistos en una manera estandarizada que permitirán así un emparejamiento flexible de recursos a los picos en demanda, continuando creciendo y con estrategias de recuperación de desastres efectivas.

6.1. Arquitectura de Presentación

Actualmente la estrategia de web de la Universidad establece el portal “utpl.edu.ec” como el método estándar de presentación a los miembros de la comunidad de la U.T.P.L., así como de presentación al público en general.

6.1.1. Diseño Orientado a Usuario

En el diseño de la capa de presentación, una metodología de diseño centrada en el usuario deberá ser adoptada para mejorar la calidad y usabilidad de las aplicaciones y sitios web. Los usuarios deberán participar en todas las fases de desarrollo (incluidos los requisitos de análisis) a través de actividades como la investigación contextual, entrevistas, grupos focales, encuestas y pruebas de usabilidad. La investigación ha demostrado que un enfoque centrado en el usuario puede mejorar dramáticamente la rentabilidad de la inversión.

Plantillas y Campos de la Estructura de TI (a llenarse en base a Entrevistas)

Arquitectura de Base de Datos Elemento Base de Datos Descripción Sistema de Gestión de Base de Datos Clase Producto Notas Preferido Soportado Prohibido

Desarrollo de Aplicaciones

Consolidación del Lenguaje

Elemento Lenguaje de Desarrollo de Aplicaciones




Descripción Clase Producto Notas Preferido Soportado Aceptable

Manejo de Versión de Código Fuente

Elemento Manejo de Código Fuente Descripción Repositorio de manejo y rastreo de Código Fuente Clase Producto Notas Preferido Soportado Mantenimiento

Pruebas Automatizadas

Elemento Pruebas Automatizadas Descripción Pruebas al Software para asegurar el rendimiento y la flexibilidad

adecuadas Clase Producto Notas Preferido Aceptable

Soporte de las Aplicaciones para Servicios y Estándares

Manejo de Identidad de usuarios

Elemento Manejo de Identidad Descripción Métodos o Protocolos para autenticación y acceso de usuario a

los recursos Clase Producto Notas Preferido Soportado Candidato

HTTP (Servidor WEB)

Elemento Servidor Web Descripción Software que provee servicios HTTP acorde a estándares HTTP Clase Producto Notas Preferido Soportable

• Aplicaciones de Escritorio • Aplicaciones Cliente




Navegador Web

Elemento Navegador Web Descripción Software para interactuar con Servicios basados en Internet Clase Producto Notas Preferido

Soporte de Servicios de Estación de Trabajo

• Servicio de Impresión remota compartido • Servicio de Archivos remotos • Manejo remoto • Anti-virus, anti-spyware y servicios de filtro de Spam

Arquitectura de Infraestructura

Arquitectura de Plataforma de Cliente

• Equipos del personal • Ordenadores personales portátiles • Equipos de laboratorio de estudiantes • Equipos de escritorio o portátiles para estudiantes • Equipos de los estudiantes

Arquitectura plataforma del Servidor

Hardware

Elemento Servidor de Aplicaciones, Web , de Archivos, etc. Descripción Clase Producto Notas Preferido Aceptable Soportado solo por aplicaciones aprobadas

Elemento Servidor de Base de Datos Descripción Clase Producto Notas Preferido Aceptable Soportado solo por aplicaciones aprobadas

Sistema Operativo




Elemento Sistema Operativo Descripción El Usado para los Servidores Clase Producto Notas Preferido Aceptable Soportado Mantenimiento Prohibido

• Consolidación de Servidor • Alojamiento “de origen” • Contratación de Servidor • Configuración

Manejo y Monitoreo

Elemento Monitoreo Descripción Clase Producto Notas Preferido Aceptable

Arquitectura de Servidor de almacenamiento de datos

Almacenamiento Elemento Servidor Almacenamiento de Datos Descripción Almacenamiento Físico Clase Producto Notas Preferido Aceptable

Respaldo y Recuperación

Elemento Respaldo y Recuperación de Datos Descripción Respaldo, archivo y recuperación de Datos Clase Producto Notas Preferido

Arquitectura de Red

• Modelo de Red • Protocolos de Red • Dispositivos y administración de Dominios y Subdominios • Servidores, otros dispositivos no de usuario final y aplicaciones intensivas de Red • Manejo de Acceso a la Red • Cableado de Red • Red Inalámbrica • Multicast • Servicio de Telefonía




Infraestructura del ambiente

Apéndice I: Clasificación

Clase Descripción Preferido El producto o los productos, que actualmente se considera que

ofrecen la mejor combinación de valor, características, seguridad, etc. Para el uso abierto de la UTPL. Usualmente existe un único preferido, pero existen casos en los que hay dos productos preferidos, para lo cual se debe especificar el dominio de uso de cada uno de ellos.

Soportado La adopción de estas tecnologías es probable que sea más caro que las "soluciones preferidas" y estos costos deben tenerse en cuenta en los presupuestos y propuestas de financiación. La arquitectura es un equilibrio de beneficio del negocio y del costo, y hay una serie de circunstancias en que un producto “no conforme” puede proporcionar beneficios empresariales que garanticen la elevación de gastos.

Aceptable Es un producto considerado menos deseable en algún sentido como los de la clase "preferida". Pero pueden utilizarse en los casos en que los productos preferidos son gobernados sobre la base de las necesidades de negocio. En general, la adopción y apoyo a las soluciones "aceptables" será más débil que "las soluciones preferidas” y a los adoptantes se les anima a considerar soluciones preferidas.

Candidato Un producto que aún no ha sido clasificado de otra manera, pero considera que tiene méritos suficientes para ser considerado un producto preferido potencial. Productos candidatos son normalmente los nuevos productos o tecnologías, y puede ser utilizado en el juicio o proyectos piloto. Estos productos generalmente no serán cubiertos por la oferta existente o los contratos de apoyo o de las licencias existentes.

Mantenimiento Productos que están en uso en la UTPL, probablemente en aplicaciones "legales", pero se consideran menos adecuados que los mejores disponibles en la actualidad. Los nuevos proyectos deben utilizar siempre los productos de la clase “preferido”. Cuando los proyectos o servicios ya son sometidos a un "mantenimiento" del producto, su uso puede continuarse hasta que haya una importante actualización o rediseño. En este punto, un cambio a un producto preferido debe ser considerado.

Prohibido Los productos que tienen defectos graves o cuya filosofía, estructura, o las necesidades de recursos que los hacen inadecuados para la arquitectura de la UTPL. No debe ser utilizado en cualquier situación de la producción sostenida.

7. Apéndice III: Marcos de Trabajo y Metodologías (A definirse)




8. Bibliografía

[1] ISO/IEC 42010: 2007 [2] The Open Group Architectural Framework (TOGAF). “TOGAF Version 9” 2009 [3] Klaus D. Niemann. “From Enterprise Architecture to IT Governance: Elements of

Effective IT Management” 2005




INDICES Y

BIBLIOGRAFIA [f2]




ANEXO 2: ÍNDICES Y BIBLIOGRAFÍA 2.1 Glosario de Figuras Nombre de Figura Página

Figura 1: Línea de Vida de la Arquitectura Empresarial 17 Figura 2: Arquitectura Empresarial como Herramienta de Gestión 22 Figura 3: Dimensiones Base de una EA 23 Figura 4: Dominio de EA 24 Figura 5: Gestión de la EA 29 Figura 6: Ciclo de Vida Genérico de una EA 30 Figura 7: ArchiMate Architectural Framework basado en Henk Jonkers 31 Figura 8: Interacción de la herramienta 37 Figura 9: Proceso EA visto desde una herramienta 38 Figura 10: Grid de Zachman 42 Figura 11: Continuum de TOGAF 44 Figura 12: Método de Desarrollo Arquitectónico (ADM) de TOGAF 45 Figura 13: Aplicación de Arquitectura Segmentada 46 Figura 14: Modelo de Arquitectura Empresarial de Gartner 49 Figura 15: Marco arquitectónico de E2AF [29] 52 Figura 16: Esquema del ADM 83 Figura 17: Relación del ADM con los frameworks de una institución 87 Figura 18: Estructura del equipo de trabajo 91 Figura 19: Esquema de escenario de negocios 132 Figura 20: Esquema de repositorio arquitectónico 166 Figura 21: Modelo técnico referencial 224 Figura 21: Modelo técnico referencial detallado 225




2.2 Glosario de Tablas Nombre de Tabla Página

TABLA 1: Análisis Comparativo de frameworks 56 TABLA 2: Contrastación de Metodologías 59 TABLA 3: Contrastación de Modelos 60 TABLA 4: Contrastación de Interfaces para desarrollo de modelos 61 TABLA 5: Valoración de criterios de automatización 63 TABLA 6: Valoración de Personalización y Extensión 65 TABLA 7: Valoración de Manipulación y Análisis 66 TABLA 8: Valoración del Repositorio 68 TABLA 9: Valoración de Arquitectura de Implementación 69 TABLA 10: Valoración de Licenciamiento y Soporte Técnico 70 TABLA 11: Valoración de Resultados Arquitectónicos 72 TABLA 12: Valoración en base a utilidad 73 TABLA 13: Resultados Finales de herramientas 76 TABLA 14: Criterios de evaluación de madurez para una EA 88 TABLA 15: Criterios de evaluación de madurez para una EA extendida 89 TABLA 16: Esquema de FODA 334 TABLA 17: Plan de acción 336




2.3 Bibliografía [1] The Open Group. The Open Group Architecture Framework “TOGAF”. The Open Group, 2009.

Versión 9. ISBN: 978-90-8753-230-7

[2] Niemann D. Klaus. From Enterprise to IT Governance “Elements of Effective IT Management”. GWV Fachverlage GmbH, 2005. ISBN 3-528-05856-0.

[3] Zachman, A. John. "A Framework for Information Systems Architecture." IBM Systems Journal, Volumen 26, Número 3, 1987. Disponible en: http://www.zachmaninternational.com/images/stories/ibmsj2603e.pdf

[4] Clinger-Cohen, Acta de la Ley de 1996 (PL 107-347) Disponible en la librería del Congreso: http://thomas.loc.gov/default.aspx

[5] Corporación MITRE. EABOK. Guide to the (Evolving) Enterprise Architecture Body of Knowledge. Mclean, Virginia, 2004.

[6] Chief Information Officer Council. Federal Enterprise Architecture. Versión 1.0. 2001. Disponible en el sitio official: http://www.whitehouse.gov/omb/e-gov/fea/

[7] Joint Information Systems Commitee (JISC). Doing Enterprise Architecture: Enabling the agile institution. 2009. Disponible en: http://www.jisc.ac.uk/media/documents/techwatch/jisc_ea_pilot_study.pdf

[8] Ross W. Jeanne, Weill Peter, Robertson C. David. Enterprise Architecture As Strategy: Creating a Foundation for Business. Harvard Business Press. 2006. ISBN: 978-1591398394

[9] Selig, J. Gad, Waterhouse Pete. IT Governance – An Integrated Framework and Roadmap: How to Plan, Deploy and Sustain for Competitive Advantage. 2006. Disponible en: http://www.axisgroup.com/downloads/CA_Clarity_IT_governance_whitepaper.pdf

[10] Zachman, John A. "The Framework for Enterprise Architecture: Background, Description and Utility." Zachman Institute for Framework Advancement (ZIFA). Document ID: 810-231-0531

[11] Entrevista con John Zachman. Roger Sessions, Editor en jefe de, “Perspectives of the International Association of Software Architects”.

[12] Gartner, Gartner Enterprise Architecture Process: Evolution 2005, R. Scott Bittler, Gregg Kreizman, ID: G00130849

[13] Institute for Enterprise Architecture Developments – IFEAD. Enterprise Architecture Tools Selection Guide. J. Schekkerman. Versión 5.0. 2009. Disponible en: http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v50.pdf

[14] Veltman Elise, Reekum Van. Determinig the Quality of Enterprise Architecture Products. Tesis de Masterado. Universidad de Utrecht & Sogety Holanda B.V. 2006. Disponible en: http://www.dya.info/Images/Thesis%20E_van_Reekum_Determining_Quality_Enterprise_Architecture_Services%20v2_tcm13-24174.pdf

[15] Objectwatch Inc. A Comparison of the Top Four Enterprise-Architecture Methodologies. Sessions Roger. 2007. Disponible en: http://wwww.msdn.microsoft.com/en-us/library/bb4666232.aspx

[16] Pragmatic EA Ltd. PEAF: Framework Comparision. Versión 2.0. 2010. Disponible en www.pragmaticea.com/docs/peaf-overview1-framework-comparison.pdf

[17] Zachman A. John. The Zachman Framework for Enterprise Architecture: A primer for enterprise engineering and manufacturing. Zifa eBook.

[18] Gartner. Gartner Predicts 95 Per Cent of Organisations Will Support Multiple Approaches to Enterprise Architecture by 2015. Gartner Analysts to Explore the Right Approaches to Enterprise Architecture at the Gartner Enterprise Architecture Summit 2010, 17-18 May in London. Disponible en: http://www.gartner.com/it/page.jsp?id=1358913

[19] Universidad de Monash. Information Architecture Technology – MITA. 2006

[20] Universidad de Cardiff. IT Roadmap. Technology brick template. Disponible en: http://congliffy.cf. ac.uk/display/LeanEA/Technology+Brick+Template




[21] IFEAD (Institute For Enterprise Architecture Develop). Disponible en: http://www.enterprise-architecture.info/ Images/Extended%20Enterprise/Extended%20Enterprise%20Architecture.htm

[22] Jaap Schekkerman President & Thought Leader IFEAD Institute EA Developments, Holanda, Extended Enterprise Architecture Framework Essentials Guide Version 1.5, 2006.

[23] The American Heritage Dictionary of the English Language. Cuarta Edición. Boston, MA: Houghton Mifflin Company, 2006.

[24] O'Rourke, Carol, Neal Fishman, and Warren Selkow. Enterprise Architecture Using the Zachman Framework. Boston, MA: Course Technology, 2003. ISBN: 0-619-06446-3

[25] Perks, Col, and Tony Beveridge. Guide to Enterprise IT Architecture. New York, NY: Springer, 2003. ISBN: 0-387-95132-6

[26] "FEA Consolidated Reference Model Document Version 2.1," December 2006, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget.

[27] A Practical Guide to Federal Enterprise Architecture by the CIO Council, Version 1.0, February 2001.

[28] IFEAD (Institute For Enterprise Architecture Develop) http://www.enterprise-architecture.info/Images/Extended%20Enterprise/Extended%20Enterprise%20Architecture.htm

[29] Jaap Schekkerman President & Thought Leader IFEAD Institute EA Developments, The Netherlands, Extended Enterprise Architecture Framework Essentials Guide Version 1.5, 2006, pp 22.

[30] Richard J. Reese. Troux Enterprise Architecture: Managing the EA function. Architecture & Analysis Enterprise Articles. Agosto de 2010. Disponible en: http://www.packtpub.com/article/troux-enterprise-architecture-managing-ea-function




ARTICULOS



EA – UTPL - 396 - | P á g i n a

PLAN DE ACTUACIÓN PARA LA IMPLEMENTACIÓN DE UN FRAMEWORK ARQUITECTURA EMPRESARIAL

ORIENTADO A INSTITUCIONES DE EDUCACIÓN SUPERIOR

Armando Cabrera*, Carlos Román*, Diego Peralta*

Abstract--En el presente artículo se propone la adopción de un plan de actuación para la implementación de una estrategia de arquitectura de empresa en las instituciones de educación superior del Ecuador con la finalidad de propiciar la mejor utilización de los recursos de TI ( mejorar la calidad de los servicios, racionalizar la administración técnica y financiera de los activos de TI, y mejorar la gestión de los recursos y portafolio de proyectos), promoviendo la aplicación de un conjunto de estándares y guías de implantación, teniendo claro que el plan de actuación propuesto es una apuesta a futuro, que no es una camisa de fuerza, pues se reconoce la permanente evolución de la tecnología y las necesidades del negocio. Palabras clave: Educación superior, arquitectura empresarial, framework, tecnologías de información gobernanza de TI.

I. INTRODUCCIÓN

3.7.1 La administración y gestión de las tecnologías de información y comunicación juegan un papel importante dentro la estructura organizativa de las instituciones de educación superior. Manejar la infraestructura tecnológica, servicios, recursos en línea y datos, se han convertido en algunas de las principales preocupaciones que los lideres de TI deben tomar en consideración para satisfacer a cada una de las funciones institucionales (docencia, investigación y extensión12

[email protected], Doctor en Informática por la, Universidad Politécnica de Madrid – Profesor Titular de la Universidad - Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software. Universidad Politécnica de Madrid

) y con esto

[email protected], Docente Investigador, Universidad Técnica Particular de Loja - Escuela de Ciencias de la Computación. [email protected], Profesional en formación, Universidad Técnica Particular de Loja - Escuela de Ciencias de la Computación.

responder a los cambios regulatorios13

La comprensión de las interrelaciones entre las personas, los procesos de negocio, aplicaciones, datos, y tecnologías subyacentes será fundamental para lograr esta sinergia entre todas las partes de la organización. El desarrollo de una Arquitectura Empresarial (EA) será fundamental para manejar estas interrelaciones, es por esto que pretende desarrollar un framework de EA, que permita a las mismas, contar con un marco arquitectónico que conjugue la visión institucional con las TI. Por tal motivo será necesario inicialmente establecer un plan de actuación

, cambios del entorno externo, la creciente competencia y la globalización y las expectativas cambiantes de la sociedad.

14

En este contexto, ¿de qué sirve una arquitectura si no es posible gestionarla por si sola?, la solución la plantea el simple hecho de acoplar la EA (de las instituciones de educación superior) a un contexto de Gobernanza de TI. No se puede realizar una

que establezca el cómo llegar a consolidar el framework de EA que se busca como producto final. Si bien se puede afirmar que toda organización cuenta con un esquema EA informal/empírico, es necesaria la adopción de un modelo formal, que nos lleve al establecimiento de una efectiva gobernanza de TI.

[email protected], Profesional en formación, Universidad Técnica Particular de Loja - Escuela de Ciencias de la Computación. 12 Consejo Nacional de Educación Superior (CONESUP), De la Constitucion, Fines y Objetivos del Sistema Nacional de Educacion Superior. Base legal Art. 3. Disponible en http://www.conesup.net/capitulo1.php 13 Consejo Nacional de Educación Superior (CONESUP), Ley Orgánica de Educación Superior. Disponible en http://www.conesup.net/descargas/PROYECTO_LOES.pdf 14 “Plan de Actuación”, guía para comentar el estado actual en el cual está el desarrollo de un software.



EA – UTPL - 397 - | P á g i n a

efectiva Gobernanza de TI, sin la presencia de un modelo EA estructurado, y tampoco se puede consolidar una EA sin una estrategia de TI clara (Véase figura 2). Así, la arquitectura una vez establecida nos servirá para conocer al detalle cómo se manejará toda la estructura de negocio de la organización (o segmento arquitectónico), pero solo haciendo uso de una Gobernanza de TI se podrá gestionar adecuadamente esta EA. En la figura 1, se ilustra esta relación de dependencia.

Figura 1: Dependencia entre la EA y la Gobernanza TI [2] Como otras disciplinas tanto la EA como la Gobernanza de TI se encuentran regidas por estándares, y cuentan con metodologías formales. El objetivo del establecimiento de un framework de EA en el contexto de las instituciones de educación superior del Ecuador, es llegar a hacer uso de las fortalezas de las metodologías y los beneficios prestados por dichos estándares. Para ello se hará un análisis de cinco frameworks de la EA (Zachman15, FEAF16, TOGAF17, Gartner18, y E2AF), y a futuro implementar un framework orientado a la Gobernanza de TI, regido por el estándar ISO 3850019. a través del “Framework de IT Governance de Calder Moir”20

. En cuanto a estándares se deberán abordar explícitamente los orientados a esta disciplina, dados principalmente por ISO, IEEE, IFEAD, The Open group, CEN, NIST, BPMI, entre otros.

15 Mayor Información disponible en el sitio oficial: http://www.zifa.com/ 16 Federal Enterprise Architecture Framework. Disponible en el sitio: http://www.cio.gov/Documents/fedarch1.pdf 17 The Open Group Architectural Framework. Disponible en el sitio oficial: http://www.opengroup.org/togaf/ 18 Mayor información disponible en el sitio oficial: http://www.gartner.com/ 19 Estándar ISO de Gobernanza de las TI. Mayor información disponible en http://www.38500.org 20 Mayor información disponible en: http://www. itgovernance.co.uk/calder_moir.aspx

II. ARQUITECTURA DE EMPRESA DEFINICIÓN, PROPÓSITO Y BENEFICIOS

A. Definición e historia En principio es necesario tener claro el contexto de los términos constitutivos de “Arquitectura Empresarial”, pues al pensar en empresa, en innumerables ocasiones se asocia a la disciplina de la EA con temas relacionados a la gestión empresarial, y como veremos esto está bastante alejado de lo que realmente es. Una publicación de ANSI/IEEE plantea que: “Una arquitectura es la organización fundamental de un Sistema, consagrada en sus componentes, sus relaciones entre sí y entre el entorno, y los principios que guían su diseño y evolución” Por otro lado TOGAF [1] propone un concepto de empresa abordándolo como: “cualquier colección de organizaciones que tienen un conjunto común de metas y/o un simple resultado final”. El término Empresa en el contexto de la Arquitectura Empresarial puede ser usado para denotar ambas: una empresa entera (abarcando la totalidad de sus Sistemas de Información) y un dominio específico dentro de la misma. En ambos casos, la arquitectura cruza múltiples sistemas y grupos funcionales dentro de la empresa. Con la explicación propuesta el concepto de EA resulta simple de acuñar, una definición concisa, que la da Klaus Niemann [2] planteando que “el término Arquitectura Empresarial (EA) se refiere a una colección estructurada, armonizada y dinámica de planes que tienen como fin el desarrollo de un panorama empresarial de TI”. Pero esta disciplina no ha sido producto de la casualidad o de un desarrollo rápido, ha involucrado un proceso lento pero muy sólido que data de hace más de dos décadas, cuando John Zachman publicó en 1987 un artículo llamado "Un marco para la Arquitectura de Sistemas de Información" [3] en el que estableció tanto el reto y la visión de arquitecturas empresariales que orientarían el campo para los próximos 20 años. El reto consistía en gestionar la complejidad, cada vez mayor de sistemas distribuidos considerando que:



EA – UTPL - 398 - | P á g i n a

“El costo involucrado y el éxito de la empresa dependen cada vez más en sus sistemas de información, se requiere por lo tanto un enfoque disciplinado para la gestión de esos sistemas”. [3] La visión de Zachman era que el valor de negocio y la agilidad podrían ser mejor realizadas por un enfoque holístico para la arquitectura de sistemas. Tal enfoque llegó a conocerse como “Framework de Arquitectura Empresarial”. La influencia de Zachman fue tal que volcó al gobierno de EE UU para, a través del Departamento de Defensa, crear el “Framework de Arquitectura Técnica para Gestión de la Información” (TAFIM)21 introducido en 1994. TAFIM y otras metodologías fueron observadas por el Congreso de los EE.UU y como consecuencia se aprobó la Ley Clinger-Cohen de 1996, también conocida como la “Acta de ley para gestión de Tecnología de la Información”, esta establecía que todas las agencias federales debían tomar medidas para mejorar la eficacia de sus inversiones en TI [4]. El Consejo22 de CIOs23

, formado por CIOs de todos los órganos gubernamentales más importantes de EE UU, fue creado para supervisar este esfuerzo.

En Abril de 1998 el consejo de CIOs empezó a trabajar en su mayor proyecto, el “Framework de Arquitectura Empresarial Federal” (FEAF). La versión 1.1 [5] de este Framework fue lanzada en septiembre de 1999. Con el pasar de los años la responsabilidad de la Arquitectura Empresarial Federal pasó del consejo de CIOs a la oficina de Gerencia y Presupuesto (OBM)24

. En el año 2002 la OBM evolucionó y cambió la metodología FEAF dejándola como Arquitectura Empresarial Federal (FEA, por sus siglas en inglés) [5].

21 Technical Architecture Framework for Information Management. Disponible en: http://citeseerx.ist. psu.edu/viewdoc/summary?doi=10.1.1.25.1473 22 Información sobre el consejo disponible en el sitio oficial: http://www. cio.gov/ 23 Chief Information Officer: Alto ejecutivo de una empresa, responsable de la tecnología de información y de los sistemas informáticos que apoyan los objetivos de negocio. 24 Office of Management and Budget. Mayor información disponible en el sitio official: www.whitehouse.gov/omb/

En 1998, cuatro años luego después de la aparición del TAFIM, este fue oficialmente retirado por el departamento de defensa. El trabajo realizado por esta metodología fue entregado a “The Open Group” que lo transformaron en un nuevo estándar que es conocido hoy como “El Framework Arquitectónico de The Open Group”, (TOGAF). Durante 2005, casi al mismo tiempo en el que OBM se estaba convirtiendo en la fuerza dominante para el sector público, otra organización (Gartner) adoptó medidas para convertirse en una fuerza dominante para el sector privado. En ese año Gartner ya era una de las organizaciones más influyentes especializadas en consultoría a nivel de CIOs, el área específica de EA -el grupo de asesoramiento e investigación de TI- no era Gartner, sino Meta Group25

, quien fue absorbido completamente por Gartner.

Debido a los beneficios innegables de la EA se han desarrollado algunos frameworks como TAFIM, FEAF, TOGAF, DoDAF26, MODAF27, PEAF28, MAGENTA29, AGATE30, CIMOSA31

25 Mayor información disponible en: http://www.meta-group.com/aboutus.html

, entre otros, que han adoptado un modelo de metadatos estándar para definir los elementos críticos de arquitectura y las dependencias entre ellos. La Corporación MITRE muestra en su publicación EABOK [5] un significativo análisis sobre los mayores desarrollos históricos de la EA (Metodologías) en el que aborda a la mayoría frameworks mencionados y otros.

26 Department of Defense Architecture Framework. De uso gubernamental y desarrollado por el DoD de EE UU. Disponible en: http://cio-nii.defense.gov/sites/dodaf20/ archives.html 27 Ministry of Defense Architectural Framework. De uso gubernamental y desarrollado por el MoD Británico. Mayor Información Disponible en: http://www.mod.uk/ DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/ 28 Pragmatic Enterprise Architecture Framework. Disponible en el sitio oficial: http://www.pragmaticea.com/ 29 Framework de uso gubernamental, desarrollado en Singapur. Mayor información en: http://www.ida.gov.sg/ Programmes/ 20060419144239.aspx?getPagetype=34 30 Atelier de Gestion de l'ArchiTEcture des systèmes d'information et de communication. Metodología de manejo de sistemas de comunicación e Información del gobierno Francés. Disponible en: http://www.ixarm.com/AGATE -framework 31 Computer Integrated Manufacturing Open System Architecture. Disponible en el sitio oficial: http://cimosa. cnt.pl/Docs/Primer/primer1.htm



EA – UTPL - 399 - | P á g i n a

B. Dimensiones a considerar Un enfoque arquitectónico abarca las áreas clave de la vida organizacional, incluyendo al personal y sus dominios de trabajo que conforman la organización. Hay varios enfoques de estructuración del dominio de la EA, estos esencialmente se distinguen en términos del número de niveles arquitectónicos que abarcan, la demarcación de esos niveles y su granularidad. Algunas representaciones incluyen más niveles o subniveles. Estos modelos son mencionados y utilizados por diversas metodologías y abarcan aspectos de seguridad, información, datos e integración de la arquitectura. Los componentes adicionales mencionados pueden ser apropiadamente asignados al modelo básico mostrado en la pirámide de la Figura 2, sin embargo la experiencia ha demostrado que los modelos de EA complejos tienden a generar volúmenes de datos que son difíciles de manejar, más aún cuando se usa la arquitectura para propósitos de análisis y planeación. “Aunque los modelos complejos pueden ser exactos, en términos prácticos resultan inútiles.” [2] Cada área de análisis que será involucrada en la construcción del framework para instituciones de educación superior, puede ser considerada como una disciplina de estrategia separada (EA segmentada), ya que se enfoca al personal de distintos niveles y áreas (personal académico, estudiantes, empleados y trabajadores32

). A menudo cada grupo tiene sus propias herramientas, métodos, reglas, principios y políticas, etc., así como medios distintos de comunicar y compartir información sobre su área. Entonces deben tener su “propia forma” de arquitectura, es decir, una particularización a medida de la EA global que especifique sus formas de “llevar las cosas”.

32 Consejo Nacional de Educación Superior (CONESUP), Forman parte del Sistema Nacional de Educación Superior Ecuatoriano, Base Legal Capitulo 8, 9 y10. Disponible en http://www.conesup.net/

Figura 2: Dimensiones Base de una EA [2] El hecho de considerar a la EA como eje primordial dentro de la organización se fundamenta en la capacidad de esta disciplina de actuar como un elemento de cohesión entre las capas de la figura 2, la misma que reunirá las particularidades mencionadas en un framework, ofreciendo así un balance entre la visión del negocio y la estrategia de TI de las instituciones de educación superior. C. Propósito

Una EA ayudará a crear transparencia, sirviendo como base para la entrega de información al gobierno de las universidades33

, esta información será esencial para la toma de decisiones y el establecimiento de un adecuado control, además creará un sólido esqueleto para aplicar una Gobernanza de TI precisa. Sobre la consolidación adecuada de una estrategia de TI y bajo la gestión dada por una gobernanza, la EA será manejada como eje fundamental en asociación a la gestión de requerimientos y portafolio, así como a la gestión de operaciones y servicios. Véase la figura 3.

33 Consejo Nacional de Educación Superior (CONESUP), Del gobierno de las instituciones del sistema nacional de educación superior, Base Legal Capitulo 6. Disponible en http://www.conesup.net/capitulo6.php



EA – UTPL - 400 - | P á g i n a

Figura 3: Ambiente de una EA [2] D. Ciclo de vida Arquitectónico Un ciclo de vida genérico se ilustra en la figura 4, muestra los pasos generales (básicos) que a menudo tienen lugar en el desarrollo de una EA. Cada metodología tiene fases distintas o iguales. Entre las más importantes podemos destacar, por ejemplo, ADM [6] de TOGAF y FEA utilizan un modelo cíclico basado en once fases. Con la ejecución periódica a mediano plazo del ciclo mostrado en la figura 4 se establece un proceso de gestión integral. La gobernanza que se deberá aplicar debe ser integral, la gobernanza de la arquitectura se deberá sustentar en la gobernanza de TI, la misma que operará para ambas en múltiples niveles. “Las áreas que deseen establecer o mejorar su nivel de gobierno podrán referirse a los Objetivos de Control de la Información y tecnologías relacionadas como COBIT34, que es un marco para la gestión de TI con un enfoque similar al estándar manejado por el PMBOK35 para la gestión de proyectos, e ITIL36

para la gestión de servicios.” [19]

34 Control Objetives for Information and Related Technology. Para mayor información visitar el sitio oficial: http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=7981 35 Project Management Body of Knowledge. Disponible en: www.unipi.gr/akad_tmhm/biom_dioik_ tech/ files/pmbok.pd 36 Information Technology Infrastructure Library. Mayor infomación disponible en el sitio oficial: http://www.itil-officialsite.com/home/home.asp

Figura 4: Ciclo de Vida Genérico de una EA [9] E. Ventajas y Beneficios Las ventajas y beneficios dependerán estrictamente del modelo de dominio que se utilice para el desarrollo de la EA. En términos generales la premisa “La EA soporta la gestión de TI logrando que se hagan las cosas correctas de la manera correcta, con un mínimo riesgo” [2] garantiza la eficiencia y eficacia, mientras que la ausencia de riesgos no es más que alta seguridad. Las ventajas más significativas que ofrecerá el desarrollo del framework arquitectónico-organizacional para las instituciones

de educación superior serán:

• La metodología madurará gradualmente a medida que las instituciones de educación superior la vayan adoptando, como practica de mejora continua.

• Promover una visión integral del modelo de negocio, basándose en la interacción de todas las dimensiones involucradas.

• Ayudar con la creación de un repositorio único de información donde se deberán incluir los modelos que reflejan los procesos de la empresa, estos artefactos plasmarán las dimensiones que definen al negocio, además de identificar la relación que existe entre ellas.



EA – UTPL - 401 - | P á g i n a

• Brindar soporte a las operaciones de TI, iden-tificando impactos en los ajustes al modelo de la visión del negocio para conocer las implicaciones de un cambio, antes de arrancar un esfuerzo o nuevo proyecto.

• Proporcionar información para generar posibles escenarios de solución y de esta manera servirá como herramienta para la toma de decisiones en los ajustes a los procesos.

Existen beneficios inmediatos que se podrán observar en las áreas globales: • Eficiencia de TI: Involucra hacer bien las cosas. • Eficacia de TI: Involucra hacer las cosas que

deben hacerse (las correctas). • Confiabilidad de la EA: Hacer las cosas con un

mínimo riesgo. F. Cómo Definirla Partiendo del hecho situacional inicial (cómo se es) y teniendo por objetivo un estado final al cual se quiere llegar (como ser) las instituciones de educación superior, deberán considerar estos dos puntos al momento de plantearse el reto de su desarrollo, porque el estado final estará definido por la especificación arquitectónica del framework. Deberán prestar atención y asignar recursos para solventar lo que se busca ser en el futuro (EA objetivo), pero también el esfuerzo deberá estar amparado por un grado de conciencia pleno respecto al estado actual (activos de información existentes, procesos de negocio, estructuras organizacionales, infraestructuras varias, etc). Es vital que el proceso que especifique la línea base sea tomado con la mayor seriedad del caso, porque de él derivarán las acciones iniciales a tomar y el camino a seguir en busca de la EA objetivo. La retroalimentación de los profesionales ejemplifica la importancia de esto: “No se puede saber a dónde va alguien mientras no se tenga claro en dónde se está.” [2] Identificar el estado actual podrá servir también para encontrar brechas, redundancias y activos de datos ocultos, así como mostrar quién hace qué y en dónde dentro de las instituciones de educación superior. Tal proceso deberá incluir alguna forma de

análisis estratégico de brechas liderando la documentación del plan de actuación para la arquitectura.

III. PLAN DE ACTUACIÓN PARA LA

IMPLEMENTACIÓN

Partiendo del hecho de considerar a la EA como un “activo empresarial” [6], es necesario establecer un plan que lleve a las instituciones de educación superior a formalizar la disciplina de EA dentro de ellas e incluso generar masa crítica a través de la creación de programas educativos y de investigación para abordar esta área de creciente importancia. Llegar a tal consecución no será tarea fácil debido a que la EA implica un esfuerzo organizacional que requiere gestión, asignación de recursos, continuidad, coordinación y programas de formación académica. A través de trabajo conjunto se debe establecer una descripción de operaciones en la que se aplicará la EA, la visión a futuro que se busca, así como las estrategias de TI que sustentarán el cumplimiento de las metas definidas. Para ello se deberán considerar tres factores preponderantes.

A. Obtener apoyo del gobierno de las

universidades “Obtener el compromiso ejecutivo para cualquier iniciativa nueva requiere el desarrollo de un modelo de negocio sólido y un enfoque de comunicación para transmitir eficazmente dicho modelo.” [6] Sin apoyo del gobierno de las universidades será difícil mantener el patrocinio necesario para financiar e implementar los procesos y sistemas mejorados. Para poder obtener el patrocinio es necesario considerar: • Éxitos de otras organizaciones (experiencia y

conocimientos) en sus aplicaciones de EA. [6] • Usar ejemplos para demostrar como la EA

ofrece un programa integral para la gestión de cambios así como para lograr mejoras en el desempeño de la misión y la responsabilidad organizacional desde un enfoque de TI. [2]

Debido al contexto académico de las instituciones de educación superior, la principal meta es



EA – UTPL - 402 - | P á g i n a

convertirse en participantes activos de una EA a través de un compromiso formal, concurrente e integral. Como ejemplos institucionales de planes pilotos / proyectos completos podemos tomar como referencia al MIT37, Penn State University38, el programa JISC [7], Monash39, Minnesota40 y Saint Louis41

.

El grupo de EA en colaboración con el gobierno de universitario, deberá desarrollar una política basada en los principios arquitectónicos institucionales que gobernarán el desarrollo, implementación y mantenimiento arquitectónico. Una vez que haya sido diseminada la política arquitectónica, el grupo de EA deberá organizar y conducir el programa para explicar las metas, objetivos, procesos, productos, costos y otras actividades relacionadas al proceso. El objetivo de esta explicación es atraer a los principales stackeholders, de nivel medio y bajo de la organización. Una vez desarrollados y analizados, los primeros resultados sobre los “productos” de EA deberán ser publicados dentro de la organización para demostrar el valor de esos resultados tempranos y así lograr la máxima exposición de los beneficios en el esfuerzo de desarrollo del framework. B. Establecer una estructura de gestión y control

La dirección, control y monitoreo de las

actividades de EA y el progreso de las mismas deberá ser iterativo y cíclico. Una estructura organizacional robusta dentro de las instituciones de educación superior será necesaria para facilitar y acelerar las definiciones de los roles y responsabilidades asociadas al desarrollo del framework. Los roles deberán ser evaluados en 37 Massachusetts Institute of Technology. Los recursos de su programa de EA se encuentran disponibles en el sitio oficial: http://web. mit.edu/itag/eag/ 38 Información detallada disponible en el sitio oficial: http://ea.ist.psu.edu/ 39 Disponible el proyecto a detalle en el sitios oficial: http://www.its.monash.edu.au/staff/plans/architecture/ 40 Para mayor información visitar el sitio: http://www.state. mn.us/mn/externalDocs/OET/Minnesota_Enterprise_Architecture_Whitepaper_061406104429_MEA Whitepaper.pdf 41 Como se buscó consolidar la EA se encuentra explicado en: net.educause.edu/ir/library/powerpoint/MWR07072.pps

términos del tamaño de la organización, la complejidad de negocios, la arquitectura gestionada, junto con otros factores para determinar la correlación de roles adecuada asignada al personal.

Una estructura de gestión y control deberá estar conformada por un CIO y un grupo de revisión técnica. El CIO estará encargado de gestionar y analizar cada aspecto relacionado con la EA, así como deberá comunicar e integrar al gobierno de las universidades con los demás niveles (docencia, investigación y extensión); por esta razón se convertirá en un elemento clave para la innovación y para lograr una ventaja competitiva. El grupo de revisión técnica se encargará de examinar los proyectos y los activos de los mismos en base al alineamiento de ellos con la EA. Este grupo determinará y documentará los resultados de mano con las acciones. Para lograr lo anterior, el grupo deberá revisar y asegurarse que: • El proyecto completo se alinee con la EA. • El proyecto no se alinea con la EA y es

necesario definir un camino alternativo de acción.

• El proyecto no se alinea con la EA y se aprueba la renuncia al desarrollo del proyecto.

C. Productos y actividades 1) Desarrollar un plan de Marketing estratégico y un plan de comunicación

Inicialmente se deberá establecer una estrategia de marketing y una estrategia de comunicación cuyos objetivos estén encaminados a mantener informado al gobierno de las universidades y a las unidades organizacionales, así como para difundir información arquitectónica a los grupos de gestión. El CIO en colaboración con el personal deberá definir un plan de marketing y comunicaciones consistente en delimitaciones, nivel de detalle, medios de comunicación, retroalimentación de los participantes, calendario de actividades de comercialización y el método de evaluación del progreso de implementación. El rol principal del CIO, será interpretar la visión del gobierno universtario así como reconocer ideas innovadoras.



EA – UTPL - 403 - | P á g i n a

Uno de los medios recomendados para el marketing del framework es el plan de comunicaciones para informar al gobierno de las universidades y a las partes interesadas en la estrategia el plan a seguir. El plan de comunicaciones puede ser utilizado para expresar la visión de los altos directivos universitarios y el papel de la EA en el cumplimiento de esa visión. También dicho plan, deberá informar de los beneficios de la arquitectura como agente de cambio para alcanzar las metas organizacionales, o como recurso crítico para evaluar opciones de cambio, tal y como el negocio y la tecnología lo requieren. Se deben considerar también roles y responsabilidades de altos directivos y su relación directa con el proyecto. Todo lo anterior tendrá como fin demostrar los beneficios de la EA para los stakeholders de las instituciones de educación superior.

2) Desarrollar un Plan de Gestión (PG)

Este deberá incluir el Plan de actuación para el cumplimiento del conjunto de metas, así como los planes de implementación para llegar a esas metas. La figura 5 muestra como se podrían integrar las capas con respecto a cada una de las fases del proyecto, habiendo roles específicos para cada una de ellas.

Figura 5: Gestión de la EA [6]

El PG delinea planes y un conjunto de acciones

para desarrollar, utilizar y mantener la EA, incluida la gestión y control de toda la arquitectura. Facilitará el seguimiento de los costos, la programación de tareas y ofrecerá datos de rendimiento, así como procedimientos de supervisión y control que deben ser desarrollados,

documentados e implementados. El PG también deberá incluir artefactos [6] como:

a) Documentación de requisitos para el CIO de la EA, para identificar todas las necesidades de financiación: gastos, plazos, calendarios, y enlaces a las medidas de rendimiento.

b) Un plan de la estructura (PE) que detalle las tareas y subtareas necesarias para adquirir, desarrollar y mantener la arquitectura.

c) Documentación de estimaciones de recursos para su financiación, la dotación de personal, formación, requisitos de espacio de trabajo y las necesidades de equipo.

d) Plan de trabajo para el inicio de los planes del proyecto.

e) Documentación de requisitos para realizar control de calidad, gestión de riesgos, gestión de configuración y gestión de la seguridad.

f) Documentación de requisitos para el establecimiento y mantenimiento de un repositorio de información de EA.

3) Iniciar el desarrollo de la EA

Tomando como base los productos desarrollados

en los puntos anteriores, en este ámbito ya es posible iniciar el proyecto de EA. Hay varias actividades periféricas asociadas con su creación: • Instituir las prácticas del Plan de Gestión. • Establecer los procesos de desarrollo de la EA y

las prácticas de gestión para los mismos. [6] • Capacitar a los participantes del proyecto de EA.

[6] • Construir una línea base de los productos EA.

[5] • Establecer el objetivo esperado con los

productos EA. [5] • Crear el plan de secuenciación. [2] • Poblar el repositorio EA. [2]

D. Definir el Proceso y el Enfoque

La naturaleza de las instituciones de educación

superior del Ecuador (públicas financiadas por el Estado, particulares cofinanciadas por el Estado y



EA – UTPL - 404 - | P á g i n a

particulares autofinanciadas42

) y los factores inherentes a la arquitectura, dictarán el enfoque de cambio de la arquitectura a ser desarrollada. Si bien un enfoque arquitectónico es una excelente herramienta para manejar entornos amplios y complejos, la profundidad y detalle de la EA necesitan ser a medida de la organización. En la Figura 6 podemos observar esta relación.

Figura 6: Profundidad y Detalle de la Arquitectura [6]

Es esencial determinar el uso que se le dará a la arquitectura, porque esta determinará el tipo de proceso de desarrollo de la misma. Es normal la presencia de ciertas actividades en la definición del enfoque, así como en la selección de productos EA, en la construcción y en el uso final de la misma. Las metas [8] que se persigue con el proceso comprenden:

• Construir una arquitectura base (de referencia)

que represente la realidad. • Construir una arquitectura objetivo que

represente la visión y estrategias de la organización.

• Desarrollar un plan de secuenciación que describa una estrategia progresiva para la transición de la línea de base a la meta.

• Publicar una EA aprobada y el plan de secuenciación que serán accesibles por el personal de la institución de educación superior.

Además se deberán considerar algunos aspectos [6] como:

42 Consejo Nacional de Educación Superior (CONESUP), De la Constitución, Fines y Objetivos del Sistema Nacional de Educación Superior. Forman parte del Sistema Nacional de Educación Superior Ecuatoriano. Disponible en http://www.conesup.net/capitulo1.php

• Tener claro las reglas y procesos de negocio, necesidades de información, flujos, locaciones.

• Relevancia de las actividades, funciones, organizaciones, calendarios, etc.

• Ámbito de aplicación de la organización. • Escenarios operacionales, las situaciones y

zonas geográficas que se consideran (extensiones universitarias).

• Proyección de beneficios económicos. • Proyección de negocios y áreas técnicas de

riesgo. • Proyección de disponibilidad y capacidades de

las tecnologías específicas, durante el plazo de destino (se aplica a la arquitectura de destino únicamente).

E. Adoptar un Framework

En este punto ya se tendrá definido a nivel administrativo como estará estructurado el proyecto, el siguiente paso será adoptar un framework (ya sea predefinido o desarrollado) que especificará de manera formal cada elemento constitutivo de la EA. Existen varios frameworks, pero se ha tomado especial atención a cinco de los enfoques más relevantes de esta disciplina, se deberán contrastar a profundidad Zachman, FEA, TOGAF, Gartner y E2AF. Es por ello necesario abordar brevemente a cada metodología y considerar un estudio [18] propuesto por Gartner en el que predice que el 95% de las organizaciones soportarán múltiples enfoques de EA hasta el año 2015. Gartner ha identificado en su estudio cuatro enfoques arquitectónicos de EA: tradicional, federado, medio exterior y diversidad gestionada. El análisis ha demostrado que la mayoría de practicantes de la disciplina EA harán uso de una mezcla de más de uno de estos enfoques basados en sus necesidades de negocio. Los enfoques mencionados se definen como: • Tradicional: el equipo de EA toma como base la

estructura organizacional para facilitar el proceso de EA, se centra en el contenido normativo que sirve para guiar la consistente toma de decisiones de proyectos con el plan maestro consagrado a la arquitectura. Este enfoque tiende a funcionar bien en organizaciones en las que gran parte de la toma



EA – UTPL - 405 - | P á g i n a

de decisiones es centralizada y son relativamente estables en términos del ritmo de cambio. No funciona tan bien en organizaciones donde la toma de decisiones y la autoridad son distribuidas y donde el ritmo de cambio en los negocios es alto.

• Federado: hecho para organizaciones grandes y complejas, en donde la toma de decisiones es a menudo muy descentralizada, con unidades de negocio caracterizadas por una considerable autonomía en la EA. Una arquitectura federada se centra en definir el núcleo y elementos comunes entre los departamentos y unidades. Este enfoque se adapta bien a las organizaciones distribuidas geográficamente y es menos eficaz en las organizaciones altamente centralizadas con un negocio homogéneo.

• Medio exterior: es una aproximación a EA por la que los arquitectos se centran en la gestión de las dependencias clave entre las partes de la organización que tengan el mayor impacto en la capacidad de cambio. Este enfoque se centra en la interoperabilidad arquitectónica mediante la definición de un pequeño, pero robusto, conjunto de estándares estables de interfaz, al tiempo que permite una completa autonomía de la toma de decisiones para las tecnologías y productos específicos que se usan en las soluciones. Este enfoque es muy adecuado para las organizaciones y los "ecosistemas de negocios", donde las unidades de negocio, socios y proveedores no están bajo el control directo de un equipo central de EA.

• Diversidad gestionada: se centra en la definición de varias opciones. Este enfoque de EA conjuga la necesidad de un conjunto de normas con la necesidad de una diversidad de soluciones para aumentar la innovación, el crecimiento empresarial y ventaja competitiva. Los equipos de proyectos pueden decidir cuál es el producto mejor que se adapte a las necesidades del proyecto, en lugar de tener una única norma que se imponga. La ventaja de este enfoque es que permite a los usuarios y equipos (de la EA) seleccionar la herramienta correcta para su trabajo, lo que permite la innovación desde la diversidad. La desventaja de este enfoque es que los usuarios y equipos del proyecto deben aceptar una mayor responsabilidad en sus decisiones.

Con un enfoque combinado de EA, las

instituciones de educación superior tratarán de determinar el equilibrio apropiado de control de su arquitectura mediante la aplicación de un enfoque arquitectónico adecuado. Esto significa que el equipo de EA tendrá que determinar un framework de decisión que les permitirá evaluar y ponderar qué enfoque se deberá usar para cualquier solución que se deba dar, definiendo qué podría ser más apropiado considerando la tecnología, información y aspectos de negocio.

1) Zachman: Se define formalmente como una taxonomía de “artefactos arquitectónicos”43

El propio John Zachman describe su trabajo de la siguiente manera:

en términos de una organización (es decir, documentación, especificaciones, modelos) que son utilizados en asuntos particulares dentro del movimiento de la empresa de acuerdo al direccionamiento que se tenga de algún asunto en el que se mueve el negocio.

El Framework EA tiene su aplicación en las empresas como una estructura lógica simple de clasificación y organización, las representaciones descriptivas de una Empresa que son importantes para la administración de la misma, como también el desarrollo de los Sistemas Empresariales. [10] Según Zachman: el esquema del Framework ha estado con nosotros por cientos de años, y estoy seguro que lo estará aún por un ciento de años más. Lo que cambiaremos será el entendimiento de éste y cómo lo usaremos para le Ingeniería Empresarial y Manufactura [11]. La siguiente dimensión que propone Zachman es un enfoque descriptivo de los artefactos, entonces las preguntas esenciales a responder son: qué, cómo, cuándo, dónde, quién y por qué del proyecto. El contexto de éstas preguntas se verá afectado por quién es el propietario que formula las preguntas, de acuerdo a la necesidad imperante en un momento determinado.

43 Cualquier entregable tangible desarrollado en base a las necesidades organizacionales.



EA – UTPL - 406 - | P á g i n a

La idea estructural que sugiere Zachman sobre la EA, insinúa una composición en celdas particulares en las que se enmarcará solamente un artefacto, con este objeto se evitará que exista ambigüedad, debido a que siempre se conocerá cuál es el lugar en el que habita un artefacto determinado. Una segunda sugerencia dentro de la taxonomía de Zachman indica que se deberá considerar un trabajo cumplido siempre y cuando se haya concluido con una celda particular. Esto garantizará que no se produzcan mezclas en los propietarios del trabajo y los artefactos en desarrollo. Cuando cada una de las celdas dispuestas en una parrilla (grid) está llena con cada uno de los artefactos que conforman el Sistema, cada uno de los participantes tendrá una visión más amplia de éste, desde cada uno de los ángulos de disposición, obviamente con el enfoque de EA.

2) TOGAF: se define a sí mismo como un

Framework, no obstante, la parte más importante de TOGAF es su Método de Arquitectura de Desarrollo, el cual es mejor conocido como ADM.

El éxito de la arquitectura empresarial propuesta por TOGAF es la división de ésta arquitectura en cuatro capas [1]:

• Arquitectura de Negocio: engloba los

parámetros relacionados con el negocio de ésta forma se logra conocer los objetivos y estrategia del mismo.

• Arquitectura de Aplicaciones: describe cómo las aplicaciones son diseñadas y cómo se desarrolla la interacción entre éstas.

• Arquitectura de Datos: describe como empresa almacena los datos, los organiza y accede a ellos.

• Arquitectura Técnica: describe la infraestructura del hardware y software que soporta las aplicaciones y su interacción.

ADM es un repositorio para la creación de la arquitectura, y éste puede organizarse como un proceso, lo que en teoría resumiría el concepto de TOGAF en una Arquitectura de Procesos, en vez de un Framework Arquitectónico o una Metodología, como es definido por The Open Group.

En contraposición con Zachman: “es necesario

categorizar los artefactos” [17], en TOGAF, se entrega una técnica que permita crear dichos artefactos.

El enfoque de TOGAF en el ámbito de la

arquitectura empresarial se enfoca directamente dentro de la arquitectura continua, creando rangos que incluirán desde la arquitectura genérica más grande, hasta la más pequeña y específica, a éste tipo de técnica se la conoce como Enterprise Cotinuum. La metodología ADM de TOGAF permite precisamente lograr aquel movimiento que va desde lo genérico hasta lo específico.

Una diferenciación un tanto precisa de los

niveles—en los que se pretende desglosar lo universal y convertirlo en específico—descritos en TOGAF, es el siguiente:

Fundation Architectures, en el que se incluyen

todos los principios arquitectónicos que podrán—al menos en teoría—ser utilizados por cualquier TI en el campo empresarial de su dominio.

El siguiente nivel de especificación, es el de

Arquitectura de Sistemas Comunes, es el diseño arquitectónico que se desea ver en muchos de los tipos de empresas.

El siguiente nivel de especificación, es el concerniente a Arquitecturas Industriales, y son los relacionadas a las empresas que tienen el mismo dominio, y en cuyo caso el crecimiento se desarrolla de forma exponencial (caso de sucursales).

Se denomina en TOGAF un nivel específico a

las Arquitecturas Organizacionales; y son las arquitecturas que harán específica a una determinada empresa.

3) FEA: Su objetivo primordial es implementar un marco referencial de Arquitectura Empresarial común y transversal, para las múltiples agencias y funciones gubernamentales de los EE UU. Visto desde el punto de vista de análisis, se convierte en uno de los más potentes Frameworks, debido a que posee un estudio de taxonomía comprensivo, al igual que Zachman, además de una



EA – UTPL - 407 - | P á g i n a

arquitectura de procesos como TOGAF. Entonces FEA puede ser considerado como una metodología para la creación de una Arquitectura Empresarial, o el resultado de la aplicación de procesos a una Empresa Particular. Generalmente se describe a FEA como un conjunto conformado por cinco modelos referenciales para incrementar su performance: Negocios, Servicios, Componentes, Tecnologías y Datos. Aquellos son considerados los elementos constitutivos de FEA, aunque un tratamiento minucioso necesariamente incluirá los siguientes parámetros [6]:

a) Una visión general de cómo la Arquitectura Empresarial deberá ser vista.

b) Un conjunto de modelos de referencia para describir las diferentes perspectivas de la Arquitectura Empresarial.

c) Procesos para crear la Arquitectura Empresarial.

d) Procesos Transaccionales para la migración de una Pre-Arquitectura Empresarial a un paradigma Post-Arquitectura Empresarial

e) Una taxonomía para catalogar activos que están incluidos en las competencias de la Arquitectura Empresarial.

f) Una aproximación a la medición de satisfacción del uso de una Arquitectura Empresarial para conducir el valor del negocio.

g) La Oficina de Administración del Programa de Arquitectura Empresarial Federal (FEAPMO)44

“Un leguaje común y un Framework que describe y analiza inversiones IT, mejora la colaboración y por último transforma al Gobierno Federal en Ciudadano-centralizado, orientado a resultado, en base al mercado organizacional como un conjunto progresivo en la Agenda de Administración del Presidente” [6]

afirma que FEA provee:

La perspectiva de FEA de EA en una empresa, es la construcción en segmentos, basados en la idea introducida por FEAF. Siendo entonces un segmento aquella línea mayor de la funcionalidad de un negocio, de la misma forma que lo serían los recursos humanos. Existiendo así dos tipos de 44 Mayor información disponible en: http://www.aboutus.org/Feapmo.gov

segmentos: los segmentos núcleo visión-área, y los segmentos negocio-servicio. Los segmentos de negocio-servicio, son fundamentales para la mayoría de organizaciones políticas—probablemente para todas ellas—por ésta razón, éste tipo de arquitectura empresarial ha servido como soporte para las instituciones gubernamentales dentro de las oficinas federales en Estados Unidos. FEA consiste en un conjunto de “Modelos de Referencia” interrelacionados, diseñados para facilitar el análisis entre agencias y la identificación de valores duplicados de inversión, brechas y oportunidades de colaboración entre éstas. Colectivamente, los modelos referenciales componen el Framework para describir los elementos importantes de FEA en una vía común y consistente [6].

4) Gartner: Según la concepción de Gartner, la Arquitectura Empresarial trae consigo tres elementos constituyentes: propietarios del negocio, especialistas de información e implementadores de tecnología; como objetivo está siempre la unificación de éstos tres elementos, pensado en un futuro acople a una visión común para dar valor al negocio. Más allá de cualquier desarrollo de artefactos y documentos técnicos, Gartner se preocupa por una eficiente implementación de una maqueta definida como “una sola idea común”, y deberá ser entendida y compartida por todos los participantes activos de la empresa. De acuerdo a los modelos de negocio, en muchas empresas, se experimenta cambios continuos en ciertos procesos, para éste caso, Gartner sugiere una creación de Arquitectura Empresarial, de una manera en la que cada miembro conozca la naturaleza, objetivos y el impacto de dichos cambios. La propuesta de Gartner es mucho más acertada si se propone en términos de estrategia, y no tanto de ingeniería. Esta visión se enfoca en el destino del negocio, y lo más importante de éste concepto es que la idealización de destino no se preocupa tanto



EA – UTPL - 408 - | P á g i n a

por el dónde está yendo la empresa sino más bien por el cómo está yendo. El Framework de Arquitectura Empresarial de Gartner, es justo, preciso y orientado a resolver los paradigmas creativos en los andamiajes colectivos, se presenta un modelo arquitectónico como un conjunto unitario y equilibrado en el que cada participante deberá conocer exactamente cada visión y enfoque para poder operar coherentemente de acuerdo a sus niveles de competencia. Luego de la definición de un objetivo común, será posible implementar modelos que resuelvan de forma eficiente los movimientos futuros del negocio. La principal preocupación de Gartner es el cómo mover las fichas sobre la marcha, entonces se puede encontrar algún tipo de metodología que no se resolverá mediante modelado debido a que se ha demostrado que nadie es capaz de modelar absolutamente todo [12].

5) E2AF: La arquitectura empresarial extendida (Extended Enterprise Architecture Framework E2AF por sus siglas en inglés) es un framework creado por Institute For Enterprise Architecture Develop IFEAD, desarrollado con el propósito de comunicar los aspectos arquitectónicos a los stakeholder. Tiene como eje fundamental la integración de los parámetros organizacionales y tecnológicos todo enmarcado en el plano de una unificación holística de tres elementos fundamentales: El elemento de construcción, el elemento de función y el elemento de estilo [21].

Desde la perspectiva organizacional generalmente no se ha dado importancia a la construcción y función de los parámetros relacionados con la arquitectura empresarial, restando de manera considerable la participación del “estilo” (elemento de la arquitectura) o simplemente ignorando las competencias que éste supone. Debido a que en la arquitectura extendida se considera el estilo además de los tres anteriormente citados, se entenderá que se relaciona con el comportamiento cultural, valores, normas y principios, así como de qué manera se incorporan éstos en los valores institucionales de las organizaciones.

Al mismo tiempo, la arquitectura empresarial direcciona los aspectos de Negocio, Información,

Sistemas de Información e Infraestructura Tecnológica de una manera integral que abarca la organización y su entorno en el plan de zonificación y a un nivel de plano de una ciudad [21].

Con el E2AF se busca ayudar a generar a los arquitectos empresariales un conjunto de métodos, técnicas y buenas prácticas, dando capacidad de integrar los aspectos empresariales con los tecnológicos, así se tendría una elaborada marca de proyección a objetivos concretos, administración y manejo de la complejidad abordados dentro de un ciclo de cambio continuo guiados por la Arquitectura Empresarial Extendida. En conclusión, el adoptar E2AE garantiza que: • Los resultados puedan ser utilizados como un

diccionario para administrar y navegar en los aspectos relevantes de una institución.

• Los roadmaps serán definidos para identificar las tareas necesarias y las actividades

• Con E2AE se identificarán los elementos de complejidad a ser direccionados, las personas involucradas en el proceso así como las relaciones y dependencias existentes entre éstos

• E2AE guiará de forma eficiente en todos las Actividades Arquitectónicas. [22]

F. Criterios de selección de Framework

Debido al contexto empresarial y de negocios de

cada uno de los frameworks analizados, se deberá tomar en consideración el enfoque que la educación superior (docencia, investigación y extensión) propone; por esta razón se podría recomendar tomar lo más relevante asociado a este contexto de cada una de las cuatro principales metodologías para obtener una metodología personalizada, o bien desarrollar una estrategia EA considerando la propuesta del enfoque de Gartner [18].

Como modelo de referencia inicial se ha tomado para la tabla 1 la contrastación hecha por Roger Sessions [15] y a partir de ella se ha comparado con el modelo estadístico propuesto por el PEAF en su contrastación de frameworks [16]. Debido a la mayor granulidad en criterios se ha decidido incluir la puntuación de Sessions en este artículo.



EA – UTPL - 409 - | P á g i n a

TABLA I: CONTRASTACIÓN DE FRAMEWORKS [15] Criterio Zachman TOGAF FEA Gartner E2AF Taxonomía 4 2 2 1 2 Procesos 1 4 2 3 4 Gobierno de un Modelo de Referencia

1 3 4 1 3

Prácticas de Orientación

1 2 2 4 3

Madurez del modelo

1 1 3 2 1

Enfoque de Negocio

1 2 1 4 2

Dirección de Gobernanza

1 2 3 3 2

Dirección de Partición

1 2 4 3 2

Catálogo Prescriptivo

1 2 4 2 2

Neutralidad del Vendedor

1 2 4 2 2

Disponibilidad de Información

2 4 2 1 2

TOTAL 15 26 31 26 25

G. Criterios para selección de la herramienta

El enfoque para la selección de la herramienta deberá ser orientado al framework sobre el cual se trabajará, tomando como referencia dos dimensiones base planteadas por el IFEAD [13]: la funcionalidad básica de cada herramienta, y la utilidad que brindará a los distintos profesionales involucrados.

Otro enfoque es el orientado hacia la funcionalidad, que se describe en base a requerimientos y cómo la herramienta es capaz de realizar diferentes funciones, necesarias para la actividad de desarrollo de una EA. El análisis está estructurado de acuerdo a los siguientes parametros [13]: • Metodologías y modelos. • Interface de desarrollo de modelos. • Automatización de la herramienta. • Personalización y extensión. • Manipulación y análisis. • Repositorio. • Arquitectura de implementación. • Licenciamiento y soporte técnico. • Resultados arquitectónicos. La segunda dimensión, aborda la utilidad de la herramienta para los diferentes perfiles profesionales, es decir, captura la aptitud vista desde

el propósito de la herramienta, y describe su usabilidad. Los perfiles a considerarse [13] son: • Arquitectos Empresariales. • Arquitectos de soluciones. • Planificadores estratégicos / Dirección. • Gerentes de Programas de Empresa. • Arquitectos de software e ingenieros. • Socios externos. La figura 7 ilustra algunos aspectos que deben considerarse para la elección de la herramienta partiendo de tres criterios: propósito, contenido y formato.

EA TOOL

Porpuse Content

Format

RelationshipsENTERPRISE

Visualizations Language

Applications

Information

Business

Technology

AgilityIntegration

Products / ServicesProcesses

Organization

Middle warePlataform Network

Data Software

InternalExternal

DrawingsGraphicsImages ModelsPatterns

GuidelinesPrinciples

RulesStarting Points

Narrative

Figura 7: Dimensiones a considerar para la elección de una herramienta [14]

En base a la lista de software del IFEAD [13] se ha desarrollado una contratación formal entre treinta y dos herramientas, tomando en consideración once criterios. En la tabla 2 se han colocado los cinco productos que obtuvieron mayor puntuación. Se deberá tomar en consideración este análisis para la



EA – UTPL - 410 - | P á g i n a

selección de la herramienta que se utilizará, por lo que se recomienda revisar más a profundidad los productos: Bizzdesign Architect y Bizzdesigner, Corporate Modeler Enterprise Edition, Enterprise Architect, System Architect Family + Rhapsody, y finalmente Troux.

TABLA II: CONTRASTACIÓN DE HERRAMIENTAS Criterio/ Vendedor

BizzDesign CaseWise Sparx Systems

IBM – TeleLogic

Troux

Metodologías 3 10 10 5 10 Modelos 8 10 10 8 8 Interfaz 9 7 10 10 10 Automatización 9 9 10 10 10 Personalización 9 8 10 9 9 Manipulación 10 9 10 10 10 Repositorio 9 9 10 10 10 Arq. De Implementación

9 7 10 10 10

Licenciamiento 7 7 7 10 10 Resultados Arquitectónicos

10 9 9 10 9

Utilidad 8 8 6 10 8 TOTAL 8,2 8,4 9,2 9,2 9,4

H. Del desarrollo a la implementación, cómo hacer

perdurar la arquitectura

La implementación por si sola carece de sentido si no se establecen las primitivas necesarias para hacer que la EA se mantenga periódicamente y sea sometida a revisión en busca de necesidades de cambio. La tabla 3 muestra un modelo de enfoque estratégico que podría ser adoptado con el fin de establecer puntos clave de control, que apoyarán a la revisión y mantenimiento de la EA. Este modelo plantea un corte a mediano plazo que busca fortalecer el desarrollo táctico y uno a largo plazo enfocado en cambio a la dirección estratégica. TABLA III: PLANEACIÓN ESTRATÉGICA DE UNA EA [20]

Actual 0-2 años 2-5 años Línea Base Desarrollo Táctico Dirección Estratégica

Todos los productos y tecnologías que actualmente están en uso. (Que tenemos ahora)

Productos o tecnologías recomendadas para usar en los próximos 2 años. (Lo que nos gustaría tener)

Productos o tecnologías recomendadas para los próximos 5 años. (Que deseamos tener en el futuro)

Principales plataformas

Usado en otras partes

Plataformas emergentes

Los productos y tecnologías más importantes actualmente en uso. (Cuales son las plataformas de mayor uso)

Los principales productos o tecnologías usados en otras partes. (Que otras organizaciones lo usan)

Productos o tecnologías a ser evaluadas (Lo que podemos ver venir como posibilidades)

Para retiro Para revisión Plataformas piloto

Productos o tecnologías marcadas para retiro. (Lo que se debe desechar)

Los productos o las tecnologías previstas para la inversión limitada (recursos, mantenimiento, etc.) solamente. (Qué es lo que se tiene que desechar, pero no se puede, entonces se limita su uso).

Los productos o tecnologías que se están desarrollando con miras a convertirse en estratégicas (Lo que están desarrollando con miras a convertirse en estratégicas)

Una vez tomados en consideración los criterios

de secciones anteriores, es necesario realizar un levantamiento de información que servirá para generar los productos y poblar el repositorio EA. Contando con la línea base arquitectónica y el enfoque que se tiene por objetivo, se revisarán y validarán los artefactos inherentes a la EA, se deberán elaborar modelos y posteriormente estos deberán ser refinados.

Una vez que hayan sido identificados las brechas y el plan de migración, la EA deberá ser aprobada, publicada y diseminada en la institución de educación superior que la vaya a aplicar. Con este paso formalmente empezarán a girar los engranes que integrarán el enfoque arquitectónico a los procesos de la organización. Deberá considerarse como guiar al personal, establecer los procesos y procedimientos de aplicación de la EA, y finalmente se deberá ejecutar los procesos ya integrados (procesos EA - procesos de la institución de educación superior). [6]

Finalmente, para poder mantener robusta y hacer madurar la arquitectura, esta deberá ser valorada periódicamente, los productos EA serán evaluados en base a un nivel de reflejo con la realidad, y se deberá considerar propuestas de cambio (como las sugeridas por la tabla 3).

IV. CONCLUSIONES

Enfrentar un desafío de implementar un enfoque de EA en las instituciones de educación superior el Ecuador requiere como aspecto clave, tener claro “en donde se está” y hacia dónde se quiere llegar organizacionalmente. El compromiso de las instituciones debe ser integral en cuanto a la inversión necesaria de recursos para la adopción del enfoque EA, al asignar adecuadamente dichos recursos y con una robusta planeación, se hará del



EA – UTPL - 411 - | P á g i n a

desarrollo un proceso iterativo y simplificado. También se debe considerar que el ciclo de vida arquitectónico deberá llevarse a mediano plazo por la constante evolución y crecimiento de las instituciones de educación superior, indistintamente a la que se aplique, debido a su constante desarrollo. Finalmente la metodología (framework) que se desee utilizar puede estar amparada por un solo enfoque, pero es conveniente tratar de reunir las fortalezas de cada enfoque en un framework híbrido especializado para la educación superior.

1. BIBLIOGRAFIA [1] The Open Group. The Open Group Architecture Framework

“TOGAF”. The Open Group, 2009. Versión 9. ISBN: 978-90-8753-230-7

[2] Niemann D. Klaus. From Enterprise to IT Governance “Elements of Effective IT Management”. GWV Fachverlage GmbH, 2005. ISBN 3-528-05856-0.

[3] Zachman, A. John. "A Framework for Information Systems Architecture." IBM Systems Journal, Volumen 26, Número 3, 1987. Disponible en: http://www.zachmaninternational.com/images/stories/ibmsj2603e.pdf

[4] Clinger-Cohen, Acta de la Ley de 1996 (PL 107-347) Disponible en la librería del Congreso: http://thomas.loc.gov/default.aspx

[5] Corporación MITRE. EABOK. Guide to the (Evolving) Enterprise Architecture Body of Knowledge. Mclean, Virginia, 2004.

[6] Chief Information Officer Council. Federal Enterprise Architecture. Versión 1.0. 2001. Disponible en el sitio official: http://www.whitehouse.gov/omb/e-gov/fea/

3.7.2 [7] Joint Information Systems Commitee (JISC). Doing Enterprise Architecture: Enabling the agile institution. 2009. Disponible en: http://www.jisc.ac.uk/media/documents/techwatch/jisc_ea_pilot_study.pdf

3.7.3 [8] Ross W. Jeanne, Weill Peter, Robertson C. David. Enterprise Architecture As Strategy: Creating a

3.7.4 Foundation for Business. Harvard Business Press. 2006. ISBN: 978-1591398394

[9] Selig, J. Gad, Waterhouse Pete. IT Governance – An Integrated Framework and Roadmap: How to Plan, Deploy and Sustain for Competitive Advantage. 2006. Disponible en: http://www.axisgroup.com/downloads/CA_Clarity_IT_governance_whitepaper.pdf

[10] Zachman, John A. "The Framework for Enterprise Architecture: Background, Description and Utility." Zachman Institute for Framework Advancement (ZIFA). Document ID: 810-231-0531

[11] Entrevista con John Zachman. Roger Sessions, Editor en jefe de, “Perspectives of the International Association of Software Architects”.

[12] Gartner, Gartner Enterprise Architecture Process: Evolution 2005, R. Scott Bittler, Gregg Kreizman, ID: G00130849

[13] Institute for Enterprise Architecture Developments – IFEAD. Enterprise Architecture Tools Selection Guide. J. Schekkerman. Versión 5.0. 2009. Disponible en: http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v50.pdf

[14] Veltman Elise, Reekum Van. Determinig the Quality of Enterprise Architecture Products. Tesis de Masterado. Universidad de Utrecht & Sogety Holanda B.V. 2006. Disponible en: http://www.dya.info/Images/Thesis%20E_van_Reekum_Determining_Quality_Enterprise_Architecture_Services%20v2_tcm13-24174.pdf

[15] Objectwatch Inc. A Comparison of the Top Four Enterprise-Architecture Methodologies. Sessions Roger. 2007

[16] Pragmatic EA Ltd. PEAF: Framework Comparision. Versión 2.0. 2010. Disponible en www.pragmaticea.com/docs/peaf-overview1-framework-comparison.pdf

[17] Zachman A. John. The Zachman Framework for Enterprise Architecture: A primer for enterprise engineering and manufacturing. Zifa eBook.

[18] Gartner. Gartner Predicts 95 Per Cent of Organisations Will Support Multiple Approaches to Enterprise Architecture by 2015. Gartner Analysts to Explore the Right Approaches to Enterprise Architecture at the Gartner Enterprise Architecture Summit 2010, 17-18 May in London. Disponible en: http://www.gartner.com/it/page.jsp?id=1358913

[19] Universidad de Monash. Information Architecture Technology – MITA. 2006

[20] Universidad de Cardiff. IT Roadmap. Technology brick template. Disponible en: http://congliffy.cf.ac.uk/display/LeanEA/Technology+Brick+Template

[21] IFEAD (Institute For Enterprise Architecture Develop). Disponible en: http://www.enterprise-architecture.info/ Images/Extended%20Enterprise/Extended%20Enterprise%20Architecture.htm

[22] Jaap Schekkerman President & Thought Leader IFEAD Institute EA Developments, The Netherlands, Extended Enterprise Architecture Framework Essentials Guide Version 1.5, 2006.

INTEGRACIÓN DE BUENAS PRÁCTICAS PARA LA …dspace.utpl.edu.ec/bitstream/123456789/1657/3/Román...

Documents

Transcript of INTEGRACIÓN DE BUENAS PRÁCTICAS PARA LA …dspace.utpl.edu.ec/bitstream/123456789/1657/3/Román...