12.07.2015 Views

Technology Review - Comarch

Technology Review - Comarch

Technology Review - Comarch

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

4 > In FocusNext GenerationService ManagementTough competition forces CSPs to tackle interactive and content-based services to avoid being pushedinto the role of mere bit carrier. The winner is the one who can introduce (at the quickest speed) newexciting customer services in collaboration with partners at the lowest costs. Next Generation ServiceManagement is a solution which can help CSPs to intercept new sources of revenue and to reduce operationcosts. NGSM combines various TMF standards including SID, eTOM, SDF and OSS/J into the completesolution which enables the boosting of service innovation.technology review [www.comarch.eu]


In Focus < 5The Internetand mobile revolution has changed the communicationservice market. From the consumer demandperspective, it is a great change. For manyend-users, no mobile phone or online presencemeans that you don’t exist. In other words, communicationbased services are perceived as necessitiesto live similar to food and air. This seemslike an ideal situation for Communication ServiceProviders (CSP). The problem is that end-users arenot only “hungry” but also very demanding. Enduserscan no longer be satisfied by simple servicesbased on network access. Along with high competitionin mature markets where the revenue can nolonger be increased by simple new subscriber acquisition,it means that revenue growth must bepursued around new types of services: interactiveand content based services.Another reason for CSP to move towards morecomplex services leveraging technology convergencecombined with content based services isthe pressure of Internet payers. According to TMFBusiness Benchmarking, industry update report[2], even mobile operators, because of the logicof mobile internet, might be cast into the role ofmere bit carriers by Internet players like Google orhandset vendors such as Apple. This is even furthertrue for fixed operators if they stop their transitionfrom voice service providers at the place wherethey serve only dumb pipes for Internet.For all these reasons, the recommendation providedin the report [1] “Revenue Growth Strategies:Getting the Balance Right” is that CSPs mustintercept revenue growth around interactive andcontent based services. This is perceived as a longterm strategy which is expected to allow CSP toattain a considerable share in the business aroundInternet.To implement this strategy, CSP must learn toplay a new role – that of a service aggregator. Thismeans that CSP must forget about the “has to bebuilt here’ motto. Instead, CSP must learn how tocooperate with partners and deliver services in thevalue chain model. The key to success is the abilityto augment native CSP services with partnerservices, and not only content based but also servicesprovided by other CSPs. The winner is the CSPwho can fastest adapt its offer to customer needsby embracing the most exciting content and applicationsprovided by third parties.The problem with the idea of providing newexciting services which are a combination of networkaccess based services leveraging technologyconvergence with content based services, is thatthese new “exciting” services may introduce complexitywhich can “eat up” profit. This challenge isindicated in the already mentioned report [2] “Winningin a Shrinking World: Points to Consider”.The answer to this problem is employing nextgeneration service management OSS systems. Halfof the solution could be leveraging hyped servicedelivery platform systems. However, this kind ofsystem mainly addresses the service delivery process,and to complete the picture one must attachthe missing part – service assurance. In a highlycompetitive environment with increased portabilityof end users between service providers, servicedelivery that does not assure comprehensive con-Figure 1. Complete service lifetime supportService deliveryCRMService assuranceCRMCustomerFocusCustomer Facing ServicesCapture customerneedsCalculate Customerservice impactResource Facing ServicesIdentify whattechnical servicesare requiredIdentify impactedtechnical servicesNetworkFocusResourcesAllocateresourcesIdentify faultyresourcesnr 1/2009 (09)


6 > In FocusFigure 2. Next Generation Service ManagementFulfillmentNG Service Deliverry Platformsumer experience may quickly turn into failure. Thisis the reason for employing next generation servicemanagement systems which address both servicefulfillment and service assurance. Fast introductionof new services must mean not only the ability todeliver the exciting services but also the ability toassure the quality which guarantees customer satisfaction.All of these need to be achievable withlow costs. These benefits should characterize thenext generation service management solution.Complete service lifetime supportThe current and future communication servicemarket is characterized by high competition. Thebattlefield is around fast service innovation. Thewinner of the game is the one who can quickly envisionnew exciting services and then promptly bringthese new services to life. The service introductionrequires not only the ability to deliver new servicesto customers but also to assure comprehensive customerexperience. The latter capability is equallyimportant. In times of strong competition andincreasing ease with which customers can migratebetween CSPs, neglecting service assurance mayService InventoryAssuranceNG Service Assurancemental impact on the positive effects of fast serviceadoption. To avoid this situation, brining newservices to life must mean providing complete lifetimesupport comprising the fulfillment and assuranceareas of service management identified by theeTOM framework. The idea of complete service lifetimesupport is depicted above (Figure 1).The concept is based on the synergy betweenfulfillment and assurance processes which use thesame service inventory. Figure 1 demonstrates thatthe service delivery process during execution fills theservice inventory with the data which should thenbe available to the service assurance process. Theexample here demonstrates the automatic serviceimpact calculation for the network related faults.This process requires data completed by the servicedelivery process. It demonstrates how practically theeTOM process decomposition into fulfillment andassurance processes can be implemented so that thedecomposed processes collaborate during the servicelifetime. The presented concept of service fulfillmentand assurance synergy is a reason for the NextGeneration Service Management solution to be composedof three main components: Service & NetworkInventory, Next Generation Service Delivery Platformand Next Generation Service Assurance.The central aspect of the solution is serviceinventory with the service catalog constructedaccording to the SID model augmented with managementmeta-data used by service fulfillment andservice assurance processes. Service fulfillment isrealized by the Next Generation Service DeliveryPlatform and service assurance by Next GenerationService Assurance. From the Service Inventory perspective,the delivery process is a producer of servicedata which includes details about customerservice decomposition down to allocated resources.The service assurance process is a consumer whichexploits service detailed data to boost service assuranceprocess automation. The presented solutionperfectly demonstrates how SID and eTOM frameworkssupport each other and enable the provisionof an end-to-end solution without scarifying thedesired modular approach.Deeper insight into the NG Service Delivery Platformand NG Service Assurance concepts can begained from the white papers listed in the ‘Furtherreading’ chapter.No need for the big bangIn the history of IT there have been a lot of overhypedrevolutionary ideas which promised to solvevirtually all the problems of the world. Even whensome of these ideas contained promising solutions,many of them failed because there was nopractical way of bringing these ides to life. Manyof them simply assumed the big bang scenario,which means replacing all existing systems withthe new system with one shot. Such an approachis impractical and presents a barrier to the introductionof innovation.The Next Generation Service Management solutiondoes not require replacing all existing systemsto reap the benefits of the solution. On the contrary,the solution assumes the scenario in which existinglegacy systems can be incorporated into theservice layer as service factories. In other words,this scenario can be perceived as a test case forthe integration capabilities of the solution. Thismeans that CSP can quickly introduce the newsolution. Instead of replacing all old systems, CSPcan concentrate all efforts on adding new servicecomponents and combining them with the existingservice portfolio to bring really new exciting customerservices to market. This is a great advantageover the scenario where much time is consumed ontransforming an IT environment with no influenceon business until the whole transition is complete.This is another dimension of the reduced time-tomarketbenefit which NGSM brings.seriously damage CSP business and have a detritechnologyreview [www.comarch.eu]


8 > In FocusNext GenerationService DeliveryPlatformIntegrated Service Fulfillmenttechnology review [www.comarch.eu]


In Focus < 9Figure 1. Silos vs. horizontal architectureVertical – Silos based ArchHorizontal – Layered ArchOSSOSSOSSNGOSSVoiceDataIPIP Access Voice Data TV ContentNetworkNetworkNetworkNetworktelecommunication industry has undergonea great shift from voice cen-Thetric services towards much more dynamic, convergentservices based on IP protocol. The driving forcein this revolution has been the introduction of mobileservices and a prevalence of the Internet, thusresulting in a change in customer needs. Customerneeds can no longer be satisfied by simple servicesbound to one specific technology. On the contrary,customers expect great flexibility and a completesolution which can deliver end-user services overdifferent technologies. This means that in order tobe profitable, telecommunication operators need totransform from simple network access providers toservices aggregators, where network access is a vehiclefor delivering content centric services.This trend resulted in the emergence of new typesof services, such as IPTV, Video on Demand and VoIP,which can be implemented ether via Mobile or fixed(including FFTx) internet broadband access. Moreover,clients demand highly customizable servicepackages with appropriate QoS. On the one hand, ahigh customer demand for new types of services canbe a great source of revenue, but on the other hand,it presents a big challenge for telecommunicationoperators in the area of service fulfillment.As the services to be delivered to end users are nolonger simple services bound to a single technology,old methods for service fulfillment cease to work.Traditional OSS systems were organized in silos builtvertically over technology-centric services. This architectureis considerably challenged by the demand forconvergent services. Old systems were designed tomaximize efficiency through leveraging tight couplingbetween technology and services deliveredby this technology. This resulted in these systemsbeing developed as isolated silos without assumingany of the horizontal integration required by convergentservices delivered in the value chain model. Firstattempts to build service delivery systems for convergentservices were realized by very costly integrationof existing silos oriented OSS systems. Following this,efforts were focused on mitigating the integrationproblem by leveraging integration platforms basedon the ESB concept. But still, the results measuredregarding cost and time to market for delivering newservices are not satisfactory. This is due to that factthat developing adapters to ESB is still a costly task,and wrapping vertical silos can only provide a horizontalservice layer imitation.The answer to the integration problems associatedwith delivering convergent services is leveragingNext Generation Service Delivery Platform(NGSDP) – a new generation of OSS systems in thefield of Service Fulfillment. The main goal for thistype of system is cost effectiveness and reducedtime to market for delivering highly customizablebundles of convergent services. System architectureis tuned for delivering services which areaggregations of convergent services rather thanmonolithic services. The support for multiple playscenarios and delivering services in a value chain isa native functionality of this type of system.The picture below illustrates how horizontal integrationis a native characteristic of the NGOSS, whilefor silo-based architecture it is a high cost task whichmust break through old architectural boundaries.Service Delivery as a ServiceAssembly ProcessThe main premise of the NGSDP is that a service isnot a monolithic service but a bundle of convergentservices. This assumption forces a shift from verticalsilos to the horizontal architecture, with the servicelayer acting as the basis for the service delivery process.The service layer is composed of fine-grainedservice components which act as reusable buildingblocks. Any customer service is defined as composingof service components. Different customerservices may reuse service components in differentconstellations, providing great flexibility in creatingnew and differentiated client services. The essentialelement of NGSDP is the notion of the service deliveryprocess as an assembly process. This means thatonce a new type of customer service is defined, it isready to be delivered via a generic service assemblyprocess, which uses fine-grained reusable servicecomponents available on the service layer as buildingblocks. This idea is depicted below (Figure 2). Thearchitecture ensures reduced time to market and asignificant reduction in integration costs.Reduced Time to MarketThe introduction of IP based convergent servicescaused a revolution in customer needs. They areno longer satisfied with monolithic services boundto a single technology. On the contrary, customersdemand highly customized service bundles whichare content rather than technology centric. Moreover,customers expect that service offerings rapidlyadapt to the changing demands. It is now commonplacethat a customer updates their demandas quickly as a new concept appears on the market.Because of strong competition, a customer caninstantaneously switch to a Service Provider whomore cheaply and quickly delivers new services,without bothering with underlying network technology.This means that having an OSS system thatnr 1/2009 (09)


10 > In FocusFigure 2. Creating customer services using fine-grained service building blocksAssembly processUserVideo On DemandTV ChannelService LayerVoiceIPTVIP Access Voice TV TV ChannelVideo OnDemandFigure 3. Third party components as plug-ins to the service layerThird PartyComponentContentcan significantly reduce new service’ ‘time to market’is essential for competitive advantage.NGSDP is all about reducing time to market andcosts of introducing new services. The NGSDP architectureis tuned for a scenario in which a ProductManager can quickly prepare new service offeringsby assembling the existing fine-grained servicecomponents. This is achieved using architecturebased on a service layer and a notion of servicedelivery as an assembly process. The introductionof a new service is as simple as combining existingbuilding blocks and preparing a bundle. Once a newservice is prepared, it is ready to be delivered by thegeneric service assembly process. This means thata new service offering can be prepared with zeroNGOSSService LayerIP Access Voice Data TV Contentcode writing, which not only drastically reducestime to market, but also costs.The benefit of reduced time to market is not limitedto introduction of new service bundle variations.The key premise of NGSDP is extendibility of the servicelayer. This means that emerging new technologies,delivering novel convergent services, can beplugged into the service layer without the need torebuild the OSS system. Once new service componentshave been added to the service layer, theyinstantly become available to the Product Managerfor building a new service offering. New customer servicesare ready for delivery by the service assemblyprocess. In other words, integration of new servicecomponents is reduced to the problem of plugging-infine grained components into the service layer, whichsignificantly reduces cost of integration.Reduced Integration CostsHistorically, integration has always been a toughtask in the OSS field. The need for a time and moneyeffectiveintegration solution has become evenmore critical for telecommunication operators followingthe emergence of convergent services. Customersdemand new services which are not monolithicsolutions, but bundles of services, and theirimplementation requires integration of differenttechnologies, delivered in a value chain. This meansthe participation of many partners, including contentproviders. This makes having a platform whichfacilities integration a necessity to survive withinthis very competitive environment.For many years, integration has meant writinga proprietary code which was neither fast nor costeffective. A step forward was employing systemsbased on the ESB concept, reducing costs but stillnot sufficiently effective. This is mostly due to thefact that the ESB concept required writing adaptersfor monolithic systems. This method resemblesfighting with symptoms rather than eliminating thecause of a disease. The effective method requires anew approach, where old OSS systems constructedaccording to the vertical silos concept are replacedwith NGSDP.The NGSDP is designed according to the horizontalarchitecture, with an essential role for theservice layer, which is composed of fine-grainedreusable components. This is the main differentiatechnologyreview [www.comarch.eu]


