Reference Architectures and Open Group Standards for the Internet of Things – Architecting for the Internet of Things
This chapter introduces the Internet of Things (IoT), describes some essential concepts of Enterprise, Solution, and Product Architecture, and discusses how architects can use standards to define IoT systems, solutions, and products. The material is partly based on discussions at a Workshop held during The Open Group London event in April 2016 (the London Workshop).
The Internet of Things
Definition
The IoT is defined in different ways by different organizations. Of those represented in the London Workshop, ISO provides a definition of the basic concept, while the others focus on aspects of that concept and its use. For the purposes of this White Paper, the definition in the Draft ISO IoT RA, being developed by ISO/IEC JTC 1/WG 10, is assumed. The special focuses of the other organizations are noted as aspects of particular importance.
The Draft ISO IoT RA (as of 2015) defines the Internet of Things (IoT) as: “an infrastructure of interconnected objects, people, systems, and information resources together with the intelligent services to allow them to process information of the physical and the virtual world and react”.
Interestingly, this definition does not assume that the means of interconnection will be, or will include, the Internet. In practice, the Internet will form the principal means of interconnection between systems and information resources in different domains. The objects will often be connected locally to other networks, with gateways to but not part of the Internet itself. Note also that the definition assumes that people, as well as things, will play an important role, and that the processing and use of information is a key aspect.
Applications
The actual and potential applications of the IoT are many and varied. Those identified or suggested during the London Workshop are shown below. They form a very incomplete list, but give an indication of the wide scope of application of the IoT.
Participants in the IoT
Enterprises concerned with the IoT include: vertical area enterprises (manufacturers, municipalities, etc.), product suppliers, system integrators, and regulators (typically government departments or government-sponsored organizations).
Human actors within these organizations include: users, customers, owners, architects, designers, developers, operators, analyzers, and decision-makers.
Factors Inhibiting Take-up
While the scope of application is wide, and the value of networked sensors and actuators is generally realized, there are factors that are preventing or delaying take-up of the IoT. The following potential roadblocks were identified during the London Workshop:
- Complexity
- Lack of understanding, and differences of understanding of key concepts and vocabulary terms
- Overlapping, conflicting standards, given that a product may have to conform to an intersection of a number of standards
- Fear of new technology and the unknown
- Lack of an established and understood ethical framework
Value of Standards
Technical standards will not help to address all of the potential roadblocks, and cannot provide complete solutions to any of them.
Standards will not dispel fear of new technology, or provide an ethical framework, but they can reduce complexity, eliminating the confusion caused by unnecessary differences between implementations. This can only be achieved if overlap and conflict between them is avoided.
Standard terminologies can help people achieve common understanding. Reference architecture standards, in particular, can create a common language. Reference architectures that emerge as documentation of accepted common practice are valuable.
As well as mitigating some of the problems, standards can help increase take-up. They can:
- Enable interoperability between machines
- Accelerate the development of products and solutions
- Reduce development time and cost
- Improve product quality
Standards help break the market dominance of established large players, and allow new entrants, although they often arise because the large players do not wish to accept a single one of them becoming dominant. They prevent vendor lock-in and enable market choice.
While standards potentially have great value, a standard is only as good as its adoption. A standard that is not used and followed is of little worth.
Architectures
An architecture can be defined as:
- A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (Source: TOGAF 9.1).
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time (Source: TOGAF 9.1, Section 3.8 (Architecture).
The role of an architect is to contribute to the development and maintenance of architectures.
An enterprise is itself a system. Enterprise Architects contribute to the development and maintenance of Enterprise Architectures, and of architectures of smaller systems within the enterprises.
Scope of this White Paper
This White Paper is concerned with architectures of systems that include, in the words of the IoT definition, “interconnected objects, people, systems, and information resources together with the intelligent services to allow them to process information of the physical and the virtual world and react”. These systems can be enterprises, or can be smaller systems created by enterprises to support their operations. They can also be products or solutions created by other companies and supplied to these enterprises.
This White Paper is written for an audience that includes Enterprise Architects, Solution Architects, and Product Architects.
The Architecture Continuum
The Architecture Continuum, described in Section 39.4.1 (Architecture Continuum) of the TOGAF 9.1 standard and illustrated below, offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture and between architectures.
In this continuum:
- A foundation architecture consists of generic components, inter-relationships, principles, and guidelines that provide a foundation on which more specific architectures can be built.
- A common systems architecture guides the selection and integration of specific services from a foundation architecture to create an architecture useful for building common (i.e., highly re-usable) solutions across a wide number of relevant domains.
- An industry architecture guides the integration of common systems components with industry-specific components, and guides the creation of industry solutions for targeted customer problems within a particular industry.
- An organization-specific architecture describes and guides the final deployment of solution components for a particular enterprise or extended network of connected enterprises.
Many different types of architecture may occur at points of the continuum between those illustrated in the figure.
Reference Architectures
A reference architecture is a generic architecture that provides guidelines and options for making decisions in the development of more specific architectures and the implementation of solutions. A reference architecture can be at any point of the architecture continuum.
Models
A model provides a smaller scale, simplified, or abstract representation of the subject matter. In the context of Enterprise Architecture, the subject matter is a whole or part of the enterprise and the model is used to construct views that address the concerns of particular stakeholders. Models often show components and the relationships between them. For the IoT, an architect will also often use behavioral models that are not necessarily component-based.
Architectures for the IoT
Common Systems Architectures
The IoT is a generic problem domain. As such, it is an appropriate subject for common systems architectures. A common systems architecture reflects requirements specific to a generic problem domain.
Possibilities for common cross-industry standards include:
- Vocabularies
- Models
- Protocols
- APIs
- Capabilities
Industry Architectures
At the next level of the continuum, the questions arise of whether each vertical industry requires a separate IoT architecture, and how far a single model or architecture can apply across vertical sectors.
At the business and application levels, there are clearly differences between vertical sectors. Different industries have different business models, different process flows, and different regulatory environments. Business and application architectures can benefit from industry reference models. This is not necessarily the case at the technical level.
IoT applications can have particular technical constraints. For example, in some engineering applications, sensors are buried in concrete with limited power supplies and relatively low processing capabilities. These are expected to deliver reports without disclosing information publicly, but may not be able to support computation-intensive features such as encryption.
One way of addressing this problem is to distinguish between full-function and limited-function devices, and to have limited function devices communicating with gateways that can support full-function messaging. A reference model could be developed using this approach. Such a model could, however, not be regarded as a reference model for the engineering industry sector, because many engineering applications do not have this constraint, but some applications in other vertical areas do have it. For example, containers used for shipping perishable goods may incorporate sensors to record the temperatures encountered, where those sensors have no separate power supplies.
A major IoT application area such as smart cities typically covers a multitude of different use-cases. For example, some of the smart city use-cases addressed by the bIoTope Project are shown below.
Architects must understand their use-cases when looking at different architectures, and not assume that a generic model will apply to them. An analysis of characteristics can show which reference architectures and models are appropriate.
The Reference Architecture Model for Industry 4.0 (RAMI 4.0) provides a good example of an industry reference architecture. It has one dimension that is generic, and adds two further dimensions that address considerations specific to the manufacturing industry.
Models for Characteristics
There may be value in cross-industry models that address particular use-case characteristics. Characteristics that might be addressed in this way include the following. They were identified in discussions at the London Workshop. Other lists of characteristics can be found in the Draft ISO IoT RA, which contains a chapter on Characteristics of IoT Systems, and the IIRA, which contains a chapter on Key System Characteristics and their Assurance.
- Particular physical properties of things monitored or controlled
- Power supply constraints
- Connectivity topologies
- Connectivity continuity
- Interaction patterns
- Time-criticality
- Data size
- Requirement for privacy
- Requirement for data integrity
- Requirement for safety
- Requirement for archiving
These characteristics are not industry-specific. The vertical industry gives context, but does not define the characteristics of the system. Industries often define markets, but products can be common across them.
Developing Architectures for IoT Systems and Solutions, and Products
The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.
An architecture description is a collection of artifacts that document an architecture. In the TOGAF standard, architecture views are the key artifacts in an architecture description. In capturing or representing the design of a system architecture, the architect will typically create one or more architecture models, possibly using different tools. A view will comprise selected parts of one or more models, chosen to demonstrate to a particular stakeholder or group of stakeholders that their concerns are being adequately addressed in the design of the system architecture.
In developing views, and architecture artifacts generally, re-use of appropriate and good-quality existing artifacts is good practice. It will often be possible to create the required views for a particular architecture by following these steps:
- Refer to an existing library of viewpoints.
- Select the appropriate viewpoints (based on the stakeholders and concerns that need to be covered by views).
- Generate views of the system by using the selected viewpoints as templates.
The Draft ISO IoT RA, the IIRA, RAMI 4.0, and the Web of Things include good-quality artifacts related to viewpoints that are appropriate for the IoT. They are available to architects for reference, as are other relevant artifacts such as the IoT Basic Architecture Models of the Open Platform 3.0 Snapshot, or the information models of OneM2M.
The next chapter contains a comparison of the Draft ISO IoT RA, the IIRA, RAMI 4.0, and the Web of Things, to help architects understand which of the artifacts of these reference architectures could be appropriate to their architecture developments.