Compass Catalyst 14052010 Final

Catalogue Data Driven
Order Automation

Catalyst Presentation

1
Copyright © 2010 TeleManagement Forum, All Rights Reserved.

Agenda
 HT requirements for COMPASS –
Catalogue Data Driven Order Automation
 To have integrated processes for online and voice
services

 Overview: Catalyst demo setup
 what is the purpose, what will be demonstrated …
Contacts:
Dominik Periškić, Croatian Telekom
dominik.periskic@t.ht.hr
Damir Medved, GDi Systems
Damir.medved@gisdata.com
John Wilmes, Progress Software
jwilmes@progress.com
Dr. Aug.-Wilh. Jagau, Telcordia
ajagau@telcordia.com

2

Prologue: What is …

THE COMPASS PROJECT?

3

COMPASS Project Targets

 The solution will enable T-HT:
 to support voice and Internet based services with a set of
integrated business processes
(order management, technical complaint management, billing,
complaint management, dunning, etc.)
 Processing orders for voice and Internet based services as a
single order to better deal with service interdependencies
 Keep synchronized the provisioning of voice and Internet
based to better optimize use of network resources
 Replacement of legacy IMF system (highly integrated system
that has all features form CRM to Activation) with standards
oriented, flexible solution

4

Project Targets – Services Covered in Phase 1
 This solution will cover customer administration, order management,
billing, and provisioning of all Internet services including:
 Dialup subscriptions
Net Plus, Net Super, Net Office
 ADSL account and traffic
e-mail accounts and quotas, free webhosting, IP backup
 IPTV
account, additional services, different TV packages
 Web hosting
Unix, Windows, quotas, different databases (MySQL, SQL Server)
 Private network (VPN) products
remote access, VPN backup
 Hosted Exchange
corporate e-mail accounting
 Office Intranet
SharePoint hosting
 Hot spot
subscription

Existing products can be upgraded and new products can be
5
configured so as to utilize assets newly added to network resources.

Project Targets – Key Processes Covered in Phase 1

 Key Processes Covered:
 ADSL and Dialup Access Provisioning
 E-Mail Service Provisioning
 IPTV Service Provisioning
 Web Hosting Provisioning
 Fraud Deterrence / Fraud Detection
 Helpdesk Support
 DNS Management

6

T-HT Landscape 1: Voice Centric
Period of 1998 – 2003

7

T-HT Landscape 2: OSS’s Consolitdated
end of 2004

8

T-HT Landscape 3: Billing Consolidated
end of 2008

9

COMPASS Design Topics
 Voice and on-line fulfillment and assurance
processes highly automated but independent
 High cost of maintenance – detached, separate systems
 Assembly and correlation of new products difficult
 Two interfaces to billing system
 Significant manual activities – automating transitions
between on-line and compound services difficult (eg.
Voice + Dial-up to broadband 3Play) and lengthy
 Solution is to change entire paradigm following
TMF “Lean Operator” model, and to introduce new
thinking during conceptual design of the new
systems

10

TMF Recommendations that Influenced COMPASS

GB921 eTOM Concepts and Principles V 8.10

GB921-D Process Decompositions and Descriptions V 4.00

GB921-F eTOM Process Flow Examples V 4.00

GB921-U User Guidelines for eTOM V 1.10

GB929 The TAM - The BSS/OSS Systems Landscape V 2.10

GB929 The TAM - The BSS/OSS Systems Landscape V 3.00

11

COMPASS Alignment with TMF TAM
Product Product Strategy /
Proposition
Product Catalog Product Lifecycle
Management Management
Management Management

Customer
Customer Self Management

Customer Service /
Mgt
Order Mgt Account Problem
Resolution

Service
Service

Inventory Mgt SLA Mgt
Service Service
Specification Design /
Service
Mgt

Mgt Service Assign
Problem
Config Mgt Mgt

Resource
Resource
Resource

Design /
Inventory Assign Resource
Mgt
Activation
Resource
Provisioning /
Mgt

Configuration Resource Resource
Resource Planning/ Problem
Specification Optimization Management
Management Resource
Logistics
Res. Domain Mngmnt. (IT Applic., Network)

Operations Support
& Readiness Fulfillment Assurance
The TAM R2.1
DCAT Expediter Granite Activator

12

COMPASS Architecture Objectives
 Support a flexible approach to product / service modeling
 Foster reusability of resource components
(optimize resource consumption with help of catalog)
 Create order management and fulfillment processes
entirely driven by catalogue data
 Under business rule control select from several feasible
alternatives the solution which make the most sense from
a network and/or operations perspective
 Make workflow control catalogue data driven
 Employ standardized (Move / Add / Change / Delete)
operations for interworking with non-COMPASS systems
 Leverage TMF frameworks (eTOM, SID, TAM)
to design of solution
13

Product vs. Service Catalogue
Product
CRM System Catalogue
Billing (order entry) (product bundles,
availability control,
pricing / discounting)

Work Force Order Manager
Management (flow controller)

Service
Provisioning Management Catalogue
(automated assignment and (order decomposition,
network rearrangement) solution selection,
MACD processing,
resource provisioning)
Service Inventory
(network inventory) OSS Control

