systematic aggregation of dependency models

Proceedings of TMCE 2010 Symposium, April 12-16, 2010, Ancona, Italy, ed. by I. Horv´ath, F. Mandorli and Z. Rus´ak c Organizing Committee of TMCE 2010 Symposium, ISBN 978-90-5155-060-3

SYSTEMATIC AGGREGATION OF DEPENDENCY MODELS – PRINCIPLES AND FORMS OF AGGREGATING SEVERAL DOMAINS Matthias Kreimeyer Institute of Product Development ¨ Munchen Technische Universitat ¨ Germany [email protected]

Nikolas Bradford Stefan Langer Wieland Biedermann Udo Lindemann Institute of Product Development ¨ Munchen Technische Universitat ¨ Germany {nikolas.bradford, Stefan.langer, wieland.biedermann, udo.lindemann}@pe.mw.tum.de

ABSTRACT

1. INTRODUCTION

Engineered systems are often modeled as dependency models that are analyzed for their structure, i.e. the constellation of their entities and how these are related, to better plan, design, and improve the behavior of the system. Often, these dependency models consist of different coexisting classes of entities (domains) and relations (relationship types). As such models often are complex to use, it is at times necessary to generate more condensed models to see how different entities depend upon each other. Therefore, this paper discusses the principles of aggregating large network structures that consist of several domains into condensed, aggregate views. Three different strategies are proposed, based on existing work in various disciplines: Path searching, attribution, and superposition. Each aggregate view can be understood as a reduced, yet not simplified recombination of several domains and relationship types. For each of the three strategies, the resulting aggregate models are reviewed, and principles to working with the resulting aggregate relationship types are presented. An example analysis of a complex process model is shown to illustrate that aggregation enables the application of common analysis methodology and algorithms that exist for dependency models.

Managing the complexity of systems is an urgent issue in engineering nowadays. In fact, complexity occurs in all kinds of engineered systems, such as products and their architectures, processes and their structure, markets and the interdependencies among their stakeholders, and so on [23].

KEYWORDS Structural complexity, design structure matrix, multiple-domain matrix, domains, aggregation

To manage complex engineered systems, models must be able to represent all relevant facets of a complex system, in particular its entities, how they interact, and how they relate to the system’s behavior [12]. As almost always there are different classes of entities, relationships and behavior [16], the models become complex themselves [3, 12]. This research is thus aimed at creating viable aggregate views that do not reduce complexity. Rather, a reduced form of modeling is searched that does not oversimplify a complex system but that allows the purposeful recombination of different sets of entities and relations into more compact model with regard to a specific behavior of the system.

1.1. Systems and complexity A system is [7, 24, 36], in this context, understood as a set of entities of (possibly) different classes (called “domains”) that are related to each other via various kinds of relations (called “relationship types”). The system is delimited by a system border, across which inputs and outputs of the system are possible as an interaction with the environment. The system fulfills

1121

Task A

Task A

„task“ generates „business object“

This aggregate relation is computed only via one intermediate domain:

Business object 1

„business object“ starts „task“

„business objects“ Task B

Task B

This aggregate relation is computed via two intermediate domains:

XOR

Figure 1

Business object 2

Business object 3

Task C

Task D

„connectors“ and „business objects“

Task D

Example of an aggregate view across two other domains.

a purpose, which guides the meaningful arrangement of entities and relations (called “structure”). The behavior of the system is, in turn, due to the arrangement of the system’s elements. In turn, the complexity of such systems is characterized by a number of aspects. Above all, a complex system is potentially highly structured [14]. Complex systems have a large number of possible arrangements of their parts, i.e. their configuration is relevant to the system’s behavior [2, 18], as its different parts interact in many different ways [33]. This makes it, in part, impossible to infer the structure and behavior of the system from the structure and behavior of its parts, especially as the parts of the system can adjust in response to changes in adjacent parts [2, 18] and the overall purpose of the system is only generated by all parts cooperatively [7]. This results in complex systems being hard to understand, as they, by design or function or both, are difficult to understand and verify [37].

1.2. Creating aggregate system descriptions to manage complexity Figure 1 shows the example of a basic process, consisting of the domains tasks and business objects that interact to generate a meaningful overall system. Each time, a task generates at least one business object that, once available, starts one or more tasks. Of course, in some cases, several business objects might be necessary to start on or more tasks.

1122

Task C

To analyze a complex system such as the process in the example, it is often necessary to reduce the complete system model as e.g. the one in Figure 1 to a more compact model to better understand the involvement of individual entities in the overall system [24]. The reason for this is mostly that the models become large and difficult to handle [3, 12], or it is necessary to reduce the model to e.g. just one domain to be able to compare them to each other [23, 24]. The lower part of Figure 1 shows how e.g. the tasks in the example are related indirectly to each other via business objects they exchange. This fact can be used to turn the model in to an explicit, aggregate representation of the interaction of just one class of entities (instead of two or more). In the example, an aggregate view on tasks is generated. There any two tasks are directly related to each other if they exchange a business object. More generally spoken, most systems (and thus their models) will consist of two or more domains that are tightly coupled [16]. Yet, when analyzing the model and comparing the entities of these domains among each other, it is often necessary to compare only entities of one kind with each other to draw conclusions about how to improve the system [24]. To do so, it is necessary to incorporate indirect relationships among these entities, which only exist via a different intermediate domain. To this end, an aggregate view can be used that only contains entities

Matthias Kreimeyer, Nikolas Bradford, Stefan Langer, Wieland Biedermann, et. al.

of one domain and their (computed) relations among each other. This is especially necessary for analyzing structural characteristics [24] or structural metrics [25, 21]. The challenge is to generate consistent models that do not simplify the system but that correctly represent one class of entities and how they are integrated into the overall system via, possibly, several other classes. This paper therefore reviews possible strategies of aggregation and deduces common principles.

1.3. Research approach The work presented here is part of a greater research project that is tailored to create a viable methodology to manage the interdependencies an enterprise is commonly faced with. As such, the approach is therefore created in a generic manner, i.e. not regarding only product architectures or process structures. At the same time, it is based on different empirical objects. For the context of this paper, however, only process models are used to illustrate this research, as processes exhibit all kinds of aspects relevant to this research (direct / undirected, unipartite / npartite relationships, intra- and inter-domain networks) [4, 22]. In this paper, all models are based on an adapted Event-driven Process Chain (EPC) [34] that is also used for the industrial case study accompanying this paper. EPC was chosen as it represents a most complete set of modeling constructs [22] and because it is well accepted in industry, thus making this research directly relevant to many cases of application in an industrial context.

1.4. Structure of this paper Having explained the motivation, goal and relevance of this research, first, the terminology relevant to structural complexity is reviewed to then introduce existing approaches that are able to handle the entities and relationships in a complex system. Furthermore, existing strategies are regarded that allow compiling simple, aggregate models. From this body of knowledge, possible strategies of aggregation are deduced that, in a second step, are systematized and explained in detail to fill the existing gaps in managing complex systems, making use of the existing approaches and regrouping them accordingly. To illustrate the use, viability and validity of the approach developed, last, a case study from process management in automotive industry is used, before the paper is concluded.

2. RELATED STATE OF THE ART Different research disciplines have brought forward a number of approaches to manage the complexity of a system. In fact, the term complexity refers to various different phenomena. Computational complexity addresses the computability of an algorithm [32], information processing sees complexity as the total number of properties transmitted [27], and in physics it is the probability of reaching a certain state vector [17]. Complexity in engineering addresses the coupling of the entities of a technical system [24], and software science focuses on assessing program code for its internal dependencies and possible errors introduced thereby [38].

2.1. Managing structural complexity Opposed to complexity as a generic term, structural complexity addresses the coupling of entities (also called “elements”) in a system via relations (also called “dependencies” if directed) [23]. Thus, structural complexity management is interested in modeling, analyzing and synthesizing these entities and their relations with a view to establishing a certain behavior of a system [6]. Within such models, a class of entities is referred to as a “domain”, and a class of relations is called a “relationship type” [23]. If only one domain is regarded, typically, an intradomain network will occur that links the entities of this one domain among them via one relationship type. Tasks, for example, can be coupled via precedence relationships, i.e. one task will lead to the next over time [35]. If more than one domain is regarded, e.g. tasks and business objects as in the previous example, the coupling between two different domains will create an inter-domain network. Assembling the inter- and intra-domain networks will create a multiple-domain network that will represent a more complete picture of the real-world system. The relationship types in such a network model can be directed (called “digraph” in Graph Theory) or undirected (“simple graph”) [15]. Directed relationships can furthermore be decomposed into basic directed and bidirectional relationships. Often, they are also attributed with a weight so represent the strength of the coupling [15]. In practice, often, undirected relationships can be resolved as bidirectional ones, which simplifies the models importantly towards the number of necessary modeling constructs and relevant algorithms to work with these constructs. In this research, therefore,

SYSTEMATIC AGGREGATION OF DEPENDENCY MODELS

1123

only directed relationship types are regarded, as these have proven sufficient to work with all common cases in structural complexity management. Furthermore, undirected relationships can are mostly modeled as bidirectional relationships. Therefore, undirected relationships can be understood as a subset of directed relationships in this context. Often, network models are not unipartite but bipartite or even n-partite. The example in Figure 1 is bi-partite (i.e., 2-partite), as no domain is coupled in a reflexive manner, i.e. to itself. In fact, each entity in one domain is always connected to an entity in a different domain. In fact, most couplings in engineering are at least bi-partite, as [16] have found in their research, making it highly relevant to be able to handle such systems efficiently. Yet, many techniques for analysis, e.g. for Design Structure Matrices or System Dynamics, are only available within one single domain, or domains are not actually differentiated, thus requiring a unipartite network. Complex, multi-partite structures therefore need to be reduced to a single domain-view to allow for the application of such algorithms (for existing algorithms for structural complexity management, see [1, 8, 10, 21, 23, 24, 25]). Generally, dependency models can be represented in a number of different ways. In the following section, different models and their contributions towards aggregation are reviewed. At each time, a model can represent a native dataset, i.e. relationships that were explicitly modeled, or an aggregate dataset, i.e. one that is computed out of a native one.

2.2. Matrix-based approaches The Design Structure Matrix (DSM) [10] and the Domain Mapping Matrix (DMM) [11] are well established methods for dealing with complex dependencies of a system [8]. DSMs represent intra-domain networks, while DMMs are able to model interdomain networks. Especially DSM offers a number of analysis methods, e.g. sequencing, banding, or clustering (see Figure 2) [10]. Sequencing

Banding

Clustering

Independent tasks

Cluster Ideal sequence

Figure 2

1124

Different analysis methods for DSM.

Task A

e.g. DMM 1 relates tasks to business objects

DMM 1 Business object 1

DMM 2 Task B

DMM 3 XOR

DMM 4 Business object 2

Business object 3

DMM 2 Task C

Figure 3

Task D

Example of a Multiple-Domain Matrix.

However, both kinds of matrices only allow for a limited view on a certain problem. To manage a complete system consisting of several coexisting views, the Multiple-Domain Matrix (MDM) was developed [24]. It combines DSM and DMM in an overall framework to represent the structure of a system, i.e. the way that different entities are related in a goaloriented way. Figure 3 shows how an MDM can be set up for the process example in Figure 1. The domains tasks and business objects (BO) are used for the respective entities. Furthermore, the XOR-connector (neither being a task nor a business object) forms a domain of its own (for details, see [20]). Each pair of domains that is coupled (only inter-domain networks exist in this example) is represented by a Domain Mapping Matrix (DMM), e.g. DMM 1 that shows how tasks generate business objects (boxed matrix). In turn, the matrix is read “row leads to column”. Similarly, e.g. DMM 2 is used several times, as there are three individual relationships from each time a business object to a task. The MDM logic can be used to compute aggregate views using matrix multiplication. This way, different native datasets (e.g. a DMM, two DMMs, or other constellations) can be reduced to just one DSM that contains the computed indirect aggregate view. Figure 4 shows those cases that [24] listed. As can be seen, the approach caters for undirected and directed cases involving one DSM and/or one or two DMMs. To each case, a specific matrix multiplication generates the final DSMs (results of the computation are shown in brackets in the matrix).

Matthias Kreimeyer, Nikolas Bradford, Stefan Langer, Wieland Biedermann, et. al.

Native DMM (Case 1 & 2)

Two native DMMs (Case 3)

Document 1

Person 1

DMM

Task 1

DMM 1 DMM

Task 1

Native DSM + native DMM (Case 4 & 5)

DSM agg =DMM nat ⋅ DMM nat

T

Task 1

Task 2

Task 1

DMM DMM 2

Task 2

DSM

Native DSM + 2 native DMMs (Case 6)

Task 2

DSM agg =DMM nat, 2 ⋅ DMM nat,1

Task 2

DMM 1 DMM

Document 1

DSM

DMM 2

Document 2

DSM agg =DMM nat ⋅ DSM nat ⋅ DMM nat

Document 1 T

Document 2

DSM agg =DMM nat, 2 ⋅ DSM nat ⋅ DMM nat,1

T

Figure 4 Aggregation via path searching – Multiple-Domain matrix, graph, and aggregation formula (adapted from [24]).

[4] similarly regarded the potentials of matrix multiplication, using the MDM like a DSM (i.e. reducing each DSM and DMM within the MDM to a relationship among domains that serve as the entities of a DSM) to spot possible cycles among the domains and existing relationship types to identify those domains that can be used as a domain of reference for aggregation. Yet, both these approaches remain incomplete to the general principle of recombining domains and relationship types, and they only show fragmented solutions to the problem. However, they prove that aggregation is, essentially, possible and useful.

2.3. Other models To the best of the authors’ knowledge, other fields of complexity management, such as System Dynamics, Systems Theory, Systems Engineering, Graph Theory or Operations Research do not explicitly regard domains and relationship types as shown here. Thus, they do not provide explicit methods to aggregate such network structures. Only Network Science, best known for the “Six Degrees of Separation” that link – on average – every person to every other person in the world via five intermediate people [28], refers to “mixing patterns” in social networks, also referred to as homophily or assortative mixing [28]. The interest is in how different nodes in a network establish groups of similarity of a kind that are not directly represented in the network [29, 31]. A common example is a network of friendships in school. If e.g. the skin color of the

children is introduced into the study, the network will sort the nodes in a way that distinct black and white subgraphs will appear [26]. However, such patterns are found in statistical models that use a degree distribution or similar to model the network [30]; for these models, then, the statistically relevant correlations of nodes are sought that follow a certain criterion (e.g. how different people form friendships and are part of different ethnic groups). While the kind of modeling is not always directly transferrable, the principle of designating an indirect relationship between two entities in case they are attributed to a common object can nevertheless be used. In fact, it is quite similar to the leftmost case of aggregation via path searching as shown in Figure 4.

3. STRATEGIES FOR AGGREGATION As shown, networks can be of different kinds. All are similar in the fact that entities are of at least two different kinds that are coupled among them, and only the coupling via a second domain gives meaning to the first; however, more than one intermediate connecting domain is possible, too. This section regards the basic principles that govern such indirect relations. Three forms of aggregation are deduced.

3.1. Possible forms of aggregation and their principles The most reduced network of a system consists either of an intra- or an inter-domain network, modeled e.g.

SYSTEMATIC AGGREGATION OF DEPENDENCY MODELS

1125

