El modelo de arquitectura empresarial NIST ( modelo EA de NIST ) es un modelo de referencia de finales de la década de 1980 para la arquitectura empresarial . Define una arquitectura empresarial [1] por la interrelación entre los entornos de negocio, información y tecnología de una empresa. [2]
Desarrollado a fines de la década de 1980 por el Instituto Nacional de Estándares y Tecnología (NIST) y otros, el gobierno federal de los Estados Unidos promovió este modelo de referencia en la década de 1990 como la base para las arquitecturas empresariales de las agencias gubernamentales estadounidenses individuales y en la arquitectura empresarial federal general. . [2]
Intro
El modelo de arquitectura empresarial del NIST es un modelo de cinco capas para la arquitectura empresarial , diseñado para organizar, planificar y construir un conjunto integrado de arquitecturas de tecnología de la información y la información. Las cinco capas se definen por separado pero están interrelacionadas y entretejidas. [2] El modelo definió la interrelación de la siguiente manera: [3]
- La arquitectura empresarial impulsa la arquitectura de la información
- La arquitectura de la información prescribe la arquitectura de los sistemas de información
- La arquitectura de los sistemas de información identifica la arquitectura de datos
- Arquitectura de datos sugiere sistemas de entrega de datos específicos, y
- Los sistemas de entrega de datos (software, hardware, comunicaciones) respaldan la arquitectura de datos.
La jerarquía en el modelo se basa en la noción de que una organización opera una serie de funciones comerciales, cada función requiere información de una serie de fuentes, y cada una de estas fuentes puede operar uno o más sistemas operativos, que a su vez contienen datos organizados y almacenados en cualquier número de sistemas de datos. [4]
Historia
El modelo de arquitectura empresarial del NIST se inició en 1988 en el quinto taller sobre direcciones de gestión de la información patrocinado por el NIST en cooperación con la Asociación de Maquinaria de Computación (ACM), la Sociedad de Computación IEEE y el Grupo Federal de Usuarios de Gestión de Datos (FEDMUG). Los resultados de este proyecto de investigación se publicaron como la Publicación especial NIST 500-167, Information Management Directions: The Integration Challenge . [3]
El campo emergente de la gestión de la información
Con la proliferación de la tecnología de la información a partir de la década de 1970, el trabajo de la gestión de la información había tomado una nueva luz y también comenzó a incluir el campo del mantenimiento de datos . La gestión de la información ya no era un trabajo sencillo que casi cualquier persona podía realizar. Se hizo necesaria una comprensión de la tecnología involucrada y la teoría detrás de ella. A medida que el almacenamiento de información pasó a medios electrónicos, esto se volvió cada vez más difícil. [3]
Uno de los primeros enfoques generales para la creación de sistemas de información y la gestión de la información de sistemas de la década de 1970 fue el enfoque de tres esquemas . Propone utilizar tres puntos de vista diferentes en el desarrollo de sistemas, en los que el modelado conceptual se considera la clave para lograr la integración de datos : [6]
- Esquema externo para vistas de usuarios
- El esquema conceptual integra esquemas externos
- Esquema interno que define las estructuras físicas de almacenamiento.
En el centro, el esquema conceptual define la ontología de los conceptos a medida que los usuarios los piensan y hablan sobre ellos. El esquema físico según Sowa (2004) "describe los formatos internos de los datos almacenados en la base de datos , y el esquema externo define la vista de los datos presentados a los programas de aplicación ". [7]
Desde la década de 1970, el NIST ha celebrado una serie de cuatro talleres sobre las direcciones de gestión de la información y las bases de datos. Cada uno de los talleres aborda un tema específico: [8]
- "¿Qué información sobre tecnología de bases de datos necesita el administrador para tomar decisiones prudentes sobre el uso de nueva tecnología?", En 1975.
- "¿Qué información puede ayudar a un gerente a evaluar el impacto en un sistema de base de datos?" en 1977.
- " Herramientas de gestión de la información desde el punto de vista de: usos; políticas y controles; diseño de bases de datos lógicas y físicas" en 1980; y
- "La naturaleza de la práctica y los problemas de gestión de los recursos de información " en 1985.
El quinto taller en 1989 fue realizado por el Laboratorio Nacional de Sistemas de Computación (NCSL) del NIST. Para entonces este era uno de los cuatro institutos, que realizaba el trabajo técnico del NIST. El objetivo específico del NCSL era realizar investigaciones y proporcionar servicios científicos y técnicos para ayudar a las agencias federales en la selección, adquisición, aplicación y uso de tecnología informática. [9]
Taller del NIST sobre direcciones de gestión de la información
El quinto taller de Information Management Directions en 1989 se centró en la integración y la productividad en la gestión de la información . Cinco grupos de trabajo consideraron aspectos específicos de la integración de conocimientos, gestión de datos , planificación, desarrollo y mantenimiento de sistemas, entornos informáticos, arquitecturas y estándares. Los participantes procedían de la academia, la industria, el gobierno y empresas consultoras. Entre los 72 participantes se encontraban Tom DeMarco , Ahmed K. Elmagarmid , Elizabeth N. Fong, Andrew U. Frank , [10] Robert E. Fulton, [11] Alan H. Goldfine, [12] Dale L. Goodhue , [13] Richard J. Mayer , Shamkant Navathe , T. William Olle , W. Bradford Rigdon , Judith A. Quillard, Stanley YW Su, [14] y John Zachman .
Tom DeMarco pronunció el discurso de apertura, afirmando que los estándares hacen más daño que bien cuando van en contra de la cultura imperante, y que la esencia de la estandarización es el descubrimiento, no la innovación. [15] Los cinco grupos de trabajo se reunieron para discutir diferentes aspectos de la integración:
- la integración del conocimiento y la gestión de datos
- la integración de la gestión de datos técnicos y comerciales
- la integración de herramientas y métodos de planificación, desarrollo y mantenimiento de sistemas
- la integración de entornos informáticos distribuidos y heterogéneos, y
- arquitecturas y estándares.
En el tercer grupo de trabajo sobre planificación de sistemas estuvo presidido por John Zachman , y adoptó el Marco de Zachman como base para la discusión.
El quinto grupo de trabajo sobre arquitecturas y estándares estuvo presidido por W. Bradford Rigdon de McDonnell Douglas Information Systems Company (MDISC), una división de McDonnell Douglas . Rigdon y col. (1989) [16] explicó que las discusiones sobre arquitectura en ese momento se centran principalmente en preocupaciones tecnológicas. Su objetivo era "tener una visión más amplia y describir la necesidad de una arquitectura empresarial que incluya un énfasis en los requisitos comerciales y de información. Estos problemas de nivel superior afectan las arquitecturas y decisiones de datos y tecnología". [17] Para ello, el grupo de trabajo abordó tres cuestiones: [18]
- Los niveles de arquitectura en una empresa
- Problemas abordados por la arquitectura
- Beneficios y riesgos de tener arquitectura
Para ilustrar los niveles de arquitectura, se presentó lo que se conoce como el Modelo de Arquitectura Empresarial NIST (ver imagen). En este concepto, las tres capas del enfoque de tres esquemas se dividen en cinco capas.
Aplicación en la década de 1990
En cierto modo, el modelo de arquitectura empresarial del NIST se adelantó a su tiempo. Según Zachman (1993) en la década de 1980 la "arquitectura" fue reconocida como un tema de interés, pero aún existía poca teoría consolidada sobre este concepto. [19] Arquitectura de software , por ejemplo. No se convirtió en un tema importante hasta la segunda mitad de los noventa. [20]
Para respaldar el modelo de arquitectura empresarial NIST en la década de 1990, se promovió ampliamente dentro del gobierno federal de los EE. UU. Como herramienta de gestión de arquitectura empresarial. [2] El Modelo de Arquitectura Empresarial NIST se aplica como base en múltiples marcos de Arquitectura Empresarial de agencias del gobierno federal de los EE. UU. Y en el Marco de Arquitectura Empresarial Federal en general . [2] Al coordinar este esfuerzo, el modelo NIST se explicó y amplió en los "Memorandos 97-16 (Arquitecturas de tecnología de la información)" de 1997 emitidos por la Oficina de Administración y Presupuesto de los EE. UU., [21] ver más Arquitectura de tecnología de la información .
Temas del modelo de arquitectura empresarial NIST
Cimientos
Según Rigdon et al. (1989) una arquitectura es "una representación clara de un marco conceptual de componentes y su relación en un momento determinado". [22] Por ejemplo, puede representar "una vista de una situación actual con islas de automatización, procesos redundantes e inconsistencias de datos" [23] o una "estructura de información de automatización integrada futura hacia la que la empresa se moverá en un número prescrito de años. " [24] El papel de los estándares en la arquitectura es "habilitar o restringir la arquitectura y servir como base". [23]
Para desarrollar una arquitectura empresarial, Rigdon reconoce: [17]
- Hay múltiples formas de desarrollar una arquitectura.
- Hay varias formas de implementar estándares
- El desarrollo y la implementación deben adaptarse al entorno
- Sin embargo, cada arquitectura en sí misma se puede dividir en diferentes niveles.
Los diferentes niveles de una arquitectura empresarial se pueden visualizar como una pirámide: en la parte superior, la unidad de negocio de una empresa y en la parte inferior, el sistema de entrega dentro de la empresa. La empresa puede constar de una o más unidades de negocio que trabajen en un área de negocio específica. Los cinco niveles de arquitectura se definen como: Unidad de Negocio, Información, Sistema de Información, Sistema de Datos y Entrega. [23]
Los niveles separados de una arquitectura empresarial están interrelacionados de una manera especial. En todos los niveles, las arquitecturas asumen o dictan las arquitecturas del nivel superior. La ilustración de la derecha ofrece un ejemplo de qué elementos pueden constituir una arquitectura empresarial.
Niveles de arquitectura
Cada capa de arquitectura en el modelo tiene una intención específica: [25]
- Nivel de arquitectura empresarial: este nivel puede representar el total o una subunidad de cualquier corporación que esté en contacto con organizaciones externas.
- Nivel de arquitectura de la información: este nivel especifica tipos de contenido, formas de presentación y formato de la información requerida.
- Nivel de arquitectura de sistemas de información: especificaciones para sistemas de información automatizados y orientados a procedimientos.
- Nivel de arquitectura de datos: marco para el mantenimiento, acceso y uso de datos, con diccionario de datos y otras convenciones de nomenclatura.
- Nivel de sistemas de entrega de datos: nivel de implementación técnica de software, hardware y comunicaciones que dan soporte a la arquitectura de datos.
En la ilustración se muestran algunos elementos de muestra de cómo se puede describir la Arquitectura empresarial con más detalle.
Arquitectura de tecnología de la información
Los "Memorandos 97-16 (Arquitecturas de tecnología de la información)" dieron la siguiente definición de arquitectura empresarial: [21]
- La Arquitectura Empresarial es la descripción explícita de las relaciones actuales y deseadas entre el proceso empresarial y de gestión y la tecnología de la información. Describe la situación "objetivo" que la agencia desea crear y mantener mediante la gestión de su cartera de TI.
- La documentación de la Arquitectura empresarial debe incluir una discusión de principios y objetivos. [26] Por ejemplo, el entorno de gestión general de la agencia, incluido el equilibrio entre centralización y descentralización y el ritmo del cambio dentro de la agencia, debe entenderse claramente al desarrollar la Arquitectura empresarial. Dentro de ese entorno, los principios y objetivos establecen la dirección en cuestiones tales como la promoción de la interoperabilidad, los sistemas abiertos, el acceso público, la satisfacción del usuario final y la seguridad.
En esta guía se adoptó y se explicó con más detalle el modelo de cinco componentes del NIST. Se permitió a las agencias identificar diferentes componentes según fuera apropiado y especificar el nivel organizacional en el cual se implementarán aspectos específicos de los componentes. Aunque la esencia de estos componentes, a veces denominados "arquitecturas" o "subarquitecturas", debe abordarse en la arquitectura empresarial completa de cada agencia, las agencias tienen una gran flexibilidad para describir, combinar y cambiar el nombre de los componentes, que consisten en: [21]
- Procesos comerciales : este componente de la arquitectura empresarial describe los procesos comerciales centrales que respaldan las misiones de la organización. El componente Procesos comerciales es un análisis de alto nivel del trabajo que realiza la agencia para respaldar la misión, la visión y los objetivos de la organización, y es la base de la ITA. El análisis de los procesos comerciales determina la información necesaria y procesada por la agencia. Este aspecto de la ITA debe ser desarrollado por los directores de programas de alto nivel junto con los directores de TI. Sin un conocimiento profundo de sus procesos comerciales y su relación con las misiones de la agencia, la agencia no podrá utilizar su ITA de manera efectiva.
Los procesos comerciales se pueden describir descomponiendo los procesos en actividades comerciales derivadas. Hay una serie de metodologías y herramientas relacionadas disponibles para ayudar a las agencias a descomponer los procesos. Independientemente de la herramienta utilizada, el modelo debe permanecer en un nivel lo suficientemente alto para permitir un enfoque amplio de la agencia, pero lo suficientemente detallado para ser útil en la toma de decisiones a medida que la agencia identifica sus necesidades de información. Las agencias deben evitar un énfasis excesivo en el modelado de procesos comerciales, lo que puede resultar en un desperdicio de recursos de la agencia. [Nota 1] - Flujos de información y relaciones : Este componente analiza la información utilizada por la organización en sus procesos de negocio, identificando la información utilizada y el movimiento de la información dentro de la agencia. Las relaciones entre los diversos flujos de información se describen en este componente. Estos flujos de información indican dónde se necesita la información y cómo se comparte la información para respaldar las funciones de la misión. [Nota 2]
- Aplicaciones : el componente Aplicaciones identifica, define y organiza las actividades que capturan, manipulan y administran la información comercial para respaldar las operaciones de la misión. También describe las dependencias lógicas y las relaciones entre las actividades comerciales. [Nota 3]
- Descripciones de datos : este componente de la arquitectura empresarial identifica cómo se mantienen, se accede y se utilizan los datos. En un nivel alto, las agencias definen los datos y describen las relaciones entre los elementos de datos utilizados en los sistemas de información de la agencia. El componente Descripciones de datos y relaciones puede incluir modelos de datos que describen los datos subyacentes a las necesidades comerciales y de información de la agencia. Representar claramente los datos y las relaciones de datos es importante para identificar los datos que se pueden compartir de forma corporativa, para minimizar la redundancia y para admitir nuevas aplicaciones [Nota 4]
- Infraestructura tecnológica : el componente Infraestructura tecnológica describe e identifica la capa física, incluidas las características funcionales, las capacidades y las interconexiones del hardware, el software y las comunicaciones, incluidas las redes, los protocolos y los nodos. Es el "diagrama de cableado" de la infraestructura física de TI . [Nota 5]
Con la excepción del componente de Procesos de negocio, las interrelaciones y prioridades de estos componentes no están prescritas en esta guía; no hay jerarquía de relaciones implícitas. Además, las agencias deben documentar no solo su entorno actual para cada uno de estos componentes, sino también el entorno objetivo que se desea. [21]
Aplicaciones
Varias agencias federales de los EE. UU. Adoptaron el Marco NIST y lo utilizaron como base para su estrategia de información. [28] El modelo de referencia se aplica en los siguientes marcos:
- Arquitectura de la información del Departamento de Energía (DOE) [29]
- El marco de arquitectura empresarial de la FDIC es el marco de la arquitectura empresarial de la Corporación Federal de Seguros de Depósitos (FDIC).
- Marco de Arquitectura Empresarial Federal (FEAF): La documentación de 1999 del Marco de Arquitectura Empresarial Federal Versión 1.1 explica cómo se utiliza el Marco NIST como base del Marco FEA . [2]
- Arquitectura empresarial del NWS: Arquitectura empresarial del Servicio Meteorológico Nacional [30]
Ver también
- Perfil de portabilidad de aplicaciones (APP)
- Historia de la arquitectura empresarial
- Modelo de referencia de entorno de sistema abierto
- Marco de arquitectura técnica para la gestión de la información (TAFIM)
- Marco de arquitectura del sistema de información de tesorería
Notas
- ^ El Departamento de Defensa de EE. UU. Incluye aspectos del elemento Procesos comerciales en su Arquitectura operativa; el Departamento del Tesoro de los Estados Unidos lo incorpora a su visión empresarial.
- ^ El Departamento de Agricultura de EE. UU. Ha incorporado este componente a su Arquitectura comercial, mientras que el Departamento de Defensa y Tesoro de EE. UU. Lo ha integrado en sus Arquitecturas operativas.
- ^ El Departamento de Energía de EE. UU. Incorpora Aplicaciones comerciales en su Subarquitectura de aplicaciones, mientras que el Departamento del Tesoro de EE. UU. Las incluye en su Arquitectura funcional.
- ^ El Departamento de Agricultura de EE. UU. Ha incluido este elemento en su Arquitectura de datos / negocios, mientras que el Departamento del Tesoro de EE. UU. Lo incorpora en su Arquitectura de información.
- ^ El Departamento de Agricultura de EE. UU. Había incorporado esta arquitectura en su Norma técnica y arquitecturas de telecomunicaciones. El Departamento de Defensa de EE. UU. Utiliza su Arquitectura de Sistema y el Tesoro de EE. UU. Su Infraestructura para describir la capa física.
Referencias
Este artículo incorpora material de dominio público del sitio web del Instituto Nacional de Estándares y Tecnología https://www.nist.gov .
- ^ Consejo de director de información (2001) Una guía práctica para la arquitectura de empresa federal Versión 1.0 Prefacio. Febrero de 2001.
- ^ a b c d e f El Consejo de directores de información (1999). Marco de arquitectura empresarial federal versión 1.1 . Septiembre de 1999.
- ^ a b c Elizabeth N. Fong y Alan H. Goldfine (1989) Direcciones de gestión de la información: El desafío de la integración . Publicación especial 500-167 del Instituto Nacional de Estándares y Tecnología (NIST), septiembre de 1989.
- ^ John O'Looney (2002). Gobiernos de cableado: desafíos y posibilidades para los administradores públicos . Grupo editorial de Greenwood. p.67.
- ^ Matthew West y Julian Fowler (1999). Modelos de datos de alta calidad . El Ejecutivo de Enlace Técnico STEP de las Industrias de Procesos Europeas (EPISTLE).
- ^ ENFOQUE DE LA SECCIÓN 2 DE LA CORREA . Consultado el 30 de septiembre de 2008.
- ^ John F. Sowa (2004). "El Desafío de la Sopa del Conocimiento", en: Tendencias de Investigación en Educación Científica, Tecnológica y Matemática . Editado por J. Ramadas & S. Chunawala, Homi Bhabha Center, Mumbai, 2006.
- ^ Fong y Goldfine (1989, p. 5)
- ^ Fong y Goldfine (1989, p. I)
- ^ Frank, Andrew U. Geoinformación del grupo de investigación, Viena. Consultado el 15 de julio de 2013.
- ^ David Terraso (2004) " Robert Fulton, 72, muere: profesor de ingeniería y comisionado del condado ". en whistle.gatech.edu
- ^ Alan H. Goldfine en DBLP .
- ^ Dale Goodhue en DBLP .
- ^ Stanley YW Su en DBLP .
- ^ Fong y Goldfine (1989, p. Ix)
- ^ W. Bradford Rigdon (1989) "Arquitecturas y estándares". En: Information Management Directions: The Integration Challenge . EN Fong y AH Goldfine (eds.). NIST, septiembre de 1989. p. 135-150
- ↑ a b Rigdon (1989), p. 136
- ^ Fong y Goldfine (1989, p. 136)
- ^ JA Zachman (1993) Conceptos de Framework para EA - Recursos de arquitectura empresarial . Documento de Zachman International, Inc. pag. 1
- ^ Leonor Barroca, Jon Hall y Patrick Hall (200) " Introducción e historia de las arquitecturas de software, los componentes y la reutilización " en: Arquitecturas de software , 2000 p. 1
- ^ a b c d Franklin D. Raines, Memorandos 97-16 (Arquitecturas de tecnología de la información ) OBM (1997) de EE. UU. M-97-16, publicado el 18 de junio de 1997.
- ^ Rigdon y col. (1989, pág.136)
- ↑ a b c Rigdon (1989), pág. 137
- ^ Rigdon y col. (1989, págs. 137-38)
- ^ Rigdon y col. (1989, pág.139-140)
- ^ Ejemplos de "marcos" arquitectónicos publicados incluyen el Marco de Arquitectura del Sistema de Información del Tesoro (TISAF), el Marco de Arquitectura Técnica del Departamento de Defensa de EE. UU. Para la Gestión de la Información (TAFIM) y el Volumen 1 de Arquitectura de Información del Departamento de Energía .
- ^ OIG (2005). Implementación de los principios del gobierno electrónico Archivado el 14 de enero de 2009 en Wayback Machine . Mayo de 2005
- ^ "Entrevista exclusiva con John Zachman" por Roger Sessions. En: Perspectivas de la Asociación Internacional de Arquitectos de Software . Abril de 2006.
- ^ Iniciativas de arquitectura de información federal de la Administración Federal de Aviación (1998) . Febrero de 1998
- ^ Bobby Jones (2003) Arquitectura empresarial de NWS . En: XX Congreso Internacional sobre Sistemas de Procesamiento e Información Interactivos. 2004 .