The TM Forum Integration Framework is a set of standards that supports the interoperability between applications defined in the Application Framework via TM Forum interfaces. The interfaces are defined in terms of the Information Framework’s entities/attributes, and the requirements for the interfaces from a business process perspective, which comes from the Business Process Framework. That is why the Integration Framework is represented as the hub to the spokes of the Business Process, Information & Application Frameworks.
Three types of Business Services are recognized by the Integration Framework:
- Task Service – composed service representing end-to-end business logic
- Entity Service – naturally agnostic to business context, entity lifecycle management
- Utility Service – no business or SME experts required in definition
The TM Forum Interface Program (TIP) has used CORBA, OSS/J & WSDL/XSD to define APIs to support; Service Problem Management, Inventory Management, Security Management, Fault Management, Policy Management and Performance Management through several team efforts; MTNM, OSS/J, MTOSI & IPDR.
Most recently the Open Digital Project has been working to create RESTful APIs for; Product Catalog, Product Ordering and Ticketing. New RESTful APIs under development include; SLA Management, Performance Management, Customer Management, Party Management, Usage, Inventory (Product, Service, Resource) Management, Identity Management and others. Click here for more information on the TM Forum Open Digital Project.
The resource model for the Product Offering RESTful API is shown here and is based on business requirements from the Business Process Framework and defined using the Information Framework. According to the Information Framework a Product Offering “represents tangible and intangible goods and services made available for a certain price to the market” and a Product Specification “defines the functionality and characteristics of product offerings made available to the market.”
The definition of the Product Specification uses the dynamic attribute pattern as shown in the model by the use of the ProductSpecCharacteristic and ProductSpecCharacteristicValue entities. By using this pattern it becomes possible to define new Product Specifications at run time rather than at design time. To see this in action post resources to create your own Product Offering using the implemented Product Catalog RESTful API.
The Product Order RESTful API supports ordering from the Product Catalog and making selections on the choices offered by the Product Specification. These selections are captured in the ProductCharacteristic entity and identify the Product being ordered.
This model has been extended by using RuleX from Nomos Software to implement business rules checking against the data sent in on the order. The rules ensure that the data provided on the order represents a complete and consistent request for the Product selected from the Product Offerings.
You can learn more about RuleX from Nomos and how it provides Self-Service Support for APIs.
Another RESTful API that has been defined by the Open Digital Project supports managing Tickets, for example those needed to track the resolution of trouble as defined by the Process Framework Assurance end-to-end processes as represented in the MagicDraw CBM BPMN2 Problem to Solution diagram shown here, which is based on flows in the TMF GB921-E document.
An implementation of the TM Forum Trouble Ticket RESTful API has been designed using Cameo E2E Builder from NoMagic and what is shown in the figure is the entity model along with the defined persistent states that represent the lifecycle of a ticket.
Using Cameo E2E Builder a Trouble Ticket state machine can be designed that will support lifecycle management of a ticket.
Shown is this figure is the Cameo E2E Builder activity model representing the steps needed to create a new ticket from the input data provided.
Once the model has been successfully compiled it can be run and tested locally with the E2E Builder and a RESTful client (e.g. curl).
It can then be deployed to a Cameo E2E Bridge server and made available for use by RESTful clients wanting to manage Trouble Tickets in support of, for example, the TMF GB921-E Problem to Solution end-to-end scenario.
In this series we’ve shown how the NoMagic MagicDraw Cameo suite of modeling tools can be used to support a Frameworx-based approach to model business processes, business information, application capability and business services.
The business service defines what the organization needs from IT/Network, whether that’s internal to the communication service provider or provided by a third-party. The business service should also define what IT/Network has or can provide to meet the needs of the organization as represented by the business process. From either side, the business service must be defined in terms that can be recognized and understood by business stakeholders. One way to achieve this is to utilize a TMF Frameworx based approach to identifying, defining and implementing the business service and supporting APIs. Just such an approach is what is represented in this overlay of Frameworx onto the TOGAF Metamodel.
That concludes this 5-part series introducing the TM Forum Frameworx suite of best practices and standards that provides a blueprint for effective, efficient business operations for communication service providers and having covered the key considerations of enterprise architecture; business process, information, application and technology.