AMKB Cloud Reference Implementation of TMF REST APIs

Posted by cfaurer on February 26th, 2015 filed in Frameworx Consulting, Frameworx Training, REST APIs
Comment now »

The TeleManagement Forum (TMF) has been working as part of their open digital program to define REST application programming interfaces (APIs) in support of multi-partner engagements. This article covers the AMKB Cloud Reference Implementation of the TMF REST APIs.

Specifications have been created by the members of the TMF API Program and cover the following management areas:

The Billing Management API provides standardized mechanisms for billing account, bill item and settlement note advice management either in B2B or B2B2C contexts. [AMKBCloud Billing Management Business Services]

The Customer Management API provides a standardized mechanism for customer and customer account management, such as creation, update, retrieval, deletion and notification of events. [AMKBCloud Customer Management Business Services]

The Party Management API provides a standardized mechanism for party management such as creation, update, retrieval, deletion and notification of events. A Party can be an individual or an organization that has any kind of relation with the enterprise. [AMKBCloud Party Management Business Services]

The Performance Management API provides a standardized mechanism for performance management such as creation, partial or full update and retrieval of the resources involved in performance management (Measurement Production Job, Measurement Collection Job, and Ad hoc Collection). It also allows notification of events related to performance. [AMKBCloud Performance Management Business Services]

The Product Catalog Management API provides a standardized solution for rapidly adding partners’ products to an existing Catalog. It brings the capability for Service Providers to directly feed partners systems with the technical description of the products they propose to them. [AMKBCloud Product Catalog Management Business Services]

The Product Inventory Management API provides standardized mechanism for product inventory management such as creation, partial or full update and retrieval of the representation of a product in the inventory. It also allows the notification of events related to product lifecycle. [AMKBCloud Product Inventory Management Business Services]

The Product Order Management API provides a standardized mechanism for placing a product order with all of the necessary order parameters. The API consists of a simple set of operations that interact with CRM/Order negotiation systems in a consistent manner. A product order is created based on a product offering that is defined in a catalog. The product offering identifies the product or set of products that are available to a customer, and includes characteristics such as pricing, product options and market. [AMKBCloud Product Order Management Business Services]

The SLA Management API provides a standardized interface for Service Level Agreement (SLA) life cycle Management (SLA Negotiation, SLA configuration SLA Activation/enforcement, SLA Operations, SLA violation / consequence handling, SLA reporting) between a Customer and a Service Provider which provides offers (product with attached SLA in its catalogue) the customer can discover, browse, trigger and order. [AMKBCloud SLA Management Business Services]

The Trouble Ticket API provides a standardized client interface to Trouble Ticket Management Systems for creating, tracking and managing trouble tickets among partners as a result of an issue or problem identified by a customer or another system. Examples of Trouble Ticket API clients include CRM applications, network management or fault management systems, or other trouble ticket management systems (e.g. B2B). [AMKBCloud Ticket Management Business Services]

The Usage Management API provides standardized mechanism for usage management such as creation, update, retrieval, import and export of a collection of usages. The API manages both rated and non-rated usage. For example, it allows a service provider:
– To retrieve usage generated by a partner service platform in order to rate it
– To provide rated usage to a partner for consumption follow up purposes. [AMKBCloud Usage Management Business Services]

Additional APIs are under specification:

Resource Catalog Management [AMKBCloud Resource Catalog Management Business Services]

The Resource Inventory API provides standardized mechanism for resource inventory management such as creation, partial or full update and retrieval of the representation of a resource in the inventory. It allows also notification of events related to resource lifecycle. [AMKBCloud Resource Inventory Management Business Services]

Resource Order Management [AMKBCloud Resource Order Management Business Services]

Service Catalog Management [AMKBCloud Service Catalog Management Business Services]

The Service Inventory API provides standardized mechanism for service inventory management such as creation, partial or full update and retrieval of the representation of a service in the inventory. It allows also notification of events related to service lifecycle. [AMKBCloud Service Inventory Management Business Services]

Service Order Management [AMKBCloud Service Order Management Business Services]

A business scenario illustrating a typical customer journey is shown below with highlighting to indicate E2E business process alignment along with reference to a supporting REST API.

AMKB Cloud has implemented a reference implementation of each of the TMF REST APIs listed above using NoMagic MagicDraw, E2E Technologies Builder & Bridge, Nomos RuleX and Swagger UI.

The approach used is model-driven based on the specification from the TMF and includes the following model-driven artifacts:

Business Service Specification – xxxManagementBusinessServices.docx

Swagger UI – swagger.json

Nomos RuleX – xxxManagementRules.json

