IoT Value Stack in Practice: How We Built a Building Automation Platform Across All 5 Layers
Most IoT articles explain the value stack in theory. This one doesn't.
Over 14 months, I built an edge-to-cloud platform with a 55-person team - from hardware to user interface. CE/RoHS certification included.
This article shows what actually happens in each layer, where the real complexity lies, and which decisions make the difference.
The IoT Value Stack: 5 Layers, 5 Decision Fields
The value stack describes the five layers of an IoT solution:
- Physical Device - Hardware that captures data
- Sensors & Actuators - Measurement and control
- Connectivity - Data transmission
- Analytics - Data processing and insights
- User Interface & Services - User interaction
The model is well known. What's missing: How these layers interact in regulated environments - and where the real problems lie.
Layer 1: Physical Device
What happened in the project:
The platform controlled building automation - doors, access systems, climate control. The physical devices were already in the field, some for years.
The real challenge:
New devices weren't the problem. Integrating existing hardware into a new cloud architecture was. Legacy protocols, different firmware versions, no unified interface.
Decision:
We built an abstraction layer between legacy hardware and the new platform. Effort: 3 months. The alternative would have been hardware replacement - economically not feasible.
Regulatory aspect:
Any hardware change would have required new CE testing. The abstraction layer was software-only - no re-certification effort.
Layer 2: Sensors & Actuators
What happened in the project:
Temperature sensors, motion detectors, door contacts, actuators. Hundreds of device types from different manufacturers.
The real challenge:
Heterogeneity. Each sensor had its own protocols, data formats, update cycles. Defining a central data model that covers all of them was more complex than the actual cloud development.
Decision:
We defined a canonical data model and built adapters per device type. This slowed down the start but massively accelerated scaling.
Regulatory aspect:
Safety-critical actuators (fire doors, emergency exits) were subject to additional standards. Any change to the control logic required documentation for CE conformity.
Layer 3: Connectivity
What happened in the project:
Edge-to-cloud architecture. Local gateways collected data, aggregated it, sent it to the cloud. Critical control commands ran locally - without cloud dependency.
The real challenge:
Latency and reliability. A fire door must respond in milliseconds - not seconds when the cloud responds. At the same time, we wanted centralized analytics and remote management.
Decision:
Hybrid architecture: Critical logic on the edge gateway, analytics and long-term storage in the cloud. This doubled development complexity but was non-negotiable.
Regulatory aspect:
For CE certification, we had to prove that safety-critical functions work even during network outages. The edge-first architecture was a regulatory requirement.
Layer 4: Analytics
What happened in the project:
Predictive maintenance for building technology. Goal: Predict failures before they happen. Reduce maintenance costs, increase availability.
The real challenge:
Data quality. Sensors delivered raw data - but without context. A temperature value alone says nothing. Only in combination with room occupancy, outside temperature, and equipment history does it become meaningful.
Decision:
We invested 4 months in data engineering before starting with ML models. Most IoT projects underestimate this effort.
Result:
Maintenance intervals could be extended by 25% without increasing failure risk. That alone justified a significant portion of the project investment.
Layer 5: User Interface & Services
What happened in the project:
Two interfaces: A technical dashboard for facility managers, a mobile app for building operators.
The real challenge:
Different users, different needs. Facility managers want detailed data and configuration options. Building operators want overviews and alerts.
Decision:
Two separate frontends on the same API. More development effort, but clear user guidance. A generic dashboard for both audiences would have been optimal for neither.
Regulatory aspect:
Documentation and audit trails were mandatory. Every configuration change had to be traceable - for CE conformity and insurance requirements.
What This Project Teaches About IoT
1. Regulation Is Not an Obstacle - It's an Architecture Driver
CE/RoHS requirements defined the architecture: Edge-first for reliability, abstraction layer for changeability, audit trails for traceability. Treat regulation as an afterthought and you'll build twice.
2. Integration Beats Innovation
The hardest problems weren't technical innovations. They were integration: legacy hardware, heterogeneous sensors, different protocols. 60% of the effort went into adapters and abstractions.
3. Data Engineering Before Data Science
Predictive maintenance sounds like machine learning. In reality, it was 80% data engineering: defining data models, ensuring quality, enriching context. The ML models were the easy part.
4. Team Coordination Is the Bottleneck
55 people: hardware engineers, firmware developers, backend developers, frontend developers, data engineers, compliance experts. The technical complexity was manageable. Coordination was the real challenge.
Business Perspective: What IoT Enables
The value stack isn't just technically relevant. It also defines business models:
| Approach | Description | Example from the project |
|---|---|---|
| Component Business | Selling individual layers | Gateways and sensors as OEM products |
| Solution Business | Offering complete solutions | Building-Automation-as-a-Service |
| Optimization Business | Improving internal processes | Reducing maintenance costs through predictive maintenance |
All three were realized in the project: hardware sales, SaaS platform, internal efficiency gains. The value stack was the foundation for all three revenue streams.
Conclusion
The IoT value stack is not a theoretical model. It's a decision framework for each layer:
- Physical Device: Build vs. Buy vs. Integrate
- Sensors & Actuators: Standardize vs. Build Adapters
- Connectivity: Edge vs. Cloud vs. Hybrid
- Analytics: Data Engineering before Data Science
- UI & Services: Generic vs. Audience-Specific
In regulated environments like building automation, there's an additional dimension: Every decision has compliance implications. CE/RoHS, functional safety, audit requirements.
The value stack wasn't the solution. It was the framework that asked the right questions.