In Focus < 11tion from older systems, which could expose onlycoarse-grained services, thus, were difficult to reuse.Moreover, old systems tightly coupled service managementwith services which were tied to a networktechnology. In contrast, NGSDP exploits fine-grainedcomponents which expose standard API, allowingthe placement of the service management functionalityabove the service components layer. Thematerialization of this concept is the generic serviceassembly process, which is an essential part ofNGSDP for service delivery implementation.This reduces the integration problem to plugginginfine-grain components into the service layer. Thisidea is depicted in the Figure 3. Once the integratedservice components are available on the servicelayer, they are ready to be used by Product Managersfor constructing new client service offerings.The task of ‘plugging in’ service components ismuch easier to that of integrating old systems basedon the vertical silos architecture. This is mostly dueto the NGSDP architecture, which assumes finegranularityof components with industry basedstandard API. Even in the case that the componentsto be integrated are not compliant with industrystandard API the task of writing adapters is muchsmaller to that of writing adapters for coarse-grainmonolithic systems. When the components to beintegrated are already based on industry standardAPI (promoted by TM Forum and NGOSS initiative)the integration problem is even further reduced.Value Chain Service DeliveryThe emergence of convergent services and aFigure 4. Value chain implemented on NGSDPThird PartyComponentContentThird PartyComponentContentAggrContentContentCreatorContentAggrager prepares a customer service by picking themost suitable service components available on theservice layer, and decides which partner’s serviceofferings are bundled into the customer service.Once a service bundle is defined by the ProductManager it is ready to be delivered to the customer.The service delivery is implemented by the NGSDPassembly process, which orchestrates creation ofindividual service components that constitute acustomer service. This means that NGSDP providescentral control over individual partner’s offeringsthroughout the service delivery process. This is anessential feature for smooth implementation ofvalue chain-based customer offerings, as serviceaggregators need to control the delivery of thirdparty components. This idea is depicted below:All the characteristics depicted highlight howNGSDP has native inbuilt support for multiple serviceoffers, significantly reducing time-to marketand integration costs.<strong>Comarch</strong> Next Generation ServiceDelivery Platform<strong>Comarch</strong> NGSDP is an aspect of the <strong>Comarch</strong> OSSSuite, which is built according to the TM Forum NGOSSconcept. The main elements of <strong>Comarch</strong> NGSDP arethe service layer and the service assembly process.<strong>Comarch</strong> Service LayerIn <strong>Comarch</strong> NGSDP, the service layer is built uponNGSDPService LayerContentAggregatorBroadbandServiceBroadbandProviderSet-top boxSet-top box/TV/PCThird PartyComponentSet-top boxthe <strong>Comarch</strong> Service Inventory. The <strong>Comarch</strong> ServiceInventory exploits the service modeling conceptbased on the SID model promoted by the TM Forum.This means that the service layer, which is a foundationof NGSDP platform, is based on an industry standard.Service components available on the servicelayer are managed according to the SID Model, whichorganizes service components into Customer FacingServices (CFS) and Resource Facing Services (RFS).The definition of a new customer service created bya Product Manager is modeled as a new CFS and RFSspecification, as defined in SID. The new CFS-RFS specificationaugmented by metadata and policy specificationsbecomes a novel recipe for the service assemblyprocess, and, thus, the new customer service is readyfor service delivery. In other words, the <strong>Comarch</strong> servicelayer provides a service catalog which containsthe recipes for all customer offerings.Founding the service layer on the industry standard,the SID model makes integration of new partner’sservices much easier and the idea of integrationvia ‘plug-able’ service components a reality. When apartner’s offerings are described as appropriate RFSor CFS specifications augmented by metadata andpolicy specifications, they can be smoothly incorporatedinto the service layer. This is achieved becauseRFS and CFS specifications play a role of an industrybased model for describing a partner’s ‘plugged-in’service offering. The basic CFS, RFS specificationsare augmented by additional meta-model and policyspecifications which describe the management interfaceof a service component and provide additionalinformation required by the assembly process. OnceRFS and/or CFS specifications with the metadata andpolicy specifications are added to the service layer,the partner’s offerings become building blocks forcustomer offerings. This mechanism provides anintegration hub which is compliant with the standardmodel (SID). In other words, the <strong>Comarch</strong> servicelayer can play the role of a federated service inven-shift from monolithic services to content centricservices bundles means that telecommunicationoperators need to alter the orientation of theirbusiness more towards service aggregation ratherthan merely profitable network access provisioning.Having a platform which has native supportfor delivering services in multiple scenarios canact as a great competitive advantage.NGSDP, with its new generation architectureconceived to change service delivery into a serviceassembly process, is a perfect fit for an OSS systemwhich needs to effectively support multiple playbusiness scenarios. Each partners offering is managedas a service component within the servicelayer which is available for service offering bundling.As the service layer of NGSDP is designed tobe extendable, each new partners offering can bequickly plugged into the service layer. This meansthat integration with new partners systems is astandard process built into the concept of the servicelayer. Once a new service partner’s offering isincorporated into the service layer it is instantlyavailable for service offer bundling. A Product Mannr1/2009 (09)


12 > In FocusFigure 5. Service layer as SID integration hubNGSDPService LayerUserCFSTV ChannelCFSIPCFSTVCFSTV ChannelIPTVRFSFFTHRFSIPOther business unitService LayerCFSIPRFSIPRFSTVRFSContentThird PartyComponentCFSContentCFS-RFS specifications augmented by additionalmetadata and policy specifications which togetherform a recipe for the service delivery process.> Once the new service is defined it is ready to bedelivered to the customer.> When a customer requests the new service, it isdelivered via the assembly process.> Once the service is delivered, it is defined withinthe <strong>Comarch</strong> Service Inventory, enabling it to beeasily managed. This includes service assurancemanagement of the newly created service, whichcan be implemented using the <strong>Comarch</strong> NextGeneration Service Assurance product.tory, providing a common layer for partners’ serviceofferings. Together with the assembly process, thismeans a platform for collaboration within valuechain offerings. This idea is depicted below:Implementing the service layer over the <strong>Comarch</strong>Service Inventory has additional benefits. Whendelivering a customer service, the service deliveryprocess is accompanied by creating instancesof appropriate CFS and RFS. This means that customerservice is not only delivered to a customer,but is also described within the <strong>Comarch</strong> ServiceInventory. Having an inventory of delivered servicesmakes these services manageable and providesa foundation for full service lifecycle support. As<strong>Comarch</strong> Service Inventory is also a foundation of<strong>Comarch</strong> Next Generation Service Assurance, thisgrants the ability to close the loop of Service Fulfillmentand Service Assurance.<strong>Comarch</strong> Service Assembly ProcessWithin <strong>Comarch</strong> NGSDP, the service assembly processthat implements service delivery is built uponthe <strong>Comarch</strong> OSS Process Management, which is apart of the <strong>Comarch</strong> OSS Suite. The main concept ofthe <strong>Comarch</strong> Service Assembly Process is that theservice delivery process is not hard coded per serviceoffering, but is a generic process which assemblesservices according to a recipe stored withinthe CFS-RFS specifications defined in the servicelayer. This means that customer services’ are notmanaged as monolithic services with a proprietaryservice delivery mechanism, but are built from reusableservice components. This approach meansleveraging the main concept of SOA, which assumesconstructing services from reusable fine-grainedservice components, rather than implementingmonolithic services using proprietary mechanisms.The reusable components are defined in the servicelayer. As described in the <strong>Comarch</strong> Service Layer, thescenario which captures this idea is as follows:> A Product Manager using marketing requirementsconceives a new type of customer service.> The new service is built as a bundle of reusable servicecomponents. The new service is described byThe basic service delivery process outlined above isperfect for illustrating the main concept of the servicedelivery as the service assembly process. Howeverin scenarios more true to real life, the servicedelivery process need not only take into accountnewly ordered services but also the existing customerservices. This is because the most commonscenario is when a user updates his existing subscription.In such a scenario, the series deliveryprocess analyzes existing customer services andconfronts them with the newly ordered services.This analysis results in the optimal delivery scenariowhich attempts to reuse the existing customerservice building blocks to support the newones yet also must decide which service componentsare compatible and which one needs to beupgraded or deallocated. All this analysis is donebased on CFS-RFS specifications and augmentingmetadata with accompanying policy specifications.Examples of such specifications for whichthe delivery process chooses the optimal deliverypath are: declaration of service dependency, servicecompatibility and declaration of which RFS Specitechnologyreview [www.comarch.eu]


In Focus < 13Figure 6. Closing the loop: service delivery & service assuranceService deliveryCRMService assuranceCRMCustomerFocusCustomer Facing ServicesCapture customerneedsCalculate Customerservice impactResource Facing ServicesIdentify whattechnical servicesare requiredIdentify impactedtechnical servicesNetworkFocusResourcesAllocateresourcesIdentify faultyresourcesfications describe technical alternative implementationsof CFS Specifications.The described intelligence of the service assemblyprocess guarantees efficient service delivery byreusing existing service building blocks and avoidingdeallocating and then reallocating service components.Moreover, this strategy assures minimalimpact on the existing customer services which auser wishes to retain.ConclusionsNGSDP is a new class of OSS system that has theprimary role of reducing time to market and integrationcosts associated with the introduction ofnew service offerings. This is achieved through completelydifferent system architecture. Unlike oldOSS systems, which exploited architecture usingthe vertical silos concept, the new format employshorizontal architecture with an essential role forthe service layer. The premise is that a customerservice is a bundle of reusable fine-grained servicecomponents. This assumption is a perfect fit for thenew generation, which is no longer monolithic servicesbound to a single technology, but on the contrary,are bundles of content-centric convergent services,including IPTV, Video on Demand and VoIP. Theconcept of the service layer is accompanied by theservice assembly process notion, which is a genericservice delivery process. According to this concept,service delivery is implemented by assembling reusableservice building blocks available on the servicelayer. This approach guarantees reduced time tomarket for new services, offering both using a newvariation of service bundles and a new type of buildingblock. The latter is possible because the servicelayer is conceived as an extendable layer. The integrationproblem is reduced to the issue of addingnew, fine-grained service components, saving costand effort. Once a new service component is availableon the service layer, it is ready to be used as abuilding block for constructing new service offerings.This concept is augmented by exploiting industrystandards. <strong>Comarch</strong> NGSDP leverages the TMForum SID model with the core model of CustomerFacing Services and Resource Facing Services formanaging service building blocks available on theplatform. Employing standard API based on OSS/Jmakes third party delivered service componentsreally pluginable modules, which can smoothlyextend the service layer, and, thus, a customer serviceoffering. This makes the NGSDP the perfect platformfor delivering multiple play services.All these NGSDP features provide such benefitsas reduced time to market and costs, which areextremely important within the very competitiveenvironment that telecommunication operatorsmust now operate.Łukasz Mendyk<strong>Comarch</strong> SAPosition: OSS Product ManagerDepartment: TelecommunicationsBusiness UnitInfo: Currently responsible for NextGeneration Service Managementsolution, specializes in the servicefulfillment areanr 1/2009 (09)>>>


14 > In FocusApplication SLAThe missing part of complete Service SLA Management?Next Generation Service Management Tools can handlenot only network but also applications impact on the services“I am a Customer, my service is not working”. Simple complaint, probably a simple solution, but howdo I find the problem when I know that my network is working correctly. The problem is that the servicemodels do not include information about used applications, and the applications are increasinglybecoming the heart of the service, while the network is simply reused.technology review [www.comarch.eu]