E2E Builder/Bridge – xUML REST Service

To exercise the AMKB Cloud RI of the TMF REST APIs go to this url: http://swagger-ui.amkbcloud.com

The url for any of the implemented APIs can then be entered into the Swagger UI explore field:

http://12.208.99.92:10000/billingManagement/api-docs

http://12.208.99.92:10001/customerManagement/api-docs

http://12.208.99.92:10002/partyManagement/api-docs

http://12.208.99.92:10003/performanceManagement/api-docs

http://12.208.99.92:10004/productCatalogManagement/api-docs

http://12.208.99.92:10005/productInventoryManagement/api-docs

http://12.208.99.92:10006/productOrderManagement/api-docs

http://12.208.99.92:10007/resourceCatalogManagement/api-docs

http://12.208.99.92:10008/resourceInventoryManagement/api-docs

http://12.208.99.92:10009/resourceOrderManagement/api-docs

http://12.208.99.92:10010/serviceCatalogManagement/api-docs

http://12.208.99.92:10011/serviceInventoryManagement/api-docs

http://12.208.99.92:10012/serviceOrderManagement/api-docs

http://12.208.99.92:10013/slaManagement/api-docs

http://12.208.99.92:10014/ticketManagement/api-docs

http://12.208.99.92:10015/usageManagement/api-docs

Drop us a note if you would like to learn more about the model-driven approach we are using to implement the TMF REST APIs  

Name: *

Email Address: *

Subject: *

Message: *

8 − = four

Model Driven APIs – Swagger & Node.js

Posted by cfaurer on July 23rd, 2015 filed in Frameworx Consulting, Frameworx Training, REST APIs
Comment now »

Thanks to Apigee and their contribution to Swagger to create the new swagger-node project! Enabling model driven APIs – Swagger & Node.js

Swagger-node provides a platform that supports an API design-first development approach. Support exists for popular node.js frameworks – express, hapi, restify, sails and any connect-based middleware.

Our previous work with Swagger has supported a model-driven approach using NoMagic MagicDraw and E2E Builder & E2E Bridge along with Nomos RuleX.

Based on that experience, we’ve been able to quickly leverage the new swagger-node project to apply our model-driven approach quickly and effectively.

We took the existing model we have for the TM Forum Ticket Management REST API and made one primary change to support the ‘x-swagger-router-controller’ extension required by swagger-node to route incoming requests to the specified controller. You can learn more here by reading the controllers.md doc.

From the Ticket Management model we generate the swagger.json specification with support for the ‘x-swagger-router-controller’ extension.

 

The generated swagger.json is imported into Swagger Editor and provides the basis for driving the auto-code-generation feature of the swagger-node project.

Once the swagger.json API specification is verified and validated it’s time to write the controller code to drive the Swagger UI behavior (you can use the mock feature if desired) .

 

Shown below is the GET results retrieved from the Mongoose MongoDB middleware being used to provide persistence for the TicketManagement REST API reference implementation.

Again, thanks to the Apigee and Swagger teams for creating and sharing their new swagger-node project. It provides an outstanding design-driven platform that supports a model-driven approach to API design, development & implementation.

Is your API Smart?

Posted by cfaurer on April 15th, 2015 filed in Frameworx Consulting, Frameworx Training, REST APIs
Comment now »

What is an API and Who’s Using Them?

A simple view on application programming interfaces (APIs) is that they provide a way for users to interact with a business through a well defined touch point. API users could be internal to the business, a business partner and/or the public.

These API users will interact with the business through an API provider and platform using WSDL SOAP and/or RESTful JSON techniques and technologies.

Behind the API provider and platform are the endpoints that provide access to the applications providing the business capability that the API users want to access.

What Kind of Business can APIs Support?

Work is underway at the TM Forum to define APIs that will support doing business with communication service providers (CSPs) – mobile providers, fixed line providers, satellite providers, cable providers, etc.

Shown is a typical customer journey – onboarding, offering, selling, ordering, delivering, using, billing, fixing and canceling products.

API Lifecycle Pain Points

There is a lot of time, interaction and complexity represented in the diagrams shown above. We can categorize the API lifecycle into design, publish and support stages.

 

Each stage of the API lifecycle has its own set of pain points. What are yours?

Make Your API Smart!

Make your API smart to reduce your API lifecycle pain points. In the design stage consider leveraging the industry knowledge and best practice of the TM Forum members by referencing or using the REST API specifications. Adopt a rapid prototyping approach to requirements-design-publish with auto-generation of Swagger UI and RuleX artifacts.

