This note is still with a touch of AI, will rewrite this one soon, sorry!
Solutions vs. Technology
Solutions: These are specific software and hardware products that are fixed and bound to a particular system. Examples include ERP systems that aim to be all-in-one solutions, leading to data being siloed and limiting interoperability. This also applies to hardware providers and vendors in vertical integration scenarios, such as machine makers in metalworking that provide both software and machines but don’t work well with other systems. Any software that is closed source and doesn’t allow full integration via modern standards like APIs and especially MQTT is considered a closed solution.
Technology: This focuses on connectivity and integration, meeting Minimum Technical Requirements (MTR) and enabling Industrial IoT (IIoT) connections. It involves creating an infrastructure that supports flexible, scalable, and interoperable integration of various devices and systems, allowing for greater adaptability and innovation.
Further reading
Some great stuff has been said in a video by Walker Reynolds: “Why your Industry 4.0 Applications are NOT scaling”
Highlights / Quotes
"Industry 4.0 applications struggle to scale because many companies use a solution-driven approach instead of a technology-driven one."
“If I’m solution-driven, I limit my initiatives to the suite of solutions or products available within that solution.”
“Using the Industry 3.0 approach with discrete connections is a solution-centered approach that doesn’t scale well for IIoT or Industry 4.0 solutions.”
“Solution-driven approaches, like those of Rockwell, Siemens, or Schneider, rely on vertically integrated products that work well together. However, they don’t integrate easily with non-partner products, limiting flexibility and scalability.”
Note
Same goes for machines, software and many providers in the metalworking industry. E.g. a machine of brand A does not talk well to machine B and so forth.)
“Our technology-driven approach involves designing a technology stack based on some Minimum Technical Requirements (MTR): report by exception, edge-driven, open architecture, and lightweight.”
Transcript (Edited for Readability)
One key piece you need to learn is to be technology-driven, not solution-driven. If I’m solution-driven, I limit my initiatives to the suite of solutions or products available within that solution. The second you do that, you’ve essentially restricted your flexibility. Think of it as nailing your furniture to the floor—it’s functional, but you can’t move it around.
[..]
The Industry 3.0 way of solving problems involves creating discrete connections:
- Connect the PLC to the HMI or the OPC server.
- Connect the HMI to SCADA.
- Connect the PLC to SCADA, SCADA to MES, MES to ERP, and ERP to the cloud.
This is a solution-centered approach because you need to understand the individual software and hardware solutions used at each layer to connect everything.
People often buy all solutions from Rockwell, for example, to ensure compatibility within their “Connected Enterprise.” However, no plant uses just one manufacturer’s solutions. Using a non-partner product with Rockwell’s system involves significant labor and time.
Every manufacturer follows this workflow: sell, plan, execute manufacturing (MES, SCADA, PLC, HMI), inventory, ship, order materials, invoice, get paid, and repeat.
Using the Industry 3.0 approach with discrete connections is a solution-centered approach that doesn't scale well for IIoT or Industry 4.0 solutions.
So, what’s the difference between solution-centered and technology-centered approaches?
Our technology-driven approach starts with the requirements for the technology, not just the customer’s needs.
Traditional integrators inventory existing solutions and plan to connect them. This involves understanding and integrating specific solutions (ControlLogix, Kepware, MES, etc.).
Solution-driven approaches, like those of Rockwell, Siemens, or Schneider, rely on vertically integrated products that work well together. However, they don’t integrate easily with non-partner products, limiting flexibility and scalability.
Our technology-driven approach involves designing a technology stack based on some basic requirements:
- Report by Exception: Only report changes in data, not unchanged values.
- Edge-driven: Smart devices push data instead of being polled, improving scalability and efficiency.
- Open Architecture: Use accessible technology standards so any device can connect.
- Lightweight: Ensure the technology doesn’t overload the network.
For example, we often use MQTT 3.1.1 and Sparkplug B standards for industrial data, which support open architecture and efficient data handling. A unified namespace acts as a single source of truth for all data, with all nodes producing and consuming data.
In a recent project with a large enterprise, we evaluated existing solutions and integrated those that met our technology stack requirements. This technology-driven approach allows for short time to value and easier integration of new solutions.
When moving from solution-driven to technology-driven, we avoid being locked into specific solutions, like Rockwell’s Connected Enterprise, and instead focus on meeting our technology requirements for scalability and flexibility.
Real-world example: We integrated a new plant into a customer’s unified namespace within 30 seconds during a demo, showcasing the power of a technology-driven approach. This impresses clients and highlights the scalability and efficiency benefits.
To summarize, being technology-driven means setting technology standards and ensuring all solutions meet these requirements, allowing for flexibility and scalability in digital transformation projects.