Operational Support Systems are the components that a company — historically this would have been a telephone operator or telco, but now normally called a Communications Service Provider (CSP) — uses to run its network and business. Typical types of activities that count as part of OSS are taking a customer’s order, configuring network components, creating a bill and managing faults.

In the days long gone (i.e. before about 1985) OSS activities were normally done solely by people passing paper around. However, it became plain around that time that much of this activity could be replaced by computers. In the next 5 years or so, the telephone companies created a number of computing systems (or software applications) which automated much of this activity. However, they were typically not linked to each other and therefore often required manual intervention. For example, consider the case where a customer wants to order a new telephone service. The ordering system would take the customer’s details and details of their order, but would not be able to configure the telephone exchange directly – this would be done by a switch management system. So the details of the new service would need to be transferred from the order handling system to the switch management system – and this would normally be done by a technician rekeying the details from one screen into another – a process often referred to as “swivel chair integration”. This was clearly another source of inefficiency, so the focus on the next few years was on creating automated interfaces between the OSS applications – OSS integration. To a large extent, cheap and simple OSS integration remains the goal of most of the Telco’s IT departments to this day.

A brief history of OSS Architecture
A lot of the work on OSS has been centred on defining its architecture. (To people who don’t work in IT, the concept of an architecture that isn’t about creating buildings may seem strange, but there you are…) Put simply, there are 4 key elements of OSS:

* Processes
– the sequence of events

* Data
– the information that is acted upon

* Applications
– the components that implement processes to manage data

* Technology
– how we implement the applications

Early work on defining OSS architecture was done by the ITU-T in its TMN model. This established a 4-layer model of TMN applicable within an OSS :

* Business Management Level(BML)
* Service Management Level(SML)
* Network Management Level(NML)
* Element Management Level(EML)
(Note: a fifth level is mentioned at times being the elements themselves, though the standards speak of only four levels) This was a basis for later work. Network management was further defined by the ISO using the FCAPS model – Fault, Configuration, Accounting, Performance and Security. This basis was adopted by the ITU-T TMN standards as the Functional model for the technology base of the TMN standards M.3000 – M.3599 series. Although the FCAPS model was originally concieved and is applicable for any IT enterprise network, it was adopted for use in the public networks run by telcommunication service providers adhering to ITU-T TMN standards.

The newest stage in OSS architecture work has come with the TMF’s [1] NGOSS programme, which was established in 2000. This established a set of principles that an OSS integration should adopt, along with a set of models that provide standardised approaches. The models include an information model (the Shared Information/Data model, or SID), a process model (the enhanced Telecom Operation Map, or eTOM) and a lifecycle model. The TMF describes NGOSS as

* a “loosely coupled”
* distributed
* component based architecture

along with functioning application components upon which a Communications Service Provider business can run.

* The components interact through a common information bus
* The components can be programmed through the use of a process management tool to control the business processes of the service provider using the functionality provided by the components

The TMF’s work so far has been mainly technology neutral, which therefore implies that there remains considerable work to create a functioning OSS estate from NGOSS principles. However, there are now a number of standardised technology-specific implementations of NGOSS, of which OSS through Java initiative (OSS/J) is one.