Balancing the network needs of today versus what’s required to grow the Multiple Services Operator (MSO) proposition in the future can be a complicated task. Both federation and consolidation of core network and service data are valid approaches, and each is being touted as the end-all solution for evolving MSOs. Those using one or the other may claim their choice was the most effective. So, how can an MSO decide which method fits their needs? This article will provide practical tips on how to evaluate each method and determine which makes the most sense for your problem.

 

 

Every operator provides services that need 24/7/365 performance continuity, and this is where the question of federation or consolidation becomes critical. Call setup, session orchestration, identity management, policy management, presence and location-based services are just a few examples where lack of service continuity can quickly turn the consumer off. As the customer’s frustration builds they may even seek a new provider. A classic example of this was in the early days of mobile Internet WAP services, where poor end-to-end connectivity often made it a gamble if you got to view your Web page or not. This resulted in the slam-down syndrome, where the first experience was frequently so poor that customers would just give up.

 

With data federation, there is a much higher chance of service failure. Federation leaves data where is it and merely adds another meta-layer on-top, creating a new view of the data held in other databases across the network. While this has the advantage of not radically shaking up the existing network topology, it does mean that more complexity, latency and points-of-failure are added into the network. The more complex the network, the longer the response times become, not to mention the increased chance of a component failure along the way. It’s a bit like the postal service, where you can never guarantee how long it’ll take for the message to arrive.

 

The data consolidation approach to the network and services is a much better option. In contrast to a federated data network, which relies on adding a new layer of technology, a consolidation simplifies the process by eliminating layers. Reducing the number of layers immediately increases response times. Another core performance differentiator is that in consolidated data networks, data becomes unified into one logical source. This means that all data can be shared with any application through a single open interface, bringing with it deterministic response rates and the ability to guarantee service levels.

 

 

Opening up your core network and subscriber databases is a major decision. There are security concerns, technical challenges, compliance, governance and contractual details to consider — none of which are simple matters. If management decides to engage in sharing data with a broader eco-system, the network engineering team will need to grapple with these issues.

 

Adding a federated data layer on top of a data consolidation approach is actually a good strategy. Federation creates a mediation layer through which selective subscriber data can be safely shared with third parties. Security is easily addressed with a federation approach as it abstracts the schema on-top of the core network ‘open access’ data layer. Abstraction also allows the data schema to effectively hide the underlying framework, creating a virtual system. This has advantages for third-party applications as it means that changes to the base schema can be hidden from the ecosystem, avoiding un-necessary modifications to application logic, and creating a more manageable solution. It also allows the third party to post updates to an abstracted view of data, leaving it up to the business to decide what the implications might be on the underlying data sources.

 

However, while many third-party applications might not be mission critical, increasingly applications require high performance as customers expect a 24/7 experience and immediate responses. So, a balance can be struck for these third-party applications. Data access can be provided through a data integration framework, which maintains minimum latency requirements while allowing access to data to be flexibility configured through a rules engine. This allows data to be accessed using protocols typically used by developer communities, such as SQL or SOAP, facilitates data integration from multiple sources, while implementing almost any kind of control, monitoring, security measure or data manipulation.

 

 

Launching new services is a difficult task for any operator. The marketing team needs to identify an opportunity, the business group must have a clear view of the costs and ROI, and the engineering teams need to build out the platforms and support systems. The first two stages of this process rely almost solely on knowing as much as possible about a provider’s current subscribers. Who are they and are they likely to use the new service? Without a mature, unified subscriber profile this is a very difficult and time-consuming, and can often lead to false assumptions. At the same time, engineers must struggle with the data spaghetti and the integration tax that each new service brings.

 

In a recent Apertio (News - Alert) survey, operators declared that on average it takes seven to twelve months to launch new services, while they typically desire to launch services in three to six months. The result is five missing months between the reality and expectation. Data Consolidation takes a big step towards speed up the pace of innovation by opening up all subscriber data for any application to access through standards based interfaces.

 

However, choosing the right database technology to do this is critical. Mature providers will have very distinct data silos spread across their network elements and service platforms, often holding land-locked subscriber profiles. This occurs when an operator’s network embeds valuable customer data inside vendor applications or when two or more networks are mashed together after a merger.

 

From a network engineering vantage-point, muddied networks like this reduce the ability to launch services more quickly, bringing major development and administrative problems. For example, if a fixed-line Telco operator merges with a wireless carrier or a cable provider, the new entity will have two or three very distinct, and often incompatible, networks that are forced to work together. Federation would simply add another layer to this bird’s nest of technology without simplifying subscriber data management.

 

 

In a business where your organization might not own all data sources, consolidation may not be the wisest choice. While consolidating data belonging to a third-party company may be totally impractical, even within one business, political alignment between different organizational domains may be necessary for consolidation to take place. In these environments a data federation approach is typically the best alternative. Each system can be left intact, administered by a separate team or entity, while data can be abstracted to create a unified view of all customer data. Access control to customer data can be managed both at the abstracted level and within each data source, giving each organization full control over their data assets. Additionally, data abstraction may involve representing data with a meta-data language, allowing unparalleled flexibility to merge and mash-up data, creating many new views on data from disparate sources.

 

 

If the motivation to update the core network is to reduce operational expenses for the MSO, consolidation is again an ideal option. Silos of data, miles of server racks, administrative overheads, and the data integration tax translate into ballooning OPEX and CAPEX. As networks become more complex, more equipment is required. In turn, this translates into the need to hire specialized and highly trained support staff and costs continue to snowball.

 

Consolidation eliminates this complexity by unifying data into one Common Information Model (CIM), supported by a single, distributed, database platform. The CIM is effectively owned by the operator and contains all subscriber profile data for every identity, device, network, service, and customer preference. Consolidation is conceptually a revolution as it allows operators to begin to monetize subscriber data, but the process of implementing consolidation continues to be an evolution, as data accretion progressively happens as the network architecture develops. In fact, to stay competitive with fast moving, data-driven service providers, operators will turn to consolidation as a strategy to stay competitive, turning data into knowledge and customer dialogue.

 

The cost savings become apparent when looking at the hardware aspect of consolidation. Miles of racks and servers could be eliminated if terabytes of data were moved to pizza-box sized hardware on carrier-scale database technology. For example, T-Mobile (News - Alert) in Germany realized tremendous savings on floor space and equipment, as it was able to consolidate more than 20 Home Location Registry (HLR) servers, distributed over 11 sites down to one database, distributed over three sites and supporting 37 million subscribers.

 

 

While consolidation and federation both have their advantages, experience is proving that a balance should be struck between both approaches. Where the requirements of performance, scalability, and cost control are paramount, data consolidation provides clear advantages. However, third-party access to subscriber profile data can justify a dual approach, where a data consolidation approach is complemented with a data federation and a data integration framework. This ensures service availability is maximized, latency is minimized, and core infrastructure is kept as simple as possible. One way to picture this solution is in a layered approach, where the core information infrastructure is consolidated. An additional data access layer opens up the core data assets for integration with multiple sources that require high performance. Finally, an outer layer federates profile data with external Web 2.0 applications.

 

Ultimately, the choice of underlying database technology will be the critical issue to secure strong technology foundations. As the bottlenecks brought about by enterprise-class database technology are replaced, a new generation of carrier-class information architectures is preparing MSOs to become a value-added channel to market for the broader open IP eco-system.

 

-----