The notion of a service oriented architecture (SOA) that encouraged componentized software (standardized interfaces for easy substitution of network elements) and made applications compensable was pretty popular with everyone in IT. But it is completely new and also completely necessary in the world of telecom.

Service orientation is the principal concept behind the network architecture. This means that the functions on each network layer are modeled as services as far as possible ir order to customize solutions and services for each customer. In this concept each network layer may bundle or split some of the higher or lower layers’ services. The network oriented to services is especially important in the integration enabler’s components.

The one responsible for implementing network changes (the abstraction layers necessary for guaranteeing the Services Oriented Architecture (SOA) on the Telecom Network) is the OSS (Operations Support System), which also makes the change transparent to BSS (Business Support System). In order to have a BSS ecosystem that efficiently supports service orientation, the OSS needs to support the following enablers:

1. Data managed in the services should be modeled in a consistent way: even if the same exact data model is not applied through the network infrastructure, there should be unambiguous mappings. It is the capacity to abstract the network which is provide by the OSS.

2. Interfaces should be consistent: they should be mapable through parameter translations or transformations and compositions of service calls. In a Network architecture oriented to services the interfaces are implemented following the OSS´ specifications and complementing them as needed according to the network abstraction layer, It mean a new concept of the network, a network completely based on software.

The integration enablers consist of the integration technology platform (OSS and IT middleware), with both generic frameworks and OSS/BSS-specific abstraction services, which are accessed through standard APIs when possible. The main idea behind this is the Virtualizaton of the Network’s Functions.

Main OSS/BSS integration enablers in brief:

– OSS/BSS and OSS Access APIs provide standard interfaces towards OSS applications and middleware software components to enable simple OSS/BSS integration.

– Custom API toolkits (e.g. EAI tools) are used for integrating systems without standard interfaces.

– Standard OSS middleware provides the generic framework and OSS specific abstraction services such as Service inventory and Service activation.

– Standard service management interfaces (e.g. Web Services) Standard OSS middleware provides components, such as:

– Topology: Network and service topology component.

– Inventory: Network and service inventories.

– Service activation: Component for interfacing towards different service directories and retrieving activation context.

– Network activation: Abstraction service utilizing needed specific service components.

– Fault management: Component for alarm monitoring and processing for network elements.

– Performance management: Component for performance data collection, KPI calculation and reporting.

– Business Process Engine (BPE) integration’s layer with the BSS.

The challenge for service providers is that they probably have no choice but to make SOA work. Most of the operation standards and Services Delivery Platforms (SDP) are based on SOA, making the service provider sector perhaps the most dependent of all on developing a successful and implementable SOA model.

One clear positive step for service providers to take is to get a full business-wide SOA strategy where an SDP SOA approach would be compatible with an OSS/BSS SOA approach, and a service management SOA approach should be orchestrated. With proper planning, SOA and SDP strategy, even considering OSS Strategy integration, being made by a telecom network operator can succeed and capture significant benefits in cost control and service flexibility for the near future.

The other consideration is how SOA and cloud computing can guarantee that network functions and applications will be componentized for maximum efficiency once, and then it would depend on the OSS stretegy

To avoid problems, it’s important to understand the differences between optimum cloud and SOA componentization. Special care should be taken with network functions, Network efficiency, security and application and lifecycle services. Appropriate steps should be taken to orchestra componentization goals as applications evolve and new customized services are being created.

The combination of SOA and NFV encourages architects and developers to think of software design in terms of reusable services, represented by a network inventory based on software components. These components are assembled into an application through the use of a service bus that steers work according to business-level rules, often expressed in Business Process Execution Language. All those procedures are orchestrated by OSS.

In the cloud, the primary goal is to reduce resource expenses, particularly Total Cost Ownership. Applications are likely to be componentized to facilitate effective deployment on a pool of network resources. In my opinion, it is the main role of the OSS working with the new network model.

Agility in addressing business changes and opportunities, software reuse potential and resource optimization are different goals requiring different strategies. No single approach will ever offer everything, but a smart network architect would design a good OSS Strategy in order to support that challenge