as a DSM or a DMM. For these models, a vast body of means of analysis is available, and obtaining them is therefore desirable to be able to better manage any complex system. In turn, creating an aggregate view onto a system should yield either a DSM or a DMM, depending on the interest of aggregation. Similarly, inter- and intra-domain networks can either be directed or undirected. In turn, the resulting DSM or DMM should be directed or undirected, as necessary. However, discussion on whether the relationships shown in an individual DMM are actually directed is ongoing; for this context, it is considered that a DMM can contain either directed or undirected relationships [4]. This is in line with the reasoning for Multiple-Domain Matrices, which always contain at least two DMMs that are symmetric to the main diagonal, thus allowing for describing the directedness of a relation [24]. As the state of the art showed, different principles are possible to recombine several domains into a more condensed aggregate view: • Path searching • Attribution • Superposition These three kinds are explained below. Each time, the principle to produce an intra-domain network for one domain of reference (i.e. the resulting DSM) is shown as well as its derivative to produce an interdomain network (i.e. a DMM). Aggregation via path searching Path searching refers to finding a path across the domains and relationship types. It thus relies on the reachability at the level of the meta-model of a network, following all paths that can be taken based on the directedness of each relationship type. For reflexive aggregation, which produces an aggregate DSM, cycles at a meta-level are searched, as they are paths that start and end at the same domain. To compute the aggregate view, the matrices along the different circuits (a circuit is a cycle with a direction) are multiplied one after the other [4]. For inter-domain aggregation, which produces an aggregate DMM, all paths between the start- and enddomain are followed at the meta-level, and the matrices are multiplied along each path. If logic operators exist in the model, different paths can coexist. Figure 5 shows both cases: On the top, the indirect coupling of business objects via tasks is resolved to

1126

Figure 5

Aggregation via path searching.

obtain a DSM “business objects” that relates its entities to themselves. Below, a DMM is obtained that maps how business objects relate to IT systems via tasks. E.g. the DSM for business objects can be obtained by multiplying the two DMMs that link business objects to tasks and tasks to business objects, as shown in Figure 4. With path searching, often, multiple paths between a pair of domains can be found, often across several intermediate domains or several different relationship types. Figure 6 lists a few examples of native data (top) and the way these can be aggregated towards a domain of reference to obtain DMSs following all possible circuits with the domain of reference as the start and end domain. Typically, these need to be chosen with care to obtain meaningful constellations that relate to the analysis that is to be run on the model to be obtained. E.g. for the process in the initial example, the flow of information among the tasks might be of interest to obtain an ideal task sequence. To do so, the relationship between two tasks would, thus, be the transfer of a business object as the carrier of the information. Thus, aggregating tasks via business objects would mimic the process flow best possible.

Matthias Kreimeyer, Nikolas Bradford, Stefan Langer, Wieland Biedermann, et. al.

Example 2: 2 aggregate views possible

Business objects

IT

Possible aggregations

Native data

Example 1: 4 aggregate views possible

Business objects

Task

IT

Business objects

Business objects

IT

Task

Business objects

Task

Task

Task

Business objects

Task

IT

Task

Task Business objects

IT

Task

Business objects

IT

Task

Task

Figure 7 Figure 6 Examples of aggregate views across two other domains.

Aggregation via attribution A second mode of aggregation is possible by associating two entities that are related to the same entity in a different domain. Thus, undirected relationships can be generated, e.g. a relation between two documents that both are input to a task. Figure 7 illustrates (top) the case for a reflexive aggregation: The resulting DSM relates those business objects among each other that connect to the same task. If an aggregate DMM is to be obtained (bottom), an undirected matrix is generated that relates the two relevant domains via those objects that entities from both domains are connected to. Besides attributing the nodes, numerical properties of nodes can be taken into account as domain, towards which the domain of reference is attributed to. Thereby, the resulting relations become weighted. If two business objects are linked via a task as shown in Figure 7, the link can be weighted e.g. by the process cost of the task. To do so, the costs must be modeled as a diagonal matrix. The cost matrix is

Aggregation via attribution.

then included into the computation to derive the relations among the business objects. [5] discuss the limitations and potentials of the approach. It mainly offers a possibility to include handily available information into the aggregate views, enabling more sophisticated analyses [9]. However, this enhanced aggregation is not purposefully applicable when combined with aggregation via superposition as the numerical properties are lost in the process. Aggregation via superposition Ultimately, a third mode of aggregation is available by using the superposition of two or more networks; here, networks that share the same domain and the same set of entities (in identical order, if done using matrices) but different relationship types are superimposed to generate a model with possibly more dependencies at a coarser level of detail. Figure 8 illustrates both the computation of an aggregate DSM and an aggregate DMM: For the DSM, two native DSMs (having the same number of entities in the same order) are added to obtain a DSM with two relationship types. The same is possible for DMMs. However, superposition needs to be used

SYSTEMATIC AGGREGATION OF DEPENDENCY MODELS

1127

Native data

Aggregate view

Business objects DMM 2

DMM 1

„creates“

DSM 1 = DMM 1 · DMM 2 „creates business object that starts“

„starts“

Tasks

Tasks

Figure 9 Recombination or relationship types (for the example of path searching).

Unfortunately, there is no other systematic way to condense the aggregate relationship type any further. In many cases, however, a higher level of abstraction can be found; for the example shown above, the relationship type can be simplified as “task delivers information to task”, which is reasonably close to the original aggregate relationship type. However, these simplifications always include a loss of precision and, therefore, should be considered with care.

Figure 8

Aggregation via superposition.

with care, as mixing relationship types is normally not desirable for one matrix [19]; in fact, superposition should preferably only be used for matrices with identical or very similar relationship types, as only then a meaningful outcome can be generated.

