At the previous post, I wrote a picture below to illustrate the architecture for consumer oriented services. Now let me explain each architectural elements as follows.


Propagation Architecture

The propagation architecture concerns the mechanisms by which users can share your service with others.

The number of users you can reach directly through conventional promotional activities is dwarfed by the tremendous number of users of social network sites, blogs, and other online communities that form the long tail of online activity. By providing services that are easy to share and embed, you can take advantage of the viral propagation channels that arise naturally within successful online communities.

Of course, just because a service is easy to share does not necessarily mean that users will share it. Users won’t propagate your service unless they are motivated to do so, because they find it personally compelling or believe others will benefit from it. User context is an important factor that determines how successful a consumer oriented service will be. User context, in the form of computer-readable metadata, can potentially connect like-minded people much more effectively than current mechanisms like comments and recommendations. It can make propagation much more natural without requiring a great deal more effort.

To be useful to the target audience, a service has to fit into users’ lifestyles. This includes providing content in manageable units, supplying community mechanisms along with the service, and taking the end-user experience into account.

The “delivery unit” of the service should be small enough to be easily manageable in a variety of contexts. For example, consider an episode of a popular television program made available as a service. An entire, unbroken 30- or 60-minute program might be unmanageable and inhibit user sharing. Providing key scenes lasting only a few minutes each, on the other hand, might be more likely to compel users to watch individual scenes through to the end, and to share them with friends.

Including mechanisms like tagging, recommendation, evaluation, and commenting can encourage the formation of communities and make it easier for users to find services that interest them. Social networking sites that allow the embedding of third-party services often have their own community mechanisms, of course, but that doesn’t preclude service providers from offering theirs.

Consumption Architecture

The consumption architecture determines how users access your service. In the current prevailing consumption model, users typically visit a Web site that offers the desired content or service, perhaps after locating it through the use of a search engine, and then consume it by viewing or interacting with it through the Web browser. While this is a reasonably useful and intuitive model, it has several deficiencies that the coming generation of consumer oriented services will be tailored to address.

Consumer oriented services should offer a rich user experience that is personalized, contextual, and interactive. The web page, accessed through a browser application on a desktop or laptop computer, remains the base unit of content and function on the Internet in the popular imagination, but that may not last much longer. Techniques like Ajax and DHTML threaten to render the static “page” metaphor obsolete, and the future will likely bring further convergence between the desktop and Web-based user experiences.

In the future, too, providers will continue to tailor their services to provide a rich user experience on a variety of alternative devices, including televisions, PDAs, mobile phones, video game consoles, and portable media players. The importance of such alternative devices is increasing as their popularity rises; many offer rich multimedia experiences, including sound and full-motion video. It may make sense to target users of these devices as well as users on the desktop, perhaps offering enhanced experiences that take advantage of the unique strengths of various alternative form factors.

With users moving effortlessly between house and car, between computer desk and living room, providing a seamless user experience is an important component of the so-called digital lifestyle. The user experience for your service across all targeted devices should be as consistent as the form factors will allow, with little or no customization or configuration required of the user. When possible, the service should be optimized to provide some subset of features in a disconnected state, with the transition between connected and disconnected states handled seamlessly by the software. If users can incorporate your services into different aspects of their lives in a minimally intrusive way, they are more likely to only to use your service more frequently, but also to share it with others.

Composition Architecture and Federation

The composition architecture enables your service to integrate with other Web sites, platforms, or devices. The composition architecture can be said to have three tiers, representing users, providers, and intermediaries (aggregators).

User Tier: Mashups

As the Web moves from a universe of static, monolithic pages to one of dynamic, modular components, one of the more notable and innovative trends in Web site design has been the emergence of sites that combine custom code with services from one or more external, independent providers in a seamless, integrated interface that provides access to many different functions, regardless of origin.

Compared to business-to-business (B2B) interfaces, which can be very complicated and strict in order to facilitate the seamless integration of large systems, business-to-consumer (B2C) Web services tend to be structured more casually. At the heart of the consumer oriented service ideal is the notion that the service provider supplies all the tools necessary for other parties to consume and integrate a service. In the tradition of the Internet, services are provided using open, published interfaces to which any authorized consumer may connect, and (aside from possibly creating accounts or usage tracking identifiers) the provider does not need to add components to its own infrastructure to accommodate individual consumers. This casual integration can be accomplished using a number of different techniques.

