2011 15th IEEE International Enterprise Distributed Object Computing Conference Workshops

Metadata Categories for Supporting Concurrent

Engineering
Juliane Blechinger, Frank Lauterwald, Richard Lenz
Chair for Computer Science 6 (Data Management)
University of Erlangen and Nuremberg
Erlangen, Germany
{juliane.blechinger, frank.lauterwald, richard.lenz}@informatik.uni-erlangen.de
have the necessary knowledge to solve their particular problems. Thus, the built information infrastructure for supporting
concurrent engineering has to be highly usable according to
the principles of interaction design: The way an interface
is designed can greatly affect how well people can perceive,
attend, learn, and remember how to carry out their tasks. [1,
p.104]. Ignoring those principles will lead to bad interfaces
which the engineers tend to refuse. Of course, if the engineers
do not use an information system, the supporting effect of the
system cannot be achieved.
One of our main goals is generalizability. Thus, our solution is
not tied to certain existing information management systems
(IMSs), which usually differ greatly between projects and
enterprises. In addition, our metadata categories are general
enough to be easily adoptable to various projects in concurrent
engineering domains. The contribution of this article is the
detailed description of these metadata categories that provide
both engineers and managers with the information they need to
effectively and efciently do their task at hand. Furthermore,
we provide implementation issues to offer a concrete solution
that can easily be adopted or at least tested by enterprises.
The contribution of this article builds on our work in [2]
where we have already provided a comprehensive problem
classication. We summarize the main points of this problem
classication in this article and present the metadata categories
and implementation issues we have derived from it, recently.
The remainder of this article is organized as follows: Section
2 summarizes the related work. It rst provides the scientic
denition and special challenges of concurrent engineering.
Second, it summarizes the existing management approaches
and meta models related to data quality issues. Section 3
presents our application domain, plant engineering, and summarizes the main points of our problem classication that we
have already presented in [2]. Finally, the general requirements
for an approach aiming at supporting concurrent engineering environments are deduced. In section 4, we describe
the necessary metadata categories for supporting concurrent
engineering. The necessity of the selected metadata categories
is based on our problem classication and the ndings of
our comprehensive analyzing activities regarding the current
process, the IMS landscape, and the real data in the enterprise
of our project partner. Of course, during the implementation
process, the selection and realization of the categories was

AbstractConcurrent engineering is a keyword in todays

enterprises. Almost every enterprise parallelizes its engineering
processes to reach a higher efciency in designing their products.
Unfortunately, the time- and cost-saving potential of concurrent
engineering cannot be used to its full capacity. In fact, design
problems arise and lead to a lot of rework. As we have recognized,
design problems always affect the underlying data. Thus, wrong
data is an indication of such problems. As a consequence,
the improvement of the data quality should reduce the design
problems. Although the data quality-related research community
has proposed various management approaches, these approaches
are too generic and thus give little guidance about what to do in
a given situation. The goal of our project, DQ-Step, is to develop
a solution that is both general enough to cover an entire domain,
namely concurrent engineering, while remaining concrete enough
to give usable guidelines to enterprises to support their engineers
and nally speed up their design. In our previous work, we have
already identied the major problems in concurrent engineering.
In this paper, we discuss the metadata categories required to help
overcome these problems.
Index Termsconcurrent engineering; metadata; meta model;
data quality; adaptability; concrete approach for enterprises

I. I NTRODUCTION
In the last decade, many enterprises switched from the common sequential engineering of their products to the concurrent
way of engineering. They parallelized their design steps with
the intention to speed up the whole engineering process.
However, they forgot to build up an appropriate information
infrastructure that is necessary to realize the intended timeand cost-savings. Without this information, the parallelized,
decomposed, and iterating nature of concurrent engineering
leads to design problems and inconsistencies that are detected
very lately and thus lead to huge rework cycles.
To deal with these inconsistencies and other data quality
problems, management approaches and meta models have
been proposed in the data quality-related scientic literature.
However, these approaches and models are very abstract and
can not serve as specic solutions in real projects. In our
project, we strive for a solution that is as general as possible,
while remaining able to give concrete advice to enterprises that
practice concurrent engineering. We propose a metadata-based
approach that enables domain experts to easily establish the
information infrastructure that the engineers need to monitor
and support their concurrent engineering processes. It is very
important to keep in mind that only engineers themselves
978-0-7695-4426-7/11 $26.00 2011 IEEE
DOI 10.1109/EDOCW.2011.10

26

reviewed several times with engineers and managers. After

a discussion of our approach in section 5, we conclude and
present some future work in section 6.

very theoretical and offer no direct practical implementation

