Arquitectura de sistemas de información interoperables

La Arquitectura de Sistemas de Información Interoperables (AIOS) es una arquitectura de referencia para el desarrollo de sistemas de información empresariales interoperables . Si las empresas o administraciones públicas desean participar en procesos de negocio automatizados con otras organizaciones, sus sistemas de TI deben poder trabajar juntos, es decir, deben ser interoperables . La AIOS representa un plan de construcción genérico para que estas organizaciones desarrollen sistemas de información interoperables mediante el ajuste y la extensión sistemáticos de sus sistemas de información internos. La AIOS se describió en una tesis doctoral y se basa en los resultados de varios proyectos de investigación sobre interoperabilidad. ^{[ 1 ]} Es independiente de productos o proveedores específicos, pero describe de forma genérica las diferentes capas, vistas, relaciones y medios técnicos necesarios para establecer sistemas de información interoperables de manera eficiente. Para ello, combina conceptos de la arquitectura orientada a servicios , el negocio colaborativo y el modelado de procesos de negocio . Puede considerarse complementaria a ARIS , una arquitectura bien conocida para sistemas de información internos y procesos de negocio.

Al igual que la automatización de procesos internos, la automatización de procesos de negocio interorganizacionales es una tendencia importante. En este sentido, las organizaciones colaboradoras buscan un acoplamiento flexible de sus sistemas de información en lugar de una integración estrecha : los sistemas de información que colaboran deben poder trabajar juntos, pero manteniendo la mayor independencia posible. Esta característica también se denomina interoperabilidad o, en el contexto de las organizaciones colaboradoras, interoperabilidad empresarial , es decir, la capacidad de las organizaciones autónomas para ejecutar un proceso de negocio colaborativo entre ellas.

Los sistemas de información son sistemas que procesan información, es decir, capturan, transportan, transforman, almacenan y ofrecen información. Según la concepción predominante en la investigación de sistemas de información, un sistema de información comprende no solo el hardware y el software de una empresa, sino también los actores humanos relacionados, las funciones y los procesos empresariales, así como las estructuras organizativas. ^{[ 2 ]} Esta comprensión amplia también se refleja, por ejemplo, en el Marco de Zachman .

La arquitectura se define como la “organización fundamental de un sistema, plasmada en sus componentes, sus relaciones entre sí y con el entorno, y los principios que rigen su diseño y evolución”. ^{[ 3 ]} Sinz define la arquitectura de un sistema de información como el plano de construcción de dicho sistema, entendido como la especificación y documentación de sus componentes y sus relaciones, abarcando todos los puntos de vista relevantes, así como las reglas de construcción para la creación del plano. ^{[ 4 ]}

En consecuencia, una arquitectura de sistemas de información interoperables puede definirse como el plan de construcción de un sistema de información interorganizacional, que permite a las organizaciones ejecutar un proceso de negocio colaborativo entre ellas.

Tras el trabajo sobre sistemas de información interoperables realizado en proyectos de investigación europeos ^{[ 5 ]} en 2010, se publicó la Arquitectura de Sistemas de Información Interoperables (AIOS) como referencia para la construcción de sistemas de información interoperables y débilmente acoplados, y para la ejecución sistemática y basada en modelos de procesos empresariales colaborativos.

El AIOS está dirigido principalmente a grandes organizaciones que desean interoperar entre sí. Para ello, describe cómo se pueden conectar sistemáticamente los elementos del sistema de información interno con los sistemas de información de los socios colaboradores. Los elementos principales del AIOS son:

1. Descripción de los distintos tipos de datos que componen un sistema de información interoperable, así como sus relaciones. Esta parte también se denomina parte estática o estructura de la arquitectura. Indica a las organizaciones qué elementos de información (por ejemplo, descripciones de mensajes, secuencias de intercambio, roles y servicios) deben proporcionar a sus socios de colaboración y cómo pueden correlacionarlos de forma óptima con los elementos internos.
2. Descripción de las distintas rutas de construcción para implementar o ajustar sistemas de información interoperables. Esto también se conoce como la parte dinámica de la arquitectura. Indica a la organización cómo desarrollar iterativamente los elementos mencionados anteriormente.
3. Concepto para los componentes técnicos necesarios para implementar la arquitectura, por ejemplo, herramientas de diseño, repositorios internos y externos visibles.

Un elemento incluido en la tercera categoría es un "repositorio BII" , en el que cada organización publica el contenido de su Interfaz de Interoperabilidad Empresarial (BII) para sus socios colaboradores. Dado que comprende vistas externas de los elementos del sistema de información, proporciona funcionalidades de publicación y descubrimiento según sea necesario en la arquitectura orientada a servicios : en la BII, los procesos, servicios, estructuras organizativas, etc., relevantes externamente se describen en varios niveles de granularidad técnica, lo que permite a otras organizaciones buscar también elementos a nivel empresarial y no solo artefactos técnicos. Aquí, a diferencia del enfoque SOA tradicional, en lugar de un directorio de servicios centralizado, se implementan varios repositorios específicos para cada socio.

La parte estática de la arquitectura se basa en tres ejes ortogonales: Dimensiones empresariales, Niveles de granularidad técnica y Vistas colaborativas.

Dimensiones de la empresa

Para describir los procesos empresariales de forma exhaustiva, este eje proporciona distintas perspectivas sobre los procesos, las funciones, los datos y los elementos organizativos.

1. En la dimensión organizativa , se describen los roles, las unidades y otros elementos organizativos relevantes para la colaboración, y se relacionan con los elementos internos. Esto garantiza, por ejemplo, que los socios colaboradores tengan un entendimiento común de los roles que interactúan.
2. En la dimensión de datos , se definen los tipos de documentos utilizados en la colaboración y se relacionan con los tipos de documentos utilizados internamente.
3. En la dimensión funcional , se describen las funciones empresariales y los servicios que se ofrecen en la colaboración.
4. En la dimensión de procesos , se describen los procesos que ofrece cada organización, así como la relación entre estos procesos públicos y los procesos adyacentes de las organizaciones asociadas.

De este modo, en combinación con el eje de las "perspectivas colaborativas", se proporcionan puntos de vista privados, públicos y globales sobre los procesos, las funciones, los datos y los roles organizativos .

Niveles de granularidad técnica

La descripción de los elementos del sistema en diferentes niveles de granularidad técnica respalda el desarrollo sistemático de sistemas de información colaborativos, desde la definición de los requisitos del negocio hasta el nivel de código. Además del aspecto constructivo, se proporciona una descripción de interoperabilidad multidimensional que facilita la sincronización de los sistemas colaboradores en cada nivel. De forma similar a, por ejemplo, ARIS y MDA de OMG , se utilizan tres niveles:

1. Nivel de negocio : Aquí se describen los procesos que se van a automatizar desde un nivel independiente de la técnica. En MDA, este nivel se denomina nivel CIM.
2. Nivel técnico : Aquí se describe el concepto de TI. Por lo tanto, los modelos del primer nivel se enriquecen técnicamente; por ejemplo, en lugar de funciones empresariales, ahora se describen componentes, aunque todavía a un nivel conceptual y general. Dado que los modelos del segundo nivel constituyen la base para la generación automatizada de código ejecutable, es posible que deban adaptarse para ajustarse a las limitaciones del nivel de implementación.
3. Nivel de ejecución : En este nivel, los modelos son interpretables por la máquina y pueden utilizarse durante la ejecución de procesos.