APIs and Services for Fleet Management - Talks given @ APIDays Berlin and Barcelona
1 like1,713 views
The document provides an overview of TomTom's telematics platform for fleet management, highlighting its extensive API capabilities and integration with various mobile carriers. It details the platform's features, including data management, compatibility, and performance metrics, emphasizing the importance of API stability and backward compatibility in a B2B context. Additionally, it discusses strategies for effective API management and testing to ensure high availability and reliability for customers.
APIs and Services for Fleet Management - Talks given @ APIDays Berlin and Barcelona
- 1. APIs and Services for Fleet Management The B2B Perspective
- 2. Connecting Vehicles Around the World Commercial Fleets Installed Base GPS Traces Density Plot (Sept 2013) 30 May 2014 @ToralfRichter :: tomtom.com/telematics2
- 3. 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/telematics3
- 4. 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/telematics4
- 5. 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/telematics5
- 6. 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/telematics6
- 7. 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/telematics7
- 8. 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/telematics8
- 9. 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/telematics10
- 10. Any questions? TomTom Telematics :: tomtom.com/telematics Toralf Richter :: @ToralfRichter