Introduction to SID

SID (Shared Information and Data model) is one of the frameworks of the TMForum NGOSS Frameworx suite. It is also called the Information Framework. SID can be considered as the language of the NGOSS. It helps us to identify the business entities that play role in the business processes of a telecommunications service provider.

As I mentioned in my previous eTOM article, eTOM is the framework that identifies the business processes of a service provider. When modeling the business processes, we have to involve some business entities. For example, suppose, in an end-to-end fulfillment process, a customer selects a product offering from the product catalog to buy at a specified price. During his/her interaction with the order fulfillment system, he/she also specifies some attributes of the product he/she is buying (such as the color of the physical resource that will be delivered). Along with this resource, and as part of the product, he/she also buys a service (a communication service such as DSL). The process goes on until the customer order is successfully delivered to the customer.

Some of the entities that play role in this specific scenario can be listed as customer, product catalog, product, service, resource, price, offering, order and interaction. All of these entities are the subjects of the SID framework.

SID helps you to find out the domain objects and their relationships between them when you are designing an NGOSS solution. Business domain analysis is a very time consuming and complex step in system analysis & design phase. It is complex because you need to know the domain very well. (That’s why we require analysts in the projects).During the analysis, you should identify the entities that should appear in the domain. The analysis should also include the relationships and dependencies between those entities. For a telecommunications provider, luckily, this analysis is ready for us to use. SID provides a ready-to-use domain model, based on the best practices, which can be directly applied to the new or re-engineering projects. Using SID in the analysis & design phases saves us a lot of time.

SID is the Information “and” the Data Model. Let me explain what this means. Information models are more abstract models that aim to tell us the inner workings or let’s say the nature of the modeled system. They look from the “business view” perspective. The data model, on the other hand, appears when you make this information more concrete. (When you apply it as a database system or a class diagram) In the information model, I may have abstract domain objects, but in the data model, I may not prefer to implement them at all. (I may want to implement those multiple objects as one object)

I really cannot see the “data model” part in SID. The data model is the model an enterprise architect should draw and it is enterprise specific. It could be seen as the technology and application independent, “system view” perspective of the logical information model.

SID and eTOM goes hand-in-hand and TMForum provides mappings between them. SID Domains are consistent with the eTOM domains. The Domains include the Level 1 ABEs which are also mapped to eTOM Level 2 business processes. What an ABE is? Well, it is the abbreviation for Aggregate Business Entity, which means an entity that can further be decomposed to other sub-entities. (Just like the decomposition we see in the eTOM hierarchy).
SID Business Entities are modeled in UML diagrams and can be imported to UML tools. (TMForum publishes them in different importable formats). The framework also comes with an extensive documentation that explains the structure and the behaviors of the business entities. Typically, you will find an abbreviation document for each ABE.

Today, OSS application vendors are more NGOSS aware and they try to design/re-design their products based on NGOSS. In order for two different OSS systems to communicate effectively, their data structures should be consistent with each other. This way, it will require minimum conversion during the conversation. OSS/J enables this on the API level but the data structure of the application is also important. Using SID in designing applications eases the integrations between the different applications. Explaining your OSS product in SID terms will also be appreciated by your customers and supplier/partners.