|
|
article page | 1
| 2 | 3 |
Using the SID as an exchange data
model, to which each system interface
needed to be mapped just once,
it was possible to reduce integration
costs and timeframes by over 50%.
Further, as systems are upgraded,
added, or replaced, the use of
the SID as a common data model
for integration “future proofs” the
integration by ensuring that systems
can change without impacting other
systems with which they are exchanging
data.
|
|
Is the SID Model Enough? The short
answer is “not always.” |
|
|
interoperability that is required
to define the relationships
between all the systems and
services in this business,
must, by necessity be quite
complex. The model is
complex because it must be
large enough to support the
sheer scope of the domain and
abstract enough to promote
the reuse of concepts used
in the integration. Because
of this, sophisticated tools
are necessary to visualize
|
|
|
|
In complex OSS/BSS environments such
as this one, which supports a large
number of systems, it is clear that
a SID-based data abstraction is necessary
in order to support rapid and flexible
integration. Although the SID model
may at first seem daunting, its adoption
as a tool for integration can be dramatically
simplified with tools that make it
easy to navigate, display, and interact
with the SID. And perhaps most important,
to map application interfaces to the
SID model and generate the runtime
services that support true any-to-any
interoperability in a loosely coupled
architecture.
Is the SID Model Enough?
The short answer is “not always.”
For one thing, not everyone will adopt
the SID model in all places at the
same time. Many legacy systems, whether
internally developed or vendor supplied,
will remain in place for the foreseeable
future and retain their underlying
data models. Therefore there is a significant
need for tooling that will support
mapping between application- or service-specific
data structures and the more abstract
SID model details.
In addition to this, the SID model
is organized generically. It
provides an abstract view that is intended
to model the entire business operation
of a telecommunications service provider. Unfortunately,
a model that is rich enough to model
a business as complex as this, and
to support the degree of
|
|
the SID model and to map application-specific
views to it.
On the other hand, experience has
taught us that no generic data model
can anticipate all existing and future
use cases that may eventually need
to be modeled. While the SID
model does a great job of providing
a very comprehensive model of a standard
service provider’s business,
there still may be enterprise-specific
extensions required to model a particular
company’s business.
When a service provider adopts the
SID model, they will likely find
that it does not have all the attributes
required to model its business, or
that the way that it represents these
attributes are not well aligned with
the way the business thinks about
them. It is tempting to change and “flatten” the
SID model, either in UML tools or
in XSD representation of the SID.
However, this results in a deviation
from the standard that will make
it difficult to adopt future enhancements
of the standard. It is therefore
preferable to have tooling that will
allow the SID model to be enriched
with mapping shortcuts and extensions
without deviating from the standard
implementation of the SID.
This is where the concept of computed
or virtual attributes can be valuable.
These are attributes that do not
exist in the SID model but are useful
to use to map concrete data elements
that are represented in abstract
......
|
article
page | 1 |
2 | 3 |
|
|
|
