|
|
|
February 2004 |
Enabling mobile mapping
Several firms in the US are using traditional GIS client/server and desktop applications in a thin-client computing configuration to deploy customized solutions to geographically dispersed offices and field engineers. This enables delivery to a distributed workforce with centrally controlled software maintenance. Each time the GIS application is changed, update and redeployment is faster and less expensive. Moreover, IT managers are able to ensure license compliance from a single location. Spatial data are maintained using standard data validation routines to prevent conflicting or ‘unauthorized’ versions from being unintentionally posted to the master data set.
Evaluating An Asp Solution
There are many issues to consider when evaluating an ASP strategy. It is important to consider these issues when deciding whether to implement an internal ASP architecture or contract with an external vendor to deliver ASP solutions.
Service Level Agreements
The Service Level Agreement (SLA) is the basic contract between the consumer (business or individual) and the spatial ASP. This contract addresses typical contract issues as well as issues that are unique to ASPs. It is necessary to understand that, unless the ASP operates their own hosting center, they will have corresponding SLAs with their data center hosting partners and communications providers. The terms and conditions of those SLAs will be passed on to the end-consumer.
Several features are recommended in any SLA between a consumer and a spatial ASP. Perhaps the most important is the guaranteed network availability metric. This often is referred to as ‘up-time’ and can range from 98% to 99.999% availability. While ‘Five 9's’ (99.999% up-time) theoretically is possible, in practice this figure is defined more conservatively in most SLAs. It is important to recognize that this guarantee only refers to network availability, not to the availability of a particular application, because the spatial ASP has no control over the reliability of third-party applications they are hosting and delivering. Despite best efforts, application ‘bugs’ persist and will arise, often at inconvenient times, even in a spatial ASP.
Another unique feature in the SLA is the frequency, period and metrics for measuring the network up-time. Also included is a clearly stated, concise ‘credit policy’ for situations in which the network does go down (and it will go down). The consumer should know how and when a credit will be given, and how to resolve disputes.
While it is not the intention of the spatial ASP to create a crisis situation, the prudent consumer should confirm that the SLA contains appropriate language to address loss of ownership of any data, intellectual property or specialized applications in the event that the spatial ASP, or any related partner organisation, ceases to conduct business or otherwise ends the relationship with the consumer. This is an often-overlooked aspect of the SLA. To minimize such risks, the consumer should demand financial reporting and conduct due diligence on the spatial ASP before executing an agreement.
Other aspects of the SLA that should be explicit are the details concerning technical support and customer service provisions, upgrades of applications, networks and hardware, training, integration and customisation services. Some ASPs include these services in the solution offering, while others provide them at additional cost. We advise consumers to consider these points during the evaluation and comparison of SLAs.
Quality of Service
With respect to data integrity, loss and consistency, the SLA should contain specific details on how the spatial ASP will provide and ensure Quality of Service (QoS) for the contracted solution. This is a significant issue, especially for those spatial ASPs that intend to deliver their products and applications over the public domain Internet. The foundation for QoS is being able to minimize the delay in IP packet delivery, minimize variations in IP packet delays and provide capacity with consistent data throughput.
|
|
|
|
|
|
|
