Learn about the WSO2 reference architecture, and its extension to cover emerging architectures.
- [Narrator] The scope of IoT includes many different categories of devices, including wireless sensors, smart homes with their smart coffee machines and fridges, remotely-monitored fitness and medical devices, low-power embedded devices for water supply systems, internet-connected wearables, interconnected and driverless cars, smart transport systems, smart meters, and so on. Some commentators use the term Internet of Everything to highlight the fact that just about anything nowadays can have an embedded chip and be connected to the Internet.
However, despite the wide variety of different devices, there's a common high-level architecture evolving to represent the way in which they connect to and interact with upstream systems and users. While IoT may be projected to have a large impact on all businesses in society and while it may involve billions of devices being deployed, it isn't fundamentally different to any of the new technology. As we've seen, a business enterprise architecture is a structural representation of the elements of the enterprise and how they interact from the business level down to technology components, processes, and people.
The business security architecture is the risk view of the architecture which shows how elements of the enterprise architecture contribute to the way in which a business may succeed, or indeed, how it may fail. As IoT devices start to be deployed by an organization, They become one more technology within its enterprise architecture technology perspective and one more addition to the risk profile, and so, a part of the security architecture. The IoT Security Foundation has defined seven discrete domains or categories of things: consumer domestic devices which are also referred to as home automation, enterprise, including security and surveillance systems, industrial, particularly control systems, medical, both bedside and theater systems as well as worn and embedded patient technologies, automotive, in vehicle, municipal as well as national deployments, including smart city concepts, and critical infrastructures such as intelligent transport, power, and other utilities.
It's useful to look at these domains as having, at the top level at least, commonality in the pervasive characteristics of their IoT devices and systems. For example, it's clear that the medical IoT domain will involve a much higher risk to personal data than, say, an industrial plant manufacturing system. Likewise, the level of resilience required in a critical infrastructure system is likely to be much higher than that required by a home automation system. We can look at IoT from a service provider perspective, those organizations that provide the application and communications tiers of the architecture.
It's important to understand that this perspective has no concept of the business in which the service may be used and is not focused on delivering business success for the enterprise that uses the service. So we can consider the use of the IoT service to be a technical contribution to the business outcomes, the success or failure of the business activities, just like any other technology. And we can consider the enterprise business to be a contribution to the service provider's success or failure as a business in its own right which is influenced by how well the IoT service performs for the customer.
An IoT reference architecture has been proposed by Paul Fremantle of WSO2. This is a conceptual architecture and is inherently vendor neutral, although it's highly influenced by key open source projects and technologies. The architecture has at the bottom layer the sensors, actuators, and devices which provide data and respond to commands. Above this is the communications layer, providing the narrow band services, aggregation, and wide area connectivity required to allow transitive device data.
But services and aggregation may also be part of the local environment. The event processing and analytics layer takes the device data and transforms that to relevant information. These services may exist in the cloud or may be at the central point of data processing. Access to the data in its raw and transformed form would be via web portals and APIs. And dashboards may be used to provide visual monitoring of data flows and processing outcomes. The architecture also identifies where device management exists and the end-to-end scope of identity and access management.
This is a high-level reference architecture which provides a good start point for thinking about the wider IoT system at the technical level in a coherent and layered manner. As IoT services have started to be deployed, we can take a more informed view of the logical technology architecture. We have IoT data being processed and displayed via web portals and dashboards but also consumed directly into non-web applications. The data may be consumed directly from the Internet through an API or indirectly via a data store, quite often a big data repository of some form.
Connectivity to the applications layer is from an access network, typically the Internet, which provides gateways for devices to connect to in order to route their data to the correct application. The devices connect via their proximity network. It's these proximity networks that we often talk about as IoT networks. At the lowest layer, we have the IoT devices. These may be appliances such as fridges, cars, building systems, infrastructure, and so on which have their own purpose and now have embedded connectivity.
Or there may be special purpose sensors which exist purely to provide data for a separate application.
- Designing an enterprise architecture
- Architecting security
- Designing IoT security
- Domain specific architectures
- Proximity network services
- IoT application services
- Revised conceptual architecture