MODELING INCREASINGLY COMPLEX
SOCIO-TECHNICAL ENVIRONMENTS
I.T. Hawryszkiewycz
University of Technology, Sydney, U.S.A.
Keywords: Collaboration, social networks, modelling.
Abstract: The paper focuses on modeling large open information systems. These are systems composed of many
activities, which include relationships between activity participants to create new knowledge and services.
The systems are further complicated by the changing nature of both the activities and relationships. The
paper proposes increased emphasis on modelling work and social structures and using the models to
generate role based interfaces. It illustrates the application to the design of complex outsourcing systems.
1 INTRODUCTION
Greater trends to organizational agility have
increased the complexity of information systems,
especially where group dynamics are a key element
to system operation. The complexity has increased
because of the growing nature of interdependencies
of knowledge workers (Davenport, 2005),
organizational structure, technology and tasks in the
global environment, where teams often coordinate
their activities and select their work practices. This
complex set of relationships, when supported by
technology, is now often referred to as a “socio-
technical system”. Support for such systems requires
the provision of an effective infrastructure that
enables knowledge workers to easily connect and
interact with each other by adapting the
infrastructure services to the evolution of their work.
There are few widely accepted methodologies to
support the design and evolution of socio-technical
systems and the connectivity and interactivity that
characterize their open nature. The options available
to designers are shown in Figure 1. These are;
• Adopt methods from the deterministic
methodologies, in particular object modeling
and often attempt to re-engineer what are
predominantly open systems.
• Do nothing but give people access to tools and
resources that facilitate communication, for
example, e-mail, meetings and travel, and
• Adopt a systematic approach to the design of
such systems to provide a balance of effective
computer support combined with effective
meeting.
Flexible
interfaces
Problem and intention
New business model
Specify technology
Problem and intention
New business model
Specify technology
Construct
requirements
process
Transaction
interface
Mechansitic
part
Socio-technical
system
Mechanize all parts
Do nothing
Develop systematic
approach
Patterns
Figure 1: Design Options.
This paper addresses the third of these. It
describes a systematic way of describing business
activities and matching the work patterns to each
activity. The work patterns are then integrated into
one work diagram that is used to specify role based
interfaces.
Primarily the design goal is to align social,
economic and information technology structure
while causing least disruption to existing
relationships. This design goal is supported by many
writers as for example Iqbal (2005), who proposes a
set of heuristics as guidelines for analysis or
Sutcliffe (2005) who stresses the importance of
small group analysis. The ultimate outcome is an
infrastructure and the services needed to support the
complex business relationships and provide ways for
111
T. Hawryszkiewycz I. (2008).
MODELING INCREASINGLY COMPLEX SOCIO-TECHNICAL ENVIRONMENTS.
In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 111-116
DOI: 10.5220/0001678901110116
Copyright
c
 SciTePress

