Insights into enterprise conceptual modeling

Data & Knowledge Engineering 69 (2010) 1302–1318

Contents lists available at ScienceDirect

Data & Knowledge Engineering j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / d a t a k

Insights into enterprise conceptual modeling Ateret Anaby-Tavor a, David Amid a,⁎, Amit Fisher a, Avivit Bercovici a, Harold Ossher b, Matthew Callery b, Michael Desmond b, Sophia Krasikov b, Ian Simmonds b a b

IBM Haifa Research Center, Haifa University Mount Carmel, Haifa 31905, Israel IBM Thomas J. Watson Research Center, P.O. Box 704, Yorktown Heights, NY 10598, USA

a r t i c l e

i n f o

Article history: Received 10 March 2010 Received in revised form 26 September 2010 Accepted 4 October 2010 Available online 13 October 2010 Keywords: Conceptual modeling Business analysis Enterprise architecture Flexible modeling Modeling techniques

a b s t r a c t Business analysts, business architects, and solution consultants use a variety of practices and methods in their quest to understand business. The resulting work products often end up being transitioned into the formal world of software requirement definitions or as recommendations for all kinds of business activities. We describe an empirical study about the nature of these methods, diagrams, and home grown conceptual models as reflected in real practice at IBM. We identify the models as artifacts of “enterprise conceptual modeling”. We study important features of these models, suggest practical classifications and characterizations, and distinguish them from drawings. Specifically we look into context, type, methods and complexity to determine enterprise conceptual models usage. Our survey shows that the “enterprise conceptual modeling” arena presents a variety of descriptive models, each used by a relatively small group of colleagues. Together they form a spectrum that extends from “drawings” on one end to “standards” on the other. © 2010 Elsevier B.V. All rights reserved.

1. Introduction Conceptual modeling is defined as the process of formally documenting a problem domain for the purpose of understanding and communicating among stakeholders [24]. Most of the published research in the conceptual modeling space is theoretical, conceptual, and/or analytical, with a limited share of empirical papers [20]. Hence, the research presented in this article is an empirical study into the nature of the conceptual models used in practice. Traditionally, it is acknowledged that “in practice, almost all conceptual models are used to develop, acquire, or modify information systems” (Moody et al. [20]). However, recent studies [4,21] observed that “conceptual modeling” has gained popularity for purposes beyond traditional systems analysis and design. This article aims to corroborate this contemporary approach by providing insight into how business stakeholders use conceptual modeling and the nature of the artifacts they create. Throughout this article, the term enterprise conceptual models refers to conceptual models that focus on the business/enterprise domain rather than the traditional information systems domain. The significance of this research lies in its theoretical, empirical, and practical levels. This study contributes to the extant body of research by increasing the understanding of the special characteristics of enterprise conceptual modeling, thereby recognizing it as a sub-discipline of conceptual modeling. Empirically, we focus on two aspects: the nature of enterprise conceptual models and the nature of business stakeholders' practice. Specifically we try to answer the following questions: – For which tasks do practitioners use conceptual models? – What types of conceptual models do practitioners use while undertaking each task? – What level of complexity do conceptual models demonstrate? ⁎ Corresponding author. Tel.: + 972 4 8281056; fax: +972 4 8296115. E-mail addresses: [email protected] (A. Anaby-Tavor), [email protected] (D. Amid), [email protected] (A. Fisher), [email protected] (A. Bercovici), [email protected] (H. Ossher), [email protected] (M. Callery), [email protected] (M. Desmond), [email protected] (S. Krasikov), [email protected] (I. Simmonds). 0169-023X/$ – see front matter © 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.datak.2010.10.003

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

1303

– What types of methods/guidance do practitioners use to support their conceptual models? – How can business stakeholders distinguish drawings from conceptual models? Practically, we aim to provide guidelines to practitioners, tool vendors, and researchers, to help increase the quality and usefulness of enterprise conceptual modeling. In particular we discuss means for practitioners to capture intellectual capital and increase knowledge transfer effectiveness. We demonstrate how tool vendors can automate artifacts and models profiling, allowing experts to accelerate their ability to identify potential for template reuse. In addition by analyzing the characteristics of enterprise conceptual models we suggest tool vendors certain features such as context-awareness, method guidance and complexity assessment which will increase the usability of conceptual modeling tools. The rest of the article is organized as follows: Section 2 describes related work. Section 3 specifies our research method and Section 4 describes the empirical results on the nature of enterprise conceptual models and the nature of business stakeholders' practice. We conclude in Section 5.

2. Related work Kaindal et al. [17] examined why, for many years, research results in requirements engineering (RE) have been developed without much interaction with, or impact on, industrial practice. Conceptual modeling as a sub-discipline of requirements engineering suffers from the same lack of empirical studies. Though the need for such studies is well recognized, very little research exists [19]. Most of the published research in the conceptual modeling space is theoretical, conceptual, and/or analytical, with a limited share of empirical papers [20]. Davis et al. [10] noted the lack of empirical investigation of modeling in practice. Their work, however, was limited in that it was a survey based only on web textual interviews and focused on conceptual modeling in the software engineering space. They described the principal tools and techniques, and the purposes for which conceptual modeling is performed. In particular, they described differences due to the size of the organization and years of experience. Others [5,22] interviewed experienced consultants to explore the advantages and disadvantages of process modeling, which covers 30% of the conceptual modeling space [10]. Of the few empirical studies, most concentrated on process modeling, a sub-discipline of enterprise conceptual modeling [5,14,22]. Davis et al. provide further background on other empirical studies, which are either dated (done in the late 1980s), focused on system development, or limited to interviews [10]. Amber [1] claims that the vast majority of modeling teams are sketching, and not using CASE or CAD tools. Although Amber mainly refers to software teams, his finding counters approaches like that of H. Kilov et al. [16] that suggest the RM-ODP standard for semantic interoperability between the different business stakeholders. Our experience shows that in reality, business analysts prefer using their own plurality of methods with different guidelines, patterns, syntaxes, and notations. Corroborating that, a recent survey [21] concluded that enterprise modeling activities require a modeling expert. In fact, most modeling experts look for tools that provide as much freedom as possible.