3.2. Aggregate relationship types Special attention needs to be paid to aggregate relationship types, as the aggregate view contains the information about the involved domains, too. In principle, the relationship types and domains along the aggregation path are collected and chained up into the new, aggregate relationship type: First the initial relationship type is collected, then the intermediate domain, then the second relationship type (and so on, if more than one intermediate domain is used). Figure 9 demonstrates this recombination of relationship types. In the native dataset, tasks “create” business objects, and these business objects “start” tasks in turn. If this circuit is used to create an aggregate view on tasks, the aggregate relationship type is condensed into “tasks create business objects that start tasks”.

1128

4. VALIDATION: AN EXAMPLE FROM PROCESS MANAGEMENT To demonstrate the validity and usefulness of the approach, a large process model is regarded more closely in this section. All findings that are presented have been validated through interviews and feedback from engineers from the company whose process the case study reflects. This process serves as an example for a complex system in this paper; however, the approach shown is valid for other systems as well, as the discussion in section 5 will show.

4.1. An automotive body design process To demonstrate the different forms of aggregation and to show their use, a case study from process management is used. It is taken from a process improvement project that was run to improve communication among design and simulation engineers. During the project, a process model was used that will be used in the following. The process model used shows the design process of creating and simulating the body design of a premium class sedan. It was generated in a series of interviews and workshops within a major German car manufacturer. It is modeled in a modified EPC no-

Matthias Kreimeyer, Nikolas Bradford, Stefan Langer, Wieland Biedermann, et. al.

tation: Opposed to the original EPC [34], it uses an alternating sequence of tasks and business objects instead of functions and events; similarly, only OR decision points are used to obtain a model that is easier to understand. The model itself comprises 160 tasks, 134 business objects, 13 organizational units, and 22 IT systems across seven milestones.

to another IT system importantly: Up to four ORs can occur in between. To assess the process systematically, the process was modeled in EPC using the R (by IDS Scheer AG, Germany) and ARIS Toolset then exported into an MDM to make it accessible to the matrix multiplications as discussed in the previous section.

4.2. The meta-structure within the process model

Figure 11 shows the Meta-MDM with the domains and relationship types as found in the meta-model. In addition, each sub-matrix (i.e. DMM) that was available as native data from the original process model, received an ID; furthermore, four DSMs (ID 1, ID 8, ID 15, and ID 29) were designated as possible aggregations. E.g. the DSM in the top left corner of the MDM (ID 1) represents the aggregation of tasks among them. In the case study, only reflexive aggregate views were created, i.e. only DSMs were created. However, the intermediate results to create these DSMs were DMMs, thus the case study validates, in fact, both facets of aggregation.

Figure 10 shows the domains and relationship types as an entity-relationship diagram. There, no domain is coupled to itself, i.e. all entities within the process model always are coupled via at least one intermediate domain. Org. unit Organizational unit is responsible for task

IT system supports task Task

IT system

Business object is input for task

OR-decision precedes OR-decision

Task generates business object

OR

Business object is necessary to reach milestone Business object

Milestone

Figure 10 Entity-relationship diagram of domains and relationship types in case study.

In turn, e.g. IT systems are only connected via tasks, which are connected via business objects, i.e. there is always a path of a minimum length of four in between two IT systems. Aggravatingly, the process model not only relates tasks and business objects directly, but they are also coupled using OR operators in between, representing major decision points where the process goes e.g. into iteration or produces different alternative designs. These decision points, again, can be coupled among them in a precedence relationship. In the actual process model, a maximum of two ORs is found in between any set of a task and business object as a join succeeded by a split. This increases the number of possible paths from e.g. an IT system

4.3. An aggregate view on tasks using path searching and superposition Four reflexive aggregate intra-domain views are possible; each view could, theoretically, be computed in several ways. However, only those aggregations that realistically represent the process execution were chosen; therefore, tasks were aggregated via the intermediate business objects. Similarly, business objects were aggregated via the intermediate tasks. Organizational units and IT systems each were aggregated via the tasks and intermediate business objects. Milestones were, in fact, not further regarded in the actual project, as data quality on the relevant relationships prove too low. In the following, the aggregation via path searching for DSM ID 1 is regarded, as it serves as a basis for most other aggregations, too (e.g. IT systems or organizational units are connected via tasks and their intermediate business objects). All other aggregations, however, would be computed in the same manner, and the results of these aggregations are shown, too, in a later section. For the case study shown, the aggregation via path searching makes use of aggregation via superposition, too. This is due to the fact that tasks can be coupled to business objects via alternative paths to business objects. Therefore, two tasks can be connected via several paths at the same time that need to be superposed to generate the final picture.

SYSTEMATIC AGGREGATION OF DEPENDENCY MODELS

1129

ID 1

Tasks T

OU

BO

T

T

ID 2

ID 7 BO

BO is input for T

Organizational units OU

OU

OU is responsible for T

ID 1

ID 6

T generates BO ID 10

ID 8

ID 1

BO is necessary to reach M

ID 13

ID 12

BO is input for T

ID 15

M

ID 25

IT Systems IT

IT

IT supports T

OR Connectors OR

OR

BO is input for T

ID 29

ID 31

Figure 11

OR

T generates BO

Business objects BO

Milestones M

IT

M

ID 32

ID 36

T generates BO

OR precedes OR

