Telecom Services

Abstract:
Architectural Solutions and approach for implementation of Common Management Information Protocol for Telecommunications Management Networks.

Today, Carriers face several challenges typical of such a major undertaking, including the variety of equipment, vendors, and protocols;
service software not being integrated with network management;
the need for a reasonable service deployment lead time;
and the costs, reliability, and performance issues associated with the manual components of network management.

An Integrated Service Management Solution from Aaramb offers an enterprise wide service and network management system, based on open systems interconnection (OSI) model, that integrates the management of new technologies (ATM, SONET) and legacy systems for long-distance division.The system is designed to interfaces with customer systems and other common carriers through standard interfaces.

Features:
distributed and fault-tolerant architecture
high performance integration of object-driven database technologies
facilitation of rapid development of new service and business applications through foundation-block-reuse
resource-independent network management
common management information service interface between managing applications and network elements, including legacy simple network management protocol (SNMP).
hierarchical scalability.

The customer management system allows customers to access and update their billing and subscription-related information from across the Internet.

Objectives

address diversity by wrapping elements in a standard protocol
integrate services to network management while maintaining flexibility through a standards-based information architecture
produce a unified application architecture for broadband that can be extended to other legacies
use object technology to reduce deployment lead time

The telecommunications industry has historically relied on advanced technology to provide solutions to complex problems. Legacy systems have proliferated in this drive for new technologies, in turn driven by the need to be competitive.

The victor in this newly created competitive environment was the company who can provide the most value in the eyes of its customer. Value could be in the form of new products and services or increased customer care. Support of the business systems made the value reality.

This is the situation faced by most long distance phone companies. Not only do companies have a large legacy environment to deal with, they find themselves facing the monumental task of offering service to local markets or risk losing market share.

Distributed technology solutions are essential to future system development, but decisions to go this route are deffered considering the cost associated with applying new technology to a mission-critical application.

Objectives

To construct an architecture that meets long-term business and technical objectives
To construct a system that scales to support thousands of users
To build an application, based upon the architecture, to consolidate the functionality of several legacy order entry and management systems
provide integration with provisioning and billing systems.
To enable Internet solutions in support of customer direct policy.

A software architecture best suited for this problem domain would be defined by a component-based layered architecture as referenced in the Logical Architecture Layers diagram. With the components in the higher layers being constructed through the assembly of components in the lower layers. Defining the architecture in this manner simplifies the construction of complex components while maximizing the reuse potential of any specific application component.

Logical Architecture Layers

The architecture specification prescribes the logical organization of the applications and describes the manner in which higher level components were constructed from and the way it interacts with components at the lower levels in the proposed architecture.

The User Interface layer of the architecture would be responsible for implementing the interface between the application, its components, and the system’s user. Specific implementations of the User Interface could be made to bind the operations that are needed for physical implementations such as Motif, Interactive Voice Response, Visual Basic, and so forth.

The Application Services layer of the architecture would be responsible for starting and configuring the application, and managing the lifecycle services of any Business Process components with which the application interacts.

The Business Process layer of the architecture shall contain components that implement a separate business process (such as ordering). The components in this layer would be responsible for managing the lifecycle of the components it contains, the business rules that dictate the use and behavior of those components, and the interaction with any external system or data store required to store or retrieve the information managed by the component.

The Business Concept layer of the architecture would contain components that are shared among the various business process components.
Examples of components in this layer would include Customer, Enrollments, Bill, Billing Plan, etc. These components would contain the business rules that govern the information contained within its context. They would be responsible for the lifecycle of the components they contain.

The Business Foundation layer of the architecture would contain classes that are common to the components in the business concept layer. Examples of components in this layer include phone number, address, location, contact, and so forth.

The Technical Foundation layer of the object would contain classes that are common to any business domain.

The Technical Infrastructure layer of the architecture would contain classes that comprise the infrastructure services needed by all applications. This includes persistence, security, transport, and so forth.

The architecture alone is not always enough to guarantee success. The organization of the team and the software development process being used are critical to any project’s success. Core issues being
the assessment and planning of the application via use cases
domain models, and analysis models,
the actual design and construction of the components.

In an approach case, a general design would be created in which the components that defined a vertical slice of functionality would be designed and implemented. In areas where changes are expected (such as transport mechanism), layers of abstraction would be added to facilitate the future change. Once the vertical slice was implemented and refined, the process would then replicated for the other system components.

This approach results in small, modular components that were easy to design, implement, debug, and understand, significantly reducing the overall development time of projects. It also enables people with very little experience in object-oriented programming to produce solid code within a few short days.