Metodología Basada en Investigación-Acción para la Implementación del Framework de Zachman-Edición Única

Monterrey, Nuevo León a de 200

Lic. Arturo Azuara Flores:

Director de Asesoría Legal del Sistema

Por medio de la presente hago constar que soy autor y titular de la obra titulada"

", en los sucesivo LA OBRA, en virtud de lo cual autorizo a el Instituto Tecnológico y de Estudios Superiores de Monterrey (EL INSTITUTO) para que efectúe la divulgación, publicación, comunicación pública, distribución y reproducción, así como la digitalización de la misma, con fines académicos o propios al objeto de EL INSTITUTO.

El Instituto se compromete a respetar en todo momento mi autoría y a otorgarme el crédito correspondiente en todas las actividades mencionadas anteriormente de la obra.

De la misma manera, desligo de toda responsabilidad a EL INSTITUTO por cualquier violación a los derechos de autor y propiedad intelectual que cometa el suscrito frente a terceros.

Metodología Basada en Investigación-Acción para la

Implementación del Framework de Zachman-Edición Única

Title Metodología Basada en Investigación-Acción para la Implementación del Framework de Zachman-Edición Única

Authors Juan Manuel Nogueira Delgado

Affiliation ITESM-Campus Monterrey

Issue Date 2006-07-01

Item type Tesis

Rights Open Access

Downloaded 19-Jan-2017 10:49:43

SUPERIORES DE MONTERREY

CAMPUS MONTERREY

PROGRAMA DE GRADUADOS EN TECNOLOGÍAS DE

INFORMACIÓN Y ELECTRÓNICA

Metodología basada en Investigación-Acción para la implementación

del Framework de Zachman

TESIS

PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADEMICO DE:

MAESTRO EN ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN

POR:

ISC. Juan Manuel Nogueira Delgado

DIVISIÓN DE TECNOLOGÍAS DE INFORMACIÓN Y ELECTRÓNICA

PROGRAMA DE GRADUADOS EN TECNOLOGÍAS DE INFORMACIÓN Y ELECTRÓNICA

Los miembros del comité de tesis recomendamos que la presente tesis del ISC. Juan Manuel Nogueira Delgado sea aceptada como requisito parcial para obtener el grado académico de Maestro en Administración de Tecnologías de Información.

Comité de tesis:

______________________________

______________________________

Sinodal

______________________________

_________________________________________

del Framework de Zachman

POR:

ISC. Juan Manuel Nogueira Delgado

TESIS

Presentada al Programa de Graduados en Tecnologías de Información

y Electrónica

Este trabajo es requisito parcial para obtener el grado de Maestro

en Administración de Tecnologías de Información

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS

SUPERIORES DE MONTERREY

iv

A

postgrado, que resultó ser todo un proyecto de vida, y depositaron en mí la confianza porque sabían que lograría el éxito.

A

P

v

A Dios por darme la oportunidad de vivir esta nueva etapa de mi vida y haberme guiado por la misma para culminarla satisfactoriamente.

A mi asesor y a los sinodales por haberme compartido su conocimiento y experiencia para la realización y la defensa exitosa de esta tesis.

A mis padres Juan Manuel Nogueira Díaz y Lucía Delgado Rodríguez por haberme apoyado en esta nueva aventura, y haberme permito tomar mis propios riesgos para crecer como persona y en el ámbito profesional. Los quiero mucho.

A mis hermanas Fabi y Grey por haber estado conmigo a través del Messenger platicando un rato para poder sobrellevar la carga de mis actividades. ¡En verdad muchas gracias, las quiero mucho!

A mi novia Lorna por haberme esperado todo este tiempo y haber compartido los pequeños momentos que podíamos estar juntos, y por creer que la distancia no es una barrera. En verdad mil gracias preciosa, te quiero mucho.

Al Dr. Jiménez por su invaluable apoyo siempre oportuno y desinteresado, por el sólo hecho de compartir sus experiencias y enriquecer mi trabajo recepcional.

A mis compañeros de MTI, MA y MDM, y en especial a Grace, Marco, RoseMa, Iván, Elba, Alex, Cynthia y David Romero, por haber hecho que los momentos difíciles pareciesen fáciles y permitirme compartir su valioso tiempo, además de su profundo conocimiento y enriquecedora experiencia. De cada uno de ustedes he aprendido algo nuevo y he recibido su apoyado en diferentes formas y sobre todo: ¡Muchas gracias a todos por su valiosa amistad!

Al equipo de PyME CREATIVA y ECOLEAD quienes convivieron conmigo como asistentes de investigación en el desarrollo de estos proyectos.

vi

El Framework de Zachman fue desarrollado para crear una Arquitectura de Sistemas de Información. Con los nuevos modelos de empresas, como son las empresas de base tecnológica, y la gran cantidad de información que deben integrar y el reto de cambios que implican los avances tecnológicos, el Framework de Zachman provee una herramienta de gran utilidad y valor para llevar a cabo la construcción de una arquitectura de la empresa que pueda integrar y alinear la tecnología a las metas del negocio.

En la práctica, los aspectos relacionados al modelo de negocio, modelo de sistemas y en parte el modelo de tecnología es descuidado por las empresas, siendo este en muchas ocasiones la fuente de las fallas y deficiencias de las arquitecturas de cada uno de estos niveles, que la propuesta del Framework de Zachman cubre para que sean contemplados en la arquitectura de toda la empresa o del desarrollo tecnológico.

En este trabajo de tesis se propone una metodología basada en investigación-acción que adecua su naturaleza para crear una nueva metodología que pueda ser usada para implementar el Framework de Zachman en los aspectos del modelo de negocio, de sistemas y de tecnología y poder construir la arquitectura que cubra estos aspectos para así cubrir el objetivo principal de la presente tesis.

vii

DEDICATORIAS ... IV AGRADECIMIENTOS ... V RESUMEN ... VI TABLA DE CONTENIDOS... VII LISTADO DE TABLAS ... XI LISTADO DE IMÁGENES... XII

CAPÍTULO 1. INTRODUCCIÓN

1.1 DESCRIPCIÓN DEL PROBLEMA. ... 2

1.2 JUSTIFICACIÓN. ... 4

1.3 OBJETIVO. ... 5

1.4 METODOLOGÍA. ... 5

1.5. CONTENIDO DE LA TESIS. ... 5

2.1 EMPRESAS DE BASE TECNOLÓGICA... 8

CAPÍTULO 2. BASE TEÓRICA

2.2.1DEFINICIÓN DE INFRAESTRUCTURA DE TECNOLOGÍA DE INFORMACIÓN. ... 9

2.2.2ARQUITECTURA DE TECNOLOGÍA DE INFORMACIÓN... 11

2.2.3DIFERENCIA ENTRE INFRAESTRUCTURA Y ARQUITECTURA DE TECNOLOGÍA DE INFORMACIÓN. ... 12

2.3 ARQUITECTURA DE NEGOCIOS... 13

2.4 FRAMEWORKS Y ARQUITECTURAS DE EMPRESAS. ... 15

2.4.1DEFINICIONES. ... 15

2.4.2DIFERENCIA ENTRE UN FRAMEWORK Y UNA ARQUITECTURA... 18

2.4.3FRAMEWORKS,ARQUITECTURAS Y MODELOS DE REFERENCIA... 18

2.4.3.1 PERA (Purdue Enterprise Reference Architecture)... 21

2.4.3.2 CIMOSA (CIM Open System Architecture) ... 22

viii

2.4.3.5 FEAF (Federal Enterprise Architecture Framework) ... 25

2.4.4BENEFICIOS DE UTILIZACIÓN DE ARQUITECTURAS DE EMPRESAS. ... 25

2.4.5CÓMO SELECCIONAR UN FRAMEWORK. ... 26

2.5 INVESTIGACIÓN-ACCIÓN. ... 29

2.5.1FASES DEL MODELO... 31

2.5.1.1 Fase de Planeación o Diagnóstico... 35

2.5.1.2 Fase de Acción. ... 36

2.5.1.3 Fase de Observación. ... 36

2.5.1.4 Fase de Reflexión. ... 37

CAPÍTULO 3. FRAMEWORK DE ZACHMAN

3.2 MODELOS DE NEGOCIOS. ... 48

3.3 MODELO DE SISTEMAS... 50

3.4 MODELO DE TECNOLOGÍA. ... 51

CAPÍTULO 4. METODOLOGÍA DE IMPLEMENTACIÓN DEL

FRAMEWORK DE ZACHMAN

