The following terms govern use of the HunchLab system and responsibilities of the Client and Azavea, Inc. (Azavea).
The HunchLab application is hosted as a multi-tenant Software-as-a-Service (SaaS) application within the AWS infrastructure. Azavea will manage the hosting infrastructure, security updates, and 2nd tier support. This cloud-based approach enables HunchLab to leverage significant amounts of computing power in an elastic manner, a critical requirement for providing the advanced statistical algorithms the system employs. Replicating a similar environment on-premise would entail a substantial outlay of capital to provide servers that are utilized only in bursts. To provide a secure application, we have consulted the FBI’s CJIS guidelines to apply as many guidelines as possible in designing our system architecture, including risk mitigation techniques such as encrypting data connections and optional 2-factor authentication.
The application requires network connectivity from the user to the HunchLab service. Bandwidth requirements are modest, as most application assets are cached locally in the browser.
HunchLab 2.0 is hosted within the Amazon Web Services (AWS) infrastructure. AWS provides best-of-breed security and flexibility for building robust and secure SaaS applications.
HunchLab’s yearly subscription includes application hosting, updates (fixes and new functionality within the place-based module of HunchLab 2.0), 2nd tier support, and ongoing training resources. This pricing model allows unlimited users and devices to access the application. All support services are coordinated and provided from Azavea’s Philadelphia office and will include incident-based and troubleshooting support services by experienced Azavea staff through e-mail or phone during business hours, Monday to Friday, 9am – 5pm, EST (exclusive of designated US federal holidays). Additional support options outside of business hours are available for discussion as needed.
Azavea develops HunchLab through an agile Scrum methodology whereby work is planned in 2-week increments. This structure enables us to quickly develop iterative improvements to the application. New functionality and any necessary operating system updates or patches are deployed on a schedule designed to minimize downtime. For instance, most software updates result in about 0 – 15 minutes of downtime. System updates require no work from the Client as Azavea staff manages the deployment process. The application is hosted as a multi-tenant application, so an update by Azavea for the US hosting environment will update all organizations hosted within that environment simultaneously.
The Client is expected to continue to maintain modern, up-to-date web browsers on the devices that will be accessing the system. More information about our browser support policy is provided below.
HunchLab does not require the Client to have any particular database available. HunchLab does require event data (crimes or calls for service records) to already be geocoded with basic attribute data such as the date and time of the event (or time range), event classification, unique identifier, etc. More information about the data interface requirements is in section 4.
In a production environment, HunchLab will mirror authoritative data repositories, such as CAD and RMS systems. The manner in which this data is transferred to HunchLab varies from client to client. A typical process will consist of transferring records to HunchLab as an extension of existing crime mapping and analysis Extract, Transform, Load (ETL) processes. For example, this might be an extract process used to get data out of an RMS for crime mapping purposes.
Alternatively, Azavea can configure an upload process that draws data from an Open Database Connectivity (ODBC) connection to a read-only database view to fetch data that has changed since the last import was conducted. Most agencies schedule this import process on a daily or hourly basis, but HunchLab can also be configured to import changes on a more frequent basis such as every few minutes. Ideally data is provided for a 5-year historic period to allow robust predictive modeling.
Event data (crimes, calls for service, etc.) are transferred to HunchLab in a simple CSV format via a Representational State Transfer (or RESTful) HTTP Application Programming Interface (API) endpoint. A RESTful API is a framework that allows one to push and pull data to and from a system in a simple and secure manner. The Client can directly push data into this API endpoint or Azavea can support its use. CSV uploads contain column headers and basic attribute values such as the location and time of an event. Formatted CSV files can also be uploaded directly via the HunchLab administrative UI.
Alternatively, Azavea can fetch data from other RESTful APIs such as those provided by ArcGIS Server. If the endpoint is available via the Internet (with proper authentication), then no on premise utility needs to be configured as HunchLab can directly fetch updates. If the endpoint is behind a firewall, then the extraction process would be setup within the Client’s environment and push updates to the HunchLab server.
Staff access HunchLab through a web-browser. As an advanced web-application, HunchLab supports the following major desktop web-browsers and contemporary operating systems:
Note: Window Vista and older Windows operating systems do not support secure versions of the TLS protocol (1.2+) within Internet Explorer. To support these older versions of Windows, we recommend the use of Chrome or Firefox (both free for installation) on these machines since they do support these newer versions of TLS.
We also support the following major mobile browsers:
In all cases, the default HunchLab configuration requires operating systems and browsers that support Transport Layer Security version 1.2. This requirement is to prevent known attacks against SSL traffic that impact TLS v1.0 and older protocols. Our supported browsers provide the correct version of TLS either automatically or with minor configuration changes (such as checking a box within the settings panel). If an agency is unable to support TLS 1.2 connections, it may necessitate the creation of a separate access point to the HunchLab system, which can be discussed on a case-by-case basis.
For the Sidekick interface of HunchLab and the Dosage Tracker, we need access to the GPS location of the device. This information is accessed through the HTML5 geolocation API that is supported by all browsers listed above. Access to the GPS location on a specific device depends on the configuration of the device itself. For instance, nearly all tablets and smartphones with GPS chips provide access to location via this HTML5 API. Mobile data terminals may or may not have access to this feed depending on their specific configuration.
During the Term of the HunchLab subscription, Azavea shall make commercially reasonable efforts to maintain the operation and availability of the application to the Customer at least 99.9% of the time as measured over the course of a calendar month. This SLA level corresponds with approximately 44 minutes of unplanned downtime per month. Scheduled downtime will not be included in these calculations but generally will amount to less than 1 hour per month. If the application does not meet the SLA, the Customer may request Service Credit as described below. This SLA states the Customer’s sole and exclusive remedy for any failure by Azavea to provide the service.
The following definitions shall apply to the SLA:
|Monthly Uptime Percentage||Service Credit added to the end of the Service Term,|
at no charge to Customer
|< 99.9% and ≥ 95.0%||1 additional week added to the subscription|
|< 95.0%||2 additional weeks added to the subscription|
In order to receive any of the Service Credits described above, Customer must notify Azavea within thirty days from the time Customer becomes eligible to receive a Service Credit. Failure to comply with this requirement will forfeit Customer’s right to receive a Service Credit.
Service Credits may not be exchanged for, or converted to, monetary amounts.
Azavea shall maintain a monitoring service external to the data center housing the equipment supporting the application and shall monitor the service with reasonable frequency and duration.
Azavea shall provide at least 5 calendar days or more notice to the Project Contact and IT Contact if there is planned downtime. Tasks performed during planned downtime may include:
The SLA does not apply to unavailability or any performance issues:
Azavea may make commercially reasonable modifications to the Service, or particular components of the Service, from time to time. Azavea will use commercially reasonable efforts to notify Customer of such changes.
In the event of a suspected or confirmed security breach, Azavea will proactively notify the Project Contact and Security Contact (these roles are defined in the Implementation Narrative on page 17) of the breach in a timely manner as specified in CJIS v5.3 section 5.3.2.
Azavea shall use commercially reasonable efforts to provide the following support services for customers: