Research
Understanding corporate data models
Graeme Shanks
*, Peta Darke
School of Information Management and Systems, Monash University, Melbourne, Australia
Received 25 November 1997; accepted 23 July 1998
Abstract
Corporate data models are widely used to support data management within organisations. However, both IS professionals and business users ®nd them dif®cult to understand. This paper describes a methodology for designing and representing corporate data models that uses explanation and visualisation mechanisms to improve understanding, and reports a case study of the use of the methodology in the development of a data warehouse. The methodology was shown to be effective in that a high quality corporate data model was designed and then understood and utilised by all the participants. The model was used as an active, hypertext interface to the ®rst prototype of the data warehouse. The case study ®ndings indicated that: scenarios are useful for eliciting information requirements and explaining abstract concepts in the model to business users; graphical icons and subject area partitions are effective means of visualising the model and lead to improved understanding of the model by business users; and design rationale is an effective means of explaining the evolution of concepts in the model for specialist data modellers.#1999 Elsevier Science B.V. All rights reserved
Keywords: Data management; Data administration; Data warehousing; Corporate data models; Information systems methodologies
1. Introduction
Data are often duplicated throughout organisations, resulting in potentially inconsistent data that may be stored in different formats and are dif®cult to con-solidate. The corporate data model has been proposed as a tool to support the management of data at the corporate level. It is an abstract representation of the information requirements of all or part of an organisa-tion and is independent of funcorganisa-tional boundaries within an organisation and of implementation technology [1].
Despite strong arguments supporting data manage-ment [2], the use of corporate data models has been problematic in practice [3, 4, 5, 6]. Empirical studies report that corporate data models are too complex [7], too conceptual, bulky and in¯exible [8], subject to complex political and organisational problems [9, 10], and considered irrelevant for strategic planning by senior management [11]. However, corporate data models are required when designing cross-functional IS that need to integrate information from a number of sources. In particular, the emergence of data ware-housing and of IS that support re-engineered business processes have again motivated interest in corporate data models [12].
*Corresponding author. Fax: +61-03-9903-2005; e-mail: graeme.shanks@sims.monash.edu.au
A major problem with corporate data models is that they are dif®cult to understand. Their abstract, generic concepts are unfamiliar to both business users and IS professionals, and remote from their local organisa-tional contexts [13]. This paper discusses a methodol-ogy for designing and representing corporate data models that makes explicit use of mechanisms for explaining and visualising them in order to facilitate stakeholder understanding. The methodology incor-porates argumentation-based design rationale and sce-narios as explanation mechanisms. Visualisation mechanisms include identi®cation of subject area clusters to structure the models and the use of gra-phical icons to represent the subject areas. The
meth-odology, ViewCon (Viewpoint Consolidator),
supports the evolutionary development of a corporate data model by providing for the design and consolida-tion of separate business user views of data require-ments. A case study of the use of ViewCon in the development of a data warehouse has demonstrated the value of the methodology in practice.
2. Understanding corporate data models
A corporate data model (or data architecture) is a high-level model of information requirements within an organisation. The model is usually represented using a conceptual data modelling notation, such as the entity relationship model [14], and should not re¯ect particular personnel, organisational structures, or technology. Corporate data models are frequently justi®ed on the basis that they will help improve the quality of poor or inconsistent data, assist with the integration of information, and help gain control of data redundancy [15]. They span functional areas within an organisation, providing a common view of data.
The purposes for corporate data models identi®ed in the literature include support for the implementation of a set of integrated systems, a data architecture to provide a stable base for planning and prioritising the development of new application systems, a basis for education and communication about information in an organisation, and a framework for developing an inventory of data in legacy systems [4, 16]. The sourcing of data for a data warehouse depends on the availability of a data inventory [17].
Empirical studies indicate that many organisations have encountered signi®cant problems in building and using a corporate data model [9, 13]. A number of these studies have identi®ed the dif®culties experi-enced by both business users and IS professionals in understanding corporate data models as a barrier to their effective use. A corporate data model is a con-ceptual data model, that is, an abstract representation of information requirements. However, corporate data models often have generic and abstract concepts that are not easily related to the actual terminology used within particular business areas. This limits the use-fulness of the model, as communication about the model is dif®cult and a shared understanding of the model is not developed. An important dimension identi®ed in frameworks for evaluating quality in conceptual data models is stakeholder understanding
[18, 19, 20]. Explanation and visualisation are two
means for improving stakeholder understanding of conceptual data models.
Important knowledge about design decisions, assumptions, and argumentation, and about the details of how particular stakeholders intend to use the data represented in the conceptual data model is gained during the data modelling process. Although this may remain in the memories of those who participated in the modelling process, it is usually not recorded. This knowledge can be captured and used to assist with explanation of the model. Argumentation-based design rationale and scenario-based analysis are mechanisms for capturing and retaining knowledge.
Empirical studies indicate that the entity relation-ship modelling notation is dif®cult to teach [21] and that practitioners ®nd some abstractions dif®cult to understand [22]. Visualisation of conceptual data models using appropriate representations can facilitate stakeholder understanding. The structuring of entity relationship models into subject areas together with the use of graphical icons as subject area representa-tions has been proposed as a means of visualising the models in order to facilitate both data modellers' and business users' understanding of the model concepts [23, 24].
concepts included in the model [26]. The mechanisms of argumentation-based design rationale, scenario-based analysis, and structured representation of the corporate data model using graphical icons can be used to enhance the capture and integration of stake-holder viewpoints.
2.1. Capturing design discussions using argumentation-based design rationale
A number of partial and alternative data models are generated, discussed, and evaluated during conceptual data modelling which can, therefore, be considered a creative design process. The models and associated discussions and design decisions constitute the design reasoning or argumentation. Design rationales are typically represented as explicitly structured
discus-sions about the design artefact and are ``. . .
represen-tations of the reasoning behind the design of an artefact'' [27]. They support the building of cumula-tive design knowledge and aid reasoning, communi-cation, and critical re¯ection about the process and the design, and they are an important resource for reuse and redesign processes [28, 29].
Structure-oriented and process-oriented techniques constitute the two main categories of design rationale [30]. Structure-oriented techniques are intended to be used after the design process. They focus on the logical structure of the space of all design alternatives. Process-oriented design rationale techniques focus on maintaining an historical record of design decisions and are intended to be used during the design process. The Issue-Based Information System (IBIS) and its descendants are examples of process-oriented design rationale techniques [31]. There are two types of process-oriented design rationale approaches: those that represent the design discussion only, and those in which the design rationale is integrated with the artefact itself as it evolves. The latter type of approaches have been used to capture and model IS requirements [32, 33]. Design rationale is used to explain the evolution of the artefact. Empirical studies suggest that integration of the design discussion with the artefact is preferable as the design is focused to the task at hand and large and unusable documentation is avoided. Simple design rationale notations are pre-ferred, as the more expressive notations with sophis-ticated computer support are not as easy to use.
2.2. Capturing and explaining information requirements using scenario-based analysis
A scenario is ``. . . a concrete description of an
activity that the user engages in when performing a speci®c task'' [34]. Scenarios are informal representa-tions of speci®c instances of work-driven tasks. These may be in various forms (e.g. text descriptions, car-toons, videos) at any level of detail. They are useful for relating abstract, generic concepts to the everyday activities with which the user is familiar.
Scenarios may take either theenvisionerrole or the
evaluatorrole [35]. In their envisioner role, scenarios can be used during requirements acquisition to drive the design process. They can be informal, vague, open and inconsistent in order to support development of an understanding of the business area and the relevant users' requirements. In their evaluator role, scenarios can be used to assist the evaluation of requirements models and to help explain their meaning to all potential stakeholders. These scenarios need to be clearly and carefully grounded in the detail of the requirements models. They are an important compo-nent of the documentation of the models and of the training programs that explain them.
Both, requirements capture and the explanation of conceptual models of requirements, have been shown to bene®t from the use of scenarios. Potts et al. used scenarios to help capture requirements for a meeting scheduling system. In their study, over half the ques-tions raised in requirements meetings related to sce-narios. They found that some questions concerning requirements could not be easily answered without the use of scenario analysis. Scenarios facilitated the elaboration of requirements, and analysis of scenarios led to about half of the improvements to the set of requirements.
2.3. Use of visualisation to assist understanding of conceptual data models
by shared entity-types, and may overlap. Subject areas allow for structuring of corporate data models to improve their accessibility. A number of high-level subject areas may be used to represent a corporate data model, each of which may be expanded into a more detailed model.
McGuniness suggested that graphical icons should be used in modelling notations within CASE tools for ease of use. Moody used graphical icons to represent subject areas in order to enhance understanding of corporate data models and to improve communication about them, and provide some anecdotal evidence of their usefulness. However, there has been no systema-tic, empirical research into the effectiveness of the use of graphical icons to represent subject areas in practice.
3. Research approach
There were two phases in the research project described in this study. In the ®rst phase, the ViewCon methodology was developed by synthesising concepts from viewpoint integration approaches, argumenta-tion-based design rationale, scenario-based analysis, and the use of subject areas and graphical icons to structure the representation of data models. ViewCon extends the existing approaches to data model design by capturing design decisions during the design pro-cess and documenting them using a design rationale notation, and by using scenarios to capture require-ments and explain the data model. It was developed using Avison and Fitzgerald's [37] framework for comparing IS methodologies.
The use of the ViewCon methodology in practice was examined in the second phase using a single case study. A single case design should be adopted when the case is considered critical, extreme or unique, or revelatory [38]. The case described in this study is both unique and revelatory, as the ViewCon metho-dology is new and was being applied in an organisa-tional setting for the ®rst time. A data warehouse was required by a large department in an Australian uni-versity, and a corporate data model was considered to be an essential input to the development process. The case participants included ®ve key senior staff mem-bers from within the department and two experienced data modelling practitioners who were motivated by
the opportunity to learn about and use the ViewCon methodology to design the corporate data model. Each of the ®ve senior staff members had their own per-spective of their particular information requirements. The team involved in the task of building the corporate data model using the ViewCon methodology formed the unit of analysis in the case study. An initial brie®ng and training session in the use of the meth-odology was followed by several sessions in which the case participants carried out the activities speci®ed in the methodology. These sessions included interviews with the senior staff, the design of data models for each of their perspectives, the integration of the various data models into a corporate data model, and a quality review with all participants present. The case study procedure concluded with a debrie®ng session in which the two data modelling practitioners provided further information about their use of the ViewCon methodology. All sessions were conducted in a meeting room equipped with videotaping facil-ities. Case study data collection was by observation (video-tapes), interviews, and examination of existing documents. Qualitative techniques were used to ana-lyse the case study data.
4. The ViewCon methodology
ViewCon focuses on the acquisition and modelling of data requirements for a corporate data model. It consists of two main activities with two tasks within each activity. The ®rst activity, requirements descrip-tion, involves acquiring user data requirements and designing a data model for each user group. During the second activity, model consolidation, these models are consolidated to form the corporate data model. View-Con is an evolutionary methodology, with ongoing re®nement and extension of both the user data require-ments and the corporate data model.
used in the design process, and for using this informa-tion to help explain the meaning of the concepts in the model. The structure of the ViewCon methodology is shown in Fig. 1.
4.1. Requirements acquisition
Specialist data modellers ®rst elicit and accumulate information about the data requirements of the busi-ness users from interviews with stakeholders, existing information systems, knowledge of the application domain, and other documentation. During require-ments acquisition an understanding of the domain of the IS is developed. In order to facilitate commu-nication, requirements should be represented in the language and terminology of the business users. Requirements are represented using informal repre-sentations, including text narrative, rich pictures, and envisioner scenarios. Informal representations are readily understood by business users and allow for requirements freedoms, as described by Feather: incompleteness, complexities, ambiguities, non-uni-formity of abstraction, and heterogeneity of expres-sion [39].
A number of separate requirements acquisition sessions may be held for each business user. Discus-sions about each data requirement are analysed and documented using the design rationale notation of Potts et al. after each session, and structured into sets of questions, answers, and reasons. Each design ratio-nale fragment is related to a particular requirement. Building the design rationale after each requirements acquisition session avoids the problem of distracting stakeholders from the task at hand during the session.
The requirements acquisition activity produces a requirements document containing a set of informal requirements (text narrative, rich pictures, and envi-sioner scenarios) together with related design rationale fragments for each business user. The quality of the requirements document is largely determined by the skills of the data modellers in eliciting and represent-ing the data requirements of the business users. Usrepresent-ing informal representations encourages active user parti-cipation in the requirements acquisition process.
4.2. Requirements modelling
After the data requirements of business users are elicited, they are modelled by specialist data model-lers in a semi-formal or formal notation in order to facilitate analysis and comparison. Although semi-formal notations have well-de®ned constructs which support model analysis, they allow some requirements freedoms, for example ambiguity, incompleteness and inconsistency [26]. They are more widely used in practice than formal representations (e.g. Z) [26]. Entity relationship notation is the semi-formal lan-guage used in ViewCon.
Specialist data modellers analyse the informal requirements, rich pictures, envisioner scenarios and design rationale fragments during the requirements modelling task. An entity relationship model is designed for each separate business user viewpoint. When designing data models, specialist data model-lers reuse generic data model patterns and application area data models learned from previous experience, in addition to using information from the requirements document [40]. The design process involves iteratively exploring alternative representations and selecting the most appropriate. After each requirements modelling session, discussions about components of the entity relationship model are documented using questions, answers and reasons. Each design rationale fragment relates to a particular entity relationship model com-ponent. The requirements modelling activity produces an entity relationship model for each business user together with related design rationale fragments.
4.3. Model integration
corporate data model. In the database literature, entity relationship models are typically integrated using a three-step process: con¯ict analysis, con¯ict resolu-tion, and view merging [25]. A weakness of this approach is that it focuses on the analysis and merging of the representations rather than on understanding the underlying perceptions of users and the meaning of the concepts in the models. It also ignores the opportunity to re-conceptualise important concepts in the data model using concepts from generic data model pat-terns and abstraction mechanisms.
In ViewCon, model integration is seen as a creative design process involving the exploration of alternative representations for concepts in the various business user requirements models. This process is supported by use of the design rationale fragments documented in the requirements modelling task. Design discus-sions between the specialist data modellers during model integration contain useful information about the process of model development and explanations of concepts in the resulting data model. After each model integration session, discussions about the design of the corporate data model are documented using questions, answers, and reasons. Each design rationale fragment relates to a particular component of the corporate data model. The model integration activity produces a corporate data model represented using the entity relationship notation together with related design rationale.
4.4. Model validation
Model validation consists of two processes: expla-nation of the model to business users and quality checking. Two mechanisms are used to explain the corporate data model to users. The ®rst involves structuring the corporate data model into subject areas and representing each subject area using a graphical icon. This enables business users to understand the concepts in the model. Each subject area is related to an entity relationship model that is a partition of the complete corporate data model. The second involves the creation of evaluator scenarios for each user. These are based on the envisioner scenarios. Evaluator sce-narios are more detailed and speci®c than envisioner scenarios and consist of a sequence of steps that refer directly to the subject areas in the corporate data model. In this way, abstract concepts in the corporate
data model are related to familiar work-driven tasks of the business user. The corporate data model is explained to business users in a workshop.
Quality checking involves reviewing the corporate data model using a set of conceptual data modelling quality factors including correctness, completeness, understandability, ¯exibility and simplicity. Quality is de®ned as ®tness for purpose and it is important to have the active participation of both business users and data modelling specialists in quality checking. Feed-back from the validation workshop is used to re®ne and improve the model.
5. Using the ViewCon methodology in practice: A case study
A case study was conducted between April 1996 and October 1997 in order to examine the use of ViewCon in practice. In the case study, ViewCon was used to develop a corporate data model for a large department in an Australian university. The corporate data model was subsequently used in the development of a data warehouse. The four ViewCon tasks are described and analysed and use of the corporate data model in providing a hypertext, model-based interface to the data warehouse is dis-cussed.
5.1. Requirements acquisition
The two specialist data modellers used interviews to elicit data requirements for each of the ®ve business users. The interviews were conducted separately; requirements were documented using informal narra-tive description and envisioner scenarios. Each inter-view lasted approximately one hour and resulted in an average of 11 informal requirements and seven envi-sioner scenarios. There was little variation in the number of requirements between the business users. Analysis of the design discussions in the interviews by one of the authors identi®ed an average of 30 design rationale fragments for each business user. Approxi-mately four hours were required to identify and docu-ment the design rationale fragdocu-ments for each interview.
the business users structure their thoughts and sup-ported communication between the data modellers and business users. Business users found envisioner scenarios particularly useful when checking require-ments for completeness after the interviews, and resulted in the identi®cation of additional require-ments.
The design rationale fragments identi®ed and docu-mented were of little value as they were mostly concerned with requests for additional requirements or scenarios, and did not help to explain and clarify the requirements statements. They were not used in later tasks.
5.2. Requirements modelling
The informal requirements and envisioner scenarios were used by the two specialist data modellers to design an entity relationship model for each of the business users. Requirements modelling took place 6 weeks after requirements acquisition was completed, and consisted of two sessions. The ®rst was of two hours duration and the second of three hours. Each entity relationship model took an average of one hour to design and contained on an average 16 entity-types and 15 relationship-types. The data mod-ellers were readily able to understand the informal requirements and envisioner scenarios, which pro-vided them with suf®cient information to design the data models.
Analysis of the design discussions in the modelling sessions by one of the authors identi®ed the rationale fragments for each data model. Approximately four hours were required to identify and document the design rationale fragments for each hour of data modelling. The design rationale fragments identi®ed and documented were mainly concerned with the justi®cation for using particular modelling abstrac-tions and for choosing from alternative representaabstrac-tions for the same underlying concept. The design process followed was opportunistic [40], rather than systema-tic. There was no evidence that the use of design rationale constrained the design discussions, as some previous empirical studies have shown. A simple example of a design rationale fragment explains how a new, generic entity-type, activity, is created. The fragment is structured as questions (Q), answers (A), and reasons (R).
Q: How are administration tasks represented? A: Use a ADMINISTRATION ACTIVITY entity-type.
This should be a sub-type of a more generic type called ACTIVITY.
Other sub-types will be TEACHING ACTIVITY, RESEARCH ACTIVITY and COMMUNITY SER-VICE.
R: This allows all types of activities to share a common relationship with the other entity type STAFF.
5.3. Model integration
In order to integrate the data models for each of the ®ve business users, copies of each of the data models and associated informal requirements, envisioner sce-narios, and design rationale were provided to the two specialist data modellers. Model integration took place 5 weeks after the requirements modelling task and consisted of one 3-hour session. The ®ve data models and their associated documentation were reviewed in the ®rst 30 minutes of the model integra-tion session. The design raintegra-tionale fragments were particularly useful in reviewing and understanding the design of each data model, and the contexts for data modelling design decisions.
Model integration was achieved by selecting the model that contained many of the core concepts required in the corporate data model, and the other data models were sequentially integrated into the selected model. This was a creative and opportunistic design activity that involved much discussion about alternative abstractions. Several new, generic concepts
were introduced: the most important wereProductand
Product Offering. These concepts were used to repre-sent any formal course or subject, short course, semi-nar or other kind of product that the department had de®ned and scheduled.
Analysis of the design discussions in the model integration session by one of the authors identi®ed the rationale fragments for the corporate data model. Approximately 4 hours were required to identify and document the design rationale fragments for each hour of model integration. A simple example
explain-ing how theProduct Offeringconcept is related to staff
Q: Are PRODUCT OFFERINGs related to staff and students?
A: Yes, ACTIVITY (TEACHING ACTIVITY) relates to PRODUCT OFFERING in several ways; for example, examiner, lecturer, tutor, course coor-dinator.
Students relate to PRODUCT OFFERING via the ENROLMENT entity-type.
5.4. Model validation
Two sessions were required for model validation. In the ®rst, which was of 2-hours duration, the two data modellers structured the model into subject areas represented by graphical icons, prepared several evaluator scenarios for explaining the model to business users, and reviewed the quality of the model. In the second session, which was of 2-hours duration, the model was explained to the business users, and the quality of the model was reviewed again. Model validation took place 4 weeks after model integration.
The model was structured using two heuristics: key concepts in the model must be represented as subject areas, and there should be about seven subject areas so that it is neither too complex nor too simple. Graphical icons were then selected to represent the subject areas. Evaluator scenarios were then prepared for each of the envisioner scenarios for each business user. The qual-ity review of the corporate data model involved an informal discussion about each of the ®ve quality factors. The model was deemed to be of high quality and no changes were made in it. The high-level consolidated data model is shown in Fig. 2 together with an example evaluator scenario, which refers to subject areas in the model.
When explaining the corporate data model, graphi-cal icons were readily understood by all the business users, and helped communication between the data modellers and the business users. Evaluator scenarios enabled the business users to relate subject areas in the corporate data model to familiar, everyday activities. The data modellers chose not to use the design ratio-nale during the presentation as they considered it inappropriate for communication with business users. However, they believed it would be very useful for other data modellers trying to understand and extend the data model at a later time. The model was
infor-mally reviewed and found to be complete and readily understood.
5.5. Developing the prototype data warehouse
The corporate data model provided the overall architecture for the subsequent design of the prototype data warehouse. Three high priority business area partitions were initially identi®ed as candidates for data warehouse development. These were student enrolments, staff activities and ®nance. Each consisted of several subject areas. For example, student enrol-ments consisted of the student, enrolment and product offering subject areas. Student enrolments was selected for implementation in the ®rst prototype data warehouse.
The development approach adopted for the proto-type was that of Kimball [17] in which a dimensional model is designed for each business area partition. A dimensional model of the student enrolments business area was readily developed from the corporate data model, and included an enrolment fact table and three-dimensional tables: student, product offering and time. The dimensional model, together with hypertext links to associated evaluator scenarios, provided an active interface to the data warehouse for business users. A set of pre-de®ned reports were also developed to provide standard information about enrolments to business users and an active link to an on-line analytical processing (OLAP) tool was provided to support browsing of the data warehouse. Explanations of the contents of the fact table and dimensions' tables were provided by hypertext links to evaluator scenarios.
An alternative interface to the data warehouse was developed for data modellers. This interface displayed an entity relationship model together with hypertext links to associated design rationale fragments. Details about the attributes in each entity and how they were sourced from central university systems and other data sources were provided by additional hypertext links.
data warehouse. An example screen for business users is shown in Fig. 3 below.
6. Case study findings and implications for practice
ViewCon was shown to be effective in supporting the design of a high quality corporate data model which was readily understood by and communicated to all participants. The case study clari®ed where and
warehouse. Discussion of more speci®c case study ®ndings follows.
6.1. Scenarios
Both envisioner and evaluator scenarios should be used during the corporate data modelling process for elicitation of requirements and to explain abstract concepts in the model to business users. Envisioner scenarios were particularly useful in helping partici-pants express their information requirements and for reviewing them and detecting omissions during requirements acquisition. They also provided data modellers with knowledge about how business users would use the information in the data models. This was very useful during the model integration activity. Evaluator scenarios were readily understood by the business users and facilitated communication between them and the data modellers during the model valida-tion activity.
6.2. Subject areas and graphical icons
The corporate data model should be structured using subject areas as a means of reducing the com-plexity of the model and providing support for
busi-ness users in gaining an overall understanding of the model. Subject areas also supported partitioning of the model for evolutionary development of the data ware-house. Graphical icons were an effective means of visualising the model and presented abstract concepts as real-world, concrete objects to which the business users could readily relate. They were effective in facilitating communication about and understanding of the model by the business users.
6.3. Design rationale
determine how they could be synthesised during the model integration task.
The simple, indented text notation adopted for the design rationale was easily understood and used. This con®rms the ®ndings of previous empirical studies. Integration of the design rationale with the artefact being designed (the data model) provided a means of partitioning the design rationale according to the components in the model and simpli®ed access to the design rationale fragments. Further studies are required to determine the effectiveness of the design rationale when other data modellers maintain and evolve the corporate data model.
6.4. Active hypertext interface
The explanation and visualisation mechanisms were used to provide a model-based, hypertext inter-face in the development of a prototype data ware-house. An important feature of the interface was the separate interface pro®les provided for business users and data modellers. Business users were provided with graphical icons, scenarios, and other linked textual information in their interface. Data modellers were provided with an entity relationship model, associated design rationale fragments, and other linked textual information in their interface. The effectiveness of the interface needs to be further examined.
6.5. Limitations of the study
There are two limitations of this case study. First, a university department is not typical of the organisa-tional environment in which corporate data modelling usually occurs, because the business users may have knowledge of data modelling and because commer-cial organisations are generally larger and more complex than the university department. Three of the business users in the study, however, were admin-istrative staff with no experience in conceptual data modelling. Second, it is constrained in that all the sessions were conducted in the same meeting room so that the sessions could be videotaped for detailed analysis. The behaviour of the participants may have been affected, because the sessions were not held in their usual work environment. Additional case studies of the use of ViewCon in building corpo-rate data models in different organisational settings
are required to con®rm and strengthen the results of this study.
7. Conclusions
This paper describes the ViewCon methodology for designing and representing corporate data models. Previous empirical studies have shown that corporate data models are dif®cult to build and use in practice, and that both information systems professionals and business users ®nd them dif®cult to understand. View-Con extends previous approaches to data model design in that it uses explanation and visualisation mechan-isms to help overcome these problems. A case study of the use of ViewCon in practice has demonstrated that the use of scenarios, subject areas, graphical icons, and design rationale is effective in improving the under-standing of corporate data models, and may be used to provide a hypertext, model-based interface to a prototype data warehouse.
References
[1] J.C. Brancheau, J.C. Wetherbe, Information architectures: Method and practice, Inf. Processing and Manage. 22(6), 1986, pp. 453±464.
[2] J.C. Brancheau, B.C. Janz, S.T. March, Key issues in information systems management: 1994, 1995 SIM Delphi results, MIS Quarterly 20(2), 1996, pp. 225±242.
[3] D.L. Goodhue, J.A. Quillard, J.F. Rockart, Managing the data resource: A contingency perspective, MIS Quarterly, pp. 373±392, 1988.
[4] D.L. Goodhue, L.J. Kirsch, J.A. Quillard, M.D. Wybo, Strategic data planning: Lessons from the ®eld, MIS Quarterly, pp. 11±34, 1992.
[5] S.T. Guynes, M.T. Vanecek, Critical success factors in data management, Inf. Manage. 30, 1996, pp. 201±209. [6] J.A. Hoffer, S.J. Michaele, J.J. Carrol, The Pitfalls of
Strategic Data and Systems Planning, in: Proc. 22nd Ann. Hawaii Int. Conf. Sys. Sci. Kona, Hawaii, January 1989. [7] M.J. Earl, Experiences in strategic information systems
planning, MIS Quarterly 17(1), 1993, pp. 1±20.
[8] Y. Kim, G.C. Everest, Building an IS architecture: Collective wisdom from the ®eld, Inf. Manage. 26, 1994, pp. 1±11. [9] P. Beynon-Davies, Information management in the British
national health service: The pragmatics of strategic data planning, Int. J. Inf. Manage. 14, 1994, pp. 84±94. [10] G.M. McGrath, Migrating information systems through the
[11] K.P. Periasamy, Development and usage of information architecture, Ph.D. dissertation, University of Oxford, 1994. [12] F. McFadden, Data warehouse for EIS: Some issues and impacts, in: Proc. 29th Annual Hawaii Int. Conf. System Sciences, 1996.
[13] G. Shanks, The challenges of strategic data planning in practice: An interpretive case study, J. Strategic Inf. Sys. 6(1), 1997, pp. 69±90.
[14] P. Chen, The entity relationship model: Towards a uni®ed view of data, ACM TODS 1(1), 1976, pp. 9±36.
[15] J. Martin, Strategic Data Planning Methodologies, Prentice-Hall, 1982.
[16] A.-W. Sheer, A. Hars, Extending data modelling to cover the whole enterprise, CACM 35(9), 1992, pp. 166±172. [17] R. Kimball, The Data Warehouse Toolkit, Wiley, New York,
1996.
[18] J. Krogstie, O.I. Lindland, G. Sindre, Towards a Deeper Understanding of Quality in Requirements Engineering, in: Proc. 7th Int. Conf. Advanced Information Systems En-gineering, Jyvaskyla, Finland, June 1995.
[19] D. Moody, G. Shanks, What makes a good data model? Evaluating the quality of entity relationship models, in: P. Loucopoulos (Eds.), Proc. 13th Int. Entity Relationship Conference, Manchester, England, 1994.
[20] G. Shanks, P. Darke, Quality in Conceptual Modelling: Linking Theory and Practice, in: Proc. Asia-Paci®c Con-ference on Information Systems, Brisbane, 1977.
[21] R.C. Goldstein, V.C. Storey, Some ®ndings on the intuitive-ness of entity-relationship constructs in: F.H. Lochovsky (Ed.), Entity-Relationship Approach to Database Design and Querying, Elsevier, Amsterdam, The Netherlands, 1990. [22] S. Hitchman, Practitioner perceptions on the use of some
concepts in the entity-relationship model, European J. Inf. Sys. 4, 1995, pp. 31±40.
[23] S. McGuiness, CASE support for collaborative modelling: Re-engineering conceptual modelling techniques to exploit the potential of CASE tools, Software Eng. J., pp. 183-189, 1994.
[24] D. Moody, A Graphical Representation of Entity Relation-ship Models in: B. Thalheim (Ed.), Proc. 15th Int. Entity Relationship Conference, Cottbus, Germany, 1996. [25] C. Batini, M. Lenzerini, S.B. Navathe, Comparison of
methodologies for database schema integration, ACM Computing Surveys 18(4), 1986, pp. 232±364.
[26] P. Darke, G. Shanks, Stakeholder viewpoints in requirements de®nition: A framework for understanding viewpoint development approaches, Requirements Eng. 1, 1996, pp. 88±105.
[27] S. Buckingham Shum, N. Hammond, Argumentation-based design rationale: What use at what cost, Int. J. Human-Computer Studies 40, 1994, pp. 603±652.
[28] G. Fischer, A. Lemke, A.C. McCall, A.I. Morch, Making argumentation serve design, Human-Computer Interaction 6, 1991, pp. 393±419.
[29] A. MacLean, R.M. Young, V.M.E. Bellotti, T.P. Moran, Questions, options and criteria: Elements of design space analysis, Human-Computer Interaction 6, 1991, pp. 210±250.
[30] A. Dix, J. Finlay, G. Abowd, R. Beale, R. Human-Computer Interaction, Prentice-Hall, 1993.
[31] J. Conklin, K.C. Burgess Yakemovic, A process-oriented approach to design rationale, Human-Computer Interaction, 6(3±4) (1991) 357±391.
[32] C. Potts, G. Bruns, G, Recording the Reasons for Design Decisions, Proc. 10th Int. Conf. Software Engineering, pp. 418-427, 1988.
[33] C. Potts, K. Takahashi, A.I. Anton, Inquiry-Based Require-ments Analysis, IEEE Software, March 1994, pp. 21±32. [34] J.M. Carrol, Introduction: The scenario perspective on
systems development, in: J.M. Carrol (Eds.) Scenario-Based Design, Wiley, New York, 1995, pp. 1±17.
[35] A MacLean, D. McKerlie, Design space analysis and use representations, in: J.M. Carrol (Ed.) Scenario-Based Design, Wiley, New York, pp. 183±207, 1995.
[36] P. Feldman, D. Miller, Entity model clustering: Structuring a data model by abstraction, The Computer J. 29(4), 1986, pp. 348±360.
[37] D. Avison, G. Fitzgerald, Information Systems Development: Methodologies, Techniques and Tools, 2nd edn., McGraw-Hill, London, 1995.
[38] R.K. Yin, Case Study Research: Design and Methods, 2nd edn., Sage Publications, San Fransisco, 1989.
[39] M. Feather, Requirements engineering ± getting right from wrong, in: Proc. 3rd European Conf. Software Engineering, Milan, 1993.
[40] R. Guindon, Knowledge exploited by experts during soft-ware system design, Int. J. Man-Machine Studies 33, 1990, pp. 279±304.
Graeme Shanks is a senior lecturer in the School of Information Management and Systems at Monash University, Melbourne, Australia. He holds a B.Sc. and a Ph.D. in information systems from Monash University. His research inter-ests include data warehousing, data quality, quality in conceptual modelling, and requirements definition. He has published articles inInformation Systems Journal,Journal of Strategic Information Systems,Requirements Engineering,Australian Computer Journal, andAustralian Journal of Information Systems.
