Université du Québec à Montréal. Financial Services Logical Data Model for Social Economy based on Universal Data Models. Project

Transcription

1 Université du Québec à Montréal Financial Services Logical Data Model for Social Economy based on Universal Data Models Project In partial fulfillment of the requirements for the degree of Master in Software Engineering by Grazia Coppola Winter 2010

2 Financial Services logical data model for Social Economy based on UDM / 132

3 Financial Services logical data model for Social Economy based on UDM / 132 Table of Contents Table of Figures...8 Table of Tables...9 Acronyms and Abbreviations Introduction Intended Audience Problem Definition Objective What is a Data Model? Logical Data Models What are Universal Data Models? Approach High Level Use Cases Actors Overall Process New Project Process Functional Areas and Data Subject Areas Contact Management Directory Management Directory Management Feature List and Business Rules Directory Management Conceptual Data Model People and Organization (PARTY) Logical Data Model Mapping Key Data Concepts to UDM Entities PEOPLE and ORGANIZATION Entities and Attributes PARTY Data Examples Contact Mechanism Logical Data Model CONTACT MECHANISM Entities and Attributes CONTACT MECHANISM Data Examples Communication Event Logical Data Model Communication Event Feature List Communication Event Logical Data Model COMMUNICATION EVENT Entities and Attributes COMMUNICATION EVENT Data Examples Contact Management Observations and Findings People and Organization Contact Mechanism Communication Event Financial Product Management Financial Product Management Financial Product Management Feature List Financial Product Management Logical Data Model Financial Product Management Entities and Attributes Financial Product Management Data Examples Financial Product Management Observations and Findings Financial Product Regulations and Rules Management Financial Product Regulations and Rules Management Logical Data Model Financial Product Regulations and Rules Management Entities and Attributes...46

4 Financial Services logical data model for Social Economy based on UDM / FINANCIAL PRODUCT RULE Data Example Financial Product Regulations and Rules Management Observations and Findings Financial Agreement Management Contract Management Contract Management Feature List and Business Rules Financial Agreement Management Logical Data Model Financial Agreement Management Entities and Attributes Financial Agreement Management Observations and Findings Account Management Account Management Account Management Feature List and Business Rules Account Management Logical Data Model Account Management Entities and Attributes Account Transaction Management Logical Data Model Account Transaction Management Entities and Attributes ACCOUNT TRANSACTION Data Examples Account Management Observations and Findings Invoicing and Payment Management Billing and Payment Processing Billing and Payment Processing Feature List and Business Rules Invoicing and Payment Management Logical Data Model Invoicing and Payment Management Entities and Attributes Invoicing and Payment Management Observations and Findings Work Effort Management Project Management Project Management Feature List and Business Rules Work Effort (Account Notification) Management Logical Data Model Work Effort (Account Notification) Management Entities and Attributes Risk Analysis Risk Analysis Risk Analysis Feature List Risk Analysis Logical Data Model Risk Analysis Entities and Attributes Risk Analysis Data Example Risk Analysis Observations and Findings Budget Planning Financial Plan Logical Data Model Financial Plan Entities and Attributes Work Effort Observations and Findings Findings Universal Data Model support for Requirements General Criteria for Evaluating a Data Model Summary of Findings by Functional Area Other Findings Recommendations Conclusion Future Work Other Requirements Other Requirements Glossary of Terms...75 Bibliography...77 Books...77

5 Financial Services logical data model for Social Economy based on UDM / 132 Articles / Papers / Documents...77 Sites Web Appendix A - Contact Management Directory Management Feature List and Business Rules People and Organization Entities and Attributes Party Person Organization Party Type Financial Institution Government Agency Local Development Fund Enterprise Job Statistics Party Role Party Role Type Contact Principle Contact Employee Internal Organization Customer Supplier Partner Party Relationship Party Relationship Type Contact Mechanism Entities and Attributes Contact Mechanism Telecom Number Electronic Address Postal Address Contact Mechanism Type Party Contact Mechanism Party Contact Mechanism Purpose Contact Mechanism Purpose Type Geographic Boundary Contact Mechanism Boundary Geographic Boundary Type Geographic Boundary Association Geographic Boundary Association Type Communication Event Feature List Communication Event Entities and Attributes Communication Event Face to Face Communication Phone Communication Communication Event Purpose Communication Event Purpose Type Communication Event Status Communication Event Status Type Case Case Role Case Status Type Appendix B Product Management...97

6 Financial Services logical data model for Social Economy based on UDM / Product Management Feature List Product Management Entities and Attributes Financial Product Product Category Product Category Classification Product Feature Product Feature Applicability Functional Setting Functional Setting Applicability Financial Product Regulations and Rules Management Entities and Attributes Financial Regulation Regulation Requirement Financial Product Rule Appendix C Financial Agreement Management Contract Management Feature List and Business Rules Financial Agreement Management Entities and Attributes Financial Agreement Agreement Type Agreement Item Agreement Term Agreement Term Type Agreement Role Agreement Role Type Asset Appendix D - Account Management Account Management Feature List and Business Rules Account Management Entities and Attributes Account Loan Account Account Status Account Status Type Account Role Account Role Type Account Product Account Transaction Management Entities and Attributes Appendix E - Work Effort Management Project Management Feature List and Business Rules Work Effort (Account Notification) Management Entities and Attributes Work Effort Work Effort Status Work Effort Status Type Notification Task Internal Task Invoicing Task Statement Task Alert Task Marketing Task Other Notification Task Account Notification Internal Notification Risk Analysis Feature List Risk Analysis Entities and Attributes

7 Financial Services logical data model for Social Economy based on UDM / Risk Analysis Risk Analysis Subject Risk Analysis Subject Type Analysis Outcome Risk Analysis Result Parameter Type Analysis Parameter Budget Plan Feature List Financial Plan Entities and Attributes Financial Plan Financial Plan Type Financial Plan Status Type Expense Expense Item Financing Financing Item Appendix F Invoicing and Payment Management Billing and Payment Processing Feature List and Business Rules Invoicing and Payment Management Entities and Attributes Invoice Invoice Type Invoice Item Invoice Status Invoice Status Type Payment Application Account Payment Payment Method Type Appendix G - Mapping of SSFA entities to Universal Data Model Entities Appendix H French / English Terms

8 Financial Services logical data model for Social Economy based on UDM / 132 Table of Figures Figure 1: Example of the UML notation used in this paper...15 Figure 2: High Level Process Diagram...19 Figure 3: High Level Use Case Diagram...20 Figure 4: process flow from receipt of initial request to preparation of a contract Figure 5: process flow from signing of a contract to completion of the service Figure 6: Mapping of Key Concepts to Universal Data Model Subject Areas...25 Figure 7: SSFA Functional Areas and Subject Area...26 Figure 8: Directory Management Conceptual Data Model Diagram...28 Figure 9: People and Organization PARTY logical data model diagram...29 Figure 10: ORGANIZATION CONTACT RELATIONSHIP logical data model diagram...30 Figure 11: ORG PRINCIPLE CONTACT RELATIONSHIP logical data model diagram...31 Figure 12: CONTACT MECHANISM logical data model diagram...33 Figure 13: GEOGRAPHIC BOUNDARY Subtypes...34 Figure 14: COMMUNICATION EVENT logical data model diagram...37 Figure 15: Financial Product Management logical data model diagram...43 Figure 16: Financial Product Regulations and Rules Management logical data model diagram...46 Figure 17: Financial Agreement Management logical data model diagram...49 Figure 18: Account Management logical data model diagram...52 Figure 19: Account Transaction Management logical data model diagram...53 Figure 20: Invoicing and Payment Management logical data model diagram...56 Figure 21: Work Effort (Account Notification) Management logical data model diagram...60 Figure 22: Risk Analysis logical data model diagram...62 Figure 23: Financial Plan logical data model diagram...64

9 Financial Services logical data model for Social Economy based on UDM / 132 Table of Tables Table 1-1: Comparison of features for the three types of data models...14 Table 4-1: Functional Area and UDM Subject Area Scope...24 Table 5-1: Mapping Key Data Concepts to UDM Entities...31 Table 5-2: PARTY data example...32 Table 5-3: PARTY RELATIONSHIP data example...32 Table 5-4: CONTACT MECHANISM PURPOSE data examples...35 Table 5-5: CONTACT MECHANISM and GEOGRAPHIC BOUNDARY data examples...35 Table 5-6: CONTACT MECHANISM BOUNDARY data examples...36 Table 5-7: GEOGRAPHIC BOUNDARY ASSOCIATION data examples...36 Table 5-8: GEOGRAPHIC BOUNDARY data examples...36 Table 5-9: GEOGRAPHIC BOUNDARY ASSOCIATION TYPE data examples...36 Table 5-10: COMMUNICATION EVENT data example...38 Table 5-11: COMMUNICATION EVENT PURPOSE data example...39 Table 5-12: COMMUNICATION EVENT and CASE data example...39 Table 6-1: PRODUCT FEATURE and FUNCTIONAL SETTING relationship examples...44 Table 6-2 FINANCIAL PRODUCT data example...44 Table 6-3: FINANCIAL PRODUCT RULES data example...47 Table 8-1: ACCOUNT TRANSACTION data example...54 Table 8-2: ACCOUNT TRANSACTION TASK data example...54 Table 10-1: Mapping Project Management information to UDM Subject Areas...58 Table 10-2: RISK ANALYSIS data example...63 Table 11-1: General Criteria for Evaluating a Data Model...67 Table 11-2: Summary of Findings by Functional Area...69

