Project 2 Output: The Multi-Access Portal

Third of a series of posts from an unpublished book chapter written in 2002

An architecture for user-centric web services across multiple devices

The Innovation Platform concept was an idea ahead of its time. The web services model was in its early days, and specifications still needed to be finalised. Despite that, just six months later, it was looking as though it was now possible to implement an Innovation Platform of some form, as the World Wide Consortium and other bodies had forged ahead on the development of XML technologies. SOAP, the Simple Object Access Protocol, and its companion WSDL (the Web Services Description Language) were now public standards. The client’s requirements, and current business mode; were analysed and a proposal for work produced. Initial discussions with the client resulted in the decision to begin work on designing a Multi-Access Portal. Using learning from the continuing work on the Innovation Platform, the Multi-Access Portal was intended to offer a means of linking services to consumers across multiple delivery channels, while providing the ability to develop a revenue stream in conjunction with third party service providers. The project took the Multi-Access Portal from an initial sketch to a set of working prototypes that delivered content to a range of devices, including wireless connected PDAs and WAP phones.

Ethnography

In any user centric design process, it is critical to understand the end user. In a project in another country, with a different language and with different cultural norms, it’s even more important to gain a deep understanding – if only to avoid falling into cultural traps. A key task for a user research team is an ethnographic study. While market data was widely available, this needed to be translated into real world activities. The team had to go out into the field and watch consumers. How did they use their mobile devices? What did they think of brands? Where did they spend their time? How did they bank? Observational data also needed to be supplemented with interviews and with focus groups. Meanwhile market studies can be used to develop a picture of the target market segments. Spending patterns can be used to flesh out these segments, and to gain an understanding of possible revenue streams and prospective services. When user research is combined with market studies, an accurate picture of end user groups can be drawn. This can allow key user needs to be captured, and selected for initial application scoping. Needs can be as simple as wanting to keep in touch with friends, and as complex as wanting to understand and manage a specific financial transaction.

Scenario development

With the target market segments and their key needs documented and agreed, the next step was to develop a set of scenarios. User profiles would be drawn up, and fictional characters created to fit these profiles. Each character would then be faced with a need defined during the user research, and a scenario drawn up showing how they would interact with a MAP while fulfilling that need. These could then be refined in the light of the available technologies. As 3G device capabilities remained unknown, some of the work had to remain speculative. Some scenarios were developed in the form of animations, in order to present a vision of the proposed service. These could sketch out user interface designs, while allowing interactions to be demonstrated. One of these scenarios showed a user researching and booking a holiday. Initially making a query on a desktop PC logged into the MAP, results and alerts were delivered throughout the day to his mobile device. More detailed information could be explored through a wireless PDA and an office PC used to put together a package that could then be shown to the whole family on an interactive TV system. Finally roaming mobile devices could be used to access location-based information when at the destination. Another involved a couple making a decision about a second mortgage. They were able to use a range of devices to communicate with their bank and financial advisers. A financial transaction could be started on one device, and confirmed on another, and information passed from one personal account to another. These scenarios showed several features of the proposed MAP. These included the use of third party services, workflow-based long transactions, and multiple device outputs. They also introduced one of the key problems for mobile application development: context. Context is a critical issue for application designers and for end users, and one often ignored. There is little or no point in duplicating web applications for mobile users, a lesson that can be learnt from the failure of WAP portals and sites. By understanding the interaction context – device, time, and location – an application can determine the appropriate user interface or content to deliver to an end user. While it remains extremely difficult to determine the exact interaction context remotely, existing personalisation and customisation techniques and technologies can be used to offer something that approximates to a context sensitive service.

Candidate architectures

Once a set of usage scenarios was complete, the technology team was able to start work on developing a technology strategy for the client. Instead of jumping into high level design, the approach chosen was to develop a set of candidate architectures that could be used as “straw men”, and tested against the requirements of the scenarios. This led to the development of two candidate architectures, one targeted at a content-based service, the other at an application-based service.

CMS and Application server architecture

