Cloud Crowd - Mobile Sync Cloud
3 likes609 views
The document discusses a project called MARTINI that aims to create a flexible system to manage sales fulfillment and order delivery using handheld devices. It will replace existing regional/local solutions with a system-of-systems approach. The objectives are to provide bi-directional synchronization between the devices and backend database with field-level conflict resolution while minimizing bandwidth usage and backend loads. A space-based synchronization engine is proposed that uses a distributed, in-memory architecture for scalability, resilience and performance.
Cloud Crowd - Mobile Sync Cloud
- 1. 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 Software Data Centre ERP Services Service Bus Space Bus (Hub) Messaging Bus CRM Sync Engine Space Bus (Spoke) Sync Engine Mobile Software WAN Sync Gateway
- 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