can operators ensure that theHow proper quality of so many complexservices is delivered? Has the software for networkand service monitoring enough functionalityto provide the right information? Fortunately, OSSsystems have evolved, and they currently containfunctionalities allowing the operator to build comprehensiveservice management platforms. Today,operators cannot even think about delivering modernservices of a high quality without providing aSLA. This means that service assurance with SLAsbecomes the most critical aspect of modern OSSsolutions. Additionally, since most modern servicesare built based on a number of applications, deliveringthe services over network, the applications arebecoming the core of the service models.But let’s start from the beginning.Service Assurance solutionsModern Service Assurance solutions allow for monitoringthe service by providing the following keyfunctionalities:> Service state propagation based on network layermonitoring and service models with detailedinformation about service-resource relations.> Service Quality Management with statistics gatheredfrom a number of different sources, includingthe network, probing systems, applications,and supporting systems. It also generates theservice affecting events based on thresholdstrespassing.These solutions are capable of joining the datain order to provide comprehensive informationabout the state of the service. This is a must-havesolution when the service provider wants to implementthe SLA and start including the applicationswithin it.How is the service provided?Where are the applications?When comprehensive Service Assurance is in place,the key issue is to identify the applications whichare required to provide such a service. The servicemodel should then be revised and all of the applicationsshould be added to such a model. Even ifthe given application cannot be fully monitored, itis still valuable to have it as a part of the service.There are different ways for modeling the services.In <strong>Comarch</strong>’s opinion, the best option is to buildthe model using SID, extending it to handle all necessaryinformation.The ideal Service Model provides informationabout used network resources and applicationsrunning together with them or on separatemachines/clusters. Such a model is used to documentan end-to-end service and present the “bigpicture”. Additionally, where possible, the propagationrules are set to describe how the eventsaffect its direct services (Resource Facing Services).The integration of applications is not an easy task.With this, one may receive two events for the sameproblem: one originating from the device and onefrom the application. There are two solutions possible:> Proper service model, allowing for correlation ofthese two events and propagating the alarm onlyif it affects both components of the service> Correlation rules, which can narrow down thenumber of events and can enrich and qualifyjust one event.Both solutions allow the service provider to enrichthe monitoring of the services, which has a directimpact on the quality of its SLA management.Service Model – dynamic imageWhen the Service Models include the applicationinformation it is important to ensure, that thismodel is up-to-date. Often, the service providersput a lot of effort in creation of those models, eitherthrough migration to newer service catalogue solutionsor through inquiries made in the current networkto locate all required applications. This isnot enough. The network environment and theapplications used to deliver services evolve, so itFigure 1. Service Models based on SIDCFSRFSResourcesEquipmentGroupsInternalis very important to at a minimum keep the informationthat some changes occurred. The ideal solutionincludes strong integration between ServiceInventory, Network Inventory and the monitoringsolution. The best solutions include the processesbuilt using ITIL Change Management, which trackall changes made in resources used by the service.Those processes should automatically update theservice model and also trigger the refresh of theinformation in the Service Assurance tool.In Focus < 15Application integrationThe applications could be monitored in almost thesame way as any network element, either throughthe integration layer with dedicated interfaces orthrough IT Application Management. Both of theseapproaches can deliver not only the state of a givenapplication but also a number of different statisticssuch as performance, disk usage, etc. Those detailscan then be included in various KPI parameters,and crossing of the assigned thresholds will triggeralarms, which can affect the service.SQM and SLA managementWhen service models are documented there aretwo final things missing: Service Quality Managementand SLA Management. The first is used to collectnetwork & application metrics and calculatethe KPI and KQI. These can then be propagatedthrough the service models to the top level CustomerServices. Such an approach creates the completepicture of a service:CustomerServiceInternal Internal Internal InternalConnectionGroupsInternalInternalConfiguration Application Applicationnr 1/2009 (09)


16 > In FocusFigure 2. Application event priorities based on Service SLAMelodyServiceService PriorityPriority = 100SLA ContractRadio AccessCore NetworkMelodyPlatformPriority = 100ContentProviderHWPlatformApplicationUTRANGERANSMSC DNS GSNPriority = 100ContentMenagerContentProviderMelody ServerAlarmPriority = 100CFS RFS 3rd partyprovidedservice> Service model as documentation of used components,resources, configurations, and mostimportantly in current complex services – usedapplications> Service impact events providing almost real-timestatus of the service> Service KPI and KQI providing the measurementsfor service quality.By including the applications in the model, theoverall service information is dependent on thestate and performance of the used applications.If all this data is exported to the SLA Managementsolution, it can be used by a number of differentSLA attributes such as availability, bandwidth orquality, to name just a few. With this approachone might even model services, which are purelybased on applications, and manage the applicationquality and the application SLAs.Loop back – Customer informationprioritizes the network andapplication eventsThe possibility of propagating the applicationevents affecting the service model is a very importantbenefit of this approach. But there is an evenmore important potential benefit from the integration.Every Service Provider tracks the signed SLA,maintains information about the priority of eachservice and finally, is often aware of the potentialfinancial loss of service failure. All of this data canbe used to prioritize services and the existing eventpropagation rules can then be used to push the priorityfrom the service level down to the networkand application events. This means that the operationstaff can use this information to solve thoseevents which are most critical from the businessperspective. If the applications are part of the model,their impact can also be prioritized, so that eventscaused by them are resolved in a reasonable order.Application prioritizing can also be used by otherusers in other activities like enhancement planning,upgrades and other maintenance activities.Why it is importantService providers might question the necessity ofincluding the applications, measuring them andmonitoring them more closely with SLAs. But atthe end-of-the-day, an increasing number of theservices depend heavily on applications like contentservers, LDAP servers or even the OS installedon their equipment. These applications often generatemore errors than the hardware used in thenetwork. The customers do not see the difference,from their perspective the service is either workingor not, and they are willing to change the serviceprovider if somebody will be able to guarantee thequality and availability of the service. Increasingamounts of service providers use this as the differentiatorof their offer, especially with regardto large business customers.Our offer and visionThe <strong>Comarch</strong> vision for realization of such solutionsis based upon the <strong>Comarch</strong> OSS Suite. It provides theability through the flexible service modeling tool, efficientFault Management with event correlation system,the Service Impact Monitoring tool, Service QualityManagement and finally SLA Management. All ofthese modules have been included in <strong>Comarch</strong> NextGeneration Service Assurance, which also includesmodules of <strong>Comarch</strong> IT Management – the source ofknowledge and best practices for application management.The modularity of the platform and theseamless integration of all the components with thirdtechnology review [www.comarch.eu]


In Focus < 17Figure 3. Schematic architecture of the <strong>Comarch</strong> solutionExternal KnowHowDatabaseTrouble TicketingsystemEnhanced Communication BusSLA ManagementAuthenticationServiceReusable componentsof <strong>Comarch</strong> OSSSystemRepository &ConfigurationData ModelConfigurationService MonitoringFault ManagementService QualityManagementReportingServiceNotification &Escalation ServiceCommand LineInterfaceEnhanced Communication Bus<strong>Comarch</strong> OSSConsole<strong>Comarch</strong> OSSWEB Console<strong>Comarch</strong> PDAConsoleMediationDeviceMediationDeviceMediationDeviceMediationLayerNetworkEnvironmentNEM’s IP Devices Applicationsparty software, through OSS/J interfaces, delivers anOSS system which we believe takes service and applicationmanagement to the next level. Since every newday brings new service requirements and demands,only tools allowing for flexible service modeling andincluding applications in management can deal withthe complexity of the service offer.>>>Jakub Załuski-Kapusta<strong>Comarch</strong> SAPosition: OSS Product ManagerDepartment: TelecommunicationsBusiness UnitInfo: Currently responsible for salessupport of <strong>Comarch</strong> OSS systems.nr 1/2009 (09)


18 > Trends & StrategiesWhat to look for in aperfect inventory solution?Accurate, consistent, streamlined Process-Driven Inventorytechnology review [www.comarch.eu]


present, it is understood that an accurateInventory database should be at theAtcore of the entire OSS. Only an accurate NetworkInventory can be the foundation of Service Inventoryand further – automated Service Provisioningand Service Level Management. The only wayto ensure such accuracy and automation, and tointroduce accurate Inventories into existing scatteredenvironments, is through Process-Driven InventoryManagement.Is an accurate Inventory stillimportant?Operators in the highly-competitive telecommunicationsenvironment are constantly looking forevery possible way to maximise their revenue andmargins. There are different tools and methodsthat can help achieve this goal, and the truth isthat there is no single solution. Innovative serviceoffers, SLA Management, Self Care, CRM, LoyaltyManagement, Fraud Management (and manyothers) are all necessary to succeed in today’s telecommunicationsindustry. However, there are alsomuch “older” areas awaiting improvement. One ofthese is Inventory Management.The initial situation prior to the implementationof Process-Driven Inventory Management usuallylooks similar regardless of the scale of theoperator:> Inventory information is scattered among thedifferent proprietary management systems thatwere delivered by vendors of the equipment;> Additionally, there are several commercial or inhousebuilt umbrella systems, covering differenttechnology and areas;> In order to maintain the connectivity across thetechnologies, Excel files or in-house built databasesare usually used;> Very often, Visio diagrams represent crucialareas of the network (there may be hundreds ofthem);> The processes are “manual” and informationexchange among different actors is conductedusing e-mails, telephones and paper documents.Even if these systems are partially (or in the bestcase, completely) integrated, an end-to-end viewpointis absent, some information is stored redundantly,various configuration items have differentnames in different tools, and the process of dataretrieval and modification is complicated. Even ifsome type of workflow management system is inplace, it usually covers only certain parts of the realprocess, within areas related to trouble ticketing,Figure 1. Resources, Services and Processes layersin the Process-Driven Inventory solutionServicesChangeRequestProcessesResourcesNoSchedulechangefinancial issues etc. Moreover, usually the inventoryand workflow systems are further integrated withone another and with external tools e.g. Fault Managementor SLA Management. This means there areplenty of interfaces to maintain.Another challenge in this scattered environmentis the lack of a consistent and accurate viewof the entire network, which is indispensable forresource usage optimization. Operators cannotallow resources to sit unused in their warehousesand on their networks. Yet, without an accurateinventory database it is impossible to remaininformed of these resources. With a separate inventory“tool” for each technology or department (orworse, yet still happening, per employee!) it is notdifficult to imagine the complexity of resourceusage optimization.In addition, the majority of operators and providerseither charge or are charged for their resources(or both). Operators cannot be certain that they canrely on the inventory database accuracy of theirsuppliers when it is time to pay their invoices. Onthe other hand, they also cannot be sure that theyfully charge for all the resources they provide.YesEquipmentavailable ondateChange approvalNoOrderaquipmentVerifyAfectedServicesIs approvedNoVerify SLAYesYesEquipmentavailableChangeApprovedVerifysparesNoEquipmentavailableTrends & Strategies < 19Changeto beexecutedHow do I ensure my Inventory isaccurate?The introduction of an accurate inventory databaseis a challenge, due to the numerous migration,integration and discovery tasks that mustbe performed. A larger challenge still is the maintenanceof inventory database accuracy. The reasonInventory databases lose their consistencyand accuracy is the lack of repeatable processesthat can keep up with reality – a rapidly changingreality. There is no time to update an inventory“later”. The goal is to enable the inventory databaseto mirror the network and not vice versa, asis the case in the traditional approach to inventorymanagement. This traditional approach results inerrors and inconsistencies.Through the introduction of automated processes,the inventory ceases to be “just a database”,and instead becomes a dynamically-adjustingsystem that presents the current, past andfuture states of a network and services. As a result,the inventory becomes the real heart of an OSS.Process-Driven Inventory provides the layers ofResources, Services and Processes (please refer toYesnr 1/2009 (09)


20 > Solutions Trends & Strategies& ProductsFigure 2. Mechanism of grants for work and approvalsService O&MResource O&MGrantWork(Project)requestUpdateWorkGrant ForWorkrequestCreate (if accepted)answerGrant ForWorkAsk forGrantanswerGrant DeclinedCustomer notificationGrant AcceptedCreatePlannedIncidentWaiting ForActivationCustomer notificationPlanned ServiceIncident ActiveactivateWork isActiveCustomer notificationServiceIncidentClosedWork isClosedProcess-Driven Inventory Management enablesthe determining of not only WHO, WHAT and WHEN,because for this Inventory Management with afull history tracking and auditing functionalityis sufficient. It enables to determine the WHY, i.e.in the context of which customer order, changeor maintenance process a given modification inthe system was introduced. Process-Driven InventoryManagement also allows for definition andmonitoring of quality and performance metrics forInventory Management and related processes. Itenables implementation of process-based accesscontrol for locations and equipment (please referto Figure 2), because field teams can access Process-Driven Inventory e.g. on their PDAs or via SMS. Fieldteams are no longer deprived of system access anddo not have to update the data after returning tothe company.Figure 1). All user tasks related to inventory dataare carried out within the context of a processinstance. It is also impossible to change the state ofa network (e.g. by provisioning a new service) withoutan update of the information in the inventory.These two factors are usually sufficient to ensurethe real-time accuracy of an inventory database.It is also important to underline that centralInventory Management integrated with the networkvia reconciliation mechanisms (that also guaranteeaccuracy) does not provide the same benefitsas Process-Driven Inventory, and so should not betreated as its alternative. Reconciliation mechanismsdo not cover all areas of the network, andthe level of detail that may be achieved in reconciliationvaries upon technology and the businessmodel. For example, in the case of outsourced networkoperations, it may be difficult to attain thereconciliation data, but it is always possible todefine common processes that will ensure informationexchange between the service providerand the operator of the network that will guaranteeconsistency of Inventory. Thus, Process-DrivenInventory and Network Reconciliation should betreated as complementary ways to ensure Inventorydata accuracy.An accurate inventory database driven by automatedprocesses is only the first step towards otherservice and customer-related applications (TroubleTicketing, Problem Management, Order Managementand others). In eTOM, Process-Driven InventoryManagement is situated on the Resource andService Management layers and supports (togetherwith other dedicated applications) processes startingfrom Infrastructure and Product Lifecycle Management,via Operations Support and Readiness toFulfilment and Assurance. It also influences BillingProcesses, especially within non-traffic-basedbusiness models.What benefits do I receive?When looking at Process-Driven Inventory Management,it is evident that when it starts to work,it does so in a cycle: automated processes ensurean accurate inventory database, and on the otherhand, the reliable accuracy of an inventory databaseenables the automation of processes. Thismost notably concerns Network Provisioning processes,where accuracy is crucial for automation.Well-designed processes may curb the need tocreate a central inventory database that containsall data (this often requires too much effort), andit may be sufficient to integrate different systemsunder the umbrella of a Process-Driven InventoryManagement solution. Such a solution also reducesthe costs of introducing a new approach.Another reason to have process-orchestrated,internally consistent and accurate Inventory isthe regulatory organisations that put obligationsupon operators to provide reports on e.g. radiofrequency utilization. Accurate Inventory is a keyfactor for external auditors in their rating procedures,and consistent financial reports are vitalto shareholders.It is clear that services can only be provided ifresources are available. However, new and innovativeservices can be provided with the speedrequired to meet the needs of today’s market, onlyif accurate knowledge of resources and effectivemeans of automatic reservation and assignmentare in place. The latter must include the managementof multiple reservations of the same resourceat different moments in time. The service inventorycan be part of the inventory management database(in this case, the inventory equals the NetworkInventory plus the Service Inventory), or it can alsobe a separate application, integrated via commonprocesses with the Resource Inventory.Streamlining resource, service and customerrelatedprocesses opens new possibilities for theintroduction of more innovative services that areno longer limited by the resource-related issuesthat existed in previous, scattered environments.Operators and providers are no longer limited byregions, domains, technologies or departments inthe provision of new services and service bundles.It is even possible to introduce these, using existinginfrastructure, as the location of unused networkcapacity is now known. This is the source of ROI!Implementation ProjectThe process of implementing Process-Driven InventoryManagement in the heterogeneous environmentrequires in-depth analysis and proper design.The following steps will usually be required:1 Identification of different sources of Inventoryinformation.2 Analysis of data scope and processes: this stepshould include the analysis of overlapping amongdifferent tools which exist permanently. Usually,technology review [www.comarch.eu]