Meta-MDM for the process model. ID 1.1b

ID 1.2b

ID 1.3b

(ID 7)

(ID 12 · ID 31)

(ID 12 · ID 36 · ID 31)

ID 1.1a =

ID 1.1a · ID 1.1b =

ID 1.1a · ID 1.2b =

ID 1.1a · ID 1.3b =

(ID 2)

ID 2 · ID 7

ID 2 · ID 12 · ID 31

ID 2 · ID 12 · ID 36 · ID 31

ID 1.2a =

ID 1.2a · ID 1.1b =

ID 1.2a · ID 1.2b =

ID 1.2a · ID 1.3b =

(ID 6 · ID 32)

ID 6 · ID 32 · ID 7

ID 6 · ID 32 · ID 12 · ID 31

ID 6 · ID 32 · ID 12 · ID 36 · ID 31

ID 1.3a =

ID 1.3a · ID 1.1b =

ID 1.3a · ID 1.2b =

ID 1.3a · ID 1.3b =

(ID 6 · ID 36 · ID 32)

ID 6 · ID 36 · ID 32 · ID 7

ID 6 · ID 36 · ID 32 · ID 12 · ID 31

ID 6 · ID 36 · ID 32 · ID 12 · ID 36 · ID 31

Figure 12

Superposition of nine occurring DSMs for paths across different constellation of OR operators.

The basic aggregation collects all paths between each pair of tasks. These will always lead via one intermediate business object. However, there can be none, one or two (or, theoretically, any number) of ORs within this path. For the creation of a complete aggregate view for tasks, 32 cases need to be combined to create a network that spans all possible combinations. Figure 13 visualizes these three different possible paths between a task and a business object; each of them can occur for the path from a task to a business object and for the path from a business object to a task. In total, therefore, nine possible paths are possible for reflexive aggregation. Figure 12 visualizes these nine DSMs that occur from multiplying each DMM on the top half of Figure 13 (IDs 1.1a, 1.2a, and 1.3a) to each DMM on the lower half (IDs 1.1b, 1.2b, and 1.3b). To obtain a complete DSM that represents all possible relations via all alternative paths, thus, all nine resulting DSMs need to be superposed, i.e. added. The resulting matrix then takes shape as a DSM with ID 1.

1130

4.4. Aggregation for other domains of reference The shown procedure similarly applies to the other possible aggregate views. Business objects can be aggregated via intermediate tasks and OR connectors (DSM with ID 8), and organizational units can be aggregated via tasks (ID 29). Therefore, for organizational units, the aggregation shown above can be applied and extended to create an organizational unit DSM. The same can be done for IT systems for the matrix with ID 36. All of these networks are fully coherent for the case study, as the model quality of the initial process map is of very good quality. Only the aggregation for the milestones was omitted, as the mapping between business objects and milestones prove to be very limited.

4.5. An aggregate view on tasks using attribution To exemplify the use of attribution as the basis for creating an aggregate view, all those tasks were regrouped as related in a DSM that share the same IT systems. This way, all those engineers who need the same skills to operate their tools can be regrouped, for example.

Matthias Kreimeyer, Nikolas Bradford, Stefan Langer, Wieland Biedermann, et. al.

Superposition

ID 1.1a

ID 1.2a

ID 1.3a

Aggregate view ID 1

Task 1

Task 1

Task 1

Task 1

ID 6 ID 6

OR

„Task generates business object that is input for task“ ~ “Task precedes task”

OR

ID 2

ID 36 OR

ID 32 ID 32 Business object A

Business object A

Business object A

ID 1.1b

ID 1.2b

ID 1.3b

Business object A

Business object A

Business object A

ID 12 ID 12 OR

ID 7

OR

ID 36 OR

ID 31 ID 31 Task 2

Task 2

Task 2

Task 2

Figure 14 Resulting DSM of aggregating tasks attributed to IT systems (schematic).

quence, which would not have been possible with existing algorithms if no aggregate view had been at hand. In the process improvement project, this sequence was, used as a basic timeline to synchronize all activities within the process.

Figure 13 Possible paths from tasks to business objects and back via any combination of no, one, or two OR operators.

The DSM is colored from green (weight 1, i.e. related via one IT system) to red (weight 8, i.e. eight tools are similarly used by two tasks). As can be seen, some clusters (e.g. top left and a little further below along the diagonale) appear where tasks are closely interconnected among a limited set of IT tools – e.g. the top left cluster represents the tasks related to the initial concept design and the simulation tools that are used to assess the concept design towards vibration, crash, and other load cases.

4.6. Using the aggregation The aggregate views obtained can be used in a variety of ways. Above all, they can now be treated like any DSM, thus they can be submitted to triangularization, banding, tearing, clustering, or more advanced algorithms as e.g. [24] or [10] suggest. Furthermore, the use of complexity metrics is possible [1, 21, 25]. As an example, Figure 15 shows the triangularized DSM for the aggregate view on tasks (only the lower right part of the triangularized matrix is shown). In fact, the process can be put into a very clean se-

Figure 15

Part of the triangularized task DSM.

Another insight can be gained from e.g. the application of complexity metrics to the resulting aggregate views, e.g. the task DSM. Figure 16 shows the values and the plot of the fifteen highest-ranking tasks for the centrality measure [13]. This complexity metric counts the number of paths from any task to any