4.2 CICLO 1. MODELO DE NEGOCIO... 55

4.2.11)DIAGNÓSTICO. ... 55

4.2.22)PLAN DE ACCIÓN... 56

4.2.33)TOMA DE ACCIÓN... 60

4.2.55)APRENDIZAJE /REFLEXIÓN. ... 62

4.3 CICLO 2. MODELO DE SISTEMAS... 63

4.3.11)PLAN DE ACCIÓN... 63

4.3.22)TOMA DE ACCIÓN... 65

4.3.35)APRENDIZAJE /REFLEXIÓN. ... 67

4.4 CICLO 3. MODELO TECNOLÓGICO. ... 67

4.4.11)PLAN DE ACCIÓN... 68

4.4.22)TOMA DE ACCIÓN... 69

ix

5.1 CASO DE ESTUDIO: PYME CREATIVA. ... 74

5.1.1DESCRIPCIÓN... 74

5.2 IMPLEMENTACIÓN DE METODOLOGÍA. ... 77

5.2.1CICLO 1.MODELO DE NEGOCIO... 77

5.2.1.1 Diagnóstico. ... 77

5.2.1.2 Plan de Acción. ... 77

5.2.1.2.1 Análisis de Involucrados... 77

5.2.1.3 Toma de Acción. ... 80

5.2.1.3.1 Reunión de Equipo. ... 80

5.2.1.3.2 Aplicación de cuestionarios. ... 81

5.2.1.3.4 Llenado/modelado del renglón de Contexto y Modelo de Negocio. ... 81

5.2.1.3.5 Presentación de resultados. ... 90

5.2.1.4 Evaluación/Observación. ... 90

5.2.1.5 Aprendizaje/Reflexión. ... 90

5.2.2CICLO 2.MODELO DE SISTEMAS... 91

5.2.2.1 Plan de Acción. ... 91

5.2.2.1.1 Presentación de trabajo a realizar. ... 91

5.2.2.1.2 Análisis de herramienta de recolección de información... 91

5.2.2.2 Toma de Acción. ... 91

5.2.2.2.1 Aplicación de cuestionario... 91

5.2.2.2.2 Análisis de resultados... 91

5.2.2.2.3 Llenado/modelado del renglón de Modelo de Sistemas. ... 92

5.2.2.2.4 Presentación de resultados. ... 100

5.2.2.3 Observación... 101

5.2.2.4 Reflexión. ... 101

5.2.3CICLO 3.MODELO TECNOLÓGICO. ... 101

5.2.3.1 Plan de Acción. ... 101

5.2.3.1.1 Presentación de trabajo a realizar. ... 101

5.2.3.1.2 Análisis de herramienta de recolección de información... 101

5.2.3.2 Toma de Acción. ... 102

5.2.3.2.1 Aplicación de cuestionario... 102

5.2.3.2.2 Análisis de resultados... 102

5.2.3.2.3 Llenado/modelado del renglón de Modelo Tecnológico. ... 102

5.2.3.2.4 Presentación de resultados. ... 110

5.2.3.3 Observación... 110

5.2.3.4 Reflexión. ... 110

x

REFERENCIAS BIBLIOGRÁFICAS... 117

ANEXOS ... 124

ANEXO A. IDENTIFICAR Y ENLISTAR A TODOS LOS POTENCIALES

INVOLUCRADOS. ... 125 ANEXO B. HACER UNA EVALUACIÓN DE LA IMPORTANCIA DE CADA

INVOLUCRADO EN EL ÉXITO DEL PROYECTO Y SUS RELATIVOS PODER O RIESGO. ... 126 ANEXO C. MATRIZ DE ASIGNACIÓN PARA LA IMPLEMENTACIÓN DEL

xi

Tabla 2. 1 Ejemplo de descripciones detalladas ... 15

Tabla 4.1 Propuesta de modelación de información ... 62

Tabla 4.2 Información producida por el renglón Modelo de Negocio ... 63

Tabla 4.3 Propuesta de modelación de Información ... 66

Tabla 4.4 Información producida por el renglón Modelo de Sistemas... 67

Tabla 4.5 Propuesta de modelación de Información ... 71

Tabla 4.6 Información producida por el renglón Modelo de Tecnología... 72

Tabla 5.1 Definición de involucrados ... 78

Tabla 5.2 Evaluación de importancia de involucrados ... 78

Tabla 5.3 Matriz de Asignación de Responsabilidades... 80

Tabla 5.4 Análisis de resultados del renglón de Contexto ... 88

Tabla 5.5 Detallado de actividades ... 89

xii

Figura 2.1 Relación de Arquitecturas (EACommunity mencionado en Pereira y

Sousa, 2004)... 17

Figura 2.2 Simplificación del Framework de Zachman (Steinkey y Nickolette, 2003) ... 24

Figura 2.3 Resultados de la investigación de Lapkin al Framework de Zachman. 27 Figura 2.4 Modelo de Investigación-Acción (Kemmis et. al., 1988)... 32

Figura 3.1 Tabla de analogías de construcción de proyectos de ingeniería de construcción, de aviones y de sistemas de información (Zachman, 1999. Impreso sin autorización) ... 39

Figura 3.2 Framework de Zachman (www.zachmaninternational.com, 2006) ... 41

Figura 3.3 Modelo de Negocio del Framework de Zachman (www.zachmaninternational.com, 2006) ... 48

Figura 3.4 Modelo de Sistemas del Framework de Zachman (www.zachmaninternational.com, 2006) ... 50

Figura 3.5 Modelo de Tecnología del Framework de Zachman (www.zachmaninternational.com, 2006) ... 51

Figura 4.1 Metodología propuesta para la implementación del Framework de Zachman [Adaptado de los modelos de Susman (1983) y Lewin (2003)] ... 54

Figura 4.2 Actividades del Plan de Acción del ciclo 1 ... 56