Trends & Strategies < 21Figure 3. <strong>Comarch</strong> Process-Driven InventoryTrouble Ticketing SLA Management Service Management Fault ManagementOther SystemsEnhanced Communication Bus<strong>Comarch</strong> OSS Framework<strong>Comarch</strong> OSSProcessManagement<strong>Comarch</strong>NetworkInventoryManagement<strong>Comarch</strong>ServiceInventoryManagementAuthenticationServiceSystemRepository& ConfigurationReportingServiceNotiffication& EscalationServiceEnhanced Communication Bus<strong>Comarch</strong> OSSConsole<strong>Comarch</strong> OSSWEB Consolemediationdevicemediationdevicemediationdevice<strong>Comarch</strong> OSSMediation PlatformNetwork Environment3 rd partysystemNMS/EMSPhysicaldevicessome inconsistencies will also be identified atthis stage (e.g. naming inconsistencies)3 Decision regarding whether a given source isgoing to be integrated into the final solution ormigrated (replaced): usually, all sources that arenot mature enough to provide on-line interfaces(Excel files, Visio diagrams) will be replaced. Additionally,databases created in-house should alsobe replaced. On the other hand, NEMS and radioplanning tools will be integrated.4 Decision regarding the interfaces: here it is importantto reduce the number of interfaces by implementingstandard solutions (such as OSS/J API)or bus solutions. However, it is not always possible.5 Decision regarding the master system for eacharea of data: this will influence the rules for datamodification in the Inventory and also rules forthe reconciliation interfaces logic. Process-DrivenInventory Management can be the master of datafor some areas (e.g. overriding the role of the systemsthat are being replaced) but not for others.6 Design of the common data model for the Process-DrivenInventory.7 Modifications of the processes resulting fromthe above mentioned points and process designusing PDL (Process Definition Language).8 Design of interfaces.In order to attain quick benefits, the project willusually be realized in phases. The above mentionedsteps will be executed repetitively for differenttechnology or when replacing different systems.Other scenarios of implementation are also possible,for example, as already mentioned before,integration of different systems under the umbrellaof Process-Driven Inventory instead of creation ofcentral Inventory Management.How to choose a Process-DrivenInventory solutionThere are several important features of the Process-DrivenInventory solution that ensure thatthe above mentioned benefits can be easily andquickly achieved:> Process-Driven Inventory provides the layers ofResources, Services and Processes (please refer toFigure 1). These layers should be independent butinter-related. Independency of the layers guaranteesthat there is enough flexibility in definitionof the services and processes, in order to coverall the complicated cases and business models oftoday’s telecommunication world. Relationshipsbetween layers ensure that the resource and servicecontext can be easily retrieved (e.g. servicesaffected by a change process on a resource).> There are numerous BPM systems on the market.Not all of them are well suited to the imple-nr 1/2009 (09)


22 > Trends & Strategiesmentation of Process-Driven Inventory. Processengine should be tightly integrated with InventoryManagement in order to create one consistentgraphical environment for the end user andalso enable easy context data retrieval. Serviceand Resource Inventory data should be easilyaccessible at every step of a process.> The system should allow for integration withthe existing environment, both at the level ofInventory (network and services data retrieval)and Processes (integration with other BPM systems,e.g. trouble ticketing, financial systems).This integration should be enabled by standardbasedinterfaces, e.g. OSS/J Trouble Ticketing API,which speeds up implementation time and lowersthe maintenance costs.> The solution should be flexible in terms of processmodelling, enabling implementation of specificrequirements. On the other hand, however,ready-to-use processes enable the attainmentof “low hanging fruits” quickly and may be sufficientfor the majority of cases. Even better, is ifthe pre-configured processes are based on industrybest practices, like ITIL.<strong>Comarch</strong> offer<strong>Comarch</strong>’s offer within the area of Process-DrivenInventory is based upon our OSS Suite products:<strong>Comarch</strong> Network & Service Inventory and <strong>Comarch</strong>OSS Process Management. These products areseamlessly integrated into the environment providedby <strong>Comarch</strong> OSS Framework, which providescommon mechanisms like user authentication andauthorisation, reporting and graphical user interface.Please refer to Figure 3 for the logical architectureof the solution.<strong>Comarch</strong> OSS Process Management is providedwith a combined eTOM and ITIL process environment,based on GB921V and TR143 by TMForum.It is aimed at helping operators execute managementprocesses from the readiness, fulfilment andassurance areas on the services and resources layersdescribed in eTOM standard. <strong>Comarch</strong> OSS ProcessManagement is a BPM class system. However,as opposed to generic BPM systems, <strong>Comarch</strong>’ssolution has been especially designed to managethe processes of telecommunications operators.Libraries of pre-defined processes are suppliedwith the system, reducing implementation time.Predefined processes include:> Change Management> Configuration Management> Fulfilment> Approval> Task-based access controlIn more demanding telecom environments, readyto-useprocesses can be customised and enhancedin order to fulfil specific requirements. Processdefinitions can be created and modified in jPDL(by JBoss). The solution is equipped with scriptinglanguage, which can be used to define the logic of aprocess’s automatic tasks. It enables manipulationof process flow and Inventory data, as well as theuse of any OSS Framework functionalities.<strong>Comarch</strong> Network & Service Inventory enables endto-endmodelling and visibility of multi-vendor andmulti-technology networks. Network Inventoryinformation is presented upon layers that representgiven technology. Service Inventory furtherextends the Network Inventory functionality andenables the advanced modelling of services. Servicesare stored in the system together with theirmutual dependencies (client/server services) andtheir dependencies upon resources in the NetworkInventory (devices, connections, and others). Servicetemplates are created and modified from thesystem GUI, enabling new services to be introducedto the system “on-the-fly”, in a very flexible way.Service Inventory enables service impact analysisand automated interaction between Service andResource Layers.Thanks to the integration of Inventory Managementwith OSS Process Management in theProcess-Driven Inventory solution, the followingfeatures are available:> Root resource information> Affected resources information> Affected services information> Execution of plans> Reconciliation> Updates of inventory objects – e.g. network elementparameters<strong>Comarch</strong> Process-Driven Inventory can integratewith Service Management, SLA Management, TroubleTicketing, Fault Management and other systems,provided either by <strong>Comarch</strong> or a 3 rd party.>>>MałgorzataKwatera-Knapek<strong>Comarch</strong> SAPosition: OSS Solution ManagerDepartment: TelecommunicationsBusiness UnitInfo: Currently responsible for buildingup solutions for <strong>Comarch</strong> customers,also takes part in major implementationsof <strong>Comarch</strong> OSS systems. Main area ofspecialization: Inventory Management.technology review [www.comarch.eu]


Trends & Strategies < 23Aiming towards bettercustomer experiencewith ITIL and eTOMeTOM is a well-known concept in the telecommunications industry. This article discusses the possibilityof combining eTOM with ITIL, the de facto standard for IT Service Management. It shows the impact tothe OSS and BSS environment of telecom operators, considering also the business benefits that the ITILbest practices will bring, when implemented in parallel with eTOM business processes.nr 1/2009 (09)


24 > Trends & Strategiesoperators in the telecommunicationsmarket are following variousThestandards and best practices such as enhancedTelecom Operations Map (eTOM) and Information<strong>Technology</strong> Infrastructure Library (ITIL). Despite thefact that ITIL is a more generic model and is popularamong all kinds of enterprises that are usingIT management business processes, ITIL can alsobring benefits for the telecom operators and theircustomers, thus it can be the differentiator that assistsoperators in the competitive market.Figure 1. ITIL Service LifecycleContinual Process ImprovementSupplierManagementService LevelManagementService CatalogManagementService DesignAvailabilityManagementITIL Relation to eTOMThe eTOM and ITIL frameworks have been developedin different organizations and for differentgroups of enterprises. As eTOM (developed by TMForum) is dedicated to telecommunications serviceproviders, ITIL is a set of best practices andguidelines for IT service management. Thus, the ITILmethodology can be applied to a larger amount ofcompanies while eTOM is used in the telecommunicationssector only. Recently, an increasing amountof interest has materialized with regard to mappingthe models of eTOM and ITIL with each other.The main purpose of ITIL is to provide bestpractices for efficient operation, service qualityimprovement and long-term cost reduction of ITservices. It focuses on the service lifecycle whichcovers the strategy, design, transition and operationof IT services as well as their continuous qualityimprovement. As a common process model it issuitable for various types of industries. This advantagecan become an issue, because it does not fullycover the typical requirements of certain industrieslike telecommunications. Another differencebetween ITIL and eTOM is the end user scope – ITILmainly serves the internal customers of an enterprise(the employees of a company) while eTOMdescribes business processes that are also relatedto serving external end customers. In other words,the end customers (such as the end subscriber oftelecoms operators) are not always interested if aspecific company follows the ITIL model, especiallysince ITIL is not always visible for external customers.However, ITIL best practices may also supportexternal customers and end users.The eTOM model focuses on communication andcontent service providers instead of general enterpriseswith IT like ITIL does. Its aim is to describetransparent and company-wide business processesdedicated to the telecoms industry. eTOM definescommunication and content services wrapped asproducts and thus offered to external customers. Amajor difference to ITIL is the telco-specific organizationaland architectural separation in horizontallayers according to the TM Forum. Thus, the wholeManagementIncidentManagementEventS ervic e O p erationProblemManagementorganization of a telecom operator is divided intothe four layers: customer, service, resource and supplier.All these layers have strong dependencies anddepend on each other. eTOM is a part of Next GenerationOperations and Software (NGOSS) whichprovides architectural guidelines for the developmentof software systems for telecommunications.The Shared Information & Data Model (SID), also apart of NGOSS, is known as the data model for theorganization of all data objects. This is an importantconstraint for the exchange of data acrosscompany borders. When it comes to IT-related businessprocesses, the use of ITIL seems to be promising– and for telecommunications also.S ervice Strate g yChallengesBringing ITIL best practices into the existing businessprocess environment (that uses eTOM) createsseveral challenges that the operator must solve.In addition to possible conflicts between ITIL andeTOM mappings, the operator’s personnel mustalso be convinced about the new methods andtheir advantages compared to the previous businessprocess environment.The transition of business processes and introductionof selected ITIL best practices must bringITILS er vic e Tra nsitio nChangeService Reporting and Service MeasurementManagementKnowledgeManagementgurationServiceReleaseManagementConManagenetTesting &DeploymentSystemValidationenough benefits for the operator (that is alreadyconducting eTOM business processes), to be worthperforming. Thus, the questions are time and costs– can the enterprise afford for business processtransformation? This brings the need for appropriatetools for measuring the effectiveness ofthe new business processes. It should be possibleto measure with concrete numbers (e.g. %, EUR,ROI).The administrative effort for new business processescan be time-consuming. Thus, the tools fordefining and managing the new business processesshould include the business process managementsystem that can handle business processes acrossmultiple platforms, thus reducing the need formany individual, parallel systems for managingthe business processes. Solving this challenge willresultantly be visible in the bottom-line results, inthe form of reduced OPEX.From the software vendor’s perspective, thechallenge is how to convince the operator toenhance their current operations by also introducingITIL best practices to the environment thatalready follows the eTOM recommended businessprocesses. In the case that the operator’s businessprocesses have been successful already, it is dantechnologyreview [www.comarch.eu]


