APIs and Services for Fleet Management

The B2B Perspective

Connecting Vehicles Around the World Commercial Fleets Installed Base GPS Traces Density Plot (Sept 2013)

30 May 2014 @ToralfRichter :: tomtom.com/telematics 2

The WEBFLEET® Platform :: In a Nutshell TomTom Telematics Platform (Facts & Figures Q1 2014)

customers

28,000 >

hours driving

1.4 M >

10 M

liters fuel

>

60 M

km driving

>

425 M

positions

>

units online

350,000 >

composed of ~25 application deployables

the SaaS platform team are ~20 developers

runs 2 physically separate data centers, employing ~4 independent Internet uplinks, 2 independent power suppliers, and various, backup diesels and batteries

Service Mesh: linked to 15+ major mobile network carriers for communication with vehicles, integrated with various TomTom Group and external APIs

Technical Facts

30 May 2014 @ToralfRichter :: tomtom.com/telematics 3

Productized APIs and Interfaces Stretching the API Idea to Make Connected Vehicle Use Cases Possible

● the API projects the platform product ● mostly indirect monetization ● protocol flavors: pragmatic, query-

based ReSTish + SOAP 1.2 with MTOM ● public API for complete fleet platform

functionality ● resilient, carrier-grade ● free for developers ● mostly free to fleet customers

● projects the product + is the product ● indirect and direct monetization ● technical protocol: Bluetooth® SPP,

multiplexing over same channel ● in-vehicle black box interface for 3rd

party devices ● simple data sink / source ● free for developers ● requires fleet customer to sign-up

NOTE: Calling a Bluetooth® interface an API is what I mean with “stretch”. BUT WHY: In the connected vehicle space we are an aftermarket vendor. The combination of the vehicle side interface with the open web API really has created a lot of potential for developers. EXAMPLE: E.g. ready mix concrete viscosity monitoring (theft detection).

WEBFLEET.connect LINK.connect

Open Developer Eco-System :: Build any Operational Fleet Solution you Want

30 May 2014 @ToralfRichter :: tomtom.com/telematics 4

APIs as Tools and for Discovery Data Vortices for Business Development, Back-Office, and Platform Integration

Scouting New Markets (UBI.connect, OBD.connect)

• “Unified Fleet API”: an orchestration layer on the WEBFLEET.connect product creates the dedicated UBI.connect variety (API key based configuration)

• OBD.connect is a smart phone SDK to connect a OBD device to WEBFLEET

Experimental (Platform Connectors, Mash-Ups, …)

• e.g. outbound API for event based data synchronization to other platforms • closed developer / user group: API contract defined and circulated • e.g. TomTom myDrive Mash-Up using JavaScript SDK for UBI.connect and TomTom

LBS Platform

Back-Office Integration (CRM.connect)

• connect CRM and back-office systems of large partners (RMRs) to WEBFLEET® subscription and contract management

• SOAP seems to hit the nerve for this specific clientele • also used in consolidation of acquisitions (e.g. Coordina)

30 May 2014 @ToralfRichter :: tomtom.com/telematics 5

Before Take-Off :: API Management Checklist for a Safe Journey

“if it is released to GA, it is bound to stay” patience and a lot of outbound communication customers and partners ask for continuity

Life Cycle Management

give some control of behavior to developers free / reduced price try-out solution accept who they are - this is why we kept SOAP

Developer Appreciation we tried both (add versions, stay compatible) overhead + cost of many versions “compatible evolution” is the better strategy

Versioning / Compatibility transform certain “morphology aspects” generalize as much as possible and specialize as little as necessary Helps reuse

Orchestration Layer

stated fair use policy rate shaping and quota system sign terms & conditions app behavior, statistics

Platform Protection SSL (only) is a must IP white / black-listing time control on credentials credentials + API Key

Authentication + Security

30 May 2014 @ToralfRichter :: tomtom.com/telematics 6

Good Hope :: API Testing B2B is Long-term. Navigating the Seas of Backward Compatibility

Why: In enterprise / B2B APIs the backward compatibility aspect is really painstakingly important.

Business continuity of customers and software investments made by developers and customers depend on it. The expectation is “carrier-grade” or “tap-water” availability.

How: Full stack, close to production, multi stage automated integration testing. 1600 scenarios / test cases, nightly run 1:20 h – 1:50 h

Two test categories: Do, then compare to expectations, and do, then compare to same operation in another version or protocol flavor.

As we want to make sure that all compatibility guarantees are kept there is a strong focus on comparing to previous GA / production version. As we say the SOAP and ReST API flavors are functionally identical, we check this too.

Integration test scenarios are sometimes coarse, so we started to close the gaps with unit tests.

Why the focus on integration testing and on comparisons?

History: In the beginnings “specification“ was created by actual implementation.

Platform complexity: WEBFLEET® platform consist of many components that cooperate and can have influence on data and functionality as available in the API.

Future: It helps us to move the APIs closer towards Continuous Delivery

30 May 2014 @ToralfRichter :: tomtom.com/telematics 7

Heavy Duty :: Four Nines and Rising How it pays (AlertSite Benchmark comparison US25)

Availability: Rank 2 • 99.99% across all

APIs and services Roundtrip: Rank 2 • 1.1710 sec across all

APIs and services and all locations and carriers

AlertSite Monitoring Locations • Dallas (XO, Savvis) • Munich (Lambdanet) • Amsterdam (AMS-IX,

BNIX, DE-CIX) • Boston (Cogent,

AboveNet, Level3) • New York (Cable &

Wireless, Global Crossing, Peer1)

• Frankfurt (Sprint, Lambdanet, Interoute, DE-CIX)

• London (AboveNet, Level3, Global Crossing, Peer1)

30 May 2014 @ToralfRichter :: tomtom.com/telematics 8

In Retrospect :: Learnings and Experiences Good-Humored Hints for API Makers

“Generalize till it Hurts, Specialize till it Works”.

Accept API styles that are not pure ReST. Pragmatic, query-based and even SOAP are the better choice for certain cases.

Try to be wise about your life-cycle choices. Make a careful picks regarding “Versioning” vs. “Compatible Evolution”. Think thoroughly before releasing anything to GA. You will have to support it.

API Engineerîng

Accept “Emergent Strategy”. Up-front big design has proven many times it can fail too.

More than the fair share of Novelty Pains hit you if your product or service is relatively new and requires explanation about its general nature.

Be aware of the liability situation when sharing the same customer with your partners and developers.

API Strategy and Eco-System

30 May 2014 @ToralfRichter :: tomtom.com/telematics 10

Any questions?

TomTom Telematics :: tomtom.com/telematics Toralf Richter :: @ToralfRichter