Figura 4.3 Matriz de Asignación de Responsabilidades (Project ... 58

Figura 4.4 Actividades de la Toma de Acción del ciclo 1 ... 60

Figura 4.5 Actividades de Plan de Acción del ciclo 2 ... 63

Figura 4.6 Actividades de la Toma de Acción ciclo 2 ... 65

Figura 4.7 Actividades del Plan de Acción del ciclo 3 ... 68

Figura 4.8 Actividades de la Toma de Acción ciclo 3 ... 70

Figura 5.1 Diagrama Entidad-Relación ... 85

Figura 5.2 Diagrama de flujo de PyME CREATIVA [Adaptado de Molina y Medina (2003)] ... 86

Figura 5.3 Representación de las localidades y su interacción... 87

Figura 5.4 Organigrama de PyME CREATIVA... 88

Figura 5.5 Representación de etapas del proyecto... 89

Figura 5.6 Modelo de e-Mercadeo ... 92

Figura 5.7 Modelo de e-Suministro ... 93

Figura 5.8 Modelo de e-Negociación ... 94

Figura 5.9 Diagrama de actividades de alta de nuevo cliente... 95

Figura 5.10 Diagrama de actividades de seguimiento de cotización... 96

xiii

Figura 5.13 Asignación de responsabilidades del equipo de trabajo ... 99

Figura 5.14 Modelo de representación de Ciclo de Vida de Desarrollo de Software... 99

Figura 5.15 Diagrama de integración de e-servicios a los procesos de las PyMEs... 100

Figura 5.16 Diagrama E-R de la base de datos ... 103

Figura 5.17 Diagrama de secuencias de alta de nuevo cliente... 104

Figura 5.18 Diagrama de secuencias de seguimiento de cotización... 105

Figura 5.19 Diagrama de secuencia de registro de tiempos muertos ... 106

Figura 5.20 Modelo de Tecnología de Red ... 107

CAPÍTULO 1

1.1 DESCRIPCIÓN DEL PROBLEMA.

El mundo de la tecnología está cambiando constantemente por su rápido desarrollo, lo cual hace que las operaciones de negocios también cambien; esta situación hace que los sistemas de información y las operaciones de negocio comiencen a integrarse uno al otro. Bonn-Oh Kim y Sang M. Lee (1996) dicen que la Tecnología de Información (TI) ha llegado a ser el arma más potente de los administradores para formular e implementar estrategias de negocios.

Por lo tanto, hoy en día se puede pensar que estas estrategias de negocio dependen en gran parte de las necesidades de TI en una organización, lo cual hace que la forma de administrar la organización cambie, según Ramaraj Palanisamy (2005), quien menciona que el ambiente de negocios de hoy está cambiando dinámicamente por el constante cambio tecnológico, las competencias globales y el comercio electrónico.

El uso extenso de la Internet y los negocios electrónicos (e-business) en años recientes han comenzado a causar un movimiento secundario en diferentes tipos de información disponible por las aplicaciones empresariales; y que estas aplicaciones deben interactuar con bases de datos, aplicaciones de servidor, sistemas de administración de contenidos (content management systems), data warehouse, workflow systems, motores de búsqueda, message queuer, Web crawlers, minería y análisis de paquetes, e integrarse con otras aplicaciones empresariales. Estas empresas deben usar una variedad de interfaces de programación y entender una variedad de lenguajes y formatos; es por esta razón que las empresas deben de enfrentar el reto de integración de su información (Roth, Wolfson, Kleewein, Nelin, 2002).

Esta integración y el crecimiento complejo de las empresas de TI, como Naik et. al. (2004) comentan, es reflejado en el incremento de la complejidad de administración de sistemas, ya que para reducir el costo total de propiedad asociada con la administración de sistemas, las empresas han iniciado una estandarización de aplicaciones de software al igual que de los procesos de TI usados.

Naik et. al. (2004) dicen que existen algunas consideraciones de cuidado para diseñar la implementación de una arquitectura de TI, algunas de estas consideraciones son motivadas por el desempeño y otras por el estado del arte disponibles por la tecnología. Esta selección de herramientas de diseño no obliga hacia un tipo en específico, pero cabe resaltar que lo que se requiere es una estandarización que se pueda integrar a cualquier sistema de información.

Maaikel Klein Klouwenberg et. al. (1995), el desarrollo de una arquitectura inicia con la estrategia de negocio.

Zachman (1999) comenta que la arquitectura de sistemas de información se realiza para poder proveer una clara comunicación profesional, y mejorar e integrar el desarrollo de metodologías y herramientas, y de la misma forma establecer un nivel de credibilidad en la inversión de sistemas.

Bonn-On et. al. (1996) mencionan que las arquitecturas de TI intentan capturar las necesidades de información de las organizaciones y así formalizar los datos. Ellos mencionan que dicha arquitectura está compuesta de dos modelos:

1. Arquitectura de Datos: provee un alto nivel del anteproyecto (blueprint) de las necesidades de organización de la información. También provee un fundamento de qué proceso de negocio puede ser diseñado y modificado. 2. Arquitectura de Procesos: describe las actividades de las organizaciones.

Por otro lado, Hayley Carter (1999), menciona que es necesaria una manera más sistemática y “holística” de planeación para conocer las necesidades de información de las organizaciones para resolver sus problemas. En respuesta a esto, menciona que está surgiendo la arquitectura de TI.

Maaikel Klein Klouwenberg et. al. (1995) y Hayley Carter (1999) coinciden en que la arquitectura de TI es un término usado para describir varios componentes de la ITI y la arquitectura del negocio, la cual es definida como un modelo de procesos de negocio soportado por la TI.

Terry Moriarty (2001) explica que a mediados de los años 80’s John Zachman, en ese entonces de IBM, propuso una matriz como Framework para planificar sistemas de información. En la matriz pone en un eje las cosas de interés, cosas que deben ser consideradas o creadas para administrar información (datos, funciones, redes, gente, tiempo, y motivación). En el otro eje muestra varias perspectivas que necesitan ser consideras para cada una de estas cosas (empresa, sistemas de información, tecnología y no contextual, por ejemplo). Estas columnas y renglones forman el Framework de Zachman.

Zachaman creó su Framework haciendo una analogía a los sistemas de información, siguiendo los pasos para la construcción de un inmueble. Este modelo incluye la misión, visión metas, estrategias, tácticas y planes de la empresa (Terry Moriarty, 2001).

capital (Bachher y Guild, 1996); por esta razón un framework para construir su arquitectura de empresa sería una herramienta adecuada para este tipo de empresas.

1.2 JUSTIFICACIÓN.

Con el énfasis de los mercados globales, las empresas llegaron a ser más complejas y tener sistemas aún más complejos, y dependen de la disponibilidad de información y conocimiento inter e intraorganizacional (Kosanke, 2005).

Recientemente, investigaciones de sistemas de información han sido conducidas con consideraciones inadecuadas del ambiente global. Tanto negocios internacionales y disciplinas de administración estratégica han tendido a ignorar los temas de sistemas de información, y como observó Neo (1991), la literatura del campo de sistemas de información en el rol de tecnología de información tiene implícita o explícitamente un enfoque a la competencia de industrias domésticas. Un factor limitante en esfuerzos previos de dirigir las investigaciones globales de tecnología de información ha sido el parte aguas de un modelo conceptual de alcance y abstracción suficiente para unir las diferentes escuelas de pensamiento y sus investigaciones (Gibson Rick, 1994).

También comenta que la adopción de un acercamiento de arquitectura al desarrollo de los sistemas de información ha sido reconocido por varios investigadores como un punto clave para investigaciones de sistemas de investigación durante la siguiente década, de hecho, Zachman (1987), mencionado en Gibson Rick (1994), afirmó que el tamaño y la complejidad de aumento de las puestas en práctica de la tecnología de información requirieron que una cierta construcción lógica esté utilizada para definir y controlar las interfaces y la integración de los componentes del sistema.

Popkin Jan (2005) en su investigación comentó que las arquitecturas de empresas son el siguiente paso natural en el mundo de hoy, que unen tres tipos diferentes de arquitectura en una vista cohesiva que cruza los límites departamentales, une datos, aplicaciones y arquitecturas de negocios. Usando una plataforma de arquitectura compartida, una referencia de arquitectura empresarial puede ser desarrollada, lo cual facilitaría la colaboración y una mayor vista global de la organización desde una perspectiva estratégica. Esto también provee una guía para la tecnología y las inversiones de la organización entera y lo que ésta involucra.

Aunado a lo anterior, no existe una metodología que provea una guía para la implementación del Framework de Zachman en los aspectos relacionados al modelo de negocios, modelo de sistemas y modelo de tecnología.

1.3 OBJETIVO.

Desarrollar una metodología basada en investigación acción para implementar el Framework de Zachman en los aspectos relacionados con el modelo de negocios, modelo de sistema y modelo de tecnología.

1.4 METODOLOGÍA.

1. Revisión de la literatura: se hizo un análisis de la literatura existente para centrarnos en el contexto del documento, abordando la temática de empresas de base tecnológica; describiendo las arquitecturas de negocio y la integración de TI haciendo diferencia entre infraestructura y arquitectura tecnológica. Con el panorama anterior se abordó también sobre arquitecturas de integración de empresas indicando los diferentes tipos que hay, y algunos frameworks y modelos que ayudan a la construcción e integración de estas arquitecturas. Con lo anterior se pudo hacer la selección de un framework, para el caso de esta investigación el Framework de Zachman. Por último se cubrió lo referente a la metodología Investigación-Acción sobre la cuál se basará la nueva propuesta metodológica.

2. Se abordó el análisis detallado del Framework de Zachman cubriendo los aspectos relacionados al modelo de negocio, modelo de sistemas y modelo de tecnología.

3. Integración de los modelos de la investigación acción al Framework de Zachman para el desarrollo de la metodología objetivo de esta tesis.

4. Aplicación de la metodología al caso de estudio PyME CREATIVA como ejemplo de un desarrollo tecnológico, teniendo como uno de los resultados de la aplicación, la reflexión de la metodología propuesta para hacer mejoras en la misma.

5. Elaboración de este documento de tesis cubriendo los aspectos antes vistos, incluyendo la reflexión y elaboración de conclusiones del desarrollo del reporte.

1.5. CONTENIDO DE LA TESIS.

arquitecturas, frameworks y modelos de referencia que son utilizados para llevar a cabo procesos de integración de empresas.

También se analiza la metodología investigación Investigación-Acción, describiéndola y mostrando a detalle la estructura de la misma, así como la descripción de los modelos aportados a la metodología.

En el capítulo 3 se detallará el Framework propuesto por John Zachman, analizando de manera minuciosa las 4 primeras etapas del mismo que contemplaran el análisis del caso de estudio.

En el capítulo de 4 se propone una metodología basada en Investigación Acción para implementar el Framework de Zachman en el Modelo de Negocio, de Sistema y de Tecnología.

En el capítulo 5 se encuentran los resultados del caso de estudio para la comprobación de esta metodología aplicado en el proyecto PyME Creativa.

CAPÍTULO 2

En el siguiente apartado de la presente tesis se verá el marco teórico que envuelve la temática de la investigación presentada, partiendo de una descripción de los nuevos modelos o tipos de empresas como las empresas de base tecnológica, las infraestructuras y arquitecturas de Tecnologías de Información, las arquitecturas de negocios, los diferentes frameworks y marcos de referencia para la construcción de arquitecturas de empresas. En este capítulo también se encuentra una descripción de algunos frameworks, como el de Zachman, y los beneficios que hay de la utilización de estos frameworks para crear arquitecturas de empresa, así como algunos puntos clave para la selección de un framework.

Por último, se encuentra descrita la metodología de investigación Investigación-Acción (action research) que será la base para la creación de la metodología propuesta por el autor de esta tesis para implementar el Framework de Zachman.

2.1 EMPRESAS DE BASE TECNOLÓGICA

Las empresas son entidades organizacionales construidas para producir bienes y/o servicios en respuesta a las necesidades de los clientes. Las empresas son altamente dependientes del mercado y necesidades y satisfacción del cliente. Las empresas deben enfrentar dos ambientes dinámicos (Bernus, Nemes y Williams, 1996):

1. El ambiente externo caracterizado por un cambio rápido de necesidades del mercado y competencia de otros vendedores ofreciendo el mismo esfuerzo. 2. El ambiente interno caracterizado por los objetivos globales, actitudes de

administración, y cambios tecnológicos.

Góngora Caamal (2003) menciona que hoy en día están surgiendo un nuevo tipo de empresas que están cubriendo y ganando un mayor mercado, estas empresas son las Empresas de Base Tecnológica (EBT). Las nuevas empresas de base tecnológica son empresas jóvenes, que intentan comercializar una tecnología por primera vez y esperan obtener ventaja competitiva de ella. Las primeras etapas de desarrollo de una empresa son conocidas como etapas tempranas: semilla, inicial y primera etapa. En cada una de estas etapas tienen necesidades específicas tanto de habilidades como de capital (Bachher y Guild, 1996).

Las nuevas empresas de base tecnológica han resaltados por tener un rol de juego importante, potencialmente, han creado un mayor número de empleos y han ido más allá de sus mercados locales a mercados internacionales (Keogh & Evans, 1998).

Las empresas de base tecnológica integran en forma intensiva la innovación, el espíritu empresarial y el desarrollo tecnológico, y juegan un papel muy importante en el crecimiento económico de un país, así como en el desarrollo económico y social en las regiones donde se establecen. Y el capital de riesgo ha jugado un papel importante en la creación y el desarrollo de nuevas empresas de base tecnológica (Góngora Caamal, 2003).

Brandkamp Michael (1997) en su investigación comenta que la principal actividad económica de las empresas de base tecnológica, la cuál por definición determina el éxito de la firma, se asume que por ser un proyecto técnico innovador contiene substancial y técnicamente altas actividades de investigación y desarrollo. Las nuevas empresas de base tecnológica enfrentan un obstáculo especial en el crecimiento del capital y los altos riesgos, largos tiempos de recuperación, y grandes inversiones requeridas para transferir nueva tecnología en el mercado, por lo tanto las características de las empresas de base tecnológica comúnmente resultan en grandes cambios en sus adquisiciones de capital. Temas como altos riesgos, nuevos mercados, motivación de propietarios, recuperación de tiempo en desarrollo de productos, activo base limitado, y derechos de propiedad intelectual a menudo presentan importantes apremios sobre la habilidad de las empresas de base tecnológica para incrementar su capital (Auken, 2001).

2.2 INFRAESTRUCTURA Y ARQUITECTURA DE TECNOLOGÍA DE INFORMACIÓN.

2.2.1 Definición de Infraestructura de Tecnología de Información.

Kayworth, Chatterjee y Sambamurthy (2001) mencionan que una Infraestructura de Tecnología de Información (TI) es vitalmente importante para las compañías, particularmente para aquellas industrias que cambiaran dinámicamente, aquellas que harán re-ingeniería de sus procesos de negocios, y aquellas que operen ampliamente dispersas (Broadbent y Weill, 1997).

de información para mantener una arquitectura de TI consistente para evitar sistemas fragmentados, huecos de integración, o como se refiere Lindquist (1992) "islas de información" (Kayworth, Chatterjee y Sambamurthy, 2001).

El tema común que emerge de conceptualizar Infraestructura de TI es que ésta es un recurso organizacional típicamente coordinado por alguna de las centrales de sistemas de información de la organización y es compartida a través de las diferentes unidades; por lo tanto desde esta perspectiva, la Infraestructura de TI puede ser vista como un recurso compartido que consiste de activos físicos e intelectuales de TI (Kayworth, Chatterjee y Sambamurthy, 2001).

Ellos también argumentan que Weill (1993) proporcionó una clara definición de Infraestructura de TI, la cual dice que la base fundamental de las capacidades presupuestadas de TI para y provista por los sistemas de información para que funcione y se comparta a través de múltiples unidades de negocio o áreas funcionales. La capacidad de TI incluye tanto expertise técnica y administrativo requerido para proveer servicios confiables.

Los componentes de una infraestructura de tecnología de información incluyen las redes, bases de datos, aplicaciones y habilidades y capacidades del personal del área de tecnología de información. De acuerdo con Byrd y Turner, una infraestructura de tecnología de información es definida como recursos compartidos de un componente técnico de hardware, software, tecnología de comunicación, datos y aplicaciones clave y componentes de habilidades y competencias humanas que provean una fundación tecnológica única para intercambios dispersos a través de una organización para diseñar, desarrollar, implementar y mantener las presentar y futuras aplicaciones del negocio (Chung, Byrd, Lewis, y Ford, 2005).

Los estándares de la Infraestructura son definidos como guías que dictan como son adquiridos los activos de TI, administrados y utilizados dentro de la organización; por lo que, al haber una ausencia de estándares sobre cómo utilizar estos activos puede resultar en una inhabilidad para integrar los sistemas en la organización, consecuentemente, los estándares o rutinas organizacionales necesitarán ser establecidos para asegurar que el expertise humano es aplicado a los activos de TI de manera significativa (Kayworth, Chatterjee, y Sambamurthy, 2001).

Weill, Subramani, y Broadbent (2002) mostraron que la Infraestructura de TI no es solo un disco en la caja amarilla marcada como Norton Antivirus o incluso un comprensivo programa SAP de facturación, sino servicios centralmente coordinados y presupuestados por el administrador senior y capacidades humanas y técnicas comprometidas.

estos recursos críticos para crear valor sobre sus bases, particularmente si la infraestructura es inimitable o no es fácil de duplicar por otros (Kayworth, Chatterjee y Sambamurthy, 2001).

Chung, Byrd, Lewis y Ford (2005) mencionan que la capacidad estructural única de TI puede proveer a las compañías beneficios materiales de una continuidad de las prácticas de negocio. Kettinger et al. (1994) sugieren que una de estas definiciones de capacidades estructurales es la infraestructura tecnológica.

La Infraestructura de TI puede ser conceptualizada como un tipo de estructura organizacional que facilitará altos niveles de tareas y procesos de integración, de modo que permita mayor sensibilidad a las empresas (Kayworth, Chatterjee y Sambamurthy, 2001).

2.2.2 Arquitectura de Tecnología de Información.

La arquitectura de información es el término colectivo usado para describir los diferentes componentes de toda la infraestructura de información, la cuál involucra el modelo de negocio, los componentes de procesos de negocio y los sistemas de información que soportan el negocio (Popkin, 2005).

Sillivan (1982), mencionado en Gibson Rick (1994), comenta que una arquitectura de sistemas de información emerge lentamente en el tiempo como un cometido de la organización para algunos niveles de integración con una mezcla adecuada de forma y contexto; como tal, las firmas eligen concentrarse, consecutivamente, sobre uno de los componentes de los sistemas de información: procesamiento, almacenamiento de datos, comunicaciones o aplicaciones. Los investigadores subsecuentes eligieron estructurar sus acercamientos apuntando solamente uno de estos cuatro componentes.

organización, y metas de administración de recursos de información (Bolles, 2004).

Recientemente y quizás lo más provechosamente posible, Karimi y Konsynski (1991) definieron la arquitectura empresarial de los sistemas de información para una firma global como un mapa de alto nivel de los requisitos de la información enteros de la firma, compuestas por la red, datos, aplicaciones y sub-arquitecturas tecnológicas. Este estudio amplió su definición para incorporar el planeamiento, la organización, y las técnicas del control que Earl (1989) sugirió que permitiría a una arquitectura completa de tecnología de información servir como foro pro activo para la interacción mundial (Gibson Rick, 1994).

En su artículo publicado en 1987, "A Framework for Information Systems Architecture", John Zachman definió una arquitectura de sistemas de información, primero "por crear un framework descriptivo de algunas disciplinas independientes de sistemas de información", después especificó "arquitecturas de sistemas de información basadas en un neutro y objetivo framework”. Este framework ha llegado a ser conocido como el Framework de Zachman por su autor (Evernden R., 1996).

Carter, H. (1999) comenta que algunas de las características “mecánicas” del proceso de diseño de arquitectura que dan valor son: 1) una perspectiva jerárquica sobre el diseño, 2) integración de diseño e implementación, 3) siempre trabaja contra el presupuesto, 4) uso de componentes estándares, 5) cambio de la administración, 6) absoluta responsabilidad de diseño; y que éstas pueden ser traducidas al campo de la información. Por ejemplo, hoy en día se realizan más compras de sistemas de información para los componentes básicos; por lo tanto, el arquitecto de información proveerá una solución adaptada a las necesidades específicas del cliente (aunque él/ella pueda utilizar componentes estándares), muy similar a lo que un “verdadero” arquitecto hace cuando diseña una casa o un edificio. Dentro de la arquitectura de información, la innovación y la creatividad pueden generar una ventaja competitiva.

