A Horizontal Taxonomy for the Industrial IoT
3.4
Module Scale
Metric: more than 10 teams or interacting applications
Architectural Impact: Interface control and evolution
The second scale parameter we choose is the number of “modules” in the system, where a
module is defined as a reasonably independent piece of software. Each module is typically an
independently-developed application built by an independent team of developers on the
“project”.
Module scale quickly becomes a key architectural driver. The reason: system integration is
inherently an “n-squared” problem. Each new team presents another interface into the system.
Smaller projects built by a cohesive team can easily share interface specifications without
formality. Larger projects built by many independent groups of developers face a daunting
challenge. System integration can occupy half of the delivery schedule and most of its risk.
In these large systems, interface control dominates the interoperability challenge. It is not
practical to expect interfaces to be static. Modules, or groups of modules, that depend on an
evolving interface schema must somehow continue to interoperate with older versions of that
schema. Communicating all the interfaces becomes hard. Forcing all modules to “update” on a
coordinated timeframe to a new schema becomes impossible. Thus, interacting teams quickly
find they need tool, process, and eventually architectural support to solve the system integration
problem.
Of course, this is a well-studied problem in enterprise software systems. In the storage world,
databases ease system integration by explicitly modeling and controlling “data tables”, thus
allowing multiple applications to access information in a controlled manner. Communication
technologies like enterprise service busses (ESBs), web services, enterprise “queuing”
middleware, and textual schema like XML and JSON all provide evolvable interface flexibility.
However, these are often not appropriate for industrial systems, usually for performance or
resource reasons.
Data-centric systems expose and control interfaces directly, thus easing system integration.
Databases, for instance, provide data-centric storage and are thus important in systems with
many modules. However, databases provide storage for data at rest. Most IIoT systems require
data in motion, not (or in addition to) data at rest.
Data-centric middleware is a relatively new concept for distributed systems. Similar to a database
data table, data-centric middleware allows applications to interact through explicit data models.
Advanced technologies can even detect and manage differences in interfaces between modules,
IIC Journal of Innovation
- 35 -