Frameworx

El Marco de Información (anteriormente Modelo de Información/Datos Compartidos o SID) es un modelo de datos de referencia unificado que proporciona un conjunto único de términos para los objetos de negocio en telecomunicaciones . Su objetivo es permitir que personas de diferentes departamentos, empresas o ubicaciones geográficas utilicen los mismos términos para describir los mismos objetos, prácticas y relaciones del mundo real. Forma parte de Frameworx.

El Marco de Información, como modelo de información de Frameworx , proporciona un modelo de referencia de información/datos y un vocabulario común de información/datos desde una perspectiva tanto empresarial como sistémica. El Marco de Información utiliza el Lenguaje Unificado de Modelado (UML) para formalizar la expresión de las necesidades desde el punto de vista de cada parte interesada.

El Marco de Información proporciona el lenguaje común para comunicar las inquietudes de los cuatro grupos principales de partes interesadas representados por los Puntos de Vista de Frameworx: Negocio, Sistema, Implementación y Despliegue, tal como se definen en el Ciclo de Vida de Frameworx. Utilizado en combinación con las descripciones de procesos y actividades del Marco de Procesos de Negocio (eTOM) y el Mapa de Aplicaciones de Telecomunicaciones, el Marco de Información permite establecer un vínculo entre los grupos de negocio y de Tecnologías de la Información dentro de una organización, al proporcionar definiciones comprensibles para el negocio, pero también lo suficientemente rigurosas para su uso en el desarrollo de software.

El modelo Information Framework se inspira en una amplia variedad de fuentes de la industria, pero sus principales orígenes son la Alliance Common Information Architecture (ACIA), creada por un equipo liderado por Bill Brook de AT&T y BT Group , y el modelo Directory Enabled Networks - next generation (DEN-ng), creado por John Strassner.

Cuando se lanzó inicialmente en el año 2000, el modelo Information Framework cubría adecuadamente el ámbito empresarial (BSS) y también el de la gestión de dispositivos, pero resultaba insuficiente para representar redes lógicas y capacidad. Estas deficiencias se están abordando mediante la revisión del modelo para incluir conceptos como topologías, pero su historial ha derivado en una escasa utilización del modelo en ciertos campos de las telecomunicaciones, como la gestión de inventarios.

Cuando los sistemas de soporte de operaciones (OSS) se interconectan, los procesos de negocio que soportan se distribuyen por toda la infraestructura de TI. En la práctica, se llega a una situación en la que un proceso comienza con la aplicación A, que procesa algunos datos y luego sabe que debe llamar a la aplicación B, que también realiza algún procesamiento y luego llama a la C, y así sucesivamente. Como resultado, es extremadamente difícil comprender dónde se encuentra realmente cada uno de estos flujos (por ejemplo, si el flujo del proceso está destinado a tomar un pedido de un cliente, ¿es la aplicación A, B o C la que está gestionando ese pedido?) y resulta aún más difícil modificar el proceso debido a su naturaleza distribuida.

Frameworx propone que el proceso se gestione como parte de la infraestructura centralizada, utilizando un motor de flujo de trabajo responsable de controlar el flujo del proceso de negocio entre las aplicaciones. Por lo tanto, el motor de flujo de trabajo iniciaría un proceso en la aplicación A, que a su vez devolvería el control al motor de flujo de trabajo, que llamaría a la aplicación B, y así sucesivamente. De esta forma, siempre es posible determinar la ubicación de un flujo de proceso individual, ya que está controlado por el motor de flujo de trabajo central, y se pueden realizar modificaciones mediante las herramientas de definición de procesos del motor. Evidentemente, algunos flujos de proceso de nivel inferior estarán integrados en las aplicaciones individuales, pero esto debería estar por debajo del nivel de procesamiento relevante para el negocio (es decir, por debajo del nivel en el que se implementan las políticas y reglas de negocio). Las metodologías de certificación de Frameworx nos ayudan a abordar el alcance de las preferencias que no se distribuyen linealmente, lo que nos permite mejorar el método indiscutiblemente apropiado y aceptado por el cliente.