3. Background and research method The genesis of this research was a three-day workshop in June 2007 for 12 IBM business architects. The workshop focused on attendees' life in the field. A central finding of that workshop was that business analysts use a holistic approach, including ideas from business and, to a lesser extent, IT. They gather information relevant to a business or pre-identified business problem, and then organize and make sense of it to identify business issues and potential solutions. A presentation is created that is used to communicate to a client proposed solutions and their value to the client's business. Thus business analysts help their clients frame business problems and explore a variety of feasible solutions. Their role is one of envisioning that often results in business transformation. The final outcome of their work is a presentation or report, containing a variety of tables, business process diagrams, organizational diagrams, as-is system diagrams, and so forth. Template reuse is a common working style. This is particularly true for consultants who apply their accumulated experience and expertise to address similar issues for a series of clients. Templates help organize findings into pre-defined categories and representations that have been found helpful in past engagements. Often the template will be adapted to fit the needs of a particular engagement. A common adaptation is to change the style and vocabulary to fit the storyline, taste, and culture of the client. To further understand the nature of their day-to-day work and the artifacts they produce, we sent an appeal to the broad community of business analyst thought leadership in IBM. The goal was to understand how conceptual models are used in day-today practice by collecting a large number of “home grown” conceptual models that have an underlying structure and are likely to be reused in many engagements. We got around 60 actual requests to participate in the experiment, with approximately 70 artifacts such as slide decks and reports. A testimony to the plurality of our sample can be seen when examining the heterogeneity of participants. Though 60% of the participants were business analysts, business architects or business consultants, they came from various industries and divisions, such as finance, the public sector, sales, marketing, and business development. They included solution consultants, strategy consultants, portfolio architects, application architects, and more. The rest of the participants came from other divisions across the company. Interestingly, they were also geographically distributed as follows: 44% of the participants were located in the USA, 14% in UK, and all the rest scattered over the globe.

1304

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

The survey in this article is based on a sample of 186 different diagrams that were elicited from the above collection, each serving as a representative of a distinct conceptual model or drawing. No judgmental sampling was conducted except for the choice to focus on graphic models, although some of the participants sent us text documents and MS-Excel files. Accordingly, the figures of conceptual models and diagrams in this article are real artifacts, in which original text has been replaced with neutral text for the sake of confidentiality. Therefore it should be noted that these figures are meant to convey the abstract syntax [2] of the models and the text is only illustrative. Our sample shows that artifacts can be grouped according to the following formality levels: – Unstructured diagrams — drawings – Semi-structured diagrams — “home grown” conceptual models – Fully structured diagrams — standards or “known methods” that have established norms and vast agreement on their syntax and structural constraints like Entity Relationship Diagrams (ERD) [6]. Although semi-structured diagrams represent more “fuzzy” models than the fully structured diagrams, they still obey specific syntactic rules (as opposed to drawings). Semi-structured diagrams are typically used by a community of practitioners who have found the semi-structured models adequate to their specific tasks. There are several reasons for the emergence of a semistructured model, of which most prominent is the inability of the standards to cover the problem space at hand. Such semistructured artifacts are likely to be built within client projects, and gain more structure over time. They are typically used during exploration phases where things are unclear and ambiguous. At these stages conceptual model authors gather information, organize it to gain insight, envision alternative possible futures, and present recommendations to stakeholders. These affect and even shape subsequent phases where standards are more applicable. As opposed to industrial standards, semi-structured diagrams offer practitioners flexibility. They promote principles such as delayed commitment to syntax, unconstrained development order, and an evolvable re-factorable metamodel. This requires highly expressive freeform user experience which cannot be found in traditional modeling tools which support standards and industrial standards. In our collection, 108 diagrams were identified as semi-structured diagrams; this was the majority (58%) of diagrams in our sample, 73 (39%) of the diagrams were drawings and 5 (3%) work products were based on standards. The significant number of semi-structured diagrams probably stems from the fact that we deliberately asked for “home grown” conceptual models that are likely to be reused across engagements. In this article, we focus on the characteristics of the “home grown” conceptual models, comparing them to drawings and standards. Semi-structured models can evolve to standards using flexible modeling tools such as [11]. Semi-structured models are the natural fit to this type of tools. Hence flexible modeling tool vendors can utilize the findings in this article to understand the nature of semi-structured models and increase the tools suitable to them. Differentiating the semi-structured models from the drawings can jumpstart template reuse as shown in Section 4.5. Using our findings, syntax aware editors can be seeded with the semi-structured models' grammar using algorithms such as in [2]. These solutions rely on the ability to differentiate between drawings and semi-structured diagrams as a means to better their input. In the next section, we provide our analysis of the results and conclusions. All the qualitative analysis was done in the form of dual coding. Two people agreed on a coding scheme and then apply it independently. When the artifact analysis was not clear or there was no consensus, we returned to the practitioner who sent the artifact and consulted them on the appropriate analysis. Throughout this article, we measure the strength of relationships between different factors (such as method, repeated instances, associated task context, etc.) associated with the diagrams. We use two statistical coefficients both are adequate for nominal data: A. The Goodman and Kruskal Lambda coefficient [13] is used for its asymmetric flavor when we want to measure predictive associations between two factors. It introduces the proportional reduction in error (PRE) measure, which means that its value reflects the percentage reduction in errors in predicting the dependent variable, given knowledge of the independent variable. This coefficient takes values on the unit interval, while a value of unity indicates a perfect predictive association. We designate a dependency of factor A on factor B by: λA|B. For example, a lambda of 0.35 means that there was a 35% reduction in error in predicting the dependent variable when the independent variable was taken into account. B. Cramer's V [23] is used to measure the symmetric association between two attributes. It compares the observed joint distribution of the two variables and the expected one (if there was no correlation). The square of the result indicates how much shared variance is taken into account by the relationship. As in the Lambda coefficient, the closer the result is to unity, the stronger the relationship. We designate Cramer's V correlation by: Vc. All the correlation questions were validated with statistical significance of more than 95%. It's worth noting that 9% of the diagrams (16 diagrams) were obtained within an eclectic deck. This deck was an assortment of diagrams in which peripheral information, like the information about the engagements they were taken from wasn't specified. To keep the sample unbiased, these diagrams were used only where the values of examined attributes were known. Therefore these diagrams were used in the analysis that appears until the end of Section 4.2. 4. The nature and practice of enterprise conceptual modeling In this section, we describe useful classifications and characteristics of the artifacts in our sample. Such artifacts gain structure incrementally over time. Consequently, elements of the conceptual model become repeatable constructs, with certain relationships between them, when practitioners must utilize the same way of thinking in different environments, e.g., in a different engagement. This is the point in time where sketching transforms into a semi-structured artifact. We further discuss the

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

1305