instructions. Many researchers in the data quality domain focus
on the denition and classication of data quality dimensions [6], [7]. These articles are the basis for management
approaches like TDQM (Total Data Quality Management) [8],
TIQM (Total Information Quality Management) [9], AIMQ
(AIM Quality) [10] or the modeling approach IP-MAP (Information Product MAP) [11]. Due to the fact that data quality
is multidimensional and thus, all arising problems are very
application-specic, these management approaches are too
abstract for concrete application scenarios. Enterprises need
advice with practical implementation instructions that they can
easily apply to their domain.

II. R ELATED W ORK

To place our approach into a proper context, this section
contains related work. To the best of our knowledge, there
is no directly comparable approach in the scientic literature.
Thus, we looked into the topics that our approach includes:
First, we present the basic concepts of concurrent engineering.
Second, well-known management approaches for data quality
are shortly summarized. The section ends with existing meta
models for data quality in the scientic literature.
A. Concurrent Engineering

C. Meta Models

In todays enterprises, the sequential way of designing

products is no longer state-of-the-art. A close-meshed, interleaved engineering concept is implemented instead in order to
achieve cost and time savings. In the mid 90s, this observation
caught researchers attention and concurrent engineering was
comprehensively dened. One denition is given by [3] and
[4]: Concurrent engineering implies that there are several
process steps that can proceed in parallel. However, many of
them are interdependent, requiring designers to proceed with
partial information, with incomplete knowledge, and subjective
interpolations. To make parallel design of interdependent
process steps possible, early preliminary upstream information
has to be shared with downstream design stages. Each iteration
in the design results in changes that must propagate through
all dependent design stages. Consequently, (iterating) rework,
upstream and downstream, can be needed to reach a consistent
design [5].
Consequently, concurrent engineering has to deal with four
basic aspects: parallelism, decomposition, iteration, and stability. I.e., the whole design task is decomposed into several
design steps (or stages). These design steps are executed
in parallel. The sharing of preliminary information leads to
iterations when something is changed. To reach convergence,
the iteration has to be stable. This means that the number of
newly arising design problems has to be less than the number
of the solved ones.
We have experienced that, although concurrent engineering
is common in todays enterprises, the engineers are mostly
not supported well enough regarding the four basic aspects
mentioned above. This leads not only to data quality problems but also reduces the potential of concurrent engineering
regarding time and cost savings substantially. Additionally, to
the best of our knowledge, only few of the existing approaches
in the scientic literature focused on or considered concurrent
engineering as root cause for many engineering problems on
the surface. This motivated us to ll this gap and particularly
focus on concurrent engineering in the remainder of this paper.

Finally, we summarize existing meta models that are at least

somehow related to data quality issues. Due to the fact that
most of the meta models mentioned in this subsection have a
completely different focus than our approach, it is obvious
that these models do not consider concurrent engineering
scenarios. Thus, the following statements are in line with our
requirements, but do not necessarily fault those meta models.
Metadata-based data quality solutions are presented in [12]
and [13]. The approach in [12] is very conceptual and does
not offer concrete metadata classes or rule types. It also
does not concentrate on concrete metrics to measure data
quality problems which is a main topic in [13], instead. The
meta model in [13] focuses on SQL-based rules and offers
a concrete metadata schema. However, both models disregard
the process and engineering context.
Besides the data quality-specic meta models, there are also
meta models in the context of business processes. The business
process activity meta model in [14] classies business rules
into global, structural, and activity rules. The resulting meta
model is separated into entities related to the business process
and its behaviour and into entities that focus on necessary
characteristics for the IMS implementation. Another meta
model for business rules is presented in [15]. This meta model
consists of the following entity types: data model component,
business rule, process, origin, information system component,
actor, organizational unit, and software component. Consequently, this model is much more detailed and comprehensive
than the model in [14]. However, both models also disregard
the characteristics of concurrent engineering. Besides, the
process context is not adequately represented.
Finally, the enterprise architecture meta model in [16] aims at
offering a situation-based solution for IT/business alignment. It
consists of entities for business processes, organizational units,
and information systems. Regarding adaptability, information
system neutrality, and the goal of offering an applicable
solution, it is similar to our approach. However, in our point of
view, it is not detailed enough and has a different focus than
our meta model. So, it does not consider concurrent engineering scenarios and offers no rule component for monitoring
data quality.

B. Management Approaches for Data Quality

In the domain of data quality, many approaches for managing data quality were presented. However, these approaches are

27

