Service Providers Surveyed on Next-Generation OSS/BSS and SOA
Susana Schwartz
01/01/2005
"Implementing a next-generation operational and business support system (NGOSS/BSS) is supposed to facilitate faster time to market as well as enable a single point of contact for customers wishing for more self-service capabilities. As service providers look to enhance self-service offerings, they rely not only on NGOSS/BSS but also consolidation of back-office systems and real-time access to information through service-oriented architectures (SOAs).
In an Apex Research survey conducted in October, 17 major service providers across three continents revealed how they intended to deploy technologies and strategies around NGOSS/BSS, and the role that SOA will play.
Of the respondents, 75 percent indicated next-gen OSS/BSS was a top priority, but that consolidation of the back-office into a common framework would depend on SOA—the concept of building components of software that disparate front-end systems can access.
That leads to network configuration, network inventory and service inventory that are independent in terms of the service provisioned and in terms of the technology required to support those services.
The survey reflected that SOA is very important to 35 percent of the respondents, who indicated it was the primary framework underpinning their next-gen OSS/BSS. The remaining 65 percent regarded SOA as an important secondary influence. Although given the option, no service providers indicated that SOA was not an important part of their next-gen OSS/BSS.
In terms of how far along service providers considered their NGOSS deployments, 47 percent indicated that they had partially developed and implemented their next-gen OSS/BSS, and 41 percent indicated that their NGOSS/BSS was under development but not yet implemented.
Web Services has become the latest incarnation of what SOA can look like (joining the rank of NGOSS, eTOM, TMN and others), as it plays a key role in service providers' plans. In the survey, 29 percent indicated that Web Services was an integral part of their current architecture, and 59 percent indicated that they were selectively using web services today. Only 12 percent indicated that they were still in the nascent stages of employing Web Services.
Respondents cited several important components of their strategies. Some 88 percent identified the desire to reduce the number of legacy point solutions as the key to their deployments. Following in importance were the goals of flow-through provisioning (82 percent), logically centralized/unified customer data (71 percent), unified network management (71 percent) and rich web self-service applications (65 percent).
Mid-tier Data Caches
Because of the growing importance of SOA in telecom, it is expected that mid-tier caches and data stores that reside in the middle of three-tier architectures will become extremely important to NGOSS/BSS.
"The middle tier becomes a means for 'decoupling' applications from back-end systems so that information is procured faster and in a reusable manner," says Apex Research CEO John Bailey.
He believes that as SOA evolves in OSS/BSS deployments, systems will make huge migrations from database-driven to events-driven architectures. "The front end will no longer connect directly to back-end databases," say Bailey, who maintains that three-tier architectures will highlight the middle tier's importance, "as it will form the foundation for how the data is accessed."
Service providers are using mid-tier cache/data stores for maintaining sessions of three-tier customer-facing applications—for example, in online bill presentment and payment applications—so that requests for billing information will no longer require exhaustive data access, every time a self-service or CSR screen is refreshed for a different calculation.
Service providers will require system flexibility to separate applications from their networks, as well as from data stores and servers, and to have myriads of applications accessing the same data without hard-coding ramifications.
"The idea of a mid-tier data cache is getting more attention, because data marts are historical in nature; they depict what has already transpired," explains John Trembley, director of telecom and networking at TimesTen, which co-sponsored the Apex study. "Because there exists no tracking of active data, traditional data stores designed around batch processing lack the performance capabilities needed for real-time application."
Traditional systems were built for big queries against large data stores. They yielded trending information, such as what percentage of customers were delinquent, or how many customers used a certain combination of good and services. "Now, you don't want to flood people with all data; you want to give customers immediate access to just the performance-sensitive data, rather than mixing in historical data they don't need," says Trembley. One example would be enabling subscribers to check the remaining minutes in a wireless plan quickly.
Mid-tier data caches will be the means by which historical data and operational data come together, according to the study. "Operational data stores need dynamic information to properly provide trouble ticketing management, work force management, accounting, and other services," says Bailey. To accomplish that, they must generate and maintain reference copies of data about network inventory or customer service inventory.
For that reason, 40 percent of service providers are creating a data cache as part of their NGOSS deployment, according to the Apex study. "In two years, we think that will increase to 64 percent," predicts Bailey. He contends that the data cache is the layer where service providers can put together a full customer view. "In three-tier applications, the Web site is communicating directly with the back end; however, mid-tier components do know how to get to the mainframe system," says Bailey. The front end has the recent information, which is sourced from the back end.
Most service providers in the study currently use the mid-tier cache for assurance, such as DSL assurance, or for trouble ticket systems.
In the study, providers also were asked about more advanced mid-tier cache/data store technologies, such as in-memory databases, object data management systems, object caches and custom caching mechanisms/flat files. Although a smaller percentage of the service providers surveyed use these technologies currently, several commented that they were considering them in their mid-tier cache/data stores: Traditional relational databases and application server caches are the prevalent technologies that service providers employ in their mid-tier cache/data store. According to the study, 100 percent of respondents use conventional relational databases, while 79 percent use application server caches. Another 20 percent use in-memory databases, and 21 percent use custom developed caching. Object data management is being used by 14 percent, as are object caches—also used by 14 percent.
Service providers indicated that 53.9 percent of their SOA deployments were implemented on a J2EE application server platform and projected that the percentage would increase to 65.6 percent within 24 months.
"If they are using a conventional relational database in a three-tier architecture, they have the data mart or data warehouse for historical data at the bottom layer; then, in the middle they have a relational database to address the operational data needs–usually with Oracle or DB2; and then, at the top tier reside the caches from application servers, or proprietary flat files or hash indices," Trembley says.
In building a three-tier architecture where the data is not latency-intensive, service providers can put some data in the application server caches rather than the back-end data stores, or they can use in-memory databases. "Conventional relational databases are not designed for quick turnaround of the data, which is necessary in mid-tier caches. And, application servers are not relational, so complex searches are difficult for them," Trembley explains. "Their foundation is a hybrid between hash indices and flat files, which go fast but possess no standards-based reliability and recovery." Because he thinks full-functioning relational databases are too "heavy" for what service providers need, Trembley predicts that hybrids will provide the speed plus familiarity and power associated with conventional relational databases. "In-memory databases will be the way to go as SOA evolves," he says.
In terms of what is the most important requirement of mid-tier/data stores, service providers cited the importance of functionality that directly impacts the customer: scalability, high availability, response time and robustness/reliability. "In the study, service providers emphasized the importance of variables that directly impact the customer's experience, versus those that affect the back end," says Bailey. "They noted response times through IVRs were paramount in staving off churn, and that scalability was germane to handling millions of transactions and keeping costs down."
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article