Frameworx es un marco de arquitectura empresarial dirigido a proveedores de servicios de comunicaciones .
Está desarrollado por TM Forum .
Estructura
Frameworx consta de cuatro marcos:
- Marco de aplicación (a veces denominado mapa de aplicaciones de telecomunicaciones (TAM))
- Marco de procesos de negocio (eTOM)
- Marco de información (a veces denominado modelo de información / datos compartidos (SID) )
- Marcos de integración (que se desarrolla en el Programa de integración de TM Forum (TIP))
Marco de información
El marco de información (formalmente Modelo de datos / información compartida o SID) es un modelo de datos de referencia unificado que proporciona un conjunto único de términos para los objetos comerciales en las telecomunicaciones . El objetivo es permitir que las 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. Es parte de Frameworx.
El marco de información, como el modelo de información Frameworx, proporciona un modelo de referencia de información / datos y un vocabulario común de información / datos desde una perspectiva empresarial y de sistemas. El marco de información utiliza el lenguaje de modelado unificado para formalizar la expresión de las necesidades de un punto de vista particular de las partes interesadas.
El marco de información proporciona el lenguaje común para comunicar las preocupaciones de los cuatro grupos principales de componentes (partes interesadas) representados por los puntos de vista de Frameworx: negocio, sistema, implementación y despliegue, como se define en el ciclo de vida de Frameworx. Utilizado en combinación con el Business Process Framework (eTOM), los procesos de negocio y las descripciones de actividades y el Telecom Application Map, el Information Framework hace posible un puente entre el negocio y los grupos de tecnología de la información dentro de una organización al proporcionar definiciones que son comprensibles para el negocio, pero también son lo suficientemente rigurosos para ser utilizados para el desarrollo de software.
El modelo de marco de información se inspira en una amplia variedad de fuentes de la industria, pero sus principales orígenes son la Arquitectura de información común de la Alianza (ACIA) creada por un equipo liderado por Bill Brook de AT&T y BT Group y Directory Enabled Networks - next generation (DEN) -ng) modelo creado por John Strassner.
Cuando se lanzó inicialmente en 2000, el modelo de marco de información cubría bien el ámbito empresarial (BSS) y también el campo de la gestión de dispositivos, pero era insuficiente en su capacidad 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 la historia ha resultado en una mala utilización del modelo en ciertos campos de las telecomunicaciones, como la gestión de inventarios.
Principios
Frameworx se basa en estos principios clave.
Separación del proceso empresarial de la implementación de componentes
Cuando los sistemas de soporte de operaciones (OSS) se vinculan entre sí, los procesos comerciales que respaldan se distribuyen en todo el estado de TI. En efecto, 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 C, etc. El resultado de esto es que es extremadamente difícil comprender dónde está realmente alguno de estos flujos (por ejemplo, si el flujo del proceso está destinado a recibir un pedido de un cliente, ¿es la Aplicación A, B o C la que está manejando ese pedido actualmente?) y es aún más difícil cambiar 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 que se encarga de controlar el flujo del proceso empresarial entre las aplicaciones. Por lo tanto, el motor de flujo de trabajo iniciaría un proceso en la aplicación A, que luego devolvería el control al motor de flujo de trabajo, que luego llamaría a la aplicación B y así sucesivamente. De esta manera, siempre es posible averiguar dónde se encuentra un flujo de proceso individual, ya que está controlado por el motor de flujo de trabajo central, y las modificaciones del proceso se pueden realizar utilizando las herramientas de definición de proceso del motor. Claramente, algunos flujos de procesos de nivel inferior estarán integrados en las aplicaciones individuales, pero esto debería estar por debajo del nivel de procesamiento significativo para el negocio (es decir, por debajo del nivel en el que se implementan las políticas y reglas comerciales). Las metodologías de certificación Frameworx nos ayudan a lidiar con el alcance de las preferencias que no se distribuyen linealmente como una apertura para mejorar el método indudablemente apropiado aceptado por el cliente.
Sistema distribuido débilmente acoplado
"Acoplado débilmente" significa que cada aplicación es relativamente independiente de las otras aplicaciones en el sistema general. Por lo tanto, en un entorno débilmente acoplado, una aplicación puede modificarse sin que la alteración afecte necesariamente a otras. Llevado al extremo, a veces se puede considerar que esto produce la capacidad de "conectar y reproducir" aplicaciones, donde son tan independientes que pueden cambiarse sin afectar el comportamiento general del sistema. Ese extremo se considera un nirvana poco probable en la actualidad.
El "sistema distribuido" hace hincapié en que Frameworx no se basa en un proveedor de servicios de comunicación (CSP) que utiliza una única aplicación monolítica para gestionar todas sus actividades, sino que utiliza un conjunto de aplicaciones integradas y cooperativas.
La integración de OSS significa que los datos deben compartirse entre las aplicaciones. Para que esto sea efectivo, cada aplicación debe comprender cómo todas las demás aplicaciones entienden / interpretan esa parte de los datos que se comparten, o debe haber un modelo común de los datos compartidos. Para entender esto, considere una aplicación de manejo de pedidos que ha pasado por un proceso para ingresar un pedido de cliente y donde ahora necesita enviar una factura usando la aplicación B (un sistema de facturación). La aplicación A tendrá un registro de la dirección del cliente y, por lo tanto, debe asegurarse de que la aplicación B envíe la factura a esta dirección. Pasar estos datos entre los sistemas simplemente requiere 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 cada línea de la misma longitud. Eso es bastante sencillo. Pero imagine la dificultad que ocurriría si la aplicación de pedidos funcionara en productos que constan de paquetes de subproductos (por ejemplo, un producto de acceso de banda ancha hecho a partir de una línea de cobre, un módem, un conjunto de filtros y una conversión de banda ancha), mientras que la facturación la aplicación solo esperaba líneas de pedido / producto individuales. Tratar de convertir productos jerárquicos en no jerárquicos sin perder información no sería posible. Un modelo de información único para datos que se comparte entre aplicaciones de esta manera proporciona una solución a este problema. La solución de TMF para esto se denomina Modelo de datos / información compartida (SID).
Infraestructura de comunicaciones común
A mediados de la década de 1980, los OSS basados en computadora se desarrollaron como aplicaciones independientes. Sin embargo, a principios de la década de 1990 se hizo evidente que emplear estas aplicaciones como aplicaciones puramente aisladas era muy ineficaz, ya que conducía a una situación en la que, por ejemplo, se tomaban órdenes en un sistema, pero luego era necesario volver a introducir los detalles en otro para configurar el equipo de red correspondiente. Se demostró que se obtienen importantes ganancias de eficiencia al vincular los OSS independientes entre sí, para permitir funciones como el "aprovisionamiento de flujo continuo", donde un pedido se puede realizar en línea y automáticamente se obtiene el aprovisionamiento de equipos, sin ninguna intervención humana.
Sin embargo, para los grandes operadores con cientos de OSS separados, la proliferación de interfaces se convirtió en un problema serio. Cada OSS necesitaba "hablar" con muchos otros, lo que hacía que el número de interfaces aumentara con el cuadrado del número de OSS.
Frameworx describe el uso de una infraestructura de comunicaciones común (CCI). En este modelo, los OSS interactúan con el CCI en lugar de directamente entre sí. Por lo tanto, el CCI permite que las aplicaciones trabajen juntas utilizando el CCI para vincularlas. De esta manera, cada aplicación solo requiere una interfaz (a la CCI) en lugar de muchas (a otras aplicaciones). Por tanto, la complejidad se reduce a uno de orden n, en lugar de n 2 .
La CCI también puede proporcionar otros servicios, incluida la seguridad, la traducción de datos, etc.
Interfaces definidas por contrato
Dada la descripción anterior de cómo las aplicaciones interactúan con la CCI, está claro que necesitamos una forma de documentar esas interfaces, tanto en términos de la tecnología empleada (por ejemplo, ¿es Java / JMS o servicios web / SOAP?) Pero también la funcionalidad de la aplicación, los datos utilizados, las condiciones previas y posteriores, etc. La especificación del contrato Frameworx proporciona un medio para documentar estas interfaces y, por lo tanto, son interfaces definidas por contrato.
Los contratos de Frameworx pueden verse como extensiones de las especificaciones de la Interfaz de programación de aplicaciones (API).
Entregables
Modelo de proceso
El eTOM (mapa de operaciones de telecomunicaciones mejorado, pronunciado ee-tom) es el marco de procesos de negocio Frameworx.
La información de Frameworx es el modelo de datos / información compartida (SID).
Modelo de ciclo de vida
El modelo de ciclo de vida de Frameworx [1] tiene como objetivo definir el uso y la implementación de Frameworx dentro de una organización y proporciona un marco para usar la arquitectura SID, eTOM y Frameworx. El modelo se basa en un considerable trabajo anterior, incluyendo Zachman Marco , Kernighan , Yourdon , y el Object Management Group 's Model Driven Architecture . El ciclo de vida de Frameworx divide el desarrollo de sistemas en 4 etapas: requisitos, diseño del sistema, implementación y operación.
Especificaciones del contrato
Como se indicó anteriormente, el contrato Frameworx es la unidad fundamental de interoperabilidad en un sistema Frameworx. La interoperabilidad es importante para cada una de las cuatro vistas definidas por Frameworx Lifecycle. Por ejemplo, el Contrato se utiliza para definir el servicio a entregar, así como para especificar la información y el código que implementa el servicio. El Contrato también se utiliza para monitorear, administrar y mantener el servicio y garantizar que se cumplan las obligaciones externas del contrato (por ejemplo, de un SLA (Acuerdo de nivel de servicio)) y para definir qué medidas tomar si se violan de alguna manera. .
Mapa de aplicaciones de telecomunicaciones
El marco de aplicaciones (formalmente, mapa de aplicaciones de telecomunicaciones (TAM)) es uno de los principales artefactos de Frameworx. Considera el rol y la funcionalidad de las diversas aplicaciones que brindan la capacidad de OSS ( Sistema de soporte de operaciones ) y BSS ( Sistema de soporte comercial ).
Al hacerlo, permite que los documentos de contratación se redacten con referencia al marco, proporcionando así declaraciones claras e inequívocas de la funcionalidad requerida de cualquier aplicación dada, identificando superposiciones funcionales de aplicaciones existentes, lo que facilita la racionalización y la identificación de las brechas funcionales.
El nivel de descomposición funcional es tal que estos beneficios pueden realizarse pero sin ser demasiado prescriptivos.
Dentro del TM Forum hay una fuerte definición de proceso y datos. El marco de aplicaciones proporciona una forma formal de agrupar funciones y datos en componentes reconocidos, que luego se considerarían potencialmente adquiribles como aplicaciones o servicios. Una aplicación o servicio (por ejemplo: servicios web) puede ser un software de grano relativamente grueso que implementa funciones / procesos y actúa sobre los datos o los utiliza. En la vida diaria vemos aplicaciones como procesadores de texto o clientes de correo; en términos de OSS, consideraríamos una aplicación como algo como un componente 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á una serie de aplicaciones más pequeñas, como un motor de clasificación.
Una "aplicación" se define como un conjunto de uno o más artefactos de software que comprenden funciones, datos, flujos comerciales, 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 gobernar los recursos de la aplicación externos e internos, un modelo de flujo, para la funcionalidad con la aplicación y especificaciones del contrato para interfaces visibles externamente para la funcionalidad dentro de la aplicación.
Las aplicaciones se pueden implementar como paquetes desplegables y se pueden obtener en el mercado de sistemas.
El marco de aplicaciones no forma parte de las definiciones del marco de información ni del marco de procesos de negocio (eTOM), sino que se vincula a ambos de una manera fácilmente comprensible y también proporciona un mapeo entre ellos.
enlaces externos
Otra información
mTOP es un programa dentro del TeleManagement Forum (TM Forum) que cubre la definición de interfaces de gestión para redes de telecomunicaciones. mTOP cubre tanto la gestión de recursos como la de servicios.