SYSTEMATIC AGGREGATION OF DEPENDENCY MODELS

1131

Figure 16

The fifteen highest ranking tasks for their centrality measure.

other task in the computed task DSM to see which task serves as the most important broker for information, thus having the strongest influence on the overall process by controlling the forming of opinions within the process.

gorithms and metrics that are only suitable to work with one domain, as commonly established, can be applied to more complex process networks. Therefore, an MDM is advantageous for a more holistic analysis.

Here, the task “coordinate simulation of crash” shows u as most importantly, which was confirmed by the engineers in the process, who focus their development efforts on the fulfillment of EURO-NCAP ratings (crashworthiness) as one of the core requirements of the development process. While this was implicitly clear, only the computation of a measure based on an aggregate view could actually confirm the engineers’ gut feeling about this.

However, the methodology still has a number of shortcomings. Especially, the recombination of several native relationship types into an aggregate relationship type is complete, yet unsatisfying, as especially aggregations across several domains produce complex relationship types that are hard to work with; here, more work will be done in the future as to the simplification of such descriptions. However, it needs to be based on empirical evidence to ensure the rigor of the simplifications. The relevance and necessity of long aggregations, especially, are of interest, as these would also aggregate modeling errors that, possibly, cannot be avoided, while at the same time produce relevant insights into implicit relations across any system.

5. CONCLUSION AND FUTURE WORK The aggregation of large networks as presented here is, above all, useful for large systems that involve many domains and many relationship types. For such systems, it enables a more targeted and compact representation by selecting a specific view onto the existing model without simplifying it unnecessarily. Rather, relevant aspects are recombined and condensed to enable the system architect to better understand, analyze and improve the structure, i.e. the arrangement and entities of the system. As such, e.g. a process model that consists of several domains becomes accessible for more straightforward analysis without reducing its complexity. By doing so, onesided improvements can be avoided during the analysis of a process model. Furthermore, existing al-

1132

Furthermore, long aggregations across several domains often generate very densely populated DSMs (or DMMs, respectively). These matrices do not always work with existing algorithms; e.g. a clustering for a matrix that is practically “full” is useless. However, the aggregation typically produces many parallel paths that take shape as multiple paths between the entities, i.e. as numbers greater unity in the cell of a matrix. Thus, aggregation introduces, in fact, a weighing towards the connectedness of an entity to another entity. On the long run, these could

Matthias Kreimeyer, Nikolas Bradford, Stefan Langer, Wieland Biedermann, et. al.

be used to improve the algorithms available for DSM and DMM analysis. While the paper shows the possible aggregations, the selection of purposeful aggregations is only touched upon; here, a detailed description of principles and the procedure to select aggregate views purposeful to a certain goal still need to be elaborated. This, however, is part of another paper. Yet, so far, the approach has only been detailed for reflexive views and for digraphs; it still needs extending to be suitable for any kind of relationship (directed/undirected, weighed or not) and their combination in a mixed graph. The approach shown is, therefore, limited to qualitative networks, i.e. the pure existence of a directed relationship. Furthermore, most work was carried out based on a process study, and the transferability to other networks (e.g. a product architecture) has only been shown in part.

[6] [7]

[8]

[9]

ACKNOWLEDGMENT This research was made possible through the generous funding by the German Research Foundation (DFG) in the context of project A2 (“Modeling and analysis of discipline-spanning structural criteria and their impacts on product development processes”), project B1 (“Process Planning of cycle-oriented Development of PPS”) and the working group Q2 (“Development of models and processes”) within the Collaborative Research Centre 768.

[10]

[11]

REFERENCES [1]

[2] [3]

[4]

[5]

Ameri, F., Summers, J., Mocko, G.M., and Porter, M., (2008), “Engineering design complexity: an investigation of methods and measures”, Research in Engineering Design, Vol. 19 (2-3), pp. 161-179. Bar-Yam, Y. (Ed.), (1997), “Dynamics of complex systems”. Becker, J., Kugeler, M., and Rosemann, M., (2005), “Process Management”, Springer, Berlin. Biedermann, W., and Lindemann, U., (2008), “Cycles in the Multiple-Domain Matrix – Interpretation and Applications”, Proceedings of the 10th International DSM Conference, Kreimeyer, M., Lindemann, U., Danilovic, M. (Eds.), Hanser, Stockholm, pp. 25-34. Biedermann, W., Maurer, M., and Lindemann, U., (2007), “The Multiple-Domain-Approach and Cost Attributes”, Proceedings of the 9th International DSM Conference, Lindemann,

[12]

[13]

[14]

[15]

[16]