La re-ingeniería de procesos de negocio (Business Process Reengineering - BPR) es un elemento clave en los factores que conducen el cambio en la arquitectura de TI (Melling, 1994).

2.2.3 Diferencia entre Infraestructura y Arquitectura de Tecnología de Información.

específicas, como: administración basada en los clientes, continua mejora en escala de metas, fluida, flexible y organizaciones virtuales, gerencia creativa de recursos humanos, y ética igualitaria. Los métodos convencionales de desarrollo de sistemas no son suficientes ni apropiados para desarrollar sistemas de información que soporten las organizaciones de clase mundial en este nueva era de tecnología de información (Bonn-On, Kim et. al., 1996).

Retomando lo que dijo Naik et. al. (2004) respecto a la complejidad presentada actualmente, según Bassellier, Reich y Benbasat (2001) esta complejidad o habilidad de competencia es utilizada de diferentes formas; y en el contexto de TI, el administrador de TI deberá ser capaz de identificar competencias que le permitan identificar nuevas tecnologías y oportunidades de utilización de las mismas para obtener mejores rendimientos.

En el terreno de TI, Sambamurthy y Zmud (1994) definen la administración de competencias de TI como las capacidades, habilidades y el conocimiento técnico tácito que una organización desarrollo en cierto plazo.

Hasta este punto, es claro, como menciona Maaikel Klein Klouwenberg et al. (1995) que se requiere de una arquitectura de tecnología de información para redefinir los procesos de negocio, o cambiarlo con la finalidad de obtener mejoras en su desempeño. Dicha arquitectura puede ser interpretada también como infraestructura, cuyo objetivo es el mismo, integrar datos, redes, aplicaciones, dispositivos de hardware y demás recursos con los que cuentan las organizaciones, de acuerdo a lo establecido por Lewis y Byrd (2003), quienes definen Infraestructura de Tecnología de Información (ITI) como recursos de TI compartidos tales como: hardware, software, tecnología de comunicaciones, datos, aplicaciones base y prácticas que proveen una base tecnológica única para diseñar, desarrollar, mantener, implementar y administrar aplicaciones de negocio.

Por otra parte, Maaikel Klein Klouwenberg et al. (1995) dice que la ITI es la implementación tanto de la arquitectura de negocios como de la arquitectura de TI.

Las infraestructuras proveen arquitecturas y plataformas para nuevas aplicaciones y nuevos negocios, por ejemplo lo que sucede con el Internet como plataforma para el comercio electrónico (Ciborra y Hanseth, 1998).

2.3 ARQUITECTURA DE NEGOCIOS.

con la arquitectura de tecnología, deben involucrarse más temas relacionados a la misma (Herman, 2001).

Pereira y Sousa (2004) mencionan que una arquitectura de negocio es el resultado de la definición de las estrategias del negocio, procesos y requerimientos funcionales, y que ésta es la base para la identificación de requerimientos de los sistemas de información, los cuáles soportan las actividades del negocio.

Herman (2001) en su investigación comenta que una arquitectura de negocio y una arquitectura tecnológica pueden alimentarse mutuamente, por ejemplo, conociendo el potencial de la automatización y el apalancamiento de información integrada que la TI puede traer consigo, afectará las decisiones sobre la arquitectura de negocio, similarmente, muchas políticas del negocio y ediciones gubernamentales afectan el desempeño y administración de la tecnología.

Una arquitectura de negocio provee una vista múltiple de los componentes clave de la organización. Esta es el puente entre el gap de los intentos de estrategias de negocio y la capacidades requeridas en el mundo real para entregar un mejor desempeño, procesos, roles y comportamientos de las dimensiones de la información. La arquitectura de negocio permite examinar las interacciones que hay en la organización (Wolfenden y Welch, 2000).

Hamza, H. S. y Fayad, M. E. (2005) argumentan que cuando una arquitectura de negocio cambia, sus estructuras y elementos lógicos también pueden cambiar. Entre los aspectos cambiables en la arquitectura están las reglas de negocio; que cuando los objetos del negocio cambian, se actualizan o eliminan, las reglas de negocio relacionadas a estos deberían de cambiar por consiguiente para evitar inconsistencia en la lógica de negocio y así evitar desastres a causas de ellas.

Una arquitectura de negocio inicia con una visión de el un posicionamiento estratégico a futuro y la competitividad imperativa asociada, después viene una articulación de principio y políticas de alto nivel que pueden ser aplicadas en una amplia variedad de situaciones. Mientras que la arquitectura de negocio tendrá provisiones generales, debe tenerse una dirección clara y prácticas de negocio específicas, como el cómo manejar la información compartida con los socios externos, quien puede contratar un proveedor de servicios externo (outsourcer) o que clase de modelos de negocios son aceptados (Herman, 2001).

Por su parte, Zachman (1999) menciona que la definición de arquitectura depende del rol que tenga uno dentro de la empresa o sobre lo que se está trabajando. Esto se ve reflejado en la tabla 2.1:

Si usted es: Entonces probablemente piense en arquitectura como:

Datos

Analista Diagrama de flujo de datos

Planeador Combinación de diagramas entidad/relación o diagramas de flujo funcionales.

Administrador de

Comunicaciones Infraestructura de logística de negocio o arquitectura de sistemas distribuídos Administrador de

Operaciones Arquitectura de sistemas Administrador de Red Arquitectura de Red Representante de soporte de

programas Datos detallados y descripción de programas Diseñador de computadoras Lenguaje máquina

Presidente Clases de entidades, clases de procesos, o mapa

Tabla 2. 1 Ejemplo de descripciones detalladas

2.4 FRAMEWORKS Y ARQUITECTURAS DE EMPRESAS.

2.4.1 Definiciones.

El punto principal de cualquier framework es definir los requisitos relevantes del negocio que se aplican a la evolución de la arquitectura. (Whitman, Ramachandran y Ketkar, 2001). En su investigación Whitman et al. (2001) comentan que de acuerdo a lo propuesto por Inmon, Zachman, y Geiger (1997), el framework como aplicado a la empresa es simplemente una estructura lógica para clasificar y organizar la representación descriptiva de una empresa que es significante para el administrador de la empresa así como para el desarrollo de los sistemas de la empresa.

Comúnmente, un framework tiene dos definiciones en relación a las empresas, la primera definición menciona que el framework es una estructura primitiva, esto es, el inicio de la arquitectura en sí, haciendo una analogía con los fundamentos y la estructura de la construcción de una casa; la segunda definición indica que el framework funciona como una modelo de referencia, o sistemas para describir toda la arquitectura (Miller y Berger, 2001).

Para algunos, una arquitectura de empresa es un modelo gráfico que define en cuidadoso detalle una serie de componentes tecnológicos y de negocio; para otros, es el software actual, un componente de hardware, etc. (Bolles, 2004).

Una arquitectura de empresa puede ser definida como un conjunto estructural de “modelos” que representan bloques invariantes de la construcción de toda la empresa. La arquitectura puede ser considerada como la base para el diseño e implementación de todo el sistema de la empresa, así, la arquitectura es una estructura o framework que muestra la interrelación de un gran número de diferentes y separados modelos que describen partes del sistema o sus funciones (Bernus et. al., 1996).