One way to provide such services is through ordinary HTML techniques that use the markup language’s hyperlinking and object embedding features to provide content and behavior from external sites within a Web page. This can be as simple as a static graphic that shows current weather conditions at a particular location, or it can return custom information and function through Representational State Transfer (REST) techniques. For example, several popular social bookmarking services provide graphics and code that providers can include in their pages to allow users to submit content easily to the services. It’s not uncommon to see a row of icons at the bottom of blog posts and news stories encouraging users to submit them for discussion at several different community sites.


For more elaborate functionality, providers often expose content and functions for consumption using XML-based web service protocols like XML-RPC and SOAP, as well as non-XML serialization formats like JavaScript Object Notation (JSON). Objects exposed using these techniques can be made available to server-side code on the target systems and used to integrate content and functions from a number of different sources tightly into a single Web page.

Providers commonly offer data and methods together as web APIs, which can be implemented in a number of different ways. This has led to the emergence of the mashup as an easy, lightweight mechanism by which even amateur Web developers can combine services in innovative ways. Mashup creation has proven popular with commercial sites and hobbyists alike. Map services are popular with today’s mashup makers, as are services that allow people to share media like photos and videos. As providers implement web APIs and other mashup tools more widely and they become more accepted, expect to see business data offered for integration, as well as additional lifestyle features like shopping. Ideally, information exposed by these services will be semantically meaningful through metadata, so that it can be included in integrated search results.

Intermediate Tier: Aggregation

An intermediate tier aggregates services from multiple providers, rather than providing services of its own. The proliferation of services provides an opportunity for aggregators specializing in particular subjects or subject areas to arise. For example, an aggregator specializing in marine biology might offer access to a comprehensive selection of marine biology-related content from different providers: video clips, photographs, book excerpts and articles, and so on. We can expect to see vertically-oriented aggregators emerge soon as a major service category.

Provider Tier: Federation

In addition to the benefits explained under “Choosing Platforms,” above, relying on major platforms can make it easier to federate with other providers. By federating with other service providers, you can offer users more information than you’re able to supply on your own. If you provide a service that offers information about restaurants in a metropolitan area, for example, you’re unlikely also to specialize in logistical information like driving directions or mass transit information. By federating with providers that do offer this specialized information, you can offer a service that combines these two kinds of information in an integrated whole that is uniquely capable of capturing the user’s interest and curiosity.

Federation also makes it possible to integrate multiple services that each rely on user authentication. Ordinarily, users must authenticate to different services individually, which can be difficult or impossible. Federation makes it possible to give users single sign-on access to a number of different services from different providers, each of which can track and log the user’s activity as appropriate for that service.

In addition to user ID information, you can federate data and functionality. This makes it possible to offer a service that incorporates functions like e-mail and chat to encourage users of the service to conduct active conversations, reinforcing the idea of community.

Delivery Architecture

The delivery architecture defines how your service is deployed and how users access it, including hosting arrangements, the targeted end-user experience, and the nature of the service itself.

Consider the nature of a consumer oriented service: Its purpose is to provide access to information, functionality, or both to multiple end users in a contextual manner. Depending on its nature, it’s required to capture user’s intent and provide services in a manner appropriate to that intent. There are a number of ways to capture user’s intent. I will show you some of them in upcoming posts.

Besides, the end-user experience encompasses things like users’ available bandwidth, the devices they use to access your service, and their geographic location. If you have or anticipate a large number of users with wireless-enabled PDAs, for example, you might consider offering a smart-client interface to your service that’s tailored to the handheld form factor and includes offline functionality to make the service usable as the user passes in and out of wireless range.

Programming Architecture

By providing developers with a public API, you can create a “hackable” platform developers can use to modify and enhance the underlying service in a number of ways. APIs are a popular way to provide developers with a programming interface for lightweight, dynamic languages.By giving external developers the ability to enhance some features of your service, you give the service itself the power to evolve over time.This phenomenon is in evidence at a number of major SNS and portal sites.

Core Service Architecture

Consider your needs in the following areas related to core service:

·         Consider how your content can be optimally indexed for conceptual requests.

·         Consider how your content can be optimally indexed for specific communities.

·         Determine your schema for both provider-generated and user-generated metadata.

·         How will you identify your users? Consider the user attributes you’ll want to store: ID, preferences, account data, and so on.

·         Consider any provisions you’ll need to make for user groups. Think about the relationships among the elements listed above, as well as others, and address them as necessary.

Management Architecture

As with any large-scale public Web application, the management architecture provides a centralized mechanism for performing administrative tasks. In addition to general administration, consider your needs in the following areas:

·         Self-service configuration by users.

·         Self-service configuration by communities.

·         Integration with hosting providers.

·         Integration with federated service providers.