U., Danilovic, M., Deubzer, F., Maurer, M., Kreimeyer, M. (Eds.), Shaker, Munich, pp. 287-295. Blanchard, B.S., (2008), “Systems Engineering Management”, John Wiley & Sons Hoboken. Boardman, J., and Sauser, B., (2006), “System of Systems – the Meaning of of”, Proceedings of the IEEE/SMC International Conference on System of Systems Engineering, IEEE, Los Angeles, pp. 6-12. Bonjour, E., (2008), “Contributions l’instrumentation du m´etier d’architecte systme : de l’architecture modulaire du produit l’organisation du systme de conception”, Habilitation de l’Universit´e de Franche-Comt´e, Besanc¸on. Braun, S.C., Biedermann, W., and Lindemann, U., (2008), “Design to Cost: New Impulses for Target Costing”, Proceedings of the International Design Conference, Marjanovic, D., Storga, M., Pavkovic, N., Bojcetic, N. (Eds.), Dubrovnik, Croatia, pp. 317-326. Browning, T.R., (2001), “Applying the Design Structure Matrix to System Decomposition and Integration Problems: a Review and New Directions”, IEEE Transactions on Engineering Management, Vol. 48 (3), pp. 292-306. Danilovic, M., and Browning, T.R., (2007), “Managing complex product development projects with design structure matrices and domain mapping matrices”, International Journal of Project Management, Vol. 25 (3), pp. 300314. Deger, R., (2007), “Managing Complexity in Automotive Engineering”, Proceedings of the 9th International DSM Conference, Lindemann, U., Danilovic, M., Deubzer, F., Maurer, M., Kreimeyer, M. (Eds.), Shaker, Munich, pp. 13-23. Freeman, L.C., (1978), “Centrality in Social Networks-Conceptual Clarification”, Social Networks, Vol. 1 (3), pp. 215-239. Goldenfeld, N., and Kadanoff, L.P., (1999), “Simple Lessons from Complexity”, Science, Vol. 284 (5411), pp. 87-89. Gross, J.L., and Yellen, J., (2005), “Graph Theory and its Applications”, Chapman & Hall/CRC, Boca Raton. Guillaume, J.-L., and Latapy, M., (2004), “Bipartite structure of all complex networks”, Information Processing Letters, Vol. 90 (5), pp. 215-221.

SYSTEMATIC AGGREGATION OF DEPENDENCY MODELS

1133

[17] Heisenberg, W., (2007), “Physics and Philosophy”, Prometheus Books, New York. [18] Holland, J.H., (1996), “Hidden Order: How Adaptation Builds Complexity”, Addison Wesley Publishing Company. [19] Jarratt, T.A.W., (2004), “A Model-based Approach to Support the Management of Engineering Change”, Cambridge University Engineering Department, Cambridge. [20] Kreimeyer, M., Braun, S., G¨urtler, M., and Lindemann, U., (2009), “Extending Multiple Domain Matrices to Allow for the Modeling of Boolean Operators in Process Models”, Proceedings of the International Conference on Engineering Design - ICED’09, The Design Society, Stanford, CA, USA. [21] Kreimeyer, M., K¨onig, C., and Braun, T., (2008), “Structural Metrics to Assess Processes”, Proceedings of the 10th International DSM Conference, Kreimeyer, M., Lindemann, U., Danilovic, M. (Eds.), Hanser, Stockholm, pp. 245-258. [22] Langer, S., Kreimeyer, M., M¨uller, P., Lindemann, U., and Blessing, L., (2009), “Entwicklungsprozesse hybrider Leistungsb¨undel – Evaluierung von Modellierungsmethoden unter Ber¨ucksichtigung zyklischer Einflussfaktoren”, in: Dienstleistungsmodellierung Methoden, Werkzeuge und Branchenl¨osungen, Thoma, O., N¨uttgens, M. (Eds.), PhysicaVerlag, Heidelberg, pp. 71-87. [23] Lindemann, U., Maurer, M., and Braun, T., (2009), “Structural Complexity Management”, Springer, Berlin. [24] Maurer, M., (2007), “Structural Awareness in Complex Product Design”, Lehrstuhl f¨ur Produktentwicklung, TU M¨unchen. [25] Mendling, J., (2008), “Metrics for Process Models”, Springer, Berlin. [26] Moody, J., (2003), “Race, School Integration, and Friendship Segregation in America”, American Journal of Sociology, Vol. 197 (3), pp. 679-716. [27] Newell, A., (1990), “Unified Theories of Cognition”, Harvard University Press, Cambridge, MA. [28] Newman, M.E., (2003), “The Structure and Function of Complex Networks”, SIAM Review, Vol. 45 (2), pp. 167–256. [29] Newman, M.E., (2002), “Assortative Mixing in Networks”, Physical Review Letters, Vol. 89 (20), p. 208701.

1134

[30] Newman, M.E., (2003), “The Structure and Function of Complex Networks”, SIAM Review, Vol. 45 (2), pp. 167–256. [31] Newman, M.E.J., (2003), “Mixing patterns in networks”, Physical Review E, Vol. 67 (2), p. 13. [32] Papadimitriou, C.H., (1994), “Computational complexity”, Addison-Wesley, Reading, Mass. [33] Rind, D., (1999), “Complexity and Climate”, Science, Vol. 284 (5411), p. 105. [34] Scheer, A.-W., (1999), “ARIS - Business Process Modeling”, Springer, Berlin. [35] Steward, D.V., (1981), “The design structure system: A method for managing the design of complex systems”, IEEE Transactions on Engineering Management, Vol. 28, pp. 71–74. [36] Wasson, C.S., (2006), “System Analysis, Design, and Development Concepts, Principles, and Practices”, Wiley Interscience, New York. [37] Weng, G., Bhalla, U.S., and Iyengar, R., (1999), “Complexity in Biological Signaling Systems”, Science, Vol. 284 (5411), p. 92. [38] Zuse, H., (1998), “A Framework of Software Measurement”, de Gruyter, Berlin.

Matthias Kreimeyer, Nikolas Bradford, Stefan Langer, Wieland Biedermann, et. al.