Trends & Strategies < 25Figure 2. Process Map of eTOMStrategy, Infrastructure & ProductOperationsStrategy &CommitInfrastructureLifecycleManagementProductLifecycleManagentOperationsSupport &ReadinessFulfillmentAssuranceBillingMarketing & Offer ManagementCustomer Relationship ManagementService Development & ManagementService Management & OperationsResource Development & Management(Application, Computing and Network)Resource Management & Operations(Application, Computing and Network)Supply Chain Development & ManagementSupplier/Partner Relationship ManagementEnterprise ManagementStrategic & EnterprisePlanningEnterprise RiskManagementEnterpriseEffectivenessManagementKnowledge & ResearchManagementFinancial & AssetManagementStakeholder & ExternalRelations ManagementHuman ResourcesManagementgerous to “rest on your laurels” and tell yourselfthat business processes and best practices havealready been optimized and there is nothing moreto improve. The introduction of ITIL best practicesinto the existing processes might be considered tooexpensive and not actually profitable enough toperform the operations transition towards ITIL.To support the operators on the ITIL transformation,various types of ITIL tools already exist on themarket. Purchasing a fully equipped set of ITIL toolscan lead to the situation where some aspects of thetools are not used at all. This can be especially truein the cases where the operator has already implementedeTOM-based business processes and wantsto introduce specific best practices from ITIL intothe existing business environment. Another importantissue that is not always considered enough isthat the appropriate tool is not enough for the successfultransition of processes – the result of thetransition will be as good as the experience of theperson(s) who are performing the actual transition.The tools enable the new processes, but are not asubstitute for good processes.<strong>Comarch</strong> ApproachThe introduction of ITIL best practices brings additionalvalue for the operators that are already usingeTOM-based business processes by enabling thefull usage of different layers described in eTOM.Failure events can be propagated between all horizontallayers. For example, depending on whethera reported malfunction is associated to customer,service, resource or supplier layer, an appropriateITIL activity can be launched and the failureresolved. Thus, in the case that the root cause ison a different layer in relation to where the incidentoriginated, the combination of eTOM and ITILprovides an efficient method for solving failuresbetween multiple layers. In accordance to ITIL areported malfunction is called an ‘Incident’. SimilarIncidents can be grouped as ‘Problems’ whoseroot cause can be resolved to avoid more Incidentsof that kind.On the other hand, if an enterprise that alsooffers telecommunications services is using ITILbut has not adopted eTOM yet, eTOM can tailorthe ITIL best practices into the business of a telcooperator using the customer/service/resource/supplier layers defined by eTOM.<strong>Comarch</strong>’s solution offerings for OSS and BSSinclude a built-in, integrated business process managementengine that supports telecommunicationsoperators in their everyday business processes. Theengine can be dynamically configured to suit thechanging principles of information circulation, andreduces system operators’ workload.<strong>Comarch</strong>’s eTOM-based products and solutionscan also support telecoms operators withimplementing ITIL-related best practices. Basedon <strong>Comarch</strong>’s vast experience in the telecommunicationsindustry and participation in standardizationactivities, the implementation of best practicesfor specific business processes will improvethe operator’s business in the form of reducedOPEX, increased customer satisfaction, shorterservice outage time and faster time-to-market fornew services.Let’s assume that the operator (who already hasthe business processes related to eTOM recommendations)wants to transform their incident managementscenario so that it is ITIL-based. The biggestchallenge for the operator is how to keep the existingbusiness processes in shape while attainingthe advantages from the new implemented bestpractices. The advantage of eTOM is realized as theenterprise can separate its business into differentprocess groupings (related to customer, service,resource and supplier) and thus reduce the complexityof individual business processes.For the telecoms operator, a combination ofthe Configuration Management Database (CMDB)and the Shared Information/Data Model (SID) canbe an important issue when mapping eTOM businessprocesses and ITIL best practices together.The usage of CMDB enables the operator to takeadvantage of the ITIL best practices, if the informationon the operator’s repository is SID compliant.Despite SID not being fully applicable for ITIL-basedservice management, many of the SID concepts areadoptable for reuse within the CMDB model. Thenr 1/2009 (09)


26 > Trends & StrategiesFigure 3. Incident and Problem Management with ITIL and eTOMUnknownErrorCustomerCustomerServiceServiceResourceResourceadvantage of this approach is that the operatorcan actually apply the selected ITIL best practiceswithout the need to modify the internal data structures,thus the transformation towards ITIL can bedone faster and cheaper. Because <strong>Comarch</strong> CentralProduct Catalog and <strong>Comarch</strong> 3arts (a compactBSS/OSS/CRM solution) follow SID guidelines, theoperator who is using the <strong>Comarch</strong> solution canPekka ValitaloIncidentIncidentIncident<strong>Comarch</strong> SAPosition: BSS ConsultantDepartment: TelecommunicationsBusiness UnitInfo: Currently responsible for buildingBSS solutions for customers and analysingtrends on the telco market.Customer Problem CustomerReportServiceReportProblemKnownCustomer Customer Restoration Customer ResolutionErrorServiceResourceKnownErrorKnownErrorReportServiceResource Problem ResourceTim WartmannRequest forChangeService Restoration Service ResolutionReportRequest forChangeResource Restoration Resource ResolutionRequest forChangereap the benefits of ITIL processes without expensiveinvestment in the new system platform.CustomerService ResourceWhen introducing ITIL best practices, it is importantthat the scope of the transition project isdivided into several phases – this makes the actualbenefits of the ITIL more quickly visible and is easierto manage. Operator transition towards ITIL should<strong>Comarch</strong> Software AGPosition: BSS/OSS ConsultantDepartment: TelecommunicationsBusiness UnitInfo: Responsible for bulding up BSS andOSS solutions for <strong>Comarch</strong> customers.still be considered as a long-term project, but inclusionof multiple phases is beneficial also for theoperator employees, who can get used to the newIT practices (instead of everything being changedat once) and also be more “cooperative” with thetransformation when there are already concreteresults available showing the benefits of the transformation.An additionally important reason as towhy several phases should be included in the projectis the fact that the business environment maychange over time – and this can have the effectthat the solution may actually become suboptimal.This means that iterative, continuous evaluationof the business processes and practices is neededto keep the processes up-to-date and optimal. Also,measuring the effects of new business processescan be conducted more easily when the project isimplemented in several phases.ConclusionsDespite the fact ITIL is becoming more and morepopular among companies, its implementationdoes not cover all the gaps in the company. Similarly,ITIL may also cause overlapping with otherstandards that are in use within the company. Companiesshould consider ITIL as a set of best practicesthat have to be tailored according to individualcompany needs.The frameworks of eTOM and ITIL provide thebasis for telecoms operators to analyse and modifytheir business structure, enabling the operators toprovide the best possible services and support fortheir end customers. The best practices from ITILand business process flows from eTOM contributetowards a subset of ITIL-based eTOM businessprocess flows. Thus, when used in tandem, eTOMand ITIL complement each other, and contributetowards increased customer satisfaction, betterquality of offered services and reduced operatingcosts. Operators should not only consider ITIL fromthe cost savings perspective – ITIL brings betterservice quality for end customers (for both internaland external), thus also increasing revenue inthe long term.<strong>Comarch</strong>, as an OSS/BSS software vendor, supportsoperators with the transformation towardsITIL best practices, based on the vast experiencethat <strong>Comarch</strong> has gained from the telecommunicationsand IT industry. <strong>Comarch</strong> provides the toolsand essential knowledge that is needed during ITILtransformation based on the individual needs ofeach operator.>>>technology review [www.comarch.eu]


Trends & Strategies < 27The Conceptof B2B GatewayMore efficient communication between business partnersThe traditionalbusiness-to-consumer market in the telecommunicationssector has been the main focus for mosttelecom operators. Due to the increasing amountof players on the telecommunication market, newbusiness opportunities have risen between companies.Typical ways of cooperation on the telecommarket can be e.g. MVNE-MVNO cooperationor cooperation between a Mobile Network Operator(MNO) and a content provider. These kind ofbusiness-to-business (B2B) partnerships bring additionalchallenges, because the technical advancesand highly competitive markets have increased theimportance for B2B platforms as a middle-groundsolution that enables the information exchangeand interaction between operator and businesspartner applications.An example of new forms of business opportunitiescan be seen from the amount of MVNEs thathave recently increased. The MVNEs have emergedfrom MVNOs need to reduce upfront and ongoinginvestments to operate their businesses. Similarly,the market deregulations that have forcednr 1/2009 (09)


28 > Trends & Strategiesthe MNOs to open their network for MVNOs, havebrought more MVNOs to the market, increasingthe already high competition.This article discusses the information exchangeand integration-related business challenges, andhow to solve these challenges. MVNE-MVNO cooperationis used as an example business case.BackgroundDuring difficult economic times, operators arefocusing on enhancing their business operationsand reducing costs at the same time. When therevenue growth from traditional voice serviceshas started to decline, the main way to increaseoperating profits is by cost reduction. One way ofreducing operating costs is realized by increasingthe efficiency of business processes.To stay competitive on the market, operatorsmust be able to adapt themselves quickly to thechanging situation on the market. These changeson the market include the changing economic situation,deregulation, introduction of new services,increasing competition and changing trends (e.g.reducing voice revenues). The operators shouldhave the appropriate tools to perform the neededchanges – if the underlying software platform cannotbe adjusted rapidly to the needed changes, theoperators will have problems staying competitiveon the market. Common problems when adaptingto market changes can be a lack of standardizedinterfaces, a large amount of heterogeneousapplications, the lack of modularized software andthe limitation of the underlying platform when itcomes to bringing new services into the market.Example Business Case: MVNE-MVNO CooperationA typical MVNO does not necessarily originate fromthe telecom industry. Non-telecommunicationbased MVNOs are able to target profitable marketniches and attract more customers by taking advantageof their recognizable brands and well tailoredmobile offerings. Along with the evolution of MVNOsand their growing needs, a market of MVNEs hasemerged. These MVNEs provide MVNOs with all necessaryback-office operations and IT platforms allowingthem to concentrate on the core of their mobilebusiness – developing new tariffs and services andtaking care of customer acquisition and retention.This aspect becomes even more relevant in the lightof how many new MVNO market entrants originatefrom sectors other than telecommunications (e.g.retail) and lack the sufficient expertise to cooperateclosely with mobile operators and develop or maintainnecessary IT platforms. The appearance of theFigure 1. Deployment models for MVNE/MVNO interactionMVNOMVNE platformoperated and hosted byplatform vendor solelyfor the MVNO(e.g. Auchan)Mobile operatorSingle MVNOmodelMVNE enables a new class of solutions which simplifythe initial MVNO business processes.As seen from the figure, the MVNE has the role ofa middleman between the MNO and MVNOs. Thusthe MVNE is responsible for negotiating the agreementwith the MNO and reselling the traffic to allMVNOs it is hosting on its platform. In this scenario,the MVNOs are responsible only for the front-officeoperations of their mobile businesses. The advantagefor the MVNOs is further reduction of up-frontinvestments necessary to start up operations.Business ChallengesAs the available services on the telecommunicationsmarket evolve constantly, the same appliesalso to the services on the operator’s OSS/BSS platform.This brings about the need for open, flexibleOSS/BSS solutions that support the addition of newservices to the existing platform, with minimalimpact on the services that are already operating.When the telecommunications operator has a largeamount of different types of services running onthe platform at the same time, the drawback fromthe platform restart can be too severe and mayaffect revenues and customer experience due tothe interruptions in the available services.MVNO 1Another contributing factor to the minimizationof the impact on existing services is the rapidimplementation time for new services. In a casewhere the operator’s platform is extended to allowMVNO 3MVNO 2Third partyaggregatorMVNE platformoperated and hostedby platform vendorfor the aggregator(e.g. vistream)Mobile operatorMVNO aggregatormodelMVNO 1for automated operations from the business partner’sside, the existing workflows may be able to bereused and thus reduce the implementation time.In addition, the reuse of the existing workflows canalso reduce the amount of possible errors duringthe implementation period.MVNO 3MVNO 2MVNE platformoperated and hostedby platform vendoror by the mobileoperator itselfMobile operatorMultiple MVNOmodelIn today’s business environment, enterprises usea wide variety of heterogeneous systems that areneeded to run business processes. It is necessary tohave these systems integrated properly to reducebusiness process complexity. Nevertheless, the heterogeneityof the systems can cause problems duringintegration. When these systems need to communicatewith each other the amount of differentinterface types results in additional complexity forthe integration. The ideal situation would be if allthe systems used a similar interface and thus theintegration efforts would be minimal. Unfortunately,this kind of situation is rare, as enterprisesbuy business software from various vendors. Figure2 presents an example case, based on MVNE-MVNO cooperation, where numerous systems thatcommunicate with each other (and have differenttypes of interfaces) can cause time-consuming integrationrelated work, higher maintenance costsand poor scalability.In the telecommunications environment, the typicalexternal systems that are integrated with thetechnology review [www.comarch.eu]


Trends & Strategies < 29underlying BSS platform can be e.g. a number portabilitydatabase and external SMS gateways. Theseentities may have different types of interfaces,thus increasing the complexity of the integration.The complexity of the integration efforts furtherincreases, when there can be various amounts ofindependent entities that need to communicatewith each other. Effective communication of softwareentities should be reached by providing commoninterfaces, abstracting the called functionsand services and decoupling them from the transportmedium.The interface that offers functionalities for thebusiness partners should be service-oriented. Thusthe functionalities offered by the operator’s BSSplatform should be wrapped into a service thatcould be used by business partners. By using theservice-oriented architecture, the operator’s BSSplatform enables a higher level of interoperabilityand loose coupling, allowing for easier integrationwith the platform.Example Business Case: AccessProvisioning for MVNOs to theMVNE PlatformTo provide services for the end subscribers, theMVNO needs to have access to the underlying platformof the MVNE. The MVNE that manages the limitedback-end operations on behalf of the MVNOcan offer various functionalities via interfaces, suchas service provisioning, billing data delivery andresource management. The functionalities that theMVNO needs to use from the underlying MVNE platformshould be able to be automated, meaning thatthe MVNO should be able to use its own applicationsto perform the selected operations. This bringsabout the requirement that the MVNE platformshould have the appropriate interfaces that offerthose services for the hosted MVNOs.When the MVNE hosts multiple MVNOs and providesaccess to the BSS platform for the MVNOs,security is a crucial issue, because the hostedMVNOs should not be able to have access to anyother MVNO’s data. For this reason, it is important toprovide security on both the network level and thelogical level. The incoming service requests from theMVNOs should be validated to prevent, for example,situations where the MVNO applies changes to a subscriberwho belongs to some other MVNO.Customization is one additional thing to consider– the MVNE platform may host multiple MVNOs thathave different services available. Therefore, theyhave a requirement for different types of data (e.g.billing data). The different needs of MVNOs typicallyoccur for things such as file formats for billingdata and the frequency of billing data updates.Figure 2. Integration complexity between various systemsBilling DataBilling SystemResourceManagementClearingHouseWorkflowMVNONumberPortability DBSMSGatewayFigure 3. Overview of the B2B Gateway concept, used in theMVNE environmentExternal SystemsIntegrationsBillingMVNOSelf CareServicesCRMWeb ServiceAccessMVNEEnvironmentResourceManagementB2B GatewayBillingIntegration LayerMNO NetworkIntegrationsBillingWorkflowMVNOSelf CareServicesCRMWeb ServiceAccessnr 1/2009 (09)