elements in the research framework on conceptual modeling as defined by Wand and Weber [25]. We examine the context in which conceptual models are created and evaluate the types of methods that accompany them. We believe these insights illuminate important aspects into the nature and practice of the enterprise conceptual modeling world. 4.1. For which tasks do practitioners use conceptual models? Wand et al. [25] assert that the creation and use of conceptual models are undertaken within a particular context termed the task contextual factor. Moreover, Wyssusek et al. [28] claim that conceptual modeling is not an end in itself; the conceptual models eventually created are not a terminal but an intermediate goal, since those models — once created — serve as means for further ends. Specifically, Kung et al. [18] identify the following uses for conceptual models: helping analysts to reason about domains; communication between analysts and users; communication between analysts and designers; documenting system requirements for future reference. In the following, we describe the tasks for which the conceptual models were used in our sample. Table 1 presents a list of context topics, the themes each topic encompasses, and the usage frequency of each theme as found in our sample. The table clearly demonstrates that organizational structure, IT architecture, and service centers are the three prominent topics accounting for more than 50% of the artifacts. We are aware that the second and third themes may be related to the specific audience of participants, as both are typical of the work of IBM consultants. These three context topics also lead to the corollary that the prevailing task of the practitioners in our sample is the alignment of IT with business aspects. For comparison, it is interesting to examine the tasks for which the drawings in our sample were used. Table 4 presents the frequencies of context topics for conceptual models and drawings side by side. The top three context topics accounting for over 50% of the drawings are: business context, business model, and solution offering. All three seem to be general domains that represent classic uses for graphical explanations. Business model doesn't appear at all within the conceptual model's context list, while documentation and information entities interaction are missing from the drawing's context list. Although some context topics overlap between the two tables, the different dominancy suggests that drawings and conceptual models are used as means for different tasks. Table 4 further analyzes the difference between the tasks for which practitioners use conceptual models, and the tasks for which they use only drawings. The next discussion examines the relations between the conceptual models' tasks and the types of conceptual models used for each one. 4.2. What type of conceptual models do practitioners use while undertaking each task? We classified the conceptual models into families according to common properties and underlying structures. Such a categorization may reveal that some families are more typically used for certain tasks than others, hence guiding practitioners and tool vendors to choose the relevant type of diagram for the task at hand. The following is a list of the families extracted from our sample with our interpretation of each family: A. Nodes and edges (graphs) — all the members of this group comprise edges that connect pairs of nodes. Some may have directed edges (in the form of arrows), while others may have unconnected nodes. B. Tables — the underlying model of the members of this group is composed of a composite object that has part–whole hierarchies with column objects, which in turn have part–whole hierarchies with row objects. Rows can further contain components or free text. C. Trees — models in this family have an underlying connected acyclic graph with hierarchical structure. It is worth noting that some of the diagrams included aberrations from the original underlying structure. For example, Fig. 2 shows a “mind map” hierarchy with relations between leaves. D. Cartesian coordinate systems — family members have static axes where points/shapes are positioned in a plane. Table 1 Contexts for use of conceptual models. Context topic

Description

# models

Percentage

Organizational structure IT architecture Service centers Business context Corporate culture Value chain management Competition landscape Business operations architecture Solution offering/application portfolio Organize/generate ideas/concepts Documentation Information entities interaction Requirements analysis Financial analysis

Organizational structural forms, sub-units, hierarchies, entity interaction Technology components/layers Organizational competencies and components Relationships between business systems/entities, business concepts interaction Social relationships, vision, values, focus Value creation, value capturing, value networks Competitive performance, competitive advantage, players in business environment Process models, hierarchies and decompositions To-be view of application portfolio, architectural building blocks-systems, sub-systems Change management, decision making, mappings As-is models, manuals, proposals Concepts of information and their relationships/associations Use cases and flows Cost vs. revenue

26 18 13 9 9 7 6 4 4 4 3 2 2 1

24 17 12 8 8 6 6 4 4 4 3 2 2 1

1306

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

Fig. 1. Onion map.

E. Layer diagrams — elements in these diagrams are placed above one another and may be semi-detached. Some of these models may demonstrate hierarchal relationships between elements (by using hierarchical numbering of these elements). F. Circle/onion maps — diagrams are in the form of concentric circles sometimes with the addition of slices. Fig. 1 shows an example of such a diagram. The above categories are not necessarily mutually exclusive nor are they exhaustive. For example, the trees group can certainly be viewed as a subset of the graphs family. In the same way, “stars” (which are very significant to social network analysis) can be viewed as another distinct group of graphs. Four-square models (which are commonly used in strategy and market analysis) can also be viewed as a distinct group within the Cartesian coordinate systems family. As a comparison to our categorization one may relate to Microsoft SmartArt graphics,1 which is a visual representation for conveying information and ideas that applies to MS Office tools. SmartArt graphics contain layouts such as Process, Cycle, Hierarchy, Relationship, Matrix, Pyramid and List. Another comparison can be made with the generic graphic structures described by B.F Jones et al. [15]. They provide nine generic graphic forms, which are visual illustrations of verbal statements: Spider maps, Series of events chains, Continuum/Scale, Compare/Contrast Matrix, Problem/Solution Outline, Network Tree, Human Interaction Outline, and Cycle. Table 2 juxtaposes the three categorizations such that the rows outline the commonality that can be found between them. The criteria for comparisons were the user needs satisfied by each categorization, and underlying structure. As can be seen by examining the table horizontally, there are counterparts for all three categorizations in each row. Still there is a difference in the purpose for which each categorization was created. While the main purpose of the SmartArt graphics is to “communicate a message”, the Jones's Graphic Forms are meant to help organize information for “skilled thinking”, mainly for the process of understanding text. Our categorization encompasses both purposes, and more; for example, we also took into account the model infrastructure for syntax aware editors [8,9]. Consequently, our categorization is less detailed. For example, in the graph family we did not distinguish between graphs that are meant for static analysis and ones that illustrate dynamic representation, while Jones's Graphic Forms deliberately specify what each of their graphs is used to represent. Fig. 3 shows the distribution of our sample according to families. According to our sample, the graph family is the largest, with 49% of the diagrams. Together with trees, they form 60% of the samples. It is interesting to note that 37% of the graphs' artifacts were flow charts (which form 13% of the whole sample). Next we examine if there is a correlation between the task at hand and the type of conceptual model selected to undertake it. Table 3 presents the data frequencies of context topics for each family. Percentages were computed longitudinally for each family category, and results of 0% were removed for the sake of legibility. Indeed, it is apparent that some families are more typically used for certain tasks than others. Comparing the frequencies of context topics across the families reveals that the IT architecture and the organizational structure topics are quite dominant and appear in almost every family. In addition, some topics are very dominant in a specific family although they also appear in others — for example, 75% of the diagrams in the tree family relate to the organizational structure context topic. In the same way, 75% of the diagrams in the table family relate to the service centers context topic, and corporate culture/social relationships form 45% of the Cartesian coordinates family. This analysis leads us to the 1

Microsoft SmartArt graphics http://office.microsoft.com/en-us/powerpoint/HA100395371033.aspx.

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