Most importantly, capture your API business rules in the design phase and implement them in the publish phase so that users in the support phase will receive rich diagnostics and auto-help services at run time. This will significantly reduce your onboarding and support costs and time spent by the help desk getting your API users up to speed on your API.

Give Smart APIs a Spin

Try out for yourself smart APIs built by AMBK Cloud using MagicDraw, Nomos RuleX & Swagger UI tooling.

Let’s talk about how we can help you create Smart APIs. 

Name: *

Email Address: *

Subject: *

Message: *

− 4 = four

SDN & NFV are an IT & Network thing! Right?

Posted by cfaurer on April 15th, 2015 filed in Frameworx Consulting, Frameworx Training
Comment now »

SDN & NFV are an IT & Network thing! Right? With an acronym like that it must be an IT & Network thing! But don’t be so sure, in fact SDN & NFV will have dramatic effect on the entire communication service provider enterprise and ecosystem value fabric.

TM Forum Zero-touch, Orchestration, Operations and Management (ZOOM)

“In the European Telecommunications Standards Institute’s (ETSI’s) initial NFV work, a decision was made to assume that existing legacy business and operational support systems (BSS/OSS) would not change and that NFV would be supported by adding new networking and BSS/OSS functions. However, research by the ZOOM team has shown that the ultimate impact of NFV on BSS/OSS will be significant and that it will require transformation not only of service providers’ operational practices, but also of existing BSS/OSS.” from NFV Can it Be Managed?

The next question to ask would be “which business and operational support systems (BSS/OSS) will need to be changed and what’s the impact on business processes?” Work to date done by the TM Forum ZOOM team suggests that these key areas will require significant transformation: PLM, CRM, Service Fulfillment, Service Assurance, Resource Management and Network Management.

SDN/NFV Impact Footprint on eTOM 14.5

What’s the footprint of those areas onto eTOM 14.5? Let’s look at each change area in turn by referring to the eTOM L1 horizontal process grouping impacted.

Frameworx Product Domain

Virtualized network functions will drive  a boon in product offerings supporting shorter and more dynamic product creation and deployment lifecycles. These product offering will rely on on-demand infrastructure changes to support customer and partner requests for self-care capabilities.  Self-service of the product will need to include handling of bundling, versioning, billing, charging, provisioning and inventory considerations.

A key capability offered by NFV is a loosening of the link to the physical realm and thus support for later stage provisioning and on-demand changes. These requirements will necessitate changes that will stretch across the full product lifecycle L1 horiziontal – planning, development, testing, on-boarding, launching, fulfillment, updating, assurance, billing, and more.

A key enhancement to the TMF Frameworx Business Process (eTOM) is still pending completion by the members but will offer a richer and more robust model to represent engaged parties that extend the current Supply Chain and Supplier/Partner L1 horizontal. This will support being able to including engaged party considerations in the discussion of SDN/NVF impacts on the business.

A more holistic view of product lifecycle management will need to be considered, which is aided now that eTOM 14.5 has adopted the Frameworx Domains structure for the L1 horizontal process groupings.

Frameworx Customer Domain

Today customer’s often find themselves having to sort out issues with their CPE and needing to wait for new equipment before things will work again. With the move toward virtualization many of the functions that require a CPE will be replaced with virtual CPE (vCPE) leading to shorter turnaround time in product delivery and maintenance. This benefit to the customer will put more pressure on the service provider to manage and maintain the product per the agreed to SLA.

With vCPE a more dynamic capability will need to be managed per the changing demands of the customer, supported by the changes described in the previous section regarding the Product Domain.

With the introduction of vCPE a much broader set of self-care and self-management capabilities can be offered to the customer spanning – ordering, inventory tracking, fulfillment, assurance, trouble shooting and more.

 

Frameworx Service Domain

To support NFV enabled product offerings the service catalog will need to present service candidates that have been designed to be end-to-end manageable in a Network as a Service environment (NaaS).

Service Order management activities will need to be streamlined and aligned with changes required in Product Order and Resource Order activities and systems as well as with AAA/Identity/Entitlement activities and systems. Service Order capabilities will need to be enhanced to support on-demand requests that will be passed to Software Defined Network (SDN) controllers and/or Policy managers. A critical success factor will be the ability to consistently manage service ordering rules end-to-end across multiple virtualized and physical domains. Further the link between the Service Catalog and Resource Catalog will need to be aligned to support successful Resource Ordering.

Service Activation with SDN/NFV in play creates an expectation that adequate physical capabilities will be available to support end-user initiated, on-demand provisioning. The scenario requiring bottom-up provisioning will require enhanced OSS capability to work closely with SDN controllers to ensure that adequate pre-provisioned resources are available. If not adequate, the OSS will need to trigger a physical provisioning request.