30 > Trends & StrategiesFigure 4. Usage of ESB as a central layer and a single pointof contactMVNOSystemsDatabasesThus it is not enough that the MVNE can provideaccess for the MVNOs to the underlying BSS platform– the platform must be customizable for individualMVNOs needs.B2B Gateway ConceptThe figure below presents the B2B Gateway concept.The B2B Gateway is a central integration layerbetween MVNE’s BSS platform, MVNOs and externalsystems. The complexity of individual interfaces,that the MVNE environment and external systemsmay have, is hidden inside the B2B Gateway. This way,Pekka Valitalo<strong>Comarch</strong> SAPosition: BSS ConsultantDepartment: TelecommunicationsBusiness UnitInfo: Currently responsible for buildingBSS solutions for customers and analysingtrends on the telco market.ClearingHouseBilling SystemESBSMSGatewayResourceManagementthe amount of interconnection points between theMVNO and MVNE is reduced to a minimum.The MVNOs can perform e.g. service provisioningactivities via web services that are provided bythe B2B Gateway. Communication with the MVNEenvironment can be realized by modifying and usingthe existing workflows, for example, if the MVNE isalready serving MVNOs. The B2B Gateway can alsobe used for delivering usage and billing data to theMVNO via SFTP.Basing on the concept presented above, <strong>Comarch</strong>has developed B2B Gateway solution. It uses EnterpriseService Bus (ESB), meaning that the integrationof internal and external systems is realizedvia the implementation of system-specific adaptersand interfaces, while the communication insideESB is unified.The solution provides secure communicationsbetween MVNO and MVNE environments. To securethe traffic between entities, VPN and/or HTTPS canbe used to encrypt traffic, depending on whichmethod the MVNO wants to use. In addition, someof the integrated external systems may only supportone of the secure communication methodsmentioned. The solution is also secure on a logicallevel: Each MVNO can have access only to the datathat is related to that MVNO, thus it is not possiblefor the MVNO to perform any kind of actions onthe data that belongs to another MVNO that thesame MVNE is hosting. The MVNOs can also be furtherrestricted to do only specific actions, meaningthat the MVNE can restrict MVNO access on two levels:Which actions (commands) are permitted, andwhich objects (customers, contracts…) the MVNOcan have access to.Number PortabilityDataBaseWorkflowBelow are some of the advantages that the B2BGateway solution provides in the MVNE-MVNO businesscase:> Automation: The B2B Gateway provides fast andreliable web service access to the specific functionalitiesof the underlying BSS platform thatis running on the MVNE environment. Whatevercan be done manually using the BSS platform, canalso be done automatically via the B2B Gatewayto increase the efficiency of business processes.> Expandability: The solution supports the additionof new services. When MVNE’s business growthbrings the demand for new services, the ESB-basedB2B Gateway solution makes it possible to integratenew services to the solution on demand,one-by-one, without impacting the existing servicesthat are already running on the platform.> Scalability: The on-the-fly service update alsoapplies to the solution scalability. Because theB2B Gateway keeps the service complexity hiddenfrom the hosted MVNOs, it is possible toupgrade the B2B Gateway according to the businessrequirements, transparently as the amountof MVNOs and their subscribers grow.> Flexibility: The solution is highly customizable.It is possible to decide what MVNO has access towhat services and what kind of data is to be deliveredto the MVNO – e.g. usage data, billing data orboth. The file formats, frequency of data updatesand other system parameters allow for optimizedadoption to the MVNE’s business requirements.> Reuse of existing business logic: The solutionmakes it possible to reuse existing workflow processesfrom the MVNE’s already existing applications.Incoming service requests from MVNOs willbe processed using exactly the same workflowprocesses that are running successfully in theMVNE’s BSS environment. This enables integrityand consistency in the business processes.ConclusionsThe <strong>Comarch</strong> B2B Gateway solution presented inthis article integrates external systems and providesunified communication between all integrated services,thus reducing complexity and increasing thelevel of platform automation.The seamless integration and execution of businessprocesses will be the key issue in cooperationbetween business partners. Business processes arenot just internal any more – enterprises must linkbusiness processes to external business partners.Having an appropriate B2B integration solutionenables telecom enterprises to increase bottomlineresults; by reducing errors, reducing OPEX andincreasing business partner satisfaction.>>>technology review [www.comarch.eu]


Trends & Strategies < 31The Increasing Importanceooooiof the Wholesale Billing DomainA Win-Win Situation for Wholesale Operators and their PartnersTraditional billingsolutions that have been designed for interconnectbilling purposes are not well suited for wholesalebilling. The reason is that interconnect billingsystems have not been designed to group hugeamounts of data using different dimensions andto sum up the appropriate charging scenarios.This problem may occur especially for the billingsolutions that have been designed mainly forvoice traffic and simple agreements, but in addition,operators now require an appropriate billingnr 1/2009 (09)


32 > Trends & Strategiessystem which is not only a rating engine, but alsohas advanced features for discounting, reconciliation,accounting and high levels of automation.In addition, a wholesale billing solution must alsosupport routing optimization, dial plan managementand trading.Wholesale Business ChallengesThe usual interconnect agreements between telcooperators consist of the traffic that traversesbetween multiple telco operators. The operatorsare exchanging the settlements with each other,based on the exchanged network traffic. As theoperators are introducing new services into themarket for end customers, the contents of theinterconnect agreements are widening from voiceservices into data services and this increases theagreement complexity, as new mechanisms maybe needed for pricing the traffic.When compared to interconnect billing scenarios,wholesale billing scenarios can be morecomplex. The agreements between a wholesaleoperator and partner can include agreement typessuch as volume discounts, penalties, volume commitments,swap deals, volume or amount commitmentsfor transit fees, origin-based pricing andcost, transit and termination fee splits etc. Thecharging types that should be supported can bee.g. usage-based charging and non-usage-basedcharging, support for voice and non-voice services(e.g. SMS, MMS, GRX, IPX), trunk-based billing andcalculation of both revenue and costs for the sameset of traffic and services.Also, it is important that the underlying wholesalebilling system supports both bilateral and multilateralagreements between operators. Thus therequired support for both agreements also meansthat the system must be able to support direct andcascade billing. This means that in an ideal situation,the partner should have only one agreement– thus the wholesale operator should be able toprovide interconnect services for worldwide destinations.And the partner should be able to settle forthe usage of all these services with one party.Wholesale operators spend vast amounts oftime and effort on defining and setting up theagreements for interconnect calls, data and otherservices. Many channels of communication cancause complex interaction between partners duringthe agreement setup phase and also when thetraffic is already established. The increased amountof manual work during agreement negotiations,configuration changes, and billing and settlementprocessing leads to increased operational costs.Another case where the effort of manual workmay unnecessarily increase is because of incorrectFigure 1. Sample telecom wholesale environmentVoice andnon-VoiceservicesTradingAgreementsManagementPrices & PrefixesManagementSuppliersHUBCustomersPartner/SupplierRelationshipManagementSettlementsWholesale Usage DataSuppliersHUBand out-of-date information (e.g. when enteringinformation about wholesale partner’s rates) thatmay then lead into further problems at a later stageof business. It should be possible to manage theagreements proactively and measure the volumebasedcommitments automatically. To enable this,it is also required that all information regardingagreements, route costs, margins and other data ismaintained and available in a single repository.To maximize the revenue margins, operatorsneed to optimize their routing processes. Optimizedrouting processes mean that the operatorreaches the target values that are defined in theagreements with partners, and still gets the bestmargins per agreement. Thus routing optimizationis one of the most important processes in thewholesale domain, as the routing configurationWholesaleBilling SolutionNetwork ConfigurationManagementCustomersRevenue Control& PerformanceManagementInvoicesSuppliersHUBCustomersRoutingSettlementReportsReconciliationInvoicingInvoicesSuppliersHUBCustomershas a direct influence on the wholesale operator’srevenue. It is also important that the optimizedrouting data is uploaded automatically to the networkelements and scheduled for the appropriatemoment, e.g. to non-peak hours. This also includesusage of temporary alternative routes during theroute update process and creation of the switchconfiguration backup prior to the actual routingplan update.The wholesale billing solution should supporttrading functionalities that consist of the buyingphase (where a wholesale product is preparedusing offers from suppliers), pricing phase (wherea wholesale offer is prepared for partners using theproducts) and selling phase (where the productsare actually sold for partners). In all these phases,the wholesale solution should be able to assist thetechnology review [www.comarch.eu]


Trends & Strategies < 33Figure 2. Overview of the <strong>Comarch</strong> Wholesale Billing SolutionPartner/Supplier RelationshipManagementAdvanced ConfigurationManagementExisting systemsWholesale BillingTradingFinancialManagementFinancialDocumentsGLRoutingOptimizerNetworkMediation &ManagementRule-basedWholesale RatingSettlement &ReconciliationPartner/SuppliersAgreements,Usage DataInvoicingDataexportDataWarehouseUsageManagementSettlementsInvoicesInvoicesSuppliers /CustomersSuppliersCustomersNetworkwholesale operator in eliminating revenue leakage– starting from the loading of the numbering plansin the buying phase, to negotiating the optimalrates for the different partners and market segmentsin the selling phase.When defining wholesale products and offers,the comparison of partners’ price lists for differentdestinations can be a challenge for the wholesaleoperator, as there can be a large amount of differentrouting, service level and cost options forthe traffic termination. The solution should supportloading and management of complex dialplans together with dial plan validation and testing.Automatic loading and verification should besupported to help with the mass update of pricingand prefixes.A Solution for the BusinessChallengesIn the Figure 1, a typical billing solution for a wholesaledepartment is presented. As can be seen fromit, the solution covers the entire billing process,starting from event collection via mediation, torating, invoicing, reconciliation and settlementmanagement. In addition, the solution supportsrouting optimization and management of productsand offers.The wholesale operator can control the revenuestream, because the solution makes it possiblevia monitoring the network traffic, analyzingit and estimating revenues and costs. In thecase of inconsistencies between the estimatedand real data, the solution issues an appropriatealarm. This is done to ensure proper routing of allconnections, to enable the fulfillment of volumecommitments and protect the operator’s revenues.The solution can also issue alarms connected todetected risks of not meeting the targets for volumecommitment.The billing solution needs to support various billingmodels. It should be possible to define billingmodels using (but not limited to) parameters suchas volume (including commitment scenarios andthresholds), amount, origin and destination, trafficclass, and content. It is also possible to combine theparameters into more complex billing scenarios,and define specific commitment scenarios.In addition to the voice and non-voice agreementsand transit agreements, multiple types ofwholesale agreements should be supported, suchas:nr 1/2009 (09)


34 > Trends & Strategies> Balanced traffic – Financially-balanced trafficbetween two carriers over a given period of time.If the traffic is not balanced at the end of theeffective period, the differences in the trafficamount are billed to the outstanding party usinga specific rate> Balanced ongoing – An agreement on rates where,based on historical data, it is possible to calculatea balance of traffic> Volume commitment – A specific amount of trafficvolume must be paid, whether the volume isreached or not> Thresholds – An agreement where the rates areapplied at a series of steps in traffic volume. Thisusually rewards a carrier for sending higher volumesof traffic> Volume swap – An agreement to swap a certainvolume of traffic to specific destinations.With the solution, the wholesale operator is ableto manage proactively the trading agreementsbetween partners, monitor the realization of volumecommitments, minimize the business impactsof incorrect and out-of-date information, and haveaccess to all agreements that are stored in a singlecentral repository.Also, a reconciliation tool is needed to find thediscrepancies between the wholesale operator’sreport and the partner’s report. This tool can displayall the differences between internal data (e.g.the internal cost invoice of the wholesale operator)and the file that is imported from the partner.It is important that the trading-related businessprocesses are supported. Trading consists ofseveral phases – from product and offer preparationto the actual selling of the product. In the firstphase, the supplier agreements can be managed,rates can be defined and numbering plans can beloaded. The numbering plan import can be mappedautomatically to the offered destinations, includingthe supplier’s rate plans with numbering plansand quality information. Automation also enablesautomatic detection of changes in the rates thatthe supplier is offering. In the offer preparationphase, the real costs of the termination are estimatedand the margins are optimized throughintegration of the routing algorithms. In the thirdphase of trading, the optimal rates for different customersand different market segments are negotiatedand revenue leakage is eliminated.To assist the wholesale operator in finding theoptimal routes for sending wholesale telecommunicationstraffic for interconnect and wholesalepartners, the solution should have a routingoptimizer module. The criteria for finding the bestroute can be defined using multiple parameterssuch as price, quality of service, answer seizureratio (ASR) and post-gateway answer delay (PGAD).When compared to the traditional least cost routingsolutions, the routing optimizer module of thesolution should be an intelligent analysis tool thatuses advanced algorithms for data analysis andproduces indicators for configuration of the routing.It is also possible using the solution to predictfuture traffic based on the analysis of historicaldata.The billing solution that the wholesale operatoris using should assist the operator with managingthe complex relationships with partners and suppliersand provide core features like agreements management,workflow processes, regulated servicessupport, dispute management, orders handling, SLAauditing and managed communication channels.The Partner Relationship Management functionalityprovides support for managing the relationshipswith partners and suppliers, and includes supportfor the automation of most tasks that are requiredto run the wholesale business when cooperatingwith partners and suppliers.SummaryWithin this article, a typical billing solution for awholesale department that assists operators withsolving their business challenges has been presented.<strong>Comarch</strong>’s solution for addressing businesschallenges on the international wholesalemarket is the <strong>Comarch</strong> Wholesale Billing Solution,which contains the features presented in thisarticle. With this solution, wholesale operators areable to enhance their everyday business processesand protect their business interests.In summary, the solution provides capabilitiesand features such as automation of business processes,automatic network configuration management,integrated trading functionality, disputemanagement and reconciliation process support,routing optimization and integration with externalsystems.The wholesale operator receives multiple benefitsfrom the solution, such as reduced complexityof business processes, service convergence, multipleagreement types, scalability and performance,efficient partner management and strong supportfor changes in business.>>>Krzysztof Kwiatkowski<strong>Comarch</strong> SAPosition: BSS Product ManagerDepartment: TelecommunicationsBusiness UnitInfo: Responsible for <strong>Comarch</strong> ConvergentBilling, InterPartner Billing and3arts in area of R&D roadmaps, salessupport and marketing activities.technology review [www.comarch.eu]


36 > Trends & Strategiesbroadband data plans. Users are looking for fast,reliable, customizable and self-manageable services.This opens brand new opportunities for bothexisting and startup service providers; however italso brings about the challenge of deploying theright network and IT infrastructure to provide thebest possible customer experience. Undoubtedly,choosing the right OSS/BSS and customer relationshipmanagement solutions will greatly influencethe customer experience and provide differentiationthat is necessary to survive in this highly competitiveenvironment.In addition, if the operator wants to launch aservice in a reasonable amount of time to enablenew revenue streams, setting up the necessarynetwork infrastructure can represent a challengefor the operator. Thus, the proper approach for theoperator can be to purchase a complete end-to-endsolution from a single vendor, which includes notonly the OSS/BSS solution, but the IT solutions andnetwork infrastructure as well.WiMAX technology has gained popularity onthe wireless broadband service provider market.WiMAX Forum® has forecasted 133 Million WiMAXusers by 2012 (with approximately 70 percent offorecasted WiMAX users utilizing mobile and portableWiMAX devices to access broadband Internetservices by 2012). This highlights the need forproper tools for running WiMAX business. Manystartup operators have already established WiMAXbusiness, and many previously existing operatorsare considering entering into the WiMAX servicemarket. However, some issues exist that the providersshould consider before starting a WiMAXbusiness. It is important to consider such issuesas how to sell WiMAX products, how to deal withsales partners, what services to offer, how to handlesystems and networks, how to manage customers,how to perform the invoicing, and how tomonitor the quality and continuity of the providedservices. Operators have a need for a complete endto-endsolution, starting from low-level networkelement device interaction through rating and upto customer management tools.Figure 1 shows a typical WiMAX usage scenario:WiMAX is used for delivering network connectivityto the home, via air interface instead of a cable.The end subscriber is then able to access Internetservices by using an appropriate WiFi access pointto connect to the WiMAX device that is located onthe subscribers’ premises. Similarly, temporaryWiFi access can be offered, for example, by hotelsfor their visitors. The customer can buy a prepaidvoucher from hotel reception and gain access tothe WiFi network in this manner.Business ChallengesHigh Startup Costs and SystemScalabilityFor new WiMAX operators, startup costs for deployingWiMAX services should not be too high. If thecost for deploying the underlying OSS/BSS systemis too high, it can become a barrier for the new operatorsthat want to enter the WiMAX service market.However OSS/BSS solution costs are not the onlything to consider – another issue can be the costsof the network infrastructure and installation.The challenge not only exists for startup operators– there are many operators that are expandingtheir service portfolio into WiMAX services so theymay offer services in parallel with other services(e.g. fixed broadband services), to offer an alternativeInternet connection or to offer these Internetservices in developing markets and rural areas.For operators that are planning to offer WiMAXservices, it is important that the end users can becharged and billed according to the services provided.Similarly, appropriate business processesshould be defined and modified to support thenew service offerings.Solution Deployment TimeOne challenge for the operator can be the implementationtime of the new solution. The time forimplementing WiMAX service should be minimal,making it possible to begin receiving revenues fromthe deployed service as soon as possible.The typical end-to-end WiMAX solution deploymentproject consists of several phases: Installationof WiMAX network infrastructure (also includingthe masts), installation of WiFi network infrastructure(if needed), integrating the WiMAX networkwith the core network, radio planning, installationof the appropriate IT systems (including the OSS/BSS solution), and configuring the system to supportthe appropriate business processes based onthe operator’s needs.To achieve a rapid implementation of an endto-endsolution, the vendor of the solution shouldcoordinate the project appropriately to finish theproject in time. If the operator, that wants to startoffering WiMAX services, has multiple vendorsadded to the mixture and the operator is coordinatingthe project by themselves, the deliverytime of the project may be delayed due to the lackof coordination between the multiple vendorsinvolved.Roaming and Revenue SharingThe operators that offer mobile WiMAX services orpublic WiFi services should also offer roaming services,to extend the potential customer segment.These roaming services will be an additional revenuesource for the operator in two ways: inboundroaming (when a subscriber of the roaming partneris using the operator’s network resources) and outboundroaming (when a subscriber uses the roamingpartner’s network resources). To implement theroaming functionality, the operator has to negotiateroaming agreements with partners, performup-to-date service billing, automate business processesand perform revenue sharing.Figure 1. Typical WiMAX usage scenarioWiMAXWiMAXInternet BackboneWiFiHome WiFiNetworkWiMAXTransmitterWiMAXTransmitterInternet ServiceProvidertechnology review [www.comarch.eu]


Trends & Strategies < 37In addition, if the operator offers WiMAX connectivityfor WiFi hotspots (the backbone connectionto the WiFi hotspot is provided via WiMAX), thecompanies that host WiFi hotspot locations (e.g.cafes, hotels) can have a share in the revenues.Network Management ComplexityThe importance of managing the network elementsshould not be underestimated. The network managementsystem should not be too expensive forthe startup operators. In addition, the wirelessinfrastructure elements should be managed from asingle system, instead of using multiple individualsystems to manage the network. This is especiallyimportant for operators who offer not only WiMAXservices, but also other services that use differentnetwork technologies.System Integration with ThirdParty ApplicationsA typical operator environment has multiple thirdparty applications and systems that must be integratedinto the OSS/BSS platform. These types ofexternal system can include a credit card authorizationcenter, bank systems, and IVR system. Standard-basedsupport for multiple types of interfacesis needed from the end-to-end WiMAX solution inorder to support the rapid installation and deploymentof the system, thus reducing the financialcosts of the system implementation.Approach for Solving the BusinessChallengesGeneral FeaturesThe solution for WiMAX services should be a comprehensiveend-to-end solution that enables operatorsto start new operations quickly. It is importantthat the solution consists of integrated functionalblocks, to provide the flexibility for the operator tochoose appropriate modules which fit their individualneeds.Each operator has specific needs for the solutionand thus there is no single, unique solution thatcan fit every operator’s needs. If the operator thatwants to set up and offer WiMAX services to endsubscribers is a small company or has only a smallsubscriber base, it may be best to select a WiMAXsolution that is a compact, low cost solution yetstill covers common business processes and helpsthe operator effectively roll out the business.Another approach is to select a solution that canfulfill a larger scale of business requirements. Thiskind of solution is ideal for enterprise customersthat need specialized telco-grade products thatnot only support the core functionalities of WiMAXbusiness, but also bring advanced features to thesolution such as CRM, Service Activation, and ConvergentBilling.Both approaches are capable of supporting themost common business processes, with the maindifference being their scope and scaling possibilities.In the event the first option is selected, thevendor of the WiMAX service platform should provideappropriate information and a roadmap forthe operator related to when and how to upgradethe WiMAX service platform to a bigger solution.This type of information is valuable for the WiMAXoperator, as they can be confident that the platformoffered will consist of up-to-date modules. The vendorof the platform can also provide an appropriatesolution in the future, keeping the platform underconstant development.Core FunctionalityIn addition to solving the business problemsdescribed earlier in this document, it is importantthat the WiMAX platform can perform themost common business processes and thus provideappropriate functionalities that help the operatorwith everyday business scenarios. The solutionshould cover business processes which arerequired in the different departments of a telcooperator. Below is a list of the functionalities thatthe solution should provide support for in each ofthe specific departments:Call Center> Customer relationship management that facilitatesnecessary activities in everyday customermanagement business processes including marketing,order management and trouble ticketing –no matter if the actual CRM user interface is usedin the call center, front office or back office.Point of Sale> Support for Point of Sale functionalities, beginningwith a web-based, easy to use solutionwhere customers can be registered and managed,through partner management and commissioncalculation and ending with revenuesharing and billing.Billing Department> Charging and billing of the services that a customerwould like to pay for in advance (prepaidmodel) or after the service has been delivered (ina postpaid model), or a combination of both.> Roaming support to enable an operator’s subscribersto travel and use those networks whichhave signed roaming agreements with mainoperator. Roaming support also allows usersfrom these networks to use the main operator’snetwork resources. In addition, revenue sharingbetween the operator and partners is an importantfunctionality that is required from the solution.> Top-up and voucher management that integratesthe delivery of various methods of rechargingand payments (via scratch cards, web pages, ATM,IVR, etc). In addition, the generation of vouchers(e.g. based on an amount of time or an amount ofdata) should be provided with the ability to flexiblydefine parameters.> Analysis tool for analyzing business data directlyin edited documents. Users who are not familiarwith database technologies are able to use theanalysis tool to conduct advanced data analysisand present the results in the form of a professional,presentation-ready report.Network Administration Department> Network element management that should beperformed by inventory management functionalitiesof the solution. The operator should beable to observe the current state of the networkinfrastructure being managed by the system.> Coverage maps to display base stations and theirapproximate range, especially when the operatoris offering mobile WiMAX services. It shouldalso be possible to browse network element statusand data.Web Portal for End Customers> On-line web access for customers for reviewingaccounts and performing actions such as topups,generating reports or initiating a troubleticket. Operator could also use the web portalfor upselling and cross-selling opportunities byplacing advertisements and sending marketingmessages for the subscribers who log on to thesystem.Solution StructureRegardless if the solution is targeted at a small orlarge operator, and what the size of the solutionis, it is important that the solution functionality isseparated between different layers. The advantageof the multi-layer structure is that the complexityof the underlying network can be hidden from themodules that are above the network abstractionlayer, thus making it possible to run the same billingsolution above many different types of networks,thus not only on top of a WiMAX network.As seen from Figure 2, the solution has many userinterfaces that support operators’ end users forperforming multiple operations – from points ofsales, through front and back offices, and networkadministration operations. The system core is theconvergent prepaid/postpaid billing engine. Thenr 1/2009 (09)


38 > Trends & StrategiesFigure 2. Usage of different layers for building the solutionDealer Agent CustomerSales forces supportCustomer Relationship ManagementPoint of SaleCRMWeb Self- CareCaptive PortalResourceInventoryTrouble TicketingCredit CardAuthorizationCenterBankRevenue Share &Commission ManagementBilling & real-time Access ControlInterconnect & RoamingSettlementsConvergent prepaid/postpaid BillingTop-ups & PaymentsVoucher & Top-upManagementNetwork & ServiceInventoryNetwork & ServiceAssuranceNetwork AbstractionRemote Management Service Activation Active MadiationWiMAXWiMAXInternet BackboneWiFiHome WiFiNetworkWiMAXTransmitterWiMAXTransmitterInternet ServiceProvidernetwork abstraction layer hides the network complexityfrom the above modules of the solution. Inthis way, it is possible to run the solution abovevarious different network systems, not only ontop of a WiMAX network. Thus the operator shouldreceive a complete end-to-end solution for runningthe business, having complete control of the servicesunder a single system. This brings benefit inthe form of reduced CAPEX, as the operator has toonly to run a single system to control the networkenvironment.Importance of Low Startup CostsFor startup operators, typically the most importantissue is the low costs of the solution and itsimplementation. The operator must be able to startrunning the business with a compact solution thatonly covers the required functionalities, and thenlater, expand the system. Sizing the platform to theexact size of the operator’s business significantlyreduces the amount of the initial investment. Theplatform must be able to grow and expand as thesubscribers increase. The same applies to the ser-vice portfolio complexity. The days of buying softwareplatforms which are scaled in such a way asto be able to handle an operator’s business manyyears in the future have long since passed by. Asoperators reduce their operating costs to improvebottom-line results, it is important to adjust OSS/BSS platform investments according to the currentrequirements and those in the near-future in orderto reduce the amount of CAPEX.Rapid Deployment TimeAn operator beginning to offer WiMAX servicesshould be able to start realizing revenues fromthese services as soon as possible. To start offeringthese services, the operator must have the appropriateWiMAX network infrastructure installed(together with WiFi infrastructure if needed) aswell as the core equipment (OSS/BSS systems, routingand switching). To achieve this, it is importantthat the operator chooses a reliable WiMAX solutionvendor which has already implemented similarsolutions and was able to meet the timelinerequirements for the delivery of the solution.The importance of selecting the appropriatevendor is highlighted in situations where the newWiMAX operator needs to purchase a complete endto-endsolution, because selecting multiple vendorsinstead of one can lead to delays in the delivery ofthe project. When there is only one vendor as a singlepoint of contact during the project, the coordinationof the project is taken care of by the WiMAXsolution vendor and the operator need not managethe project between the various vendors involved.Network Monitoring andProvisioning ActionsThe network infrastructure status should be ableto be observed from the system, right from thetechnical staff’s screen, and provide real-time performance,coverage and fault monitoring. Anotherimportant feature is the observance of networkstatus (from the perspective of service continuity)through coverage maps. If the operator offersnon-WiMAX network services, these could be integratedinto the solution as well, to be controlledand observed from a central point.technology review [www.comarch.eu]