1307

Fig. 2. Mind map hierarchy.

hypothesis that there is a correlation between the family of a diagram and its context. The general relationship between family and context resulted in: Vc = 0.512. This result indicates that such a correlation exists, thus supporting our hypothesis. Next we used the Lambda coefficient to obtain a measure of the dependency between context topic and the underlying family of the diagram. The result for family dependency on context is λFamily|Context = 0.343. This mild correlation can be validated by looking at Table 3. Consider, for example, the topics of financial analysis, organize/generate ideas, information entities interaction, service centers, and business context. Each of these topics has only one suitable family. This is less prominent in the opposite direction, i.e., the degree to which a family indicates the appropriate context. For example, the graph family has several appropriate context topics. Therefore, a smaller coefficient was obtained, and λContext|Family = 0.256. These findings imply that some families are more typically used for certain tasks than others; hence practitioners and CASE tools may suggest a layout for a conceptual model based on the required context. Table 4 presents the data frequencies of context topics according to drawing/conceptual model characteristics. Percentages were computed for each topic across characteristics. Our hypothesis is that certain context topics increase the likelihood of a diagram being a conceptual model and other contexts increase the likelihood of a diagram being merely a drawing. Such a correlation may help

Table 2 Categorization of conceptual models. Our families

SmartArt

Jones's graphic forms

Graph Table Tree Coordinate systems Layer diagrams Circle maps

Process, relationship Matrix Hierarchy Grid matrix Pyramid and list Cycle

Series of events chain, problem/solution outline Compare/contrast matrix Spider diagrams, network tree, fishbone map Continuum/scale Human interaction outline Cycle

1308

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

Fig. 3. Semi-structured models' distribution according to families.

in providing the right kind of diagram for specific communication needs. The data demonstrate a pronounced relationship between the context of a diagram and its characteristic resulting in Vc = 0.625. Further examination of the dependency between the two variables yields λCharacteristics|Content = 0.493. It is worth noting that the opposite question, i.e., whether we could predict context from characteristics yields λContext|Charactiristics = 0.0533, which prompts that diagram characteristics are dependent on context. In other words, for a specific task, practitioners may prefer a conceptual model rather than merely a drawing. These results may help direct practitioners deciding whether to use a drawing or a conceptual model for a given task. In addition, it may guide tool developers in their quest for the right editors for the business analyst community by answering questions like: What tasks will probably be done when using syntax aware editors [8,9]. 4.3. What level of complexity do conceptual models demonstrate? Analysts often strike a balance between simplicity and complexity when communicating information system requirements. Too much complexity may overwhelm the audience with detail; too simple a description may hide important issues. The choice between simplicity and complexity is especially important for communication in the early phases of systems analysis [13]. Much of the academic research into conceptual models has attempted to anchor the conceptual model grammar's constructs and rules to theories of representation or communication [25]. However, the authors/inventors of enterprise conceptual models do not aim to have their models be ontology complete or ontology clear [26]. Practitioners simply use models of the business domain they are concerned with to understand and communicate aspects of a complex domain in a simple manner. Consequently, conceptual models developed from practice in the field have distinct complexity that affects the extent of their expressiveness. In the following section, we examine the structure of enterprise conceptual models by means of their number of grammars. A conceptual model grammar is a set of constructs and rules that show how to combine the constructs to model real-world domains [25]. We project implications from the task at hand to the complexity of the required conceptual model. 4.3.1. Single vs. multi-grammar Wand and Weber [25] claim that most grammars do not provide a sufficient set of constructs to model all phenomena in a domain. Even if a grammar can model all phenomena equally well, the cognitive demand placed on users is too high. Table 3 Frequencies of context topics for each family.

Organizational structure Service centers Information entities interaction Business operations architecture Solution offering/application portfolio Corporate culture Competition landscape IT architecture Value chain management Organize/generate ideas/concepts Business context Financial analysis Documentation Requirements analysis

Graph (%)

Tree (%)

Flow chart (%)

11

75

8 8

5 3 5 5 8 26 5 11 18 3

Circle (%)

Layer (%)

Table (%)

21 7

25 25

8 75

7

13 20

8

40 29 40 21 14

8 13 25

8

Cartesian (%) 9 9

9 45 18 9

Unknown (%) 75

13 13

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

1309

Table 4 Frequencies of context topics vs. diagram characteristics.

Organizational structure Service centers Information entities interaction Business operations arch Solution offering/application portfolio Knowledge management Corporate culture/social relationships Competition landscape/competitive performance/competitive advantage/players in business environment IT architecture Value chain management/value creation/value capturing Organize/generate ideas/concepts Business context Financial analysis/cost vs. revenue Documentation Requirements analysis Misc. — business models Plans, e.g., steps over time Total

CM

Drawings

Total

26 (84%) 13 (81%) 2 (100%) 4 (57%) 4 (27%) 0 9 (90%) 6 (100%) 18 (78%) 7 (78%) 4 (67%) 9 (41%) 1 (11%) 3 (100%) 2 (33%) 0 0 108

5 (16%) 3 (19%) 0 3 (43%) 11 (73%) 2 (100%) 1 (10%) 0 5 (22%) 2 (22%) 2 (33%) 13 (59%) 8 (89%) 0 4 (67%) 13 (100%) 1 (100%) 73

31 16 2 7 15 2 10 6 23 9 6 22 9 3 6 13 1 181

Table 5 Multi-grammar conceptual models. # Grammars per conceptual model # Conceptual models

1 25

2 10

3 3

4 1

5 1

8 1

10 1

11 1