Service Inventory represents the realization/implementation of the Product as Services consuming Resources. With traditional service inventory its possible to track the static configuration information, which supports performing impact and root cause analysis with tracing across the resource-service-product-customer relationships. With the introduction of SDN, support of dynamic paths will be required. It will initially be more difficult to trace across the resource-service-product-customer relationships. OSS capability will be required to; provide visibility of what runs where; to know if the SLA is being met; to know if the service is utilizing resources efficiently (not under or over allocated).

Service Quality management poses significant challenges in the new SDN/NFV environment. Typically today KPIs are not available in the virtual space but only in the physical realm. This will need to be addressed by defining integrated metrics hierarchies between the OSS management realm and the NFV management realm (MANO see figure below). Further, this will necessitate revised and improved business processes that provide a closed-loop link between Assurance and Fulfillment activities.

Service Problem management today typically keeps the Assurance activities separate from the Fulfillment activities and therefore represents an open-loop process. With SDN/NFV that won’t suffice and a closed-loop solution will be required so that a problem with the service may request of capacity planning that additional capability be made available (e.g. more virtual machines) and then be informed when the changes have been made. This will support the requirement for a more dynamic realization of the Product as expected by the Customer as Services and Resources, as discussed previously.

Frameworx Resource Domain

Network Planning, Design & Optimization improvements will be required to ensure necessary and sufficient virtual and physical infrastructure is available based on simulation and analytics capacity projection models. A closed-loop system for optimization will be required, whereby inputs from service quality, traffic prediction, resource utilization, resource performance and more will be required in near real-time to support maintaining necessary and sufficient physical and virtual network capacity.

Resource Inventory management today is quite stable relative to what’s expected to become the norm with NFV capabilities. At the moment, the industry does not have a standardized model for virtualized resources – forwarding graph, VNF such as virtual router, virtual machine, etc. Neither is there an industry standard model to represent the capability and/or capacity of applications (VNF, VM, etc.). Getting new applications on-board is an ill defined process and the focus of standardization efforts. A strength today is that CSPs have a long history and good experience with managing physical network functions. In the NFV enabled environment it will be critical for network changes to be announced and distributed to all engaged parties in near real-time. Further, the scope of control of managed virtual resources will need to be expanded to cover a broader distributed physical platform that will be beyond the immediate control of a CSP.

Configuration Management will need to expand to support a more dynamic and realtime environment made possible by NFV capabilities. Increasing demand from customers for service preferences that meet their particular needs will require more configuration templates be managed according to service delivery rules and on-demand. Management across VNF configurations, physical configurations and service management business and operation rules will need to run in a seamless manner and become much more responsive to market demands.

Discovery & Reconciliation of physical and logical resources must become much more dynamic in order to support virtualized network functions. Today, if a virtual machine (VM) fails it is often moved to a different physical server and restarted. Pre-authorizing and tracking such changes will need to be coordinated between the OSS, resource inventory and the physical and virtual infrastructure. Self-registration, auto-discovery, self-discovery capabilities will need to be enhanced to support the real-time and dynamic change environment of NFV.

Resource Activation of network equipment by an OSS today as part of service activation will consume capacity of only the specific piece of network equipment. This will need to change in order to support OSS activation of NFV, which requires interaction with physical resource inventory to provide the necessary capacity in the hosting physical equipment environment.

Outside Plant will become part of the equation with NFV to ensure support for scaling with diverse path redundancy between data centers. This may require being able to select using different ducts and/or conduits leaving and entering data centers.

Fault Management will need to expand beyond management at the element and network management system and OSS level. The NFV Management & Orchestration (MANO) architecture creates additional points of interaction that must be fault managed. The NFV orchestrator, VNF manager and virtualized infrastructure manager will all need to do their own fault management and coordinate configuration changes with OSS, NMS & EMS in order to support end-to-end, cross-domain impact and root cause analysis.

Performance Management is handled today in a manner similar to fault management in that it is typically the responsibility of the element and network management system and OSS. As seen in the NFV MANO architecture the responsibility for performance management will need to be distributed across NFVO, VNFM & VIM. Additionally, these activities will need to be coordinated and synchronized with inventory, configuration and metrics activities in support of assurance as well as impact and root cause analysis between BSS/OSS and MANO.

SDN/NFV brings new challenges to activities supported by BSS/OSS

An SDN/NFV environment will require dynamic, policy-driven processes that run with real-time responsiveness. Management of this environment will require monitoring and tracking both virtual and physical resources and the services they offer as products to customers. The end-to-end status of the product-service-resource chain will need to be managed to support maintaining proper configuration, capacity, scaling (up and down) in order to meet the dynamic demands of the customer. Dynamic, flexible pricing and revenue sharing models will be required.

