March
2004 Issue: 31
March
2004 Issue: 31
Journal of Conceptual Modeling
www.inconcept.com/jcm
Abstract.
This is the third paper in a series that examines the relevance of the entity relationship model to practical data modelling. This paper discusses an example of a conceptual model from the financial services industry. In the opinion of the expert practitioner proponents, the model has succeeded because it was not based on the entity relationship model. Although this model has been used for over ten years there is no account of it in the research literature, probably because much of the model details are proprietary. The model is shown to consist of a high level strategic classification of domain classes, together with an extensive classification hierarchy for the domain. A detailed entity class model can be derived from these two strategic components. This conceptual modelling takes place in a framework for strategic thinking. The framework provides the foundations for generic, stable, and creative design. By understanding how practitioners are evolving their models, there is a clear perception that the ER model will not provide what is needed from a ‘high level’ conceptual model. Indeed, practitioners seem to require something different of a conceptual model than the ideas provided by the ER model itself. The conclusion of the paper is that it is important to learn about developments by expert practitioners that are successfully used in a practical situation.
Introduction
This paper discusses the ideas behind one successful conceptual model that has been widely used in a vertical application in the financial services industry. This model has succeeded, in the opinion of its expert practitioner proponents, because it was not based on the ideas of the ER model. The Financial Services Data Model (FSDM) is domain specific, based on expert practitioner ideas about conceptual modelling. The FSDM is not a theory of modelling in the conventional sense, but the application of practitioner ideas about conceptual modelling to a specific domain. The ideas are currently only available in proprietary documents. The rest of this section briefly discusses the academic literature on conceptual modelling in the strategic context. Section II explains what the FSDM model consists of, and some of the thinking behind the ideas. Section III discusses the implications for researchers trying to understand conceptual modelling. Section IV is a brief conclusion.
Conceptual modelling is often equated with the entity relationship (ER) model. Proponents of FSDM view the ER model as a low level, design oriented logical model, similar to the relational model of data. In the previous two papers in this series we have proposed that practical modelling is based on the use of entity class diagrams that are based on the relational model of data. Domain experts may not have the time or the need to become involved with all of the classes and their relationships required to support the business. This is particularly true of strategic, ‘ball-park’, and tactical thinkers in the business domain. It is also the case that, at the enterprise level, a high level view of data needs to be established that will strategically guide the development of a highly generic model. This level of thinking is removed from detailed database design, and is therefore what some practitioners call ‘conceptual’ modelling. This view of conceptual modelling facilitates creativity in business data design. This is the idea of creatively managing the business data situation, as opposed to ‘representing a reality’. “… designing a corporate data model is a creative and opportunistic process.” Darke & Shanks (1999, p.22)
FSDM is also a strategic model. Martin (1990) and Finklestein (1989) proposed the idea of a strategic modelling layer that is used to align the business strategy and information technology developments. Strategic modelling is summed up by Veryard (1992, p 2-3):
“… information systems have the power to change the way the members of the organization think about their work. … One of the purposes of building an information model is to develop a strategy for the business. Long term plans for information systems development are increasingly based on some kind of high level model of the business entities and functions (often referred to as a strategic model or information architecture). The information architecture may include … important entity-types. Strategic models can express the changing intentions and conceptual structures of the business … To provide a framework for formulating opportunities to obtain direct competitive advantage … To establish and maintain the link between the strategic business objectives. … To obtain these purposes, far more breadth is needed and far less detail.”
Veryard (1992, p.136) also makes the point that:
“Information systems development is deliberately used by senior management to educate middle and junior managers, and to force the organization as a whole to learn new concepts and practices.” So the strategic model is a way of being creative in the way the data is organized to support the business.
The FSDM exists in the context of a framework developed from the Zachman’s ideas. Cook (1996, p.77-80), talking about developing information architecture in the context of the Zachman framework, discusses “The data architecture is designed around ten to twenty company assets that are critically important for the enterprise to meet its mission, assets like customer, material and money. The data architecture is more critical than the process architecture because most business processes exist to manage the assets, not the other way around. … In the ballpark view we are only interested in determining high-level classes of data … Global data classes are the highest level of abstraction of the data architecture. The main purpose of data modelling in the business view of the architecture is to help us validate that we have classified the data architecture correctly, not to design a database.
The idea of high level entity classes has parallels with the strategic simplification of models using subject areas, proposes by, for example, Martin (1990) and Finklestein (1989). Darke & Shanks (1999) used a case study to examine an approach that used subject areas to enable a high level understanding of corporate data model concepts. Darke & Shanks noted that data modellers reuse generic patterns from previous experience when generalising detailed ER diagrams. Darke and Shanks also shield business users from the intricacies of ER diagrams. The business users are presented with the subject areas in order to understand the data situation. However, in the generic data concepts are the starting point for business analysis, rather than an aggregation of entity classes that are built during conceptual modelling. In a sense we may view FSDM as the result of generalising financial services models from past experience. The FSDM is a generalisation used to analyse the current situation, and not a presentation device.
FSDM is a domain specific corporate wide model designed to generalize disparate business areas in the finance industry. There are a few papers that have discussed problems with corporate wide models. Batra & Marakas (1995) have argued that enterprise wide models are rarely employed and that relatively few organizations even build project models. There are two empirical studies (Shanks 1997, Beynon-Davies 1994) indicating significant problems in building and using a corporate data model. Shanks (1997, p.70) discuss “a number of empirical studies of strategic data planning have highlighted many problems with the use of data planning in practice.” “The data architecture is difficult to understand and communicate” (Shanks 1997, p.71). “While structured entity-relationship models may be suitable for experienced data modelers, they are probably not the most suitable language for business users and information systems practitioners who do not regularly practice data modelling.” (Shanks 1997, p.85)
Darke & Shanks (1999, p.20) concluded that:
“A major problem with corporate data models is that they are difficult to understand. Their abstract, generic concepts are unfamiliar to both business users and IS professionals, and remote from their local organizational contexts. Empirical studies indicate that many organizations have encountered significant problems in building and using a corporate data model”
The goal of data management is to manage data as a corporate resource in much the same way as tangible assets (Trauth, 1989). We can think of on-line transaction processing systems produce data as analogous to manufacturing items. The data needs to be used as a corporate asset, and unlike other assets can be re-used without being used up.
A fuller description of aspects of the IFW, and FSDM can be found on the Modelware International web site (for example Modelware 2003) and on the IBM site (for example IBM 2003 in the context of data warehousing) . Modelware International produce the ‘m1`’ tool that supports the IFW. However, much of the information about IFW and FSDM is proprietary. According to Modelware (2003), “The Financial Services Data Model (FSDM) is one of the most successful industry models developed anywhere. Constructed by IBM in 1991, it is now deployed in over 120 financial institutions worldwide.” The FSDM is also embedded in IBM’s Banking Data Warehouse offering. It turns out that the classification hierarchies of FSDM are very useful for defining the data mart cubes for multidimensional analysis. The purpose here is not to fully define the model, but to raise aware of what the model consists of.
Historically:
“IFW was developed by IBM’s Banking Solution Centre … in conjunction with input and feedback from many of the world’s leading financial institutions. … most of the development work … was derived from experience in the financial services industry … In 1988 IBM initiated the Financial Application Solutions for the 1990s (FAS90) project. FAS90 conducted surveys of financial institution needs through customer advisory boards and other forums … Two of the initial projects were to develop the Financial Application Architecture and the … FSDM” (Evernden 1994, p.39-40).
The FSDM has a wider context of a ‘framework’. This framework provides a “… strategy for managing information as a valuable asset; hence the name ‘Information FrameWork’” (IFW) (Evernden 1994, p.37). Within this framework, the Financial Services Data Model (FSDM) was “.. the first model to be defined for the finance industry. This model provided a stable and generic set of data definitions for a particular business and became a foundation to define the function and workflow models.” (Evernden 1994, p.47). The FSDM is defined in a set of ‘IBM confidential’ documents, for example FSDM (1993). The ‘A’ level in FSDM (version 1.01) identifies nine data concepts that define the scope of the enterprise being modeled. The ‘B’ level contains three ‘Data Concept Hierarchies’. The ‘C’ level is a corporate ER diagram, but will contain no relationship sets.
Starting from the assumptions of entity class diagramming for relation design, then every entity class represents a relation. There is no need to think about relationship sets, although we do need to think about relationships between classes (from a business domain perspective). This thinking is already simpler than using the semantics involved in the ER model. The FSDM simplifies things further by establishing a few entity classes, with no reference at all to relationships. At this level most of the classes have many to many relationships with all of the other classes, so there is little point in specifying this. Most probably these classes will be heavily sub-typed later. The idea is to concentrate on a few highly generic business concepts. This layer of high level classes is called ‘Layer A’.
In the FSDM (version 1) there are nine high level concepts in Layer A:
· Involved Party, people and organisations involved with the business;
· Products of interest to the business;
· Arrangement, between involved parties. (An arrangement would be a product involved party relationship set in the ER model. The concept is, however, crucial for thinking about the business);
· Event, anything that happens, business transactions for example (also an ER relationship set);
· Location any kind of location;
· Resource Items, could be an asset, document, etc;
· Condition, these can vary the performance of an arrangement (e.g. to hold a savings account the involved party must be over eighteen);
· Classification, these are viewpoints that classify more than one of the other concepts, for example language;
· Business Direction, things that vary the direction of the business, like goals.
Secondly, ‘data concept hierarchies’ or ‘classification hierarchies’ are constructed. This is called ‘Layer B’. These are similar to the idea of ontologies both at the generic and specific level discussed by Sugumaran & Storey (2002). An ontology defines the basic terms and relations comprising the vocabulary of a topic. It is worth noting that researchers are again following the trend to theorise, this time about ontologies, without explicit reference to ideas from practice and existing tools that pre-date the academic discussion by about ten years. Layer B is essentially the business vocabulary.
The hierarchies in level ‘B’ are of classification, descriptor and relationship. The classification hierarchy classifies instances of the data concept, and these both sub-types and classifying entity types of the main concept. For example, an ‘involved party’ may be classified as ‘individual’ and ‘organization’ and on another branch as ‘single’ and ‘married’. The descriptor hierarchy classifies properties of the main concept. These are basically attributes. Part of the involved party descriptor hierarchy would be ‘name’ and ‘name’ could be classified into ‘registered’, ‘short’ and ‘common’. The relationship classification is essentially a categorized list of all of the different relationships that can exist between one main concept and all of the others. For example, using two concepts ‘involved party’ and ‘location’. Part of the involved party classification hierarchy would be ‘involved party works at location’ and ‘involved party resides at location’.
The three hierarchies can be used to directly generate the underlying ER diagram. Essentially the hierarchies present a business view of detail that would otherwise be included in the ER diagram. Because each data concept at level ‘A’ has it’s own hierarchies, the effect is very similar to the use of very high level subject areas. There are real differences with the use and definition of subject areas, however. In Information Engineering subject areas are aggregates generated from an assessment of affinity between entity classes and business functions. In FSDM data concepts are starting ideas.
The proponents of IFW and FSDM view the ER model as a tool for logical level design, not a tool for business or conceptual design. This is because the conceptual model does not aim to define a database structure. The purpose of the conceptual model is to facilitate business people in describing the concepts that make up their business. The conceptual model is restricted to high level, generic, entity classes. The proponents of IFW perceive that subject areas were not successful with business users because to understand the subject area the users had to look at the underlying entities and relationships that make up the subject area. The conceptual model structure therefore uses the idea of high level data concepts and their classification hierarchies as a constrained way of thinking about the domain. The users do not have to look beyond to the underlying detailed entity classes and relationships. Classification is thought to focus understanding on the types of things that make up the business, rather than on the assembling a structured solution in terms of entity classes and relationships. In this conceptual modelling there is a clear distinction between the details of database structure and the conceptual modelling activity. This idea of conceptual modelling is that business users engage in high level conceptual thinking and not in data design. High level conceptual thinking should facilitate creativity, for example.
Therefore, if we look at the conceptual modelling being used by practitioners, the ER model does not predict the modelling taking place. What may have happened is that theorists have concentrated on developing an alternative data model (the ER model) whereas practitioners have concentrated on how to do ‘conceptual modelling’ better.
The existence of the FSDM and the IFW strongly suggests that researchers need to adopt a different idea about what constitutes a conceptual model in practical design. The ER model is viewed by these expert practitioners as a ’low level’ (Level C) tool for detailed database design. The ER model is therefore not conceptual in the sense of giving a high level conceptual view of the data. This is another view on the previous two papers in the series that the ER model has an unknown relevance to practical design. This is because practitioners use Bachman’s ideas about entity class diagrams (ECDs) for talking about an underlying normalized relational design. If Level C is supported by an ECD, then the conceptual element is provided by Levels A and B. Therefore the ER model itself seems to be of little relevance to practical modelling.
Instead of the detailed development of an alternative low level model, such as the ER model, researchers should instead be asking questions about how to deal with high level conceptual modelling. A conceptual model seems to be a simplification of an ECD, used with a domain classification. This conceptual model is pertinent to strategic thinking and has been used for over ten years. Rather like Bachman’s original diagrams, the ideas are considerably simpler than those in the ER model. The application of the ideas in practice, however, is a highly skilled task. This is the point at which conceptual design starts and the foundations of an enterprise data design are laid. So this is clearly a very different sort of conceptual model to the ER model, which only aims to generalise logical database design. Practitioners, then, have very different ideas about what constitutes a ‘conceptual’ model.
Conclusion
A version of conceptual modelling has been developed by practitioners, has been successfully used for over ten years and is nothing like the ER model predicted. This conceptual modelling takes place in a framework for strategic thinking. The framework provides the foundations for generic, stable, and creative design. By understanding how practitioners are evolving their models, there is a clear perception that the ER model will not accomplish what is needed from a conceptual model. Indeed, practitioners seem to require something different of a conceptual model than the ideas provided by the ER model itself. The conclusion of the paper is that it is important to learn about developments by expert practitioners that are successfully used in a practical situation. Overall, the series of three papers raises difficult questions for the proponents of the ER model as the basis for practical data modelling.
References
Beynon-Davies, P., (1994) Information management in the British national health service: The pragmatics of strategic data planning, Int. J. Inf. Manage. 14,pp.84-94.
Cook, M (1996) Building Enterprise Information Architectures Prentice Hall
Darke, P & Shanks, G. (1999) Understanding Corporate Data Models, Information and Management 35 19-30
Evernden, R. (1994) The Information Framework IBM Systems Journal 35(1) 37-68
Finkelstein, C (1989) An Introduction to Information Engineering : From Strategic Planning To Information Systems Addison-Wesley
FSDM (1993) Financial Services Data Model Reference Volume 1:Model Architecture Release 1.01 International Business Machines Corporation.
IBM (2003)
IBM Banking Data Warehouse General Information Manual (accessed June 2003)
Available from
http://www-1.ibm.com/industries/financialservices/pdf/IFW
_BDW_General_2.pdf on the IBM corporate site
http://www.ibm.com
Martin, J (1990) Information Engineering – A Trilogy Prentice Hall
Modelware (2003) Modelware International Pty Ltd (1999) m1-modelmaster Version 3.0 Business Classification Model Methods Guide Roseville, NSW Australia (available as a download, accessed July 2003, from http://www.modelwarepl.com/bg_fset_bcm.html). The quotation comes from this web page, accessed July 2003: http://www.modelwarepl.com/prod_fset.html
Shanks, G (1997) The challenges of strategic data planning in practice: an interpretive case study, Journal of Strategic Information Systems 6 69-90
Sugumaran V, Storey V.C (2002) Ontologies for conceptual modeling:their creation,use, and management Data &Knowledge Engineering 42 251 –271
Trauth, EM (1989) The evolution of information resource management. Information Management 16, 257-268
Veryard, R (1992) Information Modelling:Practical Guidance Prentice Hall
Zachman, J A Framework For Information Systems Architecture IBM Systems Journal 26(3)
Steve
Hitchman (steve@infomod.fsbusiness.co.uk) has been lecturing and
consulting in data modelling issues for over ten years. Steve is currently
managing a team of Data Architects in a government department. This paper was
the result of work carried out during a teaching and research semester at
Melbourne University.
© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement. ISSN: 1533-3825