Consequently, multiple grammars arise from the need to model the domain completely. Table 5 includes our analysis of the number of grammars per conceptual model used in enterprise conceptual models.2 Our sample shows that 42% of the conceptual models were multi-grammar conceptual models artifacts. Moreover, 73% of the conceptual model diagrams were part of a multigrammar conceptual models artifact. According to our sample, the average number of grammars per conceptual model is 2.14 with a standard deviation of 2.3. Table 5 shows a positive skewed distribution of observations; the number of grammars is not spread symmetrically around an average value. As a result, the median, which is 1, is different from the average. We relate to this result as a testimony to the plurality of the artifacts that make up our sample. Our corollary from this finding is as follows: Practitioners prefer to create conceptual models that are not complex, and when there is a need for multiple grammars this need is usually satisfied by two grammars per artifact. The next discussion deals with the cases when multiple grammars are involved. Our analysis shows that when enterprise conceptual models use multiple grammars, they do it for the following reasons: A. Levels of granularity — one or more diagrams represent the high level or panoramic view of detailing, while the successors represent zooming-in or a decomposition of segments from previous diagrams. The relationships between elements of different diagrams should be maintained. B. Trace — diagrams are sequenced according to a trace that comprised graphical cues for each step. Each step is associated with one or more diagrams. Sometimes the trace itself can be seen as a reduced conceptual model. Fig 4 illustrates a multi-grammar conceptual model where the small diagram on the top left designates a trace, and the main diagram designates a zooming-in of the first element in the trace. In this method the author takes a top down approach. He goes from a static view of the competencies always present in the business, to a focus on business functions and services these functions require from technology. Each zoomed-in domain is also related to one of three view points, which are designated with the dark circles. This example was taken from an artifact that decomposes 21 domains; such a level of expressiveness requires the use of multigrammar conceptual model. C. Combination of static and dynamic views — diagrams can be seen as viewpoints of the model, where the conceptual model starts with a static structure and the following structures offer behavioral aspects. D. Integrating several approaches — a method can comprise diagrams from different grammars to evolve a multi-dimension point of view. Fig 5 shows an example of a multi-grammar method that is motivated from the desire to express complicated ideas. The method suggests using a Component Business Map [7,12] integrated with a social network graph for the first phase of the business analysis, an annotated Component Business Map for the second phase, and a hierarchy of issues, hypotheses and recommendations for the last phase. The first two phases aim at information collating/space pattern which precede conclusion/ solution development that appears in the last phase. 2 From here onwards we exclude the models that were obtained within the eclectic deck, since the analysis hereafter required peripheral information, such as the information taken from engagements in which the models were used.

1310

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

Fig. 4. A multi-grammar with a trace and zooming-in.

The first three patterns require significant emphasis on interconnection between grammars. That was usually accomplished through guidelines provided along with the set of diagrams as a cookbook or multistep methodology. We refer to this as the “phenomena identification for multi-grammar” and discuss it further in Section 4.4. Next we deal with the question of whether certain tasks require multiple grammars while others can be satisfied with a single grammar conceptual model. Table 6 presents the data frequencies of context topics found in our sample according to single/multiple grammar characteristics. Percentages were computed longitudinally for each characteristic. The table indicates that for most of the context topics there is a tendency towards one of the grammar characteristics. Still there are some topics in which it is not clear cut. For example, 34% of the diagrams that are part of multiple grammar artifacts express organizational structure, while only 12% of the single grammar ones belong to this context topic. This finding suggests that organizational structure is better suited to describe one aspect of the solution model, and needs to be supplemented with additional conceptual models. Conversely, the competition landscape is more dominant in the single grammar category. These kinds of models usually appear as a standalone analysis that is self-contained and therefore does not require additional models. Cramer's V coefficient validates those corollaries with Vc = 0.543. We then calculated the Lambda coefficient and further concluded that according to Context, one can predict a recommendation to use multiple or single grammar complex. The result is λGramma|Context = 0.32 (while λContext|Grammar = 0.015). 4.4. What types of methods/guidance do practitioners use to support their conceptual models? Several scholars have addressed the topic of conceptual modeling methods. According to Wyssusek et al. [28], modeling methods are tools that help accomplish a task — the creation and representation of conceptual models. Thus, modeling methods are technologies, i.e., a means to an end. Accordingly, Wand et al. [25] describe conceptual modeling methods as aids to the creation of faithful representations using conceptual models that conform to an associated grammar that defines the syntax of the conceptual model. Lastly, Davies et al. [10] show that inexperienced practitioners make strong use of techniques and methods. As experience is gained, however, usage decreases significantly. We next present our findings and conclusions in connection with the existence of method for grammar (i.e. method for describing how to use the constructs defined in the grammar) in our sample. Often grammars are well formalized but their creators provide neither a detailed nor unambiguous way of using them [25]. We conclude the discussion on method existence with an analysis on the use of method for phenomena, i.e., the kind of guidelines that enable stakeholders to identify the phenomena to be modeled. Method for grammar is defined as a procedure for describing how to use the constructs defined in the grammar. Our sample shows that methods for grammar are either full or partial. When a diagram was accompanied with a comprehensive explanation of its building blocks and constructs, we clustered it under the “full method” classification. Fig. 6 describes departments in the organization and their interactions, and was built according to a real artifact. In addition to the diagrams themselves, the practitioner provided a full method for grammar in the form of companion slides to the diagram. Fig. 7 illustrates one of these

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

1311

Fig. 5. A multi-grammar that integrates several approaches.

slides, which describes the basic notation used to create the diagram. Another publicly available example for a “full method” is the comprehensive description of the constructs done in the Process Modeling Notation (BPMN) standard specification [27]. When only a partial explanation was provided — e.g., for only some of the constructs — we classified it as a “partial method”. An example for a “partial method” is when the accompanied description includes a legend that associates a name for each symbol. For instance, in Fig. 8 the practitioner used a legend to convey the parts of the notation they found most important or those that were not self-descriptive. The figure describes a Component Business Map [7,12], with color annotations that designate different enumeration values for each component.

1312

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

Table 6 Frequencies of context topics vs. grammar characteristics. Context topic

Single (%)

Multiple (%)

Organizational structure Service centers Information entities interaction Business operations architecture Solution offering/application portfolio Corporate culture/social relationships Competition landscape/competitive performance/competitive advantage/players in business environment IT architecture Value chain management Business context Documentation Requirements analysis

12 12 0 4 12 0 16 16 4 8 8 8

34 15 3 3 1 12 1 18 6 4 1 0

Table 7 presents the relationships between method levels and the source of each artifact within the conceptual models group in our sample. Artifact sources were designated as either dedicated or engagement artifacts. A dedicated artifact is created for the purpose of documenting, educating, and describing the conceptual models it holds. An engagement artifact is a work product that resulted from a client engagement. The table shows that a significant proportion (80%) of the conceptual models in our sample were obtained with no methods associated with their grammars and that only a marginal proportion (5%) had full methods. More than half (52%) of the artifacts in our corpus were work products that resulted from engagements; within these, no “full method” description was found. One might have expected the conceptual models identified as “dedicated” artifacts to be accompanied by explanations of the grammars; however, even within this group (48% of the conceptual models), only 11% were obtained with full methods. In summary, it appears that our sample adheres to the claims noted above regarding the scarcity of methods explaining the conceptual models' grammars. Our practical corollary for tool vendors is that they should provide a means for model authors to generate methods for using the grammars that define the syntax of new conceptual models. Such means should help authors describe the conceptual model grammar ranging from legends to full documentation as seen in Figs. 7 and 8. Next we look into the extent of phenomena identification provided by the methods in our sample. For each of the conceptual models, we examined the phenomena method for single/multiple grammar [25] that designates whether the conceptual model method provided guidance on what real-world phenomena the conceptual model is intended to model and how to map those