To keep such a dynamic environment up and running will require more automation than is in place today with tighter connections between and across design, fulfillment, assurance, billing and revenue management. In other words, much of what is represented by the TMF Frameworx across business activities and processes (eTOM); business, API and system information (SID); business (BSS) and operational (OSS) application capability (TAM); business services and APIs (Integration Framework) and business metrics (Metrics).

This work is underway by the TMF members participating in and contributing to the ZOOM and Frameworx team deliverables. Join your colleagues and get involved in defining the future!

Name: *

Email Address: *

Subject: *

Message: *

+ four = 13

Adapted from “SDN & NFV – Impacts on OSS” TMF ZOOM project contribution

Onboarding – a challenge and cost in API Management

Posted by cfaurer on April 1st, 2015 filed in Frameworx Consulting, Frameworx Training, REST APIs
Comment now »

How can you keep your support teams from having to answer the same questions all the time about using your APIs? How can you reduce these costs of time and money to your API Management program?

Well, how about providing solid documentation and real-time feedback on how to use your APIs! That’s what AMKB Cloud and Nomos Software have done with the REST APIs specified by the folks at the TM Forum Frameworx API Program, of which AMKB Cloud is an active contributor.

What we’ve done is to use the specification from the TMF Fx API Program as the basis for the documentation of the implementation of the REST API. This includes:

• model generated Business Service Specification
• an API specification that works with Swagger UI
• model generated RuleX business rules in json5 format

The result is an implementation of the TMF Fx REST APIs that provide automated technical support for developers working to use the API 24 hours a day and 7 days a week.

Here’s a snippet from the Customer Management API Specification generated from the AMKB Cloud model of the business service:

From the documentation we can see what’s required to create a valid PaymentMean request dataset as the required attributes and entities are specified. We can also see that there are several business rules defined for the BankAccount entity.

The model represented in the document snippet shown above is the source used to generate the swagger.json file that drives the Swagger UI shown here:

The  swagger.json that is driving the Swagger UI is shown here:

If you look closely at the swagger.json specification you will see that it matches what was defined in the business service specification doc, as expected.

The last piece needed is the RuleX json5 file generated from the model of the API:

The swagger.json and customerManagementRules.json5 files generated from the AMKB Cloud model of the business service are the required inputs to the Nomos Software RuleX validator and result in a  customerManagement.war that is deployed to a rules server. The RuleX war is called by the Reference Implementation (RI) of the REST API (to learn more about how this is done visit – TMF Fx & Nomos RuleX, Cameo E2E Builder/Server – Part 5)

Let’s try out the AMKB Cloud RI of the Customer Management REST API with Nomos Software RuleX validation.

Notice that the Swagger UI is using the swagger.json generate from the model and that the default values set in the model are driving the user interface.

And the response of the create request shows that the new PaymentMean has been created behind the API:

So, by default a valid create PaymentMean dataset is provided by the Swagger UI being driven by the model, specification and swagger.json. What if we make a mistake? What happens then? Let’s change the PaymentMean type from DD, which stands for Direct Debit, to Credit and see what happens:

You may have noticed that there are 25 business rules defined for the Customer Management API and they provide feedback similar to what’s shown above. What went wrong and where.

So, what can be done to reduce the time and money spent supporting API Management?

Give us a call and let’s talk about how we can help. 

Name: *

Email Address: *

Subject: *

Message: *

seven + 3 =

 

MVNO Wireless – TMF Fx eTOM, SID, TAM & REST APIs

Posted by cfaurer on March 24th, 2015 filed in BPMN, Frameworx Consulting, Frameworx Training, REST APIs
Comment now »

I have a phone that I purchased from Google that uses a SIM card and minutes purchased from a reseller for an MVNO, which depends on a network operator. Can these engaged parties and their various relationships be understood as MVNO Wireless – TMF Fx eTOM, SID, TAM & REST APIs?

We’ll see! That’s the goal of this series of articles. In part-1 we’ll outline the scope of the scenario introduced above using TMF Fx eTOM, SID, TAM & REST APIs covering E2E business scenarios: C2M, O2C, U2P and T2R.

A Mobile Virtual Network Operator (MVNO) does not manage it’s own network, rather it buys network capability in bulk and resells it to end customers. A SIM card reseller has a similar business model in that it resells the MVNO service as it’s own product offering.

The handset provider utilizes industry standard specifications and engaged party relationships to ensure that the mobile device it sells will operate on the specified 2G, 3G and 4G networks. The mobile network operator (MNO) provides access to the network infrastructure that makes using the mobile device possible for voice, data, text and video services.