10 Financial Services logical data model for Social Economy based on UDM / 132 Acronyms and Abbreviations Terms AI2L API (the) Chair DTES gif IT jpeg PDF SME SSFA UDM UML Definitions Association Internationale du Logiciel Libre Application Programming Interfaces The Chair for Open Source Software for Social and Solidarity Finance of the Department of Information Technology at University of Quebec at Montreal Desjardins Transaction Express Services Graphics Interchange Format (an image format) Information Technology Joint Photographic Experts Group, an image format Portable Document Format Small and Medium size Enterprise Social and Solidarity Finance Application. Refers to the open source software for social and solidarity financial services. This software will be delivered as product line by the Chair which includes a set of financial services application. A name for the product line has yet to be given by the Chair, SSFA is an acronym given by the author in this paper to facilitate writing and reading of the paper. Universal Data Models Unified Modeling Language

11 Financial Services logical data model for Social Economy based on UDM / Introduction The Chair for Open Source Software for Social and Solidarity Finance of the Department of Information Technology 1 at University of Quebec at Montreal has the goal of establishing the foundation for a family of open source software products for social and solidarity financial services. The Chair will act as the incubator for the development of a financial services product line of applications that would eventually be transferred over to the chair s funding partner, the Association Internationale du Logiciel Libre (AI2L) for the social economy. AI2L currently consists of six organizations, three are based in France and three are based in Quebec. The AI2L has the responsibility of providing the specifications for the software applications and will ultimately be responsible for the distribution of the software to its members in the social economy community. The Chair s understanding is that the majority of the organizations that are part of the social economy interested in the financial services applications to be developed are small and medium size enterprises (SMEs). The enterprises all offer some form of financial services and products to their clients. It is a known fact that the financial services offered by these organizations will vary from organization to organization. Following are the six members of AI2L and a very brief description of the type of services and products they offer: 1. Caisse d'économie solidaire (Quebec): offers financial services to both enterprises and individuals. This cooperative financial institution offers a variety of services and products including loans, savings plans, insurance, and also payment services like credit card and debit card. 2. Crédit Coopératif (France): a cooperative bank offering to its mostly business clients a full range of financial banking services. 3. Groupe Chèque Déjeuner (France): offers a wide variety of services and products to organizations and individuals, products like credit cards and certificates that can be used to purchase goods and services essential to daily life (e.g. food, clothing and transportation) and also for entertainment services. 4. (Quebec): is a non-profit organization that provides loans to local development funds and SMEs. 5. Fondaction (Quebec): a worker s fund that provides a wide variety of savings plans to its members. It is also heavily involved in investing in businesses to help maintain and create new jobs in the Quebec market. 6. La Macif (France): a mutual insurance company offering to its members a variety of insurance plans, saving plans and credit. Based on the diversity of financial services and products offered by these six AI2L founding members it is obvious that to develop a software application that meets all the needs of each organization involved in the social economy is next to impossible. The Chair, with its limited resources, has as an objective to develop a solid application architecture and a generic financial services application that can be extended to meet as many as possible the varying needs of social economy organizations. The term generic is used to mean that the application must be designed with an extensible architecture allowing for flexibility for the addition of new products and services with relative ease. A key element for the success of such an application is the structure of the data to support the business functions. This 1 In French: La Chaire de logiciel libre- Finance sociale et solidaire, will be referred to as the Chair in the rest of this document.

12 Financial Services logical data model for Social Economy based on UDM / 132 paper addresses what the structure of the data would look like to be able to meet the varying needs of the organizations planning to deploy the open source software for social and solidarity finance. 1.1 Intended Audience This paper has been requested by the chairman of the Chair, Professor Louis Martin and will also be presented to members of the Chair s funding partner, AI2L. Its main target audience are the architects and developers of the software. The business requirements and the data structures presented in this paper are indented to serve as an initial base for building a prototype of the open source software for Social and Solidarity Finance Application (SSFA) to test key architectural decisions and deliver an application that can be used to elicit further requirements. It is assumed that the reader has some familiarity with entity relationship modelling and its notation. 1.2 Problem Definition The Chair has as a goal to develop a financial services software application that is flexible to meet as many as possible the requirements of various social economy organizations that offers financial services and management of these services to its customers. Although the Chair is developing open source software and the code would be made widely available, the objective is to provide software that is customizable through configuration and not requiring code changes to meet user requirements. Also to note, the Chair understands that most of the social economy Financial Services organizations do not have the technical resources to customize software code. The Chair has recommended the following high level architectural decisions, to help deliver an extensible architecture to meet the requirements for a software solution that is highly flexible and easily customizable without the need to redesign or access code to add new financial services functions: 1. The use of a business rules engine to manage and evaluate business rules, allowing for dynamic modifications of business rules. 2. The use of a business process engine to coordinate the execution of business process activities. 3. Use PostgreSQL, an open source Relational Data Base Management System (RDBMS), to store and maintain data records. 4. And the adoption of polyglot programming to allow for the right programming language for the task at hand; though the main programming languages will be Java, an object oriented language. The decision to use a business rules engine and business process engine is based on the need for application flexibility that will allow for business functions and business rules to be maintained outside of the core application program code. This is a move away from the object-oriented paradigm where software developers manipulate data and functions within an object. This decoupling of the data from the functions will require that the software developers build separate function and data models. Also that implies that the developers need to design the application to allow for flexibility to introduce new business functions into the application and to design extensible data architecture to support the varying requirements of Financial Services organizations. A key point to note is that business rules engines and business process engines exist to manipulate business data, making the structure of the data a crucial element to the success of the software solution.

13 Financial Services logical data model for Social Economy based on UDM / 132 The integrity and correctness of data is of great importance to financial services organizations. The data typically outlives the life of an application; it is typically migrated or converted in one form or another to the replacement application or made accessible for different uses as the business evolves. The challenge addressed in this paper is to answer how to best develop a data structure needed to support a generic and flexible financial service software application, given the limited availability of business domain expertise on the Chair and the limited resources to develop a good quality data model. The obvious answer was to search for re-usable data structures. Reuse is a very common and encouraged practice in the Information Technology (IT) industry. Besides reusable software components/modules and design patterns there exists a number of re-usable data structures. Len Silverston has written three books and numerous articles on the topic of re-useable data structures which he refers to as Universal Data Models. 2 These models are intended to jumpstart 3 the development of high quality data models that will result in data structures that can easily evolve or be extended. 1.3 Objective The objective of this paper is to investigate if the Universal Data Models (UDM) proposed by Len Silverston can be used as a starting point for developing the need data structures required to support the varying needs of social economy financial services organizations. Since data does not stand on its own in that it only makes sense in terms of the business activities it supports,, a member of AI2L, offered to provide a set business functions bases on their current Lotus Notes application which uses to manage their business. Validation of the usefulness and applicability of UDM is supported by analyzing s current Lotus Notes application to derive a list of requirements and business rules and mapping those requirements against the data models described in the Universal Data Models. 1.4 What is a Data Model? A data model defines the structure of the data to support the business activities. A data model is developed through a known data modeling process which involves: 1. The analysis of business functions and their required information 2. Data design activities 3. Producing full documentation of the data model. The data model documentation contains at a minimum: 1. Entities 4 and their descriptions 2. An Entity Relationship Diagram, a graphical representation of the entities and their relationships, using widely understood common syntax so that they may be understood by business analysts 3. Entity attributes: the pieces of data that describe an entity 4. Entity primary key: consists of one or more data attributes that uniquely identify a specific instance of an entity 5. Entity foreign keys: are data attributes that define relationships between entities, used to navigate between the different instances of an entity. Also known as referential attributes, since they are a primary key of another entity. 2 TM 3 To quickly and successfully set into motion. 4 A person, object, place or event for which data is collected and stored in a database.

