Document theory for the design of socio‐technical systems. A document model as ontology of human expression
| Pages | 100-126 |
| Published date | 13 January 2012 |
| DOI | https://doi.org/10.1108/00220411211200347 |
| Date | 13 January 2012 |
| Author | Bernt Ivar Olsen,Niels Windfeld Lund,Gunnar Ellingsen,Gunnar Hartvigsen |
| Subject Matter | Information & knowledge management,Library & information science |
Document theory for the design of
socio-technical systems
A document model as ontology of human
expression
Bernt Ivar Olsen
Department of Computer Science, University of Tromsø, Tromsø, Norway
Niels Windfeld Lund
Department of Documentation Studies, University of Tromsø, Tromsø, Norway
Gunnar Ellingsen
Department of Clinical Medicine, University of Tromsø, Tromsø, Norway, and
Gunnar Hartvigsen
Department of Computer Science, University of Tromsø, Tromsø, Norway
Abstract
Purpose – This conceptual article aims to discuss how the concept of a document and documentation
along with a general document model could inform us in the design and engineering of information or
rather documentation systems.
Design/methodology/approach – This paper presents a broad and complementary document
model, derived from the last couple of decades’ discussion on what is a document and what is
documentation. This model is used as a basis for a method, a conceptual tool or a template for analysis
of socio-technical systems.
Findings – The authors contend that the document systems analysis is a holistic approach compared
to the traditional systems design and engineering reductionist approach, and also in the context of
sociotechnical systems design. The document model is a taxonomy of the constituents of the document
and, the authors argue, a potential communication tool in systems design.
Research limitations/implications – The document model presented in this article is discussed
more or less solely in the context of information systems design, specifically sociotechnical systems.
Moreover, the authors have tried to fit the theory and model within this context here, even though the
concepts and thoughts can have much more general implications.
Practical implications – This presentation of a novel document model and framework is presented
as a potential tool for systems analysis and design. The authors regard this as a realistic vision for the
framework, but at the current stage of development for the model it is probably more useful as draft
for such a tool or framework; a point of departure for the discussion of practical – and theoretical –
implications of a broad and holistic document model.
Originality/value – A novel, unpublished document model, derived from theoretical discourses
of document ontology in the “neo-documentalist” movement spawned from a particular research
community in Tromsø, Norway, is presented and discussed in the light of information systems
design.
Keywords CSCW, Boundaryobjects, Conceptual modeling, Documenttheory,
Information systemsdesign, Sociotechnical systemsdesign, Document management,
Information systems
Paper type Conceptual paper
The current issue and full text archive of this journal is available at
www.emeraldinsight.com/0022-0418.htm
JDOC
68,1
100
Received 14 November 2010
Accepted 5 May 2011
Journal of Documentation
Vol. 68 No. 1, 2012
pp. 100-126
qEmerald Group Publishing Limited
0022-0418
DOI 10.1108/00220411211200347
1. Introduction and motivation
Building information systems to support and even enhance human interaction is a
complex task. Building large information systems is in itself not an easy undertaking,
which also requires understanding of the environment that the system is to operate
within and communication of this understanding to the engineers and designers who
ultimately decide what the system should be like. Apart from this, the process of
building such systems is also a complex matter, as large software engineering projects
involves having up to several hundreds or more people collaborating to produce a
compound of software artifacts, potentially containing millions of lines of code. These
artifacts are also meant to communicate and collaborate between themselves and the
people that make use of them in their daily work in a – as much as possible – flawl ess
manner.
Building information, communication or interaction systems is basically a process
that goes somewhat like this: Someone realizes a need for an information system (“The
System”) and sets out to find someone else with the ability of making a system to fit
their needs. The “someone else” – let us call them Software Design, Inc. – then needs to
create an understanding of what The System needs to do – and to crea te an agreement
with the principal (Someone) on this issue. Furthermore, Software Design, Inc. needs to
create an internal understanding of how to reach a final version of the system, and to
allocate resources in terms of software engineers and designers, systems analysts and
others, in addition to material components in order to reach that goal – and, of course,
plan a timeline in order to get there. The conceptual or abstract view of The System is
already from the very start differing between the principal and Software Design, Inc.,
where, to take an example from the medical domain, a hospital, or several hospita ls
called HealthPartners, Inc., wanting to have a hospital information system that
manages their patients and their resources to treat patients in the hospital in such a
way that they get the highest possible patient care with the least possible resources.
Software Design, Inc., having won the contract to build the system in competition with
several other software vendors, wants to help HealthPartners achieve its goal, while
also doing so within the budgets that it have made in order to win the contract.
One could also include other, overarching issues and requirements from political or
national points of view, but it suffices to conclude that there are even additional actors
and mechanisms that go into this system, both from the top of the system (political)
and from the bottom (individual/personal).
From this very brief and cartoonish view of (large-scale) information systems
design, we can see that there are many interfaces between different layers in a
hierarchy of stakeholders in a project where communication of system goals might go
wrong. And there are many more layers and groupings of different kinds of pe ople that
are involved in this process, both within Software Design, Inc. and within the hospitals.
What we argue to be missing in this context are communication artifacts that can be
used across several or all levels of the hierarchy of design of systems; artifacts that are
both structured and specific when needed and that can also “paint” a more loose
description of the system and the parts, components and pieces of it in order to create a
coherent view and (mental) model of the system. These kinds of artifacts are commonly
denoted “boundary objects” (Star, 1989). Our proposal is to suggest to conceive these
artifacts as documents, on the basis of a broad and complementary document model,
which will act as such communicators of an if not completely common (we will not
Design of
socio-technical
systems
101
To continue reading
Request your trial