BIBLIOTECAS DEL TECNOLÓGICO DE MONTERREY
PUBLICACIÓN DE TRABAJOS DE GRADO
Las Bibliotecas del Sistema Tecnológico de Monterrey son depositarias de los trabajos recepcionales y de
grado que generan sus egresados. De esta manera, con el objeto de preservarlos y salvaguardarlos como
parte del acervo bibliográfico del Tecnológico de Monterrey se ha generado una copia de las tesis en
versión electrónica del tradicional formato impreso, con base en la Ley Federal del Derecho de Autor
(LFDA).
Es importante señalar que las tesis no se divulgan ni están a disposición pública con fines de
comercialización o lucro y que su control y organización únicamente se realiza en los Campus de origen.
Cabe mencionar, que la Colección de
Documentos Tec,
donde se encuentran las tesis, tesinas y
disertaciones doctorales, únicamente pueden ser consultables en pantalla por la comunidad del
Tecnológico de Monterrey a través de Biblioteca Digital, cuyo acceso requiere cuenta y clave de acceso,
para asegurar el uso restringido de dicha comunidad.
El Tecnológico de Monterrey informa a través de este medio a todos los egresados que tengan alguna
inconformidad o comentario por la publicación de su trabajo de grado en la sección Colección de
Documentos Tec
del Tecnológico de Monterrey deberán notificarlo por escrito a
Modelo para la Definición de la Arquitectura de Datos de la
Empresa-Edición Única
Title
Modelo para la Definición de la Arquitectura de Datos de
la Empresa-Edición Única
Authors
Silvia Ivette Aguilar Macías
Affiliation
Tecnológico de Monterrey, Universidad Virtual
Issue Date
1999-12-01
Item type
Tesis
Rights
Open Access
Downloaded
18-Jan-2017 20:01:13
MODELO PARA LA DEFINICIÓN DE
LA ARQUITECTURA DE DATOS DE LA
EMPRESA
Tesis presentada
por
SILVIA IVETTE AGUI LAR MACÍAS
Presentada ante la Dirección Académica de la
Universidad Virtual del
Instituto Tecnológico y de Estudios Superiores de
Monterrey
como requisito parcial para optar al título de
MAESTRO EN ADM INISTRACIÓN DE
TECNOLOGÍAS DE INFORM ACIÓN
Asesor: Dr.Edgar Emmanuel Vallejo Clemente
Sinodales Lic. Horacio Echeverría Cabrera
Dr. Guillermo Rodríguez Abitia
Jurado: Dr.Edgar Emmanuel Vallejo Clemente
Lic. Horacio Echeverría Cabrera
Dr. Guillermo Rodríguez Abitia
Diciembre de 1999
DEDICATORIA
Principalmente a mis padres, que me apoyaron a terminar una etapa más en mi vida. Gracias por estar ahí todas esas veces que conté con su incondicional apoyo.
AGRADECIMIENTOS
Deseo agradecer principalmente a mis padres por su apoyo incondicional y a mi hermano M C C . Héctor Aguilar Maclas su apoyo incondicional y porque constantemente me enseña las bases del éxito y la excelencia a seguir en la vida.
Al MTIA. Daniel Peñaloza Moreno por su incondicional y constante apoyo además de sus invaluables enseñanzas de las cuales aprendí tanto a lo largo de
la maestría y que a lo largo de mi vida tendré presentes.
Al Ing. Mauricio García Tiscareño, a la Lic. Marcela San Román Manterola, al
Ing. Jorge Eliel Zarate Vázquez y al Lie Marco Tulio Martínez González, por su importante apoyo y empuje profesional además del permitirme ilustrarme con sus
enseñanzas durante mis estudios de maestría.
Al Lic. José Antonio Delgado Selley por su apoyo profesional a lo largo del
desempeño de la maestría.
A mi asesor, Dr. Edgar Emmanuel Vallejo Clemente y a mis sinodales M.A.
Juan Norberto Torres Valencia, al Dr. Guillermo Rodríguez Abitia y al Lic. Horacio Echeverría Cabrera por su paciencia, constante apoyo y dirección en la elaboración de esta tesis.
Al Instituto Tecnológico y de Estudios Superiores de Monterrey por sus
RESUMEN
M O D E L O P A R A L A DEFINICIÓN D E L A
A R Q U I T E C T U R A D E D A T O S D E L A E M P R E S A
DICIEMBRE DE 1 9 9 9
SILVIA IVETTE AGUILAR MACÍAS
LICENCIADA EN SISTEMAS DE COMPUTACIÓN
ADMINISTRATIVA
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE
MONTERREY
C A M P U S E S T A D O DE MÉXICO
MAESTRO EN ADMINISTRACIÓN DE TECNOLOGÍAS DE
INFORMACIÓN
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE
MONTERREY
C A M P U S E S T A D O DE MÉXICO
Actualmente el contar con datos que conforman información cuando se necesita, donde se necesita y en un formato utilizable, es un factor crítico de éxito
para la competitividad de la empresa. El atender estos requerimientos, forma parte de la misión del departamento de Sistemas de Información. La calidad de datos
debe planearse y la arquitectura de datos es un producto de la planeación de los datos y como cumplimiento de la misión del área de Sistemas de Información. Es de crucial importancia que los datos posean una organización común que elimine
directriz al aspecto de los datos de un sistema en la etapa de diseño, se incrementa la producción de sistemas estables.
Debido a esto, resulta relevante realizar una investigación para desarrollar un
modelo de apoyo a los analistas y diseñadores de sistemas a definir la arquitectura de datos óptima, que permita dentro de la organización, flexibilidad
ante los cambios y necesidades de la misma, asegurando la integridad de los datos a través de la organización a un bajo costo.
Basándonos en la premisa de que los métodos tradicionales de planificación de sistemas para la definición de la arquitectura tecnológica en una empresa, no
cubren con oportunidad las necesidades de las organizaciones hoy en día, debido a que inician con la determinación de hardware, para continuar con las aplicaciones que pueden ejecutarse por dicha tecnología y finalizar con el aspecto
datos; incrementando costos tanto cuantitativos como cualitativos en la obtención de información intrínseca a la competitividad de la empresa.
El desarrollo de esta tesis, busca proporcionar a las empresas un modelo para
la determinación de su arquitectura de datos base como cimiento de la arquitectura tecnológica, que permita la optimización de la modelación de sus
datos, buscando integridad y calidad de estos, diferenciando la información necesaria para los tres niveles de la organización: estratégico, táctico y operativo, proporcionando a cada uno información que se requiere, en el momento que se
ÍNDICE
ÍNDICE DE CONTENIDO
DEDICATORIA XXXII AGRADECIMIENTOS XXXII
RESUMEN XXXII ÍNDICE DE CONTENIDO XXXII
ÍNDICE DE ILUSTRACIONES XXXII
INTRODUCCIÓN 32
Objetivo y Producto Final de la Tesis 32
Organización del Documento 32
Capítulo 1 Evolución del Manejo de Datos 32 Capítulo 2 Necesidad de una arquitectura de datos 32
Capítulo 3 Fundamentos de Modelación de Datos 32 Capítulo 4 Modelo Propuesto para la Definición de la Arquitectura de Datos 32
CAPÍTULO 1 32
EVOLUCIÓN DEL M A N E J O DE DATOS 32
Datos dentro de los programas 32
Datos fuera de los programas 32
Sistemas Manejadores de Bases de Datos 32
El surgimiento del Modelo Relacional 32
Integración de Información a través de Almacén de Datos (Data Warehousing) 32
Minería de Datos (Data Mining) 32
CAPÍTULO 2 32
NECESIDAD DE UNA ARQUITECTURA DE DATOS 3 2
¿Por qué contar con una Arquitectura de Datos? 32
El Posicionamiento y la Información 32
La Misión de los Sistemas de Información en la Organización 32
Calidad de Datos 32
Reingeniería 32 Downsizing 32 Outsourcing 32 Administración de la Calidad Total (TQM Total Quality Management) 32
Integración de Bases de Datos 32 Planeación estratégica de Datos e Ingeniería de Información 32
CAPÍTULO 3 32
FUDAMENTOS DE MODELACIÓN DE DATOS 3 2
Planeación Estratégica de Bases de Datos 32
La línea de trabajo de Zachman 32
El Metalenguaje como apoyo a la Arquitectura de Datos 32
Metalenguaje KIF 32
Nivel Carácter 32 Nivel Lexema 32 Nivel Expresiones 32
Metalenguaje CES 32
Reingeniería Automatizada de Programas y Datos a Nivel Empresa Xinotech 32
ÍNDICE
Extracción de Modelos a Nivel Empresa 32 Administración Automatizada del Proceso de Reingeniería 32
Transformación Automatizada de Programas y Datos 32
Resolución de Problemas 32 Typel y el Año 2000 32 Interfaz del Usuario 32
CAPÍTULO 4 32
MODELO P R O P U E S T O PARA LA DEFINICIÓN DE LA ARQUITECTURA DE DATOS 32
Modelo Propuesto 32
Fase Planeación 32 Fase Modelación del Negocio 32
Fase Análisis Sistemas y Tecnologías Actuales 32 Fase Definición de Arquitectura de datos 32
Fase Implantación 32
Investigación de Campo 32
Personal Entrevistado 32
Visión 32 Organización 32
Conclusiones 32
REFERENCIAS BIBLIOGRÁFICAS 32
ÍNDICE
[image:11.612.110.556.89.396.2]ÍNDICE DE ILUSTRACIONES
FIGURA 1.1 DATOS COMPARTIDOS CON MÚLTIPLES SUBRUTINAS 3 2
FIGURA 1.2 DATOS LOCALES DENTRO DE SUBRUTINAS 3 2 FIGURA 1.3 U N P R O G R A M A ACCEDIENDO UN ARCHIVO 3 2 FIGURA 1.4 COMPARTIR DATOS EN UNA BASE DE DATOS 3 2 FIGURA 1.5 MODELO JERÁRQUICO DE B A S E S DE DATOS 3 2 FIGURA 1.6 MODELO RELACIONAL DE B A S E S DE DATOS 3 2 FIGURA 1.7 ALMACÉN DE DATOS (DATA WAREHOUSE) 3 2 FIGURA 1.8 ALMACÉN DE DATOS ENTRE DATOS PRE MINADOS Y MINADOS 3 2
FIGURA 1.9 L o s CUATRO ESPACIOS QUE FORMAN LA BASE DEL SOPORTE A DECISIONES 3 2 FIGURA 2.1 SISTEMAS INDEPENDIENTE CON DATOS DUPLICADOS E INCOMPATIBLES 3 2
FIGURA 2 . 2 . E L ÉNFASIS ORGANIZACIONAL ES CAMBIANTE 3 2 FIGURA 2 . 3 DATOS DEL ANÁLISIS DE LA SITUACIÓN 3 2 FIGURA 2.4 F A C T O R E S DE ÉXITO QUE CREAN LA MISIÓN DE SISTEMAS DE INFORMACIÓN 3 2
FIGURA 2 . 5 CALIDAD DE DATOS 3 2 FIGURA 2 . 6 PLANEACIÓN ESTRATÉGICA DE DATOS E INGENIERÍA DE INFORMACIÓN 3 2
FIGURA 3.1 ANALOGÍA DEL OBJETIVO DE LA PLANEACIÓN ESTRATÉGICA DE BASES DE DATOS 3 2
FIGURA 3 . 2 E J E M P L O DE MODELO DE DATOS GENÉRICO ORGANIZACIONAL 3 2 FIGURA 3 . 3 F A S E S DE LA PLANEACIÓN ESTRATÉGICA DE BASES DE DATOS 3 2
FIGURA 3.4 PUNTOS DE OPORTUNIDAD TECNOLÓGICA 3 2
FIGURA 3 . 5 LÍNEA DE TRABAJO DE ZACHMAN 3 2 FIGURA 3 . 6 E J E M P L O DE METALENGUAJE C E S EN BASES DE DATOS 3 2
FIGURA 4.1 L A DEFINICIÓN DE UNA ARQUITECTURA DE DATOS 3 2
FIGURA 4.2 NIVELES EN LA ORGANIZACIÓN 3 2 FIGURA 4.3 P R O C E S O S EJEMPLO EN CADA UNO DE LOS NIVELES DE LA ORGANIZACIÓN 3 2
INTRODUCCIÓN
INTRODUCCIÓN
Hoy en día el trabajo de todos, requiere de datos y el acceder a estos cada vez es más frecuente. Es común encontrar individuos que utilizan gran parte de su tiempo manipulando información, datos. Debido a esto, el tener la posibilidad de
obtener datos cuando se necesita, donde se necesita y en un formato utilizable, es crítico. Entendemos por formato utilizable, cuando los datos pueden ser
interpretados en información y no son datos irrelevantes. En pocas palabras, el acceder a datos es el requerimiento número uno para el logro de las metas del negocio.
Conforme una organización crece y se torna más compleja, la administración
demanda más de la función de Sistemas de Información. Requieren acceder rápidamente a los datos cuando y en donde sea necesario, en un formato
accesible, que pueda ser fácilmente interpretado, con datos correctos y consistentes, a través de cada departamento, maleables al cambio rápido y constante de las condiciones del negocio y compartidos en toda la organización.
Estos requerimientos forman parte de la misión del departamento de Sistemas de Información. Proveer datos de calidad a aquellos que lo necesitan. Sin embargo, la
calidad de los datos no emerge de la nada, tampoco resulta de enfocarse en la productividad en el desarrollo de aplicaciones. La calidad debe planearse. La arquitectura de datos es un producto de la planeación de la calidad de los datos y
INTRODUCCIÓN
Uno de los puntos primordiales, es la participación de la administración, ya que provee una perspectiva del negocio y credibilidad en el proceso de planeación. Esto es de suma importancia, ya que esta intervención es nivelada conforme se
maneja el negocio o los datos, debido a que:
• Un modelo estable (independiente de las fronteras organizacionales, sistemas y procedimientos) es el cimiento de la arquitectura.
• Los datos son definidos antes que las aplicaciones.
• La dependencia de los datos determina la secuencia de implantación de los sistemas aplicativos.
Para prosperar en una economía mundial, los negocios deben de tener la
posibilidad de ajustarse y adaptarse a los cambios rápidos. Los ejecutivos requieren de Sistemas de Información que soporten al negocio conforme este
cambia. En un ambiente dinámicamente cambiante, los usuarios no pueden permitirse el esperar seis meses, un año o más a que Sistemas de Información responda formalmente a sus peticiones. Las bases de datos deben de ser flexibles
y de fácil mantenimiento, para que rápidamente junto con las aplicaciones, permitan ajustarse a los cambios que afecten de manera directa o indirecta a la
empresa.
Actualmente los ejecutivos desean y esperan que los datos que reciben sean correctos y consistentes. Los datos deben mantener una integridad completa. No sólo deben de ser correctos dentro de una precisión aceptable, sino consistentes a
través de la organización. Para que los datos sean propiamente interpretados y combinados de distintas partes de la organización, es necesario un vocabulario
-INTRODUCCIÓN
común y una estandarización de datos. Las diferencias e inconsistencias de significados de datos en la empresa deben eliminarse. Los datos provistos, deben
de ser correctos y actualizados. Los ejecutivos reconocen que los datos deben ser compartidos a través de la organización en orden de alcanzar exitosamente las
metas de la misma. Los datos también deben compartirse entre los diferentes departamentos y las unidades de negocio, para que esto suceda, los datos deben
de existir, mantenerse, administrarse y coordinarse, en forma centralizada. Esto no implica una base de datos, aislada y no distribuida. En su lugar, es de crucial importancia que los datos posean una organización común que elimine la
redundancia y asegure la consistencia de los datos. Los ejecutivos buscan: el acceder a datos en formatos utilizables cuando y donde se requiera, la habilidad
de adaptarse a los cambios y necesidades del negocio, datos correctos y consistentes y compartir estos datos dentro de la organización, sin elevar los costos de los Sistemas de Información. Los presupuestos de varios dígitos, no son
tolerables por mucho tiempo. Los datos deben de ser provistos a un costo
accesible y razonable.
Objetivo y Producto Final de la Tesis
Por lo antes expuesto, resulta relevante realizar una investigación para
desarrollar un modelo de apoyo a los analistas y diseñadores de sistemas a definir la arquitectura de datos óptima, que permita dentro de la organización, flexibilidad ante los cambios y necesidades de la misma, asegurando la integridad de los
INTRODUCCIÓN
Organización del Documento
Capítulo 1 Evolución del Manejo de Datos
En el capítulo 1 encontraremos la evolución del manejo de datos Iniciando con el manejo de datos globales utilizados dentro de los programas en la
programación estructurada, para continuar con datos almacenados en archivos para ser utilizados fuera de los programas y tener un entendimiento del
surgimiento de los Sistemas Manejadores de Bases de Datos, contemplando el modelo jerárquico y el surgimiento del modelo relacional, con la integración de información a través de almacenes de datos., finalizando con la minería de datos
Capítulo 2 Necesidad de una arquitectura de datos.
En el capítulo 2 analizamos las razones de contar con una arquitectura de datos
en la organización, qué es lo que espera la organización de una arquitectura de datos y como cumple esta con los puntos de la misión del área de Sistemas de Información. Las estrategias que las organizaciones han considerado en los
últimos años con el objetivo de encontrar calidad de datos y que significa el obtener calidad de datos.
Capítulo 3 Fundamentos de Modelación de Datos.
En este capítulo analizamos la arquitectura de datos de la organización como
resultado objetivo de la planeación estratégica de datos y presentamos las fases
que comprende esta planeación, según William H. InmonzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Data Architecture: The
-INTRODUCCIÓN
Information Paradigm, 1992]. Con el objetivo de entender los diferentes puntos de vista de la organización en el desarrollo de arquitecturas de información,
presentamos la línea de trabajo de Zachman [1987\. Por último, el metalenguaje como herramienta de estandarización para la definición de la arquitectura de datos
de la organización, analizando KIF, C E S y la tecnología Xinotech.
Capítulo 4 Modelo Propuesto para la Definición de la Arquitectura de Datos.
En este último capítulo presentamos las fases que integran el modelo propuesto resultado de la investigación de esta tesis, incluyendo una explicación de cada una
de las fases y que aspectos se deben cubrir para la obtención de los productos finales de cada fase, haciendo referencia a los capítulos anteriores. Por último se incluyen los resultados de la investigación de campo realizada con el objetivo de
EVOLUCIÓN DEL M A N E J O DE DATOS
CAPÍTULO 1
EVOLUCIÓN DEL MANEJO DE DATOS
La mayoría de los esfuerzos para mejorar el desarrollo de software, se han enfocado en la modularización de procedimientos. Pero existe otro aspecto en el software que mientras es menos obvio, no es menos importante. Este punto lo
conforman los datos, la colección de información operada por los procedimientos. Conforme las técnicas de programación modular han evolucionado a través de los
años, también se ha incrementado aparentemente que los datos también sean modulares.
Datos dentro de los programas.
Sí un programa requiere solo algunos datos para desempeñar sus tareas, estos
datos pueden permanecer de manera segura, disponibles para todas las diferentes subrutinas que constituyen el programa. Este orden es muy conveniente para los programadores, debido a que una colección de datos compartidos,
típicamente llamado datos globales, provee una tabla boletín comunal, de la cual las diferentes subrutinas pueden intercambiar información cuando necesiten
comunicarla.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Taylor]
Cuándo el número de datos se encuentra en el rango de cientos o miles, esta solución simple, usualmente lleva a errores misteriosos y a un comportamiento impredecible. El problema es qué, compartir datos es una violación a la
-EVOLUCIÓN DEL M A N E J O DE DATOS
programación modular, que requiere que los módulos sean tan independientes
como sea posible. Permitir que los módulos interactúen libremente a través de datos compartidos, provoca que las acciones de cualquier otro módulo dependan del comportamiento de todos los demás. En efecto, los datos globales se
convierten en grietas de la armonía que la programación estructurada a creado entre las subrutinas.
La solución a este problema es modularizar los datos a lo largo con los procedimientos. Esto se realiza típicamente, dando a cada subrutina su propio
almacenamiento de datos local, de manera que por sí solo logre leer o escribir. Esta estrategia de ocultar información, minimiza interacciones no deseadas entre
EVOLUCIÓN DEL M A N E J O DE DATOS
Figura 1.2 Datos
locales dentro de subrutinas
Datos fuera de los programas.
Los programas pequeños a menudo requieren solo de algunas entradas y
generan salidas que están hechas para ser consumidas inmediatamente. Por ejemplo, un programa para calcular las tablas de amortización, posiblemente
acepte un valor base y un periodo de amortización del teclado, para después imprimir una página de cálculos. Los programas de este tipo, no necesitan almacenar datos debido a que trabajan con información fresca cada vez que se
ejecutan.
Sin embargo, los programas más grandes, usualmente trabajan con la misma
información una y otra vez. Los programas para control de inventarios, sistemas de contabilidad y herramientas de diseño de ingeniería, no pueden funcionar sí no
cuentan con una manera de preservar la información de una sesión a la siguiente.
-EVOLUCIÓN DEL M A N E J O DE DATOS
La solución más simple a este problema de almacenar información, es contar
con un programa que almacene su información en un archivo externo. Cuando el programa finaliza su ejecución, envía los datos a un archivo externo. Cuando se configura el programa nuevamente, recupera la información de un archivo. El uso
de un archivo, también permite al programa trabajar con más información que internamente podría mantener, leyendo y escribiendo una pequeña porción del archivo en cualquier momento.
Los archivos externos de datos proveen una solución adecuada para almacenamiento de información, tan larga como los datos, sí sólo es accedida por
[image:20.612.195.421.413.602.2]un usuario a la vez. Cuando los datos necesitan ser compartidos entre personas, programas o ambos, surgen nuevos problemas.
EVOLUCIÓN DEL M A N E J O DE DATOS
Sistemas Manejadores de Bases de Datos.
La mayoría de los sistemas basados en archivos no permiten que más de una persona acceda el archivo al mismo tiempo. Permitir el acceder a diferentes
personas simultáneamente, presenta la posibilidad de que una persona modifique la información que otros están actualmente utilizando. Prevenir estas confusiones resulta ser un problema técnico bastante difícil, que no fácilmente se soluciona
dentro de un sistema basado en archivos. A pesar de que algunos programas viejos continúen utilizando archivos para almacenar información compartida,
[image:21.612.84.559.384.612.2]llamados sistemas manejadores de bases de datos (datábase management systems (DBMS's)), que son diseñados para manejar simultáneamente el acceder a datos compartidos.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Object Technology: A Manager's Guide]
Figura 1.4 Compartir datos en una base de datos.
-EVOLUCIÓN DEL M A N E J O DE DATOS
Los programas de los manejadores de bases de datos hacen más que sólo
controlar el acceder a datos almacenados en archivos, también almacenan las relaciones entre los diferentes elementos de datos. El entendimiento de cómo la generación de bases de datos va y viene en un ambiente corporativo, es crítico
debido a la manera en que se almacenan estas relaciones. Los primeros DBMS's adoptaron el acercamiento de almacenar referencias directas entre los elementos
de datos, permitiendo a los datos ser recuperados a través de un proceso llamado acceso de navegación. Este acercamiento soporta extremadamente rápida recuperación de información relacionada, debido a que cada pieza de información
almacenada incluye la localización de toda la información relacionada.
Las primeras formas de manejadores de bases de datos conocidas como modelos jerárquicos, representan elementos de datos, llamados registros, en estructuras de árbol. Por ejemplo, un departamento puede incluir registros de los
puestos que contiene y del equipo. Cada posición en turno, puede ser asociada con una lista de responsabilidades y una lista de empleados en el departamento
EVOLUCIÓN DEL MANEJÓ DE DATOS
Figura 1.5 Modelo Jerárquico de Bases de Datos.
Una extensión subsecuente de un modelo jerárquico, el modelo de red, permitiendo que los datos sean interconectados libremente, sin requerimiento de
que encajen en una simple estructura de árbol. En el ejemplo anterior, cada pieza de equipo puede ser asociada con ambos, un departamento y una lista de empleados que fueron autorizados a utilizarlo. Este tipo de asociaciones no sería
permitido en un modelo jerárquico.
El surgimiento del Modelo Relacional
Los modelos de bases de datos jerárquicos y de red permitieron facilidad para representar relaciones complejas entre elementos de datos y proveyeron el acceder rápido a los datos. Sin embargo existía un costo: Acceder a los datos de diferente manera a la ya soportada por las relaciones predefinidas, era muy lento e
-EVOLUCIÓN DEL M A N E J O DE DATOS
ineficiente. Peor aún, es muy difícil modificar las estructuras de datos. Cambiar estas estructuras, requerían de que los administradores del sistema dieran de baja la base de datos y la reconstruyeran, modificando todos los programas de
aplicación que utilizaran las nuevas estructuras y entonces, traer todos los componentes del sistema en línea, simultáneamente.
El tiempo fuera de servicio creado por estos cambios era intolerable para los
usuarios que tenían que continuar trabajando sin acceder a sus datos o la habilidad de almacenar sus transacciones de negocio. Más aún, estos cambios eran mucho más riesgosos para la empresa. Un error simple en cualquiera de los
pasos podría fácilmente corromper los datos corporativos de manera que su costo fuera de millones de dólares. El efecto combinado de estos problemas era que las
bases de datos jerárquicas y de red eran raramente modificadas una vez que eran desplegadas.
Una nueva forma de manejador de bases de datos, el modelo relacional,
direccionaba estos problemas removiendo la información acerca de las relaciones complejas en la base de datos. Todos los datos son almacenados en tablas simples, mediante relaciones sencillas entre artículos de los datos que se
expresan como referencias a valores en otras tablas. Por ejemplo: cada entrada en la tabla de equipo podía contener un valor indicando a que departamento
EVOLUCIÓN DEL M A N E J O DE DATOS
también hizo posible una nueva sintaxis, el lenguaje estructurado de consulta (Structured Query Language SQL), que permitía acceder a la información en un R D B M S mediante combinaciones posibles.
A pesar de que el modelo relacional es mucho más flexible que sus
predecesores, extrae un precio inclinado debido a esta flexibilidad. La información acerca de las relaciones complejas que fue removida de la base de datos, debe expresarse como procedimientos en cada programa que acceda la base de datos,
una violación clara de la independencia requerida por la modularidad del software. El cambio de acceder por navegación a asociativo, también extrae una penalidad
seria en cuanto a desempeño, debido a que toma más tiempo localizar información relacionada buscando por contenido en lugar de brincar a una dirección calculada.
-EVOLUCIÓN DEL M A N E J O DE DATOS
Figura 1.6 Modelo Relacional de Bases de Datos
Las comparaciones han demostrado que las estructuras complejas de datos
toman de 100 a 1,000 veces más tiempo para recuperar estructuras de datos de
bases de datos relaciónales que lo que toman las bases de datos de red.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Taylor]
No obstante estos inconvenientes, la flexibilidad de las bases de datos
relaciónales a ganado la industria. A pesar de que una vasta cantidad de datos continua siendo administrada por bases de datos jerárquicas, de red y archivos estructurados, estas son herencias de generaciones previas en lugar de
EVOLUCIÓN DEL M A N E J O DE DATOS
la tecnología D B M S dominante hoy en día y virtualmente todas las nuevas aplicaciones son construidas utilizando sistemas relaciónales.
Integración de Información a través de Almacén de Datos (Data
Warehousing).
El concepto principal de almacenaje de datos es que sea más efectivo el acceder a los datos almacenados para análisis de negocio, separándolos de los
datos contenidos en sistemas operacionales. Las razones para separar los datos operacionales de los datos de análisis no han cambiado significativamente con la
evolución de los sistemas de almacenaje de datos, excepto que ahora son considerados más formalmente durante el proceso de construcción de sistemas de almacenaje de datos. Los avances en la tecnología y los cambios en la naturaleza
del negocio, han permitido que el análisis de negocios sea más sofisticado y más complejo, adicionando la producción de reportes estándares. Hoy en día los
sistemas de almacenaje de datos soportan análisis sofisticados en línea,
incluyendo análisis de datos multidimensionales.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Object Technology: A Manager's Guide]
El mantener datos dispersados a través de varias generaciones de tecnologías DBMS, presenta su propio conjunto de problemas. Es muy difícil para aplicaciones
individuales, integrar datos a través de tecnologías tan radicalmente diferentes, lo que significa que obtener cualquier punto de vista administrativo es más difícil que nunca. El acercamiento actual para la resolución de este problema es el
almacenaje de datos, una base de datos relacional que se utiliza para tomar datos
-EVOLUCIÓN DEL M A N E J O DE DATOS
seleccionados juntos de diferentes localidades de almacenaje en un repositorio con un mecanismo de acceder común. El almacenaje de datos, por sí solo, no
soluciona el problema de integrar datos de fuentes divergentes, pero permite que el problema se solucione una sola vez, utilizando procedimientos habituales para
obtener los datos juntos. Una vez que esto se ha realizado, todos los datos combinados pueden ser accedidos de manera uniforme, utilizando S Q L y otras
herramientas estándar.
Los sistemas de almacenaje de datos son más exitosos cuando se combinan datos de más de un sistema operacional. Cuando los datos necesitan tomarse de
más de una fuente aplicativa, es natural que esta integración se dé en una aplicación separada, independiente de las aplicaciones fuente. Los sistemas de almacenaje de datos permiten de manera muy efectiva, la combinación de datos
de múltiples fuentes de aplicación, tales como ventas, mercadotecnia, finanzas y producción. Muchas arquitecturas grandes de almacenaje de datos, permiten que
las aplicaciones fuente sean integradas en almacenes de datos increméntales.
La razón primaria de combinar datos de múltiples aplicaciones fuente, es la habilidad de referencias cruzadas de datos de estas aplicaciones. Todos los datos
de un Almacén de datos típico, se crean en una dimensión de tiempo. El tiempo es el primer filtro criterio para un gran porcentaje de toda la actividad realizada en un
EVOLUCIÓN DEL M A N E J O DE DATOS
posible comparar ventas del primer cuarto del año, con ventas del primer cuarto de años anteriores. La dimensión de tiempo en un almacén de datos también sirve como atributo fundamental de referencia cruzada en un almacén de datos. Por
ejemplo un analista puede analizar el impacto de una nueva campaña de mercado
accediendo las ventas de ciertos meses durante un mismo periodo. La habilidad de establecer y entender la relación entre actividades de diferentes grupos organizacionales dentro de una empresa, es continuamente citado como la mejor
característica de los sistemas de almacenaje de datos.
Los sistemas de almacén de datos son útiles, no sólo como plataformas de
fusión de datos de múltiples aplicaciones, también es posible integrar múltiples versiones de la misma aplicación. Por ejemplo una organización puede haber migrado a una nueva aplicación estándar de negocio, reemplazando un sistema
basado en mainframe. Los sistemas de almacén de datos pueden servir como una plataforma muy poderosa, para combinar datos de viejas y nuevas aplicaciones.
Diseñada de manera propia, el almacén de datos puede permitir el análisis de año
por año a pesar de cambiar la aplicación operacional base.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [The data warehouse lifecycle toolkit: expert methods for designing, developing, and deploying
datawarehouses]
La razón más importante de separar los datos operacionales de los de negocio,
es la degradación del potencial de desempeño en los sistemas operacionales, que puede resultar de los procesos de análisis. El alto desempeño y una rápida respuesta son casi universalmente críticos para los sistemas operacionales. La
EVOLUCIÓN DEL MANEJÓ DE DATOS
pérdida de eficiencia y el costo incurrido con respuestas más lentas sobre las
transacciones predefinidas son usualmente fácil de calcular y medir. Por ejemplo, una pérdida de cinco segundos de tiempo de procesamiento es quizá insignificante por sí sola, pero mezcla considerablemente más tiempo y altos
costos, una vez que se observa el panorama completo de todas las operaciones juntas. Por otro lado los procesos de análisis de negocio en un almacén de datos
son difíciles de predefinir y rara vez necesitan una respuesta rígida en cuanto a requerimientos de tiempo.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [The data warehouse lifecycle toolkit: expert methods for designing, developing and deploying data warehouses]
El almacenaje de datos es un paso razonable hacia delante, pero es una
solución que introduce problemas de sí mismo que aparentemente se han tornado dolorosos. Un problema es que la rigidez de los datos de sistema se ha
incrementado, debido a que cualquier cambio en las bases de datos locales requiere modificar el sistema de almacenaje de datos. Otra preocupación es el
aspecto tiempo. La información de un almacén de datos siempre se retrasa detrás del tiempo real de operación de datos de la empresa y este retraso difiere cuando
las diferentes bases de datos son actualizadas en momentos diferentes. El resultado es que el punto de vista administrativo de la empresa está siempre
desactualizado en un cierto grado y puede ser inconsistente temporalmente.
EVOLUCIÓN DEL M A N E J O DE DATOS
Figura 1.7 Almacén de datos (Data Warehouse)
Minería de Datos (Data Mining)
En los primeros días del data warehousing, la minería de datos era visto como un subconjunto de las actividades asociadas con el almacén de datos.
Actualmente los caminos del data warehouse y el data mining se están separando. Mientras el almacén puede ser una buena fuente para los datos a ser minados, la
minería ha sido reconocido como una tarea independiente y no más como parte de la colonia del almacén de datos.
De hecho, la minería de datos no sólo ha ganado independencia, sino que está influenciando directa y significativamente el diseño e implantación de grandes
almacenes de datos. En los primeros el paradigma de "construya un almacén primero, después mine", parecía simple e intuitivo y en muchos casos se siguió
-EVOLUCIÓN DEL M A N E J O DE DATOS
por default. Este acercamiento de "construya primero, piense después", fue realmente un paradigma de recolectores de datos, debido a que en muchos casos conducía a la construcción de recolectores de datos cuyo contenido no era
[image:32.612.95.326.223.530.2]fácilmente salvable. La mejor manera de resolver esto, es dejar el almacén de datos entre dos capas de minería, tal como se muestra en la figura 1.8
Figura 1.8 Almacén de datos entre
datos preminados y minados.
A pesar de que el almacenaje y la minería son sin duda actividades relacionadas, que pueden reforzarse una a otra. La minería de datos requiere de diferentes estructuras de datos, procesos computacionales y abastecedores a
EVOLUCIÓN DEL M A N E J O DE DATOS
cuidadosamente estos procesos y entender como difieren en orden de utilizarlos efectivamente.
El propósito de la mayoría de los almacenes de datos es unir grandes montos de datos históricos de diferentes fuentes y utilizarlas para soporte a decisiones.
Las actividades desempeñadas para grandes repositorios corporativos, son usualmente diversas, pero continuamente incluyen distintas tareas, tales como
consultas, reportes, análisis multidimensional y minería de datos. Estas tareas rompen naturalmente en grupos separados de usuarios, así como procesos computacionales distintos.
El acceder a datos y su análisis, trabajan en diferentes espacios computacionales, los cuales son "espacios derivados". El acceder a operaciones
de datos, tales como consultas y reportes, tratan con el espacio de datos, OLAP utiliza el espacio multidimensional y la minería de datos utiliza el espacio de influencia. Los cuatro espacios que forman la base del soporte a decisiones se
muestran en la figura 1.9. Estos son espacios de agregación, influencia y variación. Puede ser también utilizado un espacio basado en las relaciones
geográficas para cierto tipo de análisis.
Un almacén de datos es entonces, el espacio natural para almacenar el espacio
de datos, que es donde se almacena el nivel base de los elementos de datos que más tarde serán analizados para entregar información y justo cuando O L A P no es
-EVOLUCIÓN DEL M A N E J O DE DATOS
[image:34.612.57.544.138.420.2]visto como un esfuerzo únicamente de almacenaje, la minería de datos es donde se desempeña el análisis que trata con el espacio de influencia.
Figura 1.9 Los cuatro espacios que forman la base del soporte a decisiones
Las preguntas planteadas a estos espacios, son inherentemente diferentes.
Algunas preguntas como ¿Qué influenció las ventas?, son casi imposibles de contestar directamente en el espacio de datos. Más aún, los espacios derivados son continuamente tan grandes que los factores de influencia no pueden ser
fácilmente procesados de antemano, dentro de bases de datos también grandes. Continuamente tenemos que confiar en preprocesamientos parciales de estos
espacios, con computaciones dinámicas, con computaciones más allá de las
EVOLUCIÓN DEL MANEJÓ DE DATOS
Los espacios de datos incluyen toda la información contenida en otros espacios, pero en forma con menor refinamiento. Esto forma las bases para la derivación de los otros espacios, pero de manera menos refinada.
En el proceso de análisis, el espacio de datos continuamente necesita ser enriquecido con semántica adicional, adicionando información acerca de
jerarquías y comportamiento periódico. Esta semántica adicional va un poco más allá del modelo relacional simple, pero continuamente ayuda al usuario. De hecho, mes, trimestre, año y ciudad, estado, municipio, forman jerarquías naturales que el
modelo relacional simple ignora. Adicionando dicha semántica al espacio OLAP se provee de beneficios adicionales al usuario.
Mientras el espacio OLAP, trata con valores numéricos computados, el espacio de influencia tiene una naturaleza lógica. Este trata con la influencia de grupos
específicos de elementos en los demás. Lo que hace más interesante a este espacio es que la información que provee es mucho más utilizable que los otros
espacios, debido a que dicha información es típicamente muy general y puede ser referida como conocimiento. Desde que la información uno de los artículos más valorados en el mundo y con la complejidad incremental de la sociedad de hoy en
día, la información obtenida por la minería de datos puede ser exponencialmente más valorada que cualquier otro activo.
EVOLUCIÓN DEL M A N E J O DE DATOS
• El almacén de datos, donde la montaña de datos corporativos son almacenados en un solo lugar. Aquí los volúmenes de datos son muy altos. Estos diseños son usualmente esquemas de estrella o estructuras altamente normalizadas.
• Los mercados de datos son donde los datos departamentales son almacenados y continuamente se añaden componentes de datos. Los volúmenes de tamaño de los almacenes van de un 15% a un 30%. Estas bases de datos se basan usualmente en diagramas de estrella o están normalizados. Deben encontrarse en el espacio de datos, pero algunas veces se realiza análisis multidimensional.
• La minería de datos es donde se organizan los datos para su análisis y la información es extraída de los datos. Los volúmenes de datos son los mismos que los mercados de datos, pero los datos son ricamente más estructurados y ya no son solo departamentales. Los datos aquí se refieren a objetivos específicos del negocio y son analizados con el propósito de extracción de información.
Mientras las estructuras de datos utilizadas dentro de los almacenes y mercados de datos, son similares, las de la minería de datos son
significativamente diferentes. La minería de datos difiere del almacén de datos no solo en el tamaño que maneja, sino también en la estructura de los datos. El contenido de los datos en la minería es a menudo diferente de los datos en el
almacén, debido a que es enriquecida frecuentemente con datos externos adicionales que no se encuentran en el almacén. La llave de la arquitectura de la
EVOLUCIÓN DEL M A N E J O DE DATOS
La minería de datos puede existir en tres formas básicas:
• Arriba del almacén de datos, como un conjunto de vistas conceptuales • Junto al almacén de datos como un repositorio separado.
• Dentro del almacén de datos, como un conjunto distinto de recursos.
En algunos casos existe la minería de datos autosuficiente, esto sucede cuando una unidad de negocio dentro de una organización necesita obtener resultados del próximo trimestre, no del próximo año. Cuando toma demasiado construir un almacén corporativo, algunas organizaciones no tienen opción más que tomar el
asunto en sus manos, a menudo con resultados excelentes.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [DataMines for Data Warehouses]
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
CAPÍTULO 2
NECESIDAD DE UNA ARQUITECTURA DE DATOS
El mundo del desarrollo de sistemas ha cambiado tan rápido, como la
tecnología misma. Originalmente existía un análisis basado en requerimientos, donde dominaban los pensamientos de modelación de procesos. Fue entonces cuando iniciaron los análisis y diseños basados en datos.
Las organizaciones continuamente adquirían cierto número de computadoras y
era frecuentemente difícil transferir datos entre ellas. El tamaño y la naturaleza de los dispositivos de almacenaje disponibles, eran tal como hacer imposible el manejo de grandes bases de datos integradas. No era para sorprenderse, que el
software requerido para administrar dichas bases de datos no existía. Consecuentemente, la situación norma se presenta en la figura 2.1.
Con el desarrollo de nuevos sistemas de alto desempeño de procesamiento de transacciones en línea y el mantenimiento de sistemas viejos orientados al
procesamiento por lotes (batch), se hizo realidad el hecho de que el hacer énfasis en la automatización de un solo proceso, era incorrecta. Había mucho más en el
desarrollo del sistema, qué la especificación de código y de requerimientos. Un poco más allá, mientras los procesos tendían a cambiar con el tiempo, los datos requeridos para desempeñar esos procesos, tendían a permanecer relativamente
NECESIDAD DE UNA ARQUITECTURA DE DATOS
sistema en la etapa de diseño, se incrementa la producción de sistemas estables.
A través de los días de análisis de procesos y análisis y diseño estructurado, el aspecto completo de los datos ha sido tratado como un pensamiento final. De hecho, en los primeros tiempos del desarrollo de sistemas, se contempla a los
[image:39.612.102.532.215.460.2]datos como producto del procesamiento.
Figura 2.1 Sistemas Independiente con datos duplicados e incompatibles.
Las islas de datos existentes en muchas organizaciones, son parte de los sistemas legados que operan hoy día en la mayoría de las organizaciones que
implementaron sistemas hasta los años ochenta. De hecho a la fecha se continúa creando islas de datos. Existen numerosas consecuencias importantes de esta
herencia:
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
Datos acerca de productos, clientes y otras entidades pueden mantenerse en más de un archivo.
Puede resultar extremadamente difícil, reconciliar la información producida por varios sistemas por razones tales como:
• El uso inconsciente de códigos.
• Diferenciación de cortes y procesamientos.
• La eficiencia y efectividad de las operaciones intra e inter organizacionales son forzadas debido a las barreras resultantes del flujo ligero de datos.
¿Por qué contar con una Arquitectura de Datos?
Los crecientes problemas ocasionados por los sistemas autosuficientes y las islas de datos asociadas, llegan a ser rigurosamente aparente, desde una
consideración tipo informe de la Figura 2.2, la cual muestra el cambiante énfasis organizacional. Históricamente el comando jerárquico y control de la organización fue un lugar común, tal como se indica en la organización vertical de la Figura 2.2.
Sin embargo, dichas organizaciones son relativamente sin responsiva e inflexibles. Ahora en muchos sectores se han establecido nuevos arreglos que son mucho
más flexibles y con más responsiva a las demandas de un mercado cambiante. La figura 2.2, utiliza el término horizontal para describir una forma de dichos arreglos
organizacionales. El término red debió ser de igual manera utilizado.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Data
NECESIDAD DE UNA ARQUITECTURA DE DATOS
Un requerimiento llave de las organizaciones red, es que debe existir un flujo libre de datos a través de la organización y que a todo el personal de la organización se le debe presentar una vista consistente de la información que requieren para realizar su trabajo efectivamente. La calidad de la arquitectura de datos de la empresa y la efectividad de su implantación, determina que tan bien
[image:41.612.140.487.246.543.2]pueden fluir los datos a través de la organización.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Architecture]
Figura 2.2. El énfasis organizacional es cambiante
De tal manera la estructura de datos puede tener una influencia significante en la habilidad de la organización de ser flexible y responsiva ante las demandas de un mercado cambiante. Una estructura de datos fuerte no es suficiente por sí
misma para asegurar que una organización es flexible y responsiva, pero una
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
estructura de datos pobre, seguramente dará lugar constantemente a represiones serias en la habilidad de la organización de archivar estándares de desempeño
mundial, es parecido a hacer imposible el archivo de dichos estándares. Es por esto, que las arquitecturas de datos son importantes desde cierta perspectiva.
El paradigma de la información es la arquitectura de datos, que es el resultado de una evolución y de alguna manera, se explica así mismo, debido a que muchos
de sus componentes sobrevivientes o moldeados por la evolución, son familiares. Este resultado es una arquitectura, descrita en términos de datos, pero aplicable más allá de la narrativa de que solo los datos se ajustan a las necesidades de
información genérica y presupuestos de la empresa de manera eficiente y efectiva. Esta arquitectura de datos es el paradigma de los Sistemas de Información y la
tecnología para sistemas estables y efectivos.
El término de arquitectura de datos, se ha definido como el componente de la
línea de trabajo del recurso datos, que contiene todas las actividades y los productos de esas actividades relacionados con la identificación, nombre,
definición, estructuración, calidad y documentación del recurso datos para una empresa.
Una arquitectura de datos común, es una arquitectura de datos que provee un
NECESIDAD DE UNA ARQUITECTURA DE DATOS
necesidades de información. Los Sistemas de Información que prosperan, son
aquellos que se encuentran en armonía con la arquitectura de datos.
El departamento de defensa de los Estados Unidos de Norte América, dice qué: "Una arquitectura es definida en IEEE 610.2 como la estructura de componentes,
sus relaciones, sus principios, las guías gobernantes de su diseño y evolución sobre el tiempo". La arquitectura de datos de una empresa contiene el
procesamiento de transacciones en línea y (OLTP On-Line Transaction Processing) el procesamiento analítico en línea (OLAP On-Line Analytical Processing). Los datos de OLTP soportan las operaciones y los datos de OLAP
producen inteligencia.
Los datos y la información son activos de extremo valor a la empresa. La
arquitectura de datos, define una infraestructura para proveer datos de alta calidad y consistentes, donde se necesita y cuando se necesita. Esta infraestructura asiste de manera complementaria a los requerimientos de datos, para hacerlos
fácilmente accesibles y entendibles por usuarios finales autorizados y por sistemas aplicativos.
Los resultados de un estudio realizado por la Sociedad de Administración de Información (The Society of Information Management SIM) y el Centro de
Investigación de Sistemas de Información gerencial de la Universidad de Minnesota (MIS Research Center at the University of Minnesota), publicados en
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
Diciembre de 1991, muestran que los aspectos más importantes que enfrenta la administración de Sistemas de Información actualmente, son:
• El desarrollo de una arquitectura de información, hace efectivo el uso de datos como recurso.
• El mejoramiento de la planeación estratégica de los Sistemas de Información.
El proceso de arquitectura, inicia con un entendimiento de la empresa y de los datos que constituyen su infraestructura de información. A manera de ser más útil, los Sistemas de Información deben de derivarse de ésta base de conocimiento
acerca de la empresa.
Generalmente hablando, una arquitectura define qué es lo que se necesita, y un plan soporta cuando esta arquitectura será implementada. Las arquitecturas por si solas pueden proveer definiciones útiles y estándares, además de proveer ideas.
En cualquier compañía, negocio o industria, los ejecutivos enfrentan grandes retos para alcanzar sus metas. Sin discusión alguna, la información provee las
respuestas a las necesidades de éxito. La gente a todos niveles de la organización, necesita de información para llevar a cabo su trabajo de manera
correcta. Cuando se pregunta: Con respecto a la información,zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA ¿Qué es necesario para completar sus objetivos o realizar su trabajo? Presidentes, Vicepresidentes y
los niveles que reportan a estos, responden las siguientes cinco mismas
NECESIDAD DE UNA ARQUITECTURA DE DATOS
1. Acceder a datos en un formato utilizable cuando y donde sea necesario.
Virtualmente, el trabajo de cualquier persona requiere datos y el acceder a
estos es la requisición más frecuente. Es común encontrar individuos que gastan más del 50% de su tiempo manejando información -buscando,
encontrando, ordenando, examinando, copiando, guardando, cambiando, completando, y enviando datos. Consecuentemente, el que sea posible acceder datos cuando sea necesario, donde sea necesario y en un formato
utilizable es crítico. El que se encuentre en un formato utilizable, significa que es posible leer los datos e interpretarlos en información y no convertirlos en
datos irrelevantes. Pura y simplemente, el acceder a datos es el requerimiento número uno para alcanzar las metas del negocio.
2. Habilidad para adaptarse a las necesidades cambiantes del negocio.
Para prosperar en una economía mundial, los negocios modernos deben ser capaces de ajustarse y adaptarse rápidamente a cambios. Los ejecutivos
requieren de Sistemas de Información que soporten al negocio conforme este cambia. En un ambiente dinámico de negocios, los usuarios no pueden
darse el lujo de esperar seis meses, un año, o más a que el área de Sistemas de Información atienda de manera formal sus requisiciones. Las bases de datos y las aplicaciones que se utilicen dentro de la organización,
deben ser flexibles y de fácil mantenimiento, de manera que rápidamente sea posible acoplarse a los cambios de nuevos productos, mercados, fusiones y
adquisiciones, tecnología, regulaciones gubernamentales y cambios competitivos.
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
3. Datos Exactos y Consistentes
Los ejecutivos desean y esperan que los datos que reciben sean exactos y consistentes. Los datos deben tener una alta integridad, no solo deben ser
correctos dentro de una precisión aceptable también deben ser consistentes a través de la organización. Para datos que deben ser propiamente
interpretados y combinados en toda la organización, es necesario un vocabulario común o una estandarización de datos. Por ejemplo, suponga que el gerente divisional de una gran compañía necesita tomar una decisión
para asignar recursos de venta sobre la base de niveles de venta. El gerente podría preguntar a las cabezas de las áreas de ventas, mercadotecnia,
manufactura, distribución y finanzas,zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA ¿Cuáles son nuestras ventas? y recibiría cuatro diferentes respuestas significativas, aunque ninguna de estas
figuras de ventas sería incorrecta desde la perspectiva de la persona que
provee la información, cada uno determinó la información de manera diferente. Esto es, la palabra ventas puede tener cuatro diferentes
significados en la empresa. Estas diferencias e inconsistencias deben de ser eliminadas. Los datos provistos deben de ser exactos y sobretodo actualizados al día.
4. Compartir datos dentro de la organización.
Los ejecutivos reconocen que los datos deben de ser compartidos dentro
NECESIDAD DE UNA ARQUITECTURA DE DATOS
y coordinados en su administración. Sin embargo, este enunciado no implica una base de datos centralizada. En su lugar es crucial que los datos posean una organización común que elimine la redundancia y asegure la consistencia de los datos, donde ésta deba estar.
5. Contener Costos
Los ejecutivos desean los cuatro puntos anteriores sin escalar los costos de los Sistemas de Información. Los presupuestos de varios dígitos reservados para Sistemas de Información, no son ampliamente aceptados.
Los datos deben proveerse a un costo razonable y accesible.
A los individuos con perfil en cómputo o con experiencia práctica extensa en la utilización de sistemas procesadores de transacciones en organizaciones medianas y grandes, les es más difícil adquirir estas ideas. Sin embargo, muchos
gerentes de nivel medio alto, no tienen experiencia. Actualmente no es posible considerar, que entiendan inmediatamente el significado de la calidad de la
estructura de datos en una organización para esa habilidad de competir en los mercados globales actuales, lo que demanda incrementalmente la demanda de clase mundial de estándares de desempeño.
Las razones por las que los gerentes de nivel medio alto podrían interesarse en este tópico incluyen:
• Mejorar la eficiencia y efectividad del negocio.
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
• Habilitar una rápida respuesta a las necesidades cambiantes del negocio. • Preocuparse acerca del impacto que las estructuras de datos pobres
están teniendo en una organización y un interés en ¿cómo las oportunidades pueden maximizarse y minimizando los riesgos?
Desde la perspectiva de la administración de Sistemas de Información, las metas y los aspectos incluyen:
• Entender que información es estratégica y que información tiene un alto potencial, parecido a tornarse estratégica.
• Crear una estructura de datos estable e integra. • Mejorar la calidad de la información y los sistemas.
Estos dos conjuntos de razones para que los gerentes tomen interés en este
tópico son complementarios. Sin embargo, es muy importante para el personal de Sistemas de Información que considere el tópico desde la perspectiva generalmente de los gerentes de nivel medio alto y no lo considere desde la
perspectiva técnica.
Esto refuerza la noción implícita en otras ideas varias. La importancia crítica del trabajo en conjunto entre el personal de Sistemas de Información y los gerentes de
nivel medio alto, para identificar las oportunidades y acordar en cual es la mejor manera de asignar recursos de Sistemas de Información; En conjunto, la consideración de las estructuras de datos de una organización, siempre resultará
NECESIDAD DE UNA ARQUITECTURA DE DATOS
arquitectura. Sin embargo, los pasos de la implantación serán determinados por las prioridades del negocio.
Muchas de las organizaciones tienen un gran monto de datos variables dentro de sus sistemas, que frecuentemente no están disponibles para obtener los
valores completos de los datos, debido a que los datos se encuentran pobremente estructurados. Sin embargo, es posible obtener adicionalmente, valor significante adicional, de los datos contenidos en sistemas existentes sin remplazar estos
sistemas.
El Posicionamiento y la Información
El establecimiento de la estrategia de mercado, parte integral del posicionamiento de una empresa en el mercado, se basa en la revisión corporativa
de sus mercados (por línea de producto) y de sus capacidades, fortalezas y debilidades para competir. Las oportunidades y las acciones necesarias para
eliminar las debilidades internas y capitalizar las de la competencia se analizan frente a la información básica de los modelos de posicionamiento, para determinar fuerza e impacto. Establecer una estrategia de mercado implica tomar decisiones
sustentadas en una base amplia con relación a las posiciones que la compañía y sus productos aspiran a alcanzar en el mercado. Cuando sea necesario, esta
estrategia incluirá también las decisiones relacionadas con el desarrollo de nuevos productos.
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
En la actualidad, las decisiones corporativas para el posicionamiento en el mercado pueden tener un alcance novísimo más amplio debido a la globalización, tomando en cuenta factores como la competencia global. Las sociedades
internacionales y el desarrollo de activos internacionales. Para garantizar el
enfoque apropiado, todos los proyectos corporativos deben acceder de inmediato a la estrategia de mercado más actualizada de la compañía y a los planes individuales de mercado para cada producto y/o servicio, esto es a información. En
los niveles más bajos de los proyectos de cambio, este tipo de información debe incluirse con los detalles acerca de lo que la compañía expresa en su publicidad,
lo que está haciendo la competencia y de los cuales son las actitudes de sus clientes.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Reingeniería: Cómo Aplicarla con Éxito en los Negocios]
La etapa más sistemática del posicionamiento es la recopilación de datos. Las
clases de información reunidas por el posicionamiento y utilizadas en los proyectos de cambio, aparecen en la figura 2.1. Este es necesariamente un
proceso detallado que requiere tiempo, en especial cuando las operaciones son muy grandes y antiguas. Sin embargo, el tiempo y el esfuerzo pueden reducirse y el efecto de los datos puede aumentar mediante el empleo de tecnología.
Cualquier sistema computarizado de textos, como el procesador de palabras y los diagramas son mejores que utilizar sólo papel. Una vez que la recopilación de
NECESIDAD DE UNA ARQUITECTURA DE DATOS
[image:51.612.84.551.119.578.2]flexibilidad y apoyo con base en computadoras, Sistemas de Información, que permitan la explotación de datos.
Figura 2.3 Datos del Análisis de la Situación
La información incluida en la conformación de una arquitectura de datos, debe dirigirse a cada faceta de la operación. Deberá incluir modelos de flujo de trabajo,
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
organigramas, enunciados de la misión corporativa, modelos de proceso de negocios, política de negocios y reglas establecidas, modelos de funciones (diagramas de relación) y planes corporativos. Esta información contiene las
respuestas a los interrogantes de quien, qué, dónde, cómo y porqué.
La Misión de los Sistemas de Información en la Organización
Desde una perspectiva de Sistemas de Información, la Figura 2.4 compara los factores de éxito mencionados anteriormente a la misión de Sistemas de
Información:
5 factores de éxito listados por los ejecutivos
Misión de Sistemas de Información
a Acceder datos cuando y donde sea a Acceder oportunamente a los datos necesario. necesarios.
•
Habilidad de adaptación a las•
Sistemas flexibles y de fácil necesidades cambiantes del mantenimiento.negocio.
•
Datos exactos y consistentes•
Integridad y estandarización de datos.a Compartir datos dentro de la
•
Integración Datos/Sistemas organización.a Contener Costos. a Efectividad del costo
NECESIDAD DE UNA ARQUITECTURA DE DATOS
Estos cinco factores forman la misión de Sistemas de Información en las organizaciones. La planificación de la arquitectura de datos de la empresa, es el primer paso en la vía de logro de esta misión, y es el único tipo de proceso de planeación que a largo plazo puede alcanzar la misma.
Calidad de Datos
Sí uno pudiera utilizar una palabra que describa estos cinco componentes, sería zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA calidad. En otras palabras, proveer calidad a aquellos que la necesitan es la
misión de los Sistemas de Información. Este concepto ha sido objeto de mucha
atención; W. Edwards Deming y otros, han expuesto la longitud en la calidad y productividad del negocio.
Sí aceptamos que la misión de Sistemas de Información es proveer calidad en los datos, entonces los 14 puntos para calidad de Deming, podrían ser utilizados.
La Figura 2.5 interpreta los 14 puntos de Deming, para lograr calidad en los datos.
Un principio importante a notar es que los autores como Deming, Juran y Conway quienes escribieron acerca de calidad, han declarado que la productividad
resulta del enfoque en la calidad, pero la calidad no ocurre a través de perseguir la productividad. Esto es un punto vital porque diversas metodologías de desarrollo
de sistemas y herramientas, tales como C A S E y los productos de AD/Cycle han sido explícitamente aclamados hacia mejorar la productividad del desarrollo de los sistemas. De acuerdo a las enseñanzas de Deming, enfocándonos en la
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
productividad de los sistemas por si sola, no necesariamente resultan en la calidad de datos ni habilita la misión de Sistemas de Información
Los 14 puntos de calidad de 14 puntos de calidad de Datos
Deming
1 Crear una constancia de propósito hacia mejora (misión y plan)
Desarrollar una constancia para la administración de recursos de datos 2 Adoptar la nueva filosofía (no aceptar Administrar los datos como activo,
retrasos, defectos y errores) compromiso de compartir datos e integridad de datos.
3 Eliminar con la dependencia de inspecciones masivas (Requiere evidencia estadística)
4 Utilizar una fuente única
5 Constantemente mejorar la producción del sistema y servicio; encontrar problemas
6 Instituir métodos modernos basados en el entrenamiento del trabajo.
7 Instituir métodos modernos de supervisión.
8 Desaparecer el miedo.
Desarrollar medidas para calidad de datos.
Establecer una estrategia de
migración basada en la creación de datos (Sistemas de datos fuente) Entender el negocio (modelo funcional del negocio, planes del negocio)
Instituir programas de entrenamiento sobre Administración de datos como recurso.
Debe identificarse un líder para Administración de Datos como Recurso; promover el trabajo en equipo; eliminar los cálculos de desempeño a corto plazo.
NECESIDAD DE UNA ARQUITECTURA DE DATOS
9 Romper las barreras entre departamentos
Desarrollar modelos de negocio, arquitecturas y planes que crucen las fronteras de la organización
10 Eliminar las metas numéricas, Desarrollar estándares y forzar publicidad y axiomas para nuevos mecanismos que aseguren la calidad niveles de productividad sin métodos, de los datos.
11 Eliminar estándares de trabajo que prescriben citas.
12 Promover el orgullo de los trabajadores.
13 Instituir programas vigorosos de educación y entrenamiento.
14 Crear estructuras que empujen los 13 puntos antes mencionados.
Seguir con estándares a través del liderazgo y la responsabilidad para la calidad de los datos (proveer
incentivos de adaptación) Utilizar métodos, técnicas y herramientas para actualizar la posición de las responsabilidades. Equipo con la función o comité de aseguramiento de la calidad. La administración debe
comprometerse a estos principios de calidad de datos (establecer
administración del recurso de datos, reorganización, autorización)
Figura 2.5 Calidad de Datos
La calidad no sucede simplemente, esta debe de ser planeada y diseñada en
los productos de Sistemas de Información, de ahí que debe ser referida
propiamente como planificación para la calidad de datos.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA [Enterprise Architecture Planning: Developing a Blueprint for data, Applications and Technology]]
Algunas de las ventajas obtenidas de establecer una arquitectura de datos a
nivel empresa son:
• El enfoque es en el uso estratégico de la tecnología para la administración de datos como un activo.
-NECESIDAD DE UNA ARQUITECTURA DE DATOS
• El uso de un vocabulario estándar, facilita la comunicación y reduce la inconsistencia y redundancia de datos.
• La documentación incrementa el entendimiento del negocio.
• Los modelos pueden ser utilizados para explicar el negocio y asegurar el impacto de los cambios del mismo.
• Las políticas de toma de decisiones pueden ser revisadas. • Considera la integración de sistemas actuales con los nuevos. • Permite un acercamiento comprensivo, objetivo e imparcial.
• En cuanto a costo - beneficio, una solución a largo plazo considera la tasa de retorno.
• Involucra una estrategia de migración factible con logros a corto plazo. • Facilita el asegurar los beneficios e impactos de nuevos sistemas y
software.
• Permite el fácil acoplamiento de cambios dinámicos del negocio, tales como: fusiones, adquisiciones, nuevos productos, líneas de negocio, etc. • La participación de la administración gerencial provee la perspectiva del
negocio, su credibilidad y confidencialidad, además de eliminar el mito del desarrollo de sistemas.
En lo que se refiere a los beneficios a obtener de una planificación de sistemas,
a continuación se presenta una lista de estos:
• Más responsabilidad hacia las necesidades de los clientes. • Reducción de los costos de entrada de datos.
• Incrementa la productividad del personal, que permite incrementar el nivel de negocio y mantiene los costos.
