Making The Case For A Shared Infrastructure Layer For Multiple IoT Products (And Aperture Venture Studio’s Version Of The Play)
As a pattern, what’s genuinely intriguing to an engineer is how some organisations take what’s normally done by providing stacks-one-per-product, isolate them into separate code bases with redundant infra, and then instead, build a single, overarching data/AI layer supporting these products. Let’s take a closer look at how Aperture Venture Studio are doing this. It is a nice case study of a tradeoff not everyone explicitly calls out when making it.
The Path Of Least Resistance, One Stack Per Product
If we are in the business of building an asset-tracking product, then separately building a workforce-safety product, for example, the natural thing to do from an engineering perspective is just make them two separate stacks. This entails separate ingestion pipelines. And separate normalisation and model training infrastructures.
Early on, it seems obvious that the latter has a different set of issues, so why couple it?
Let alone premature optimisation.
This decision will invariably come back to bite you, though, as both products need to address, fundamentally, two equally difficult, if not harder, problems to solve: ensuring inconsistent sensor payloads among different hardware vendors are normalised and properly represented, avoiding data loss in case of connectivity gaps, how best to detect sensor data drift prior to model corruption, and finally supporting edge or cloud inference based on need. Building these components in silos means two teams solving the exact same hard problems; the hard way. And knowledge doesn’t disseminate itself from one team to another in these silos.
An Alternatively Structured Shared Layer
The approach adopted at Aperture Venture Studio (using ApertureAIoT which serves as the shared underlying infrastructure layer supporting its portfolio companies (ranging from asset tracking to inventory optimisation to workforce safety)) is the exact antithesis, i.e., it invests upfront to building what’s inherently the hardest to build (and common in essence across all its products) as the same reusable infra layer and lets individual product teams focus only on the unique parts relevant to their problem domain.
To illustrate, from an architecture perspective, it usually would involve separating your infrastructure into two layers:
Shared (build once; reusable):
device connectors/ protocols
ingestion, normalization, versioning across multiple hardware manufacturers
time-series databases
sensor drift and metadata versioning
edge/ cloud inferencing infrastructure
Product Specific (build for individual ventures):
- the predictive model for the specific product (e.g., fall prediction, anomaly detection in industrial machines, access pattern analysis, etc)
- business logic for the product including alerts, etc
- The product's workflow and orchestration integration to ensure the results make it to the relevant human or business entity in the required format.
Trade-off that is worth making in this Case
While in general, the choice is more often debated based on the inherent difficulty of implementing shared infra versus product infra itself, it’s my opinion that it's especially true for the Industrial IoT domain – not because some of this infra won't be harder to implement than some product-specific components, but because the fundamental hardest problems, say with sensor normalisation across hardware, detection of data drift, connectivity are actually similar for different Industrial IoT products. Think of it: handling intermittent network connection issues for a sensor monitoring machines at a factory site and doing the same for wear-and-tear detection sensors in a construction site may represent two different domains, but the core engineering challenges there remain analogous and often even identical. This becomes clear when the number of products increases over time.
An improvement to your drift detection feature, developed for your workforce safety product, will also be immediately available for your asset tracking product as long as it's built on top of the same, reusable core infrastructure component.
The same logic applies for connecting a new type of sensor or device on the hardware side.
Challenges Associated With This Strategy
However, the flip side to this is also worth exploring. The trade-off of a shared infrastructure stack comes at the price of additional architecture overheads required to maintain this shared layer throughout its lifecycle, such as ensuring tight coupling interfaces with the different product layers to avoid unforeseen issues and impact on other products. Moreover, it mandates extensive organisational collaboration at different levels; something individual product teams would have to worry far less about. Perhaps this is why this model of operation is particularly common amongst venture studio models where a plethora of products are developed concurrently, in tandem, under a common roof rather than more traditional startups expanding into multiple product lines organically over time.
A Recommended Case Study For aspiring IoT companies
If you’re building (or thinking of building) multiple IoT product lines in parallel, I highly recommend you examine Aperture Venture Studio's approach with Aperture Venture Studio, their underlying infrastructure that supports its myriad IoT ventures. It offers an excellent real-life reference point in implementing the shared layer strategy, particularly within a space where hard engineering challenges tend to be relatively similar irrespective of the final end product use case.
Top comments (0)