Mobile Sync Cloud Alejandro M. Ramallo - Group Head of Technology, BAT Phil Shotton - Cloudscape.

Mobile Sync Cloud

Alejandro M. Ramallo - Group Head of Technology, BAT

Phil Shotton - Cloudscape

2

Background

• The MARTINI Project is a global initiative to provide a flexible, extensible TM&D system

• A System-of-systems (SOA) aimed at replacing the existing regional/local solutions.

• More than 10,000 Sales Reps worldwide will use hand-held devices (Smart-phones, PDAs etc) to manage sales fulfilment and order delivery functions

• The hand-held will run a bespoke application accessing a local database holding an extract from the BAT backend’s master database

3

Objectives

• Robust, resilient synchronisation capability

• Full database load

• Bi-directional delta synchronisation

• Background scheduling of data retrieval and synchronisation

• Field-level delta updates to minimise network bandwidth requirements and backend system load

4

Requirements

• Provide bi-directional, asynchronous, delta synchronisation

• Conflict resolution at field level

• Minimise mobile connect time

• Plug-in architecture, extensible

• Scalability

• Performance

• Hub-and-spoke capabilities

5

Scale

• 2,500,000 outlets visited every week more than once ~ 4 million visits

• 10,000 Sales Reps * 77 Mb per user = 752 Gb

6

Alternatives considered

COTS Bespoke using RDBMS Bespoke Space-based

•Stateless engine•State in RDBMS or Queues

•No hub-and-spoke•High availability is costly•RDBMS requires administration•Development platform lock-in•Not really made for our data volumes

•Stateless engine•Bespoke caching•State in RDBMS

•Hub-and-spoke more difficult to implement•High availability is costly•RDBMS requires administration•Development platform lock-in•Not really made for our data volumes

•100% in-memory•Distributed•Partitioning•Hub-and-spoke

•Cleaner/Better programming model•Multi-platform support•Resilience•Performance

7

A space-based sync engine

8

Challenges

• Data Mapping

• Data extraction, visibility, 'invisible' delete

• Support multiple models simultaneously

• Decouple sync clients

• Memory and Performance requirements

9

Scale

• 2,500,000 outlets visited every week more than once ~ 4 million visits

• 10,000 Sales Reps * 77 Mb per user = 752 Gb

• 53 Sales Reps per space @ 4 Gb per space

• 188 spaces + backup

• @10 spaces per machine = 38 machines

10

Design Principles

• Decompose problem into discrete tasks

• Tasks model process flow

• Pluggable services provide business logic

• Extraction, Upload and Mapping driven by externally-managed configuration

• Highly-scalable, resilient, space-based architecture

11

High Level Architecture

Mobile Softwar

eData Centre

ERP

Services

Service Bus

Space Bus (Hub)

Messaging Bus

CRM

Sync Engine

Space Bus (Spoke)Sync

Engine

Mobile Softwar

e

WAN

SyncSyncGatewGatew

ayay

12

High Level Architecture

13

Internal Architecture

14

Downward flow

15

Upward flow

16

Backend extract

17

Reconciliation

18

Backend upload

19

Lessons learned

• GigaSpaces can be used to create a Mobile Data Cloud

• Volumes of scale with resiliency can be achieved 

• You are only as fast as your slowest link / bottleneck

• Monolithic Back Office systems present challenges that can be overcome although it would be nice if vendors migrate to SOA (really)

20

Questions