En conclusión a la definición de una arquitectura de empresa se requiere del desarrollo de 3 cosas:

1. Una foto clara de qué existe hoy

2. Una visión de qué es lo que debería existir mañana 3. Una forma (road map) de cómo llegar a esa visión.

Una arquitectura de empresa es fundamental para permitir la asimilación de cambios internos en respuesta a la dinámica y a las incertidumbres externas de la información (Whitman et. al., 2001). Una arquitectura de empresa también define un lenguaje consistente para describir el negocio, la información de la organización y la tecnología usada para crear, administrar y distribuir esa información; aunado a esto, las arquitectura de empresas pueden proveer una disciplina para ayudar a controlar los costos de TI, soportar la toma de decisiones y consolidar los recursos de TI, haciendo así una mejor escalabilidad de la TI a la demandas de crecimiento del negocio (Bolles, 2004).

Ambler Scott W. (2002), mencionado en Pereira y Sousa, 2004, comenta que algunas veces el término de arquitectura de empresa se refiere al grupo de personas que son responsables de modelar y documentar la arquitectura, en otras ocasiones, el término denota los procesos de hacer este trabajo, pero comúnmente cuando nos referimos a la arquitectura de empresa, nos referimos a los modelos, documentos e ítems reutilizables que reflejan la arquitectura actual.

Figura 2.1 Relación de Arquitecturas (EACommunity mencionado en Pereira y Sousa, 2004)

La Arquitectura de Negocio reflejan las definiciones de las estrategias del negocio, procesos y requerimientos funcionales; esta arquitectura es la base para identificar los requerimientos de Sistemas de Información (SI), los cuáles soportan las actividades del negocio. La Arquitectura de Aplicación provee un modelo focalizado en el desarrollo y/o implementación de aplicaciones que cumplan con los requerimientos del negocio y asegure la calidad necesaria que cubra las necesidades del negocio. La Arquitectura de Información describe los datos físicos y aspectos lógicos, esta arquitectura es resultado de la modelación de la información que es necesaria para soportar los procesos y funciones del negocio de la empresa. Respecto a la Arquitectura Técnica, ésta provee la base que suporta las aplicaciones, datos y procesos de negocio identificados en los niveles anteriores; aquí se identifican y planean servicios computacionales que forman la infraestructura tecnológica de la empresa. La Arquitectura de Producto es un subconjunto de la Arquitectura Técnica, ésta identifica estándares y configuraciones para integración o adaptación de tecnologías y productos dentro de la Arquitectura Técnica (Pereira y Sousa, 2004).

Una arquitectura de empresa es una herramienta que puede ser usada para desarrollar un método estándar para analizar el sistema en el cual opera la empresa en un rango amplio (Whitman et. al., 2001).

Anaya y Ortiz (2005) en su investigación comentan que las arquitecturas de empresa tienen dos usos principales:

2. Herramienta de administración. Después de una fase de ingeniería, el administrador podría visualizar las relaciones entre cualquier artefacto que se encuentre en cualquier nivel de la arquitectura, por lo que es necesarios que se haya previsto las relaciones entre las diferentes arquitecturas y los artefactos u objetivos contenidos en la misma.

2.4.2 Diferencia entre un framework y una arquitectura.

Arquitecturas y frameworks son comúnmente muy usado en la definición de modelos de empresas, esto es, porque estos términos se encuentran altamente inter vinculados y son ambiguos. Los frameworks definen la visión arquitectural que demuestra la respuesta a los requerimientos de la empresa, los cuáles están basados en las metas del negocio y los recursos estratégicos de la organización, con esto se definirá una arquitectura para un propósito específico y acelerar su desarrollo (Whitman et. al., 2001).

Las arquitecturas ayudan a construir el sistema de la empresa de tal manera que apunte al sistema final, mientas que un framework construye la definición de varios puntos de la organización de tal modo que ayude en la construcción y definición de la arquitectura. Una arquitectura provee una imagen más amplia de toda la empresa completa tomando en consideración todas las vistas posibles, integrándolas para proveer una imagen más grande de tal forma que permita a la empresa alcanzar sus metas. Cabe resaltar que un framework es más enfocado, en comparación con la arquitectura, y generalmente es usando cuando se aplica a industrias o sectores particulares (Whitman et. al., 2001).

2.4.3 Frameworks, Arquitecturas y Modelos de Referencia.

Los modelos de referencia son una útil idealización de la realidad que filtran detalles irrelevantes y representan sólo la información esencial para las tareas. Como tal, el principio básico de la Modelación de Integración de Empresas es producir “metamodelos” de las empresas para así poder ser utilizados para integrar procesos de negocio, aplicaciones de software, sistemas de información, recursos físicos y modelos empresariales. Existen frameworks y arquitecturas que fueron diseñadas para proveer las capacidades de modelación de empresas.

Un sistema puede ser formalmente descrito usando una arquitectura, la cuál está hecha de pequeños bloques que definen el sistema completo. (Whitman et. al., 2001).

completamente los componentes de la empresa de forma que resuelva las necesidades del negocio.

Diferentes modelos de referencia, frameworks y arquitecturas han sido desarrolladas para ser usadas en sistemas de información y desarrollo de sistemas de manufactura. Los modelos de referencia proveen una representación general de diferentes aspectos de un sistema; estas representaciones pueden ser referenciadas para asistir el desarrollo de sistemas durante varias etapas de su ciclo de vida (Molina, A. y Bell, R., 2002).

Whitman et. al. (2001) citan que un modelo es un a representación abstracta de la realidad. Detalles que son innecesarios no son incluidos como la regla de la mayoría de los esfuerzos de modelar. Ellos definen el modelo de empresa como una representación simbólica de las empresas y las cosas que está relacionadas, incluyendo representaciones de hechos individuales, objetos, y las relaciones que ocurren dentro de la empresa para que sean fáciles de entender.

Los modelos fueron desarrollados para resolver preguntas específicas de una empresa, sin embargo, múltiples vistas proveen una imagen clara de la empresa y múltiples vistas son útiles para resolver múltiples preguntas (Whitman et. al., 2001).

La terminología, metodología y estándares usados en un modelo de referencia determina su estructura y contenido. Estos modelos de referencia deben hacer uso de una ampliamente aceptada terminología para permitir su fácil identificación e interpretación de las estructuras y contenidos (Molina et. al., 2002).

Integración de empresas puede ser definido como la coordinación de operaciones de todos los elementos de trabajo que realiza juntos una empresa para alcanzar un nivel óptimo de satisfacción de la misión de la empresa que ha sido definida por los administradores de la empresa, y al decir todos, se habla de la dirección, control y función de la información que permite a los recursos humanos y equipo involucrados en la empresa para realizar sus actividades (Williams, Rathwell y Li, 1996).

cómo estas puede ser ejecutadas eficientemente usando los recursos de la empresa (como son los recursos humanos, aplicaciones y recursos físicos) dependiendo de la disponibilidad y de las condiciones (Lim, Juster, y Pennington, 1997).

El primer paso del procesos de integración de empresas es desarrollar un modelo empresarial, este es un proceso de producción abstracta acerca de las funciones de negocio de la empresa, datos del negocios, ciclos del negocios en sí como cualquier otro modelo que sea útil para describir los estados de al empresa, lo cuál puede involucrar mezclar diferentes lenguajes, métodos y herramientas. El objetivo de un modelo empresarial o modelo de empresa es proveer las bases para un entendimiento común de las operaciones y recursos del negocio entre aquellos que llevan a cabo las funciones del negocio y los modeladores de la empresa; desde este modelo validado, la eficacia de las operaciones de la empresa puede ser analizadas y determinada por métodos para integración de empresas (Lim et. al., 1997).

Las arquitecturas de empresas deben ser evaluadas desde el nivel más alto, de dónde provienen los cambios a los cuáles se deben de ajustar los recursos de la empresa. Las estrategias de la empresa deben verificarse constantemente, pues de ellas parte la alineación de estos recursos como lo es la tecnología. La primera arquitectura que debe ser examinada es la arquitectura de negocio, la cuál es la única arquitectura que realmente decide si el cambio en la arquitectura de empresa valdrá la pena en términos de retorno de la inversión o en términos de beneficios; la segunda arquitectura a ser analizada será la de procesos, cambios en la tecnología generalmente implica cambios en la forma en cómo se llevan a cabo los procesos, lo que implica también nuevo conocimiento de esta tecnología, y en especial por parte de aquellos que harán uso de la misma, lo cual se traduce nuevamente en costos, pues deberán pagarse nuevos cursos o entrenamientos; por último, la tercer arquitectura que debe considerarse es la relacionada a los recursos de información. Información y Tecnología de Información son intrínsecamente modulares y adaptables, lo cuál hace a esta arquitectura como la más capaz de integrarse y trabajar con las otras arquitecturas (Miller y Berger, 2001).

