NGOSS
Encyclopedia
Frameworx, formerly known as NGOSS or "New Generation Operations Systems and Software" is the TeleManagement Forum’s programme to provide ways to help Communication Service Providers to manage their business. Frameworx includes a set of principles and technical deliverables.
Frameworx proposes that the process is managed as part of the centralised infrastructure, using a workflow engine that is responsible for controlling the flow of the business process between the applications. Therefore, the workflow engine would initiate a process on application A, which would then return control to workflow engine, which would then call application B, and so on. In this way it's always possible to find out where an individual process flow is, since it’s controlled by the central workflow engine, and process modifications can be made using the engine’s process definition tools. Clearly some lower level process flows will be embedded in the individual applications, but this should be below the level of business-significant processing (i.e. below the level at which business policy and rules are implemented).
The "distributed system" is emphasising that Frameworx is not based on a Communication Service Provider (CSP) using a single monolithic application to manage all its activities, but is instead using a set of integrated and co-operating applications.
However, for large operators with many hundreds of separate OSSs, the proliferation of interfaces became a serious problem. Each OSS needed to "talk to" many others, leading to the number of interfaces increasing with the square of the number of OSSs.
Frameworx describes the use of a Common Communications Infrastructure (CCI). In this model, OSSs interface with the CCI rather than directly with each other. The CCI thus allows applications to work together using the CCI to link them together. In this way, each application only requires one interface (to the CCI) rather than many (to other applications). The complexity is therefore reduced to one of order n, rather than n2.
The CCI may also provide other services, including security, data translation, etc.
Frameworx contracts can be seen as extensions of Application Programming Interface (API) specifications.
(enhanced Telecom Operations Map, pronounced ee-tom) is the Frameworx business process framework.
, Kernighan, Yourdon, and the Object Management Group
's Model Driven Architecture. The Frameworx lifecycle divides systems development into 4 stages: requirements, system design, implementation and operation.
(TAM) http://www.tmforum.org/browse.aspx?catID=2390&linkID=32370 links process views and data/information views to describe IT-type applications that service providers can procure.
mTOP is program within the TeleManagement Forum (TM Forum) that covers the definition of management interfaces for telecommunications networks. mTOP covers both resource and service management.
TTI-Telecom
Principles
Frameworx is based around 5 key principles:- Separation of Business Process from Component Implementation
- Loosely Coupled Distributed System
- Shared Information Model
- Common Communications Infrastructure
- Contract defined interfaces
Separation of Business Process from Component Implementation
When Operations Support Systems (OSSs) are linked together, the business processes they support become distributed across the IT estate. In effect the situation is reached where a process starts with application A, which processes some data and then knows that it must call application B, which also does some processing and then calls C, etc., etc. The result of this is that it's extremely difficult to understand where any of these flows actually are (e.g. if the process flow is one intended to take a customer order, is it Application A or B or C that’s currently handling that order?) and it's even more difficult to change the process owing to its distributed nature.Frameworx proposes that the process is managed as part of the centralised infrastructure, using a workflow engine that is responsible for controlling the flow of the business process between the applications. Therefore, the workflow engine would initiate a process on application A, which would then return control to workflow engine, which would then call application B, and so on. In this way it's always possible to find out where an individual process flow is, since it’s controlled by the central workflow engine, and process modifications can be made using the engine’s process definition tools. Clearly some lower level process flows will be embedded in the individual applications, but this should be below the level of business-significant processing (i.e. below the level at which business policy and rules are implemented).
Loosely Coupled Distributed System
"Loosely coupled" means that each application is relatively independent of the other applications in the overall system. Therefore, in a loosely coupled environment, one application can be altered without the alteration necessarily affecting others. Taken to extreme, this can sometimes be viewed as producing the ability to "plug and play" applications, where they are so independent that they can be changed without affecting the overall system behaviour. That extreme is considered an unlikely nirvana at the present time.The "distributed system" is emphasising that Frameworx is not based on a Communication Service Provider (CSP) using a single monolithic application to manage all its activities, but is instead using a set of integrated and co-operating applications.
Shared Information Model
Integrating OSSs means that data must be shared between the applications. For this to be effective, either each application must understand how every other application understands/interprets that part of the data that is shared, or there must be a common model of the shared data. To understand this, consider an order handling application which has gone through a process to enter a customer order and where it now needs to send out a bill using application B (a billing system). Application A will have a record of the customer address and it therefore needs to ensure that application B sends the bill to this address. Passing this data between the systems simply requires a common format for the address information – each system needs to expect the same number of address lines, with each line being the same length. That’s fairly straightforward. But imagine the difficulty that would occur if the ordering application worked on products that consists of bundles of sub-products (e.g. a broadband access product made from a copper line, a modem, a set of filters and a broadband conversion), whereas the billing application only expected single product/order lines. Trying to convert hierarchical products into non-hierarchical ones without losing information would not be possible. A single information model for data that is shared between applications in this way provides a solution to this problem. The TMF solution to this is called the Shared Information/Data Model (SID).Common Communications Infrastructure
Originally (typically in the mid 1980s), computer-based OSSs were developed as stand-alone applications. However, during the early 1990s it became apparent that employing these as purely isolated applications was highly inefficient, since it led to a situation where, for example, orders would be taken on one system but the details would then need to be re-keyed into another in order to configure the relevant network equipment. Major efficiency gains were shown to be available from linking the standalone OSSs together, to allow such features as "Flow-through provisioning", where an order could be placed online and automatically result in equipment being provisioned, without any human intervention.However, for large operators with many hundreds of separate OSSs, the proliferation of interfaces became a serious problem. Each OSS needed to "talk to" many others, leading to the number of interfaces increasing with the square of the number of OSSs.
Frameworx describes the use of a Common Communications Infrastructure (CCI). In this model, OSSs interface with the CCI rather than directly with each other. The CCI thus allows applications to work together using the CCI to link them together. In this way, each application only requires one interface (to the CCI) rather than many (to other applications). The complexity is therefore reduced to one of order n, rather than n2.
The CCI may also provide other services, including security, data translation, etc.
Contract defined interfaces
Given the description above of how applications interface to the CCI, it’s clear that we need a way of documenting those interfaces, both in terms of the technology employed (e.g. is it Java/JMS or Web services/SOAP?) but also the functionality of the application, the data used, the pre- and post-conditions, etc. The Frameworx contract specification provides a means to document these interfaces, and these are therefore contract defined interfaces.Frameworx contracts can be seen as extensions of Application Programming Interface (API) specifications.
Process Model
The eTOMETOM
The eTOM , published by the TM Forum, is a guidebook that defines the most widely used and accepted standard for business processes in the telecommunications industry...
(enhanced Telecom Operations Map, pronounced ee-tom) is the Frameworx business process framework.
Shared Information Model
The Frameworx Information is the Shared Information/Data Model (SID).Lifecycle Model
The Frameworx lifecycle model http://www.tmforum.org/browse.aspx?catID=2025&linkID=29276 is aimed at defining the use and deployment of Frameworx within an organisation, and provides a framework for using the SID, eTOM and the Frameworx architecture. The model is based on considerable earlier work, including Zachman FrameworkZachman framework
The Zachman Framework is an Enterprise Architecture framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining an enterprise...
, Kernighan, Yourdon, and the Object Management Group
Object Management Group
Object Management Group is a consortium, originally aimed at setting standards for distributed object-oriented systems, and is now focused on modeling and model-based standards.- Overview :...
's Model Driven Architecture. The Frameworx lifecycle divides systems development into 4 stages: requirements, system design, implementation and operation.
Contract Specifications
As stated earlier, the Frameworx Contract is the fundamental unit of interoperability in an Frameworx system. Interoperability is important for each of the four views defined by the Frameworx Lifecycle. For example, the Contract is used to define the service to be delivered, as well as to specify information and code that implement the service. The Contract is also used to monitor, administer and maintain the service and ensure that any external obligations of the contract (e.g., from an SLA (Service Level Agreement)) are met and to define what measures to take if they are violated in some way.Telecom Application Map
The Telecom Application MapTelecom Application Map
The TM Forum Applications Framework is produced by the TM Forum . The TM Forum is the world’s industry association of web, telecom and media companies focused on end-end service management...
(TAM) http://www.tmforum.org/browse.aspx?catID=2390&linkID=32370 links process views and data/information views to describe IT-type applications that service providers can procure.
Weblinks
TM Forum Frameworx pageOther information
TM Forum - Telcordia FTTx/PON Solution and MTOSI Case StudymTOP is program within the TeleManagement Forum (TM Forum) that covers the definition of management interfaces for telecommunications networks. mTOP covers both resource and service management.
TTI-Telecom
See also
- eTOMETOMThe eTOM , published by the TM Forum, is a guidebook that defines the most widely used and accepted standard for business processes in the telecommunications industry...
- Model-driven architectureModel-driven architectureModel-driven architecture is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of...
- Service-oriented architectureService-oriented architectureIn software engineering, a Service-Oriented Architecture is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components that can be reused for...
- Telecommunications Management NetworkTelecommunications Management NetworkThe Telecommunications Management Network is a protocol model defined by ITU-T for managing open systems in a communications network. It is part of the ITU-T Recommendation series M.3000 and is based on the OSI management specifications in ITU-T Recommendation series X.700.TMN provides a framework...
- Web serviceWeb serviceA Web service is a method of communication between two electronic devices over the web.The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network". It has an interface described in a machine-processable format...
- TM ForumTM ForumThe TeleManagement Forum formerly the Network Management Forum, is an international non-profit industry association, for service providers and their suppliers in the information industry, the telecommunications industry and the entertainment industry.Members include telephone companies, cable...