El término "acoplamiento flexible" significa que cada aplicación es relativamente independiente de las demás en el sistema general. Por lo tanto, en un entorno de acoplamiento flexible, una aplicación puede modificarse sin que ello afecte necesariamente a las demás. Llevado al extremo, esto puede interpretarse como la capacidad de "conectar y usar" aplicaciones, donde su independencia es tal que pueden modificarse sin afectar el comportamiento general del sistema. Sin embargo, este extremo se considera una solución ideal poco probable en la actualidad.

El término "sistema distribuido" hace hincapié en que Frameworx no se basa en un proveedor de servicios de comunicación (CSP) que utilice una única aplicación monolítica para gestionar todas sus actividades, sino que utiliza un conjunto de aplicaciones integradas y que cooperan entre sí.

La integración de sistemas de soporte operativo (OSS) implica que los datos deben compartirse entre las aplicaciones. Para que esto sea efectivo, cada aplicación debe comprender cómo las demás entienden o interpretan la parte de los datos compartidos, o bien debe existir un modelo común de dichos datos. Para comprenderlo mejor, consideremos una aplicación de gestión de pedidos que ha procesado un pedido de un cliente y ahora necesita enviar una factura a través de la aplicación B (un sistema de facturación). La aplicación A dispone de la dirección del cliente y, por lo tanto, debe asegurarse de que la aplicación B envíe la factura a dicha dirección. Para transferir estos datos entre los sistemas, basta con un formato común para la información de la dirección: cada sistema debe esperar el mismo número de líneas de dirección, con la misma longitud en cada una. Esto es bastante sencillo. Sin embargo, imaginemos la dificultad que surgiría si la aplicación de pedidos trabajara con productos que constan de conjuntos de subproductos (por ejemplo, un producto de acceso a banda ancha compuesto por una línea de cobre, un módem, un conjunto de filtros y un convertidor de banda ancha), mientras que la aplicación de facturación solo esperara líneas de producto/pedido individuales. Intentar convertir productos jerárquicos en no jerárquicos sin perder información sería imposible. Un modelo de información único para los datos compartidos entre aplicaciones ofrece una solución a este problema. La solución de TMF se denomina Modelo de Información/Datos Compartidos (SID).

Hasta mediados de la década de 1980, los sistemas de soporte operativo (OSS) basados ​​en computadora se desarrollaron como aplicaciones independientes. Sin embargo, a principios de la década de 1990, se hizo evidente que utilizarlos como aplicaciones aisladas resultaba muy ineficiente, ya que generaba situaciones en las que, por ejemplo, se recibían pedidos en un sistema, pero luego era necesario volver a ingresar los detalles en otro para configurar el equipo de red correspondiente. Se demostró que se podían obtener importantes mejoras de eficiencia al conectar los OSS independientes, lo que permitía funciones como el "aprovisionamiento en flujo", mediante el cual se podía realizar un pedido en línea y obtener automáticamente el equipo aprovisionado, sin intervención humana.

Sin embargo, para los grandes operadores con cientos de sistemas de soporte operativo (OSS) independientes, la proliferación de interfaces se convirtió en un problema grave. Cada OSS necesitaba comunicarse con muchos otros, lo que provocaba que el número de interfaces aumentara con el cuadrado del número de OSS.

Frameworx describe el uso de una Infraestructura de Comunicaciones Comunes (CCI). En este modelo, los sistemas de soporte operativo (OSS) interactúan con la CCI en lugar de hacerlo directamente entre sí. De esta manera, la CCI permite que las aplicaciones colaboren, conectándolas entre sí. Así, cada aplicación solo requiere una interfaz (con la CCI) en lugar de varias (con otras aplicaciones). Por lo tanto, la complejidad se reduce a una de orden n, en lugar de ^n² .

La CCI también puede proporcionar otros servicios, como seguridad, traducción de datos, etc.

Dada la descripción anterior sobre cómo las aplicaciones interactúan con la CCI, es evidente que necesitamos una forma de documentar dichas interfaces, tanto en lo que respecta a la tecnología empleada (por ejemplo, ¿es Java/JMS o servicios web/SOAP?) como a la funcionalidad de la aplicación, los datos utilizados, las precondiciones y postcondiciones, etc. La especificación del contrato de Frameworx proporciona un medio para documentar estas interfaces, por lo que se trata de interfaces definidas por contrato.