primero análisis en el campo de arquitecturas, la IFAC/IFIP Task Force on Architecture for Enterprise Integration (Task Force, 1993) encontró que existían tres principales arquitecturas que podría ser clasificadas como Arquitectura de Tipo 2: CIMOSA, GRAI-GIM y PERA (Molina, Sanchez, & Kusiak, 1998).

2.4.3.1 PERA (Purdue Enterprise Reference Architecture)

PERA (Purdue Enterprise Reference Architecture) fue originalmente desarrollado para facilitar la preparación del Manual de Procedimientos de Implementación para el Desarrollo de Planes Maestro para Manufactura Integrada por Computadora por el Consorcio Industrial de la Universidad de Purdue para CIM. El resultado de la metodología puede ser presentado empezando de la siguiente forma (Bernus et. al., 1996):

1. La metodología usa PERA como el patrón y el modelo de referencia para todos los programas.

2. Usa PERA como la base para muchos de los datos iniciales y análisis funcionales de información necesarios.

3. Usa el Manuel de Implementación de Procedimientos para ayudar a programar fechas y definir el trabajo a realizar y enseñar el cómo del Plan Maestro.

4. Como parte del esfuerzo del plan maestro, la metodología desarrolla un programa de propósitos del CIM el cuál es un conjunto de proyectos, con las capacidades de recursos de la empresa en términos de mano de obra y capital, tomando en consideración las recomendaciones del Plan Maestro. 5. Estos proyectos entonces son implementados por la Empresa, como

recursos permitidos, siguiendo las recomendaciones del Plan Maestro en cada caso, con el conocimiento de que al completar este el proyecto de integración será completado también.

Bernus et. al. (1996) comentan que PERA es una estructura que se extiende de arriba hacia abajo representando la historia de vida del proyecto de integración de la empresa desde su concepto inicial a través de la etapa de análisis funcional, diseño o especificación funcional, diseño detallado, construcción e instalación para operar y finalmente la obsolescencia. Los bloques que constituyen el modelo proveen información importante indicando el trabajo que será hecho en cada paso o bloque en el desarrollo del sistema CIM (Computer Integrated Manufacturing). PERA ve la empresa desde tos puntos de vista diferentes a los comunes, los ve como que los ambientes de negocio vistos como los usuarios del negocio y los recursos de la empresa (tecnología de campo del esfuerzo y tecnología de información).

2.4.3.2 CIMOSA (CIM Open System Architecture)

La meta principal de CIMOSA es soportar la modelación orientada a procesos de empresas manufactureras y proveer soporte para operaciones de sistemas de empresa basados en estos modelos (Molina et. al., 1998). El trabajo de CIMOSA (Computer Integrated Manufacturing Open Systems Architecture) promueve cuatro vistas: Función, Información, Recursos, y Organización (Delen, Dalal y Benjamin, 2005). El punto principal de CIMOSA es proveer una arquitectura de sistemas abierto para soportar la integración de los componentes del sistema de Manufactura Integrada por Computadora (CIM - Computer Integrated Manufacturing), con este fin, CIMOSA provee una integración de infraestructura y modelos de referencia (Kumar, Karunamoorthy, Roth y Mirnalinee, 2004).

Por otra parte, CIMOSA no intenta proveer una arquitectura estándar para ser usada por toda la industria manufacturera, pero en ocasiones de esta arquitectura de referencia parten arquitecturas particulares puede ser derivadas de la misma y que cubrirán las necesidades de una empresa en particular (Bernus et. al., 1996).

CIMOSA está estructurado en una arquitectura genérica y un nivel parcial de modelación, cada uno de estos soporta diferentes vistas de la empresa. Este concepto de vistas permite trabajar con un sub-conjunto de modelos a diferencia de otros frameworks que trabajan con el modelo completo, de esta forma, se reduce la complejidad para el área en particular que nos concierne. Este modelo puede iniciar en cualquiera de los ciclos de vida o fases y puede ser repetido si es necesario, esto dependerá de la intensión del modelador, y de la misma forma el indicará que fases o ciclos de vida serán utilizados (Molina et. al., 1998)

CIMOSA soporta nuevos paradigmas en administración de empresas, así que permite la descripción explícita de procesos de empresa a diferentes niveles de abstracción para el uso de estrategias y soporte de decisiones tácticas y operacionales. Por lo tanto, implementar CIMOSA nos da como resultado una completa descripción de los dominios de la empresa y de sus procesos de negocio contenidos, incluyendo sus relaciones con agentes externos (como proveedores, clientes, gobierno, etc.). CIMOSA provee los constructores necesarios para permitir estas vistas múltiples a ser creadas y manipuladas por los usuarios quienes tienen conocimiento específico de su campo en particular pero que no sean expertos en tecnología de información (Bernus et. al., 1996).

2.4.3.3 Zachman (IBM Architecture)

Arquitecturas de Sistemas de Información incluyendo todos los aspectos de una arquitectura de sistemas de información, desde las estrategias de negocio de alto nivel hasta la codificación de sistemas (Schoch y Laplante, 1995).

Este framework fue formalmente publicado en 1987, destacó por ser descrito como una arquitectura que representa los artefactos de los sistemas de información, proveyendo un aseguramiento de la existencia de estándares para crear ambientes de información existentes apropiadamente integrados. En este framework la arquitectura es descrita a través de dos aspectos independientes, los renglones representan las diferentes perspectivas que pueden ser usadas para ver el negocio, una situación, una oportunidad o un sistema, y, las columnas representan las diferentes dimensiones en las cuáles se aplica cada una de las perspectivas de negocio, situación oportunidad o sistema (Pereira y Sousa, 2004).

El modelo de Zachman describe los entregables de un proceso de ingeniería de software. Él identifica dos tipos diferentes de representación, la cual, cuando es combinada, describe la naturaleza y propósito de estos entregables dentro del contexto de la organización (DJ de Villiers, 2003).

El Framework de Zachman está compuesto por cinco roles, los cuáles son similares a los roles de un diseño arquitectónico. Los roles o perspectivas están representados en los renglones del Framework y son (Steinke y Nickolette, 2003):

1. Planeador, enfocado al alcance,

2. Propietario, enfocado a los entregables,

3. Diseñador, enfocado a las especificaciones y lo esperado por el propietario, 4. Constructor, enfocado en la producción y ensamblaje del producto,

5. Subcontractista, enfocado en crear componentes reutilizables de acuerdo a las especificaciones del constructor.

El Framework trata de resolver seis preguntas básicas que apuntan hacia dimensiones o abstracciones específicas. Esta correlaciona las seis interrogantes y son representadas en las columnas de la matriz, dichas preguntas son (Steinke y Nickolette, 2003):

1. Datos, ¿cómo? 2. Función, ¿qué? 3. Red, ¿dónde? 4. Personas, ¿quién? 5. Tiempo, ¿cuándo? 6. Motivación, ¿por qué?