14 Financial Services logical data model for Social Economy based on UDM / 132 The data modeling process involves the development of three different levels of data models starting with the Conceptual Data Model whose purpose is to facilitate communication between the data modeller and the business. This data model is defined in business terminology, describes the data things of interest (aka data entities) at a high level and how they relate to one another. The Conceptual Data Model is technology independent. The second model is the logical data model (LDM) which focuses on understanding and documenting the details of the data. It uses as input the Conceptual Data Model and further details the entities and their relationships to place them into structures that facilitate their implementation in a RDBMS using data modeling techniques designed for building good quality data bases. The LDM details include attributes of the entities, primary keys and foreign keys. The LDM also does not contain database platform specifics. The third and final data model is the Physical Data Model which incorporates any changes to the Logical Data Model required to implement the data in the physical RDBMS of choice and to achieve the required performance. The following table summarizes the three different levels of data models and which features are detailed in each. Table 1-1: Comparison of features for the three types of data models Feature Conceptual Logical Physical Entity Names Entity Relationships Attributes Primary Keys Foreign Keys Alternate Keys Table Names Column Names Column Data Types Indexes Adapted from: Logical Data Models The data models presented in this a paper are logical data models, their purpose is to understand the data structure required to address the basic business needs as understood at the time of writing based on an analysis performed on the needs of and limited knowledge of the Financial Services domain. The data models are by no means complete, they are an initial logical data model, deemed good enough to evaluate if the UDM defined by Len Silverston are a good starting point logical data models for SSFA. The logical data model diagrams presented in this paper use the Unified Modeling Language (UML) notation. Although UML is not the most ideal notation for describing data entity relationship models it was chosen since it is the notation language most developers are familiar with. In the data model diagrams the data entities are shown as UML classes, entity relationships are shown as associations including multiplicity, and association ends are used to describe the relationship. Since most of the LDM diagrams contain several entities, to keep the diagrams legible the primary key, foreign keys and attributes are not shown in the diagrams, they are provided with the entity description in the Appendix sections of this paper.

15 Financial Services logical data model for Social Economy based on UDM / 132 Figure 1: Example of the UML notation used in this paper The above diagram reads as follows: Each ORDER may be composed of zero or many ORDER ITEMs. Each ORDER ITEM must be part of one and only one ORDER. SALES ORDER and PURCHASE ORDER are subtypes of ORDER or ORDER is a supertype of SALES ORDER and PURCHASE ORDER. Note: Entity names are written in capital letters. Subtypes represent the set of possible classifications of an entity that has characteristics such as attributes or relationships in common with the more general (supertype) entity, hence the attributes and relationships of the supertype are inherited by the subtype. In the above diagram SALES ORDER is a subtype of ORDER. ORDER is the supertype for SALES ORDER and PURCHASE ORDER. The TYPE entities (e.g. ORDER TYPE in Figure 1), represent a classification, these entities store the complete set of values allowed for the entity (ORDER), some which may not appear in the diagram. Note: An important element of a logical data model is the documentation of the entities and their attributes. The entity descriptions provided in the Appendix sections of this paper are based on the entity descriptions provided in The Data Model Resource Book Volumes 1 5, Volume 2 6 and Volume The Data Model Resource Book, Volume 1, A Library of Universal Data Models for all Enterprises, by Len Silverston, 2001, John Wiley & Sons, Inc. [BB-1] 6 The Data Model Resource Book, Volume 2, A Library of Universal Data Models by Industry Types, by Len Silverston, 2001, John Wiley & Sons, Inc. [BB-2] 7 The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

16 Financial Services logical data model for Social Economy based on UDM / What are Universal Data Models? Len Silverston is an author of several articles and three books on the topic of Universal Data Models. Volume 1 [BB-1] of The Data Model Resource Book presents data models for data common to all types of enterprises, such as People, Organizations, Human Resources, Products, Invoices, Accounting and Budgeting. Volume 2 [BB-2] shows how to extends the standard models presented in Volume 1 to address industry specific data modeling requirements for a variety of industries such as Manufacturing, Financial Services and Insurance. Volume 3 [BB-3] provides a library of templates and alternatives for common universal patterns or themes in data modeling that appear over and over again in most data modeling such as ways to model roles, statuses, classification, hierarchies, business rules and contact information. 8 The models presented are universal since they describe generalized and abstract set of entities, relationships and attributes modeled to support common data needs and to facilitate the extendibility and evolution of the data models to address specific business needs. Mr. Silverston emphasises that there is no such thing as a right data model his models provide alternatives to modeling various structures and point out the pros and cons of each 9. According Mr. Silverston the UDM are most beneficial to data modellers. UDM represent a repository of reusable logical data models that can easily be extended and customized. They are based on the experience of professionals and have gone through several iterations. Using UDM would save time and effort by leveraging on the reuse of good quality data models. In addition the UDM provide a holistic perspective, hence allowing for data modellers to proactively inquire, validate and explore about possible information requirements, this aspect is especially beneficial when the data modeller initiates data modeling activities with limited domain knowledge. In short the UDM are essentially a toolkit of best practices data structures for data modeling that have been proven and successfully implemented in industry. 8 Interview with Len Silverston of Universal Data Models by Robert S. Seiner and Len Silverston, April 2009, The Data Administration Newsletter, LLC [BA-1] 9 Universal Data Models: Simsion interviews Silverston, October 2003, Wilshire Conferences [BA-2]

17 Financial Services logical data model for Social Economy based on UDM / Approach The objective of this paper is to validate the claimed benefits of using the UDM to jump start the creation of good quality logical data models. An analysis of s Lotus Notes application was done to allow for validation of the Universal Data Models. It is understood that the analysis of one organization s functions and data is not enough to validate a generic data model; the plan is to conduct a similar analysis with at least one more organization that provides financial services in the social economy before a prototype of SSFA is developed. The following outlines the series of activities carried out in an iterative fashion, each time further refining the business requirements and the data models to support those requirements: 1. Analyze overall requirements: i. Extract and analyze requirements, by analyzing their current Lotus Notes application user guides which provide the functional capabilities and data elements of the application ii. Hold work sessions and meeting with personnel for further clarification of the requirements iii. Develop a High Level Use Case Model to identify the system boundaries iv. Develop an Overall Process Diagram for v. Review and validate the above high level documents with the business analyst vi. Produce an overall Conceptual Data Model to identify the key data concepts (aka Subject Areas) and the Functional Areas that the requirements address. 2. Gain overall understanding of the UDM: i. Review the 3 volumes of The Data Model Resource Book by Len Silverton ii. Identify the Universal Data Models that address the Functional Areas and Subject Areas needed to meet the requirements. 3. Further analysis of requirements: i. Conduct a more detail analysis of the business requirements and business rules ii. Document to validate the business requirements and rules with the business analyst. 4. Develop a logical data model for each Functional Area: i. Analyze the appropriate Universal Data Models, specifically the entities, relationships and their attributes ii. Map the entities to the UDM entities iii. Produce the logical data models for the Subject Area using the UDM as the base and extend them with the requirements iv. For the more complex entities provide examples of the entities with sample data to help better understand the data model v. Identifying any gaps between the needed data structures and the UDM (if any) vi. Document observations or findings regarding the use of the UDM as starter logical data model for the Functional Area. The above process was used to produce for each Functional Area the following documentation: 1. feature list of general business requirements and business rules. 2. SSFA logical data model diagram based on the UDM and extended to include data requirements.

18 Financial Services logical data model for Social Economy based on UDM / SSFA logical data model documentation which includes description of entities, primary and foreign keys and attributes. 4. Observations and findings regarding the use of UDM as a starter model. To document the business requirements it was deemed sufficient to produce a list of features rather than document the requirements in Use Cases, since the main objective of this paper is to document the logical data model and not the detail functional requirements. To document the requirements in Use Case format would necessitate an analysis of the User Interface required for the SSFA solution which is believed will be very different than the current Lotus Notes User Interface.

19 Financial Services logical data model for Social Economy based on UDM / The following section provides a description of s process, functions and required data. is a non-profit organization that provides loans and loans associated financial services to Local Development Funds and SMEs. The Local Development Funds in turn loan money to various organization in their jurisdiction. Some of Local Development Funds are given access to the Lotus Notes application to manage the loans they provide to their clients. In this case the Local Development Fund is given access to a complete separate instance on the Lotus Notes application (including data base), provides the application and the environment to execute the application. The overall process for to provide services is as show in the following diagram. Figure 2: High Level Process Diagram The above diagram shows a request for financial services is made by a potential customer, will analyse the request, if the request is approved by the Board of Directors a contract is prepared, a project is created to manage the service and the financial service is delivered to the customer. At pre-established periods will collect payments for the service and monitors the progress of the customer s ability to pay for the service. Once the customer has completely paid for the service the project is closed. 3.1 High Level Use Cases Use cases provide functional descriptions of a system s behaviour. The following diagram shows the high level use cases depicting the main functions of the Lotus Notes application that wished to replace with a new financial services application.