One of the two candidate approaches to a MAP architecture treats a MAP as a primarily a content-based service. This entails using a content management system as the core of the service, handling multi-channel and multi-device output through an application server. In this architectural approach, a content management system is used to manage content assets, with an application server taking those assets, and formatting them appropriately, delivering device-targeted content. The application server also allows the MAP to include business logic in any service delivery components, integrating content and applications. It’s possible to use the CMS can be used to manage application components as well as content. UI for applications will be handled using familiar techniques, based around templates that tailor content for selected target devices. It’s important for operators using this architecture to regularly monitor server logs for requests from unknown devices and to then develop templates and application components to tailor content for these devices. The use of commercial application servers and content management tools will allow rapid roll out, with minimal systems integration. Applications will need to be developed as required, and scalability can be provided using well known procedures. By using a CMS solution, content can be generated by the MAP operator and its partners, and delivered into the CMS workflow process before being delivered to end users. One issue with a content driven approach is that there is reduced scope for user interactivity with MAP services, with its users acting as information consumers. Applications delivered over this service are likely to be limited to request and response services, with some alert functionality. A CMS solution does reduce development risk, as it is possible to implement it by customising off-the-shelf products, reducing initial time to market at the expense of increased development time for future applications and services. It should be noted that multi-channel delivery tools are being built into the latest generation of content management products.

Benefits.

• Traditional n-tier web architecture.
• Can be put together using existing products.
• Reduced time to market for initial launch.
• Content can be delivered using existing channels and procedures.
• Content assets and code are kept separate.
• Use of separate application and web servers adds to scalability and reliability.

Risks.

• Users become information consumers, not active application users.
• Applications will need to be one-off developments.
• Little prospect of code reuse.
• Increased time to market for new application development.
• Not all content management architectures support multi-channel delivery.
• Architecture does not support context-based applications – separate applications will be required for each possible delivery channel.

Web services architecture

The second architectural approach was to consider a MAP as a host platform for a collection of interactive applications, hosted in an application management framework. Open standards are a key technology driver, and so application components should be implemented as web services. In this architecture the MAP is used to provide a framework of tools and services that can be used to deliver applications to target devices. As well as offering core services, it will host applications that can be developed internally, or by third parties and partners. By using a web services approach for application design and development, these applications will be composed of software components that can take advantage of other components in the framework. The core toolset is likely to contain some content management features, in order to manage and deliver content to client devices. However, application workflow and delivery templates can be separated from the web services components, easing application development and reducing time to market for the introduction of new services and applications. By using this application management approach interfaces and functionality can be tailored to the user’s context (e.g. working at PC, using a mobile device, watching interactive TV) without requiring separate applications for each context. This will give network and portal operators the opportunity to deliver appropriate services to specific devices – and with appropriate templates even within a specific device family, so that different variants of device browsers can be supported. The template approach used will allow the user experience to be managed separately from application components. An application management platform will allow design and UI standards for multiple devices to be enforced by the application framework, separating UI from both application components and workflow. Service components can be updated or changed without affecting design, and vice versa. The application framework used by a MAP can be delivered through a collection of web service APIs, which allow services to communicate through a loosely coupled messaging architecture. This will allow a MAP to be deployed across a number of server platforms, and to take advantage of developing XML-based enterprise application integration approaches to increase integration with partner services and applications. By using open standards such as WSDL (Web Service Description Language) and UDDI (Universal Description, Discovery and Integration) to publicly advertise APIs and UI standards, an application MAP can attract third party developers, and allow rapid development and roll out of new services in response to user demand. This approach will require logging and monitoring of service usage in order to examine user habits and actions. While offering an environment that meets the needs of a mobile service operator, the application management approach to a MAP will require significant development effort. There is a possibility that web service frameworks from Microsoft, IBM and the like will reduce this risk, but it must be kept in mind when planning implementation.

Benefits.

• EAI messaging architecture.
• Can be put together using a mix of existing products and bespoke development.
• Applications and services can be developed in-house and with third parties.
• Application workflow, display assets and service components are kept separate.
• Use of distributed application architecture increases reliability and scalability.
• Component-based services model increases code reusability.

Risks.

