Apr 122010
 

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.

Mar 302010
 

OSS/J defines a common interface structure and SID based data model for the messages that are delivered between different OSS components (FM, PM, TT etc.). It aims to deliver interoperability between those components with minimum effort.

OSS/J initiative (previously by JCP, now TMF) is composed of specifications. Specifications are issued for OSS domains such as trouble ticket (TT), fault management (FM) etc. and they depict the attributes, naming conventions (templates) and mandatory/optional operations for that domain.

These specifications are fully implemented by the OSS vendors who claim that they are OSS/J compatible. The clients (other OSS components in the infrastructure) connect to the server by using these specifications.

OSS/J also provides 3 integration profiles: EJB (Java), JMS (XML) and web services. Profiles are the possible ways that you may connect to the OSS/J servers. A server may implement one of these, or all of these. Some vendors even add other non-standard profiles that enable the legacy clients to connect. The important part here is the nature of the message flow. For example, fault management is asynchronous in nature. So, for me, the best protocol to use would be JMS. For trouble ticket operations, which are synchronous in nature, we may use EJB or web service profiles.

How should we migrate our interfaces to OSS/J? Well, it is better to explain the process with an example.

Suppose, we have a fault management platform and a trouble ticket platform. We have an expert rule deployed in the fault manager that creates a trouble ticket when it receives a specific string in the alarm’s AdditionalText attribute. FM reaches TT via its “legacy” CORBA interface.

Our TT vendor says that their latest product version supports OSS/J TT Specification. (which means they wrote a server which expose OSS/J interface)

Since we want to migrate to that interface, we ask the vendor which version of the specification they have implemented on the server. They replied with the specification number: v1.2. We also learned that we can use EJB (Java) profile to reach their server.

A quick note: most probably, the vendor did not write the whole NBI stack, but they wrote an intermediary OSS/J server which, at the backend, communicates with the old NBI stack over CORBA. (There will be data mapping and conversions between the specifications) This way, they will able to support both CORBA clients and OSS/J clients and reduce time to market.

On the FM side, we need to write an OSS/J TT client that follows the v1.2 specification. (Generally we ask the FM vendor to write it for us). Within the client’s configuration, we will have to specify the connection details to the remote server. After the client is successfully connected to the server, it can issue calls to operations that are implemented on the server.

The important part in here is; if the vendor is saying, “I am OSS/J TT spec v1.2 compliant”; it should define all the mandatory operations that appear in the specification. For the clients, however, this is not mandatory. For example, if I only need to create a trouble ticket within my Fault Management application, and I do not care about closing it, I can implement only the create TT operation from the spec.

OSS/J brings portability. The client would work, in theory, with any TT OSS/J server (vendor) that conforms the same specification. I say, in theory, because most of the time you are required to do minor modifications on your client.

For those, who are interested in OSS/J, you may have a look at the TMF OSS/J site at:
http://tmforum.org/BestPracticesStandards/OSSJAPIs/2923/Home.html

Introduction to eTOM

 NGOSS  Comments Off on Introduction to eTOM
Mar 252010
 

eTOM is a map which categorizes and classifies the business processes of a service provider in a hierarchical structure. It gives us a common vocabulary of processes which brings huge benefits in defining business interactions with other entities such as suppliers, partners and customers. It also acts like a marketing tool where product vendors use to claim their products comply with eTOM and specific processes within it.

The best way to express large volume of information is to present it in a hierarchical structure. eTOM uses decomposition method between it’s elements to expose more details. Each process element in the hierarchy (the boxes), decomposes to more detailed process elements in the next level. Decomposition steps are called “levels”. The leveling starts at level-0 and continues. In theory the maximum decomposition level is limitless however in practice we do not see decompositions above level 7. Current version of eTOM (v8) decomposes the process elements until level-3. There are some level-4 decompositions but level-4 is not common yet.

eTOM gives you the process elements to be used when constructing your organizational business flows. The important detail is, it does not mandate how those process elements should interact with each other or how you should order them. eTOM says, these flows are organization specific and it is impossible to cover every different flow in a generic framework. However, as a guideline, TM Forum provides some common flows as an addendum to the framework documentation.

eTOM can be used to construct business flows of new products/services/policies etc. It’s more common use is to guide the re-engineering efforts. Service providers are applying assessments to themselves to see if their current processes comply with the best practices, if they have duplicate or missing processes that may lead to organizational inefficiencies. I will comment on this topic in another article.

We talked about the levels in eTOM. Understanding the levels are important as they define the scope of the process elements you will see in that particular view.

Level 0 does not give us much detail. It is the place where we see the domain areas that we may encounter in a service provider. SIP (Strategy and Commit, Infrastructure, Product), OPS (Operations) and Enterprise. Within the Level 0, we also see the horizontal groupings. It is important that these groupings align with the SID. Level 0 defines the business activities of a service provider organization.

Level 1 introduces new horizontal and vertical groupings. I will not name them all in here. The important detail is the level-1 vertical groupings are overlays on the framework decomposition hierarchy. In a correct decomposition hierarchy, each element should appear only once. That is because the horizontal ones are chosen in the decomposition hierarchy and the vertical ones are left as overlays. The overlaid ones denote the elements’ nature and help us to locate elements that most-probably appear in the end-to-end process flows such as fulfillment. Level 1 is sometimes called CxO view as it focuses on the horizontal and vertical groupings that should be under the responsibility of CIOs and CEOs respectively.

Level 2 is what we can call the core business process view. Process engineering starts here because this is where the process elements (boxes) appear. We can start building the highest level process flows in this context.

Level 3 is the business process flow view that enables us to draw more detailed flow diagrams.

Level 4 and below belongs to the operational processes and highly specific to organizations. We will see product or service specific processes and procedures in those lower levels.