Towards Data Awareness by Socio-technological Knowledge
Management
Alexander Heußner, Moritz H
¨
oser and Sven Ziemer
Knowledge Management, Bauhaus Luftfahrt e.V., Willy-Messerschmitt-Str. 1, Taufkirchen, Germany
Keywords:
Data Awareness Challenge, Diagrammatic, Multi-perspective Modelling, Multi-modal Knowledge.
Abstract:
In today’s data-centric world, the data-awareness challenge is a crucial touchstone to existing knowledge man-
agement technologies. Adaptive, stakeholder-centric knowledge modelling approaches provide a solid ground
to tackle this challenge and open the door to enrich knowledge management by a socio-technological perspec-
tive. This paper proposes the use of a socio-technological approach to overcome the data-awereness challenge
by treating knowledge on data as a crucial business asset. Here, a data awareness generating, iterative, incre-
mental knowledge elicitation technique based on a multi-perspective, multi-modal diagrammatic knowledge
representation language serves as proof of concept.
1 INTRODUCTION
Data-driven software systems and data-based analy-
ses are the engines of today’s innovative businesses.
The key to start and operate such an engine is the
awareness an organization and its individual stake-
holders have of their data, its context and meta-data as
well as the corresponding implicit background know-
ledge. Establishing this data-awareness and address-
ing the awarenss challenge requires knowledge man-
agement (KM) to treat knowledge on data and not
only data itself – as crucial business asset.
Thesis. Data awareness within an organization
in the sense described above can only be estab-
lished when a socio-technological perspective on the
involved stakeholders is included. Thus, we need to
rethink knowledge technologies and methods to (self-
) adapt to the needs of the individual stakeholders and
their multiple views, and not the other way round.
Setting. Knowledge assessment in an enterprise set-
ting requires to make knowledge on existing data, data
sources, corresponding meta-data on data quality, and
the related context knowledge. The results are tangi-
ble knowledge shared by the whole organization for
all participating stakeholders, e.g. from management
over IT to physical, industry workers – thus, deriving
an overview over the “data landscape”. Each stake-
holder represents different domains and functions and
has an individual perspective on the data, including
its context, that is processed by a system. The ac-
ceptance of a system depends on how well the sys-
tem is capable of reflecting the different user prior-
ities and perspectives and of facilitating knowledge
sharing among the stakeholders.
Knowledge elicitation as part of the requirements
analysis phase when developing next-generation data-
(& knowledge-)based enterprise information systems,
e.g. in the context of Industry 4.0, should there-
fore extend its mindset as well as its applied meth-
ods and tools, to include a socio-technical perspec-
tive. Existing methods and tools such as UML or
BPMN cover mostly the specification and documen-
tation of software systems and processes. What is
needed, is thus the conception and specification of a
method that fit precisly into the required spot: a socio-
technical enbabled method to establish data aware-
ness as part of the requirements analysis phase. Es-
tablishing data awareness is a multi-disciplined task,
where exchanged knowledge must be accessible to all
stakeholders. As data-(& knolwedge-)based informa-
tion systems are rarely developed on the green field,
we need to underpin their architecture and design with
sufficient knowledge on the structure of existing data,
thus making the implicit knowledge (also hidden in
an organization’s hierarchy) and legacy knowledge
accessible for system engineers and data analysts as
well as software developers.
Crucial for the success of knowledge management
techniques is the provision of access to implicit back-
ground knowledge on various hierarchical levels in
the business organization, and the possibility to easily
adapt to each stakeholders’ context and the peculiari-
Heußner, A., Höser, M. and Ziemer, S.
Towards Data Awareness by Socio-technological Knowledge Management.
DOI: 10.5220/0008349602910298
In Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2019), pages 291-298
ISBN: 978-989-758-382-7
Copyright
c
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
291
ties of the domain. In our view, this holistic view on
data awareness is a critical contribution to ensure the
acceptance of data-driven systems to be developed.
Note on Awareness. We utilize the term “awareness”
close to its psychological understanding as “percep-
tion or knowledge of something” and achieving ac-
curate reportability of the perceived process (APA,
2019). We apply awareness both regarding the stake-
holders’ understanding and their self-perception in
the model itself and the underlying context.
This paper presents an approach using a socia-
technological perspective to establish data awareness.
This buttom up and self-adapting approach consists of
a three-step description for involving all participating
stakeholders and a notation for data modelling. The
reminder of this paper is organized as follows: The
awareness challenge is further outlined in Section 2.
In addition, a review of existing approaches to multi-
perspective modelling is given. The proposed method
is presented in Section 3 and conclusions are given in
Section 4.
2 AWARENESS CHALLENGE
We argue that the KM community must devise their
next generation of knowledge management tech-
niques to inherently by design tackle the awareness
challenge. A technique to be proposed consists at
least of a method to elicitate and maintain knowledge
based on a corresponding knowledge representation
language. The challenge can be narrowed to the fol-
lowing set of requirements to such a technique:
It shall address and adapt to multiple stakeholders
with different perspectives on different organiza-
tional layers (viz. Fig. 1);
the underlying representation language shall be
both formal & sound, and thus open to algorith-
mic treatment, but also
shall be easily accessible to the stakeholders, as
accessibility is key for generating awareness;
the formalism shall interweave data, meta-data,
infrastructure and process models;
the elicitation method shall be “minimal invasive”
and not disturb the business and disquiet the stake-
holders in their natural habitat;
hence, a technique shall embed itself into organi-
zation and shall be suitable for everyday use;
but shall also focus awareness from the point of
view of each of the individual stakeholders, i.e.
adapt to each stakeholders individual desidera-
tum;
existing knowledge frameworks (e.g. process
maps, descriptions of IT infrastructure, etc.) shall
be sufficiently included or interfaced as far as ap-
propriate;
the formalism shall bridge the gap between (pos-
sibly existing) formally described processes and
the way it is instantiated, i.e. lived, adapted and
adopted, always anew in everyday business;
Measuring awareness itself and thus evaluating a
solution to the awareness challenge is a scientific bar-
rier. We assume in the following, that a higher aware-
ness leads to a better quality of the underlying busi-
ness process, which is slightly easier to measure.
Regarding Existing Solutions. Existing approaches
on multi-perspective modelling, e.g. (Wood-Harper
et al., 1985) (Curtis et al., 1992) (Stohr and Zhao,
2001), fix to certain set of perspectives regarding a
special application domain and often neglect acces-
sibility by all participating stakeholders. Putting the
stakeholder in the center of modelling, e.g. as in
(Jablonski, 2009), often leads to restrictions in expres-
sivity and readability.
The UML standard offers a range of diagrams as
notation for multi-view artefacts, which can be further
formalized with profiles and viewpoints (Object Man-
agement Group, 2017). However, these extensions to
UML are rather used to formally capture information
from spezialized domains, with current research on
multi-view notation and their consistency (Cicchetti
et al., 2019). Instead, a new formalism is needed that
focuses on accessible views for stakeholders with dif-
ferent background and level of operation.
More business artefact targeted approaches
like artifact-centric process modelling (Nigam and
Caswell, 2003) (Bhattacharya et al., 2007) (Kumaran
et al., 2008) (Cohn and Hull, 2009) miss multi-
ple perspectives and often focus solely high-level
management stakeholders.
Merging process and data modelling pari passu
is still extremely rare, e.g. (K
¨
unzle and Reichert,
2011). Several approaches focus on a data-centric
view on business processes (Sun et al., 2006) (Aalst
et al., 2015), (Deutsch et al., 2009) or anticipate
an object-aware process support (Reichert and We-
ber, 2012), (K
¨
unzle and Reichert, 2011). Other
data-centric modelling approaches research knowl-
edge awareness in process-aware information sys-
tems (Bhattacharya et al., 2009) (Reichert and We-
ber, 2012). Although both UML and BPMN (Object
Management Group, 2013) offer the coexistence of
process and data-related elements, the two concep-
tual models are rarely formally related and used sep-
arately by different teams (De Giacomo et al., 2017).
More recent approaches formalize the connection be-
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
292
tween process and data, especially between BPMN
and UML activity diagrams with a “conceptual view”
(Combi et al., 2018a) (Combi et al., 2018b). Never-
theless, most approaches only seem to provide a com-
plicated fix to existing modelling languages by reduc-
ing their readability, and are, thus, rather far from be-
ing applicable in an everyday setting.
Modelling frameworks often provide a toolbox of
different approaches and strategies to adapt to rather
different application domains and groups of stake-
holders. However, they require to be introduced top-
down with support from an organizations higher level
hierarchy, substantially influence the daily business
(thus are rarely minimal invasive), and do not focus
individual stakeholders and their demands. Though,
these frameworks often address a lot of the other
requirements of the awareness modelling challenge.
For example, ArchiMate (Lankhorst et al., 2009) em-
phasizes communication with the stakeholders and a
multi-viewpoint modelling approach; however, view-
points are restricted to a stakeholder group and the
target is not a holistic model. Also ArchiMate trades
flexibility for formalization and ease of use. Further,
these frameworks need to be established top-down in
an organization often not in a minimal invasive man-
ner. This is another hurdle for assuring the participa-
tion of all stakeholders and their awareness. Similar
objections would hold for other well-established ma-
jor frameworks like IDEF (Bruce, 1992), TOGAF or
IAF (Wang et al., 2016), or ZF (Zachman, 1987).
Supposing accessibility as key to awareness, most
notions of accessibility in practice are boiled down
to cognitive effectiveness or even only readability.
However, accessibility rarely played an initial prin-
cipal role in the design of state-of-the-art established
modelling languages like UML or BPMN (Reijers
and Mendling, 2011) (Moody and van Hillegers-
berg, 2008) (St
¨
orrle and Fish, 2013). Moody’s “The
Physics of Notations” (Moody, 2009) has proposed a
catalogue principles that target this shortcoming and
includes several ideas how to devise a syntactically
based and measurable notion of accessibility. This
catalogue should be taken seriously from the start
when devising a knowledge representation language.
Thus, resolving the complete data awareness chal-
lenge with existing approaches is not straightfor-
wardly possible; especially, as existing approaches
in their practical implementation often mainly focus
the business-technological side that is established in a
top-down manner, and not the social embedding of the
stakeholders, i.e. their self-awareness and long-term
established accountability and responsibility regard-
ing a concrete business process and the correspond-
ing data. Existing frameworks often provide a bou-
IT
Landscape
Process
Organization
Application
Utilisation
Applied
Process
Organizational
Level
Implementation
Level
instance of
Data View Process View
Figure 1: Combining a data and process view in one dimen-
sion with hierarchically different granularity due to differ-
ent systemic levels, we target a sweet spot (“ ”) for multi-
perspective modelling.
quet of different techniques, diagrams, methods, etc.,
to be combined into a set of knowledge tools that are
tailored to a concrete domain. However, these frame-
works and their a priori chosen set of tools not easily
adapt on-the-fly to the stakeholders’ needs and in gen-
eral do not focus data awareness as central concern.
Knowledge Management 4.0. Recently, there are
several tendencies to re-invent knowledge manage-
ment in the context of current technological trends
and in the setting of Industry 4.0, e.g. (North and
Maier, 2019), (North et al., 2018), or (Peinl, 2017).
These are similar in spirit to our approach but focus
on generic, top-down business perspective, whereas
we primarily take a socio-technological, awareness-
focussed angle.
Proposed Path to Tackle the Challenge. Inspired
by the well-established design principles of “keeping
it simple” and leaving out parts that “you aren’t gonna
need” (KISS & YAGNI), we tackle the data aware-
ness challenge by a “bottom-up” approach, starting
from the concrete participating stakeholders and their
embedding in a business process, as follows:
A diagrammatic, multi-perspective modelling lan-
guage that is implicitly accessible to all stakehold-
ers, can be represented sufficiently formal, and is
embedded in
an iterative, incremental elicitation method, sup-
porting the generation of (data) awareness, com-
bined with
a self-adaption along these iterations of the both
language and method itself in a concrete knowl-
edge management situation.
This three step approach helped us to bottom-up
derive a diagrammatic modelling language that, em-
bedded in a suitable knowledge elicitation method,
helped us to establish a data awareness in a practi-
cal setting thus, providing a proof of concept that
the awareness challenge can be tackled by taking a
socio-technological perspective on knowledge mod-
elling, elicitating and maintaining.
Towards Data Awareness by Socio-technological Knowledge Management
293
BusinessProductionInformation
Flow
Machine 1 Machine 2
Process Step 1 Process Step 2
Data Storage Information System
x xx
Workers
(intermediary)
Product
Figure 2: Running Example’s simplified Industry 4.0 pro-
duction context: different layers & perspectives.
3 PROOF OF CONCEPT:
DATA-AWARE MODELLING
We briefly present the diagrammatic knowledge rep-
resentation language devised by following our path
to tackle a concrete practical instance of the aware-
ness challenge. We applied this multi-perspective lan-
guage in a series of elicitation interviews to success-
fully establish a notion of data awareness among all
participating stakeholders.
An Exemplary KM Application. In a recent infor-
mation systems engineering project, two of the au-
thors faced the task of creating a process-spanning
data-inventory in a manufacturing facility in order to
be able to design data analysis applications in the con-
text of enterprise systems. We experienced, however,
the difficulty to harmonize the specific information
from the perspectives of different stakeholder groups,
e.g. workers, process managers and data analysts.
This problem matches the information gap in the ex-
isting perspectives, as we could analyze the informa-
tion provided by the different stakeholder groups sep-
arately but we could not make them accessible for a
joint understanding and could not integrate them into
a holistic model. At its core, this situation is a pro-
totypical instance of the awareness challenge, with
additional intricacies belonging to the manufacturing
domain (e.g. only semi-digitalized data, strong hier-
archical dependencies between the stakeholders,. . . )
– these will be left out in the following discussion.
Exemplarily, a generic Industry 4.0 production
context is represented by Figure 2: A two-step pro-
duction in the physical world is based on preparing a
physical product on Machine 1, which is then moved
to and further processes on Machine 2. Both ma-
chines are operated by Workers and are embedded
into an IT landscape, e.g. reading machine parame-
ters from a database and exchanging information via
the ERP system. Without loss of generality, we as-
sume in the following that each process step runs on
one corresponding machine and that each machine is
operated by one worker. Further, we restrict ourselves
to processes that are chain-like and step-wise (e.g.
no forks, alternatives and joins). However, the pre-
sented approach can be straightforwardly generalized
to cover these more complex process models.
We refer to concrete data objects that are accessed
in a single instantiation of the process, i.e. producing
one concrete product, as data instances. Examples
here are a paper job card that is tracking what takes
place in the production process or machine parame-
ters that are taken from a data base.
Data Awareness Analysis Diagrams. The core of
our approach is a diagrammatic modelling language,
called Data Awareness Analysis Diagrams (DAAD),
that served as a medium for discussions with the dif-
ferent stakeholders. DAAD was derived pragmati-
cally in practice and it is based on a combination of
distinct (formal) diagrams. We provide sufficient for-
mality for this notation derived from practical needs
to see its connection with existing, competing for-
malisms. A rigid formalization of the diagrammatic
formal language is currently in preparation.
Inspiration for DAAD was certainly drawn from
the broad background of diagrams applied in soft-
ware engineering and in the stakeholders’s daily work
practice. Hence, reminiscences to UML class, object,
package and use case diagrams as well as business
process modelling languages are implicit but were
initially not explicitly intended, as the notation grew
from a pragmatic need and was not a priori designed
in a purely theoretic setting. Further, to cover the
needs of a multi-perspective, i.e. holistic, view, we
adapted the 4 + 1, or better n + 1 architectural view
approach of (Kruchten, 1995) to our needs, by orbit-
ing a central diagram with a set of additional “per-
spective” diagrams related to the different views of
distinct stakeholder groups.
To simplify the presentation, we will not draw a
distinction between the view or perspective itself and
its representation in the corresponding diagram in the
following and will not distinguish between the ab-
stract and concrete syntax of the diagrams.
Principal View. In the following, we present these
views inside-out by starting with the central Principal
View. The Principal View combines a data-oriented
with a process-oriented view, and “floats” between the
organisational and the implementational level, as in-
troduced in Figure 1. Thus, this view can be seen as
the nexus of the knowledge elicitation interview tech-
nique. While the Principal View serves as the main
communication anchor for operational users, the sur-
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
294
Material
Cutting Drilling Inspection
:Instruction
:Parts
:Instruction
:Design
:Standard
doc
Input
Output
design
:WorkRecord
:MachineData
table
:Instruction
:Standard
:WorkRecord
:MachineData
:QualityControl
:QualityFeature
:Equipment
:WorkRecord
:Inspection
:Measurement
(a) Principal View: Tracing data instances along the process steps.
OrderStore
AssemblyDB
QualityCtrlSystem
(b) Data Architecture View: Relating data instances to the
storage architecture.
QualityControl
QualityFeature
-setPoint
-location
TestEquipment
-instrument
Measurement
-value
-unit
(c) Data Entity View abstract view on data instances and
their relations.
abstract
& get context
locate
Figure 3: Example DAAD. We only present an excerpt containing three prominent perspectives. Color is applied to connect
entities between the different views, e.g. the QualityFeature data instance is subsumed by the QualityFeature class that can
be found in the Quality Control System in the IT landscape. Different stakeholders can insert their background knowledge in
their “closest” perspective. Then, the other perspectives are updated accordingly. Taking the view from a different perspective
supports any stakeholder to reconsider their position in the underlying business operation and, thus, to gain additional self-
awareness besides the data awareness.
rounding views are pivotal for bridging adjacent do-
main areas.
Supposing a step-wise representation of the under-
lying production process, the basic unit of the princi-
pal view represents one of these steps by the symbol
and relates the data instances accessed in this step.
Each can include additional information, e.g. an
identifier, or description of the machinery used. We
differentiate data instances that are read by actions
in this step, i.e. its input, and those that are writ-
ten, i.e. its output. We depict the input instances
above and the output instances below. See for
example the “Material” step in Figure 3a: Instruc-
tions feed into the Material- and we output (a col-
lection of) parts. Data instance that are updated, i.e.
both read and written, appear both above and below of
, whereas the identity is assured by assigning the
same instance identifier. We resort to depict these data
Towards Data Awareness by Socio-technological Knowledge Management
295
instances similar to object in UML object diagrams.
Thus, we can also add additional information, e.g. ex-
ample documents or screenshots of the user interface
to the corresponding data instances. These data an-
notations build a visual bridge between process and
entity elements for stakeholders from the process do-
main.
In the Principal View, we now combine differ-
ent steps along a temporal axis to sequentially repre-
sent the underlying production process (see Figure 3a:
step sequence from “Material” over “Cutting” and
“Drilling” to “Inspection”). As before, anonymous
objects depict different data instances of the same
type along the process chain, while data instances us-
ing the same identifier (not shown here) represent the
same data object. For example in Figure 3a: The “In-
struction” and “WorkRecord” data from the first steps
are from the same IT system. Recall that without loss
of generality we assumed these processes to be linear,
i.e. chains, only. Hence, we put the linear sequence
of in the center of the diagram from left-to-right.
Adding Additional Perspectives. Covering the prin-
cipal information regarding the interaction between
data and the (business) process and, thus, aiming at
the heart of the information gap, we enrich the Princi-
pal View by different additional, stakeholder-driven
perspectives. Thus, we provide access to the sys-
tem parts mentioned in Figure 1 through intermediary
views that refer to elements of both the Principal View
and the existing enterprise information system. For
simplicity, we rely on the (UML-inspired) diagrams
already established and applied in each stakeholder’s
domain as far as possible to assure readability and ac-
cessibility:
Data Architecture View. We provide an UML pack-
age diagram with additional meta-information to rep-
resent data context groups on an abstract level. The
groups can be UML-ish packages or class stereotypes
and are associated with a simple coloring scheme.
This view is presented to IT and relates the con-
text groups to their concrete location in the underly-
ing IT landscape, e.g. servers, information systems,
databases. The coloring scheme is used throughout
all views to re-identify the context groups.
Data Entity View. An UML class diagram is used
to detail the data context groups. The Data Entity
View provides the data analyst with a detailed view
on the processed data from a abstract conceptual per-
spective. See Figure 3 for an example.
Data Characteristics View. Additionally we pro-
vide the data analyst with data characteristics, de-
rived from the V’s” of Big Data (Gandomi and Haider,
2015; Sagiroglu and Sinanc, 2013), represented in an
appropriate formalism. The choice of this formalism
heavily depends on the analysis framework to be ap-
plied later on in the engineering process. In our case,
we applied a simple table assigning “V”-qualities to
types of data instances with the help of a table.
Process View. The Process View provides a busi-
ness process language representation of the underly-
ing process. However, in our context, the representa-
tion by the chain of already included in the Prin-
cipal View was sufficient to represent the perspective
from process management.
Business View. The Business View embeds the in-
formation contained in all other perspectives, and es-
pecially from both the Process View and the Data
Architecture View, into high level business perspec-
tive in form of an UML Use Case diagram. This
permitted us to embed the process and data/architec-
ture perspective into the organizations management
context and to highlight the participating stakeholders
and their connection in the business case underlying
the production process; thus, providing a general and
very abstract anchor point for all gathered informa-
tion. The Business View also embeds the whole en-
deavor in the underlying information system develop-
ment’s requirement analysis model and provides ref-
erence points for traceability.
Additionally, we harmonized the different per-
spectives by making the connection of elements be-
tween them visually explicit, e.g. by using the same
color representation for instances and the correspond-
ing class. This allowed us to provide a straightforward
traceability of concepts between the different abstrac-
tion layers. For example, one could easily match
a data instance :QualityControl in the Principal View
with its class’s data context group in the Data Entity
View and thus the corresponding IT system where this
instance is maintained/stored in the Data Architecture
View by tracing the instance’s color.
Thus, the diagrammatic modelling language
DAAD is the spearhead of our approach that targets
the data awareness challenge via its embedding in an
iterative, incremental knowledge elicitation method.
4 CONCLUSION
Posing data awareness as central concern of knowl-
edge management proves to be a challenge to
both existing formalisms and techniques. Taking a
socio-technological perspective and a bottom-up self-
adapting approach supplies sufficient tools to tackle
this challenge in concrete practical situations. Here,
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
296
we provided a proof of concept regarding a newly de-
vised modelling language in an industry 4.0 domain
that embraces data awareness as central concern.
Beyond the presentation here, we supplied the
modelling language with a proper formal founda-
tion and were able to show, that it shares seman-
tic similarities with UML but gains better accessi-
bility in general. A formalization of updating and
harmonizing multi-perspective models in DAAD and
tool support is planned as future work. Further,
we are still augmenting the language to cover prac-
tical demands in data-analytical business processes,
e.g. including context information (as crucial for sus-
tainable data-analyses) and classical organizational
knowledge models in addition to data and process
models by additionally embracing knowledge maps
(Eppler, 2001) as additional perspective. Seeing the
success of the bottom-up derivation of a self-adapting
knowledge representation formalism, we want to in-
vestigate further the direction of modelling frame-
works that embrace at their core a notion of on-the-fly
self-adaption to concrete stakeholder demands.
Future work will also include the transfer of
DAAD to other domains and apply the three-step
approach to tackle the awareness challenge in other
practical knowledge management application situa-
tions. This will serve the long term sustainability and
development of DAAD.
ACKNOWLEDGEMENTS
The project underlying this
research (EFFPRO 4.0 In-
tegration and Analysis of De-
sign and Production Data for
a more efficient Development
Process Chain) has received
funding from the German
Federal Ministry for Economic Affairs and Energy
under grant agreement no. 20Y1509E.
REFERENCES
APA (2019) Awareness. In Online Dict. of the Am. Psych.
Assoc., online: https://dictionary.apa.org/awareness.
Aalst, W. V. D., Zhao, J. L., and Wang, H. J. (2015). Busi-
ness process intelligence: Connecting data and pro-
cesses. ACM TMIS, 5(4):18e.
Bhattacharya, K., Gerede, C., Hull, R., Liu, R., and Su,
J. (2007). Towards formal analysis of artifact-centric
business process models. In Int. Conf. on BPM, pages
288–304. Springer.
Bhattacharya, K., Hull, R., and Su, J. (2009). A data-
centric design methodology for business processes. In
Handbook of Research on Business Process Modeling,
pages 503–531. IGI Global.
Bruce, T. A. (1992). Designing quality databases with
IDEF1X information models. Dorset House.
Cicchetti, A., Ciccozzi, F. and Pierantonio, A. (2019).
Multi-view approaches for software and system mod-
elling: a systematic literature review. Software & Sys-
tems Modeling, pages 1–27. Springer.
Cohn, D. and Hull, R. (2009). Business artifacts: A data-
centric approach to modeling business operations and
processes. IEEE Data Eng. Bull., 32(3):3–9.
Combi, C., Oliboni, B., Weske, M., and Zerbato, F. (2018a).
Conceptual modeling of inter-dependencies between
processes and data. In Proc. of ACM Symposium on
Applied Computing, pages 110–119. ACM.
Combi, C., Oliboni, B., Weske, M., and Zerbato, F. (2018b).
Conceptual modeling of processes and data: Connect-
ing different perspectives. In Int. Conf. on Conceptual
Modeling, pages 236–250. Springer.
Curtis, B., Kellner, M. I., and Over, J. (1992). Process mod-
eling. Communications of the ACM, 35(9):75–90.
De Giacomo, G., Oriol, X., Estanol, M. and Teniente, E.
(2017). Linking data and BPMN processes to achieve
executable models. In Int. Conf. on Advanced Infor-
mation Systems Engineering. Springer.
Deutsch, A., Hull, R., Patrizi, F., and Vianu, V. (2009).
Automatic verification of data-centric business pro-
cesses. In Proc. of ICDT 2009, pages 252–267. ACM.
Eppler, M. J. (2001). Making knowledge visible through
intranet knowledge maps: Concepts, elements, cases.
In Proc. of HICSS-34. IEEE Computer Society.
Gandomi, A. and Haider, M. (2015). Beyond the hype: Big
data concepts, methods, and analytics. Int. J. of Infor-
mation Management, 35(2):137–144.
Jablonski, S. (2009). Process modeling for holistic process
management. In Handbook of Research on Business
Process Modeling, pages 49–68. IGI Global.
Kruchten, P. B. (1995). The 4+ 1 view model of architec-
ture. IEEE software, 12(6):42–50.
Kumaran, S., Liu, R., and Wu, F. Y. (2008). On the duality
of information-centric and activity-centric models of
business processes. In Int. Conf. on Adv. Information
Systems Engineering, pages 32–47. Springer.
K
¨
unzle, V. and Reichert, M. (2011). Striving for object-
aware process support: How existing approaches fit
together. In Int. Symp. on Data-Driven Process Dis-
covery and Analysis, pages 169–188. Springer.
Lankhorst, M. et al. (2009). Enterprise architecture at work,
volume 352. Springer.
Moody, D. (2009). The “physics” of notations: toward a sci-
entific basis for constructing visual notations in soft-
ware engineering. IEEE Trans. on Software Engineer-
ing, 35(6):756–779.
Moody, D. and van Hillegersberg, J. (2008). Evaluating
the visual syntax of uml: An analysis of the cognitive
effectiveness of the uml family of diagrams. In Int.
Conf. on Software Language Engineering, pages 16–
34. Springer.
Towards Data Awareness by Socio-technological Knowledge Management
297
Nigam, A. and Caswell, N. S. (2003). Business artifacts: An
approach to operational specification. IBM Systems
Journal, 42(3):428–445.
North, K. and Maier, R. (2019). Wissensmanagement f
¨
ur
industrie 4.0. herausforderungen und l
¨
osungsans
¨
atze.
Industrie 4.0 Management, pages 7–12.
North, K., Maier, R., and Haas, O., editors (2018). Knowl-
edge Management in Digital Change. Springer.
Object Management Group (2013). Business Process
Model and Notation (BPML). https://www.omg.org/
spec/BPMN/2.0.2/.
Object Management Group (2017). Unified Modeling
Language (OMG UML). https://www.omg.org/spec/
UML/2.5.1/.
Peinl, R. (2017). Knowledge management 4.0 - lessons
learned from IT trends. In Sure-Vetter, Y., Zander,
S., and Harth, A., editors, Proc. of Prof. Knowledge
Management 2017, pages 112–117. CEUR-WS.org.
Reichert, M. and Weber, B. (2012). Enabling flexibil-
ity in process-aware information systems: challenges,
methods, technologies. Springer.
Reijers, H. A. and Mendling, J. (2011). A study into the
factors that influence the understandability of busi-
ness process models. IEEE Trans. on Sys., Man, and
Cybernetics-Part A, 41(3):449–462.
Sagiroglu, S. and Sinanc, D. (2013). Big data: A review. In
Proc. of CTS 2013, pages 42–47. IEEE.
Stohr, E. A. and Zhao, J. L. (2001). Workflow automation:
Overview and research issues. Information Systems
Frontiers, 3(3):281–296.
St
¨
orrle, H. and Fish, A. (2013). Towards an operationaliza-
tion of the “physics of notations” for the analysis of vi-
sual languages. In Proc. of Int. Conf. on Model Driven
Engineering Languages and Systems, pages 104–120.
Springer.
Sun, S. X., Zhao, J. L., Nunamaker, J. F., and Sheng, O.
R. L. (2006). Formulating the data-flow perspective
for business process management. Information Sys-
tems Research, 17(4):374–391.
Wang, J., Wang, H., Ding, J., Furuta, K., Kanno, T., Ip,
W., and Zhang, W. (2016). On domain modelling of
the service system with its application to enterprise
information systems. Enterpr. Inf. Sys., 10(1):1–16.
Wood-Harper, A. T., Antill, L., and Avison, D. E. (1985).
Information systems definition: the multiview ap-
proach.
Zachman, J. A. (1987). A framework for information sys-
tems architecture. IBM sys. journ., 26(3):276–292.
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
298