CNET también está disponible en español.

Ir a español

Don't show this again

The IT factor in mobile services

McKinsey experts say mobile telecom companies will need to redraw their IT architectures if they hope to market new services quickly and cheaply.

The IT factor in mobile services
From the McKinsey Quarterly
Special to CNET News.com
August 24, 2003, 6:00 AM PT

Boosting revenue in the face of slowing subscriber growth has become a priority for mobile telecommunications companies in Europe and North America, and to that end, they are launching any number of new services to consumers.

But in launching these services, mobile operators must solve a swath of strategic and marketing problems--and deal with vexing operational challenges that stem from the structure of the technologies that support the business.

Like companies in so many other sectors, mobile operators have for years installed one information technology system after another, and the interconnections between them have become complex and often inefficient. Modifying these complex systems or adding new ones to the mix is more and more costly and time-consuming.

The lesson is that mobile telecom companies need to redraw their IT architecture if they hope to get a stream of new services to market quickly and cost-effectively. The way forward is to remap today?s jumbled mixture of IT systems into streamlined domains defined for business rather than IT reasons.

The approach we recommend is already in use among some fixed-line telephony companies, but mobile operators have only just started down the road. They have every reason to step up their efforts.

Reinventing the wheel
One reason many mobile operators find it hard to market their products quickly is a complex and inflexible IT architecture that forces them to develop many parts of each new product almost from scratch. Product developers who can?t reuse components across applications--even, at times, bedrock support functions such as billing and customer information--must constantly reinvent the wheel.

Mobile operators have only just started down the road. They have every reason to step up their efforts.

Reusability is rare, because speedy growth meant everything during the boom years of the late 1990s, when companies had neither the time nor the inclination to consider which components could be reused in other products. The quickest way to get out new products was to patch the existing architecture by forging connections between whatever systems needed them immediately. The result was an increasingly complex, spaghettilike architecture littered with incompatible stand-alone systems, based on software from a number of vendors and often using a variety of data formats such as customer databases with different sets of vital statistics.

A restaurant finder--a location-based mobile product that some of the most important operators already offer--illustrates the problems. A subscriber requests a list of nearby eating places, perhaps by the Short Message Service (SMS) or the operator?s mobile Internet portal; the operator notes the hungry caller?s location and replies with a list of restaurants. An operator developing such a product starts by defining its characteristics: which countries and cities to include, whether to add more detail (such as opening hours and prices), how to deliver the information to the subscriber (SMS, the Multimedia Messaging Service, or the mobile Internet), and a pricing scheme, which could involve a fixed monthly sum, usage-based fees, or fees based on the data usage that requests generate.

Then programmers get to work creating the applications, databases and interfaces. This is an arduous process that involves thousands of hours of coding, and the longer the code takes to write, the costlier the development of the product and the more time needed to bring it to market.

The product also needs a restaurant database, perhaps licensed from local guides, because the richer the information, the happier the subscriber. Likewise, the user experience will be vastly improved if suggestions are tailored to individual wallets and tastes. Marketing executives would want the software developers to concentrate on improving the user experience; after all, the other main ingredients of the restaurant finder will just be support features also developed for earlier products such as customer profiles (is the subscriber a teenager most likely looking for fast food or a business traveler seeking a more up-market establishment?) and systems for locating and billing subscribers.

This is when the problems begin.

The supporting features, it turns out, aren?t readily available. Information about customers is almost certainly spread over a multitude of databases and applications. Programmers may be able to access it, but they will need time to understand the code and data structures of legacy applications, to create interfaces to legacy databases and to combine and match customer information from many different sources. Ultimately, the great majority of the 10 or 20 programmers in a team will focus not on creating a differentiating customer experience but rather on getting the basics right.

Moreover, the problems don?t disappear with less-sophisticated products. A prepaid calling plan, for example, might seem to be straightforward. But a team that's developing one will look in vain for readily available support functions such as customer information, credit checks and the ability to calculate the price of each call for billing purposes.

Building blocks
To begin constructing those support functions, mobile telecom companies should reorganize their information systems into reusable building blocks or components. Assembling and reassembling them into the basic elements of a mobile product then becomes a lot less time-consuming and costly.

In all industries, the first step in creating reusable IT components is to divide the maze of legacy systems into domains: broad categories of products and functions that have a business rationale for being managed as a unit.

Business executives, with their deep knowledge of a company?s current business processes and potential strategies--rather than IT managers--must take a leading role in organizing applications and databases into domains.

For mobile services, the natural starting point is their three main architectural elements: the product applications that generate revenue and differentiate a company from its competitors, the business systems that support the product and the network elements that make services mobile. Each of these three domains would contain smaller interrelated units--subdomains--comprising the actual applications, databases and network elements.

A provider?s product applications domain would bring together all of the different types of mobile products: "infotainment" applications such as mobile games; weather reports; a video stream from, say, the latest Jennifer Lopez concert or a soccer league final; messaging applications; and location-based products, such as the restaurant finder.