20 Financial Services logical data model for Social Economy based on UDM / 132 Figure 3: High Level Use Case Diagram Following is a brief description of each high level use case: Manage Company Directory: Allows for the managing of contact type information. requires that all persons or organizations its employees have business dealings with be included in the contact database. Manage Project: Once and a customer have reached an agreement regarding a financial service that will provide, the complete management of that service is handled under an umbrella of what refers to as a Project. Manage Loans and Other Services: s main service is to provide loans with varying parameters to Local Development Funds and other SMEs. also provides other financial services like guarantees. This high level uses case addresses the management of the disbursement, re-payments loans and other financial services. Manage Contract: All services provided to customers require some form of agreement or contract with signatures, this use case addresses the management of the contract terms and conditions for services provided to a customer. Track Customer Communication: requires that all communications exchanges between its employees and customers be logged, including s, face-to-face meetings, and phone calls. This high level use case address the effective tracking of communication exchanges with customers.

21 Financial Services logical data model for Social Economy based on UDM / 132 Manage Product: Before a product or service can be offered to customers it needs to be defined. This user case allows for the definition of the various services with their parameters and settings combinations. Currently this function is done mostly manually. Produce: This use case addresses the reporting needs of including queries and dashboards. Mass Mailing: Allows for the mass mailing of information to a group of customers Actors In use case modeling actors are people or systems that interact with the system in question to achieve a desired goal. Following is a list of actors as depicted in Figure 3: High Level Use Case Diagram: Local Development Fund: Customers to whom provides mostly loans to. In turn these Local Development Funds provide loans to local organizations in their jurisdiction. Some Local Development Funds are given a complete instance of the Lotus Notes application which is hosted in s environment to manage the loans they provided to their local customers. Project Manager: Person responsible for the overall management of a Project. Project Manager is a main user of the system. Analyst: Provides assistance to the Project Manager for the management of a Project. Analyst is also a main user of the system. Board of Directors: Members who oversee the activities of. Their responsibility includes the approval of loans and services provided by. They are mainly interested in having access to reports and dashboards provided by the system. Desjardins Transaction Express Service: uses Desjardins Transactions Express Service for disbursing loans and collecting payments. ( rarely deals with cash and checks). Document Management System: Allows for the storage and retrieval of electronic documents of various formats (Word, PDF, Excel, Word Pad, Power Point, Images). Currently the Document Management System (DMS) is integrated with the Lotus Notes application. Mail System: Allows for the exchange of electronic mail. Currently the Lotus Notes application has an integrated mail system. Spreadsheet application: makes extensive use of Excel for preparing payment schedules and budget plans. Lotus Notes allows for easy integration with Excel. Accounting System: Currently data from the Lotus Notes application is manually prepared and sent to the Accounting System.

22 Financial Services logical data model for Social Economy based on UDM / Overall Process New Project Process Figure 2: High Level Process Diagram shows a very high level view of the process has implemented to process requests for financial services. The following diagram provides a little more details regarding that process of a request up to the preparation of a contract. Figure 4: process flow from receipt of initial request to preparation of a contract. Once a request for financial services is received a project is created which serves to group and manage all activities related to the request from the receipt of the request for services up to the time the services are completed or closed. If the customer is new to, all its contact information is captured. Any documents related to the project that are provided by the customer or prepared by a employee are saved in s Documenting Management System (DMS) and linked to the project. An internal committee of analysts reviews the request and conducts an initial risk analysis of the request to determine if should provide the requested services. If the request is deem viable a budget plan is produce. In some cases a set of pre-condition tasks are established which are require to be completed before can provide the requested service(s). A financial risk analysis report is produced and presented to the Board of Directors for approval to provide the services. If the board approves the request a contract is prepared outlining the terms and conditions to be met by both the customer and. The following diagram is a continuation of the above flow depicting the process after a contract is prepared and signed by both parties.

23 Financial Services logical data model for Social Economy based on UDM / 132 Figure 5: process flow from signing of a contract to completion of the service. Once a contract is signed the requested service in delivered to the customer, for example in the case of a loan the requested funds are provided to the customer, through the Desjardins Transaction Express Services 10 (DTES). At predefined periods will send to DTES data requesting payments for a project. Payment data is received from DTES and updates are made accordingly in the Lotus Notes application, at the same time accounting data is prepared manually and sent to the Accounting System. On a regular basis project follow-up activities are performed and tracked including annual review of interest rates being charged to the customer. In cases where the customer is unable to pay due to bankruptcy the amount of money owed to is written-off or once the customer has completely paid for services rendered all documents associated with the project are saved into the DMS and the project is closed. 10

24 Financial Services logical data model for Social Economy based on UDM / Functional Areas and Data Subject Areas The objective of this study is to validate if the UDM can help jump start the development of the logical data model for SSFA. Given the number financial services business processes, activities and the various data needs to support these processes, a structure is required to help manage and understand the complex of areas of interest. A common approach is to group business activities and data into Functional Areas and Subject Areas. To identify the Functional Areas a simple one to one mapping of the High Level Uses Cases to Functional Area is done (see column (a) in Table 4-1: Functional Area and UDM Subject Area Scope below). In addition the key data concepts (column b) for the Functional Area are identified based on the key data needed to perform the tasks for the Functional Area. Since the objective is to develop a generic application the Functional Areas are given more generic names (column c). Finally based on the key data concepts the UDM Subject Area are identified (column d). Table 4-1: Functional Area and UDM Subject Area Scope High Level User Case /Functional Area (a) Key Data Concepts (b) Functional Area SSFA Generic Model (c) Manage Company Directory / Directory Management Society, Contact Contact Management UDM Subject Area (main ENTITY) (d) People and Organization (PARTY, PERSON, ORGANIZATION, CONTACT MECHANISM) Manage Product/ Product Management Loans, Other Financial Services Product Management Financial Product (FINANCIAL PRODUCT, FINANCIAL PRODUCT REGULATIONS AND RULES) Manage Contract /Contract Management Contract Agreement Management Financial Agreement (FINANCIAL AGREEMENT) Manage Loans and other Services Payment, Disbursement Account Management Financial Account (FINANCIAL ACCOUNT, FINANCIAL ACCOUNT TRANSACTION) Manage Loans and other Services Request for Payment Invoicing and Payment Management Invoice (INVOICE) Track Customer Communication Follow-up Log Contact Management People and Organization (COMMUNICATION EVENT) Manage Project, Analyze Risk / Project Management Project, Risk Analysis, Budget Plan, Follow-up Activity Work Effort Management Work Effort (RISK ANALYSIS, FINANCIAL PLAN, ACCOUNT NOTIFICATION)

25 Financial Services logical data model for Social Economy based on UDM / 132 Produce Reports & Mass Mailing These are not considered Functional Areas rather they are lower level activities, all information needed to conduct these activities is created in Functional Areas already identified. In Table 4-1: Functional Area and UDM Subject Area Scope column (c) and (d) provide the Functional Areas and UDM Data Subject Areas/Entities of interest, essentially defining the scope that addresses financial services requirements based on the functionality covered by s Lotus Notes application. These Functional Areas and Subject Areas serve as the initial model for SSFA. Following diagram displays the key data concepts overlaid with corresponding UDM Subject Areas as described in Table 4-1: Functional Area and UDM Subject Area Scope Figure 6: Mapping of Key Concepts to Universal Data Model Subject Areas The following diagram displays the Functional Areas and Subject Areas of interest addressed in this paper based on the scope of the Lotus Notes application for which the initial logical data model based on UDM is developed for SSFA.

26 Financial Services logical data model for Social Economy based on UDM / 132 Figure 7: SSFA Functional Areas and Subject Area The following sections of this paper describe for each Functional Area the requirements and the generic logical data models based on UDM to support the requirements and other requirements deemed essential for the Financial Services Functional Area.

27 Financial Services logical data model for Social Economy based on UDM / Contact Management Contact Management is the generic functional area name for what refers to as Directory Management. This functional area s main purpose is to allow organizations to: Record the various relationships between organizations and individuals Store and retrieve customer, partner, and any other entities of interest to the organization Keep track of customer exchanges such as phone calls, s, and letters. The subject area that supports the needs of Contact Management is known as the People and Organization subject area in UDM terminology. Since this subject area contains many entities the entities are separated into three logical data models: 1. Party 2. Contact Mechanism 3. And Communication Event. 5.1 Directory Management maintains a directory of information regarding any organization and person it has any dealings with. uses the general term Society for organizations to differentiate them from a person, who is referred to as a Contact. Besides basic information such as name and address the Directory maintains information regarding the organization s profile such as whether the organization is unionized, the type of business it is in, if the organization is a Local Development Fund, a Partner or a Government Agency Directory Management Feature List and Business Rules See Appendix Section 15.1 Directory Management Feature List and Business Rules, for descriptions of features and business rules.

