Cliff Faurer

Avatar

Cliff C. Faurer has spent 20+ years in the Software and Communications industries developing and implementing technical strategies. He is currently a Principal at AMKB Cloud, which provides consulting and training with TMForum Frameworx suite of best practices and standards. TMF Frameworx is used by ICT & Media enterprises as a blueprint for effective, efficient business operations. Contributor to TMF Digital Services Initiative and mentor at TMF sponsored Hackathons to promote use and adoption of TMF REST management APIs; product catalog, product order, trouble ticket & simple management. His technical management responsibilities include software system specification for Wipro, Qwest, US WEST, TeleManagement Forum. With Wipro at Dish Network, Cliff worked to identify, define and support implementation of SOA Services for Dish’s business transformation initiative. Goals of the engagement included reducing the number of order entry applications along with creating reusable business services (process, task and entity service types). He holds a BS degree in Electrical Engineering and an MS in Telecommunications.

Mar 022015
 

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.

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]

Resource Inventory Management [AMKBCloud Resource Inventory Management Business Services]

Resource Order Management [AMKBCloud Resource Order Management Business Services]

Service Catalog Management [AMKBCloud Service Catalog Management Business Services]

Service Inventory Management [AMKBCloud Service Inventory Management Business Services]

Service Order Management [AMKBCloud Service Order Management Business Services]

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.

Mar 312014
 

FrameworxLogo-IntegrationThe 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.

RESTful-API- ProductOffering

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

RESTful-API- ProductSpecification

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.

RESTful-API- ProductOrder

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.

RESTful-API- ProductOrder-NomosRules

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.

GB921-E-ProblemToSolution

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.

E2E-Builder-TroubleTicket

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.

E2E-Builder-TroubleTicket-StateMachine

Using Cameo E2E Builder a Trouble Ticket state machine can be designed that will support lifecycle management of a ticket.

E2E-Builder-TroubleTicket-AddNewTicket

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.

E2E-Builder-TroubleTicket-TestCase

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.

AMKBCloud-TOGAF-Fx

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.

Mar 162014
 

FrameworxLogo-TAMThe 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.

TAM Domains

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:

Download (PDF, Unknown)

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

ProductManagementApps-BusinessProcesses

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.

Mar 162014
 

FrameworxLogo-SIDThe 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.

eTOM Domains

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:

SID 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:

SID Domains Model

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

ProductSpec-ProductOffering-Product Model

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:

Download (PDF, Unknown)

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.

Mar 132014
 

FrameworxLogo-eTOM

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 focuses 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:

eTOM-L1

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.

SIP to L2

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.

Strategy&Commit to L3

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:

Problem Handling to L4

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:

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 the next article in this series we’ll look at the TMF Frameworx Information Framework also known as the SID and how it relates to the Business Process Framework.

Mar 122014
 

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

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 Frameworx material can be represented as a model using MagicDraw Cameo Business Modeler.