Los contratos de Frameworx pueden considerarse extensiones de las especificaciones de la interfaz de programación de aplicaciones (API).

El eTOM (Mapa de Operaciones de Telecomunicaciones Mejorado, pronunciado ee-tom) es el marco de procesos de negocio de Frameworx.

La información de Frameworx es el Modelo de Información/Datos Compartidos (SID).

El modelo de ciclo de vida de Frameworx tiene como objetivo definir el uso y la implementación de Frameworx dentro de una organización, y proporciona un marco para utilizar el SID, el eTOM y la arquitectura de Frameworx. El modelo se basa en trabajos previos importantes, como el Marco de Zachman , Kernighan , Yourdon y la Arquitectura Dirigida por Modelos del Object Management Group . El ciclo de vida de Frameworx divide el desarrollo de sistemas en cuatro etapas: requisitos, diseño del sistema, implementación y operación.

Como se mencionó anteriormente, el Contrato de Frameworx es la unidad fundamental de interoperabilidad en un sistema Frameworx. La interoperabilidad es importante para cada una de las cuatro vistas definidas por el Ciclo de Vida de Frameworx. Por ejemplo, el Contrato se utiliza para definir el servicio que se va a prestar, así como para especificar la información y el código que lo implementan. El Contrato también se utiliza para supervisar, administrar y mantener el servicio, y para garantizar que se cumplan todas las obligaciones externas del contrato (por ejemplo, las derivadas de un SLA [Acuerdo de Nivel de Servicio]), y para definir las medidas que se deben tomar en caso de incumplimiento.

El marco de aplicaciones (anteriormente denominado Mapa de Aplicaciones de Telecomunicaciones (TAM)) es uno de los principales componentes de Frameworx. Este marco considera el rol y la funcionalidad de las diversas aplicaciones que brindan capacidades de OSS ( Sistema de Soporte de Operaciones ) y BSS ( Sistema de Soporte Empresarial ).

De este modo, permite redactar los documentos de adquisición haciendo referencia al marco de referencia, proporcionando así declaraciones claras e inequívocas de la funcionalidad requerida para cada aplicación, identificando las superposiciones funcionales de las aplicaciones existentes y, por lo tanto, facilitando la racionalización y la identificación de las deficiencias funcionales.

El nivel de descomposición funcional es tal que estos beneficios pueden obtenerse sin ser excesivamente restrictivo.

Dentro del Foro TM existe una definición precisa de proceso y datos. El Marco de Aplicaciones proporciona una forma formalizada de agrupar funciones y datos en componentes reconocidos, que luego se considerarían potencialmente obtenibles como aplicaciones o servicios. Una aplicación o servicio (por ejemplo, servicios web) puede ser un software relativamente básico que implementa funciones/procesos y actúa sobre los datos o los utiliza. En la vida cotidiana vemos aplicaciones como procesadores de texto o clientes de correo electrónico; en términos de software de código abierto, consideraríamos una aplicación como un componente de CRM, un sistema de facturación o una solución de inventario, aunque también entendemos que estos pueden descomponerse hasta cierto punto; por ejemplo, un sistema de facturación incluirá varias aplicaciones más pequeñas, como un motor de tarificación.

Una “aplicación” se define como un conjunto de uno o más artefactos de software que comprenden funciones, datos, flujos de negocio, reglas e interfaces bien definidos. Esto incluiría un modelo de datos, para los datos utilizados para interactuar con y dentro de una aplicación; políticas, para gestionar los recursos externos e internos de la aplicación; un modelo de flujo, para la funcionalidad de la aplicación; y especificaciones de contrato para las interfaces visibles externamente a la funcionalidad dentro de la aplicación.

Las aplicaciones se pueden implementar como paquetes desplegables y se pueden adquirir en el mercado del sistema.

El marco de aplicaciones no forma parte de las definiciones del marco de información ni del marco de procesos de negocio (eTOM) , pero se vincula con ambos de una manera fácilmente comprensible y también proporciona una correspondencia entre ellos.