Business Scenario Document

Business Scenario: Syndication of Mapping Service

 

Version <1.0>

 

 

 

 


Revision History

Date

Version

Description

Author

17 February 17, 2002

1.0

Initial Draft

Gil Tayar

 

 

 

 

 

 

 

 

 

 

 

 

 


Table of Contents

1.       Syn       1

1.1     Description      1

2.       Participants          1

2.1     AllMaps      1

2.1.1         Role            1

2.1.2         Relationships            1

2.1.3         Business Objectives            1

2.1.4         Solution Requirements            2

2.2     MonsterCard      2

2.2.1         Role            2

2.2.2         Relationships            2

2.2.3         Business Objectives            2

2.2.4         Solution Requirements            3

3.       References 3


Business Scenario: Syndication of Mapping Service

1.                  Syndication of Mapping Service

1.1               Description

In an attempt to extend the reach of their mapping service, AllMaps (fictive company) is looking for ways in which to “free” their mapping service from their Web Site, and thus generate additional revenues from new channel possibilities. In this case, we will define AllMaps as the Producer of the service, and the channel sites as the Consumers of the service.

AllMaps already has business solutions that enable other sites to host AllMaps maps on their own sites. These solutions involve either linking to AllMaps, or directly linking to the AllMaps image. In both cases the search parameters are in the URL. AllMaps also enables Consumer to add markers of their own on AllMaps created sites.

AllMaps has invested person-years in the usability of their site, and finds that this investment does not manifest itself in the Consumer sites, as the functionality provided by AllMaps does not (except in the case of a link) include the UI functionality.

An example Consumer in this case would be MonsterCard (fictive company), a credit card company, which already consumes AllMaps’ service for location of MonsterCard ATMs. This “consumption” is done by adding an <img> tag linking to the correct AllMaps map. MonsterCard can even add markers to the map indicating all nearby ATMs, plus the ability to navigate (e.g. “North”, “South” buttons) and zoom in, zoom out. This navigational ability was provided by MonsterCard by using their own navigational buttons which link back to their site with the new parameters. What MonsterCard is missing is functionality like “Get Directions to this Location”, “Map Legend”, “Big Map”, “Add a Location”, and even “Aerial Photo” that is already available in the AllMaps site.

AllMaps would like to provide all these additional functionalities with their service in a way that is easy to use and which does not necessitate rewriting the UI on the Consumer side. AllMaps would probably want the UI features that are developed in the Producer Web Service to be added “transparently” to the Consumer site, e.g. if a new button is available in the AllMaps service, this new button – and its functionality – will be automatically available to all Consumers of the Web Service.

2.                  Participants

2.1               AllMaps

2.1.1          Role

In our scenario, AllMaps (AM) is the Producer.

The Web Service is a mapping service which enables the Consumer to host a UI that enables searching for a location around the world, viewing it, navigating/zooming around it, and providing a host of features such as “Ariel Photo”, “Driving Directions”, etc. The Web Service should also enable Consumer-defined markers in Consumer-defined coordinates on all the Web Service pages.

The current functionality available to the Consumer is just the mapping service, with no UI at all.

2.1.2          Relationships

MonsterCard is using the current minimal service AllMaps is providing, but wants to “upgrade” to the new Web Service.

2.1.3          Business Objectives

·         Sell the Mapping functionality as a Service, and not just as a consumer Web Site.

·         Enhance functionality and ease of integration to increase competitive advantage via other Mapping services.

2.1.4          Solution Requirements

§         Brand Control. The AM’s Logo must be properly presented and maintained throughout the Mapping Service UI.

§         Look and Feel. Consumers of the Web Service must be allowed to alter the look and feel of the application within constraints set by the AM’s marketing team.

§         Map Extensibility. The Consumer must be able to add “markers” in specific coordinates to each map image the Producer Web Service creates, even if the map was generated by users navigating elsewhere.

§         Cross-Personalization. Producer will probably have personalization options (e.g. ”Saved Maps”), and should be able to maintain them.

2.1.4.1     Technology Requirements

§         Producer Low Cost of Entry. Leverage the AM’s current code, UI, and skill assets.

§         Consumer Low Cost of Entry. The UI must be exported, and Consumers should not be required to rewrite the UI at their end.

§         Transparent Extensibility. The Producer must be able to change the UI without notifying the Consumer, except where integration points between the two are changed.

2.1.4.2     Usability

N/A

2.2               MonsterCard

2.2.1          Role

In our scenario, MonsterCard is the Consumer of the Web Service. It will be consumed as a helpful “ATM locator”. As such, MonsterCard should communicate the locations of the ATMs to AllMaps so that they will be viewed on the maps consumed by them.

2.2.2          Relationships

MonsterCard has no relationship to AllMaps except as they are current consumers of the minimal service AllMaps is providing, but want to “upgrade” to the new Web Service.

2.2.3          Business Objectives

Enhance a valuable service, already existing on their site, to their customers.

2.2.4          Solution Requirements

§         Low Cost of Entry. The Consumer should integrate the Web Service using existing standard technologies that it has – e.g. SOAP, HTTP – easily.

·         Ownership of End-User Relationship: User experience must always be perceived as one of MonsterCard. Related to look & feel as well as branding..

§         Cross-Personalization. Consumer will probably have personalization options (e.g. ”Your Account”), and should be able to maintain them.

2.2.4.1     Technology Requirements

§         Low Cost of Entry. MonsterCard would like not to create a whole infrastructure that sends ATM locations to AllMaps.

3.                  References

Real world example of a mapping service – MapQuest: http://www.mapquest.com/maps/main.adp.

Real world example of a Consumer of a “minimal” – MasterCard’s ATM Locator: http://www.mastercard.com/cardholderservices/atm.