=Paper=
{{Paper
|id=Vol-3239/paper9
|storemode=property
|title=On the use of sociotechnical systems design in industry: Digital transformation processes and artifacts
|pdfUrl=https://ceur-ws.org/Vol-3239/paper9.pdf
|volume=Vol-3239
|authors=Eric S. Rebentisch,António L. Soares,Donna H. Rhodes,Ricardo A. Zimmermann,Joana L. F. P. Cardoso
|dblpUrl=https://dblp.org/rec/conf/stpis/RebentischSRZC22
}}
==On the use of sociotechnical systems design in industry: Digital transformation processes and artifacts==
https://ceur-ws.org/Vol-3239/paper9.pdf
On the use of sociotechnical systems design in industry: digital
transformation processes and artifacts
Eric S. Rebentisch 1, António L. Soares 2, 3, Donna H. Rhodes 1, Ricardo A. Zimmermann 3, and
Joana L F P. Cardoso 1
1
Massachusetts Institute of Technology, 77 Massachusetts Avenue, Cambridge, 01239, USA
2
University of Porto, Praça de Gomes Teixeira, 4099-002 Porto, Portugal
3
INESC TEC, Rua Dr Roberto Frias, 4200-465 Porto, Portugal
Abstract
Digital transformation is a broad description of efforts to introduce new technologies within
and across organizations with the potential to revolutionize the way they function and perform.
Digital transformation may be addressed at multiple levels of analysis, and this paper focuses
on the enterprise level. This includes the organization, its people, systems, tools and
technologies, and suppliers and partners that combined create valued outcomes that sustain the
enterprise and advance its objectives. Collectively, this is a complex sociotechnical system
(STS), and digital transformation is an intervention in a STS of potentially profound scope.
Classical STS theory emerged from analysis of individuals and work groups and principles
have been defined for the design of work systems at that level. We explore how STS design
principles may be applied to the enterprise-level challenges associated with digital
transformation. We present an enterprise-level framework that describes a process and methods
that are consistent with STS design principles and illustrates how existing systems analysis
methods and artifacts may be used to design an enterprise level STS. We review some artifacts
employed in digital transformation efforts, including enterprise reference architectures, to
better understand how they might function as means to foster communication and collaboration
across multiple disciplines and domains in the STS design process.
Keywords 1
Digital Transformation, Sociotechnical System Design, Enterprise Architecture, Reference
Architecture, Boundary Objects
1. Introduction
Digital transformation encompasses the transformation of organizations and their structures,
processes, relationships, and behaviors and is largely driven by the development and growth of enabling
digital technologies. As a phenomenon, it has already been underway for some decades, but the
introduction of new technologies and near-continuous changes and improvements to existing
technologies suggests that organizations will face the prospect of ongoing redesign for some time to
come. With the influx of new digital technologies, new behaviors and capability sets will emerge within
organizations, whether by design or by necessity. One thing is certain, however: the introduction of new
digital technologies will not only change the technical capabilities of organizations, but will also change
their social structures and dynamics.
The understanding of the interplay of social and technical systems (or sociotechnical systems, STS)
has developed over several decades, starting with seminal works in the 1950s. Much of the development
of STS theory has focused at the individual and group levels and their interaction with specific
technologies. More recently, STS theory has started to address more aggregated levels of analysis—the
organization and enterprise—with promising results. The importance of studying sociotechnical
Proceedings Socio-Technical Perspective in IS Development 2022, Aug 19-21, 2022, Reykjavík, Iceland
EMAIL: erebenti@mit.edu; antonio.l.soares@inesctec.pt; rhodes@mit.edu; ricardo.a.zimmermann@inesctec.pt; jcardoso@mit.edu
ORCID: 0000-0003-1124-1312; 0000-0001-7654-1397; 0000-0002-5868-8982; 0000-0002-3398-7134
© 2022 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
85
systems at the enterprise level has long been recognized. Trist, in a 1959 lecture, asserted that the
relationships of social systems and technology “can be studied at any level: that of the individual, the
primary work group, larger internal units involving various levels of management, and the enterprise as
a whole.” [1]. Legacy studies of large enterprises typically focused on the social systems rather than the
sociotechnical. Rouse et al. [2] discuss the evolution of STS from origins to contemporary views, and
the implications of growing social complexity. Currently, the characterization of STS principles and
practices at the organization or enterprise level is still in its early days. There is much that we don’t
know about how STS principles and practices can be applied to the design of organizational systems at
higher levels of aggregation.
When new technologies are introduced into organizations, the human/social system often adapts to
accommodate and appropriate the benefits of the new technical capabilities. However, this can often be
a lengthy and disruptive process, and not always successful, especially when done in an ad-hoc manner.
Enterprise Architectures (EA) result from a deliberate, structured approach that seeks to characterize
how new capabilities relate to one another with an enterprise-wide perspective. EA ideally encompass
all relevant facets of the organization, transcending traditional information technology (IT)-centric
views in order to better respond to increasingly complex environments [3]. Adding additional challenge
to the STS designer is the near-constant pace of change in enabling information technologies. Pasmore
et al. [4] assert that a sociotechnical system should strive for “continuous design” instead of episodic
design in the development of new capabilities in order to better cope with continuous change.
In addition to social and technical aspects of digital transformation, the STS may involve a large
number of elements and connections, with corresponding diversity in disciplines and domain expertise
required. Collaborating in the design of the new STS requires the ability to represent and share multiple
perspectives through artifacts functioning as boundary objects that facilitate understanding and
knowledge transformation [5]. Previous research focusing on the introduction of digital twins into a
STS used the concept of operations (CONOP) as an artifact that explicitly translates strategic decisions
into sociotechnical systems vision, goals, concepts and high-level requirements, bridging the strategic
process with enterprise architecting and STS design activities [6]. This paper seeks to identify other
possible artifacts that can support and enable STS design by acting in the role of boundary objects.
The architecting of IT systems increasingly includes the use of reference architectures (RAs). RAs
describe the expected functions and capabilities typical to a digital enterprise. A closer look at existing
RAs suggests that they express greater detail concerning technical capabilities than of the social
capabilities in the digital enterprise. As such, they may provide some benefit to STS design, but may
not sufficiently address the spectrum of social and technical challenges likely to be encountered.
In this paper, we explore whether the development of new organizational capabilities enabled by
digital technologies can be made a more deliberate and systematic process, in which the benefits are
realized more quickly and with less disruption to on-going operations. More specifically, we are
interested in exploring how STS design principles can be applied to the design of digital-enabled
organizations such that the creation and employment of new capabilities is less disruptive and the
likelihood of overall success increases. We further investigate whether RAs or similar EA artifacts
could be useful to bridge between the IT, managerial, and other communities of practice in the STS
design process for a digital-enabled enterprise. We start with these questions:
• Can enterprise-level perspectives and techniques be combined with existing STS design theory,
principles, and practices to help with the transformation of modern digital-enabled enterprises?
• Do existing enterprise architecting artifacts, such as reference architectures, better enable a STS-
oriented approach to digital transformation?
• Is a multiple disciplinary perspective enhanced during the STS design of digital-enabled enterprises
by the use of system artifacts functioning in the role of boundary objects?
2. Sociotechnical systems implications for digital transformation
In addition to the increasing dynamism and complexity of current business environments,
technologies themselves are changing and becoming more complex, requiring new approaches to design
and implementation processes. While initial discussions about digital transformation focused mainly on
technical dimensions, there is a gradual and increasing recognition of the relevance of human and
86
organizational aspects in this process [7]. In this paper, we adopt a definition of Digital Transformation
as "[...] the process of organizational or societal changes driven by innovations and developments of
ICT [information and communications technology]. It includes the ability to adopt technologies rapidly
and affects social as well as technical elements of business models, processes, products and the
organizational structure" [8]. Digital transformation includes the design, development and
implementation of technology-intensive work systems, as well as the required organizational change
process. In this sense, successful digital transformation includes the combination of technical systems
(adoption of digital technologies) and social systems (organizational practices and human factors) with
the objective of enabling business and performance gains [9], [10].
In addition to technological development and implementation, digital transformation presents
challenges in the operational, organizational and managerial levels [11], [12] and its boundaries are
defined by a systems perspective and by the principles of open systems [9]. The social dimension of a
sociotechnical system focuses on aspects such as people, relationships, organizations and performance,
while the technical dimension includes technology, innovation, knowledge, processes, and methods
[13]. The adoption of a systems approach to the design and implementation of digital technologies will
necessarily include organizational changes. This approach encompasses the dependencies between all
the components of the sociotechnical system and commits to the idea that the different aspects must not
be analyzed separately.
According to [14], “digitalization is about leveraging digital technology to alter socio-technical
structures''. The introduction of digital technologies represents sociotechnical interventions that have
impact on several working and organizational aspects such as: organizational structure; production
systems and operating procedures; communication and collaboration; job profile, skills and the abilities
required to perform the work; climate, culture and strategy [15], [16]. Thus, social and technical
elements must be considered in the process of digital transformation. The sociotechnical design
perspective has begun to co-evolve in response to the increasing adoption of digital technologies [4].
The sociotechnical systems design cycle becomes iterative with trades made between the different
system elements and relationships until the sociotechnical systems design converges on a higher-
performing system architecture.
Although digital transformation may be addressed at multiple levels of analysis, systems designers
must recognize that systems boundaries are usually permeable, permitting interactions with the
environment. The traditional level of analysis (usually the company or the team) does not consider all
the relationships and the myriad of elements that influence and are influenced by the implementation
of a new technology. In this scenario, there may be a mismatch between the analysis carried out by the
systems designers and the reality, considerably more complex.
The enterprise level of analysis includes the organization, its people, systems, tools and technologies,
and suppliers and partners that combined create valued outcomes that sustain the enterprise and advance
its objectives. In this organization’s larger enterprise context, the partners, suppliers, and other
stakeholders may contribute/consume resources or provide capabilities, and may value or otherwise
benefit from outcomes. Therefore, the organization develops its strategy in response to the ecosystem
in which it resides, and typically evolves that strategy based on how well its outcomes suit the
environment in which it operates [6]. Enterprise architecting extends the description of system elements
beyond the core organization and includes additional perspectives to more fully encompass the elements
and their relationships.
A step further in terms of the level of analysis to the systems design process is to consider an even
wider sphere of mutual influence of the organization. The enterprise value chain includes the flow of
goods, money, information and knowledge between individuals, organizations, resources and activities
(internally and externally) with the goal of delivering value to the end user. Beyond its value chain, an
organization influences and is influenced, in a greater or lesser extent, by the environment around it,
including society and the natural world. In this sense, the adoption of a new technology also has the
potential to impact and be impacted by these elements. Moreover, as digital transformation potentially
enables companies to improve efficiency and resource management, it also theoretically improves
sustainable performance, both economically and environmentally [17].
A system design considers the complexity of a sociotechnical systems in a broad level perspective
covering aspects such as: (1) Active involvement of relevant stakeholders (internal and external) across
the organization’s value chain; (2) Identification of system boundaries and definition of performance
87
criteria – allowing the definition of the systems parameters; (3) Clear knowledge on the current situation
(as is), including the assessment of technological and organizational aspects related to structure (e.g.
number of hierarchical levels), job profile and competences; (4) Analysis of the necessary changes “as
a condition” and the expected “changes as a consequence” of the technology implementation –
considering aspects such as technology, people, infrastructure, processes, culture and strategies; and (5)
Analysis on how the adoption of a new technology can impact and be impacted by social and
environmental aspects.
3. A framework for sociotechnical system design
A sociotechnical system design approach benefits from the application of existing tools and analysis
methods to define both high-level and detailed elements, relationships, and processes in the enterprise,
encompassing both social and technical aspects. Importantly, this enables evaluation and tradeoff
between social and technical system elements that characterizes the actions, interactions, and roles of
each.
Bartezzaghia et al. [18] in a study of Industry 4.0 technology adoption in three organizations describe
the STS design effort as a continuous, participatory, learning process, where planning and doing are
contemporaneous. They describe three methods used in STS design that: 1) ensure that design choices
are simultaneously considered from multiple domains; 2) are based on continuous experimentation and
iteration; and 3) actively involve a broad set of stakeholders. Imanghaliyeva et al. [19] define a list of
20 STS design principles based on a systematic literature review. Among the STS principles mentioned
are joint optimization, participation, experimentation, responsibility, boundaries, multidisciplinarity,
functional purposes, and simplicity and scale.
While helpful, principles must be operationalized into methods and processes to be successfully
employed in digital transformation efforts. Rebentisch et al. [6] developed a STS framework for
organizational design, which is adapted and presented in Figure 1. The framework defines a sequence
of cycles employing specific, existing system analysis methods in a way that operationalizes STS design
principles. The major cycles of activity are requirements, sociotechnical systems design, and
implementation. The framework connects enterprise strategy to implementation, so its scope exceeds
just the design of the STS, but is consistent with the principles of STS design mentioned in the literature.
Figure 1: Digital transformation framework highlighting STS Design activities (figure adapted from [6]).
The three main cycles of the framework include these elements:
• The Requirements cycle identifies stakeholder and other needs in the enterprise, and elements
of strategy that may be addressed through capabilities enabled by digital transformation. The
artifacts created during system analysis include a concept of operations (CONOP), use cases
and operating scenarios, and system requirements [6].
• The STS Design cycle collects artifacts that describe the relevant aspects and attributes of the
STS and synthesizes them into a design that can be implemented. The artifacts used during this
88
cycle include candidate technical system architecture elements (e.g., IT architecture(s)),
candidate enterprise architecture elements, and artifacts from the Requirements cycle. The
design of the STS emerges through a highly iterative, collaborative process where the different
elements are fashioned into an STS enterprise design using system architecting methods (e.g.,
allocating functions to forms in an iterative manner; see [20]). The STS design cycle requires
the greatest degree of interaction across domains and knowledge boundaries given the scope of
information associated with creating an enterprise-level STS design.
• The Implementation cycle partitions the STS design into discrete implementation projects and
manages the implementation process through the execution of these projects. The primary
artifacts in this cycle are the project plans and overall roadmap to implementation.
As the framework depicted in Figure 1 is based on systems analysis and engineering concepts, many
of the artifacts are drawn from systems engineering methods. The CONOP charts a path from strategic
goals or objectives to the operational capabilities needed to accomplish those objectives, and its authors
would include senior management, other stakeholders, and systems analysts. The technical architecture
is a system architecture description of the technical elements of the system that includes a
decomposition of technical elements and their interactions to actionable levels of detail. For a digital
system, it would generally be produced by IT architects and would potentially represent technical
architecture options through multiple levels of decomposition. The EA describes the candidate elements
of the enterprise and relationships between them. An enterprise reference architecture is a generalized
description of an EA. The artifacts associated with the technical architecture and EA may be formally-
or informally-defined, but exist nevertheless, and are used as inputs to the STS design process (if they
are not already formally-defined, they will likely be discovered and perhaps documented through
collaboration during the STS design).
The synthesis of the STS through the process shown in Figure 1 reflects the principles of STS design,
including engaging multiple stakeholders and domains, joint optimization of social and technical
elements, challenging existing boundaries, multidisciplinarity, and driving the STS design from
functional objectives. The effectiveness of the application of these principles will depend on the
likelihood that the artifacts employed in the process enable meaningful collaboration across different
perspectives. If the artifact representing the technical architecture, for instance, is understandable only
to the IT architect, the managerial staff or other stakeholders may not be able to identify organizational
processes, resources, or relationships that must be co-designed with the new technical approach. A lack
of accessible and understandable artifacts in any part of the STS design cycle may inhibit the ability to
correctly allocate functions to solutions across domain boundaries or jointly optimize the overall
configuration of the STS design.
Boundary objects possess the attributes that enable them to foster communication and joint problem-
solving between different groups and across knowledge boundaries. A question for the STS designer is
whether the artifacts being used (e.g., the CONOP, technical architecture, etc.) possess the necessary
attributes to enable them to function as boundary objects. In the next section, we examine whether
enterprise architectures (and specifically reference architectures) as they currently are employed can
function as effective boundary objects during STS design.
4. Architectural artifacts and their potential role in STS design
The concept of Enterprise Architecture (EA) goes back to the 1980s [21] while the industry specific
manifestations of it appeared in the 1990s with research initiatives across Europe and the US [22], [23].
EA are conceptual artifacts that are used in a range of management activities, mostly addressing the
planning and use of information technology and systems. Enterprise architecture management (EAM)
aims to purposefully design an enterprise’s architecture to enhance its pursuit of its strategic goals [24].
At its most basic level, an "architecture" describes a system's fundamental structure, and provides
guidelines for its evolution [29]. It describes the fundamental organization of a system's components,
their relationships to each other, and to the environment.
EA can be seen as a process (architecting) - a manifestation or enactment of strategic, tactical, and
operational decisions regarding processes, organization, technology, and people – or as a set of
articulated descriptive and prescriptive artifacts – principles, guidelines, models – providing support to
89
the management of an enterprise. While EA as a process is continuously evolving, EA as an artifact is
not adaptive to cope with complex, continuously changing environments [3]. Nevertheless, EA artifacts
such as Reference Architectures (RA) have been increasingly adopted since at least two decades by
industrial companies and organizations as a blueprint for building and interoperating their software-
intensive, cyber-physical systems [25].
But to what extent is EA consequential to STS design? Extant literature is scarce in respect to the
use of structural (conceptual) representations of the enterprise that include some facet of a
sociotechnical perspective. For example, Fayoumi et al. [26] address the design of explicit socio-
technical constructs within an Enterprise Modeling approach. This type of research outcome, resulting
from a blank sheet approach, is challenging because of a usually long knowledge transfer process and
adoption into practice. In a stream of research addressing EA beyond IT and enterprise organizing and
transforming processes, Korhonen and colleagues start by proposing that enterprise architectural work
(possibly involving EA) be divided into three distinct yet interlinked architectures: technical, socio-
technical and ecosystemic [27]. Later, they propose an adaptive EA to cope with the complexity of
enterprise in ecosystems, drawing on the heritage of “Open Sociotechnical Systems design” [3]. Finally,
they question the implications of digital transformation on EA, again using the three interlinked
architectures mentioned above [28]. This stream of research points to the possibility of using EA and
their artifacts with a potential mediating role in STS design processes.
4.1. Reference architectures as boundary objects in STS design
In the last decade, in particular with the rise of the Industry 4.0 concept and associated technologies,
the concept of “Reference Architecture” has gained traction across several industrial areas. Cloutier et
al., [30] define Reference Architectures (RA) as capturing “the essence of existing architectures, and
the vision of future needs and evolution to provide guidance to assist in developing new system
architectures”. Ideally, an RA should address the technical architecture, the business architecture, and
the customer context [30]. Two main principles should be considered when designing or using an RA:
(i) an RA is an elaboration of company (or consortium) mission, vision, and strategy; it facilitates a
shared understanding across multiple products, organizations, and disciplines about the current
architecture and the vision on the future direction; (ii) an RA is based on concepts proven in practice
[30]. A reference architecture provides a common framework around which more detailed discussions
can center, enabling the comprehension of the most important high-level aspects and providing a
structural guide for systems design, without the encumbrance of unnecessary and arbitrary details or
restrictions [31]. Last, but not the least, RAs are the result of negotiation and consensus within reputed
business and professional (and academic, to a lesser extent) communities, thus having some
authoritative influence with practitioners.
Previous research concluded that EA artifacts can act as instruments for information sharing,
highlighting dependencies and supporting the coordination of enterprise transformation. However, in
practice, EA artifacts often fail to be used by communities other than IT to communicate [24]. Kotusev
and Kurnia [32] conclude that EA can work as boundary objects and be meaningful to diverse
communities of practice, facilitating communication and understanding. However, they view EA
artifacts as boundary objects mostly between business and IT communities, not necessarily embracing
STS design. This raises important questions regarding their desirable informational content and other
related properties boundary objects could beneficially exhibit within STS design. At present, no
empirical analysis of EA artifacts from the perspective of their informational content and respective
boundary-spanning capacity has been conducted [32]. On the other hand, [24] already used the concept
of boundary objects to derive hypotheses for the design of EA artifacts, with the goal of supporting
communication and coordination in enterprise transformation projects. We build on these results to
analyze the instrumental potential of industry-specific EA artifacts (e.g., Industry 4.0 Reference
Architectures - i4.0-RA) in digital enterprise transformation processes, from the perspective of STS.
Boundary objects are abstract or physical artifacts that support knowledge sharing and coordination
between different communities of practice by providing interfaces. This concept was first introduced
by Star and Griesemer [33] and since then interpreted, adapted, and appropriated by other researchers
in various scientific areas. Two central aspects have been common to the use of the BO concept:
90
interpretive flexibility and retaining the community's identity [24]. The notion of boundary objects
identifies the types of representations that have “different meanings in different social worlds but their
structure is common enough to more than one world to make them recognizable as a means of
translation” [33]. Effective boundary objects “do not need to be accurate to be useful” [34], as long as
they enable people to share knowledge and find common ground. Boundary objects contain sufficient
detail to be understandable by both parties, but at the same time, neither party understands the full
context of use by the other [33].
From the properties identified by [24] we selected Abstraction, Shared syntax/semantics (added),
Malleability, Stability, and Visualization as the relevant properties to analyze the potential contributions
of RAs to the STS design process. For the STS conceptualization, the STS conceptual elements
described in [6] - Strategy, Ecosystem, Organization, Resources, Capabilities, Social system,
Stakeholders, Outcomes – were used in combination with the Levels of STS Design from [4] – Strategic
design (purpose, governance, ecosystem, organization), Operating system design (technology, social
system), and Work design (projects, expertise, processes). This conceptual framework is represented in
Figure 2. We use this conceptual framework to evaluate RAs as potentially useful artifacts in the STS
design process.
Figure 2: Conceptual framework for analyzing the potential of RAs in STS design.
4.2. The potential role of industrial Reference Architectures in STS design
Why do we hypothesize that a RA is a potentially useful instrument in STS design processes? Uslar
and Hanna [35], on describing their approach to a visualization for RAMI 4.0 (Reference Architectural
Model Industrie 4.0), briefly discuss the adaptation process of RAMI 4.0 from the earlier SGAM (Smart
Grid Architecture Model). Although this discussion is at the business/technical requirements level, it
shows the possibility of this specific RA to act as a boundary object between two business/technical
communities – industry/manufacturing and energy/smart grids – although these communities are
disciplinarily close in theory and practice. Panarotto et al. [36] point to the need to rely on the ability of
stakeholders to develop shared meaning when using models as boundary objects in early design
negotiations. Although [36] analyzed mostly computational models (while we are analyzing the use of
conceptual models) the study highlighted the importance of taking a boundary object perspective in the
development of a collaborative decision support system. We consider STS design as an example of
collaborative decision process. Another relevant conclusion from [36] is the need for increasing the
91
flexibility of information exchange between modeling domains and the development of a ‘metamodel’
boundary object which enables negotiation about the information requirements for a certain decision to
be made. This meta-model role could potentially be assumed by a RA.
The EA artifacts analyzed in this paper are RAMI 4.0 (Reference Architectural Model Industrie 4.0),
IIRA (Industrial Internet Reference Architecture), IVRA (Industrial Value Chain Reference
Architecture) and IDS-RAM (International Data Spaces – Reference Architecture Model 3.0) (see
Figure 3). RAMI 4.01 (Reference Architectural Model Industrie 4.0) is a domain-specific, government-
driven architecture resulting from the Platform Industrie 4.0 initiative of the German government and
widely adopted in the EU. It is also the international technical specification IEC PAS 63088:2017. IIRA
(Industrial Internet Reference Architecture) is a domain-independent, industry-driven architecture that
includes manufacturing, healthcare, energy, smart city, and others, and has been developed by the US-
led IIC-Industrial Internet Consortium, a program of the Object Management Group (OMG). IVRA
(Industrial Value Chain Reference Architecture) is a conceptual architecture maintained by the
Industrial Value Chain Initiative in Japan. IDS-RAM (International Data Spaces – Reference
Architecture Model 3.0) is a virtual data space, based on existing standards, technologies, and data
economy accepted governance models, aimed to facilitate secure and standardized data exchange and
linkage in a trusted business ecosystem. It is promoted and managed by the International Data Spaces
Association, a non-profit organization. Basic visual models of these RAs are shown in Figure 3.
Figure 3: The four reference architectures analyzed (left-right, top-down): RAMI4.0, IIRA, IVRA and
IDS-RAM3.0.
This analysis is based on the upper-level STS design ontology depicted in the conceptual framework
of Figure 2. Enterprise Architecture and boundary objects fundamental concepts were linked to this
ontology. This is mostly a terminological/conceptual analysis where we try to align the concepts in the
i4.0-RA to the concepts in the STS design ontology. From this terminological/conceptual analysis,
essentially along the Shared syntax/semantics property, we inductively characterize the remaining
properties.
92
The four RAs have some common structural properties. They use architecture viewpoints and views
to frame and address the various interests (concerns) that stakeholders in the system may have. In
RAMI4.0, IIRA and IVRA the viewpoints are visualized through a tridimensional space metaphor. The
IDS_RAM3.0 high-level structure is two-dimensional.
The RAMI4.0 documentation does not go into detail beyond the overall tridimensional structure,
thus our analysis is inconclusive regarding the alignment of concepts. At such a high level, particularly
the Levels viewpoint can be aligned with any of the STS design concepts, although substantial
interpretation and explanation would be needed.
The IIRA description is much more detailed in conceptual terms. The Business, Usage, Functional
and Implementation viewpoints unfold into specific concepts: Business - Visions, Values, Key
Objectives, Fundamental Capabilities, Stakeholders; Usage - System, Activity, Task, Role, Party;
Functional - Domains (Business, Operations, Information, Application, Control); Implementation -
Architecture Patterns. These concepts are generic enough to align with the STS Strategic design level.
It is relevant to note that IIRA describes the "human role" for the domains in the Functional viewpoint.
This enables the alignment with the Operating System and Work STS design level concepts.
IVRA is structurally more complex as it proposes a Smart Manufacturing Unit tridimensional model
(Asset, Activity, and Management) to be "encased" in the more general, also tridimensional "General
Function Block for Smart Manufacturing". The three viewpoints are: Level (Enterprise, Department,
Floor, and Device), Knowledge/Engineering Flow (life-cycle) and Demand/Supply Flow (Planning,
Procurement, Manufacturing Execution, Sales and Logistics, After Service). While the latter are generic
enough to align with the STS Strategic Design level, the Asset, Activity and Management views of the
former are able to align with Operating System and Work STS design levels' concepts.
From the four RAs analyzed, IDS-RAM3.0 is the more infrastructure-oriented and thus the least
human-oriented in conceptual terms. Nevertheless, the viewpoints (Layers) Business, Functional,
Process, Information, System use some concepts related with organizational structure, roles and
relationships that can (loosely) align with the Operating System STS design: User, Consumer, Broker,
Identity, Exchange, Contract, Trust, Sovereignty. Finally, the conceptual representation of a digital
resource in this RA proposes a concern-basic description including Content, Concept, Community of
Trust, Commodity, Communication, Context that can (again, loosely) be aligned with the Operating
System STS design. Table 1 summarizes these findings.
Table 1
Boundary Object property analysis of ERA frameworks
Abstraction (higher) Shared Malleability Stability Visualization
syntax/semantics
RAMI Layers, lifecycle value While the Business, The high The origin The 3D space
4.0 stream and hierarchy Functional, Information, conceptual level and metaphor together
levels are high-level Communication, enables nature of with a layered
concepts (perhaps too Integration, and Asset adaptation and the RA structure provides
high) that can layers can be easily transformation, makes it a familiar
generically be shared, the lack of but the effort to relatively recognition of
integrated with the conceptual details and do so would be stable views and
levels of STS design. modeling tools substantial. over time. concerns.
descriptions limits
building shared
meanings.
93
IIRA Viewpoints (concerns, Business, Usage, The level of The origin The 3D space
views, models), lifecycle Functional and conceptual detail and metaphor together
process, industrial Implementation and a number of nature of with a layered
sectors are high-level viewpoints give enough concepts similar the RA structure provides
concepts (perhaps too latitude to to the STS design makes it a familiar
high) that can accommodate STS concepts relatively recognition of
generically be design. potentially stable views and
integrated with the Model types are enables cost over time. concerns.
levels of STS design. technically-oriented effective
thus may be more adaptation and
challenging to develop transformation.
shared meaning.
IVRA Levels, Enterprise, Department, The level of The origin The 3D space
engineering/knowledge Floor, Device levels are conceptual detail and metaphor together
flow, demand/supply not general enough to and a number of nature of with a layered
flow are high-level accommodate all the concepts similar the RA structure provides
concepts (perhaps too STS design concepts. to the STS design makes it a familiar
high) that can However, the Asset, concepts relatively recognition of
generically be Activity, and potentially stable views and
integrated with the Management views on enables cost over time. concerns.
levels of STS design. Smart Manufacturing effective However, this RA is
Units can be useful in adaptation and structurally more
the STS detailed design. transformation. complex, which
can cause
difficulties in
visualization.
IDS- Layers, perspectives are While Business, The infrastructure The origin The relatively
RAM high-level concepts Functional, Process, orientation and simpler visual
(perhaps too high) that Information, System, doesn't give much nature of representations
can generically be layers can be easily space for the RA are not as effective
integrated with the shared, Security, transformation makes it as the ones from
levels of STS design. Certification, and and adaptation. relatively the other RAs.
Governance are difficult stable
to be related with the over time.
STS design concepts.
.
Abstraction – high-level view, hiding local contingencies, highlighting communalities.
Shared syntax/semantics – common information models, shared notation conventions, uniform local use of
information objects across communities of practice.
Malleability – joint transformation and adaptation of constructs, agreements on parts of models to suit
communities’ areas of concern.
Stability – information objects stable over time, despite local uses, stable reference frames.
Visualization – graphical or physical representations, interpretive flexibility, and cognitive effectiveness.
5. Discussion and conclusions
This paper described digital transformation as an enterprise-level example of a STS design exercise.
It presented a framework for describing the context in which STS design occurs – embedded within a
transformation process that includes requirements, STS design, and implementation cycles. The
artifacts produced during these cycles are instrumental in the design of the STS. Their effectiveness in
part depends on their ability to foster communication, collaboration, and synthesis of implementable
designs, consistent with principles of STS design and the attributes of effective boundary objects.
We proposed a role for reference architectures as potentially useful artifacts in digital transformation
using an STS design approach. The idea is that RAs could function as boundary objects between
94
different stakeholders in the STS to enable them to balance and optimize the allocation of functions
across the social and technical elements of the digitally-transformed enterprise.
The results of the terminological/conceptual analysis of four representative RAs are inconclusive.
For the moment we are not able to definitively answer the question of whether RAs can be useful
boundary objects and potential tools to support a STS design process for digital transformation. A
summary of the insights gained from the review provides these observations by the respective boundary
object properties:
• Abstraction: The RAs in general are high-level abstractions that can be mapped to some (but not
all) STS design elements. However, the usefulness of RAs as boundary objects is questionable from
an abstraction perspective given the high-level at which they are currently described. Useful STS
design will likely need to take place at more detailed-granular levels of abstraction that are closer
to the actual value-creating activities. The current RAs may therefore be useful to frame the scope
of the STS design discussions, but may not provide substantive content for STS design itself.
• Shared syntax/semantics: Each of the RAs have areas of strength and weakness with respect to
STS syntax and semantics, depending on what areas they emphasize. Overall alignment with the
conceptual framework for STS design is uneven, however. Perhaps STS-oriented guidance from
the conceptual framework could be used in the definition of RAs to help them to be more useful as
boundary objects in STS design.
• Malleability: RAs with greater existing overlap with the attributes in the conceptual framework for
STS design may potentially require less effort to adapt to serve as effective BOs. Some RAs do not
have as much overlap with the STS design attributes and the effort required to adapt them to be
more effective boundary objects could be substantial.
• Stability: All RAs demonstrate stability
• Visualization: Most of the RAs are effective at visualizing the dimensions
In summary, the RAs that were examined are weakest in the areas of abstraction (lack of
concreteness, limited coverage), shared syntax (limited coverage), and malleability (higher cost to adapt
a RA that lacks the necessary attributes). The RAs are strongest in stability and visualization, although
these may not necessarily be the most consequential of the BO attributes. A common theme among the
weaknesses involve limited alignment with STS design conceptual framework and overly-high level of
abstraction. This suggests that the STS design conceptual framework could potentially evolve to serve
as an input to the definition of RAs to enable them to be more effective artifacts in the STS design
process.
This analysis of RAs as boundary objects was made at a high abstraction level using documentation
that is openly available. Without perspective on the application of these RAs in practice, it is
questionable whether this analysis is suitable for deriving relevant implications for practice. This is not
a surprising result. RAs most likely weren’t defined with the STS design use case in mind. They are
descriptive representations of system properties from different viewpoints. The ability to function as
useful boundary objects were not necessarily a priority in their original definition (i.e., they are
conceptually understandable, but not consequential at the level of making architecture decisions,
tradeoffs, and designing solutions). RAs are however malleable artifacts and currently have reputational
advantage among practitioners. This means that they may be the most effective way to engage in
continuous STS design for digital transformation, if they can be tailored to include STS design element
artifacts.
From a theoretical perspective, we believe this analysis paves the way for a more detailed study on
the role of RA in STS design. Specifically, this analysis is based on reference documents, which are by
nature generic descriptions that enable them to apply across a range of application domains. Moreover,
architecture models themselves are descriptive rather than specific in their characterizations of the STS.
Useful boundary objects are situated between domains in a specific context, and thus depend on enough
detail to enable consequential sharing across the boundary. This suggests that to fully explore the
potential benefits of using RAs as artifacts in STS design will require empirical investigation, which
could address these points:
• Our analysis assumes that RAs are employed by enterprises for design actions leading to digital
transformation, and can be used in that role as effective BOs. However, this role should be
investigated empirically to confirm that in fact RAs are being used as assumed, and to verify that
95
the existing intent is to employ them as boundary objects in EA and digital transformation. The
empirical questions are what role are they currently employed in, and what is the intended role?
And how do they function in that role (i.e., how effective are they?)
• Future studies should investigate multiple levels of hierarchical abstraction in which STS design
may occur, and how RAs are employed at each level. RAs may be useful at high levels of
abstraction, but perhaps not so much at lower levels where specific solutions begin to emerge.
While not conclusive in this study, we believe this discussion can help to frame future research that
not only will address the role of RAs as useful artifacts in the design of STS for digital transformation,
but also potentially explore the effectiveness of other artifacts and methods in the STS design process.
The next steps should focus on the collection of empirical evidence to test these ideas and their
effectiveness. We have reason to be confident that these investigations can help to enable digital
transformation initiatives to be more timely and effective in the future.
6. Acknowledgements
The project TRF4p0 - Transformer 4.0 that provided funding in part for this work is co-financed by
the European Regional Development Fund - ERDF, through COMPETE - Operational Program for
Competitiveness and Internationalization (POCI) and by the Foundation for Science and Technology
under the MIT Portugal Program under POCI-01-0247-FEDER-045926.
7. Bibliography
[1] E. Trist, “On socio-technical systems. In, Pasmore, WA & Sherwood,” J JEds Sociotechnical Syst.
Sourceb. San Diego CA Univ. Assoc., 1978.
[2] W. B. Rouse, M. J. Pennock, J. Cardoso, J. Hsu, and R. Curran, “Advances in sociotechnical
systems,” N Adv. Syst. Eng. Rest. VA USA, 2016.
[3] J. J. Korhonen, J. Lapalme, D. McDavid, and A. Q. Gill, “Adaptive Enterprise Architecture for the
Future: Towards a Reconceptualization of EA,” in 2016 IEEE 18th Conference on Business
Informatics (CBI), Aug. 2016, vol. 01, pp. 272–281. doi: 10.1109/CBI.2016.38.
[4] W. Pasmore, S. Winby, S. A. Mohrman, and R. Vanasse, “Reflections: Sociotechnical Systems
Design and Organization Change,” J. Change Manag., vol. 19, no. 2, pp. 67–85, Apr. 2019, doi:
10.1080/14697017.2018.1553761.
[5] P. R. Carlile, and E. S. Rebentisch, 2003. Into the Black Box: The Knowledge Transformation
Cycle. Mgt. Sci. 49(9) pp. 1180-1195, doi: 10.1287/mnsc.49.9.1180.16564.
[6] E. Rebentisch, D. H. Rhodes, A. L. Soares, R. Zimmerman, and S. Tavares, “The digital twin as
an enabler of digital transformation: a sociotechnical perspective,” 2021 IEEE 19th Int. Conf. Ind.
Inform. INDIN, pp. 1–6, 2021, doi: 10.1109/indin45523.2021.9557455.
[7] C. Cimini, A. Boffelli, A. Lagorio, M. Kalchschmidt, and R. Pinto, “How do industry 4.0
technologies influence organisational change? An empirical analysis of Italian SMEs,” J. Manuf.
Technol. Manag., vol. 32, no. 3, pp. 695–721, 2020, doi: 10.1108/JMTM-04-2019-0135.
[8] A. Bockshecker, S. Hackstein, and U. Baumöl, “Systematization of the term digital transformation
and its phenomena from a socio-technical perspective - A literature review,” 26th Eur. Conf. Inf.
Syst. Digit. - Facets Socio-Tech. Change ECIS 2018, 2018.
[9] M. Sony and S. Naik, “Industry 4.0 integration with socio-technical systems theory: A systematic
review and proposed theoretical model,” Technol. Soc., vol. 61, no. March, p. 101248, 2020, doi:
10.1016/j.techsoc.2020.101248.
[10] F. Imran and J. Kantola, “Review of industry 4.0 in the light of sociotechnical system theory and
competence-based view: A future research agenda for the evolute approach,” Adv. Intell. Syst.
Comput., vol. 783, pp. 118–128, 2019, doi: 10.1007/978-3-319-94709-9_12.
[11] R. Davies, T. Coole, and A. Smith, “Review of Socio-technical Considerations to Ensure
Successful Implementation of Industry 4.0,” Procedia Manuf., vol. 11, no. June, pp. 1288–1295,
2017, doi: 10.1016/j.promfg.2017.07.256.
96
[12] S. Thun, O. Bakås, and T. C. B. Storholmen, “Development and implementation processes of
digitalization in engineer-to-order manufacturing: enablers and barriers,” AI Soc., no.
0123456789, 2021, doi: 10.1007/s00146-021-01174-4.
[13] C. Münch, E. Marx, L. Benz, E. Hartmann, and M. Matzner, “Capabilities of digital servitization:
Evidence from the socio-technical systems theory,” Technol. Forecast. Soc. Change, vol. 176, no.
October 2021, p. 121361, 2022, doi: 10.1016/j.techfore.2021.121361.
[14] K. Osmundsen, J. Iden, and B. Bygstad, “Digital Transformation: Drivers, Success Factors, and
Implications.,” in Proceedings of MCIS 2018, 2018, p. 37.
[15] L. Hannola, F. Lacueva-Pérez, P. Pretto, A. Richter, M. Schafler, and M. Steinhüser, “Assessing
the impact of socio-technical interventions on shop floor work practices,” Int. J. Comput. Integr.
Manuf., vol. 33, no. 6, pp. 550–571, 2020, doi: 10.1080/0951192X.2020.1775296.
[16] A. Vereycken, M. Ramioul, and M. Hermans, “Old wine in new bottles? Revisiting employee
participation in Industry 4.0,” New Technol. Work Employ., pp. 44–73, 2020, doi:
10.1111/ntwe.12176.
[17] L. L. Li, H. Li, F. Gu, N. Ding, X. J. Gu, and G. F. Luo, “Multidisciplinary collaborative design
modeling technologies for complex mechanical products based on digital twin,” Comput Integr
Manuf Syst, vol. 25, no. 6, pp. 1307–19, 2019, doi: 10.13196/j.cims.2019.06.001.
[18] E. Bartezzaghi, R. Cagliano, F. Canterino, M. Guerci, S. Gilardi, and E. Shaba, “Joint
organizational design 4.0: Revisiting the socio technical principles,” CEUR Workshop Proc., vol.
2789, no. December, pp. 110–120, 2020.
[19] A. A. Imanghaliyeva, P. Thompson, P. Salmon, and N. A. Stanton, “A Synthesis of Sociotechnical
Principles for System Design,” Adv. Intell. Syst. Comput., vol. 955, pp. 665–676, 2020, doi:
10.1007/978-3-030-20227-9_63.
[20] B. Cameron, E. Crawley, and D. Selva, Systems Architecture. Strategy and product development
for complex systems. Pearson Education, 2016.
[21] S. Kotusev, “The History of Enterprise Architecture: An Evidence-Based Review,” J. Enterp.
Archit., vol. 12, pp. 29–37, Apr. 2016.
[22] M. Zelm, F. B. Vernadat, and K. Kosanke, “The CIMOSA business modelling process,” Comput.
Ind., vol. 27, no. 2, pp. 123–142, Oct. 1995, doi: 10.1016/0166-3615(95)00018-2.
[23] T. J. Williams, “The Purdue enterprise reference architecture,” Comput. Ind., vol. 24, no. 2, pp.
141–158, Sep. 1994, doi: 10.1016/0166-3615(94)90017-5.
[24] R. Abraham, “Enterprise Architecture Artifacts as Boundary Objects - A Framework of
Properties,” in Proceedings of the 21st European Conference on Information Systems (ECIS 2013),
AIS Electronic Library (AISeL), Jun. 2013, p. 120. [Online]. Available:
http://www.alexandria.unisg.ch/223501/
[25] E. Y. Nakagawa, P. O. Antonino, F. Schnicke, R. Capilla, T. Kuhn, and P. Liggesmeyer, “Industry
4.0 reference architectures: State of the art and future trends,” Comput. Ind. Eng., vol. 156, p.
107241, Jun. 2021, doi: 10.1016/j.cie.2021.107241.
[26] A. Fayoumi and R. Williams, “An integrated socio-technical enterprise modelling: A scenario of
healthcare system analysis and design,” J. Ind. Inf. Integr., vol. 23, p. 100221, Sep. 2021, doi:
10.1016/j.jii.2021.100221.
[27] J. J. Korhonen and J. Poutanen, “Tripartite Approach to Enterprise Architecture,” J. Enterp.
Archit., vol. 9, no. 1, pp. 28–38, 2013.
[28] J. J. Korhonen and M. Halén, “Enterprise Architecture for Digital Transformation,” in 2017 IEEE
19th Conference on Business Informatics (CBI), Jul. 2017, vol. 01, pp. 349–358. doi:
10.1109/CBI.2017.45.
[29] “ISO/IEC/IEEE 42010: Conceptual Model.” http://www.iso-architecture.org/42010/cm/ (accessed
Jun. 08, 2022).
[30] R. Cloutier, G. Muller, D. Verma, R. Nilchiani, E. Hole, and M. Bone, “The Concept of Reference
Architectures,” Syst. Eng., vol. 13, no. 1, pp. 14–27, Mar. 2010, doi: 10.1002/SYS.20129.
[31] Industrial Internet Consortium, “The Industrial Internet of Things. Volume G1: Reference
Architecture v1.9.” 2019. [Online]. Available: https://www.iiconsortium.org/pdf/IIRA-v1.9.pdf
[32] S. Kotusev and S. Kurnia, “The theoretical basis of enterprise architecture: A critical review and
taxonomy of relevant theories,” J. Inf. Technol., vol. 36, no. 3, pp. 275–315, Sep. 2021, doi:
10.1177/0268396220977873.
97
[33] S. L. Star and J. R. Griesemer, “Institutional Ecology, `Translations’ and Boundary Objects:
Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39,” Soc. Stud.
Sci., vol. 19, no. 3, pp. 387–420, 1989.
[34] S. L. Star, “This is Not a Boundary Object: Reflections on the Origin of a Concept”, Science,
Technology, & Human Values, 2010, vol.35, no. 5, pp. 601-617.
[35] M. Uslar and S. Hanna, “Model-driven Requirements Engineering Using RAMI 4.0 Based
Visualizations,” in Joint Proceedings of the Workshops at Modellierung 2018 co-located with
Modellierung 2018, Braunschweig, Germany, February 21, 2018, 2018, vol. 2060. [Online].
Available: http://ceur-ws.org/Vol-2060/
[36] M. Panarotto, M. Bertoni, and C. Johansson, “Using models as boundary objects in early design
negotiations: Analysis and implications for decision support systems,” J. Des. Res., vol. 17, no. 2–
4, pp. 214–237, 2019, doi: 10.1504/JDR.2019.105762.
98