28 Financial Services logical data model for Social Economy based on UDM / Directory Management Conceptual Data Model Figure 8: Directory Management Conceptual Data Model Diagram Figure 8 shows the key data concepts that support Directory Management Functional Area. refers to the organizations it deals with as Societies, the various types are: LOCAL DEVELOPMENT FUND to whom money is loan to ENTERPRISE, to whom money is loan to PARTNER FINANCIAL INSTITUTION SUPPLIER INTERNAL ORGANIZATION refers to. maintains up to the last five year of JOB STATISTICS for LOCAL DEVELOPMENT FUNDs and ENTERPRISEs. A SOCIETY must have at least one CONTACT. In some cases a specific person may be a CONTACT for more than one SOCIETY, hence the many to many relationship between SOCIETY and CONTACT. Currently the Lotus Notes application requires that a CONTACT must belong to at least one SOCIETY. ADDRESS information is maintained for the SOCIETYs and their CONTACTs. also requires a log be maintained of any s, FACE-TO-FACE MEETINGs, TELEPHONE CALLs and FAes that are exchanged with a CONTACT. In addition any documents exchanged may also be stored in the Document Management System. 5.2 People and Organization (PARTY) Logical Data Model As stated earlier Contact Management is the term chosen for Financial Services application functional area that encompasses the functionality and data requirements of Directory Management. The

29 Financial Services logical data model for Social Economy based on UDM / 132 main subject area to support this functional area is known as People and Organization in the Universal Data Model. Following diagram is the logical data model for the generic People and Organization Subject Area. The entities shown in the diagram are a subset of those that appear in the UDM, only entities deem required to support the based requirements are included in the data model. Figure 9: People and Organization PARTY logical data model diagram Those entities with a note are entities specifically added to the SSFA logical data model to satisfy requirements. Key data structures used from the UDM are PARTY, PARTY ROLE and PARTY RELATIONSHIP. PARTY is the supertype entity for subtypes PERSON and ORGANIZATION; it maintains information about a PERSON or ORGANIZATION of interest. PARTY entity exists because organizations and people require similar type of information to be stored and maintained, e.g. name, address, and phone number. A PARTY is of interest to Financial Services organization due to the assigned or required actions and activities it performs. It is common that a PARTY may perform many different activities or plays different roles. The PARTY ROLE supertype contains the common information that may exist to support the different types of roles to that a PARTY may be acting as. In the above diagram the PARTY ROLE subtypes shown are those roles which are needed to support the Contact Management Functional Area, based on the requirements. Later in this paper other PARTY ROLE subtypes will appear in LDM to support other Functional Areas e.g. OWNER, GUARANTOR, CO-OWNER.

30 Financial Services logical data model for Social Economy based on UDM / 132 In most cases the roles that a PARTY plays has to do with its relationship with another PARTY. For example in a CONTACT must belong to an ORGANIZATION, hence a PERSON has a role of CONTACT in relation to an ORGANIZATION. (In the SSFA logical data model the SOCIETY is represented by the supertype ORGANIZATION). Note: The TYPE entities contain the set of allowed types for the Entity (it contains the complete set) some which may not appear in the diagram. The PARTY TYPE data structure is for classifying the PARTY. This entity is of interest to Financial Services organizations to support the classification of client organizations based on any classification the Financial Services organization requires. A client organization may be classified for example by industry or size. In the case of they would be interested in classifying their LOCAL DEVELOPMENT FUNDS by Minority owned businesses, Women owned business or Women s shelter. Figure 10: ORGANIZATION CONTACT RELATIONSHIP logical data model diagram The above diagram shows PARTY RELATIONSHIP having a subtype of ORGANIZATION CONTACT RELATIONSHIP to model the relationship between a CONTACT and an ORGANIZATION which identifies the ORGANIZATION that a CONTACT belongs to. Also Figure 10 shows the EMPLOYMENT entity to model the relationship between an INTERNAL ORGANIZATION and EMPLOYEE. The EMPLOYMENT entity would maintain all information regarding the employee s employment for an INTERNAL ORGANIZATION.

31 Financial Services logical data model for Social Economy based on UDM / 132 Figure 11: ORG PRINCIPLE CONTACT RELATIONSHIP logical data model diagram The above diagram shows PARTY RELATIONSHIP having a subtype of ORG PRINCIPLE CONTACT RELATIONSHIP to model the relationship between a PRINCIPLE CONTACT and an ORGANIZATION which identifies the principle contact for an ORGANIZATION and would maintain any specific information regarding that relationship Mapping Key Data Concepts to UDM Entities In the SSFA logical data model the SOCIETY entity is referred to by the ORGANIZATION supertype and its subtype. The CONTACT is referred to by PARTY subtype PERSON and PARTY ROLE subtype CONTACT. The subtype entities LOCAL DEVELOPMENT FUND and ENTERPRISE of ORGANIZATION are included since the belief is that has slightly different processes depending if the CUSTOMER is a LOCAL DEVELOPMENT FUND or an ENTERPRISE. Table 5-1: Mapping Key Data Concepts to UDM Entities Entities (from Universal Data Model Conceptual Data Model) Entities Notes SOCIETY PARTY, ORGANIZATION The term SOCIETY is the same as UDM ORGANIZATION which is a subtype of PARTY. LOCAL DEVELOPMENT FUND ENTERPRISE Subtype of ORGANIZATION, CUSTOMER Subtype of ORGANIZATION LOCAL DEVELOPMENT FUND is added as a Subtype of ORGANIZATION. CUSTOMER is a subtype of PARTY ROLE. ENTERPRISE added as a Subtype of ORGANIZATION. CUSTOMER is a subtype of PARTY ROLE. CONTACT A subtype of PARTY ROLE GOVERNMENT AGENCY REGULATORY AGENCY Decided to keep the more generic UDM entity name of REGULATORY AGENCY FINANCIAL INSTITUTION Same Entity Name Subtype of ORGANIZATION. PARTNER Same Entity Name Subtype of ORGANIZATION. SUPPLIER Same Entity Name Subtype of ORGANIZATION. FINANCIAL INSTITUTION Same Entity Name Subtype of ORGANIZATION. INTERNAL ORGANIZATION Same Entity Name Subtype of ORGANIZATION.

32 Financial Services logical data model for Social Economy based on UDM / 132 EMPLOYEE Same Entity Name Subtype of PARTY ROLE. JOB STATISTICS Added to the SSFA logical data model ADDRESS CONTACT MECHANISM See Section 5.3. FACE-TO-FACE MEETING COMMUNICATION EVENT See Section 5.4. TELEPHONE CALL COMMUNICATION EVENT See Section 5.4. FA COMMUNICATION EVENT See Section PEOPLE and ORGANIZATION Entities and Attributes See Appendix Section 15.2 People and Organization Entities and Attributes, for descriptions of the entities and attributes PARTY Data Examples As one can see generic or universal data models are much more complex to understand, they would not typically be the type of models to be reviewed with business domain experts, they are intended for the software developers of an application. Following are data examples of some of the People and Organization Subject Area entities provided to help better understand the data models. Table 5-2: PARTY data example PARTY. Party ID PERSON. Last Name, First Name ORGANIZATION. Name PARTY ROLE TYPE. Role type id PARTY ROLE TYPE. Name CONTACT. Title EMPLOYEE. User ID 10 Fonds ACE 1 Customer 12 Fonds ABC 1 Customer 15 6 Internal Organization 20 YMCA 2 Partner 50 Roy, Nicole 3 Employee NRoy 33 Bureau en Gros 4 Supplier 22 Enterprise Nadia 1 Contact Meubles 13 Blais, David 4 Contact Manager 42 Martin, Ray 5 Principle Contact Director Table 5-3: PARTY RELATIONSHIP data example PARTY RELATIONSHIP TYPE. Name PARTY RELATIONSHIP. From Party (Name) PARTY RELATIONSHIP. From Role (Description) PARTY RELATIONSHIP. To Party (Name) PARTY RELATIONSHIP. To Role PARTY RELATIONSHIP. from date Partnership YMCA Partner Internal 1990/11/01 Organization Organization Blais, David Contact Fonds ACE Customer 1999/02/01 Contact Relationship Org Principle Martin, Ray Principle Contact Fonds ACE Customer 2008/01/01 Contact Relationship Employment Roy, Nicole Employee Internal 1992/01/10 Organization Customer Relationship Fond ABC Customer Internal Organization 2007/12/08 PARTY RELATIONSHIP. thru date