una. Una imagen completa del Framework está en el sitio Web de Zachman (http://www.zifa.com/).

Figura 2.2 Simplificación del Framework de Zachman (Steinkey y Nickolette, 2003)

El Framework de Zachman ciertamente es el modelo de referencia más conocido en el contexto de Arquitectura de Empresa, la razón de que su uso sea tan extenso es que es un marco muy flexible, no impone métodos y no restringe a ningún usuario a un sistema de artefactos predefinidos (Pereira y Sousa, 2004).

2.4.3.4 GERAM (Generalizad Enterprise Referente Architecture and Methodology)

En 1990 fue formada la IFAC/IFIP Task Force on Achitectures on Enterprise Integration. La misión de la Task Force fue seleccionar la mejor arquitectura de referencia (RA - Reference Arqchitecture) de los existentes para ser usado como una arquitectura sencilla universalmente aceptada en el campo de la integración de empresas. El resultado de este estudio fue GERAM (General Enterprise Reference Architecture and Methodology) (Carrasco, Galeano y Molina, 2004).

En 1998 fue propuesto el Generalized Enterprise Reference Architecture and Metodology (GERAM) como un framework para describir los componentes necesitados en todos los tipos de ingeniería de empresas y en los esfuerzos de integración de empresas. GERAM es una arquitectura genérica, por lo que puede ser usada en diferentes tipos de empresas e inclusive proyectos. (Denle et. al., 2005).

GERAM cuenta con ocho fases que cubren el ciclo de vida completo de una entidad. Estas fases son (Molina A. y Carrasco R., 2003):

• Identificación.

• Conceptualización.

• Requerimientos.

• Diseño preliminar.

• Implementación.

• Operación.

• Desarme.

2.4.3.5 FEAF (Federal Enterprise Architecture Framework)

El gobierno de los Estados Unidos de América ha reconocido la importancia de establecer una manera uniforme de especificar y desarrollar tecnología de información a través de oficinas federales, con este fin, ha creado su propio framework de arquitectura de la empresa. Este framework es usado para promover desarrollos compartidos para procesos federales comunes, interoperabilidad, y compartir información a través de las agencias de el gobierno federal y otras entidades de gobierno (Miller y Berger, 2001).

Este framework surge de la necesidad que tuvieron las agencias federales para desarrollar un acercamiento comprensivo para administrar la adquisición, uso y disposición de la TI; entre otras cosas, la legislación ayudó a los Gerentes de Información (Chief Information Officers - CIO’s) responsables de la agencia facilitar el mantenimiento y desarrollo de una “sonada e integrada arquitectura de TI”. La U.S. Federal CIO Council desarrolló el FEAF (Federal Enterprise Architecture Framework; ver www.feapmo.gov) en 1999 como parte de una iniciativa para promover el compartir desarrollos para diferentes agencias de gobierno de Estados Unidos de América. Este framework está compuesto de 3 partes: el framework, el modelo de referencia técnico y la matriz, la cuál tiene su origen del Framework de Zachman en el nivel de la matriz.

La relación entre el framework, la matriz y el modelo de referencia técnico no son bien definidos, y la orientación promete un proyecto a favor de la arquitectura (Lapkin Anne, 2004).

2.4.4 Beneficios de utilización de arquitecturas de empresas.

Anaya y Ortiz (2005) en su investigación mencionan los siguientes beneficios de usar una arquitectura de empresa:

• Documentos de la empresa disponibles fácilmente.

• Capacidad para unificar e integrar procesos de negocios en la empresa.

• Capacidad para unificar e integrar datos de la empresa y vincularlos con socios externos.

• Incrementar la agilidad de cambios del negocio.

• Tener una visión del negocio común y comunidades de TI.

Por su parte, Pereira y Sousa (2004) mencionan que unas de las ventajas de las arquitecturas de empresa son:

• Actúa como una forma de pasar del caos y desacuerdos a un orden y estructura,

• Permite una visión integrada y perspectivas de metas de los recursos de información,

• Permite describir y eliminar redundancia en procesos de negocio reduciendo la complejidad de los sistemas de información,

• Contribuye a tener sistemas de información que reflejen metas comunes y métricas de desempeño de todos los administradores, para asegurar la cooperación en lugar de conflictos, y las competencias dentro de la organización, y

• Llega a ser el puente entre los dominios del negocio y la tecnología.

2.4.5 Cómo seleccionar un framework.

Lo primordial a considerar en la elección de un framework son los involucrados y el dominio de la organización, pues uno de los usos fundamentales de una descripción de una arquitectura es tener comunicados a los involucrados o stakeholders, pues las diferentes vistas de la arquitectura proveen información que los stakeholders necesitan de manera que ellos puedan asimilar y usar. A pesar de que existen diferentes frameworks que comparten objetivos y características similares, es relevante entender las similitudes y diferencias de cada uno, para así, poder encontrar el adecuado para dar solución a los problemas localizados; por lo tanto si un framework tiene la mayoría de estas cosas que uno necesita, pero algunas fallas en otras, podremos agregar otras opciones de otros frameworks para poder entender y seleccionar la mejor o mejores opciones para la construcción de la arquitectura (Lapkin Anne, 2004).

Lapkin (2004) en sus investigaciones analizó diferentes frameworks evaluando los siguientes puntos:

• El framework debe ser consistente y estructurado.

• La construcción del framework debe hacerse de arriba a abajo de manera simple y natural.

• El framework debe incorporar una variedad de constructores y múltiples niveles de abstracción.

• El framework debe definir un proceso para desarrollar la arquitectura.

• El framework debe describir las “cosas” que serán producidas.

Uno de los frameworks analizados por Lapkin (2004) fue el de Zachman, del cuál comenta que es discutiblemente el más comprensivo, en términos que es difícil de imaginar una "cosa" que no es, de alguna manera, incluido. Sin embargo, uno podría argumentar que el framework es muy comprensivo y que la cantidad de esfuerzo requerido para llenar todas las celdas es más de lo que muchas organizaciones pueden aceptar. Muchos autores en sus investigaciones recomiendan que sólo deban ser llenadas las celdas relevantes y necesarias para cada organización. Como conclusión de su investigación, los resultados de la evaluación del framework se aprecian en la figura 2.3:

Figura 2.3 Resultados de la investigación de Lapkin al Framework de Zachman

Por su parte, O'Rourke, Fishman y Selkow (2003) mencionan que el Framework de Zachman puede ser usado para organizar simples piezas de información. Sin embargo, puesto que más temas y acciones en una organización hoy en día son altamente complejos, los beneficios de usar un framework pueden ser más claros cuando se aborden temas complejos. Los temas complejos requieren de arquitecturas, y por tanto los siguientes argumentos tratan la necesidad de las arquitecturas de empresas:

• Primer argumento. La clave del manejo de la complejidad y cambios es la arquitectura, es decir, si lo que uno quiere construir es demasiado complejo que no se puede recordar todo al mismo tiempo, se debe escribir o almacenar. Guardar información es la base para el desempeño de una arquitectura. Por otra parte, cuando se quieren realizar cambios a lo que se ha construido, se debe empezar por revisar que sea ha escrito. La documentación es la base para la administración del cambio. En la era de la información, se crean una arquitectura de empresa porque las organizaciones han llegado a incrementar la complejidad y demanda constante de cambios.

• Tercer argumento. Se puede utilizar el framework para ayudar a pensar, razonar y comunicar cualquier cosa, una empresa entera, o sólo una porción de la empresa.

• Cuarto argumento. Las definiciones son importantes para la arquitectura, por lo cual se debe asegurar el significado contextual de los datos o información. Analizar cosas que parecen estar claras y consistentes puede producir anomalías y errores. La arquitectura puede ayudar a superar el deshacer y volver a empezar nuevamente.

• Quinto argumento. El framework no indica que para cada artefacto debe ser producido un nivel suficiente de detalle antes de que la empresa inicie su operación o funcionamiento. Sin embargo, se debe tener en cuenta que cualquier cosa no explicitada es implícita, y que implícito es asumir; por lo tanto, asumir implica que se acepta correr el riesgo que todo o parte del trabajo deba ser desecho y reiniciado.

• Sexto argumento. Cuando un objeto no es producido de una perspectiva de la empresa, la organización es inhibida en su habilidad para compartir y ser consistente con la información, procesos, redes, flujos, calendarios y reglas. La desintegración es una causa de la administración frustrada.

• Séptimo argumento. Si no se observan los principios de diseño de la ingeniería relacionada a los artefactos de las celdas, no se podrá realizar el diseño de objetivos de alineamiento, integración, flexibilidad, interoperabilidad, reducción de tiempo de ventas, calidad, adaptabilidad, amigable con el usuario, utilidad, y reutilidad.

• Octavo argumento. Si la empresa no puede encontrar, compartir y reutilizar los artefactos de las celdas, sólo se puede operar en modo made-to-order (hecho a la medida). La meta de cada organización es crear productos y servicios basados sobre masas personalizadas (mass customization) de uno, es decir, la organización opera usando un paradigma de ensamblado a la orden (assembled-to-order).

• Noveno argumento. Si no se están construyendo, almacenando, gestionando y cambiando modelos primitivos, no se está creando una arquitectura, sino se están creando implementaciones.

• Décimo argumento. Estadísticas provistas por el Zachman Institute for Framework Advancement indican que desarrollar software basándose en la arquitectura de empresa en lugar de hacerlo de forman tradicional produce aplicaciones empresariales diez veces más baratas y seis veces más rápidas. La arquitectura de empresa está basada en la idea de que algo debe ser analizado antes de ser manufacturado e implementado.