Fig. 6. Departments interaction diagram.

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

1313

Fig. 7. Portion of a full method for grammar.

phenomena to the model constructs. Fig. 9 illustrates part of the method for phenomena that the practitioner provided to accompany the Departments Interaction Diagram example (Fig. 6). The distinction between single and multiple grammars was important. We noticed that some practitioners provided deliberate guidance regarding the stages in the method and the place of each conceptual model in the complex; these methods were different from the guidance provided for the mapping of a single conceptual model to the right business circumstances. Table 8 indicates that a high proportion (75%) of the conceptual models was accompanied by a method for determining the right phenomena to be modeled. Table 9 clearly indicates that most of the multi-grammar conceptual models were obtained with such phenomena methods. We assert this as a fundamental result of our survey, and that the complexity of multi-grammar conceptual models brought about the necessity to provide guidance for the right phenomena identification when applying them. We also think this result, combined with the scarcity of methods explaining grammars, might indicate that practitioners rely on methods for phenomena to compensate for the lack of detailed grammar construct specification and mapping. Another explanation may be that the practitioners' work is more focused on the business problem at hand than on the methods' constructs and correct grammar. 4.5. How can business stakeholders distinguish drawings from conceptual models? Being able to decide what conceptual model each artifact contains is vital for the organization's reuse of intellectual capital captured in conceptual models. Capturing intellectual capital in a reusable form is the key to enabling knowledge transfer within

Fig. 8. An example for partial method for grammar.

1314

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

Table 7 Source of artifact vs. degree of method for grammar. Total

Dedicated Engagement Totals

No method

Partial method

Full method

#

%

#

%

#

%

#

%

44 48 92

48 52 100

32 42 74

35 45 80

7 6 13

8 7 15

5 0 5

5 0 5

Fig. 9. Example of method for phenomena.

an organization. The organization seeks to organize, create, capture, or distribute knowledge and ensure its availability for future users [21]. Knowledge transfer is considered to be more than just a communication problem. If it were merely that, then a memorandum, e-mail, or meeting would accomplish the knowledge transfer.3 The complexity of knowledge transfer stems from the following reasons: A. Knowledge resides in organizational members, tools, tasks, and their sub networks [3]. B. Much knowledge in organizations is tacit or hard to articulate [19]. Hence, in facing an artifact created by a business stakeholder, it is important for the organization to understand whether the artifact contains conceptual models that are reusable or merely drawings. This is especially true in light of the template reuse across engagements, which was found so prominent in the aforementioned workshop (a three-day workshop mentioned in Section 3). Automating the cleansing of artifacts and extracting from them the conceptual models for further use can enable organizations to manage this knowledge transfer problem. For various business stakeholders, drawings serve to convey thoughts. These diagrams are created to communicate a “oneshot” thought and are not intended to be reproduced in similar contexts. They are missing two major parts relative to conceptual models: grammar and method [25]. As noted, we identified 73 of 186 diagrams as merely drawings — an illustrative explanation that replaces a textual one. We combined our understanding of the artifacts with occasional help from the authors to understand whether a diagram in an artifact is a drawing or a conceptual model (or part of it). As a result of this process, we devised a method to distinguish a conceptual model from a drawing. We identified four factors that can influence whether a diagram is defined as a conceptual model or not: A. Method existence — if the business stakeholder provides within the artifact a detailed and unambiguous description of the constructs of the diagram, and a way of using them in the business circumstances, then they suggest that the diagram is a conceptual model. B. Multiple interwoven diagrams — if the artifacts contain diagrams that relate to each other then it implies that the diagrams are part of a multi-grammar conceptual model. C. Standard manipulation — if the diagram is a manipulation of a standard, it implies that the diagram reflects a conceptual model created by a variation of the standard's conceptual model. D. Repetitiveness — diagrams can be repeated with slight modifications and different data/text in the same artifact. If a diagram is repeated, it implies that the author found this method of conveying a thought useful enough to be repeated in similar context. Ideally cleansing an artifact produced in a client engagement yields a template in which consultants can apply their accumulated experience to address similar issues for a series of clients. We assert that these factors can help experts accelerate their ability to identify potential for template reuse. Furthermore, tool vendors can automate the cleansing procedure by identifying the existence of most, if not all, of these factors. We chose to focus on diagrams in engagement artifacts since the need to cleanse engagement artifacts may be more prominent than the need to cleanse dedicated artifacts. Accordingly, Table 10 presents the frequencies of factors by characteristic in the

3

http://en.wikipedia.org/wiki/Knowledge_transfer.

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

1315

Table 8 Phenomena identification for single grammar. # Conceptual models

# Conceptual models with phenomena method for single grammar

%

92

69

75

artifacts that stem from engagements. The parentheses show the ratio between diagrams associated with the appropriate factor and the total diagrams in each characteristic category. The table shows that the two most prominent factors for predicting whether a diagram is a conceptual model are method existence (83%) and multiple interwoven diagrams (71%). The analysis showed that all the conceptual models containing multiple interleaved diagrams were also received with an accompanying method. This evidence led us to conclude that conceptual models that are multi-grammar are naturally more complex and hence less intuitive — and require method guidance. Accordingly, a high correlation was found: Vc = 0.698 which was evident in both directions: λMultiple|Method = 0.633 and λMethod|Multiple = 0.621. Our hypothesis is that the existence of a combination of the aforementioned factors in a diagram will increase the likelihood of it being a conceptual model rather than merely a drawing. Therefore we checked whether the data indicates a relationship between the characteristic of a diagram as a conceptual model/drawing and the number of factors it associated with. We examined the existence of the following factors: method existence, repetitiveness, and standard manipulation. Out of the two dependent factors “multiple interwoven diagrams” and “method existence”, we selected “method existence” due to its prominence. A slight relationship between “repetitiveness” and “method existence” was found by the Cramer coefficient (Vc = 0.239); nevertheless, this finding was neither verified by the Lambda coefficient (λMethod|repetitiveness = 0, λrepetitiveness|Method = 0) nor by running the Cramer coefficient over the whole sample (both dedicated and engagement artifacts), and therefore it was considered negligible. All other factors were found independent of one another. The combined factor values are {0,1,2,3} corresponding to the number of factors that exist in the subject diagram. Table 11 presents the frequencies of number of factors, according to characteristic. The parentheses show the percentage of diagrams, with each characteristic having the indicated number of factors. Inspection of the table clearly shows that the more factors a diagram has, the more likely it is to be a conceptual model. Accordingly, the Cramer correlation coefficient yields a pronounced relationship between the characteristic of a diagram and the existence of the aforementioned factors: Vc = 0.707. Furthermore, λCharacteristics|CombinedFactor = 0.621, so information about these three factors decreases the error in predicting the diagram's characteristic by 62.1%. 5. Conclusions and future work We investigated some major aspects of enterprise conceptual modeling through an empirical analysis over real-world work products. We reported the results relating to two aspects: the nature of enterprise conceptual models and the nature of the business stakeholders practice. We began by examining the context of the conceptual models in our sample, which yielded the result that organizational structure, IT architecture, and service centers are the three prominent topics accounting for more than 50% of artifacts. This led to the corollary that the prevailing task of the practitioners in our sample is the alignment of IT with business aspects. We classified the conceptual models in our sample into six families and threw light on the correlation between the family of a diagram and its context, with some families more typically used for certain tasks than others. The distinction between drawings and conceptual models is essential for knowledge transfer. Therefore, throughout the article we closely examine the similarities and differences between the two. Our analysis yields that drawings are used for different tasks than conceptual models. Consequently, a pronounced relationship was demonstrated between the context of a diagram and its characteristics. Moreover, by providing context one can anticipate which kind of conceptual model they might need — a single grammar, or a more complex (multi-grammar) one. We used the number of grammars as a measure of the complexity for the conceptual model, then analyzed the reasons for using multi-grammars, fortified with real examples. A large proportion of the conceptual models were accompanied by methods for phenomena. We assert that the complexity of multi-grammar conceptual models resulted in the need to provide guidance for the right phenomena identification when applying them. Our study corroborated the assertion about the scarcity of methods that explain conceptual models' grammars. Our practical corollary to tool vendors is that they should provide a means for conceptual model builders to generate methods for the conceptual model grammar. Finally, we introduced four factors that positively affect the likelihood of identifying a diagram as a conceptual model rather than merely a drawing. We assert that these factors can help experts accelerate their ability to identify potential for