33 Financial Services logical data model for Social Economy based on UDM / Contact Mechanism Logical Data Model and other Financial Services organizations need to maintain PARTY information such address, various phone numbers, and addresses. The UDM refers to the various ways a person or organization can be contacted as contact mechanisms. Contact mechanism information is an important part of Contact Management. Given the different types of contact mechanism information it is not easy to model the various contact mechanisms in a consistent way. Following is the logical data model diagram modeling the contact mechanism entities and their relationships based on the UDM. Figure 12: CONTACT MECHANISM logical data model diagram Volume 3 of The Data Model Resource Book 11 series, has over 100 pages on the topic of alternative data models for contact mechanism, the author describes 4 different pattern levels for contact mechanism, Level 1 being the least flexible and Level 4 being the most flexible. The logical data model diagram above contains selected entities and their relationships based on the Level 3 and Level 4 patterns as a result of analysis done to determine what the SSFA solution targeted for the international community would require as an initial logical data model. The key data entities are CONTACT MECHANISM and GEOGRAPHIC BOUNDARY. CONTACT MECHANISM is the supertype for the different types of contact mechanisms, as shown in Figure 12, ELECTRONIC ADDRESS, TELECOM NUMBER and POSTAL ADDRESS. This model provides flexibility by allowing as many contact mechanisms as needed for a PARTY. Typically there are not many common attributes for the different types of contact mechanisms, but usually there exist many common relationships. In the Financial Services domain many types of contact mechanisms are related to entities such has PARTY, INVOICE and PAYMENT. Having a CONTACT MECHANISM supertype: 1. Helps to simplify the relationships that different contact mechanisms have to other entities 11 The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

34 Financial Services logical data model for Social Economy based on UDM / Allows for the grouping of all contact mechanism under one supertype to manage and simplify the relationships to contact mechanisms 3. Provides a place holder for new contact mechanisms 4. Allows for a more consistent way to maintain contact mechanism data. CONTACT MECHANISM TYPE like all TYPE entities contains a list of the different classifications for the entity, e.g. Telecom Number, Electronic Address and Postal Address. Each PARTY may be contacted via one or many PARTY CONTACT MECHANISMs. A PARTY CONTACT MECHANISM maybe used for one or more CONTACT MECHANISM PURPOSEs. That is, a person or an organization may use the same telephone number for both Business and Personal use. GEOGRAPHIC BOUNDARY maintains any type of encompassing area (or jurisdiction) such as but not limited to city, province, postal code, territory, region, country. Most enterprises and their employees function within some jurisdiction that is either created by some third party, e.g. a government demarcates a region, or the organization itself defines a sales territory. Figure 13: GEOGRAPHIC BOUNDARY Subtypes shows some of the possible different GEOGRAPHIC BOUNDARY subtypes. Figure 13: GEOGRAPHIC BOUNDARY Subtypes A CONTACT MECHANISM may be referencing one or more CONTACT MECHANISM BOUNDARY which are each for a GEOGRAPHIC BOUNDARY. The GEOGRAPHIC BOUNDARY subtypes are related to each other via the GEOGRAPHIC BOUNDARY ASSOCIATION entity. Each GEOGRAPHIC BOUNDARY may be from and to other GEOGRAPHIC BOUNDARYs through the GEOGRAPHIC BOUNDARY ASSOCIATION, e.g. COUNTRY Canada contains PROVINCE Quebec, hence considered a Province Country relationship in the GEOGRAPHIC BOUNDARY ASSOCIATION TYPE entity. Another example: from the POSTAL ADDRESS one can obtain the city from the associated GEOGRAPHIC BOUNDARY and use the GEOGRAPHIC BOUNDARY ASSOCIATION to relate the city to its province ( Bellville city is related to Quebec province) the province to the country ( Quebec province is related Canada Country). See Section CONTACT MECHANISM Data Examples for more data examples CONTACT MECHANISM Entities and Attributes See Appendix Section 15.3 Contact Mechanism Entities and Attributes, for descriptions of the entities and attributes.