KDVQH[W
SUHYLRXV

,QVWDQFH,'

5XOH&RQQHFWLRQ

KDV

QH[W

KDV

1
LVERXQGWR

$WRPLF5XOH

KDV

0DWFKLQJ5XOH

KDV

5XOH0HWDGDWD

EHORQJVWR

FRQVLVWVRI


UHIHUHQFHV

SUHYLRXV
KDVQH[W

)RUPXOD

KDV

QH[W

UHTXHVW DQVZHU

3RVVLEOH0LVWDNH


1

'HVLJQ6WHS

LVILOOHGLQ

2EMHFW7\SH
$WWULEXWH

1QH[W
0SUHYLRXV


,QWHUDFWLRQ
0HVVDJH

KDV

KDV

KDV

2EOLJDWLRQ5XOH

FRQFHUQV

KDVQH[W

KDV

5HVSRQVLEOH5ROH

VHQGV

KDV

3HUVRQ

EHORQJVWR

EHORQJVWR

UHFHLYHV

KDV
1

5HSRUW

EHORQJVWR


SUHYLRXV

KDV

KDVQH[W

2EOLJDWLRQ7\SH
QH[W

Fig. 1.

3HUVRQ,QVWDQFH
&RQQHFWLRQ

KDV

Entity-relationship diagram of the implemented metadata categories (attributes omitted)

engineering or the design and construction of any kind of

industrial factories, e.g. for the chemical industry.
Projects in plant engineering are huge and last several years.
This makes it impossible to change the underlying IMS
landscape during a running project, if problems regarding data
quality, delays in time, or complaints from the engineers arise.
Besides, even in engineering projects with shorter durations,
the replacement of IMSs is often not up for discussion. This
has two reasons: First, every major enterprise has an IMS
landscape consisting of many interdependent subsystems with
various interfaces. This makes it hard to change the whole
landscape. Changing only one subsystem would not solve the
problems mentioned above, because data quality problems,
user dissatisfaction as well as time delays result from the
whole landscape and not from only one subsystem. Second,
changing the IMS landscape is a management decision and
can hardly be inuenced by the engineering department.
These considerations lead to the fact that an approach for
supporting concurrent engineering has to be IMS-neutral and
thus, needs to be placed on top of the IMS landscape. This
makes it easy for various enterprises to adapt, or at least test,
the approach at low costs.

III. P ROBLEM D EFINITION

In this section, we rst characterize our application domain,
namely plant engineering, that represents the real environment
for our implementations. All of the ndings we present in this
article were gained via comprehensive analyzing activities and
interviews in the enterprise of our plant engineering-specic
project partner. The second subsection summarizes the problem classication we have already presented comprehensively
in [2]. The deduced general requirements for an approach
aiming at supporting concurrent engineering environments are
nally presented in the last subsection.
A. Application Domain
The application domain of our project partner that serves
as the real environment for user interviews, data and process
analysis, and the implementation of our approach is plant engineering. Plant engineering can be attributed to the engineering
of huge physical objects that are only built on explicit order
and consist of many composite objects (or items). According
to their functionality and construction, these objects can be
classied into object types. Other domains with the same
characteristics are for example ship building, astronautical

28

B. Problem Classication

ways. For example, they can have the wrong format or be

wrong regarding the allowed range or list of values. Of
course, one can say that these problems can be avoided
with constraints, but in most application domains every
rule has exceptions. That is why rigid constraints are
hardly implemented in IMSs. Thus, the engineers need
a possibility to dene rules to be able to nd possible
mistakes. If these possible mistakes are really erroneous
and need to be corrected, or if they are just exceptions,
can only be judged by the responsible engineer. Besides,
there are also types of incorrectness that can only be
found via manual inspection or by means of validated
reference data.
Inconsistency: In concurrent engineering environments,
many types of inconsistencies can arise. Examples are:
Different attribute values of replicated objects in different
IMSs, inconsistencies between adjacent objects, inconsistencies between objects and predened catalogues, and
inconsistencies between attribute values of one object
with conditional functional dependencies [20].
3) Information Decits for Managers: This problem class
contains information about the overall project status. This information is primarily needed by managers to estimate design
durations and reassign resources according to newly incurred
bottlenecks. Thus, the managers need aggregated information
about the number of completed and uncompleted objects per
design step and object type with the name and contact details
of responsible persons.

To base our approach on a comprehensive problem

classication, we have applied various analysis techniques
to our application domain. First, we conducted interviews
with representatives of different user groups. Engineers,
administrators, and managers were involved. Second, we
made an electronic assessment survey to get a wide-spread
view. Third, we analyzed the current process, the IMS
landscape, and the real data in the enterprise of our project
partner. Based on the results, we summarized the three
following basic problem classes: necessary information
unavailable to the engineers, problems of wrong data values,
and necessary management information. In the following,
we shortly summarize these problem classes which are
comprehensively described and exemplied in [2].
1) Information Decits for Engineers: This problem class
contains information that is not at all - or only with a
lot of effort regarding searching and comparing activities available to the engineers. However, this information is very
important for supporting engineers in concurrent engineering
environments; for example, the availability of the following
information types would preserve the engineers from wrong
assumptions that lead to wrong data and nally to a lot of
rework:
Responsibility: The engineer receives attributes from previous design steps. If s/he has problems or questions
regarding these attributes, s/he needs to know the name
and contact details of the lling responsible persons to be
able to immediately contact them without loosing time.
Object Type Classication: If an engineer has to design
an instance of a special object type, s/he exactly needs
to know what attributes have to be lled when and by
which role. This information helps the engineer in being
aware of what s/he has to ll mandatorily.
Interaction Messages: The engineers need usable interaction possibilities between design steps and responsibilities. For example, they have to be notied if attributes
of objects, which they are involved with, change. Additionally, they need a mechanism to easily send change
requests to responsible persons, if attributes from previous design steps rise conicts with their design.
Obligation Levels: For the attributes the engineers receive, they need to know their obligation level. This
would preserve the engineers from building their design
on unreliable information.
2) Wrong Data Values: This problem class contains typical
data error types. Taxonomies of data error types are already
comprehensively provided in the scientic literature [17], [18].
Additionally, denitions regarding the underlying data quality
dimensions are given in [19]. Thus, only the most common
data error types are shortly summarized:
Incompleteness: Objects are specied insufciently, because mandatory attributes are not lled.
Incorrectness: Attribute values can be incorrect in various

C. Requirements
To sum up, we identied the following requirements for
supporting concurrent engineering:
The solution should be IMS-neutral and adaptable. This
is necessary, because almost every enterprise has an existing IMS landscape consisting of many interdependent
subsystems and the exchange of this IMS landscape is
often not up to discussion. Additionally, IMS changes in
the future can not be foreseen. Consequently, an IMSneutral and adaptable solution would make it easy for
various enterprises to adapt, or at least test, the solution
at low costs.
In engineering enterprises, not the technical administrators but the engineers have comprehensive knowledge
to adequately dene domain-specic data quality rules.
Additionally, only if the solution is intuitively usable,
understandable, and motivating, the engineers will use
it. Thus, important requirements from the domain of
interaction design arise.
The solution has to offer special information for engineers, aggregated information for managers, and a rule
denition possibility to nd wrong data values. The
information for the engineers consists of responsibility
information, an object type classication, interaction messages, and obligation levels. The information for the
managers shows the overall project status with contact
details of responsible persons. Finally, the engineers need

29

,VRODWLRQ
9DOYHV
*URXS

a possibility to easily dene data quality rules to nd

possible mistakes regarding incomplete, inconsistent, or
incorrect data values.
Before we present our metadata categories in the next section,
it has to be mentioned that state of the art tools in plant
engineering do not adequately address these mentioned requirements. Additionally, we analyzed both commercial and
research data quality tools in [2], but those tools concentrate
on cleaning and proling activities and not on concurrent
engineering. A comprehensive survey about data quality tools
can be found in [21].

6DIHW\
9DOYHV
*URXS

9DOYH

&RQWURO
9DOYHV
*URXS

*OREH
&RQWURO
9DOYHV

IV. M ETADATA C ATEGORIES

In this section, we present the necessary metadata categories
for supporting concurrent engineering. In fact, we identied
six main categories. Every subsection describes one of these
six categories. Due to the fact that practical implementation instructions are mandatory for todays enterprises, we
show exemplarily how we have implemented the mentioned
metadata categories in our real project. The overall entityrelationship diagram of the metadata categories implemented
in our prototype is presented in Figure 1. For lack of space,
attributes are omitted in Figure 1, but - if important - are
mentioned in the following subsection. Besides, the entity
types that we used to implement every category in our real
project are also shortly addressed.
Additionally, metadata categories can be separated into
project-specic and user-specic categories. Project-specic
metadata has to be dened by the administrators once at the
beginning of the project and stays static afterwards. However,
user-specic metadata is dened by the engineers themselves
and changes during the project arbitrarily.

3OXJ
&RQWURO
9DOYHV

%XWWHUIO\
&RQWURO
9DOYHV

ZD\3OXJ
&RQWURO
9DOYHV

&RQWUROYDOYH
SOXJ(065

Fig. 2.
Part of the Object Type Model for valves in plant engineering
(attributes omitted)

(see [22] for valve-specic explanations). Referring to Figure

1, Figure 2 is a zoom into the Object Type Attribute entity type
in Figure 1 in our concrete implementation; it demonstrates
how we implemented the object type model as a tree structure
(more details on this tree structure can also be found in [2]).
We stored this tree structure of object types in the entity type
Object Type Attribute. In detail, we rst built generalizations
of object types as exemplied in Figure 2. Then, the attribute
names of the object types were reassigned to the adequate
superclasses in the tree. Finally, the entity type Object Type
Attribute has to map this tree by means of at least the attributes
attribute name, type (as assigned superclass), source as IMS
where the attribute value is saved, and a Boolean mandatory?.
This entity type is the central point of all other metadata
categories and thus has to be lled carefully. It belongs to the
category of project-specic metadata and has to be dened
once at the beginning of the project.

A. Object Type Model

The nal product in engineering consists of many composite
objects. For example in plant engineering, an object is a pipe,
a valve, or a pump. To design an object, many different engineering departments have to calculate and nally ll attributes
of this object according to their role. Which attributes have to
be lled for an object is dened by its type, the object type.
Object types can be classied by their functionality and their
construction. In fact, commonly many object types exist that
differ only in few constructional issues. So, it is reasonable
to classify the object types hierarchically according to a tree
structure. That way, the redundancy of describing many similar
object types is reduced signicantly. New object types can
easily be added to the tree structure. Additionally, the engineer
can derive a special object type via its superclasses in the tree
structure what makes it easy to understand the functionality
and construction issues behind the object type name.
As an example, a small part of our concrete object type
model for valves in plant engineering is given in Figure 2
where the classication path to the existing object type ControlValvePlugEMSR is depicted. Via this classication path, the
engineer gets the information that objects of this type have the
control function, two separate inputs and a plug moving device

B. Design Step Model and Responsibility

The attributes of an object are lled in several interdependent design steps and by various engineering roles.
Consequently, if an already released attribute is changed in
a previous design step, it has to be claried which of the
subsequent design steps are affected. In order to provide this
information to the engineers, a design step model has to be
built that consists of the denition of the design steps and their
order. Additionally, the design step model extends the object
type model with information on the attributes regarding when
they have to be lled and by which role. Every attribute has
an engineering role that has the responsibility to ll it (llresponsible role). All other roles have just the permission to

30

redundant, implication should also be implemented as connection operator because of its frequent use. This combination
of rule-parts can be arbitrarily continued. The nal result is
represented by the root of the tree.
Additionally, we have to differentiate between intra-item and
inter-item rules. The former denes attribute checks only for
one object type, the latter for various object types whereas
matching partners have to identied via a matching rule. An
example from the context of plant engineering is a rule for a
valve in conjunction with its host pipe: First, associated valve
and pipe instances have to be found, before a rule regarding
the compatibility of the maximum allowable working pressure
of both instances can be checked.
When executing the rule, instances that violate the rule are
reported back to the engineer. In order to identify huge
deviations quickly and thus mark possibly urgent problems, we
have implemented interval-scaled correctness values according
to the recommendations in [23]. That way, normalized, easily
interpretable [0,1]-scaled correctness values help the engineers
in ranking their tasks.
Furthermore, we have detected that it is very important to
allow for the linking of atomic rules to design steps. In our
application domain, many engineers asked for this possibility
in order to test rules only on instances that are in a specic
design step. This refers to the fact that many rules are less
restrictive in former than in later design steps.
Referring to Figure 1, we implemented the rule model by
means of ve entity types. The checks on the leaf-level are
stored in the entity type Atomic Rule. If the check states
a dependency between several attributes, i.e. more than one
attribute is involved, the arbitrarily long dependency is stored
in the entity type Formula and then referenced by Atomic
Rule. The combination of several atomic rules by means
of connection operators is stored in the entity type Rule
Connection. The entity type Rule Metadata nally provides
the metadata, i.e. the name and the owning person, to every
rule connection and references a Matching Rule in case of
inter-item rules. Storing the rules by means of these ve entity
types has several advantages: The atomic rules are stored
without any redundancy and can be referenced in various rule
connections. Additionally, conict tests can be executed on
atomic rules. Separating the rule metadata makes it possible
to copy already stored rule connections to other persons or test
them for different matching rules. In our application domain,
by means of this modeling concept, all necessary rules can
be expressed. Of course, in other application domains other
modeling concepts are possibly necessary.
All entity types of the rule model belong to the category of
user-specic metadata, are dened by the engineers themselves
and can change during the project.

read the concerned attribute.

To provide the responsibility information regarding the name
and contact details of responsible persons to the engineers, also
metadata about the engineers themselves have to be stored.
Consequently, every person has an engineering role. Based
on that, every person can mark him/herself in his/her role
as the ll-responsible person or just as interested person for
specic objects. Of course, only one person per role can be
the ll-responsible person of a specic object, whereas any
number of persons can be just interested in the changes of
an specic object. The personal adoption of roles for specic
objects is necessary for notication purposes. This way it can
be easily determined, which persons have to be informed, if
an object in a previous design step has changed. Additionally,
if an engineer in a subsequent design step conducts problems
with an received attribute from a previous design step, the llresponsible person can be easily identied. This speeds up the
communication and feedback loops.
Referring to Figure 1, we implemented the design step model
with the entity type Design Step and an n:m-relationship type
has next regarding the order. It is important to notice that
every design step in the design step model has to have at
least either a previous or a next design step. So, it can be
guaranteed that no design step is isolated. The responsibility
issues are implemented with the entity types Responsible Role,
Person, and Person Instance Connection. The latter stores
via the attributes instance id, person id, and a Boolean llresponsible? the personal adoption of roles for specic objects
(or instances).
The entity types Design Step, Responsible Role and the n:mrelationship type has next belong to the category of projectspecic metadata and have to be dened once at the beginning
of the project. However, the entity types Person and Person
Instance Connection belong to the category of user-specic
metadata, are dened by the engineers themselves and can
change during the project.
C. Rule Model
In order to check if the lled attribute values are possibly
wrong - i.e. incorrect, incomplete, or inconsistent - the engineers need a possibility to dene rules. These rules shall
express the engineers expectations and experience regarding
the characteristics of attribute values of specic object types.
The rules are considered as tree structures whereas the leaves
consist of checks on attributes. These checks can be either
simple comparisons of attributes with values or more complex
dependencies between several attributes. To give an example,
a simple comparison of an attribute with a value is the
expression that the maximum allowable working temperature
of a valve has to be less than 200 degree. A similar example
of a dependency between several attributes is the expression
that the maximum allowable working temperature has to be
less than twice the minimum allowable working temperature.
The checks on the leaf-level are then combined by connection
operators represented as internal nodes. Connection operators
are conjunction, disjunction, and negation. Although it is

D. Obligation Rules
For concurrent engineering, it is essential that subsequent
design steps are supplied with preliminary and partial information from previous design steps. In real engineering
environments, this means that newly lled attribute values

31

become visible for engineers in different design steps at the

same point in time. However, the obligation of the visible
attribute values varies according to the role of the viewing
person and the current design step and object type of the
corresponding object (or instance). Because of that, obligation
rules have to be stated that assign the adequate obligation
type to attributes according to the mentioned parameters. This
makes it possible to show the obligation level of received
attribute values to every engineer and thus preserving the
engineer from basing his/her design on unreliable attribute
values.
In our application domain, a differentiation between three obligation types fullled the engineers requirements. Thus, we
differentiate between reliable attribute values (i.e. the attribute
values will not change again), slightly unreliable attribute
values (i.e. the attribute values will possibly change again)
and highly unreliable attribute values (i.e. the attribute values
will most likely change again, for example due to estimation
issues). Of course, one can choose more ne-grained types if
necessary. Based on these types, every obligation rule consists
of the following ve parameters: If an object of type t is in
design step x, role y has obligation z for attribute v. Obligation
rules can either be stated on attribute level or on whole
attribute groups.
Referring to Figure 1, we implemented the obligation rules
with the entity types Obligation Rule and Obligation Type.
Both entity types belong to the category of project-specic
metadata and have to be dened once at the beginning of the
project.

message sequences are already predened. For example, if

engineer A conducts a problem with a received attribute value
from engineer B, A sends to B a forced-read message stating
the problem and asking B to check this attribute value again.
B can then accept or reject the request, and a message of
type inform-about-change, or inform-about-reject respectively,
is sent back to A. In case of accepting the change, the informabout-change message is also sent to all affected engineers.
Now, if any of the affected engineers rejects, the message
sequence ends with an ofine-coordination-message to all
participants. It is obvious that the entity type Interaction
Message belongs to the category of user-specic metadata.
F. Traceability of Rule Execution
Whenever an engineer executes a rule, the results of the rule
execution, the name of the executing engineer, and the date of
execution is documented. This is necessary to trace the rule
execution process. By aggregating these data, questions about
the project status can be answered. Examples are How many
possible mistakes per object type are still open? or Which
mistakes are corrected tardily after their detection?. So, time
scheduling and the prioritization of tasks can be improved, e.g.
by rearranging the allocation of resources.
Referring to Figure 1, we implemented the documentation
of the rule execution with the entity types Report, Possible
Mistake, and Instance ID. The entity type Report contains the
name of the executing engineer, the date of execution, and the
text and reference of the executed rule. All possible mistakes
found by the executed rule are stored in Possible Mistake,
which is referenced by Report. Due to the fact that in case of
inter-item rules more than one instance is related to a possible
mistake, the instance IDs with the name of their source IMS
are stored in a separated entity type, namely Instance ID. All
entity types are automatically lled, when an engineer executes
a rule.

E. Interaction Messages
The situation that persons have to be informed, if an object
in a previous design step has changed, was already explained
in the subsection of the Design Step Model and Responsibility. Who exactly has to be informed is determined via the
possibility to personally adopt roles - as a ll-responsible or
interested person - for specic objects. It was also already
mentioned above that an engineer in a subsequent design
step needs a possibility to easily and immediately contact
previous ll-responsible persons, if s/he perceives problems
with received attribute values. Without this possibility, the
engineer is tempted to change the attribute value illegally by
him/herself or work around the possible error which defers its
detection.
Consequently, an easily usable interaction messaging mechanism should be provided to the engineers to support and
speed up their communication. For traceability reasons, all
sent interaction messages should be stored append-only. So,
the interaction messages can be marked as done, but are never
deleted. In our implementation, this is done with the entity
type Interaction Message. It is important to notice that the
receiver(s) of every message are automatically detected via the
responsibility metadata mentioned above. Additionally, every
message has a certain type. In our application domain, we
need four types: forced-read, inform-about-change, informabout-reject, and ofine-coordination-necessary. The possible

V. D ISCUSSION
The contribution of this paper is the proposal of necessary
metadata categories to support concurrent engineering. Additionally, practical recommendations regarding the implementation of these categories are given. Regarding those practical
recommendations and the entity-relationship diagram in Figure
1, it is very important to notice that Figure 1 is just our
implementation of the presented metadata categories regarding
the concrete requirements in the enterprise of our project
partner. Figure 1 should serve as an example how the proposed
metadata categories can be implemented; however, in other
application scenarios this implementation probably has to be
adapted. For example, design steps can also have a hierarchical order and not the sequential one we have implemented.
Additionally, rules can be stored in various ways. These
issues have to be carefully discussed when implementing the
proposed metadata categories in other application domains.
But, the fact that the six presented metadata categories are
- regardless of their concrete implementation - necessary in
concurrent engineering environments is doubtless according

32

users. As a next step, we will extend the evaluation to a larger

number of users in order to to get more signicant results
about its function and usability. Next, we plan to implement
the metadata repository in a different application domain to
test its adaptability to various environments.

to the problem classication and analyzing activities in the

enterprise of our project partner.
To the enterprises, this paper raises their awareness of the
needs for successfully switching to concurrent engineering.
Unfortunately, according to our experience, many enterprises
switched from sequential to concurrent engineering without
building adequate support for the engineers. This leads to
the fact that the time- and cost-saving potential of concurrent
engineering can not be used to its full capacity. Frequently, late
feedback in form of late error detections lead to a huge rework
cycle and thus compensate previously achieved time-savings
of parallelized design steps. That is why it is very important
that enterprise become aware of the needs that concurrent
engineering requires.
To the data quality tool industry, this paper shows new
requirements that arise because of concurrent engineering. Due
to the fact that we have presented an IMS-neutral approach,
enterprises can easily test our approach, although the tool
industry has not discovered this problem domain, yet.
To the scientic community, our approach shows how to
generalize application-specic data quality problems and build
a practical method to support concurrent engineering. This
approach is far more detailed and usable than other data
quality management approaches from the scientic literature.
Hopefully, this approach motivates enterprises, researchers,
and the tool industry to further extend our approach and
especially improve the detection and prevention of data quality
problems originating from concurrent engineering.
It is important to notice that our approach is completely useless
if the engineers do not use it. Thus, the interaction design of
the user interface is very important and needs to be developed
closely with engineers. Additionally, it has to be mentioned
that in the long term the replacement of the existing IMS
landscape is still the best thing to do. The new IMS landscape
has to provide strong support for concurrent engineering, a
high usability, and needs to be evolutionary. The latter is
very important because IMSs are ever-changing. Thus, only an
highly adaptable and evolutionary IMS landscape can endure.

R EFERENCES
[1] J. Preece, Y. Rogers, and H. Sharp, Interaction Design: Beyond HumanComputer Interaction. John Wiley & Sons, Inc., 2002.
[2] J. Blechinger, F. Lauterwald, and R. Lenz, Supporting the production of
high-quality data in concurrent plant engineering using a metadatarepository, in 16th Americas Conference of Informtion Systems (AMCIS),
2010.
[3] B. Prasad, R. S. Morenc, and R. M. Rangan, Information management
for concurrent engineering: Research issues, Concurrent Engineering,
vol. 1, no. 1, pp. 320, 1993.
[4] B. Prasad, System integration techniques of sharing and collaboration
among work-groups, computers and processes, Journal of Systems
Integration, vol. 9, pp. 115139, 1999.
[5] A. Yassine and D. Braha, Complex concurrent engineering and the
design structure matrix method, Concurrent Engineering, vol. 11, no. 3,
pp. 165176, September 2003.
[6] B. K. Kahn, D. M. Strong, and R. Y. Wang, Information quality
benchmarks: Product and service performance, Communications of the
ACM, vol. 45, no. 4, pp. 184192, April 2002.
[7] Y. Wand and R. Y. Wang, Anchoring data quality dimensions in
ontological foundations, Communications of the ACM, vol. 39, no. 11,
pp. 8695, November 1996.
[8] R. Y. Wang, A product perspective on total data quality management,
Communications of the ACM, vol. 41, no. 2, pp. 5865, February 1998.
[9] L. English, Total information quality management: A complete methodology for iq management, DM Review, vol. 9, pp. 17, September 2003.
[10] Y. W. Lee, D. M. Strong, B. K. Kahn, and R. Y. Wang, Aimq:
a methodology for information quality assessment, Information &
Management, vol. 40, no. 2, pp. 133146, December 2002.
[11] G. Shankaranarayan and R. Y. Wang, Ip-map: Representing the manufacture of an information product, in Proceedings of the 5th International Conference on Information Quality (ICIQ00), 2000, pp. 116.
[12] M. Helfert and C. Herrmann, Proactive data quality management for
data warehouse systems - a metadata based data quality system, in Proceedings of the 4th International Workshop on Design and Management
of Data Warehouses (DMDW02), 2002, pp. 97106.
[13] D. Becker, W. McMullen, and K. Hetherington-Young, A exible and
generic data quality metamodel, in Proceedings of the 12th International Conference on Information Quality, November 2007, pp. 5064.
[14] A. Kovacic, Business renovation: business rules (still) the missing link,
Business Process Management Journal, vol. 10, no. 2, pp. 158170,
2004.
[15] H. Herbst, Business rules in systems analysis: a meta-model and
repository system, Information Systems, vol. 21, no. 2, pp. 147166,
1996.
[16] J. Saat, U. Franke, R. Lagerstrom, and M. Ekstedt, Enterprise architecture meta model for it/business alignment situations, in Proceedings of
the 14th IEEE International Enterprise Distributed Object Computing
Conference, 2010, pp. 1423.
[17] W. Kim, B.-J. Choi, E.-K. Hong, S.-K. Kim, and D. Lee, A taxonomy
of dirty data, Data Mining and Knowledge Discovery, vol. 7, no. 1, pp.
8199, 2003.
[18] P. Oliveira, F. Rodrigues, and P. Henriques, A formal denition of data
quality problems, in Proceedings of the 10th International Conference
on Information Quality (ICIQ05), 2005, pp. 1326.
[19] C. Batini and M. Scannapieco, Data Quality, Concepts, Methodologies
and Techniques. Springer, 2006.
[20] W. Fan, F. Geerts, and X. Jia, Conditional dependencies: A principled
approach to improving data quality, in British National Conference on
Databases (BNCOD09), 2009, pp. 820.
[21] J. Barateiro and H. Galhardas, A survey of data quality tools,
Datenbank-Spektrum, vol. 14, no. 5, pp. 1521, 2005.
[22] H. Dubbel, Taschenbuch fur den Maschinenbau. Springer, 2004.
[23] B. Heinrich, M. Klier, and M. Kaiser, A procedure to develop metrics
for currency and its application in crm, ACM Journal of Data and
Information Quality, vol. 1, no. 1, pp. 128, June 2009.

VI. C ONCLUSION
In this paper, we have presented metadata categories for
supporting concurrent engineering. We have discussed why
concurrent engineering poses unique challenges and how an
apt IT infrastructure can help overcome them. Based on this
discussion and on our general approach of building a metadata
repository that is independent of the existing IMS landscape,
we have detailed the main contribution of this paper: The
description of the metadata categories that are required to
overcome common problems in concurrent engineering. For
each category, we have explained which problems may be
solved with the help of the respective type of metadata and
for which group of users it provides benets. We have also
explained by whom each type of metadata has to be entered
and how general each type is (project- vs. user-specic).
The implementation of our metadata repository is completed
and has already been evaluated by a small number of end

33