• An application management system will be a significant investment - both in terms of time and funds.
• Loosely coupled messaging architectures are slower than tightly coupled n-tier systems.
• Requires significant new build of integration components and systems.
• Separation of workflow and application components can lead to inconsistencies if interfaces and APIs are not well defined.

The MAP as a web services platform for mobile users

By choosing an XML-based web services approach to the development of a MAP, an operator can approach service delivery in a very different manner from traditional portals. Instead of focusing purely on acting as an information provider, an operator can base their delivery model on applications, and their business model on the additional revenue streams that can be realised from these applications. Revenue can come from various routes. Some core services can be sold to third-party developers, an operator can take a percentage of every transaction carried out over their system, and users can subscribe to premium services. In practice, a MAP is likely to be used by a network operator to increase ARPU, and services will be targeted to either deliver transactional revenue, or to drive additional voice traffic. Developing a web services platform also means that an operator isn’t reliant on its own development staff. Instead, a Darwinian approach will allow third-parties to develop new services that may or may not survive in the market. Usage monitoring will allow a platform operator to determine the successful services, and to promote services that it sees as important. If a service isn’t successful, the architecture will allow it to be quickly removed and replaced with either a new version, or a completely different service.

Application design issues

The development of a web services based MAP raises several new issues for developers. While the web services model itself is now well understood (in the shape of Microsoft’s .NET platform, and the work done by IBM and others), some of the issues with integrating a distributed component architecture still need some thought. This include the question of how to develop applications that separate display from workflow from business logic, and that need to be both able to deal with user interaction context and long “transactions”. An early requirement will be the development of an XML-based workflow grammar. This will allow developers to describe the application workflow, and to define how component inputs and outputs will be managed. A key design decision will be the choice of core web services. These will need to be provided by the service platform, and run by the operator. While some will be stand alone services that will be used to boot-strap third-party developments, others will need to expose elements of the operator’s network infrastructure. These elements could include billing and location services. A possible list of core services is shown in the following table:

Registration	A Registration service will be required to take a user’s personal details and store them for future reference; it will also need to record users’ usernames and passwords, and their service preferences. The Registration service should be available any time a user accesses the portal or any of its component services.
User database	This service will offer access to a relational store that will be used to store user information and to manage basic account information. This service will only handle user details and logon-on information – e.g. address, billing address, account name, user screen names, and service passwords.
Login and single sign-on	The sign-on service will define tools that can be used to handle user authentication as well as offering authorisation services that can be used by external service components. This service will offer a well documented API for use by third party applications, in order to give portal users a seamless online experience. In practice it may be possible to use a third party service like Microsoft’s Passport or the rival Liberty Alliance solution.
User preference storage	This service will be used to store and handle user preferences. By offering a central service it will make it easier to manage changes, and to distribute them to all relevant systems. While third-party service will be able to hold their own user preferences, this service will act as the master copy of the user data.
User customisation details storage	In order to deliver an appropriate customer experience, there will be a need to allow service customisation. This will allow users to pick and choose which service elements are displayed. Using this service, applications will be able to give users the tools to fine-tune their online experiences – reducing the need for complex personalisation systems.
Personalisation	For more complex applications, there will need to be some form of personalisation. This is intended to monitor the habits and behaviours of its users in order to dynamically control the content delivered by the service. Using the personalisation service, application developers will be able to track user actions, and to tailor future responses appropriately. This will require the use of a storage service. As any mobile service will be device orientated, there will need to be a means of indicating that a guest is using the service in the guise of a registered user, or that the user is operating the service for a friend. This can then be used to avoid creating false positives in the tracking and personalisation system.
Legacy system API	Mobile operators will have existing service components they will want to offer as services to their users and to application developers. This will require the development of web service APIs to wrap these existing applications and components. These legacy components are likely to be in the form of applications or data storage, such as geographical information systems. Existing enterprise application integration techniques can be used to ensure continuity of service in the event of changes to the legacy architecture and applications.
Multi-channel UI formatting	As the role of a MAP is to handle UI for an aggregation of web services, it will need to contain private components that will deliver information directly to devices. This services platform will contain tools that will handle multiple templates for multi-channel delivery. A key feature will be a central identification service that will be used to identify devices based on the browser signature. This will require a regularly updated database of browser signatures for all supported devices, along with a mechanism for recording the signatures of un-identified browsers, in order to allow design and development of appropriate templates.
Information storage	Like any online service, a MAP will need to store information, in order to manage persistence information for applications, or to store content that will be delivered to its users. A well-designed storage architecture will be a critical component of the service, and will need to be designed to use a common storage model for all applications. On option is to make sure that all information will be tagged with XML descriptors to provide effective metadata, and also to ensure that XML Schema are in lace that define all XML documents used on the service. An appropriate web services interface should be designed to give applications managed access to this storage. In practice it’s likely that multiple storage systems will be implemented, in order to provide the most appropriate storage for applications and service components. Any storage system used will need to comply with the service architectural principles and API standards.
Syndication API	There may be a requirement for a MAP to share content with partners and other portals on a revenue basis. This will require the development of a core service that will allow content to be shared to authenticated and authorised services. If the syndication system is to be billed on a per-bit basis, there will need to be tracking of all downloaded files, and possibly the implementation of a digital rights management solution where multimedia content is being used.
3rdparty information delivery/editing	Third party content will need to be delivered to any content management system used to manage MAP content. In order to operate this function a service will be needed that will give third parties access to the CMS, and to allow content partners to be included in the CMS workflow. This functionality will need to be considered in the choice of any CMS tool or solution. All alternative option will to be to expose CMS functionality through a partner extranet. Security will need to be a key consideration here, as any exposure of editing functionality to partners will increase the risk of intrusion or content subversion. Such an approach would also reduce the ability to automate publishing processes. All content submitted to the service by partners and information providers will need to be in a specified format. This is likely to be in XML documents, defined by an XML Schema in such a manner as to allow automated content processing services to parse documents and store them appropriately.
Transactional payment system	A MAP service will require a complex payment system capable of dealing with multiple payment methods: among them direct phone billing, service account billing, and credit card payments. The payment engine will need to link to user profile information in a secure fashion in order to determine payment preferences and offer appropriate choices depending on the application context. An appropriate web service will expose this functionality to applications. Before developing a transactional payment system, decisions on the accepted payment methods and associated APIs will need to be taken.
Location service API	As MAP applications may not necessarily be offered by a network provider, location information for any location dependent service will need to be provided by to application by a location service. By working with information stored in user profiles a location API will allow applications to either take information from handset GPS systems, network location systems, or user input. This standard interface should be made available to all applications, and included in template definitions for location-based applications and functions.
Advertising engine	A possible revenue generating function of a MAP will be to deliver targeted and appropriate advertising to its users. There will be a requirement for any advertising system to use personalisation information and user preferences to determine appropriate advertising content. Location services may also offer a method of targeting adverts for mobile users. If relationships with other network operators are developed this engine may be required to deliver content to network subscribers who are not service subscribers.
Billing system API	As a MAP is intended to be a transactional system, with the ability to charge users for content and services and goods, there will be a need for some form of billing system for account customers. This type of functionality could also form the basis of any micro-payment solutions. An API or a series of APIs will be required, in order to allow applications access to the service billing solution, as well as from the service to partner billing solutions – especially if services are being offered to users of external 3G networks on a negotiated basis with the network operators.

Prototyping to enhance user experiences

A key development approach for a MAP is the use of agile development methodologies (such as eXtreme Programming). These are suitable for component architectures, as they concentrate on testing and on regular delivery cycles. This approach can be linked with regular prototypes, in order to allow user testing for interfaces. One possible prototyping environment is built around wireless PDAs, using 802.11b connections. These can be throttled to give an appropriate connectivity experience, and can then be used to trial UI designs. An interesting early finding from this project was that users were far more inclined to use fingers on touch screens than styluses. Early UI designs with small stylus buttons were then reworked to be “finger-friendly”. One useful feature of the 802.11b prototype was its portability – a UI prototype could be served from a laptop running a local web server, with wireless connectivity to Compaq iPAQs. This meant that impromptu demonstrations could be given anywhere, without relying on network connectivity or software device simulators.