The domain would also include applications directly supporting mobile applications--for instance, gateways that send information and transform it from one mobile standard to another and content-management systems that package information into tiny chunks for mobile devices and deliver the content through mobile portals. Strategic-marketing people and product managers (who are responsible for developing products) and sales executives would have major stakes in developing and managing the mobile-services domain.

The business support domain?defined and managed by marketing, sales and finance managers--would provide crucial IT elements for mobile products, including software for functions such as billing, customer relationship management, subscriber management, provisioning and accounting and control.

Finally, the network domain would include radio-access technologies, core networks (circuit- or packet-switched), and signaling and network-management facilities. This domain would be highly complex given the intricate and ever-changing world of mobile-technology standards and networks as well as the high levels of reliability, availability and security that mobile networks demand. Accountability ought to rest with network executives who would be responsible for the technical side and with marketing executives who would ensure that the network was provided to customers at reasonable cost.

Making components reusable
Unscrambling and regrouping applications and databases into domains helps IT and business managers see which components of the architecture might be reusable. But before product developers gain access to these building blocks, another vital step must be taken: developing a set of simple software interfaces, which IT experts call "services" (not to be confused with mobile-service products), to connect the domains.

Services, which are essentially standardized interfaces, can be reused each time product development teams create new products for customers. Banks that streamlined their IT architecture have developed services for calculating a customer?s lifetime value and creating, modifying and archiving checking account data--services that can easily be reused to offer new products and develop new applications.

Mobile operators could reduce the time to market of a new product by 30 percent and cut the cost of integrating it into an existing system by 60 percent to 70 percent.

For mobile telecom companies, one service might be a miniapplication pulling together customer profiles--a processing component that would clearly be useful in many different products. (To serve as a foundation for subsequent products, this kind of service would be created in tandem with the first product that needed it.)

Such a miniapplication can be reused, because it is standardized, so business and IT people should join forces to analyze what data or features are needed to serve a broad range of mobile services. A miniapplication should also be simple in the sense of being coded in a programming language (for instance, Java) that application developers know well. Standardized services would be developed gradually to replace the many complex interfaces, often written in obscure code, which have been tailored for a great many individual applications.

Now, a service connects applications in different domains. Consider the way a restaurant finder might use a customer profile service. First, the request for an eating place would come in to the restaurant finder application. The application would identify the caller and input the subscriber?s name, which would be sent to customer- and customer-care billing systems.

Then the output--standardized customer-segmentation information used to tailor the list of recommended restaurants to the customer profile--would come back to the restaurant finder application. Creating a service, even if it must be done only once, is a highly complex job that involves programming access to a multitude of legacy systems. Programmers in subsequent product development projects can then reuse the customer- profile components by hooking up to the service.

Services that mobile telecom companies could build within the mobile-services domain might, for example, charge customers for online games (a reusable service, since it wouldn?t have to be created anew for each game launched), send out big volumes of automated text messages and reformat video streams or music so that one service could address a variety of mobile devices such as handsets and PDAs.

Standardized application services are just beginning to emerge in mobile telecommunications, but their value could grow rapidly. Application server software--a similar layer of reusable IT functions utilized in a multitude of enterprise applications (for instance, customer relationship management (CRM systems)--created a $2 billion market in only a few years.

Within the business support domain, services would resemble those found in large retail banks and logistics companies. Developers could reuse billing, call center and customer relationship services in new products and in efforts to target products to specific customers and customer segments.

As for the network domain, the problem is that the current interfaces to network functions are extremely complex, often requiring thousands of pages of explanation. These manuals are comprehensible to network engineers who need interfaces that offer broad functions--for instance, to set up and test a network. But product development teams interested only in the functions that matter for products find that the manuals take a lot of time to read and are hard to understand. Furthermore, different generations of network technologies have different interfaces.

A few mobile operators have started to create standardized, simplified network domain services that would be indifferent to particular mobile-access standards and could be understood and reused by application developers. Such services could, for example, find out whether the phones of mobile subscribers had been turned on and block network access for customers whose prepaid accounts had been drained.

An IT architecture with reusable components would permit a team developing a mobile product to scroll through a company?s database of services and to pick what it needed straight off the shelf or to tweak existing elements of the service. The team would thus be free to concentrate on developing the product?s features. This approach, we believe, will become common in mobile telecommunications over the next few years.

Judging by the results achieved in other industries, mobile operators could reduce the time to market of a new product by 30 percent and cut the cost of integrating it into an existing system by 60 percent to 70 percent. The operators would therefore improve their chances of creating successful mobile applications to put them on the road to renewed revenue growth and higher profits.

For more insight, go to the McKinsey Quarterly Web site.

Copyright © 1992-2003 McKinsey & Company, Inc.

Interested in more research studies like these? If so, free registration at The McKinsey Quarterly will offer you topical alerts, monthly newsletters, and access to selected full-text articles. For premium membership, which offers full access to the McKinsey Quarterly site and the print edition, click here.

Close
Drag
Autoplay: ON Autoplay: OFF