CUTTER BUSINESS TECHNOLOGY JOURNAL,  VOL. 29, NO. 12
  

Internet of Things (IoT), smart cities, wearable devices, and virtual reality are some information and communications technology (ICT) buzzwords that are making the boundaries between reality and fiction vanish. According to Mark Weiser, the father of ubiquitous computing:

The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.

While this weave is already happening through smart fabrics, for example, we expect that IoT (or “things” for short) will transparently blend with the know-how of enterprises commonly referred to as business processes (BPs). Although the ICT community considers the task the basic unit of work that implements a BP, the next trend is to allow things to be in charge of this implementation by forming ad hoc (i.e., on-the-fly/opportunistic) collaborative groups. This should happen through the concept of Process of Things (PoT), which will:

• Guide the identification of things according to their capabilities

• Allow things to take over new capabilities (i.e., mutation)

• Facilitate the connection (and disconnection) of things through socially flavored relations

• Incentivize or penalize things in response to their positive or negative participation in processes

PoT is the new way of tapping into the worlds of IoT and BP. PoT ensures that things will not function as silos but contribute collectively to offering value-added services to enterprises such as developing smart applications around connected things and reaching out to more customers through adaptable things. Predefined relations between things (e.g., parental, colocation, ownership) will support the development of networks of (privileged) contacts so that a thing can:

1. Contact other things for possible connection in these networks

2. Avoid conflicts with existing things in processes

3. Recommend other things for either inclusion in or exclusion from processes based on past experiences

The ICT community is already building the Social Internet of Things (SIoT) using social relations among things (not among their owners) and is stressing the importance of exploiting these relations in developing smart applications. In a PoT, capabilities will prescribe a thing’s duties once it becomes activated and, thus, ready to form collaborative groups with other things. Capabilities would include sensing, storing, processing, diffusion, and reporting, with the option of combining them (e.g., sensing-and-processing).

Despite the ICT community’s interest in blending social computing with IoT, a good number of challenges and open issues that emerge out of this blend remain untackled. This includes defining a social-thing architecture, addressing the interoperability of things, discovering things, managing energy consumption of things, and handling the security, privacy, and trust of things, to cite just a few. On top of these challenges and issues, it is important to examine the on-the-fly com­bination of things, taking into account their dynamic capabilities and end users’ dynamic requirements. A PoT should have an operation model that inventories things according to a particular context (e.g., meeting room) and capitalizes on relations between things to expand this model.

Business Processes, Old and New

Enterprises and/or IT practitioners will raise the question of how a PoT compares to a regular process of tasks. There are some similarities:

• Just as a process of tasks has a business logic defining who does what, when, and where, a PoT will have a “story” that defines the necessary things along with their capabilities and connections to other things. To develop such a story, enterprises will need a Thing Definition Language (TDL) and a Thing Connection Language (TCL). Both languages could be built upon the W3C semantic sensor network ontology after enrichment with additional properties that describe context-based social relations between things.

• Like dependencies between tasks in processes, a PoT will count on capacity-driven relations between things, such as precedence (washing machine then dryer), complementarity (coffee machine and toaster), “antagonism” (VCR and DVD), and competition (a new fridge that could replace an existing one). Relations will be context-sensitive and based on the purpose of the future PoT.

And there are some differences:

• Contrary to a process of tasks whose runtime instantiation leads into several process instances that could run concurrently, instantiating the same PoT several times could call for different things depending on their capabilities and availabilities.

• Unlike a process of tasks whose tasks are known in advance, a PoT will have a set of core things (also known in advance) and a set of optional things that are part of these core things’ networks of contacts. Upon the recommendation of the core things, optional things can be added to a PoT, subject to the enterprise’s approval of the additional cost. Needless to say, dropping a core thing from a PoT results in dropping all of its optional things.

We believe it is necessary to differentiate between the social Internet of things and the Internet of social things. On the one hand, in the social Internet, things are configured and controlled in preparation for their integration into specialized networks built upon specific relations like those mentioned above. On the other hand, a social thing will be empowered with the capabilities needed for tapping into the opportunities of these networks, such as looking for partners, avoiding partners, forming alliances with partners, and so on, based on past experiences.

Capabilities in Context

To run a PoT, enterprises will have to define contextual boundaries of the future thing-based applications. These boundaries will identify the things that are willing to participate in these applications, taking into account their ongoing commitments and available capabilities. As stated above, each PoT execution can call for different things, since new things could emerge and existing things could, at any given moment, either cease to exist or change their priorities in supporting application development.

An example of a PoT could be a heating system that relies on sensors, actuators, and other devices to ensure comfortable living conditions for people. Mapping the heating system onto a PoT would require scanning the environment to detect things in terms of availabilities and capabilities, defining relations between things, and putting appropriate things together in response to specific requests such as maintaining a certain temperature level. Of course, it is vital to secure each PoT, as hacked things could lead to catastrophic consequences. In a PoT, things are parts of networks, and thus hacking one thing will give free access to the remaining things in these networks. The success of PoT will depend on enhancing things with the necessary capabilities to support them in securely building networks of contacts, responding to users’ needs proactively, and — last but not least — questioning our ways of thinking about things.