Professional Documents
Culture Documents
On
OSS/BSS
BY
PRN: 091030
Shared Information/Data Model or (SID) is a unified reference data
model providing a single set of terms for business objects in telecommunications.
The objective is to enable people in different departments, companies or
geographical locations to use the same terms to describe the same real world
objects, practices and relationships.
The SID provides the common language for communicating the concerns of
the four major groups of constituents represented by the NGOSS Viewpoints -
Business, System, Implementation and Deployment, as defined in the NGOSS
Lifecycle. Used in combination with the eTOM business process and activity
descriptions and the Telecom Application Map (TAM) the SID make it possible to
bridge between the business and Information Technology groups within an
organization by providing definitions that are understandable by the business, but
are also rigorous enough to be used for software development.
The SID model takes inspiration from a wide variety of industry sources, but
its principal origins are the Alliance Common Information Architecture (ACIA) created
by a team led by Bill Brook from AT&T and BT and the Directory Enabled Networks -
next generation (DEN-ng) model created by John Strassner.
When initially released in 2000, the SID model covered the business (BSS)
arena well, and also the device management field well, but was insufficient in its
ability to represent logical networks and capacity. These deficiencies are being
addressed through revision of the model to include concepts such as topologies, but
the history has resulted in poor utilisation of the model in certain telecom fields,
notably inventory management.
Lack of flexibility
1. These are rules that cannot be enforced in XML alone. While XML
does an excellent job of ensuring the format integrity of the message
(field lengths, numeric versus alpha-numeric and so on), XML cannot
ensure inter-field dependencies or conditions like this VOIP example.
2. These rules are often obvious to the business yet are not
consistently defined or implemented across multiple integration projects
and can cause significant data quality or operational issues. Typically,
these rules are written in procedural code all over the architecture — in
the adapters, or on the bus.
3. These rules are too simple to warrant the use of business rules
engines, which can perform very complex rules processing but at a heavy
expense in terms of performance and training.