users to dynamically change their platforms to match
changing relationships in work activities. It is to get
away from using personal computers and laptops
and over reliance on e-mail and provide a platform
that closely matches work practices. The ultimate
requirement is to support better connectivity
between process participants and ways for them to
interact in productive ways while changing their
work practices. This connectivity should be related
to a context to relieve users of maintaining their own
contexts and moving information between different
systems, thus having a negative effect on
satisfaction, quality and productivity. The paper
focuses on modelling such complex relationships to
define specific needs. The main aspect is emphasis
on integrating business relationships into business
activities and support them with customized role
based interfaces.
2 MODELING
SOCIO-TECHNICAL
PROCESSES
Figure 2 illustrates the major dimensions to be
addressed in modeling. This paper focuses on the
social and work network, here called the
collaborative network, and the conversion of the
model to technical support systems.
SUPPORT SERVICES
SOCIAL and WORK NETWORK
Connectivity through context
service service service service service serviceservice service service
Activity
1
Activity
2
Activity
3
Stage 1
output
Stage 2
output
Roles
Activities
Tasks
Artifacts
Participants
Lightweight
infrastructure
to provide
services for
work support
Human
resource
policy for staff
management
Process
support for
work
organization
Figure 2: The Major Dimensions of Modeling Complex
Relationships.
The central part of Figure 2 as proposed by
Rizzo (2006) is the activity model that describes the
work activities. The main objects here are the
activities, the activity roles and the context.
Participants can then undertake particular roles. The
social structure in this case provides the way to
explicitly show the relationships between
participants within and between the roles. People are
assigned to the roles based on policies followed with
the organization or alliance. The way they interact is
described by the social or work network. The social
part is modeled by what is here called a work
diagram, which illustrates the relationships between
the roles. The work network in this sense describes
the interactions that must take place between people
assigned to the various roles to satisfy the work
requirements. A social network would also include
any informal communication between the role
participants. The work carried out within the
activities is supported by services. These services
are to be provided through lightweight platforms that
allow such services to be adapted to the work
practices followed by the role participants.
At the work network level construct
communication patterns (Dustdar, Hoffman, 2007)
and use these as a metaphor in providing services.
We can for example say “this is like a brokering
activity which needs the following communication
support”. This approach parallels that of Oates and
Fitzgerald (2007) who are suggesting a multi-
metaphor approach to design. We thus have a
combination of the multi-method approach where
particular designers choose the set of phases, as
suggested by Rizzo (2006) and then use heuristics in
each phase possibly basing each phase on a
particular metaphor or guideline. Rizzo furthermore
suggests that activity be used as the unit of analysis.
2.1 Modeling the Relationships
The central modelling approach is shown in Figure
3. It is made up of three components, which are
used to specify flexible workspaces or what are
sometimes known as lightweight technologies as
shown in Figure 3. This becomes the link between
the social and technical parts of the socio-technical
system. The important aspect here is to introduce
models that themselves are dynamic in nature to
create a dynamic implementation that follows the
connections between participants rather any formal
workflow specification.
Business
activity diagram
Collaboration
graph
Knowledge
requirements
Link through
role definitions
Create customized
workspace for
each role
I
d
e
n
t
i
f
y
l
i
n
k
s
t
o
o
t
h
e
r
r
o
l
e
s
E
n
t
e
r
c
o
n
t
e
x
t
o
f
c
o
l
l
a
b
o
r
a
t
i
o
n
I
d
e
n
t
i
f
y
c
r
i
t
i
c
a
l
c
o
n
d
i
t
i
o
n
s
Process
(Scenarios)
(Collaborative
Database)
Infrastructure
to generate
role-based
interfaces
Figure 3: Following with an implementation.
The role of infrastructure is important here as it
should be possible to use infrastructure services to
ICEIS 2008 - International Conference on Enterprise Information Systems
112

