8.4. Extended Boundary
Modeling large scale, complex systems is non trivial, in particular addressing boundary issues between the technical system and the environment: “Considerations of large-scale engineering systems often present a dilemma of where to draw the line between a system and its environment. How are social, political, economic, and institutional issues addressed? How can the techniques of engineering science be connected with a modern understanding of human decision making, organizational behavior, and institutional inertia?” [
43]. To build joint optimization into a STS from inception, the system boundary must necessarily include people and environment, resulting in what can be defined as an extended boundary. It is not possible to achieve joint optimization if the socio and the technical aspects are modeled separately as different things, because all the modeling, development and engineering activities that follow are influenced and guided by the boundary. Setting an inclusive boundary results in the STS being considered as a whole, rather than emerging from the interaction of different sub-systems. The three aspects of the system contribute different kinds of
resources to the resulting STS, which are complementary and extend each other with corresponding attributes ad relations:
The Human/Social aspect of the system contributes (1) Stakeholders, (2) Goal/scope for the system/desired functionality, (3) Requirements, (4) Human level intelligence/cognition, (5) Specialized Knowledge and skills;
The
Technical aspect is derived from some of the “attributes” of the Human/Social aspect, in the sense that it is generated from requirements and limited by resource constraints, however technology also recursively extends and influence the Human/Social aspect, for example with extended cognition and productivity capabilities, in what can be defined as a self determining hermeneutic cycle [
44];
The Environmental aspect can be distinguished into Physical and Cultural/Social, contributing respectively natural resources (such as materials, physical laws, deployment grounds), as well as norms, languages, and intellectual context. The environment is where the impact of the STS can be observed and measured, it is also where physical and cultural conditions in turn influence the other two aspects.
Figure 1 represents a STS as a nested holarchy [
45,
46], where the core element is the human system, which influences (top arrow) and is influenced by (bottom arrow) the technical system, which in turn impacts (top arrow) as is constrained by (bottom arrow) the natural system/environment. The arrows represent both the correlation and interdependence of the three aspects, as well as the recursive
resonance [
1] in which each aspect influences on the others. In future work, resources permitting, we plan to study in more detail this interdependence by modeling and observing changes in behaviors between the three. A concept known as Total System Boundary [
47] found in literature, is analogous to our STS Extended Boundary illustrated in
Figure 1, however it was not applied to joint optimization.
Figure 1.
The STS Extended Boundary.
Figure 1.
The STS Extended Boundary.
8.5. Core Entities
This is intended as a static part of the metamodel, the purpose of which is mostly to serve as a “catalog” of core entities and relations. No behavior is ascribed. They are derived from a systematic review and meta analysis of models of joint optimization in use, some of which have been outlined in
Section 8 of this paper. The Core entities are intended to be a super-abstraction (a high level abstraction) and a meta synthesis of archetypes which can be observed at some level in “any” STS—at least to some degree—however these artifacts are designed to be “extensible” and become more detailed to any desired degree of granularity and to be revised iteratively against the outcomes of ongoing evaluation exercises.
Table 1 lists the initial set of core entities identified in literature and from observations in the field, as the minimum essential set without which a STS does not exist. The other columns correspond to the three core dimensions of a STS, showing how each core entity plays a role in one or more dimensions. Feedback Loop is introduced as a core element, for completeness of design. Feedback is also a part of the Core Process Input-Output, discussed below. The next section provides some justification and an explanation of for these entities and the corresponding dimensional associations are derived.
Table 1.
Schema of Joint Optimization Metamodel (JOM) core entities, and how these relate to the three main aspects of Socio Technical Systems (STS).
Table 1.
Schema of Joint Optimization Metamodel (JOM) core entities, and how these relate to the three main aspects of Socio Technical Systems (STS).
Core Entity | Social/Human | Technical | Environment |
---|
Stakeholder | X | X | X |
Goal/Requirements | X | X | X |
Culture | X | X | X |
Task (Function/Process) | X | X | X |
Resource/Input | X | X | X |
Resource/Output | X | X | X |
Feedback | X | X | X |
Elements of the work system are abstracted from literature [
39] in
Table 2 and
Table 3, and rehashed to provide a higher level of abstraction and reduce redundancy.
Table 2.
Elements of a work system [
39].
Table 2.
Elements of a work system [39].
Customers are recipients of a work system’s products and services for purposes other than performing work activities within the work system. For example, a doctor who receives a lab result while treating a patient might be viewed as a customer of the lab, but is not a customer of the work system of providing medical care. Internal customers are customers of a work system who happen to be employees or contractors of the firm within which the work system operates. External customers are not employees or contractors for that firm. |
Products and services are the physical things, information, and actions that are received or used by the work system’s customers and that provide direct benefit for its customers. Different groups of customers may benefit from different products and services produced by the work system. |
Processes and activities are actions that occur within the work system to produce products and services for its customers. Processes and activities include much more than totally structured processes that appear in some IS definitions as “procedures”. As happens in collaboration systems and many other situations, various processes and activities performed by participants may be structured, semi-structured, or unstructured. |
Participants are people who do the work within the work system. They include both IT users and non-users. Thus, non-users of IT may still be important to include as participants in the work system. A work systems’s customers are also participants in many work systems that provide services. In self-service work systems, customers may be the only participants. |
Information includes codified and non-codified information created and/or used by a work system. |
Technologies include tools that are used by work system participants, plus other tools that perform totally automated activities. Technologies within a work system include IT and other, non-IT technologies that perform physical movements or transformations that are visible to users. Many technologies that perform physical activities (e.g., automobiles and microwave ovens) include embedded IT. |
Infrastructure includes relevant human, information, and technical resources that are used by the work system but are managed outside of it and are shared with other work systems. |
Environment includes the relevant organizational, cultural, competitive, technical, and regulatory environment within which the work system operates. A work system’s environment should be considered when analyzing a work system because its success depends partly on surrounding factors that are not part of the work system itself. |
Strategies that are relevant to a work system include strategies of the work system, the organization, and the enterprise. Strategies may or may not be articulated. When articulated, strategies may help in understanding a work system and its environment. |
Table 3.
Elements of a work system streamlined and regrouped as JOM elements.
Table 3.
Elements of a work system streamlined and regrouped as JOM elements.
Customers, Participants = Stakeholder Products Processes and activities = Process Strategy = Culture Information = Resource Infrastructure = Resource |
An outline of JOM elements follows:
Stakeholder. Based on a Stakeholder Taxonomy [
48] from literature, a segmentation of different roles of system stakeholders is identified which includes Beneficiary/User, Negative Stakeholder, Developer, Operator, Purchaser, Sponsor/Investor, Consultant, Regulator. It should, however, be noted that (a) in real world STS settings the roles are increasingly interchangeable (b) a stakeholder entity can have multiple roles, sometimes simultaneously. While Stakeholder primarily pertains to the first dimension (human/social) as stakeholders are inherently people/human, JOM purports that both the other two dimensions are directly related the human dimension. For example (a) stakeholders use/need/create/co-create technologies, and there is interdependence between users cognitive and behavioral traits technological systems they adopt and
vice versa [
49,
50], as well as by their physical and cultural environments surrounding them There is a growing consensus that timely and broad based stakeholder involvement is a vital ingredient for effective environmental assessment, as it is for project planning, appraisal and development in general. The World Bank has found that public participation in EIA (environmental impact assessment) tends to improve project design, environmental soundness and social acceptability [
51] and (b) the environment is also a type of external stakeholder in any given STS [
52].
Goal/Function. What purpose should the system fulfill? What problem does it solve? The crux of what a STS consists of, is initially determined by standard functional requirements. There is a strong correlation between “goal” and “stakeholder” identification, in that different groups of stakeholders may have different goals as the priority for the system. How to reconcile different views and stakeholders expectations is part of a balancing exercise which continues throughout the life of a STS, and relies on multistakeholder modeling techniques such as IEEE1471 to capture different views and viewpoints.
Culture. Under Culture everything that defines to the socio technical praxis. It includes organizational culture, axioms, values, beliefs, attitudes, worldviews, paradigms, policies, rules, laws, procedures. Culture is inherently a social entity, albeit largely intangible, but clearly reflected in the governance structure and policies not only of the organization (as a cluster of stakeholders) but also of the STS itself. Technology influences culture, and culture influences technology, culture also impacts the environment [
53,
54].
Task (Function/Process). A task is any activity which supports the system goal and objectives, via “functions”, which are implemented through processes. Typically task models distinguish between system task model that provide information about how the designed system requires tasks to be performed, and user task model which is how users perform system tasks, however, in STS terms, a socio technical task model devised to support joint optimization, must inevitably be the synthesis of both.
Defining tasks in complex systems is problematic as illustrated by text book example: “if you go down to a shipyard and look around for as shipbuilder you will find welders, carpenters, foremen, engineers, and many other specialist, but no shipbuilders. True, the company executives may call themselves shipbuilders, but if you observe them at their work… consists of writing contracts, planning budgets, and other administrative activities… they are not in any concrete sense building ships… a system is building ships, and the system is the shipbuilder” [
55].
A concept defined as “core task” for modeling the “outcome critical content” of process control work in complex, dynamic and technologically mediated environments (such as air traffic control and nuclear power plant control room), shown in
Figure 2, is defined in the Core Task Analysis (CTA) Framework [
56] and used for in analyzing working practices and personal work orientations:
“The result-critical content of a particular work, which defines both the possibilities for action and the demands that must be fulfilled in all situations in order to maintain appropriate interaction with the environment”. Nevertheless, the core task concept should not be restricted to individual actions, but action should be interpreted in a wider perspective of a societal activity that is carried out co-cooperatively by a number of actors. Therefore, leveraging the same fundamental assumption, the element TASK in JOM is represented with the set operation, action, activity, motivation.
Figure 2.
Core Task Model, Norros [
56].
Figure 2.
Core Task Model, Norros [
56].
Tasks can be of different kinds, for example Cognitive Manual/Physical Digital/Virtual, but in contemporary information technology intensive scenarios, it is likely to be a hybrid, which is becoming increasingly intertwined: cognitive systems automate at least to some extent intelligent tasks carried out by humans, and also increasingly present in tools and processes which were traditionally manual and “physical”. Operational tasks, from complex critical systems to everyday chores, are increasingly technology intensive, and as such implemented via processes, whether routinely automated or ad hoc. The “environment” is both the space where all tasks and actions take place, and where their impact/effect becomes observable and measurable. Therefore, the element TASK exists in all three dimensions of STS models.
Resource (input/output). A STS resource is whatever the system requires to operate and fulfill its function/goal, as well as the product/outcome of the any system function. It’s a very high level class to represent everything that is required and everything that is produced, No single standard model exists of “System resources”, let alone a model for socio technical systems resources, which is going to be tackled in more detail in future work. For the purpose of this paper JOM characterizes resources: tangible/physical (as in materials), cognitive (knowledge, information), and non-tangible (organizational, belief systems, socio-political infrastructures). STS resources are typically a combination of human, technical and environmental assets, and as such this element exists also in all three dimensions.
Feedback. Feedback is inherently the life and soul of STS, the single mechanism thanks to which the system and its various components exchange information to enable goals to be achieved, functions to be performed correctly and eventually, for all systems states to be reached and maintained, thus enabling joint optimization. The structure of feedback is recursive: feedback loops gather responses to outputs and return value-actions and need to be iterative, continuous. Some design tradeoffs have been considered, whether feedback should be one of the core elements, or part of the core process. Given the importance of feedback in achieving JO, JOM enlists feedback as both.
8.7. Core STS Process
A process essentially consists of what goes on in the system defining its dynamics and efficiency. That’s where everything that really matters happens, the rest of the architecture consists of mere “ingredients” for a successful socio technical recipe. Differences in process execution impact the outcome and outputs. A system process can be defined as “a business process” in the sense that it is any procedure relevant for creating value [
57]. A common example in systems engineering is the Business Process Model. What is unique to a STS process, and that has not yet been identified in standard process models in use, is the process which enables and supports (or disables and inhibits) Joint Optimization (JO). Joint optimization is the result of a “business process” carried out through iterative recursions across the three STS dimensions, People Technology and Environment. Each task, function, process, and activity pertaining to the system must be carried out in relation to all of its elements and across its core dimensions.
To facilitate Joint Optimization, JOM adopts the central elements of the process architecture of ARIS (Architecture of Integrated Information Systems) Architecture and Reference Models for Business Process Management [
57], which distinguishes between four interlinked levels of processes:
Process engineering—processes are modeled in accordance with a work schedule. Various methods for optimizing, evaluating and ensuring the quality of the processes are adopted;
Process planning and control—processes are planned and controlled, with methods for scheduling and capacity. Process monitoring is the control mechanism;
Work flow control—data information and knowledge objects are scheduled according to work design criteria, and implemented via work flow processes;
Process execution—the function of enacting the business process.
The specific characteristic of ARIS inherited by JOM (
Figure 3) is that “the four levels are interdependently connected: Information at Level II regarding the profitability of current processes, is the point of departure for continuous adjustment and improvement of the business processes at Level I. Work flow Control is linked to Level I, because Work flow Control at Level III requires the description of business processes. At the same time, Work flow Control reports actual data regarding the processes to be executed (amounts, times, organizational allocation) back to Level II. Applications at Level IV are executed from the work flow system at Level III and configured according to the business process models at Level I” [
57]. Another characteristic of the JOM process is that it is inherently iterative, and self determining, supporting “coevolution” (
Figure 4) whereby Interactions and feedback loops are represented by arrows. Interactions are iteratively defined, as in the Rational Unified Process (RUP) [
58].
JOM core process has a dual function:
- (1)
Support the development of a STS, by ensuring that (a) comprehensive stakeholder perspective is adhered to; and (b) each phase of the system development process is carried out iteratively taking into the account as input the output of the precedent phase;
- (2)
To ensure that the STS which is the outcome of JOM core process, adheres to its blueprint, IE, that replicates its core structure and features;
Therefore the JOM core process, essentially consists of a series of steps to e carried out alongside the four dimensions, which maximize the inclusion of STS stakeholders and is capable of adjusting
-

Identify stakeholders;
-

Stakeholder define goals, expected outcomes and boundaries STS boundary;
-

(What should be in the system, stakeholder, technology and environment);
-

Align goals to optimize resource allocation;
-

Define STS components, functions, behaviors;
-

Identify STS dynamics/flows;
-

Outline process to achieve goal/expected outcomes;
-

Iterate until goal is achieved.
Figure 3.
JOM Process Architecture Modified from ARIS (Architecture of Integrated Information Systems) [
57].
Figure 3.
JOM Process Architecture Modified from ARIS (Architecture of Integrated Information Systems) [
57].
Note: curved arrows indicate iteration and feedback flows.
Figure 4.
STS co-evolution.
Figure 4.
STS co-evolution.
The resulting JOM core process outline therefore consist of these steps carried out iteratively across the four level process architecture defined earlier, as shown diagrammatically in
Figure 3.