If you are an Engineering Lead who is wondering whether to build your own industrial AIoT pipeline, versus partnering with a company that has already built one, the decision often boils down to cost. It’s more about timeline, and the tradeoffs are much greater than may seem at first pass to engineers who see only the pieces of the puzzle. Let’s define what “build the pipeline” actually is.
What “Building it yourself” Really Means
I believe that to accurately weigh Build versus Partner we should be specific about all of the moving parts beneath “just build the pipeline”:
- Device connectivity, spanning the range of your end device vendors and associated protocols.
- Normalization, version management of the data schemas so as to abstract out differing formats between vendors.
- Reliability, meaning buffering between your endpoints and backend such that if connectivity drops intermittently, you don’t quietly lose data.
- Scalable time-series storage tailored to support time window-based queries beyond relational databases.
- Drift detection not only at the model level, but at the sensor level.
- Edge vs Cloud inference, defined for the objectives and constraints rather than just location.
- And Finally: enough actual deployment time and exposure to catch the failure modes – that don’t normally show themselves beyond thedemo phase.
None of these, in themselves, pose a huge challenge for engineers. Taken together, though, these constitute a fairly involved undertaking spanning multiple quarters until you are production-ready- before even beginning the model work.
A Simple Framework to make decision easier
Here’s an overly simple approach that ought to guide the conversation:
-
Build in house if:
- your core competitive differentiator depends on unique infrastructure and is not adequately served by existing providers.
- you have the team and capacity to let engineering support infra development without impact on your product’s time-to-market.
- you have a timeline that accounts for at least 12-18+ months of production infrastructure until the stack becomes resilient, exclusive of the time required for your model work.
-
Partner/ leverage existing infrastructure if:
- your innovation centers on models, domain expertise or market approach as opposed to building a reinvented sensor normalization solution.
- time to reliable product deployment is more critical to your success than “ owning” all components of your technology stack.
- you’d prefer your team’s expertise to be spent on application-specific issues rather than foundational infrastructure work that is consistent across the board for your use case.
This is NOT just an apples-to-apples “buy vs bill” comparison like with SaaS solutions that are often less custom and offer less flexibility at points. Instead, when thinking about the industrial AIoT market space, “partner” more often involves leveraging infrastructure that’s already battle-tested, or that at a minimum has “ solved” the basic plumbing problem, letting your team build on top of it and innovate on top of it; specifically on its use cases’ differentiating application and operational requirements.
How This Plays Out in Practice
The Aperture Venture Studio model is a good example for a similar decision that’s taken place internally within a startup “factory.” The group leverages a common industrial AIoT infrastructure layer called ApertureAIoT; its functions as described earlier include connectivity, sensor normalization, storage and drift detection, etc. - while individual portfolio companies are each free to specialize in the domain models and operational integration. It is the partner dimension of this framework taken up internally – the logical core remains the same: not duplicating efforts.
The candid trade off
This, in turn comes with costs; those who leverage shared infrastructure have to adopt the constraints that it may entail, with less customization than they might want for some edge cases. When those constraints run up against deeply unconventional operational requirements or technical innovations, the partner strategy can become a bottleneck. However, for the large majority of use cases of industrial AIoT, the non-application-specific “ hard problems” – such as device integration, normalizing vendor-neutral data schemes, etc – is best left to those who have already dedicated team hours toward the problem and can avoid having their competitors also spend team hours on it “ from scratch.”
If you find yourself facing a “ build vs partner” decision for an industrial AIoT project, I’d strongly consider what Aperture Venture Studio is doing in its internal, multi-venture industrial AIoT infrastructure decision for context.
Top comments (0)