November last year, I had the privilege of speaking at The Things Conference about "Future-Proof by Design: Building IoT Solutions that Endure." The response from the audience told me I'd struck a nerve—engineers and product leaders alike were grappling with the same questions I've been wrestling with for 25 years: How do you build IoT systems that last? How do you architect for a future you can't predict? And why does our industry keep repeating the same mistakes?
I've been meaning to turn that talk into a blog post ever since. The AI revolution sweeping through IoT has only made the argument more urgent—so here it is.
The era of siloed IoT is over. After two decades of fragmented protocols, proprietary platforms, and isolated data islands, artificial intelligence has become the forcing function that demands open collaboration across the Internet of Things. The convergence of AI and IoT—already a market projected to exceed $79 billion by 2030—requires an architectural foundation that no single vendor can provide alone.
Ironically, the architectural blueprint for that foundation was drafted over 25 years ago. OSGi, first specified in 1999, may look dated in a world of Kubernetes, WebAssembly, and serverless edge computing. Its Java-centric heritage, its XML-heavy configuration era, its association with enterprise middleware of the 2000s—none of that screams "cutting edge" in 2026. And yet, the core engineering principles that OSGi pioneered have never been more relevant. The question isn't whether to use OSGi itself. It's whether the IoT industry is finally ready to adopt the principles OSGi got right a quarter century ago—principles that AI is now making non-negotiable.
25 years of learning what IoT actually needs
I've been working at the intersection of IoT and open standards since before anyone used the term "Internet of Things." When I joined ProSyst Software in 2001, we were building IoT middleware for embedded devices—back then, we simply called it connected device management. The term "IoT" didn't gain traction until around 2005-2006.
Over these 25 years—through roles spanning technology evangelism, industrial IoT business ownership, and now leading products and solutions for Bosch Software and Digital Solutions in Europe—I've watched the same architectural mistakes repeat themselves in every wave of IoT adoption. And I've watched OSGi's core ideas prove themselves right, again and again, even as the technology itself has aged.
I served on the OSGi Alliance Board of Directors, co-chaired its Residential Expert Group for a decade, and chaired the Industrial Internet Consortium's Over-the-Air Updates Special Interest Group. Through all of that, one conviction has only grown stronger: open standards and ecosystem thinking beat vendor lock-in. Every time. Without exception.
What follows isn't a pitch for OSGi as a technology choice in 2026. It's an argument that the principles OSGi embodied—dynamic modularity, runtime service orientation, security isolation, and lifecycle management—are exactly what the AI-meets-IoT era demands. And that most modern IoT architectures still fail to implement them properly.
AI has broken the siloed IoT model beyond repair
The IoT landscape in 2026 remains, in many ways, a patchwork of proprietary systems, competing protocols, and isolated data silos—digital islands that cannot speak to one another without expensive, custom-built bridges. For years, this fragmentation was tolerable. Devices collected data, sent it to a cloud platform, and humans made decisions. The system was inefficient but functional.
AI changed that calculus entirely. When you need machine learning models running inference at the edge, processing data from heterogeneous sensors in real time, and updating autonomously without downtime, the single-vendor approach collapses under its own weight. I've seen this firsthand: research indicates that 70% of IoT-plus-AI integration projects fail due to proprietary lock-in, connectivity gaps, and pilot-to-production scaling issues. Meanwhile, 84% of enterprises now identify AI as a fundamental enabler for their IoT projects—creating an urgent gap between ambition and execution.
The technical demands are staggering. Deploying AI on edge devices means managing resource-constrained microcontrollers with limited memory and power budgets. Models must be compressed through quantization and pruning to run on devices with under 50KB of RAM. Once deployed, those models need dynamic updates—you can't take a factory's predictive maintenance system offline every time you retrain an anomaly detection algorithm. And all of this must work across devices from dozens of manufacturers, speaking different protocols, in environments where 29 billion installed IoT endpoints generate over 73 zettabytes of data annually.
No single company possesses the breadth of expertise to solve this alone. In my experience, IoT deployments typically require two to three ecosystem partners at minimum, spanning hardware, software, connectivity, data analytics, and domain-specific knowledge. 53% of executives now rank strategic partnerships and alliances as a top priority—not because collaboration is trendy, but because the alternative is failure.
Why now is the inflection point
Several converging forces have made 2025-2026 the true tipping point for IoT ecosystem collaboration—and I want to walk you through the ones I find most significant.
The most visible is the edge AI hardware revolution. NVIDIA's Jetson Orin Nano delivers 40 TOPS at under 15 watts. Hailo-8 and Axelera Metis achieve 50-plus TOPS under 5 watts. The edge AI chip market hit $3 billion in 2024 and is growing at nearly 25% annually. Qualcomm's acquisition of Edge Impulse in March 2025 and Nordic Semiconductor's purchase of Neuton.AI in June 2025 signal that major silicon vendors are betting heavily on embedded intelligence. Hardware is no longer the bottleneck. Software architecture is.
The TinyML movement—now rebranded as the Edge AI Foundation as of November 2024—has matured from academic curiosity to production reality. Transfer learning enables adapting pre-trained models to specific IoT use cases on devices consuming milliwatts of power. The transition from TinyML to edge generative AI is already underway, bringing language model capabilities to resource-constrained devices. But deploying, updating, and managing these models across heterogeneous device fleets? That's an architectural problem, not a hardware problem.
Regulatory pressure adds urgency. The EU Cyber Resilience Act, which entered force in December 2024, mandates security-by-design for all products with digital elements sold in the EU. Compliance is required by December 2027, with penalties reaching €15 million or 2.5% of global revenue. The act explicitly promotes interoperability and secure update mechanisms—exactly the capabilities that open, modular architectures provide and proprietary silos struggle to deliver.
The Matter protocol exemplifies the industry's collaborative turn. The ecosystem now exceeds 10,400 certified products from 794 member companies. Thread 1.4, released in September 2024, finally enables border routers to share credentials across ecosystems—solving a fundamental interoperability problem that plagued earlier versions. The industry is learning, slowly, that collaboration isn't optional.
The seven principles OSGi got right — and why they matter more than ever
Let me be direct: OSGi as a technology has rough edges. Its learning curve is steep. Its tooling has not kept pace with modern developer expectations. Its Java dependency limits its reach in a polyglot world. Many of its enterprise-era abstractions feel over-engineered for today's microservice sensibilities.
But strip away the implementation details and look at what OSGi actually specified 25 years ago. You'll find a set of architectural principles that read like a requirements document for modern AIoT systems. Here's what OSGi got right—and what most modern IoT platforms still get wrong.
1. True runtime modularity with hot deployment
OSGi's module system—the bundle—wasn't just a packaging format. It was a runtime-enforced boundary with explicit dependency declarations, version ranges, and classloader isolation. Bundles could be installed, started, stopped, updated, and uninstalled while the system continued running. No restart. No downtime. No monolithic redeployment.
Why this matters for AIoT: When you deploy an anomaly detection model on an edge gateway monitoring a production line, you need to update that model when it drifts—without touching the OPC-UA driver, the MQTT publisher, the local data buffer, or the security layer running alongside it. You need to swap a TensorFlow Lite model for an ONNX Runtime model without rebuilding the entire firmware image. You need to roll back a faulty update in seconds, not hours.
Most modern IoT edge platforms still deploy as monolithic container images or firmware blobs. Updating one component means redeploying everything. This is the architectural equivalent of replacing an entire car engine because you need new spark plugs. OSGi solved this problem in 2001. The principle—independently deployable, independently updatable components with runtime lifecycle management—remains the gold standard that most IoT architectures fail to meet.
The technical mechanism matters: OSGi achieved this through hierarchical classloaders that enforced package-level visibility between bundles, combined with a lifecycle state machine (INSTALLED → RESOLVED → STARTING → ACTIVE → STOPPING → UNINSTALLED) that governed transitions deterministically. Each bundle declared its imports and exports at the Java package level, with semantic versioning and version range matching. The resolver would wire dependencies dynamically, refusing to activate a bundle whose requirements couldn't be satisfied. This isn't just "hot deploy"—it's dependency-safe hot deploy, something that Docker swap-and-restart still doesn't provide.
2. Service-oriented architecture with dynamic binding
OSGi's service registry was a local, in-process publish-subscribe mechanism where components registered and discovered services through Java interfaces. Services appeared and disappeared dynamically. Components could filter, rank, and track services at runtime. The Declarative Services specification later simplified this with annotation-driven dependency injection that automatically activated and deactivated components based on service availability.
Why this matters for AIoT: An IoT gateway in a smart factory might need to integrate data from Modbus sensors, BACnet HVAC controllers, OPC-UA industrial equipment, and Bluetooth Low Energy environmental sensors—all simultaneously, with devices joining and leaving the network constantly. An AI inference engine needs to consume data from whatever sources are currently available, gracefully degrading when a sensor goes offline rather than crashing.
This is fundamentally a dynamic service discovery problem. The modern IoT world has reinvented pieces of this—mDNS for local discovery, service meshes for microservices, MQTT topic-based routing for messaging. But none of these provide the tight, in-process, type-safe service binding that OSGi's model delivered. When your edge device runs fifteen different vendor components that need to communicate reliably, loosely coupled service interfaces with dynamic lifecycle tracking aren't a luxury—they're a necessity.
The elegance of OSGi's approach was the separation of the service interface (a plain Java interface) from its implementation. Multiple implementations could coexist, ranked by properties. Consumers didn't know or care which implementation they were using. When an implementation was updated—say, replacing a rules-based anomaly detector with a neural network—consumers continued operating without modification, without restart, without reconfiguration. The service registry handled the rebinding transparently.
3. Security isolation at the component level
OSGi's security model extended Java's security architecture with bundle-level permission management. The Conditional Permission Admin enabled operators to define fine-grained permission sets: which bundles could access the filesystem, which could open network connections, which could interact with specific hardware interfaces. Permissions were enforced at runtime and could be modified dynamically without restart.
Why this matters for AIoT: In any real-world IoT deployment, you're running code from multiple vendors on the same device. A protocol driver from vendor A, an analytics engine from vendor B, a visualization component from vendor C, and an AI model from vendor D—all sharing a single runtime on a gateway with direct access to operational technology networks. If vendor B's component is compromised, can it access vendor A's sensor data? Can it exfiltrate data through vendor C's network connection? Can it tamper with vendor D's model parameters?
The EU Cyber Resilience Act explicitly demands security-by-design and vulnerability handling across the entire software supply chain. Most IoT platforms today run components either in shared processes with no isolation (everything can access everything) or in separate containers with heavy overhead (hundreds of megabytes per component on resource-constrained devices). OSGi's in-process security model provided a middle path: lightweight isolation that enforced access boundaries without the resource cost of full containerization.
The principle is clear: multi-vendor code sharing a runtime requires enforceable security boundaries at the component level, not just at the process or container level. Whether you implement this through OSGi's permission model, WebAssembly's capability-based security, or a future mechanism yet to be invented, the requirement is non-negotiable in an era of AI models from third-party providers running on shared edge infrastructure.
4. Configuration management for heterogeneous fleets
OSGi's Configuration Admin service provided a standardized mechanism for managing component configuration across diverse device populations. Configurations were stored separately from code, could be updated at runtime, and were scoped to specific component instances. The MetaType service added self-describing configuration schemas, enabling management tools to generate configuration UIs automatically.
Why this matters for AIoT: Consider deploying an AI-powered quality inspection system across 200 factory locations. Each location has different camera hardware, different lighting conditions, different product variants, and different network constraints. The AI model is the same, but its preprocessing pipeline, confidence thresholds, inference scheduling, and data retention policies differ per site—sometimes per production line.
This is a fleet configuration management problem at massive scale. You need to push model updates to all 200 sites while preserving site-specific configurations. You need to adjust inference parameters on a subset of devices without affecting others. You need to roll out configuration changes gradually, validate them, and roll back if quality metrics degrade.
OSGi solved this by decoupling configuration from code and making configuration a first-class runtime concept with its own lifecycle. Modern IoT platforms typically bake configuration into environment variables, config files in container images, or cloud-side device twins. None of these approaches match the granularity and dynamism that per-component, runtime-modifiable, schema-validated configuration management provides—especially when components from multiple vendors each have their own configuration requirements.
5. Explicit dependency management with semantic versioning
OSGi mandated that every bundle declare its dependencies as package imports with version ranges—not just "I need library X" but "I need package org.sensor.api version [2.0, 3.0)" meaning any compatible version from 2.0 up to but not including 3.0. The framework's resolver verified that all dependencies could be satisfied before activating a bundle, preventing the runtime classpath conflicts and "dependency hell" that plague most software systems.
Why this matters for AIoT: Edge AI deployments involve complex dependency graphs. An inference engine depends on a specific version of a math library, which depends on a specific native binding, which depends on a specific hardware abstraction layer. A protocol driver depends on a specific version of a parsing library that conflicts with the version another driver needs. An AI model exported from a training pipeline expects a specific tensor format that the edge runtime's new version has deprecated.
In monolithic deployments, these conflicts surface as mysterious runtime crashes weeks after deployment. In containerized deployments, each component carries its own copy of every dependency, bloating device storage and memory. OSGi's approach—declared dependencies with version ranges, verified at resolution time before any code executes—caught conflicts early, deterministically, and allowed multiple versions of the same library to coexist through classloader isolation.
The broader principle: any system that deploys components from multiple sources onto resource-constrained devices must have explicit, machine-verifiable dependency management with conflict detection before deployment, not after. Whether you achieve this through OSGi's resolver, Nix-style reproducible builds, or WebAssembly component model interfaces, the requirement is fundamental.
6. Interoperability across protocols and platforms by design
OSGi's entire architecture was built around the idea that components from different vendors, written at different times, for different purposes, must work together on the same runtime. The service registry acted as a protocol-neutral integration bus: a bundle exposing a temperature reading didn't need to know whether the consumer was a cloud connector, a local rule engine, or an AI inference pipeline. The standardized service interfaces created a contract layer that decoupled producers from consumers completely—not just at the code level, but at the organizational level. Two companies that had never spoken to each other could build components that interoperated seamlessly, as long as both adhered to the shared interface specifications.
Why this matters for AIoT: The IoT interoperability problem is getting worse, not better. A modern smart building might combine BACnet for HVAC, KNX for lighting, Modbus for energy metering, Zigbee or Matter for occupancy sensors, and LoRaWAN for parking lot monitoring—each with its own data model, its own addressing scheme, its own semantics. Layering AI on top of this means an inference engine must consume normalized data from all of these sources simultaneously. A predictive maintenance model trained on OPC-UA vibration data must also ingest MQTT-based temperature readings and REST API-delivered production schedules.
The industry's current answer to this is typically a cloud-side data lake where everything gets normalized after ingestion. But edge AI demands interoperability at the device level, before data ever leaves the gateway. You can't run a real-time anomaly detection model if the data it needs is scattered across five incompatible protocol stacks with no common abstraction layer.
OSGi's principle here was deceptively simple: define the contract, not the implementation. A SensorDataServiceinterface doesn't care whether the data arrives via Modbus, OPC-UA, or MQTT. A ModelInferenceService doesn't care whether the underlying engine is TensorFlow Lite, ONNX Runtime, or a custom C library behind a JNI bridge. The abstraction boundary is the service interface—and as long as that interface is well-designed and versioned, any implementation can participate in the ecosystem. This is the same insight that drove the success of POSIX, SQL, and HTTP: interoperability comes from shared abstractions, not from shared implementations.
7. Reusability of components across products and generations
Perhaps the most underappreciated aspect of OSGi's design was how aggressively it enabled component reuse. Because bundles were self-contained units with explicit dependencies and no hidden assumptions about their hosting environment, a bundle written for one product could be deployed in an entirely different product without modification. A Modbus protocol driver developed for a building automation gateway could be reused verbatim in an industrial edge controller. A data logging component built for a first-generation device could migrate unchanged to its successor hardware five years later.
This wasn't accidental—it was a direct consequence of the architectural principles working together. Classloader isolation prevented bundles from making assumptions about what else was running. The service registry prevented hard-coded dependencies on specific implementations. Semantic versioning prevented silent API breakage. Configuration Admin prevented baked-in environment assumptions. Together, these mechanisms created components that were genuinely portable across contexts, products, and time.
Why this matters for AIoT: Building AI-enabled IoT solutions from scratch for every product, every customer, and every generation is economically unsustainable. The development cost of a robust OPC-UA driver, a secure OTA update mechanism, or a TensorFlow Lite inference wrapper is significant. If that investment is locked to a single product because the component is entangled with its host application, the cost must be amortized over a single product's revenue. If it's genuinely reusable, the same investment pays dividends across an entire product portfolio—and across hardware generations that span a decade or more.
I've seen organizations build the same protocol driver three or four times because the previous version was so tightly coupled to its original product that extracting it was more expensive than rewriting it. I've seen AI preprocessing pipelines that worked perfectly on one gateway fail completely on the next because they contained implicit assumptions about filesystem paths, memory availability, or co-resident services. Every one of these failures traces back to the same root cause: the original architecture didn't enforce the boundaries that make reuse possible.
The principle is straightforward: components must be designed as self-contained, context-independent units that declare their requirements explicitly and make zero assumptions about their deployment environment. When you achieve this—as OSGi's bundle model demonstrated—a component library becomes a compounding asset that grows more valuable with every product it's deployed in. When you don't, every product starts from near-zero, and every generation discards the engineering investment of its predecessor.
The gap between these principles and today's reality
Here's what frustrates me after 25 years in this space: the IoT industry keeps learning these lessons the hard way, over and over again.
Container-based edge deployments give you process isolation and simplified packaging but sacrifice granularity. You can't update one component of a container without rebuilding and redeploying the entire image. On a gateway with 512MB of RAM, running six Docker containers for six vendor components is prohibitively expensive. You lose the in-process communication efficiency that sub-millisecond edge AI inference demands.
Monolithic firmware approaches are fast and resource-efficient but make updates dangerous and all-or-nothing. A bug in the telemetry module requires reflashing the entire device, taking down the AI inference pipeline, the protocol drivers, and the security stack along with it. Partial updates and rollbacks become complex engineering projects rather than routine operations.
Cloud-first architectures defer the modularity problem to the cloud, but AI is forcing intelligence to the edge. When you need sub-10-millisecond inference latency for a robotic arm's collision avoidance system, roundtripping to the cloud isn't an option. When regulatory requirements mandate data sovereignty and local processing, cloud-side model serving fails by design. The architectural complexity that the cloud used to absorb is migrating to the edge—and the edge isn't ready.
Microservice patterns adapted from web backends introduce network overhead between components that should be communicating in-process. Serialization, deserialization, and network stack traversal add latency and resource consumption that resource-constrained edge devices cannot afford. An AI inference pipeline that involves three HTTP calls between local containers to go from sensor reading to inference result to actuation command is architecturally broken for real-time industrial use cases.
What the next generation of IoT architecture must deliver
Based on everything I've seen over 25 years, here's what I believe the AIoT era demands from its architectural foundations—whether or not OSGi is part of the implementation:
Component-level modularity with independent lifecycle management. Every functional unit—a protocol driver, an AI model, a data preprocessor, a security policy engine—must be deployable, updatable, and removable independently, at runtime, without system restart. This is the single most critical architectural requirement for AI-driven IoT, and the one most commonly violated.
In-process service discovery with dynamic binding. Components on the same device must communicate through typed interfaces with automatic lifecycle tracking—not through network calls, not through shared files, not through message queues. When a new AI model is deployed, consuming components should bind to it automatically. When a sensor driver crashes, dependent components should degrade gracefully, not crash in cascade.
Lightweight security isolation between vendor components. Running multi-vendor code on shared edge infrastructure without enforceable security boundaries is negligent in 2026. Full container isolation is too expensive for constrained devices. The industry needs in-process isolation mechanisms—whether based on classloader hierarchies, WebAssembly sandboxing, capability-based security, or hardware-assisted memory protection.
Configuration as a first-class runtime concept. Device configuration must be decoupled from code, scoped per component, modifiable at runtime, and manageable across heterogeneous fleets. AI model hyperparameters, inference schedules, preprocessing pipelines, and data retention policies must be configurable without redeployment.
Explicit, machine-verifiable dependency management. Before any component is deployed to an edge device, the system must verify that all its dependencies can be satisfied, that no version conflicts exist, and that resource constraints (memory, storage, compute) are met. Post-deployment crashes from dependency conflicts are unacceptable in safety-critical IoT environments.
Protocol-agnostic interoperability at the device level. Edge AI cannot wait for cloud-side data normalization. Components must communicate through shared abstraction layers that decouple data producers from consumers regardless of the underlying protocol—Modbus, OPC-UA, MQTT, Matter, or whatever comes next. Interoperability must be an architectural property, not an integration project.
Reusability as a compounding engineering asset. Components must be self-contained, context-independent units that can migrate across products, customers, and hardware generations without modification. Every protocol driver, AI inference wrapper, or security module that's locked to a single product represents duplicated engineering cost that the industry can no longer afford.
Designing for longevity: the hidden superpower of OSGi thinking
There's one meta-principle underlying everything I've described that deserves its own attention: designing for longevity.
IoT devices aren't web applications. You don't spin them up for a product launch and deprecate them eighteen months later. A smart meter deployed today must operate for 15 to 20 years. An industrial gateway installed in a factory will outlast multiple generations of AI frameworks, cloud platforms, and communication protocols. A connected vehicle's electronic architecture must remain updatable for a decade or more—long after the team that designed it has moved on.
This is where OSGi's principles reveal their deepest value. When you design a system around strict interface contracts between modules, you're not just enabling hot deployment—you're decoupling the rate of change between different parts of the system. The MQTT protocol driver can evolve independently of the AI inference engine. The security policy layer can be hardened against newly discovered vulnerabilities without touching the sensor data pipeline. A protocol that doesn't exist yet—the successor to Matter, the next industrial fieldbus standard—can be integrated as a new module without redesigning the architecture.
Contrast this with today's dominant approaches. A monolithic firmware image ties every component to the same release cycle—the slowest-moving piece dictates the pace for everything. A tightly coupled cloud dependency means that when the cloud provider deprecates an API version or sunsets a service (and they will), every device in the fleet is affected simultaneously. A container image that bundles an AI runtime with a specific version of glibc and OpenSSL becomes a security liability the moment a CVE is published—but rebuilding it means regression-testing the entire stack.
OSGi's design philosophy was fundamentally about absorbing change without breaking. Semantic version ranges meant that a bundle could declare compatibility with a range of API versions, automatically picking up improvements without manual intervention. The service registry's dynamic binding meant that implementations could be replaced—by a better algorithm, a more efficient library, a post-quantum cryptography provider—without consumers even knowing. The Configuration Admin's separation of configuration from code meant that operational parameters could evolve independently of software releases.
In IoT, longevity isn't a feature. It's a survival requirement. The devices we deploy today will need to run AI models that haven't been invented yet, speak protocols that haven't been standardized yet, and comply with regulations that haven't been written yet. The only way to achieve that is to architect for change from the beginning—to build systems where every component can be replaced, every interface can be extended, and every dependency can evolve, without bringing down the whole.
That's what OSGi taught me in 25 years. Not how to write bundles and service trackers. But how to think about software that must outlive its creators' assumptions.
Collaboration is the only path forward
These principles aren't theoretical ideals. They're engineering requirements that I've validated across thousands of IoT deployments over 25 years—in smart homes, factories, connected vehicles, telecom infrastructure, and energy systems. OSGi proved them in production with millions of device deployments, even if the technology itself has aged.
The organizations that thrive in the AIoT era will be those that embrace open standards, contribute to open-source foundations, and architect their systems for dynamic, modular, secure interoperability. It is industry collaboration that increases the quality of standards. Multiple stakeholders foster long-term investment and increase the durability and global adoption of solutions. The siloed alternative—vendor lock-in, data trapped in proprietary formats, forced obsolescence when platforms shift—has always been costly. With AI raising the stakes exponentially, it has become untenable.
The technology to build this future exists. The principles have been proven for a quarter century. The only question is whether our industry moves fast enough to implement them—together—before the AI-driven transformation leaves the holdouts behind.
I invite you to join this conversation. Whether you're building edge AI solutions, deploying IoT at scale, or navigating regulatory compliance—let's collaborate on the architectural foundations that will define the next decade of connected intelligence.