Service
The Network
Activation
14

COMPASS Architecture

Customer Relationship Manual Task
Billing Management Management
Order Entry/Negotiation Work Force

Enterprise Service Bus

Order Orchestration Order Decomposition Feasibility Analysis Service Activation

Expediter Dynamic Resource Activator
Service Catalog Components

Granite Inventory Customer Number
Manager (CNUM)

Geographic Information
System

15

Flow of Information Through COMPASS
Product & CFS Customer Orders /
References Product Instances

PLM OSS

Service Resource
Modelling Provisioning
and Service
Activation

Product / Service / Resource Solution Instances
Models
Service Inventory
Specifications of Network Updates
and Service Capabilities
16

COMPASS Catalogue Data Uses

Order Entry

Order Verification

Order Decomposition

Provisioning

Work-Order Dispatch

Service Activation

Service Turn-On
Order Information
Forms Layout Information
Service Topology Data
Business Rules
Order Work-Flows
Network Relevant Data
OSS Reference Data
Resource Optimization Rules
Exception Handling Data
Transaction Roll-Back Procedures

17

Request eXchange Interface

INTERWORKING COMPASS
WITH EXTERNAL SYSTEMS

18

Original COMPASS

Workforce
CRM System O-IF Billing
Management

O-IF
O-IF

O-IF
O-IF

COMPASS
O-IF The Resource
Order O-IF
DCAT Engine Components
Manager

Original IF’s Service Service
Catalog Inventory
SW Mandated IF’s

19

Challenge Re-Using COMPASS Solution

70%+ of respondents spend more
than 40% of their project on data
integration
• COMPASS uses approx. 40
different message types
• each message type has an
average of 60 data items

A whopping 70% describe data
integration as challenging or very
challenging
• COMPASS is interworked with
four other systems at T-HT
• all of these systems are T-HT
specific
Surveys from TM Forum Events 2008
20

Interworking COMPASS Using SOA Ideas

Business Process
Management

Data Interoperability

Management of
Enterprise Services

21

Data Exchange Via Intelligent Services Layer

Utilize a common
model to provide a
common context
across the process

Abstract physical
interface definitions
by mapping to a
common model

22

COMPASS+: Enhanced by Semantic Integrator

BPM
Business Process
(eTOM – Business Process
Framework)

Enterprise-wide SID Common Data Model
Market
Information Partner
Customer
Product
Resource
Framework Service
(SID –information Common
Framework)

Systems Integration
Framework ENTERPRISE SERVICE BUS
(TNA – Systems Integration
Framework)

Applications NMS Inventory OMS Billing CRM
Framework
(TAM –Application
Framework)

23

RXI*: Enabling Future Solutions
Product Workforce
Catalogue CRM System Billing
Management
(BSS Level)

Enterprise-Wide Message Schemas
(managed with Semantic Integrator)

Service Delivery
Order Resource
DCAT and Activation
Manager Components Platforms

Semantic Integrator
Facilitated Interface Service Service
Interface Pre-Built w/ Catalog Inventory
Semantic Integrator *RXI: Request eXchange Infra-Structure

24

Catalogue Data Driven Order Automation

DCAT THEORY OF OPERATIONS

25

DCAT Overview

Dynamic Service Catalogue

Designer

Configuration
Component Catalogue
Workflow
Product Catalogue
Policies

Relationships

The DCAT Engine
SOA Interfaces

26

GDi Systems DCAT Engine
The DCAT Engine …
 identifies and compiles fully specified service instances for each of the requested
products
 interfaces to service / network inventory via Resource Components
 is driven by business rules stored in the DCAT models
 processes Move / Add / Delete / Change service actions
 delivers fully specified solution(s) to Order Manager
 updates the service inventory upon completion of order process

CRM Product Recomm. Service Decomposed
Request Selection Engine Instance Order

27

DCAT Product/Service Modeling
in Support of The DCAT Engine

 For interworking COMPASS with external CRM systems,
DCAT uses the Product / Customer Facing Service (CFS) level
as point of reference, i.e. it must be ensured that product or CFS
names qualify as unique keys in both the CRM product catalogue and
the DCAT service model data base.
 To enable the automated operations of The DCAT Engine,
DCAT business rules must be created for evaluating order
data contained in the CRM request as well as service profile
and network footprint information retrieved from Granite
Inventory
 DCAT service models must include details of the behaviour
of the resource underlying each service

28

COMPASS Product Model
Product – CFS - RFS - Components

Product

CFS CFS

p
RFS RFS RFS RFS

PC1 C4 C5 C6

C1 C2 C3 C4

CFS Customer Facing Service
29
RFS Resource Facing Service
29

Product Model Example: ADSL with POTS
Model Showing References Between Resources

30

Inventory Resource Components
 Inventory Resource Components control the provisioning of network
facing services and thusly provide an automation layer for the
management of the Granite Inventory core objects.

 Granite Inventory artifacts used by COMPASS are:
• Path
• UDC (and TUDC – >transparent< user defined class)
• AMO (advanced modeling object for modeling resource facing services)
• Association
• Channel
• Equipment (network elements, CPE, and others)
• Customer

 These Granite Inventory artifacts will directly map to resource components in DCAT.

31

Provisioning Control Resource Components

 Examples of available provisioning control resource components are:
• Active Equipment Free Port Finder (abbreviated: AE)
• Find Free Path Channel
• Routing Engine (abbreviated : RE)
• Numbering Engine (abbreviated : NE)
• GIS Engine (abbreviated : GE)

 These and other resource components are capable of fully managing
a set of key Granite Inventory objects.
 The functionality provided by each of the resource components
is accessible via an exposed web-services interface.

32

Request eXchange Interface (RXI)
 The RXI supports different request types:
 Workorder management
 Fault repair management
 Task assignment
 The RXI utilizes “Semantic Integrator”:
 Management of enterprise data schemas
 Automated mapping of external messages to
COMPASS data dictionary
 Generation of stub-code for external interfaces
 What was rationale for its implementation ?
 Yield a generic interface for supporting as many
different order scenarios as possible

33

Modules COMPASS Like Solutions Are Constructed From

PRODUCT SUMMARIES

34

Products Underlying COMPASS Catalyst Project

Vendor Product Name Synopsis
Implement a provisioning engine on top of Granite Inventory.
Resource
Resource Components manage the entire life-cycle of
Components network and service objects stored in Granite Inventory
Ensures full data interoperability by implementing complex
Semantic
translations across a common model, dramatically reducing
Integrator the cost and effort required for design and maintenance.
Handles order decomposition and service orchestration,
Dynamic Service
sequences provisioning of resources, and directs the
Catalogue operations of the order manager.
Used as an order manager. Accepts commercial orders from
Expediter Order
CRM system and manages service requests sent to work-
Automation force and activation systems.
Granite Authoritative data base for all network and service resources.
Inventory

35

COMPASS Achievements for Croatian Telekom

 Key Croatian Telekom requests fulfilled
 Future proof design achieved
…

36

Subjects of The Life Demonstration

EXAMPLES OF SERVICE MODELS

37

COMPASS Demo Environment

 Explaining modeling of IPTV service in Service Catalogue
 Creation of E-2-E process and orchestration of IPTV provisioning
 Receiving and decomposition of message from HT CRM system–
message will be delivered from HT side and sending success/fail
message back to CRM system
 Creation of interface (southbound interface) to provisioning system
(Myrio)
 Sending message to Myrio system and receiving response
 Execution - live demonstration step-by-step.

38

Example 1: MaxTV (IPTV) product model

Complex due to compromise :
• to match structures in HT CRM (Donat)
• to avoid changes in HT CRM

39
39

Demo scenario 2: Upgrade/Downgrade case

 For the purpose of presentation of DCAT engine it can be interesting to show
upgrade/downgrade case. The order for the case consists of two parts, i.e. two
correlated products in the same order. The products are correlated by the same
scenario_id parameter as it was defined by NBI.

 Let’s stick with the concrete case. The customer has plain dial up account and
wants to upgrade to ADSL account. From AAA system perspective, the only
thing in that case that should occur is change of customer type in the system
(also, some additional services should be added as it is defined by business
regarding ADSL account). Without DCAT engine correlation and deduction, the
result would be deletion of dial up account and creation of new ADSL account.
That approach would not be acceptable because the customer would get new
account (customer already has one and there is no need to change it),
customer would get a new email address (this definitely should be avoided)
and mail box for the current email address would be deleted (this is
unacceptable; customer upgrades to better service and we delete all customers
emails!).

40

Demo scenario 2: Upgrade/Downgrade case
 DCAT implementation is able to detect the case. In stated example, the
detection is not very straight forward. CFS from those two products are not the
same (different CFSs that represents an account are defined on ADSL and dial
up) and DCAT Engine has to deduct it is the same account from AAA
perspective and that resulting actions should not be DELETE and ADD (as it
would be if the products are not correlated) but MODIFY. The whole
implementation is done in the rules (by adding few methods inside the engine
which helps the deduction) and it is quite simple (it just follows the same logic
as for ADD or DELETE actions).
 We can show what happens when e.g. just dial up DELETE order comes, and
what happens when dial up DELETE with ADSL ADD (correlated) comes into
the system. We can show the rules that deduct the cases and the resulting
tasks. Also, final result in AAA can be shown for both cases.
 Downgrade case would be actually the same but with ADSL DELETE and dial
up ADD in the same order. The behavior is actually the same (in different
direction).
 This is one of the most powerful benefits of DCAT implementation that
can be shown out of the first phase of the COMPASS project (when the
Granite Inventory is not involved in the provisioning process).
41

Example 2. – Web Hosting

42

Activate” Order Action Workflow Sequence Diagram – Complex Case

43

Q&A SESSION

44

Compass Catalyst 14052010 Final

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Compass Catalyst 14052010 Final

Similar to Compass Catalyst 14052010 Final (20)

More from Damir Medved

More from Damir Medved (12)

Compass Catalyst 14052010 Final

Editor's Notes