create workspaces for different roles and easily
change them as needed.
The central part of the integration is to describe
the business activities using a set of well defined
terms and then match the descriptions to the work
patterns. The parameters for describing activities
are:
• The kind of work in the activity
(Davenport, 2005). The categories here are
transactional work, integrative work such as
that found in system development,
collaborative work and expert work,
• Management level based on Anthony’s
framework of strategic, management and
operational level, and
• Process focus which may be planning,
coordination or task execution.
One design goal may be to create activities
which are focused on a clear set of parameters – they
are made up of one work kind with one focus
performed at one management level. For example
the creation of an artefact can be a task execution at
an operational level that requires an integrative work
kind. Another example, creating a project plan is a
task execution at management level and requires
collaboration between a number of people.
Although ideally we may wish to simplify a design
by designing well defined activities this is often not
possible. For example the development of a plan
may need to be closely linked to actual task
execution where organizations must respond to a
changing situation.
Activity Analysis
Kind of work
Management Level
Process Focus
Scope
Size of group
Number of activities
Selecting social
structure patterns
Task Execution
Transactional
work
Int egra tive
work
Collaborative, Coordination and Task
Execution
Coordinator
Facilitator
Selected pattern
Example
patterns
Figure 4: The guidelines framework.
For example, Figure 4 illustrates two such
collaborative patterns. Here each black dot is a role.
One is where work has one focus – task execution.
The pattern depends on the type of work. If it is
transactional then usually work passes from role to
role. Here people who take the roles simply pass
work between themselves, or carry out their
individual tasks in accordance with a fixed plan.
Where the work is integrative then usually a
facilitator is needed to ensure integration. The other
pattern is where coordination and task execution are
needed in the same activity. Here there can be a
number of groups each working on one task, but
whose work must be coordinated. Agility requires
activities to be continuously monitored and organize
changes to the tasks carried out by each task group.
There are of course many other patterns to be used
in the selection process.
2.2 An Example
Outsourcing is an example one such system.
Contemporary outsourcing situations can be quite
complex in nature. Outsourcing presents one such
system, which is an outsourcing arrangement that
includes a number of organizations. Often such
outsourcing arrangements are quire complex as for
example shown in Figure 5, which is a simplified
form of an ongoing practical case study. Here the
process service provider maintains a service (which
may include a number of applications) and
subcontracts the provision of application programs
for a third party, the software vendor. At the same
time there is the network provider , who supports the
network, operating systems required by the three
alliance members. Different roles, which are shown
on the business activity diagram, are associated with
each of these organizations and they must
collaborate to resolve any issues. In this case the
initial analysis indicates a business requirement to
maintain a quality of service to the client through
response to queries and general maintenance of a
level of client satisfaction.
Provider contracts to support
the sales application for a
client
Provider leases application
software from a vendor and
customizes it to client needs
Service provider is obliged to
provide a quality of service
and respond to any requests
from the client’s customers
Application vendor agrees to
amend application software
should the need arise and to
assist in the correction of any
faults and installation of
software upgrades
ClientClient
Software
vendor
Software
vendor
Process
service
provider
Process
service
provider
Network
provider
Network
provider
Provides network at agreed
quality of service
Figure 5: An outsourcing business arrangement.
2.3 Top level – Identify the Major
Activities
The important concepts in this case are the high
level business activities and the roles and
MODELING INCREASINGLY COMPLEX SOCIO-TECHNICAL ENVIRONMENTS
113

Arrange
program change
Arrange
program change
Resolve
service report
Resolve
service report
Sales
contract
Operations
manager
Operations
manager
Vendor
manager-sales
AgentAgent
Client
manager
Service
reports
Receive
service report
Receive
service report
customercustomer
Record service
report
Record service
report
Team
member
Team
member
Team
leader
Team
leader
Client
contract
Outsourcing
management
Outsourcing
management
Customer
sales
Sales recordingSales recording
Client
salesperson
Client
salesperson
Issues
Transactional,
operational
with task focus
Includes integrative and
collaborative work at
both operational and
management levels
that includes task and
coordination focus
Collaborative work at
operational level with a
task focus
Transactional,
operational
with task focus
Collaborative,
operational
with task focus
Integrative,
management with
coordination focus
Figure 6: A Business Activity Model.
relationships between them as well as the artifacts
they use. We call this the business activity diagram.
Figure 6 is an example of such a high level in the
context of resolving trouble reports in an
outsourcing arrangement. The diagram also shows a
description for each activity. For example:
“Receive service report” and “Sales recording”
are both operational with a task focus usually of a
transactional nature,
“Resolving a service report” can be classified as
at the operational management level, often of a
collaborative nature.
“Arrange program change”, which may result
from a service report and has a mix of different work
kinds and hence should probably be decomposed
into two activities, one to decide what change is
needed and the other to coordinate the change
implementation.
2.4 Collaborative Graph
The work network is now constructed using the kind
of approach illustrated earlier in Figure 4. We look
at the activity description and match a social pattern
to the activity. A different pattern is constructed for
each of the teams, which are primarily collaborative
at the operational management level and focus on
task execution. There are then the overlapping
activities of coordinating any software changes with
the software vendor and coordinating a response to a
customer. In addition a transient team may be
constructed to resolve an urgent issue. The
collaborative graph is shown in Figure 7, which also
identifies the activity that was used to generate parts
of the work network.
3 SPECIFYING TECHNICAL
SUPPORT SYSTEMS
The technical component has a two part role –
infrastructure support and individual, support. This
corresponds to the bricks and bits suggested in
(Fruchter, 2001) where the bricks build the global
support and the bits are what is provided to user. The
kind of infrastructure needed is primarily of a
lightweight nature. Some earlier work
(Hawryszkiewycz, 2007) described the kinds of
lightweight workspaces for different kinds of
activities, ranging from lightweight exchange to
process support. Each of these provides a range of
services needed by a particular activity type.
The goal is to allow each role to have a
customized interface with access to a common
context. The role responsibilities are identified from
the business activity diagram from the activities in
which the role participates. These activities are
included in the role interface as that shown in Figure
8 for the network manager (with sensitive data
suppressed). The interface also includes access to all
roles connected to the role in the work network to
encourage informal interaction. The goal is to allow
each role to have a role specific interface with access
to a common context. The role responsibilities are
identified from the social network analysis by
identifying the activities of the role and presenting
them in the role interface.
ICEIS 2008 - International Conference on Enterprise Information Systems
114

