Proceedings of the 8th International Conference on Intellectual ...

Igor Hawryszkiewycz
between communities. For example, <strong>the</strong> collaboration between application developers and vendor
s<strong>of</strong>tware creates new knowledge <strong>of</strong> how vendor s<strong>of</strong>tware can be used to create applications that
satisfy user requirements.
Customer
knowledge
community
Client liaison
Monitoring
Customer CustomeCommunity
r
System
performance
Infrastructure
knowledge
community
Process
requirements
Client
manager
Infrastructure
manager
Figure 2: Communities in process outsourcing
2.2 Modeling <strong>the</strong> system
Coordination
Community
Operations
manager
Application
knowledge
community
Vendor
manager
Application
program
Vendor
s<strong>of</strong>tware
knowledge
community
Vendor
s<strong>of</strong>tware
Modeling tools in such environments must be able to combine selected concepts to model
relationships between communities. It should be sufficiently flexible to show any <strong>of</strong> any number <strong>of</strong>
selected relationships. The modelling method described here is implemented on <strong>the</strong> open modelling
platform at <strong>the</strong> University <strong>of</strong> Vienna. The method known as MelCa allows models to be set up from
different perspectives and maintains cross references between models as allowed by <strong>the</strong> open
modelling platforms. New objects can be easily added to each perspective. The concepts for each
perspective are shown in <strong>the</strong> center and can be easily selected and plugged into <strong>the</strong> model.
Figure 3 shows <strong>the</strong> high level community structure illustrated in Figure 2. It shows communities, roles
and artifacts that were described in Figure 2. The roles are represented by circles and communities by
organizational symbols. There is a link between <strong>the</strong> roles and communities. Notes can be attached to
all components.
An aggregation feature, shown as <strong>the</strong> shaded areas, can be used to identify <strong>the</strong> coordination or
monitoring communities. For example, <strong>the</strong> roles responsible for <strong>the</strong> four communities all participate in
goal setting. These goals are implemented as contracts between <strong>the</strong> different parties.
The modeling method can <strong>the</strong>n be used to look at knowledge responsibilities within <strong>the</strong> system. It can
also define <strong>the</strong> services needed. To this <strong>the</strong> knowledge communities are described in more detail.
2.3 Expanding to information flows
Figure 4 shows a detailed model <strong>of</strong> <strong>the</strong> application knowledge community. It uses <strong>the</strong> idea <strong>of</strong> an
Enterprise Social Network (Hawryszkiewycz, 2010) to model knowledge flows in enterprises. The
ESN shows <strong>the</strong> responsibilities <strong>of</strong> roles and interactions between <strong>the</strong>m. Figure 4 shows a number <strong>of</strong>
additional roles found in <strong>the</strong> application knowledge community. The main additional roles are:
The fault coordinator to take responsibility for dealing with any fault reports raised by <strong>the</strong> system
clients, and
The development manager who takes responsibility for implementing any agreed changes from
<strong>the</strong> client.
229