Table 9 Phenomena identification for multi-grammar. # Multi-grammar conceptual models

# Conceptual models with phenomena method for multi-grammar

%

67

63

94

1316

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

Table 10 Number of diagrams per factor. Characteristic

Total

Manipulation

Method existence

Multiple interwoven diagrams

Repetitiveness

Drawings Conceptual models

29 48

0 (0%) 7 (15%)

8 (28%) 40 (83%)

13 (45%) 34 (71%)

1 (3%) 17 (35%)

Table 11 Characteristic vs. number of factors.

0 1 2 3 Total

Conceptual model

Drawing

Total

2 (9%) 29 (78%) 16 (94%) 1 (100%) 48

20 (91%) 8 (22%) 1 (6%) 0 (0%) 29

22 37 17 1 77

template reuse, and help tool vendors automate the cleansing procedure by identifying the existence of most, if not all, of these factors. As future work, we intend to extend our understanding about variables that are supplementary to the characteristics of the artifacts themselves, such as: – The target audience of these artifacts (clients, peers, managers, executives) and the circumstances for which they were created (briefings, communication with peers, etc.) – The correlation between the practitioner's role, geographical location, or industry, and the artifact's nature. We also plan to extend the empirical study to a wider audience in more industries and disciplines. Consequently, we envision a study into approaches and tools, in which we will develop and support methods and practices that reflect the reality presented here. The outcome of that study would be thorough research into the tooling aspects of the enterprise conceptual modeling arena. This research will aim at combining the benefits of drawing tools with the benefits of modeling tools, and is likely to help in understanding the needs of the marketplace in terms of desired features and main pain points. Acknowledgments Our thanks go to Dave Bartek, Jason Macleod, Dennis R Jones, Marcel Schlatter, and Trevor Davis for the insights from their world of practice and the examples that appear in this article. References [1] S.W. Ambler, Agilists Write Documentation!. Dr. Dobb's 2008 modeling and documentation survey. [2] A. Anaby-Tavor, D. Amid, A. Fisher, H. Ossher, R. Bellamy, M. Callery, M. Desmond, S. Krasikov, T. Roth, I. Simmonds, J. De Vries, An algorithm for identifying the abstract syntax of graph-based diagrams, IEEE Symposium on Visual Languages and Human-Centric Computing, Washington, DC, USA, 2009, pp. 193–196. [3] L. Argote, P. Ingram, Knowledge transfer a basis for competitive advantage in firms, Org. Beh. Hum. Dec. Pro. 82 (2000) 150–169. [4] W. Bandara, H.W. Tan, J. Recker, M. Indulska, M. Rosemann, Bibliography of process modeling: an emerging research field, Unpublished results, Queensland University of Technology, Australia, 2007. [5] S. Chang, M. Kesari, P. Seddon, A content-analytic study of the advantages and disadvantages of process modeling, in: J. Burn, C. Standing, P. Love (Eds.), 14th Australasian Conference on Information Systems, Perth, 2003. [6] P.P. Chen, The entity-relationship model: toward a unified view of data, ACM Trans. Data. Sys. 1 (1976) 1–36. [7] L. Cherbakov, G. Galambos, R. Harishankar, S. Kalyana, G. Rackham, Impact of service orientation at the business level, IBM Sys. J. 44 (2005) 653–668. [8] S. Chock, K. Marriot, Automatic generation of intelligent diagram editors, ACM Trans. Comput. Hum. Interact. 10 (2003) 244–276. [9] G. Costagliola, V. Deufemia, G. Polese, A framework for modeling and implementing visual notations with applications to software engineering, ACM Trans. Softw. Eng. Methodol. 13 (2004) 431–487. [10] I. Davies, P. Green, M. Rosemann, M. Indulska, S. Gallo, How do practitioners use conceptual modeling in practice? Data Know. Eng. 58 (2006) 358–380. [11] M. Desmond, R. Bellamy, H. Ossher, I. Simmonds, D. Amid, A. Anaby-Tavor, A. Bercovich, M. Callery, A. Fisher, S. Krasikov. Style mapping in a flexible modeling environment, FlexiTools 2010 International Confernece of Software Engineering 2010 Workshop on Flexible Modeling Tools. Cape Town, South Africa. [12] D. Flaxer, A. Nigam, Realizing business components, business operations and business services, International Conference on e-Commerce Technology, 2004, pp. 328–332, Beijing, China. [13] L.A. Goodman, W.H. Kruskal, Measures of association for cross classifications, J. Amer. Statist. Assoc. 49 (1954) 732–764. [14] N. Gorla, H.C. Pu, W. Rom, Evaluation of process tools in systems analysis, Info. Soft. Tech. 37 (1995) 119–126. [15] B.F. Jones, J. Pierce, B. Hunter, Teaching students to construct graphic representations, Edu. Leader. 46 (1988–9) 5–20. [16] H. Kilov, Using RM-ODP to bridge communication gaps between stakeholders, Workshop on ODP for Enterprise Computing, Monterey, California, 2004. [17] H. Kaindl, S. Brinkkemper, J.A. Bubenko, B. Farbey, S.J. Greenspan, C.L. Heitmeyer, J.C.S.P. Leite, M.N.R.J. Myopolous, J. Siddiqui, Requirements engineering and technology transfer: obstacles, incentives and improvement agenda, Req. Eng. 7 (2002) 113–123. [18] C.H. Kung, A. Solvberg, Activity modelling and behaviour modelling, in: T.W. Olle, H.G. Sol, A.A. Verrijn-Stuart (Eds.), Information Systems Design Methodologies: Improving the Practice. North-Holland Amsterdam, 1986, pp. 145–171. [19] I. Nonaka, H. Takeuchi, The knowledge creating company, Harv. Bus. Rev. 69 (1991) 95–104. [20] D.L. Moody, Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions, Data Know. Eng. 55 (2005) 243–276. [21] A. Persson, J. Stirna, Why enterprise modeling? An explorative study into current practice, International Conference on Advanced Information Systems Engineering, 2001, pp. 465–468.

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318