a2
a3
a1
a4
Operations manager
Development
mgr
Sales operations
af2
af3
Sales fix
af1
af4
Client manager
Vendor mgr
(sales)
Vendor mgr
(sales)
Agent
a2
a3
a1
a4
Service operations
Customer
Transient
issue team
Team
leader
Coordinator
Issue
definer
Solution
supplier
Arrange program change
Receive and record
service report
Resolve service report
Figure 7: The Collaboration Graph.
Manager
data
Client
data
system
Figure 8: An interface for the network manager.
4 SUMMARY
This paper described the components that now
make up many of the emerging systems, which are
needed to support dynamic networked enterprises
within global environments. These are characterized
by closely linked activities and communication
patterns between the activity participants. The paper
identified the need to focus more on these
communication patterns in system design and
suggested ways of fin\ding the best patterns by
matching them to activity descriptions. It described a
way of describing such activities and illustrated an
application to an outsourcing system.
REFERENCES
Davenport, T. (2005): “Thinking for a Living” Harvard
Business School Press.
Dustdar, S. and Hoffman, T. (2007): “Interaction pattern
detection in process oriented information systems”
Data and Knowledge Engineering, Vol. 62, Issue 1,
July 2007, pp. 138-155.
Hawryszkiewycz, I.T. (2007): “Lightweight Technologies
for Knowledge Based Collaborative Applications”
Proceedings of the IEEE CEC/EEE2007 Conference
on E-Commerce Technology, Tokyo, July 2007, pp.
255-264.
Hermann, T., Hoffman, M., Jahnke, I., Kienle, A. Kunau,
G., Loser, K-U, Menold, N. (2003): “Concepts for
MODELING INCREASINGLY COMPLEX SOCIO-TECHNICAL ENVIRONMENTS
115

Usable Patterns of Groupware Applications”
GROUP’03, September, 2003, Sanibel Island, Florida.
Herrman, T., Kunau, G., Loser, K-U., Menold, N. (2004):
“Socio-technical Walkthrough: Designing Technology
along Work Processes” Proceedings Participatory
Design Conference 04, Toronto, Canada,.
Fruchter, R. (2001): “Bricks and Bits and Interaction”
JSAI Workshops, 2001, pp. 35-42.
Iqbal, R, Gatward, R., James, A. (2005): “A General
Approach to Ethnographic Analysis for System
Design” SIGDOC’o5, September, 2005, Coventry,
UK.
Oates, B.J., Fitzgerald, B. (2007): “Information Systems
Journal, Vol. 17, No. 4. October 2007, pp. 421-449.
Rizzo, A. Pozzi, S., Save, L., Sujan, M. (2006):
“Designing complex socio-technical systems: A
heuristic schema based on Cultural-Historical
Psychology” Proceedings of the 2005 annual
conference on European association of cognitive
ergonomics, pp. 71-81
Sutcliffe, A. (2005): “Applying Small Group Theory to
Analysis and Design of CSCW Systems” Human and
Social Factors of Software Engineering, May, 2005,
St. Louis, Missouri.
ICEIS 2008 - International Conference on Enterprise Information Systems
116