Keywords

1 Introduction

Organizations increasingly shift to agile forms of work, pushing for fully digitized workplaces. ‘The average work day is becoming filled with employee-facing technologies that are transforming how work gets done. Organizations that help their employees become more agile, inclusive and engaged are in an excellent position to use emerging technologies to drive competitive advantage. Competitive advantage for 30% of organizations will come from the workforce’s ability to creatively exploit emerging technologies.’ ([9], p. 1).

Recognizing the engagement of operational stakeholders as nucleus of continuous change and evolution means to push them into the role of (re-)designers and development engineers, once emerging technologies, such as the Internet of Things (IoT), algorithmic decision making, and deep learning become integral part of their work. Binding individual activities increasingly to digital actions through these technologies leads to an “Internet of Behavior” (IoB) ([28], p. 1) as follow-up to the Internet-of-Things (IoT) ([21], p. 2). Consequently, behavior data direct activities of socio-technical systems in real time, encouraging or discouraging human behavior. For instance, a home healthcare support system can adapt its behavior to the situation at hand based on received sensor data, and trigger specific actuator behavior based on algorithmic processing and data analytics. This trigger could lead to adjustments of human behavior, e.g., taking care of a certain order of using healthcare appliances (cf. [35]).

Hence, the design of IoB systems based on behavior (specifications) is a moving target. As such, it is an immanent and pervasive engineering task. It requires technical and technological capabilities, when ‘by 2023, 40% of professional workers will orchestrate their business application experiences and capabilities like they do their music streaming services’ ([28], p. 4). Due to their cyber-physical nature – they are based on the IoT – IoB systems require a model representation (termed digital twin) as baseline for continuous design-integrated engineering (cf. [25]). This paper aims to define and design such a scheme. It should enable the dynamic arrangement of networked behavior encapsulations, and thus, represent an operational framework of informed and continuous transformation. Thereby, transformation should be able to utilize IoB data for predictive analytics. Recent results indicate for specific domains the utility of algorithmic data analytics (cf. [38]). However, we rather target opportunistic IoB system behavior (cf. [17]), building on mutual actor awareness (cf. [15]) and value-based co-creation (cf. [30]), than unidirectional control of stakeholder behavior (cf. [31]).

Section 2 provides the methodological background of the study. Design Science-based Research has been used to generate the findings in this paper. Section 3 provides fundamentals of IoB system design and thus leads to the requirements to be met by the choreographic transformation scheme. Section 4 introduces the scheme from a methodological and representational perspective. Intelligence for transformation is identified through a value-stream analysis, and followed by subject-oriented refining and adapting of Behavior-encapsulating Entities and their mutual interaction. The approach is exemplified through a field study of home healthcare, involving various stakeholders and IoT devices. Section 5 concludes the paper.

2 Methodology

In this section, the Design-Based Research procedure is explained, detailing the steps of the presented work. Design Science has attracted attention increasingly for the last decade (cf. [6, 19]). Its dual while iterative nature with respect to design artifacts and design theory equally supports practical development and conceptual understanding.

The Relevance Cycle (Fig. 1) applied to the objective of this work connects the environment of the IoB implementation project with its core development activities. The Rigor Cycle relates these activities to a knowledge base informing the project. The Design Cycle iterates between the core development activities (building and evaluating artifacts). This intermediate position ensures on one hand that artifact development remains in the context the process started, and on the other hand, that each development cycle is informed by scientific theories and domain-specific practice, and the results can be documented in a structured form. Each design cycle result can be traced back to its starting point and related to previous design cycles. In this way, each step in developing the IoB transformation space becomes transparent.

Fig. 1.
figure 1

Design cycles embodied in pragmatic and methodological context (according to [19]).

Full size image

The original Design Science framework has been operationalized by Peffers et al. [29]. It captures the development stages as shown in Fig. 2: (i) identification of the problem, (ii) definition of objectives for a solution, (iii) design and development of artifact, (iv) demonstration of artifact use to solve the problem, (v) evaluation of the solution, (vi) communication of achievements:

