A web services based approach to customer-centric mobile portal architectures

First of a series of posts from an unpublished book chapter written in 2002 Introduction: what are web services and project overviews This chapter looks at work done during 2000 and 2001 on defining an architectural approach that would enable network operators and third-party service providers to use a standard platform for the development, delivery and management of services for use with 2.5G and 3G mobile devices. Three projects are covered, one for a Far Eastern GSM operator, one for a European portal company and one for a European GSM operator. The work done with these clients led to the development of a web services based architectural approach intended to enable organizations rapidly roll out and evaluate customer-centric services. Web services are a relatively recent innovation, one that has come from the extension of XML-based enterprise application integration techniques to both distributed application development and component software. With EAI, we can use Internet technologies to link disparate applications across a global organisation – even between organisations involved in a formal business-to-business partnership. Tools like Microsoft’s BizTalk, and iPlanet’s Integration Server (based on the industry-proven Forte Fusion/Conductor combination) can be used to link applications through a corporate integration server, often based on a messaging framework to pass information between applications. A key technology in EAI is XML. The eXtensible Mark-up Language has been designed to allow application and OS independent exchange of information. By using XML to create application specific documents, containing inputs and outputs, information can be exchanged asynchronously – though near synchronous behaviour can be achieved. Businesses and applications wishing to exchange information via XML must develop a common business language that can be implemented as XML tags. Message bus tools like IBM’s MQ Series can be used to deliver these messages, handling connections and communications protocols. Microsoft’s EAI solution, BizTalk is an example of an XML-enabled message bus. XML messages are routed through a BizTalk server, delivering information to applications. A workflow design tool is used to orchestrate these messages, allowing the creation of business-centric translation rules. Translation services are an important feature of EAI solutions, as they allow messages from one organisation to be delivered to systems in another, by using an agreed “business grammar” to define message formats and content. Recent work by the World Wide Web Consortium has extended XML considerably, increasing its suitability for use in EAI. The recent ratification of XML Schema has given developers a key tool for creating complex XML data exchanges. Instead of merely describing the structure of a document, like an XML DTD, an XML Schema is a powerful means of describing a document’s content – by allowing tag descriptions to both define and prescribe the data they will contain. XML has also given us another piece of the web services jigsaw puzzle with SOAP, the Simple Object Access Protocol. SOAP allows us to offer a subset of the traditional RPC functionality. SOAP allows developers to expose object methods and parameters through XML interfaces. Short XML messages transmitted over HTTP (as well as HTTPS and SMTP) can be used to deliver calls to a SOAP object, with other XML messages returning the results. This is an important technology, as it allows a COM Windows application to consume objects in J2EE application servers. Extensions such as to SOAP such as DIME (Direct Internet Message Encapsulation) allow a SOAP message to contain binary data without requiring encoding. Web services need technologies like SOAP and its associated Web Services Description Language (WSDL), as these allow development environments to access information about available functions. A web services aware IDE should be able to treat a remote service as a software component that can be used in your applications – and manage the syntax of your calls appropriately. At a higher level UDDI (the Repository for Universal Description, Discovery and Integration) acts as a tool for advertising WSDL service descriptions. Putting together XML Schema, SOAP, WSDL and UDDI gives us everything we need to implement web services. Instead of organisations offering full featured web applications, they will be able to deliver appropriate functionality to users, charging per use or on a subscription basis. As web services will be true software components, developers will be able to update and improve the services they offer, and as long as they do not change interfaces, users (both applications and end users) won’t know any that there’s been any change. Web services are an attractive technology, and one suited for use in the mobile world, where customers are attracted to the best deal and where service providers are still learning what appropriate services for 2.5 and 3G subscribers will be. Project 1: Far Eastern GSM operator The first project involved working with a Far Eastern GSM operator to determine its approach to delivering services over its proposed 2.5G network. The operator was already linking IVRS, WAP and web services, and but needed to find an approach that would reduce its time to market for new services, as well as giving it the flexibility to deliver content to the next generation of devices, as well as wireless connected PDAs. Project 2: European ISP and Portal operator This project involved working with a European ISP and Portal operator. Owned by a national wireline telecoms provider, the ISP wanted to extend its existing portal service, with the aim of supporting a sister company’s 3G operations. The existing portal was offering some WAP services, but was mainly targeted at PC users, and the ISPs own dial-up customers. Project 3: European GSM operator This project involved working with a European GSM operator; that was looking to roll out further services around the world. In order to support these new operations, which would also extend its existing range of services; it needed to develop a management platform that would be suitable for use with its own service operations team, and with partners around the world. User research and user experience defining projects and solutions Any customer-focused service, whether it’s on the web or delivered through mobile devices, needs to be focused on the needs of the end user. Too many projects have failed and services scrapped because they have been technology or business led, delivering what an organisation thought the users needed, rather than what they actually needed and wanted. As a result, mobile service development needs to start with user research. While market research and business plans are still important, any results need to be validated with a sample of users. Techniques used will include ethnography, surveys, focus groups and user interviews. User research isn’t just for the early phases of a project. At every step through the project results and outputs need to be checked against user response. This is especially important during the development phases. Regular prototypes of applications and services need to be tested – even if they are just wire frames or user interface mock-ups. Dealing with customer churn and changing markets
Early mobile telecommunications markets were biased towards the operator, locking consumers into long term contracts and inflexible numbering schemes. The implementation of consumer-centric regulatory schemes put an end to these practices, and instead introduced more flexible contract terms, as well as consumer friendly schemes such as number portability. In the first client’s home market this process, along with the arrival of “pay-as-you-go” services lead to massive churn, and heavy price competition. This had resulted in low costs for voice calls, and an emphasis on value added services as a differentiator between operators. There was also a strong emphasis on brand values and brand identification, with the client focussing strongly on the young adult market. One interesting side effect of the regulatory environment was the development of a saturated market, with 60% plus device penetration. The second client’s market was younger, but had a much higher reliance on “pay as you go” customers. Mobile handsets were available from virtually any corner shop, in bubble wrapped packaging. Whichever company brought out the latest model phones would quickly find their packages at the top of the sales charts. A recently privatised incumbent national telco was finding its feet in a newly competitive market, and it was beginning to take advantage of its broadband assets and ownership of the main cable TV operator. In both these cases there was a strong need for a solution that would allow the operator to react to rapid changes in the market. This need was made even more critical, as the changes were likely to be customer led – and maintaining customer bases would be important to future revenue streams.