Trends & Strategies < 39Key features of the solution:> WiMAX and WiFi network> Prepaid and postpaid service billing> Coverage maps> Network and service monitoring> Trouble ticketing> Customer Relationship Management> Web portal for customer self care and captiveportal> Multitenancy and reseller brandingMain benefits of the solution:> Reduced operating costs> Improved time-to-market for new services> Single platform for managing multiple types ofservices> Integration with external systems via standardbasedAPIs> Short implementation timeWhat can <strong>Comarch</strong> offer?> Green field deployments> Network planning> Installation and integration of network infrastructure> Design of services> Analysis of a customer’s business processes> Implementation of OSS/BSS/CRM systems> Project management> Data Center services> Maintenance and operation servicesIn addition, the solution should be able to automaticallyprocess access provisioning actions, serviceconnection and disconnection, restriction ofaccess to a walled garden (in case of lack of payment)and shaping traffic based on configurablerules. All these automatic features will assist theoperator in running the business smoothly withminimum manual intervention, thus reducing theoperating costs.Replacement of an Existing BSS/OSS PlatformNot all operators are completely replacing theirexisting platforms when bringing additional servicesto the market. Thus it is important that boththe underlying OSS/BSS platform and the implementedWiMAX solution components be integratedtogether without complex, proprietary interfacesthat can become expensive to integrate properly.The integrated systems should contain appropriateAPIs and support the most common standardizedinterface types.ConclusionsThe features of an end-to-end WiMAX solutionthat have been presented in this document enableWiMAX service in an operator’s product portfolioin a reasonable amount of time. It is important forthe WiMAX operator to have an appropriate solutionwhich benefits not only the operator itself,but the end subscribers as well.<strong>Comarch</strong>’s end-to-end WiMAX solution has beendesigned based on the characteristics mentioned.The solution is suitable for start-up WiMAX operatorsand also for already established operators thatwant to expand their service portfolio into WiMAXservices. To summarize, the solution advantages forthe operators can be classified as a reduction inoperating costs, improved time-to-market for newservices, a single platform for managing multipletypes of services, improved customer experiencethus reducing churn, and seamless integrationwith third party systems.An appropriate WiMAX solution also bringsadvantages to end subscribers. Increased customersatisfaction, access to a customer self careweb portal (for ordering new services, viewingusage data, recharging an account, etc.), prepaidand postpaid service types, faster resolution ofproblems (through trouble ticketing) and the possibilityof using roaming services. These are theadvantages that help operators increase subscriberretention.>>>Cooperation with PartnersWhen implementing an end-to-end solution forWiMAX, it is important that the solution also supportsboth inbound and outbound roaming, tobring an additional revenue source for the operator.Appropriate settlements for roaming partnersshould be able to be produced by the solutionand the solution also should also support automaticreconciliation of settlements between partners.Similarly, the revenue sharing functionalitybetween the operator and partners is an importantfeature to be performed by the solution. Thepartner does not have to be a roaming partner –the partner can be for example, an external serviceprovider or a dealer at the point of sale.Pekka Valitalo<strong>Comarch</strong> SAPosition: BSS ConsultantDepartment: TelecommunicationsBusiness UnitInfo: Currently responsible for buildingBSS solutions for customers and analysingtrends on the telco market.Krzysztof Kwiatkowski<strong>Comarch</strong> SAPosition: BSS Product ManagerDepartment: TelecommunicationsBusiness UnitInfo: Responsible for <strong>Comarch</strong> ConvergentBilling, InterPartner Billing and3arts in area of R&D roadmaps, salessupport and marketing activities.nr 1/2009 (09)


40 > Case StudiesTowards semantic modelingof physical devices in NGOSStechnology review [www.comarch.eu]


Case Studies < 41MotivationOne of the challenges faced by NGOSS systems isthe increasing need for consistent management ofphysical network equipment. In large companiesthe time consumed by maintaining thousands ofdevices and finding solutions to possible problemsis constantly on the rise. State-of-the-art technologiesenable vendor independent equipment typeidentification and access to the attributes of thecomponent types. Furthermore, current solutionsoften provide the user with convenient graphicalmodeling of the physical elements structures, butare usually unable to provide consistent supportto the user, by answering questions that involvesophisticated configuration related constraints.In our approach, we propose a solution whereequipment is modeled using a dedicated DomainSpecific Language enriched with the power of thebest available logic-based reasoning services. Thisenables us to define a rich layer of semantics ontop of the structural description of the devices.This way, the configuration related constraints areexpressed declaratively, in a platform independentmanner, and are managed in an integrated waywith the structural model. The information keptin the model can then be used on runtime to giveguidance to the system user.Problem descriptionOne of the usage scenarios targeted in the MOSTproject is the management of physical networkequipment. Myriads of device types and their configurationscan make user’s everyday work a nightmare.For example, each time a card in some deviceis broken, the system operator faces questions like,‘what are the possible replacements for that card,are some options better then others?’On the other hand, a system analyst planningnew services on a particular device wants to knowwhat components he can use with that device, ifpossible, from those available in the company’swarehouse.Similar questions may also arise while integratingmanually maintained repositories ofphysical network equipment. In such cases, automaticchecking of device configuration correctnessor even finding the exact device type usingonly information about its configuration, wouldsurely improve the integrity and correctness ofexisting data.As shown, there is clearly a need for tools providingadvanced support helping users make correctdecisions, tools based on knowledge bases andsemantics, able to learn, reason and bring meaningfulanswers for user questions.Figure 1. Example Cisco 7603 chassis installationCisco 7603Figure 2. Cisco 7603 physical device configuration descriptionCisco 7603Slot 1Slot 2Slot 3Slot 1Slot 2Slot 3Cisco Supervisor 1Cisco Supervisor 2Cisco Supervisor 1or Supervisor Engine 7200Supported Catalyst 6500 seriesmodule, Cisco Supervisor 2 orSupervisor Engine 7200Supported Catalyst 6500series moduleSuch tools, guiding and supporting usersthrough tedious tasks by answering the questionsmentioned, would generate substantial profit, andreduce the number of potential errors in deviceconfiguration. It would also improve productivity,and mitigate the time consumed studying the technicaldetails of a device’s documentation.Domain Specific Languages andOntologiesOne of the first things to do in the MOST project, wasto identify parts of <strong>Comarch</strong>’s OSS suite that canprofit from the research most. Modeling physicaldevices was a perfect candidate, and for a reason.Firstly, a network of physical devices can easilybe described using a limited number of conceptsthat makes it a subject of Physical Device DomainSpecific Language. On the other hand, possibledevice configurations and connections build somekind of knowledge base, which would be hard toexpress using structural models, but are ideal forrepresenting as an ontology.If (Cisco Supervisor 2 orSupervisor Engine 7200) {exactly the same type as in slot 1}Domain Specific Language provides a formal butsimplified description of a specific domain.Maintaining models using small but clearlydefined concepts and syntax, increases productivity,resistance to mistakes and readability of thedesigned models.An ontology is a specification of a conceptualization.That is, an ontology is a description ofconcepts and the relationships among them fromsome point of view. For example, from the point ofview of a system analyst that is modeling physicaldevices.Ontology simply putEveryone uses more or less formal ontologiesevery day. When we see a girl on the street callingan older person father, we suppose that thegirl is the daughter of that person. Formally, therelationship “daughter” is inverse to the relationship“father”. Knowing ontological relationshipsbetween people gives us the possibilityto reason from partial knowledge.nr 1/2009 (09)


42 > Case StudiesOntology not only enables knowledge sharingand reuse, but together with a reasoning engine,provides inference capability.In the scope of the MOST project, our work goestoward extending the expressiveness of the domainspecific language for the description of the physicaldevice structure. This is achieved through integrationof Domain Specific Languages with Ontology,and thus opening new spaces for modeling structureand semantics together. What’s important isthat integrated models remain easy to edit and processusing existing tools and approaches, being astructural and semantic model at the same time.Use CaseThis section presents a real life example of modelinga physical device and shows the advantages of usingDSL enriched by the ontology. It presents a usual situationin telecommunication companies when one ofthe physical device cards is broken or not supportedany longer and requires replacement. Figure 1 presentsan example configuration of the Cisco 7603 chassis.It contains two cards. The card in slot 1 is a supervisorcard, required by the device to work properly. Inslot 2, a backup supervisor card is inserted.Let’s suppose that main supervisor card is brokenand requires replacement. The person responsiblefor this device receives a notification aboutthe problem and begins to resolve it.Current solutions of OSS systems require deepknowledge about every sub-component of thephysical device (what kind of cards can be used asa replacement for a broken card, what kind of constraintsa particular card has, etc.). The standardprocedure in such cases is that the user studies thedevice documentation looking for technical detailswhile being simultaneously bothering about howto get the replacement (e.g. if it is available in company’swarehouse, or if it must be ordered). Managingthese kinds of issues in a large scale devicenetwork is difficult and time consuming.To limit the effort required to solve such problemswe designed DSL that describes the structureof the physical device and stores information abouta possible connection between physical device elements.The description is enriched by the ontologyconstraints that guard the correctness of the createdconfiguration. In our example one of the constraintsthat occur is that the Cisco 7603 physicaldevice requires the same models of the main andbackup supervisor cards (see Fig. 2).Of course the internal structure of the domainspecific language and ontology will be hidden fromthe user, who will receive user-friendly wizards andcontext actions. In our example a new generationOSS, enriched by guidance capability, will showtwo possible actions to perform:> Order the same card model> Find all possible replacements available in storageThe first action will start the process of orderingthe card model and the second one will locate allthe cards with the same functionality as the brokenone. Additionally, the process of finding a replacementtakes into account every constraint the physicaldevice has. In our example, only the cards ofthe same type as the backup supervisor card willbe found.ConclusionIn order to fulfill customer demands, the <strong>Comarch</strong>OSS research and development department is constantlyactive in research for technologies intendedto improve user productivity and the comfort ofwork. Even though ontologies in computer sciencehave been used for a long time, integration withdomain specific languages is a early innovation inthe field of data modeling. The problems describedand appearing in everyday tasks are of an abstractnature and cannot easily be solved using existingtools and approaches. Introducing integrated modelscontaining structure and semantic informationwill surely be a great advantage, and will lead tothe improvement of existing systems, making themmore user-friendly. The presented usage scenarioserves as a proof of a concept for ontology enrichedmodeling. Initial results have already proved itsusefulness in the development of user-friendly,efficient tools. We can therefore expect them tobe implemented in <strong>Comarch</strong> OSS soon.MOST, “Marrying Ontologies and Software <strong>Technology</strong>”is a project co-funded within the SeventhFramework Programme. www.most-project.eu>>>Paweł Sabina<strong>Comarch</strong> SAPosition: Software AnalystDepartment: OSS Research & DevelopmentInfo: Work package leader in MOST Project.Marek Kasztelnik<strong>Comarch</strong> SAPosition: Software AnalystDepartment: OSS Research & DevelopmentInfo: Expertise in physical devicesmodeling.Krzysztof Miksa<strong>Comarch</strong> SAPosition: Project ManagerDepartment: OSS Research & DevelopmentInfo: MOST Project Coordinatortechnology review [www.comarch.eu]


Get all your pieces togetherGet it right with <strong>Comarch</strong>Interconnect Billing Solution<strong>Comarch</strong> Interconnect Billing Solution enables you to handle anyservice type using one platform. Full, convergent platform that handlesvoice, data, SMS, MMS, premium or modern content services and evenroaming. All those can be efficiently managed using this carrier-gradesolution supporting you in your everyday operations and in developingyour business.Learn more atwww.interconnect-billing.comWe know that billing solution is crucial for business performance. Weknow that it is deployed not for one year. We know that it must befuture-proof – as such solution has been designed to serve today butalso tomorrow services despite of network type or partners that youdeal with.Interconnect business means working with partners and managingrelationships with them. <strong>Comarch</strong> is giving you the tool for managingyour Agreements and relationships with partners and suppliers as apart of the Interconnect Billing solution. Additionally to support you inresolving all disputes with partners and suppliers solution automatesDispute Management and Reconciliation of Settlement Reports.


Need to simplify managing wholesale agreements?Dealing with complex routing structures?Looking to optimize traffic trading?Discover <strong>Comarch</strong>Wholesale Billing Solution:wholesale.comarch.comMake sure your wholesale business is in good hands!The <strong>Comarch</strong> Wholesale Billing Solution is a complete solution for wholesale departments,supporting them in everyday operations and protecting operator’s businessinterests.Learn more atwholesale.comarch.comThe solution provides you with the following benefits:• Increased sales margins• Automation and reduced complexity of business processes• Integrated trading functionality• Ability to optimize and perform routing changes quickly• Automatic network configuration management• Support in dispute management and reconciliation processes• Increased partner and supplier satisfaction

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!