Vol. 9, No. 2 March, 2001 yyy ™ www.gilbane.com Published by: Bluebill Advisors, Inc. 763 Massachusetts Ave. Cambridge, MA 02139 USA Content, Computing, and Commerce – Technology & Trends (617) 497.9443 Fax (617) 497.5256 www.bluebilladvisors.com CHOOSING AN ARCHITECTURE FOR Editor: Frank Gilbane [email protected] (617) 497.9443 WIRELESS CONTENT DELIVERY Editors Emeriti: Tim Bray [email protected] In spite of the current economic climate, it would not be a good idea to put (604) 708.9592 all e-business-related IT development on the shelf. It is certainly prudent to David Weinberger [email protected] be more selective in project choices and scheduling, but reactive retrench- (617) 738.8323 ing to older ways of doing business is suicide. The current mantra of “multi- channel” needs to be interpreted as inclusive not reclusive. Yes, we need Associate Editors: Bill Trippe bricks and mortar and we need paper – we always have – but the web and [email protected] wireless are still where the opportunity for “discontinuous” growth is. (617) 497.9443 David R. Guenette [email protected] While there is no doubt that wireless is the channel, or channel category, (617) 868.6093 with the most strategic upside down the road, no one really knows what Contributors: business models, user interface designs, or even which combination of func- Mary Laplante tions will ultimately win. But whatever the future holds, you can be sure that [email protected] (412) 264.8432 your content management and delivery architecture will need to support Mike Maziarka wireless content – and now is the time to figure out what this means. [email protected] (781) 871.9000 All multi-channel architectures are difficult (which is why people talk a lot Production Assistant: Sarah G. Dionne about them but seldom implement them), and wireless adds even more [email protected] complexity. This month guest contributors Girish Altekar and Regan Cole- (617) 497.9443 man suggest a straightforward, clear, and useful way to approach decisions Subscriptions: surrounding architectures for wireless content. [email protected] (617) 497.9443 Customer Service: [email protected] CONTENTS Consulting Inquiries: Bill Trippe [email protected] Choosing an Architecture for Wireless Content Delivery ......................2 (617) 497.9443 Industry News ...................................................................................................................9 Events & subscriber discounts ............................................................................. 26 Back Issues ....................................................................................................................... 27 Subscription Form & Calendar............................................................................. 28 The Gilbane Report y1 March, 2001 CHOOSING AN ARCHITECTURE FOR WIRELESS CONTENT DELIVERY Not many people can predict the form the wireless web will take in the next two to three years. There are many uncertainties about the technology, the spectrum allocation, the standards that might prevail, the cost of building the infrastruc- ture and, not in the least, the user behavior. Nevertheless, just as today we can- not imagine our lives without cell phones, it is probably safe to assume that there will be a time when we will want to be connected to data in the same way. This makes it necessary for businesses to think clearly about managing content for use in the wired and wireless web. This article defines a framework on which to base this thinking. PROBLEM STATEMENT In this article, we attempt to answer the following central questions: “What ar- chitectural choices are available to us as we make decisions about managing wired and wireless content?” and “What strategies make sense and/or how do you get started?” To answer the question, we start by identifying the problem domain, the delivery of business content over the Internet. As shown in the diagram below, a firm produces static and/or dynamic content that it must deliver to its customer or consumer. In return, it receives revenues, either directly for the purchase of the content or indirectly through purchase of its goods and services. $ Static Co ntent Core Bus iness Content Dynamic Co ntent Next we distinguish between two kinds of businesses. The first set includes com- panies whose services are focused exclusively on the mobility offered by wireless devices such as PDAs and cell phones, and who, therefore, create content only for the wireless web. The second set includes those companies whose business value is in the content they produce and they need to deliver it to their custom- ers through all channels that make sense. Generally, this implies both the wired and the wireless web – making the content management problem more acute for these firms. This article is directed towards this second set of firms. The Gilbane Report y2 March, 2001 We suggest that the fundamental content management problem for these busi- nesses as it relates to the wireless web can be restated as the following. “Where do we build in device intelligence (transforming content to suit the user’s access device) in the web channel to our customers in order to a) maximize revenues, b) increase customer loyalty, c) add in maximum flexibility for current and future content development activities, and d) minimize the costs of current and future technology expenditures?” DEVICE INTELLIGENCE CHOICES The following diagram points out the various options associated with placing de- vice intelligence and the associated translation capabilities. App Server Web Server Repositories Static Content Core Bus iness Dynamic Co ntent 1 2 3 4 5 6 Where should it r eside? Device Intell igence The first option suggests that this problem is a user’s to manage – they know the content they want and can choose the device most appropriate for the purpose. The second option is to outsource this function to a service provider on the Internet – either the wireless carrier or another intermediary with the demon- strated capability of dealing with the complex translation problem. Alternately, the device intelligence could be placed between the Internet and the “real” web servers (#3), between the web server and the application servers (#4), between the application servers and the content repositories (#5) or the content itself be replicated based on the type of device accessing the content (#6). Let us now consider these architectural choices one at a time. 1. With the User For content companies, this is the do-nothing option that is based on the belief that users are smart enough to figure out whether or not their content is appropriate for their device. If it is not appropriate, then the users can switch to the appropriate device. This may be a reasonable ap- proach if your content is highly proprietary and has no substitutes. For The Gilbane Report y3 March, 2001 example, there are no choices for the readers of the Wall Street Journal Interactive editorial; the content dictates a PC only access1. Nevertheless, it may be prudent to at least think about the devices your customers are beginning to use, or might want to use, in the future. Plan for this even- tuality because even partial substitutes can lower switching costs if sig- nificant benefits are accrued in some other dimension. Not to mention that you might be missing out on another market segment that you never thought about. 2. With a Wireless Service Provider (WSP) There are a number of companies who are developing competencies in making your content available over the wireless. These range from the wireless carriers who wish to provide their subscribers one stop shopping by aggregating content from different providers, to numerous compa- nies that provide transformation capabilities, infrastructure and hosting services for an enterprise’s wireless web sites. This arrangement is in fact outsourcing of the device intelligence transformation function. It works because companies don’t have the capability in-house, content branding is not enormously important, and content can be transformed using simple static rules. It also allows companies to provide content in the wireless market without significant investment. 3. Between the Internet and the Web Server By this we mean placing the device intelligence in the wireless web server, which simply takes the HTML output of the company web server and transforms it into content suitable for viewing over a wireless device. This is different from the second option because the transformation ca- pabilities lie within your control. So even though the content still needs to be simple and capable of being transformed using fairly simple, static rules, the output, the devices, the brand management can be a bit more tightly controlled. 4. Between the Wireless Web Server and the Application Server In this configuration, the device intelligence capability is introduced be- tween the Wireless Web Server and the single application server that serves both the wired and the wireless web servers. This configuration al- lows a significant amount of flexibility in transforming the output with- out changing much of the content generation infrastructure. Assuming that the Application Server spits out XML, an XSLT application can trans- form the Application Server output to either HTML suitable for desktop interaction or WML for WAP enabled phones or other variants suitable for other devices. This architecture allows a nice balance between control over content and presentation, and interaction between