35 Financial Services logical data model for Social Economy based on UDM / CONTACT MECHANISM Data Examples Table 5-4: CONTACT MECHANISM PURPOSE data examples PARTY. Party ID (Party Name) PARTY CONTACT MECHANISM. Contact Mechanism ID CONTACT MECHANISM 1001 (ACE Company) 0013 (David Blais) 0013(David Blais) 0013(David Blais) 0013(David Blais) 0013(David Blais) 0013(David Blais) 0042(Martin, Ray) CONTACT MECHANISM TYPE. Description CONTACT MECHANISM PURPOSE Baker street, suite 999, the Main building New York, NY, USA, Postal Address Main Office Baker street, suite 999, the Main Postal Address Office building New York, NY, USA, ave des Pins Postal Address Home residence Telephone Number Business Mobile Number Business Mobile Number Personal 435 David.blais@ace.com Address Business rue Rose, Belville, Quebec G1R 3W4 Postal Address Office Table 5-5: CONTACT MECHANISM and GEOGRAPHIC BOUNDARY data examples CONTACT MECHANISM. Contact Mechanism ID CONTACT MECHANISM (data based on the Contact Mechanism Type CONTACT MECHANISM BOUNDARY. Geographic Boundary ID (FK) GEOGRAPHIC BOUNDARY. Name from (TYPE) GEOGRAPHIC BOUNDARY. Name To (TYPE) GEOGRAPHIC BOUNDARY ASSOCIATION TYPE. Name() Baker street, suite 999, the Main building New York, NY, USA, rue Rose, Bellville, Quebec G1R 3W rue Rose, Bellville, Quebec G1R 3W New York (City) New York (State) City State Relationship New York (State) USA (country) State Country Relationship 2222 Bellville (City) Quebec City Province (Province) Relationship 1344 Bas St-Laurent (Region) Quebec (Province) Region Province Relationship

36 Financial Services logical data model for Social Economy based on UDM / 132 Table 5-6: CONTACT MECHANISM BOUNDARY data examples Contact Mechanism Boundary ID Contact Mechanism ID Geographic Boundary ID Notes: each CONTACT MECHANISM may reference one or more CONTACT MECHANISM BOUNDARY, which are each for a GEOGRAPHIC BOUNDARY CONTACT MECHANISM (100) City of New York CONTACT MECHANISM (522) City of Bellville CONTACT MECHANISM (522) Region Bas St-Laurent Table 5-7: GEOGRAPHIC BOUNDARY ASSOCIATION data examples Geographic Boundary Association ID Geographic Boundary ID From Geographic Boundary ID To Geographic Boundary Association Type ID Notes: Relates the one Geographic Boundary to another New York city to New York State New York state to USA country Bellville city to Quebec province Quebec province to Canada country Bas St-Laurent region to Quebec province Table 5-8: GEOGRAPHIC BOUNDARY data examples Geographic Geographic Name Abbreviation Boundary ID Boundary Type id 2002 City New York N.Y. 666 State New York NY 1020 State Iowa IA 2077 City Bellville Bellville 1122 Province Quebec PQ 1133 Country Canada Canada 1233 Region Mauricie Mauricie 1344 Region Bas St-Laurent Bas St-Laurent 1155 Country United States of America U.S.A. Table 5-9: GEOGRAPHIC BOUNDARY ASSOCIATION TYPE data examples Geographic Boundary Association Type ID Name 0010 City Province Relationship 0020 City State Relationship 0030 Province Country Relationship 0040 State Country Relationship 0050 Postal Code Province Relationship 0060 Region Province Relationship

37 Financial Services logical data model for Social Economy based on UDM / Communication Event Logical Data Model Contact Management includes the tracking of any communication exchanges between PARTYs be it via , phone call, fax or face-to-face meeting a log is kept to include information like the date and time, the originator and the purpose of the communication. current Lotus Notes application allows for linking any pertinent documents to the communication exchanges to provide a complete picture the communication for later access. The Universal Data Model refers to the contact or communication exchanges between PARTYs as a COMMUNICATION EVENT Communication Event Feature List See Appendix Section 15.4 Communication Event Feature List, for descriptions of features Communication Event Logical Data Model Following is the logical data model for Communication Event Management, using UDM as the base and modified slightly to address the needs of. Figure 14: COMMUNICATION EVENT logical data model diagram The COMMUNICATION EVENT entity maintains a history of the various communications or interactions that occur within the context of each PARTY RELATIONSHIP. The reason why COMMUNICATION EVENTs are maintained within the context of PARTY RELATIONSHIPs is because it is possible have many different relationships between parties, what an organization is interested in is the communication that occurs within a specific PARTY Relationship.

38 Financial Services logical data model for Social Economy based on UDM / 132 A COMMUNICATION EVENT is used to keep a log of the following methods of communication: FA COMMUNICATION, LETTER CORRESPONDENCE, FACE TO FACE COMMUNICATION, COMMUNICATION, PHONE COMMUNICATION, and WEB SITE COMMUNICATION. Should another mode of communication be required the model can easily be extended to include it. A COMMUNICATION EVENT takes place through one and only one CONTACT MECHANISM TYPE which describes the method of communication, the event it may have many COMMUNICATION EVENT PURPOSES, like for example a meeting could be for a FOLLOW-UP and an ANNUAL REVIEW. also requires that any documents discussed or prepared as a result of a COMMUNICATION EVENT be stored in their Document Management System and linked to the COMMUNICATION EVENT. The Chair fully expects as part of the SSFA solution, it must provide an interface of some form to a Document Management System to allow for various types of documents to be linked to more than one communication event. COMMUNICATION EVENT STATUS TYPE maintains the list of valid event statuses for example: scheduled, completed, cancelled, pending and in progress. Should a series of COMMUNICATION EVENTS be required for managing a particular issue, they may be grouped under a CASE. Each CASE may have several PARTYs involved and acting in different CASE ROLEs, for example, who is responsible for the CASE and who needs to provide some form of service to assist with the CASEs. For the communication events are within the context of a PROJECT hence the relationship between PROJECT and COMMUNICATION EVENT. At a COMMUNICATION EVENT pertains to one and only one PROJECT and may generate one or more INTERNAL TASKs to successfully complete the event. Note: PROJECT and INTERNAL TASK have been added to logical data model to support requirements. See Section 10 Work Effort Management for more details regarding PROJECT and INTERNAL TASK COMMUNICATION EVENT Entities and Attributes See Appendix Section 15.5 Communication Event Entities and Attributes, for descriptions of the entities and attributes COMMUNICATION EVENT Data Examples Table 5-10: COMMUNICATION EVENT data example Communication Event ID Work Effort ID Party ID from Party ID To Date Time Started Contact Mechanism Type Status ID 778 Project11 Mario Blue David Blais :30 Phone Completed 876 Project11 Mario Blue David Blais :30 Completed 465 Project11 Mario Blue David Blais :30 Face to Face Completed 522 CONTACT MECHANISM (location) ID

39 Financial Services logical data model for Social Economy based on UDM / 132 Table 5-11: COMMUNICATION EVENT PURPOSE data example Communications Event Purpose ID Communications Event Purpose Type Communication Event ID 332 Follow up Annual Review Invite Annual Review Payment Request 778 Table 5-12: COMMUNICATION EVENT and CASE data example CASE. CASE. Case ID Description 101 Project 11 Late Payment 101 Project11 Late Payment COMMUNICATION EVENT. Communication Event ID COMMUNICATION EVENT PURPOSE.. Communication Event Purpose ID Type Follow up Request Payment Phone Follow up Request Payment CONTACT MECHANISM TYPE. Contact Mechanism Type ID 5.5 Contact Management Observations and Findings This section provides some observations, findings and insights regarding the logical data models presented for Contact Management. First some general comments regarding the data models. After reviewing the data models it becomes quickly evident that although generic models do offer flexibility, they are not easy to understand, definitely not something a non IT professional can review and validate. As stated previously, the objective of this paper is to define generic flexible logical data models that can be used as the foundation for data structures to support a family of SSFA, the models are targeted to IT professionals who will be working to develop the software for the Chair. The data models produced are based on the analysis of only one social economy Financial Services organization which is the Quebec based organization,, and the body of work described in Len Silverton s books on Universal Data Models. The Universal Data Models describe several alternative patterns to model a particular business problem. The ideal model is the simplest data model that supports all the business needs. What makes it challenging when building a generic data model for a business domain where the modeller is not a domain experts, and a full set of requirements does not exists, is what to base the decisions to model one way versus another way. For this reason these models must be viewed as starting point data models, which have has objective to allow for as much flexibility, and ability to extend the data structures given the fact that the solution application is targeted for many Financial Services social economy organizations with varying needs People and Organization An organization like does not need the complexity of entities PARTY ROLE and PARTY RELATIONSHIP. FILACTION does not currently maintain information at this level, and most likely will not need to in the future. These entities which are defined in the UDM are included in the SSFA logical data model because one can see the value in the flexibility they offer and that other Financial Services organizations may want to maintain this type of data.

40 Financial Services logical data model for Social Economy based on UDM / 132 A PARTY may play more than one role in an organization, which is the case with, an organization may play the role of a PARTNER for one PROJECT and CUSTOMER for another PROJECT, does not keep additional attributes regarding the ROLE but it is highly likely that some other Financial Services organization may need to. There are several ways to modeling a PRINCIPLE CONTACT for an organization as required by, who also requires that no more than one principle contact must exist for a Society. The choices are 1. Make CONTACT and PRINCIPLE CONTACT subtypes of PARTY ROLE and create an ORG PRINCIPLE CONTACT RELATIONSHIP to maintain information regarding the CONTACT and its ORGANIZATION. 2. Create only a CONTACT subtype entity for PARTY ROLE and include an attribute called principle contact of format Boolean, in the CONTACT entity. Method 1 makes more sense since it best describes the role of the contact as a Principle Contact, it also allows in the future for additional attributes to be included in the PRINCIPLE CONTACT entity if ever an organization wants to keep additional information regarding their principle contacts. Once again it is an issue of what are the requirements. The UDM describes additional entities such as PARTY CLASSIFICATION with its subtypes of ORGANIZATION CLASSIFICATION and PERSON CLASSIFICATION with each of these having their own subtypes like INDUSTRY CLASSIFICATION as a subtype for ORGANIZATION CLASSIFICATION. At this point there are not enough requirements to include these entities in the logical data model, hence the decision to only include the PARTY TYPE entity for classifying the PARTY. This entity allows for identifying organization based on industry or size for example in the case of they would be interested in classifying their LOCAL DEVELOPMENT FUNDS by minority owned business, woman owned business, women shelter. Suffice to say that should the business domain require more complex data structure to maintain information based on the classification of PARTY the model could easily be extended to include PARTY CLASSIFICATION entities Contact Mechanism The data model presented for CONTACT MECHANISM is fairly complex for satisfying a simple need like maintaining address information. The main advantages the CONTACT MECHANISM model presented is that it allows for the fact that there are many ways of contacting a party, and that different types of contact information is maintained in a consistent way, this should make maintaining contact data easier and allow for better data quality and easier access to data. The model is also flexible in that a new means of contact can easily be supported. Given that SSFA will need to maintain international addresses, entities from the UDM such as GEOGRAPHIC BOUNDARY and GEOGRAPHIC BOUNDARY ASSOCIATION where included in the data model. The UDM provides an even more generic CONTACT MECHANISM model, which is far more generalized and as a result more complex to understand. The model presented in this paper is a good starting point for Contact Mechanism, if after further analysis of other Financial Services organization requirements dictate that additional data structures are included the proposed model can be extended. Note: If SSFA data structures are modified or extended, after an organization has implemented SSFA, a data migration utility should be provided by the developers of the software to migrate existing data to the new data structure.

41 Financial Services logical data model for Social Economy based on UDM / 132 Through the CONTACT MECHANISM USAGE TYPE entity the model provides for the classification of the contact mechanism such as Business, Personal, Mobile, Home, Office as required by which the current application only supports a maximum 2 types of addresses for an organization. The logical data model presented does not support the formatting or address presentation which varies from country to country. The UDM provides a much more complex data model that could help to support different address presentation needs using an entity called POSTAL ADDRESS PART 12. After spending many hours analyzing the proposed UDM model it was found to be far too complex to completely understand it. The proposed UDM adds a level of complexity and flexibility that is confusing and could lead to poor implementation and eventually lead to data quality issues. Should the business need arise and one is able to justify adding such complexity including building a user interface to capture the data and the correct data structure, it is suffice to say the UDM does provide a data model for maintaining flexible international address presentation structures Communication Event The model for communication event includes the entity COMMUNICATIONS EVENT PURPOSE; requirements do not justify such an entity since it does not keep specific information on the purpose of the communication event. Replacing COMMUNICATIONS EVENT PURPOSE and COMMUNICATIONS EVENT PURPOSE TYPE with only a COMMUNICATION EVENT TYPE entity would meet the requirements; the more complex data structure was adopted to allow for flexibility. The UDM proposes a COMMUNICATION EVENT ROLE which maintains the role that each party plays during an event, e.g. caller, receiver, minute taker and facilitator. This is deemed too complex a data structure for the need, this type of information can be included in the text field attribute notes or the attribute Other Participants in the entities FACE TO FACE COMMUNICATION and PHONE COMMUNICATION. If after further analysis of other Financial Services organization the need for an EVENT ROLE entity is required the model can easily be extended. 12 Details regarding Contact Mechanism with Flexible Address Parts Pattern can be found on page 391 of The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

42 Financial Services logical data model for Social Economy based on UDM / Financial Product Management The Financial Services industry like any other industries exists because it provides some kind of goods to potential customers. In the case of Financial Services the goods it provides are mainly services (nontangible), the services have very specific conditions and arrangements for which both the Financial Institution and the customer must abide by, if not penalties may be incurred. Product Management is the Functional Area that addresses the design, definition and cataloguing of the financial service and products offered. For a particular type of financial service, e.g. loans, there are typically different types of loan products, each designed with specific features like interest rate calculations, repayment terms, collateral requirements and in some cases even choice of currency. A financial service may be a predefined service or set of services with specific arrangements offered to many customers or a customized service (or set of services) for a specific customer. Defining the various products and their features with the different combination of parameters can be a daunting task. Developing software targeting the social economy to support Product Management is even more challenging since different Financial Services organizations support a much wider variety of services; one needs just look at the variety of services offered by the funding partners of AI2L as described in the Section 1 Introduction of this paper. This means that a financial services application must allow for highly flexible and customizable product definition, a fluid or adaptable data structure becomes an important element to support this requirement. 6.1 Financial Product Management Following is a list of the types of products/services offers to Local Development Funds and other enterprises: 1. Loans with different types of features: e.g. repayment schedules with different payment frequencies, varying grace periods, and seasonal payments (e.g. customer makes payments only during the summer months). 2. Purchasing share: where will buy shares from the Society. In this case no payment schedule is required, may charge monitoring fees and bonus fees for this service 3. Debentures: are like a loan with a payment schedule where if after a specified period the borrower is not able to pay back the loan, will purchase company shares from the customer on the remaining amount owned. 4. Revolving loan (also known as an open-end credit): a loan with a specific end date that allows the amount to be repaid and borrowed once again within specified date. also has a number of different fees it may collect from its customer: 1. Guarantee fee: example, a Local Development Fund or enterprise takes a loan from Caisse Desjardins and guarantees the loan. charges a fee for the grantee. 2. Performance fee: where charges a percentage based on the borrowers profits. 3. Late Payment fee: the borrower is charged a fee for late payments. The current Lotus Notes application does not support designing and the definition of a product and its features, this activity is done manually. The logical data model for Product Management is based on UDM and therefore needs to be validated with other social economy Financial Services organizations.

43 Financial Services logical data model for Social Economy based on UDM / Financial Product Management Feature List See Appendix Section 16.1 Product Management Feature List, for descriptions of features. 6.3 Financial Product Management Logical Data Model Figure 15: Financial Product Management logical data model diagram A Financial Services organization may offer a variety of products; these products are typically classified by PRODUCT CATEGORY. In this model only two subtypes of PRODUCT CATEGORY are show; INVESTMENT VEHICLE and LOAN PRODUCT since this represents the scope of products. Other examples of PRODUCT CATEGORY are savings, credit card and insurance. The FINANCIAL PRODUCT indicates how the services provided to the customer will behave. A FINANCIAL PRODUCT has a number of PRODUCT FEATURES and FUNCTIONAL SETTINGS that may apply when a product is defined in an agreement/contract. The FEATURE APPLICABILITY and FUNCTIONAL SETTING APPLICABILITY identify the specific features and settings that apply to the FINANCIAL PRODUCT in question. These four entities (PRODUCT FEATURES, FUNCTIONAL SETTINGS, FEATURE APPLICABILITY and FUNCTIONAL SETTING APPLICABILITY) define how a product works, allow for customizing a product offering. 6.4 Financial Product Management Entities and Attributes See Appendix Section 16.2 Product Management Entities and Attributes, for descriptions of the entities and attributes.

44 Financial Services logical data model for Social Economy based on UDM / Financial Product Management Data Examples Table 6-1: PRODUCT FEATURE and FUNCTIONAL SETTING relationship examples PRODUCT FEATURE description FUNCTIONAL SETTING description Monthly interest rate Apply interest rate at end of month Statement Prepare statement every 30 days Payment mode Electronic payment Repayment schedule Monthly payments Non sufficient funds fee Apply fee when account balance goes below zero Performance fee Apply performance fee based on borrower s annual sales profits Guarantee fee Apply fee for guaranteeing a bank loan Table 6-2 FINANCIAL PRODUCT data example FINANCIAL PRODUCT. ID FINANCIAL PRODUCT. Name PRODUCT FEATURE. Description PRODUCT FEATURE APPLICABILITY. value 11 Regular Loan Base Interest Rate Prime Interest Rate PRODUCT FEATURE APPLICABILITY. From Date Contract open date PRODUCT FEATURE APPLICABILITY. Thru Date 12 months after disbursement date Contract end date Last date on payment schedule FUNCTIONAL SETTING APPLICABILITY. Description apply interest rate at end of month 11 Fixed Interest Rate 1.5% Contract open date apply interest rate at end of month 11 Repayment 1rst date on due monthly Payment schedule 11 Grace Period 3 period to apply after disbursement 22 Revolving Base Interest Prime Interest Contract open Contract end apply interest rate at Loan Rate Rate date date end of month 22 Fixed Interest 2% Contract open Contract end apply interest rate at Rate date date end of month 22 Payment any time before end of contract The PRODUCT FUNCTIONAL SETTING APPLICABILITY indicates which FUNCTIONAL SETTINGs apply to which specific FINANCIAL PRODUCTs as part of the design of the product offering In the above example is based on two of products. For a Regular Loan a borrower is expected to make monthly payments, the interest rate is calculated based on the prime rate which is set by the Central Bank of Canada on the anniversary date of the disbursement plus a fixed interest rate set at the time of the contract and valid until the end of the contract. For a Revolving Loan the interest rate is calculated based on the prime rate plus a fixed interest rate set at the time of the contract and valid until the end of the contract. Payments (including full payment) can be made any time before the end of the contract.

45 Financial Services logical data model for Social Economy based on UDM / Financial Product Management Observations and Findings does offer a handful of products/services surrounding loans. Lotus Notes application system does not support the design and definition of the products. The products are defined manually and the software application is used in a rather crude way to identify which service is being provided to a customer. There is no doubt that a data structure is required to support the definition and maintenance of various products a Financial Services organizations may offer to its customers, the logical data model seems to provide a good starting point to allow for the support of defining various features and varying parameters in a product. More requirements and analysis are required to determine the quality and how easily the model can be implemented. The data model is quite complex since it is intended to support the complexity of business rules needed to identify which feature and which parameter setting apply for a given product. Given the complexity of the proposed UDM model and the importance of the Product Management functional area, it is strongly suggested that the Chair conduct further studies to determine if this specific functional area would greatly benefit from using a business rules engine for the definition, maintenance and applicability of product business rules. 6.6 Financial Product Regulations and Rules Management Analysis of current system has not expressed a need for a Product Regulations and Rules logical data model. The belief is that since the open source software that the Chair will be developing is targeting the international market, and since the Financial Industry is highly regulated, in most countries, there will be a set of governmental, or standards body with regulations and rules that the Financial Services organizations which need to abide by. It is expected these regulations and rules will impact how a financial product will function, and what may and may not be offered as a product or service. The Universal Data Models includes a very generic model for Financial Products Regulation and Rules 13, which may be useful for the chair to consider once the requirements for financial product regulations and rules are better understood. The model has also been included in this paper to show the relationship between the financial product regulations and rules and the entities FINANCIAL PRODUCT, PRODUCT FEATURE and PRODUCT SETTING described in section 6.3 Financial Product Management Logical Data Model. Financial Products Regulation and Rules consists of regulation requirements that a financial services organization needs to follow. These regulation requirements affect what features and functional settings may be available for a financial product, and dictate what FUNCTIONAL SETTING APPLICABILITY or PRODUCT APPLICABILITY may be applied to FINANCIAL PRODUCTS. 13 Page 273 The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

46 Financial Services logical data model for Social Economy based on UDM / Financial Product Regulations and Rules Management Logical Data Model Figure 16: Financial Product Regulations and Rules Management logical data model diagram 14 REGULATION REQUIREMENTS are the statements of understanding of what the Financial Services organization needs to follow. A FINANCIAL REGULATION may be a requirement governed by external agencies or the Financial Services organization itself. The model shows two subtypes for FINANCIAL REGULATION: GOVERNMENT REGULATION: are external regulation imposed by different levels of governmental bodies (e.g. federal, state and local bodies). ORGANIZATION REGULATION: are defined by the financial services organization and enforced by management. FINANCIAL REGULATIONs and associated REGULATION REQUIREMENTs impose FINANCIAL PRODUCT RULEs that impact FINANCIAL PRODUCTs, PRODUCT FEATUREs and/or FUNCTIONAL SETTINGS. AGREEMENT TERMS that were negotiated with customers may also impose FINANCIAL PRODUCT RULES that affect the same entities. See Section 7 Financial Agreement Management. 6.8 Financial Product Regulations and Rules Management Entities and Attributes See Appendix Section 16.3 Financial Product Regulations and Rules Management Entities and Attributes, for descriptions of the entities and attributes. 14 Source: p 274, Figure 6.4 Financial product regulations and rules. The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]