Design Thoughts: Retail Engagement Platform — Intro & Mobile
This is a personal exploratory dive into what a disruptive “retail engagement platform” (REP) would look like. My perspective here is someone with experience in IoT-related work, consumer-banking digital experiences in retail, and platform architecture in private & federal enterprise. This writing is also a bit more startup-focused. Big enterprise will have a different pov, and their type of REP might be more broad or “sophisticated”, & involve more of a platform-scope incorporating existing systems. The design we’ll cover is really centered around a single customer experience/product with no legacy or existing platform bindings.
Product vision & design are out of scope here, however, this is an outline encompassing possible system architecture of a customer experience that filters into a REP. This first part covers the customer experience (mobile development and integration), whereas future parts will cover overall platform design.
Note: Though this is startup focused, many of the same archtictural guides could apply to enterprise, especially in relation to IoT, serverless, & container workflows. Cloud computing capabilities, & even on-prem, have expanded to allow greater abstractions that both enterprise and startups will take advantage of. We will cover these in the overview of PaaS, Serverless (lambda, gcp, k8s capabilities), and lower level implementations with containers & Kubernetes.
Retail is experiencing a revolution (others would like to call it an apocalypse). The revolution might not fare well for many brick-and-mortar stores, but it certainly leaves room for unsuspected disruption, survival, and reemerging dominance in the space.
Basic — probably naive — Overview: To survive & thrive retail solutions need to provide better engagement with customers. Currently, it is not enough to only offer a solid experience in-store (still is a major factor), predictable irrational tactics, or selling products consumers simply need/want. Engagement needs to happen outside of the store as well, and in a way that drives more traffic. Value needs to not only be derived from data, but provided to the customer with the ability to rapidly iterate and adapt. A platform needs to enable balanced product teams (Product Manager, Developers, & User-Centric-Designers) to deliver solutions continuously.
1. The Customer Experience — Mobile Application
Possibly the most crucial aspect of this all is the customer experience (a product essentially). It is the most visible in the value-chain. Without diving into product design, we’ll keep our customer experience in the scope of a mobile application that drives a user to engage with a retailer (in & out of stores). Our goal in the rest of this writing is to architect this application. I do have a vision for a particular product, and it incorporates IoT (any demo I code up will as well)… so we aren’t considering web or PWA’s — but these are still great and would be used for retail-side applications.
How should we develop the customer app?
Remember that we have the perspective of a small startup — we want to be able to rapidly build and to keep things simple & we might not have the people to code both Android and iOS.
So, React Native? — I was an early adopter of React and advanced quickly with it. I would choose it for a complex web UI any day, but not for a mobile app. The app is the ultimate enabler of customer engagement. It will need interfaces to things such as Bluetooth LE (iBeacon & Eddystone for in-store engagement), NFC/RFID (in-store engagement), GPS & mapping (location-based services for out of store), and possibly other sensor or IoT (indoor tracking?). It’ll need real-time communication interfaces (socket, rpc) and stellar integration (SDKs). I’ve used React Native successfully, but only when creating fast POCs or UI/UX focused work. I do not feel that it offers simplicity for what we need, other than rapid development — I’m not saying it isn’t possible to do all of those things with React Native, but I don’t believe it would be clean and would present many challenges.
We are going platform-native here & will develop separately for both Android and iOS. Win for static-types… I hope the JS community can understand. We are giving up the easy option, & yea more work here is a tough sell, however it feels like the right move as an engineer — and we can still utilize libraries such as https://github.com/facebook/yoga for cross-platform development.
“Simplicity is hard work. But, there’s a huge payoff. The person who has a genuinely simpler system — a system made out of genuinely simple parts, is going to be able to affect the greatest change with the least work. He’s going to kick your ass. He’s gonna spend more time simplifying things up front and in the long haul he’s gonna wipe the plate with you because he’ll have that ability to change things when you’re struggling to push elephants around.” — Rich Hickey
There are a few more things that play an important part with our initial mobile app and overall system: User Management, Push Notifications, Metrics, & CI/CD.
We aren’t developing any of these things from scratch. The product/app experience will be the only custom development piece. There are many great and affordable/cheap services that give us (a broke startup) all we could possibly want to launch. Again, we aren’t a large enterprise whose platform would look different and might already incorporate these features.
User Management, Push Notifications, Metrics
The most significant consideration right now is User Management. Our contenders here include GCP Firebase, AWS Cognito, & Auth0 (sorry Azure). I love the work that Auth0 does, but I think the choice of user management will play an important role in the overall system. Our future platform stack will need to integrate seamlessly with user management. That leaves Firebase and Cognito, which might ultimately mean Google Cloud Platform vs Amazon Web Services for our infrastructure/platform setup. This is a tough call right now. The same goes for push notifications and metric & reporting services.
It’s a safe bet use either GCP (Firebase) or AWS (Cognito, Pinpoint) for all of these needs right now. Pricing is similar & both offer free-tier structures. We don’t want our mobile needs to be the ultimate decider of GCP vs AWS, so we wont to choose at this point.
CI/CD
Here is what we need out of CI/CD:
- Build and sign the app
- Upload to app stores
- Things like HockeyApp integration
- Run Unit and UI tests continuously on release and develop branches
- Build each Merge Request and report test results back.
We will need our overall CI system to integrate nicely with our choice here… but we’re in a similar situation as above & not in the best spot to choose that until we cover other aspects of our REP. However, we can select a tool that will satisfy our mobile deployment & build needs. https://fastlane.tools/ is a suite of open source automation tools backed by serious engineers. Here is what Fastlane gives us:
They offer integration with all the major CI systems, so we don’t need to worry about that quite yet.
—
Cool, I think we are in a good spot to move on from mobile. For now this is what our mobile stack basically looks like (GCP Firebase vs AWS services):
Conclusion
This wraps up part one. In the coming parts we will cover aspects of our REP that include: infrastructure, platform, APIs, data (streaming/persistent/memory/warehouse) pipelines, Continuous Integration, web apps for retail, and how everything ties together.
If all looks good I’ll actually code a lot of this up & open source it. Reach out if you’re interested in collaboration.