Who will purchase the product offerings and use the services and resources provided? The customer.

The engaged parties discussed include; customer, mobile device provider, SIM & minutes reseller, MVNO and MNO.

The TMF membership have defined 4 key business scenarios that are of interest to us:

• Concept to Market (C2M)
• Order to Cash (O2C)
• Usage to Payment (U2P)
• Trouble to Resolve (T2R)

Concept to Market (C2M)

Adapted from TM Forum QuickStart Pack – GB955_Concept_to_Market_v0.4

SID Business Entities supporting C2M

Mappings adapted from GB942MAP

TAM Application Capability supporting C2M

Mappings adapted from GB942MAP

Business Services supporting C2M

Order to Cash (O2C)

Adapted from TM Forum E2E Business Scenarios – GB921_E_Release 13-5_v1-13-2

SID Business Entities supporting O2C

Mappings adapted from GB942MAP

TAM Application Capability supporting O2C

Mappings adapted from GB942MAP

Business Services supporting O2C

Usage to Payment (U2P)

Adapted from TM Forum E2E Business Scenarios – GB921_E_Release 13-5_v1-13-2

SID Business Entities supporting U2P

Mappings adapted from GB942MAP

TAM Application Capability supporting U2P

Mappings adapted from GB942MAP

Business Services supporting U2P

Trouble to Resolve (T2R)

Adapted from TM Forum E2E Business Scenarios – GB921_E_Release 13-5_v1-13-2

SID Business Entities supporting T2R

Mappings adapted from GB942MAP

TAM Application Capability supporting T2R

Mappings adapted from GB942MAP

Business Services supporting T2R

The material presented represents the general scope of the engaged party scenario based on TM Forum Frameworx content – a phone purchased from Google that uses a SIM card and minutes purchased from a reseller for an MVNO, which depends on a network operator. Is this the necessary and sufficient material required to understand this business scenario?

TM Forum Frameworx & TOGAF

A validation that the material presented does provide a solid base understanding of the business scenario is represent by the figure above showing the relationship between The Open Group Architectural Framework (TOGAF) and TM Forum Frameworx – Process Framework (eTOM), Information Framework (SID), Application Framework (TAM), Integration Framework (Business Services & APIs). Available from TMF Fx but not covered are Business Metrics.

Assignment of activities to roles in the organization is beyond the scope of responsibility of TMF Frameworx and therefore TBD.

In the next article we’ll look at each TMF Frameworx eTOM E2E scenario in turn – C2M, O2C, U2P and T2R for the MVNO Wireless example.

TMF Fx & Nomos RuleX, Cameo E2E Builder/Server – Part 5

Posted by cfaurer on March 3rd, 2015 filed in Frameworx Consulting, Frameworx Training
Comment now »

TMF Fx & Nomos RuleX, Cameo E2E Builder/Server are used together to implement the TMF REST APIs. 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.

You’ll also find implementations for Product Ordering and Ticketing that you can try out.

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.

TMF Fx TAM & MD Cameo Business Modeler – Part 4

Posted by cfaurer on March 3rd, 2015 filed in Frameworx Consulting, Frameworx Training
Comment now »

TMF Fx TAM & MD Cameo Business Modeler are used together to provide a BPMN based model of application capability that can be used by a typical Service Provider to implement their business activities. The Frameworx Application Framework provides a common language for communities who specify, procure, design, and sell operation and business support systems, so that they can understand each other’s viewpoints. It provides logical groupings of applications, then defines each application’s offered functionality.

The logical grouping of applications follows the lead set by the Information Framework and reuses the management area domain-based approach. The Application Framework has the same 7 core domains and adds 2 more; Cross Domain and Integration Infrastructure.

Frameworx defines an application to be a set of one or more software artifacts consisting of well defined functions, data, business flows, rules and interfaces. Applications are implementable as a deployable package, and procurable in the system market place.

Applications support Business Process Framework business activities and this mapping in the model can be used to produce a report that looks like the following:

[gview file=”https://www.amkbcloud.com/blog/?p=287″]

Another way to represent the applications needed to support a given business process is to use a Dependency Matrix diagram:

The next step in this series is to explore the Integration Framework, which provides a definition of business services that can be used by business tasks to gain access to the provided application capability and needed information.

TMF Fx SID & MD Cameo Business Modeler – Part 3

Posted by cfaurer on March 3rd, 2015 filed in Frameworx Consulting, Frameworx Training
Comment now »

TMF Fx SID & MD Cameo Business Modeler are used together to provide a UML model of business entities that can be used to support defining a typical Service Provider’s activities. The Frameworx Information Framework provides a reference model and common vocabulary for all the information required to implement Business Process Framework processes. It reduces complexity in service and system integration, development and design by providing an off-the-shelf information model that can be quickly adopted by all parties.

There are two perspectives to the Information Framework; one is as an information model and the other is as a data model, which is based on the information model.  Therefore the Information Framework can be used to harmonize both information and data models from other sources.

The Information Framework enables reuse via the separation of a technology neutral (information) model from a technology specific (data) model.  More than one data model can be generated or developed from a single base information model.

Several existing models and sources of requirements contributed to the creation of the Information Framework: ITU-T M.3100 generic network information model; and DMTF CIM definition of management information for IT systems, networks, applications and services. A continuing source of requirements for the Information Framework is the Business Process Framework.

Behavior is not modeled in the Information Framework as that is addressed by the TMF Frameworx Integration Framework. What is modeling in the Information Framework are the things of interest to the business (entities), relationships between things (associations) and the details that characterize things (attributes).

The Information Framework was designed bottom-up by recognizing the things of interest to the business. These may be tangible, active or conceptual things. Business entities are characterized by attributes and participate in relationships with other business entities. Business entities typically move through a well defined lifecycle and a good source of requirements for understanding this behavior can be found in the Business Process Framework L2 definitions.

Information Framework Business Entities are grouped into Aggregate Business Entities (ABE), which represent a well defined set of information that characterizes a highly cohesive set of entities, loosely coupled with entities in other ABEs.

Collections of ABEs associated with specific management areas are grouped into domains, which are consistent with the L1 horizontal process groupings in the Business Process Framework.

The 7 management areas represented above, plus the Common Domain, provide the primary organizing mechanism for the Information Framework  as shown in the Information Framework Domain and L1 model:

In total the TMF Frameworx Information Model contains 1,500+ classes along with their associations and attributes, which can be represented at the highest level as a set of interacting management areas, or Domains:

At the class level the core structural model of Frameworx, which supports the top-level Domain interaction model is shown here:

This static, end-state class diagram can be understood by referring back to the Business Process Framework and recognizing that the information represented here is governed, designed, implemented, managed and operated by L2 business processes that reside in most of the L1 vertical and horizontal process groupings.

A mapping between the Product Domain L1 ABEs and the primary as well as secondary Business Process Framework L2 business processes can be generated from the model to produce a report that looks like the following:

[gview file=”https://www.amkbcloud.com/blog/?p=285″]

We can see from these sample mappings that the Business Process Framework activity requires information, which can be defined by using the Information Framework.

The next step in this series is to explore the Application Framework, which provides a definition of types of capability that might be required to support business activity and provide access to the needed information.

TMF Fx eTOM & MD Cameo Business Modeler – Part 2

Posted by cfaurer on March 3rd, 2015 filed in BPMN, Frameworx Consulting, Frameworx Training
Comment now »

 

 TMF Fx eTOM & MD Cameo Business Modeler are used together to provide a BPMN based model of typical Service Provider business activity. The Business Process Framework is a hierarchical catalog and classification scheme of the key business processes required to run a service-focused business.

At the conceptual level, the framework has three major level o process areas, reflecting major areas of focus within typical enterprises:

• Strategy, Infrastructure and Product
• Operations
• Enterprise Management

The Strategy, Infrastructure & Product (SIP) process area includes processes that develop strategy, commit to the firm, build infrastructure, develop and manage products, and that develop and manage the Supply Chain.

The Operations (OPS) process area is the traditional heart of the Communication Service Provider (CSP) enterprise, and of the Business Process Framework. It includes all operations processes that support the customer (and network) operations and management, as well as those that enable direct customer operations with the customer. These processes include both day-to-day and operations support and readiness processes.

The Enterprise Management process area includes basic business processes required to run any business. These processes focus on Enterprise Level processes, goals and objectives. These processes have interfaces with almost every other process in the enterprise, whether operational, product or infrastructure processes. These are sometimes considered corporate functions and/or processes.

The SIP and OPS Process Areas are subdivided by both horizontal and vertical level 1 process groupings:

 

Process decomposition of the TMF Frameworx Business Process Framework proceeds along the level 1 horizontal process groupings for both the SIP and OPS process areas. Shown below is an MD Cameo Business Modeler BPMN Processes Structure Map diagram of the SIP L0 with its 4 L1s and subsequent L2s.

 

The level 1 vertical process groupings represent a view of end-to-end processes within the business, such as those involved in the overall strategy setting and gaining commitment from the stakeholders. Vertical end-to-end processes typically span organizational boundaries, and so the end-end effectiveness of these processes is an area of concern to senior management and particularly the CEO. Vertical process groupings thus represent the C-level view of the Business Process Framework.

The Assurance vertical end-end process grouping is responsible for the execution of proactive and reactive maintenance activities to ensure that services provided to customers are continuously available and performing to SLA or QoS performance levels. It performs continuous resource status and performance monitoring to proactively detect possible failures. It collects performance data and analyzes them to identify potential problems and resolve them without impact to the customer. This process manages the SLAs and reports service performance to the customer. It receives trouble reports from the customer, informs the customer of the trouble status, and ensures restoration and repair, as well as ensuring a delighted customer.

Within the Assurance vertical at the L1 CRM horizontal is an L2 process responsible for receiving trouble reports from customers, resolving them to the customer’s satisfaction and providing meaningful status on repair and/or restoration activity to the customer. This process is named Problem Handling and is shown here with complete hierarchical decomposition to the L4 leaf level of the TMF Business Process Framwork:

 

The L3 Isolate Customer Problem process is tasked with identifying the root cause of the customer problem. The responsibilities of these processes include, but are not limited to:

• Verifying whether the customer is using the purchased product offering correctly; and
• Performing diagnostics based on the customer provided information to determine whether the root cause of the customer problem is linked to the underlying services.

The Isolate Customer Problem processes will make the results of the root cause analysis available to other processes. The Isolate Customer Problem processes will update the open customer problem report, as required during the assessment, and when the root cause has been identified. The Isolate Customer Problem processes will notify the Track & Manage Customer Problem processes when the analysis is complete.

This defined activity can be represented using an MD Cameo Business Modeler BPMN Process Diagram for an Isolate Customer Problem L4 flow:

In total the TMF Business Process Framework version 13.5 contains 1,407 process elements organized in the decomposition hierarchy introduced in this article. The Business Process Framework is used by CSPs to support many business needs, including but not limited to:

• Scope
• Assess
• Gap Analysis
• Plan
• Measure
• Review
• Adjust

In this Part 2 of the series we looked at TMF Fx eTOM & MD Cameo Business Modeler. In the next article we’ll look at the TMF Frameworx Information Framework also known as the SID and how it relates to the Business Process Framework.

TMF Frameworx & MD Cameo Business Modeler – Part 1

Posted by cfaurer on March 3rd, 2015 filed in BPMN, Frameworx Consulting, Frameworx Training
Comment now »

The TeleManagement Forum is a global trade association with 1,000 member companies representing 100,000 professionals in 195 countries. The TM Forum is focused on bringing together the digital ecosystem, including communication service providers, digital service providers and enterprises, with the goal of enabling an open digital world. This series of articles introduce TMF Frameworx & MD Cameo Business Modeler and how it is being used to model the Frameworx reference material.

Frameworx is the TM Forum suite of best practices and standards that provides the blueprint for effective, efficient business operations. It enables you to assess and optimize performance using a proven, service-oriented approach to operations and integration. Frameworx is build on a services oriented design and uses standard, reusable, generic blocks that can be assembled in unique ways to gain the advantages of standardization while still allowing customization and enabling differentiation and competition  at the service level.

The components that comprise Frameworx are:

1. Business Process Framework
2. Information Framework
3. Application Framework
4. Integration Framework
5. Business Metrics
6. Best Practices

The Business Process Framework is a hierarchical catalog and classification scheme of the key business processes required to run a service-focused business. At the conceptual level, the framework has three major process areas, reflecting major focuses within typical enterprises:

• Strategy, Infrastructure and Product
• Operations
• Enterprise Management

The Information Framework provides a reference model and common vocabulary for all the information required to implement Business Process Framework processes. It reduces complexity in service and system integration, development and design by providing an off-the-shelf information model that can be quickly adopted by all parties.

The Application Framework provides a common language for communities who specify, procure, design, and sell operation and business support systems, so that they can understand each other’s viewpoints. It provides logical groupings of applications, then defines each application’s offered functionality.

The 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.

TM Forum Business Metrics provide a balanced scorecard across finance, customer and operations areas.

• Revenue and Margin – financial performance indicators such as OpEx as a % of revenue or recovered leakage
• Customer Experience – indicators from the customer-facing side of the business
• Operational Efficiency – indicators around the key operational process areas of fulfillment, assurance, bill and call center

Best Practices provide practical tools that leverage Frameworx and help to improve end-to-end management of services across complex, multi-partner environment.

In the next part of this series we’ll look at how TMF Frameworx & MD Cameo Business Modeler can be used together to represent Frameworx material as a model using MagicDraw Cameo Business Modeler.