Compass Catalyst 14052010 Final


Published on

Croatian Telekom, GDI Systems, Telcordia and Progress Software presentation of the COMPASS project (Dynamic service Catalogue implementation)

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Dialup subscriptions(Net Plus, Net Super, Net Office)New product/technology line should be introduced, e.g. “Dialup”.Define new products, components and attributes to represent customer assetsWeb hosting, e-commerce hosting, server renting, collocation, and banner servicesNew product/technology line should be introduced, e.g. “Hosting”.Define new products, components and attributes to represent customer assets
  • ADSL and Dialup access provisioning(provisioning of MAXadsl and dialup services for access to internet including generation of username, password, e-mail address, mailbox quota, antivirus settings, firewall settings, active additional services, etc.)E-mail service provisioning(provisioning of e-mail mailboxes related to ADSL or dialup users or Hosted Exchange users)IPTV service provisioning(provisioning of MAXtv users for adding, enabling or disabling and towards the IPTV middleware, also assigning packages to users and terminating users’ packages)Web hosting provisioning(provisioning of Unix and Windows web hosting services including additional services e.g. web statistics, frontpage extensions, collocation and server renting services)Abuse process(analyzing abuse complaint tickets – identification of T-Com customers abusing the service; taking appropriate measures (temporary or permanent disconnections)Helpdesk support process(1st and 2nd level customer support including changing of internet passwords, checking validity of passwords, reviewing access logs for successful and unsuccessful connections to help troubleshoot internet issues)DNS processes(registration of Internet domains (local domains under, Croatian domains under .hr and commercial domains under .com/.net/.org) with relevant registrars and processing of related documentation)
  • Talking Points:Introduction of GenevaIntroduction of Enterprise Service Bus
  • Telcordia Dynamic Service Catalog (DCAT) is system focusing on product lifecycle and customer fulfillment management. Using graphical interface it is possible to make models to standardize how products, services, resources, and business interactions are defined and managed across BSS/OSS. DCAT is used for order (product) decomposition purposes through its exposed engine.In the context of the OSS solution it is used as a repository for storing product and service model information (model for short) to be used for commercial order decomposition in the Expediter supported order management process.The DCAT functionality is extended further by way of the DCAT Engine module which runs the recommendation engine and creates input to Expediter for control of the fulfillment part of the order management process.Telcordia Expediter is an order management and automation platform providing a graphical design tool supporting BPML standards help end user define and develop customized business flows and GUIs. Through its APIs it supports connection to number of standardized protocols to other systems. In the solution Expediter has orchestration role towards all OSS systems included in provisioning process.In the context of the OSS solution, Expediter is used to manage the interfaces to various systems needed for service activation (e.g., WWMS and TOPS). Moreover its work-flow execution capabilities will be used to implement those parts of the provisioning and activation processes whose complexity will benefit from visually rendering the control flow.Resource components represent a set of SOA components which can be consumed by any system via standardized interface. Resource components internally communicate with Granite Inventory, CNUM, GIS, and other systems. The key features of those components are to provide the functionality of a provisioning engine.The order management process consists of several phases, the main ones of which are order orchestration, service provisioning, and service activation.
  • CRM RequestThe CRM first sends a selection of products and related services with all attributes to the order management system. The O.M. (in our case Expediter) will initiate a call to the DCAT Engine with the CRM order.Product SelectionBased on the CRM order, more precisely following the product/services structure which is directly mapped to a product / customer facing services structure in DCAT product selection is done (product instances selection).Recommendation EngineDynamic Service Catalog uses rules-driven policies to automate the selection of appropriate implementations in response to customer orders. The separation of business rules from other logic makes it possible to change product and service specifications without coding. The complete set of business rules is also easier to manage and review. The execution of business rules is done in the DCAT Recommendation Engine.Service InstanceDynamic Service Catalog after recommendation engine execution saves complete set of components which are result of the DCAT Recommendation Engine. The service instance comprises a complete data set with all corresponding attributes which are necessary for the provisioning process.Order DecompositionInstances can be designed to hold the workflow name. Each workflow name defines the workflow required to fulfill the particular item. This allows a product implementation to be associated with a particular workflow. Once a service instance has been selected and the order is sent to the order management system, the OM system will then have the workflow name to execute for the particular order. In addition, Dynamic Service Catalog supplies the necessary data for the decomposition of the particular product ordered.
  • The picture above adds the correlations which exist between the resources of the MaxADSL product. When the underlying network resources are to be provisioned and activated, it will be necessary to use business rules in order to determine the exact sequence in which each of the components need to be evaluated. Given the relatively simple product and the relatively small number of references, one can imagine that the processing of such a much can quickly become quite complex. Add on top of this the fact that all of the references need to be described using characteristics, the resulting model will undoubtedly be hard to understand.The above picture shows four resource facing resources. The Physical Access Service can be thought of as data container. It does not require a process because the SWInventoryRServices, which requires an Expediter process-flow to be designed, will use all of its data (as indicated by the reference, for instance). Moreover, the seven resource components, which make up this resource facing service, too are linked by references. This then provides yet another indication to have a process candidate that will benefit from being designed using the graphical tool process design tool provided with the Expediter Service Designer.
  • The picture above describes the physical layer and the BB portion of the HT ADSL service in terms of a DCAT product model. The physical access components are referenced by resource components which are able to trigger specific resource components. The PSTN part is handled by the existing interface, aka the DIS Interface Manager resource component.
  • 1. The Order received by Expediter.2. Expediter propagates request to the DCAT Engine adding some Expediter related information.3. The DCAT Engine recognizes the order action “Add”.4. The DCAT Engine creates a new service instance along with the corresponding product implementation.5. The DCAT Engine replaces the values in the characteristics of the completely specified model with values specified in the order or obtained from the service inventory, and subsequently runs the Recommendation Engine.6. DCAT identifies the process name and its position in the execution sequence, packs it with the data taken from descendant Resources and returns everything to Expediter as a technical order.7. Expediter finds the correct process by the name of the technical order and executes it in the sequence order also found in the data transmitted from DCAT.8. Using data contained in the technical order, Expediter invokes all Resources Components, passes data contained in the technical order as parameters, and appends data yielded from previous components as needed.9. The Resource Component returns an activity list for processing by the dispatch process. After each Resource Component has been invoked, Expediter triggers the dispatch process and has it send the necessary requests to the WWMS workforce system, Activator, and potentially some other systems.10.After all systems complete their tasks successfully, Expediter calls each of the resource components to flag the associated service inventory instances as “Active”.11. Expediter sends a “Complete” message.
  • Compass Catalyst 14052010 Final

    1. 1. Catalogue Data Driven Order Automation Catalyst Presentation 1 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    2. 2. 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 Damir Medved, GDi Systems John Wilmes, Progress Software Dr. Aug.-Wilh. Jagau, Telcordia 2 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    3. 3. Prologue: What is … THE COMPASS PROJECT? 3 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    4. 4. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    5. 5. 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. Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    6. 6. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    7. 7. T-HT Landscape 1: Voice Centric Period of 1998 – 2003 7 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    8. 8. T-HT Landscape 2: OSS’s Consolitdated end of 2004 8 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    9. 9. T-HT Landscape 3: Billing Consolidated end of 2008 9 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    10. 10. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    11. 11. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    12. 12. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    13. 13. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    14. 14. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    15. 15. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    16. 16. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    17. 17. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    18. 18. Request eXchange Interface INTERWORKING COMPASS WITH EXTERNAL SYSTEMS 18 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    19. 19. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    20. 20. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    21. 21. Interworking COMPASS Using SOA Ideas Business Process Management Data Interoperability Management of Enterprise Services 21 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    22. 22. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    23. 23. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    24. 24. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    25. 25. Catalogue Data Driven Order Automation DCAT THEORY OF OPERATIONS 25 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    26. 26. DCAT Overview Dynamic Service Catalogue Designer Configuration Component Catalogue Workflow Product Catalogue Policies Relationships The DCAT Engine SOA Interfaces 26 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    27. 27. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    28. 28. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    29. 29. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    30. 30. Product Model Example: ADSL with POTS Model Showing References Between Resources 30 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    31. 31. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    32. 32. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    33. 33. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    34. 34. Modules COMPASS Like Solutions Are Constructed From PRODUCT SUMMARIES 34 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    35. 35. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    36. 36. COMPASS Achievements for Croatian Telekom  Key Croatian Telekom requests fulfilled  Future proof design achieved … 36 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    37. 37. Subjects of The Life Demonstration EXAMPLES OF SERVICE MODELS 37 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    38. 38. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    39. 39. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    40. 40. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    41. 41. 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 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    42. 42. Example 2. – Web Hosting 42 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    43. 43. Activate” Order Action Workflow Sequence Diagram – Complex Case 43 Copyright © 2010 TeleManagement Forum, All Rights Reserved.
    44. 44. Q&A SESSION 44 Copyright © 2010 TeleManagement Forum, All Rights Reserved.