Information Technology Reference
In-Depth Information
Kellogg, & Rosson, 1992). When the artifact
changes, the object is likely to change as well.
The professional domain is ambivalent in that it
belongs to multiple categories and we treat it as a
“boundary object” between two activity systems.
But there are other dependency relationships and
analytic categories as well. Subjects, artifacts,
and objects are affected by the existing rules,
the community in which the activity occurs, and
the division of labor within this community. We
analyze the following topics in more detail in the
following subsections:
the professional developers talk about VB together,
it is important that they have a shared object in
mind or in front of them to ground the discussion.
This can be the goal of the activity (e.g., tailoring
VB) but more often it is the profession-oriented
language of the domain. The latter provides the
necessary pre-understanding for using and fur-
ther developing the application. We see both of
them as boundary objects (one concrete the other
abstract)
.
Previous studies have shown that both
the “application system language” and the profes-
sion-oriented language of the domain have to be
learned for collaboration between developers and
users to succeed (Nygaard, 1984).
It was the opinion among all employees inter-
viewed that it was positive to have a super user
acting as the local expert at each office. This
made it possible to have a professional discussion
of accounting issues with the confidence that the
super user could understand the problems the
employees were experiencing. It was also com-
monly accepted that technical competence and
the ability to grasp new knowledge quickly were
very important requirements for being a super
user. One of the super users put it this way:
•
The profession of accounting as a boundary
object;
The VB application as a meditating arti-
fact;
The division of labor among the different user
groups and developers.
•
•
The first topic is of special importance in that
it stands as a prerequisite for the other two. It con-
cerns the process that leads up to EUD, whereas
the other two show the results after a boundary
object has been successfully established.
the profession of accounting as a
boundary object
I think it is important to have both. We noticed
it at the same time we converted to VB, when we
called the support unit. Many of them managed
the technical bit, but nobody had any clue about
accounting. It was a problem. When the super
users are here in the house they use the same ap-
plications. We talk the same language.
Star and Griesemer (1989) introduced boundary
objects as objects that are both flexible enough
to adapt to local needs and constrained enough
to allow several parties to employ them for their
own purposes. These objects are robust enough
to maintain a common identity across commu-
nities (activity systems). Boundary objects can
be both abstract and concrete and they have dif-
ferent meanings in different communities. The
creation and management of boundary objects
thus becomes a key task in order to develop and
maintain coherence across interacting activity
systems
.
When regular users, super users, the applica-
tion coordinator (local developer), and sometimes
The employee here points to the importance
of a shared understanding (boundary object) by
saying that the super users need to have the same
common understanding of the problem as the
person stating the problem. They interact within
the same community of practice (Wenger, 1998)
as the regular users, where the shared object repre-
sented by accounting constitutes the basis for the
collective competence that develops. This is what,
in the context of traditional system development,
Search WWH ::
Custom Search