1317

[22] W. Sedera, G. Gable, M. Rosemann, R. Smyth, A success model for business process modeling: findings from a multiple case study, in: T.P. Liang, Z. Zheng (Eds.), 8th Pacific Asia Conference on Information Systems. Shanghai, 2004. [23] D.J. Sheskin, Handbook of parametric and nonparametric statistical procedures, second edChapman&Hall/CRC, Boca Raton, Florida, 2000. [24] K. Siau, Informational and computational equivalence in comparing information modelling methods, J. Of Data. Mng. 15 (2004) 73–86. [25] Y. Wand, R.A. Weber, Research commentary: information systems and conceptual modeling — a research agenda, Info. Sys. Res. 13 (2002) 363–376. [26] Y. Wand, R. Weber, On the ontological expressiveness of information systems analysis and design grammars, J. Info. Sys. 3 (1993) 217–237. [27] S.A. White, Business Process Modeling Notation (BPMN) Version 1.0. Business Process Management Initiative, BPMI.org, 2004. [28] B. Wyssusek, J.M. Zaha, Towards a pragmatic perspective on requirements for conceptual modeling methods, Exploring Modelling Methods for Systems Analysis and Design, held in conjunction with the 19th Conference on Advanced Information Systems Trondheim, Norway, 2007, pp. 17–26. Ateret Anaby Tavor is the manager of Business Transformation and Architecture Technologies Group in IBM Haifa Research Labs. Her current responsibilities focus on development of techniques and tools that streamline organizational change and business-to-IT transitions. Projects address levering the Business Analysts and Business Architect work and teamwork; Future of business modeling tools; Supportive environments for Business Transformation projects; and new technologies for cross enterprise collaborations. Her main publications are in the fields of Services Science, Conceptual Models, Visual Languages, Software Engineering and Databases. She received an MSC in Information Management Engineering (Cum Laude) from the Technion — Israel Institute of Technology.

David Amid is a technical leader in the Business Transformation and Architecture Technologies Group in IBM Haifa Research Labs. His main focus is the exploration of future tooling for enterprise conceptual models. In particular David explores the interplay between office tools and traditional modeling tools. His background varies from research in the requirements engineering field to developing distributed computing systems. David has a B.A. in Computer Science and an M.Ss. in Information Management Engineering from the Technion — Israel Institute of Technology.

Amit Fisher is managing the Business and Systems Solutions department at the IBM Haifa Research Labs. His main expertise are Business and Enterprise Architecture modeling, business models, business strategy and IT strategy, business process management, service oriented architecture, data mining and business intelligence, operation research and marketing. Mr. Fisher gained a lot of experience in participating and leading business strategy and transformation project, and was one of the main contributors to the IBM Business Architecture offering. Furthermore, Mr. Fisher is involved in shaping IBM's future business-level tools, and leading several project in this realm. Amit has a B.Sc. degree in Industrial Engineering and Management and a M.SC. degree in Information System Engineering from the Technion, Israel.

Avivit Bercovici got her Information Systems B.Sc. and M.Sc. from the Technion, Israel. While working for IBM research lab Avivit has led and participated in several Business Transformation and Optimization research projects , including Component Business Modeling, Enterprise Portfolio Management and developing tools for enterprise/business architects. Her research focused on: Developing methods and tools for model driven approaches; Developing methods and tools for creating and supporting models in their early lifecycle phases; Enterprise Architecture and Enterprise Portfolio Management; Smarter water management models and methods. She currently works for Toluna Inc. leading the reporting project.

Harold Ossher received the B.Sc. (Hons.) and M.Sc. degrees from Rhodes University, South Africa, and the PhD degree in Computer Science from Stanford University. He is an ACM Distinguished Scientist. He has been a researcher at the IBM Thomas J. Watson Research Center since 1986, where he was one of the originators of subject-oriented programming, multi-dimensional separation of concerns and Hyper/J. He worked on agile requirements engineering in the early days of IBM Rational's Jazz project. His current research focus is flexible modeling tools, in the context of the Business Insight Toolkit (BITKit).

1318

A. Anaby-Tavor et al. / Data & Knowledge Engineering 69 (2010) 1302–1318 Matt Callery is a Software Engineer at the IBM Thomas J. Watson Research Center in Hawthorne, NY. Over the span of his 21-year career at IBM, Matt has worked for IBM's Global Services, Internet, Software, and Research divisions. For the past 7 years, Matt has participated in projects for IBM's Software and Services divisions supporting IT consultants.

Michael Desmond is a Postdoctoral researcher at the IBM TJ Watson research center in Hawthorne NY. His background varies from video game design and implementation, to the invention of software exploration tools aimed at alleviating programmer disorientation. Michael is particularly interested in fluid user interface design and web technologies.

Sophia Krasikov is a Research Software Engineer at the IBM Thomas J. Watson Research Center in Hawthorne, NY. Her areas of interest are Web development and visualization software.

Ian Simmonds researches the application of the modeling technologies of software engineering for non-traditional purposes and concepts in the early lifecycle of application development, as well as more broadly in the reflective parts of organizations. Projects have addressed application envisioning, bridging the business/IT gap, business strategy (Sense-and-Respond), IT architecture (with Architects' Workbench), and Enterprise Architecture and Planning. Some day he may write a paper blending ideas from Pierre Bourdieu, Jane Jacobs and Hernando De Soto. He is also a leading researcher, lecturer and dealer in early American glass. He received an M.A. in Mathematics from the University of Cambridge.