CloudCrowd- BAT Presentation on building a private mobile sync cloud
2 likes•2,676 views
The document outlines the Martini Project, a global initiative designed to implement a flexible and extensible system for over 10,000 sales reps using hand-held devices to improve sales fulfillment and order delivery. It details the project's objectives, including robust synchronization capabilities, bi-directional synchronization, and performance considerations, along with challenges and design principles. Alternatives considered included various system architectures, leading to the decision to utilize a space-based sync engine for scalability and resilience.
CloudCrowd- BAT Presentation on building a private mobile sync cloud
- 1. Mobile Sync CloudAlejandro M. Ramallo - Group Head of Technology, BATPhil Shotton - Cloudscape
- 2. 2BackgroundThe MARTINI Project is a global initiative to provide a flexible, extensible TM&D systemA 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 functionsThe hand-held will run a bespoke application accessing a local database holding an extract from the BAT backend’s master database
- 3. 3ObjectivesRobust, resilient synchronisation capabilityFull database loadBi-directional delta synchronisationBackground scheduling of data retrieval and synchronisation Field-level delta updates to minimise network bandwidth requirements and backend system load
- 4. 4RequirementsProvide bi-directional, asynchronous, delta synchronisationConflict resolution at field levelMinimise mobile connect timePlug-in architecture, extensibleScalabilityPerformanceHub-and-spoke capabilities
- 5. 5Scale2,500,000 outlets visited every week more than once ~ 4 million visits10,000 Sales Reps * 77 Mb per user = 752 Gb
- 6. 6Alternatives consideredCOTSBespoke using RDBMSBespoke Space-basedStateless engine
- 7. State in RDBMS or Queues
- 9. High availability is costly
- 12. Not really made for our data volumes
- 13. Stateless engine
- 14. Bespoke caching
- 15. State in RDBMS
- 16. Hub-and-spoke more difficult to implement
- 17. High availability is costly
- 20. Not really made for our data volumes
- 21. 100% in-memory
- 22. Distributed
- 23. Partitioning
- 24. Hub-and-spoke
- 27. Resilience
- 28. Performance7A space-based sync engine
- 29. 8ChallengesData MappingData extraction, visibility, 'invisible' deleteSupport multiple models simultaneouslyDecouple sync clientsMemory and Performance requirements
- 30. 9Scale2,500,000 outlets visited every week more than once ~ 4 million visits10,000 Sales Reps * 77 Mb per user = 752 Gb53 Sales Reps per space @ 4 Gb per space188 spaces + backup@10 spaces per machine = 38 machines
- 31. 10Design PrinciplesDecompose problem into discrete tasksTasks model process flowPluggable services provide business logicExtraction, Upload and Mapping driven by externally-managed configurationHighly-scalable, resilient, space-based architecture
- 32. 11High Level ArchitectureMobile SoftwareData CentreERPServicesSpace Bus (Spoke)Service BusSync EngineMessaging BusCRMWANSyncGatewaySpace Bus (Hub)Mobile SoftwareSync Engine
- 35. 14Downward flow
- 36. 15Upward flow
- 38. 17Reconciliation
- 39. 18Backend upload
- 40. 19Lessons learnedGigaSpaces can be used to create a Mobile Data CloudVolumes of scale with resiliency can be achieved You are only as fast as your slowest link / bottleneckMonolithic Back Office systems present challenges that can be overcome although it would be nice if vendors migrate to SOA (really)
- 41. 20Questions