Fig. 2.
figure 2

Design-science based approach to IoB implementation as transformation space

Full size image
  1. 1.

    Identification of object and motivation: The research problem needs to be identified and the value of a solution needs to be justified. So far, the concept of IoB has been specified and promoted by strategic foresight rather than elaborated development requirements. For structuring development, IoB value drivers and properties need to be elaborated. Since the IoB is based on the IoT that are part of Cyber-Physical Systems, digital models (‘twins’), and thus modeling needs to be addressed. They serve as baseline for organizational transformation, in particular through dynamic adaptation and predictive analytics.

  2. 2.

    Definition of objectives for a solution: The solution needs to facilitate dynamic transformation of organizations through informed IoB developments supporting business operation. Developers can design digital models (‘twins’) in the course of transformation, and utilize them for execution (operation), dynamic adaptation and behavior prediction. Particularities of industrial developments, such as Industry4.0 (https://www.plattform-i40.de/) and related system architectures, e.g., of Cyber-Physical Production Systems, need to be recognized and taken into account.

  3. 3.

    Demonstration: Each Design Science cycle uses the current version of the artifact to exemplify whether and how the addressed problem is solved in practice. In our case, a home healthcare scenario is selected due to its technological and organizational IoB fit, and existing findings with respect to the applied solution concepts (see Complex Adaptive Systems and subject orientation related to the transition between Definition of Objectives of a Solution and Design & Development in Fig. 2).

  4. 4.

    Evaluation: In each of the Design Science cycles the current solution is evaluated, based on the objectives and the requirements developed so far. It is checked whether the results from the use of the artifact in the demonstration case meets the requirements. As the directed backward links from Evaluation indicate, either the artifact requires further refinement and/or adjustment, or the objectives need to be reconsidered in terms of revisiting the conceptual foundation of the approach, before a new design cycle can be started.

  5. 5.

    Communication of all collected information and achievements, including the problem, the artifact, its utility and effectiveness to other researches and practitioners. It feeds to the Knowledge Base (see Fig. 1), and enables a complete picture of findings through the Rigor Cycle. Both, conceptual and experiential findings, are captured, allowing for reflecting on the process of finding a solution (i.e. meta-findings).

The result of the Design Science cycles is always a purposeful artifact. In our case it is an operational framework, i.e. a procedure involving IoT technology and methodological support (tools) to achieve an effective IoB implementation through organizational transformation. Like many Design Science projects the endeavor finally focuses on social systems and their members. The outcome of this work will be used by individuals applying IoB-concepts for organizations. Focus of their work is the interaction between people and technological products, and the representation of working IoB systems featuring human understanding and intelligibility. Human design activities are integrated with engineering ones, leading to a design-integrated IoB engineering approach to developing a solution. Whenever evaluation is performed, (previous) experiences, needs/requirements, conventions, and standards form the basis of reflection and further design.

In the following section, the requirements for a design-integrated engineering solution are detailed revealing the addressed socio-technical nature of IoB systems. It documents the results achieved in step 1 and 2 of the Design Science framework. Section 4 provides the result of running several Design Science cycles (step 3–5) to define the operational IoB framework, i.e. how to establish an organizational transformation space based on behavior specifications.

3 IoB Solution Requirements

When aiming to identify meaningful behavior patterns, the IoB, analogous to the IoT, provides an Internet address for behavior patterns. It enables accessing systems or addressing individuals engaged with a specific behavior. Such a connection can be used in various ways and directions, for data delivery, joint processing, or taking control. Like for IoT, the power of IoB is the scale that matters. Several billions of systems and/or actors and thus, behavior patterns populate the network and represent a unique source of collecting data and passing it on for processing, controlling, and thus, influencing behavior through generated information.

Figure 3 aims to categorize the technological advancements that are characteristics of IoB developments on the left side, and to develop a corresponding behavior perspective on the right side. After introducing IoT on an elementary or syntactic level, system components have been captured by semantic technologies which enabled contextual process design. Turning passive actors to active ones, and adding intelligence to system components has led to self-organizing actors, which allowed the emergence of novel system behavior [16] referring to the self and future developments.

Fig. 3.
figure 3

IoB conceptualization with design intelligence

Full size image

Complex Adaptive Systems [20] focus on the interdependence of behaviors. The concept raises awareness for the consequences of individual acting on other actors or system components, as individual acting influences the activities of other actors in the system. In this way, self-referential interaction loops develop in a specific system. Understanding such a system mechanism helps in the development of predictive analytics, since behavior can be anticipated based on the history of individual action and received inputs from other actors driven by those actions.

From this conceptualization two requirements for operational organizational transformation can be derived:

  • (REQ 1) Design elements need to encapsulate behavior. They need to be considered the fundamental unit of design and engineering.

  • (REQ 2) IoT fundamental to IoB requires a socio-technical approach, thus taking into account the interaction between behavior entities. Exchange (i.e. bi-directional) relations enable to capture the impact certain behavior of a single entity can have on a system (cf. Complex Adaptive Systems).

From an operational perspective, IoB systems are based on Internet-based connected technologies. Thereby, the IoT architecture serves as baseline and is represented traditionally as a stack (see Fig. 4). IoT-based architectures facilitate interaction and data exchange between systems, their components, and users. They take into account the business perspective as well as the environment of an IoB system influencing its use and the behavioral integration of its components. Comprehensive architectures frame data management and runtime issues, including access regulations and flow of control for developers.

Fig. 4.
figure 4

The IoT stack (according to [23]) as baseline to design-integrated engineering

Full size image

The core elements of IoT systems are positioned on the bottom of the stacked architecture. It comprises the sensor components and the software managing them (Asset part) as integrating software and hardware allows for embedded system design. Architecture components connected with the Asset are Internet components to share all kinds of collected data. They ensure connectivity of networked assets and the exchange of data. The logic to manage collected data and their transmission for processing is operated in the Cloud. Cloud computing services allow omnipresent and scalable access and distribution of system features. They comprise storing data in a database, applications and platforms to run services, rule engines to enforce (business) regulations, and analytics to generate decision-relevant information. Finally, all elements need to be related to the context of an application. It contains all relevant information for design and operation (termed external information in the stacked architecture). Another frame of the stack components is composed of overarching performance-relevant topics, in particular authentication and security. Both affect the interactive and automated use of architecture components, and thus, running the overall system.

It is the upper part of the stacked architecture injected by external information that is crucial for design-integrated engineering (see Fig. 4). At some point in time, stakeholders acting in specific roles need to access the IoT system, triggering data collections or interpreting the results of analysis. They also need to know the involved component for developing and maintaining the IoT technologies, either directly or via a corresponding model (digital twin). Consequently, the following requirements need to be met:

  • (REQ 3) IoB designers (including operational workforce) model IoT components the same way as their work tasks or business processes.

  • (REQ 4) For design-integrated engineering, models should be executable, in order to provide direct feedback to stakeholders in their role as system designers.

The ongoing proliferation of connected system components drives current application development and propagation in large domains, such as healthcare (cf. [8]), and production industry (cf. [13]). Large capabilities for intelligent system design are enabled by autonomous data collection through sensor systems, as well as the dynamic adaptation and remote control of devices through actuators. When using the Internet as basis of so-called smart services (cf. [7]), physical objects, such as shoes, are augmented with Internet-based functions, extending their capabilities, e.g., signaling the possibility of exhaustion. The provision of such services is based on the recording of sensors and operational data, the transmission via digital networks, as well as the interpretation and delivery of analysis results, e.g., via smartphone apps.

When products originally designed for a specific use get enriched in scope, the design process needs to take into account further services and processes. Consider clients of a home healthcare appliance with smart shoes who are provided with health intelligence according to their individual use of the product. Design tasks need to encounter further components for interpretation, leading to (dynamic) adaptation of an IoB system. It enables novel relationships between stakeholders (in particular between producers and consumers) and components, intermingling their role through operation and utilization (cf. [24]). Hence, design-integrated engineering should take into consideration dynamic adaptation, such as

  • Use case or even business model development based on an enriched use of IoB systems, services, or collected data, e.g., [4]

  • Revisiting product lifecycles, e.g., [14]

  • ‘Smartification’ of traditional industrial products, e.g., [32]

Although these efforts contribute to the overall goal of higher market and customer orientation, there is only fragmented knowledge on how to systematically inform designers when developing IoT-based systems (cf. [18, 36]). Besides indications that design-integrated engineering could profit from Software Engineering embedded system analysis and design (cf. [18]), design modeling has to meet the following requirement of dynamic adaptability of system behavior:

  • (REQ 5) Adaptation capabilities need to be captured in a generic, however, context-sensitive form.

The following section demonstrates how the specified requirements of a solution can be met by utilizing existing concepts stemming from Value Network Analysis [3] and Subject-oriented Business Process Management [10].

4 Transformation Space Design

This section provides the results of iterating several Design Science cycles (see step 3–5 in Fig. 2) to define the operational IoB framework as subject-oriented transformation space. As methodological entry point, IoB systems are considered as Complex Adaptive Systems and analyzed according to value streams between Behavior-encapsulating Entities as described in the first sub section. The resulting map can be refined from a function and communication behavior perspective. Thereby, Subject-oriented Business Process Management (S-BPM) and its choreographic representation schema play a crucial role: Enriched S-BPM models form the baseline for design-integrated engineering, as shown in sub Sect. 4.2, following the value stream analyses presented in sub Sect. 4.1. The resulting models can be enhanced for dynamic adaptation and prediction of behavior, utilizing existing S-BPM features (see sub Sect. 4.3).

4.1 Value Stream Representation and Analysis

This section reports on the results for meeting REQ 1 and REQ 2, looking for artifacts based on behavior entities and their interaction. This type of entity constitutes the design space for transformation, engineered for putting IoB applications to operation, and for linking them to predictive analytics:

  • Design elements encapsulate behavior. They represent the fundamental unit of design and engineering (cf. REQ 1).

  • IoB is a socio-technical system design approach due to the underlying IoT. It takes into account the interaction between behavior entities. Exchange (i.e. bi-directional) relations refer to the impact a certain behavior of an entity has on system behavior (according to Complex Adaptive Systems theory) (cf. REQ 2).

Methodological intervention is based on operational business knowledge and its structured representation of value streams between involved stakeholders, and between support systems and the stakeholders (cf. [5]). Recognizing support systems as design elements equal to stakeholder roles the approach enriches Value Network Analysis (VNA) originally introduced by Allee [3]. However, the exchange of deliverables as patterns of acting and receiving feedback is still at the focus of transformation. VNA is meant to be a development instrument beyond engineering, as it aims to understand organizational dynamics, and thus to manage structural knowledge from a value-seeking perspective, for individual stakeholders and the organization as a whole. However, it is based on several fundamental principles and assumptions of Complex Adaptive Systems that are shared in the proposed transformation space design as value network [1,2,3]:

  • Network nodes (IoB elements) encapsulate legitimized behavior, i.e. human, digital, semi-digital, or trans-human actors, process information and contribute values to the network, and thus to an organization.

  • A value contribution is a transaction meaningful in relation to the system as a whole, even though it occurs between two nodes.

  • Network nodes, and thus an organization operates in a highly dynamic and complex setting. In their socio-technical nature they are self-regulating and self-managing entities.

For self-organization to happen, stakeholders need to have an understanding of the organization, and its behavior as a whole. Since the behavior of autonomous stakeholders cannot be predicted fully, organizations need design representations and design support to guide behavior management according to the understanding of stakeholders and their capabilities to change their behavior (cf. [27, 34]).

The proposed VNA-variant builds upon patterns of interaction as design elements for analysis and refinement to operation. An organization is a value stream network represented as self-adapting complex system, which is modeled by identifying patterns of interactions representing relations between behavior-encapsulating entities (BeE) as nodes of the network. Each BeE in a certain organizational role produces and delivers assets along acts of exchange (transactions).

Since transactions denote organizational task accomplishment through exchanges of goods or information, they encode the currently available organizational intelligence (determining the current economic success). They can be modeled in concept maps [26], according to the following guidelines:

  • Each nodes represents a BeE, i.e. an organizational role of an IoB element.

  • BeEs send or extend deliverables to other BeEs. One-directional arrows represent the direction in which the deliverables are moving in the course of a specific transaction. The label on the arrow denotes the deliverable.

Each transaction is represented by an arrow that originates with one BeE and ends with another. The arrow represents the transmission and denotes the direction of addressing a BeE. Deliverables are those entities that move from one BeE to another. A deliverable can have some physical appearance, such as a document or a tangible product, or be of digital nature, such as a message or request for information.

The concept of exchange is considered a bi-directional value stream: An exchange occurs when a transaction results in a particular deliverable coming back to the originator either directly or indirectly. It ranges from feedback on a BeE deliverable to a new request ‘for more of the same’, or to a change of behavior. Exchanges reveal patterns typical of organizational relationships, e.g., goods and money.

In the following we exemplify a BeE map for home- and healthcare involving a service company providing innovative instruments (methods and technologies) for customers with specific healthcare needs. The IoB system should help tracking a person’s blood pressure, sleep patterns, the diet, blood sugar levels. It should alert relevant stakeholders to adverse situations and suggest behavior modifications to them towards a different outcome, such as reducing blood pressure through a different diet, or reducing the dose of pills for the sake of daytime agility. Moreover, the system should provide every-day convenience, in particular alerting for timely healthcare and medical supply.

The BeE map helps scoping the design and transformation space and leverages potential changes for each BeE. Accurate service provision for wellbeing of a customer in home- and healthcare is the overall goal of the exemplified IoB system. It monitors health- and living conditions to continuously improve service provision.

The first step designers need to consider in the modeling process is the set of organizational tasks, roles, or units, as well as functional technology components and systems that are considered of relevance for service provision. They represent BeEs, and include the IoT devices Blood Pressure Measurement, Sleep Pattern Monitoring, Diet Handler, Medication Handler, and the Personal Scheduler, as well external medical services. Each of the identified roles or functional task represents a node in the BeE network which is partially shown in Fig. 5.

Fig. 5.
figure 5

Part of a BeE-map scoping and structuring the transformation space

Full size image

According to Verna Allee [2, 3], analyzing the capabilities of a value-driven network and developing opportunities for constructive transformation requires an initial assessment of the structure and transactions of the represented system as a whole. Designers need to perform an exchange analysis targeting (i) the overall objective of the organization in terms of value streams, and (ii) the question: What is the overall pattern of exchanges in the represented system?

In the course of this analysis, designers investigate the overall pattern of interactions addressing a variety of structural issues. When starting to identify missing relations for operating the business or links requiring a rationale, potential breakdowns in flow that can be critical for the business can be determined. In that context, the coherence of relations and resulting flows of how value is generated in the network can be evaluated. For successful operation, an end-to-end value stream (i.e. a set of adjacent transactions) should be identified representing how the organizational objective is met. For instance, for home healthcare, the value stream should contain sequences of transactions that contribute to the well-being of clients in term of preventing adverse conditions.

The overall pattern of reciprocity reveals involvement data of the BeEs (as perceived by the respective modeler). Extensive sources and sinks of interactions should be noted as potentials for optimizing the entire network, avoiding specific BeE benefitting at the expense of others.

In the BeE map in Fig. 5, a specific pattern can be noticed. The Medication Handler triggers Blood Pressure Measurement, involving the Personal Scheduler to start in time. In the network without dotted transactions, Blood Pressure Management is a sink of information. Hence, in order for information not to result in “dead ends”, information on blood measurement needs to be passed on explicitly to the Medication Handler and Personal Scheduler. In this way significant knowledge can be exchanged and further action can be designed in case of adverse conditions.

At this stage of design, exchange relations can be added, as indicated by the dotted transactions in Fig. 5. In the simple example, Blood Pressure Measurement should be in exchange relations to the Medication Handler and Personal Scheduler, as the medication could be adapted optimized according to time and current condition of the client. It needs to be noted, that this is a semantically grounded supplement requiring systemic domain knowledge and human intervention, in contrast to syntactically checking whether each BeE interacts with all others in the network.

4.2 Subject-Oriented Refinement and Runtime Completion

In this section we proceed with refining design representations, such as the BeE map, towards digital models of IoB systems serving as baseline for engineering. The presented approach refines BeE maps from a function and communication behavior perspective, utilizing the choreographic representation and engineering scheme from Subject-oriented Business Process Management. It enables embodying BeE maps and refines the involved (socio-technical) components, thereby generating digital twins. In this way REQ 3 and REQ 4 (see Sect. 3) are addressed:

  • IoB designers (including operational workforce) are able to model IoT components the same way as their work task or business processes (REQ 3).

  • For design-integrated engineering, models can be refined until being executable, in order to provide operational feedback to designers (REQ 4).

Subject-oriented modeling and execution capabilities (cf. [10, 12]) view systems as sets of interacting subjects. Subjects are defined as behavior encapsulation. As they address tasks, machine operations, organizational units, or roles people have in business, they correspond to the Behavior-encapsulating Entities (BeEs) defined for analyzing value streams in the previous section. From an operational perspective, subjects operate in parallel. Thereby, they exchange messages asynchronously or synchronously. Consequently, the transactions forming value streams can be interpreted as transmissions of messages between subjects.

IoB systems specified in subject-oriented models operate as autonomous, concurrent behavior entities representing distributed (IoB) elements. Each entity (subject) is capable to performing (local) actions that do not involve interacting with other subjects, e.g., calculating a threshold value of blood pressure for a measurement device in medical care. Subjects also perform communicative actions that concern transmission of messages to other subjects, namely sending and receiving messages.

Subjects as behavior encapsulations are specified in adjacent diagrams types: Subject Interaction Diagrams (SIDs) and Subject Behavior Diagrams (SBDs). They address different levels of behavior abstraction: SIDs a more abstract one, denoting behavior entities and an accumulated view on message transmissions, and SBDs refining the behavior of each subject of a SID by and revealing the sequence of sending and receiving messages as well as its local actions (i.e. functional behavior).

SIDs provide an integrated view of an IoB system, comprising the subjects involved and the messages they exchange. A part of the SID of the already introduced home- and healthcare support system is shown in Fig. 6. According to the BeEs in Sect. 3, it comprises several subjects involved in IoT communication. In the figure the messages to be exchanged between the subjects are represented along the links between the subjects as rectangles, already including the supplemented ones from the value stream analysis:

Fig. 6.
figure 6

Sample Subject Interaction Diagram representing a home healthcare appliance

Full size image

  • The Personal Scheduler (subject) coordinates all activities wherever a client is located (traditionally available on a mobile device).

  • The Medication Handler takes care of providing the correct medication at any time and location.

  • The Blood Pressure Measurement subject enables sensing the blood pressure of the client.

  • The Shopping Collector contains all items to be purchased to ensure continuous quality in home health care.

The client handles the measurement device and needs to know, when to activate it and whether further measurements need to be taken. The Shopping Collector receives requests from both, the Medication Handler when drugs are required from the pharmacy, physician, or hospital, and the Personal Scheduler, in case further medicine for the client is required.

State transitions are represented as arrows, with labels indicating the outcome of the preceding state. The part shown in Fig. 7 represents a scheduling request to the Personal Scheduler subject sent by the Medication Handler subject, in order to demonstrate the choreographic synchronization of behavior abstractions (cf. [37]). The figure reveals the parallel operating nature of the 2 subjects involved in the interaction. Once the need for (re)scheduling – modelled as send activity – is recognized by the Medication Handler, a corresponding message is delivered to the Personal Scheduler. When the Personal Scheduler has received that message, the request can be processed, either recognizing a conflict or fixing an entry into the schedule. In both cases, the result is delivered by ‘send reaction’ to the Medication Scheduler. The subject that has initiated the interaction can now process the results, i.e. the Medication Handler processes the reaction of the Personal Scheduler (modelled by the function of the respective SBD).

Fig. 7.
figure 7

Sample Subject Behavior Diagrams and message exchange upon request

Full size image

Each subject has a so-called input pool as a mailbox for receiving messages (including transmitted data through messaging that are termed business objects). Messages sent to a subject are kept in that input pool together with their name, a time stamp of their arrival, the data they transport and the name of the subject they come from. The designer can define how many messages of which type and/or from which sender can be deposited. The modeler can also define a reaction, if messaging restrictions are violated, e.g., to delete arriving messages, to replace older messages in the input pool. Hence, the type of synchronization through messaging can be specified individually.

Internal functions of subjects process (the transmitted) data. In our example the subject Blood Pressure Measurement has a counter for each application. An internal maintenance function increases the counter by one when the client activates the device. The function can either end with the result “sufficient energy” or “change battery”.

Once a Subject Behavior Diagram, e.g., for the Blood Pressure Measurement subject is instantiated, it has to be decided (i) whether a human or a digital device (organizational implementation) and (ii) which actual device is assigned to the subject, acting as technical subject carrier (technological implementation). Validation of SBDs is sufficient for interactive process experience and testing process completion. Besides academic engines, e.g., UeberFlow [22], commercial solutions, such as Metasonic (www.metasonic.de) and actnconnect (www.actnconnect.de), can be used. Since neither the input pool nor the business objects are part of the modeling notation, it depends on the environment and runtime engine used for development, at which point in time and in which form data structures and business logic determining the communication on the subject instance level can be specified for pragmatic process support.

4.3 Dynamic Adaptation and Predictive Analysis

After refining BeEs from a function and communication behavior perspective by means of Subject-oriented Business Process Management and its choreographic representation scheme, for organizational transformation, dynamic adaptation and prediction of behavior can be tackled as addressed in this section. The design scheme is enriched with modeling the dynamic adaptability of system behavior, thus aiming to meet REQ 5:

  • Adaptation is captured in a generic, however, context-sensitive form (REQ 5).

Dynamic adaptation is based on a trigger, such as a result from performing a function or a sensor signal, which requires special behavior specification. It can be handled according to S-BPM’s concept of event processing, thus allowing to capture variants of organizational behavior at design time (cf. [11]). The trigger to dynamic adaptation independent to its implementation can carry some data as payload. For instance, with the trigger “blood pressure above threshold” some information can be tagged to the physical device. Like an event, a data object representing a trigger can carry three types of information: Header, payload and plain content. The header consists of meta-information about the trigger like name, arrival time, priorities, etc. The payload contains specific information about the triggering event. Finally, a trigger can also contain free format content.

With respect to operation and model execution, triggers are messages. Messages of a S-BPM model represent event types. Once a process instance is created and messages are sent, these messages become events. If messages are sent and kept in the input pool they get a time stamp documenting their arrival time. Instantaneous events can be handled by Message Guards. They are modeling constructs to represent behavior variants including the conditions when which variant is relevant and should be executed (see Fig. 8).

For instance, the message “call emergency service” from the subject Blood Pressure Measurement can arrive at any time when delivering data from measurement. This message is handled by a Message Guard. In that Message Guard the reaction of an instantaneous message is specified, e.g., the emergency service is called by the Personal Scheduler subject, since reaching a certain threshold of the blood pressure indicates the need for medical expert intervention for the concerned client.

Message Guards as shown in Fig. 8 allow handling adaptive behavior at design time. The specification shows how critical cases are handled at run time (i.e. once the subject has been instantiated), either by humans or technological systems. The general pattern reveals that jumping from routine behavior (left side) to non-routine behavior is based on flagging functions serving a triggers and (re-)entry points. In the addressed home healthcare example the Message Guard can be applied when a threshold of Blood Pressure has been reached. Once the flag is raised at runtime, either

  • either substitutive procedures, returning to the regular SBD sequence – see left side of Message Guard, or

  • complementary behavior, leaving the originally executed SBD – see right side of Message Guard in Fig. 8 – is triggered.

Message Guards can be flagged in a process in various behavior states of subjects. The receipt of certain messages, e.g., to abort the process, always results in the same processing pattern. Hence, this pattern should be modeled for each state in which it is relevant. The design decision that has to be taken concerns the way how the adaptation occurs, either extending an existing behavior, or replacing it from a certain state on.

In the home healthcare example, returning to the original sequence (regular SBD sequence), is given when the called emergency service in case of high blood pressure does not require any further intervention of medical experts. Replacement of the regular procedure, however, is required, in case the Medication Handler subject, and as a follow-up, the Personal Scheduler subject (referring to the time of medication), have to be modified.

Once the organizational transformation includes predictive analytics, its integration needs to be structured according to its context (cf. [33]). Figure 9 shows an organizational approach for embodying predictive analytics. The developed pattern is based on a Monitor subject that is triggered by a function in an idle loop observing an IoB system. The monitored data needs to be evaluated to identify the need of adaptation. For algorithmic decision making, a (business) rule base could be of benefit.

Fig. 8.
figure 8

Dynamic behavior adaptation using Message Guards

Full size image
Fig. 9.
figure 9

Sample SID for dynamic behavior adaptation using Predictive Analytics

Full size image

Recognizing the need of adaptation requires business intelligence stemming from a Predictive Analytics subject. According to the behavior data available and the calculation model to either predict the behavior of the acting, or the behavior of other interacting subjects, a proposal is generated. In order to avoid re-iterating certain behavior patterns, the adaptation request is stored, together with the newly generated proposal. The latter will be evaluated for effectiveness and efficiency.

With respect to our home healthcare case, organizing the setting could be challenged on whether medical experts need to be contacted once the blood pressure is higher than a specific threshold by predicting that an additional data analysis (e.g., diet patterns) could help avoiding triggering emergency services. Implementing such a proposal requires extending the SID with a Diet Handler subject that can deliver timely data on the diet behavior of the client. It would need to interact with all other subjects, as its functional behavior to provide the requested data leads to novel patterns of interaction.

Given this path of exploratory growth of networked behavior entities, the design science-based framework sketched in Sect. 2 supports their iterative while structured development. Each enrichment can be iteratively tested along design-evaluation iterations of various granularity. Consequently, whenever the transformation space is to be enhanced with choreographic intelligence, the resulting additional requirements for a solution can be exemplarily met by (re-)designing the artefact, demonstrating and evaluating the envisioned enhancement. In this way even variants of system intelligence can be explored and checked for viability.

5 Conclusion

The Internet-of-Behavior (IoB) is built upon IoT and leading towards dynamics adaptation and generation of behavior. Due to its networked nature data analytics can be used for timely adaptation and manipulation of behavior. The resulting system complexity can be handled by representation and access capabilities. The presented approach follows a well-structured and consecutive development approach stemming from design science. It targets organizational structures that can be developed to IoB transformation spaces due to the choreographic behavior encapsulation of functional entities.

The transformation process starts with describing the individually perceived role- or task-specific behavior as part of mutual interaction patterns that are challenged with a specific objective. In a further step, the identified behavior encapsulations and interaction patterns are refined to executable process models. In this way organizations can experiment with IoB system solutions, and structure analytical intelligence development according to their needs.