Purpose of this guideline: The purpose of this guideline is to provide a planning framework that will help organizations create and use the appropriate models throughout information resource development phases.
Scope of this guideline: The scope of this guideline includes:
The scope of this guideline does not include:
Audience: The audience for this guideline comprises Minnesota government organization business managers, CIOs or equivalents, information resource steering committee members, and other persons involved in information resource development.
A context diagram is a graphical or text representation, usually of processes or data, that follows the general diagramming conventions for the model type it represents, but shows only the highest level objects that are within the scope of interest. For example, a process context diagram might represent functions and information flows between functions, but not break them down into lower level processes. A data context diagram might identify only the major entities and relationships to help depict the general subject areas of interest.
Data model, conceptual
A conceptual data model represents a business view of an organization's data. This model is made up of a diagram and its supporting documentation (text). A conceptual data model contains entities and relationships that the business cares about. Supporting documentation includes detailed definitions of entities and relationships. A conceptual data model may be oriented more toward a "business object" view or a "data structure" view and may be represented by more than one type of diagram. An entity relationship diagram (ERD) is an example of a diagram used to represent the "business object" view. Either an ERD or a data structure diagram (DSD) may be used to represent a "data structure" view.
Data model, logical
A logical data model is a transformation of the conceptual data model to reflect data structure considerations. A logical data model is made up of a diagram and its supporting documentation. The diagram for a logical data model contains entities, relationships and attributes from a data perspective (also known as a "fully attributed data model"). Supporting documentation includes complete definitions of entities, relationships and attributes along with enough detail for database administrators to develop a physical data model and a database design. A data structure diagram (DSD) is an example of a diagram used to represent a logical data model.
Entity relationship diagram (ERD)
A entity relationship diagram is a modeling convention that shows entities, relationships, attributes (or data elements) and cardinality. An entity relationship diagram is typically used to reflect business data, or data structures (see data model, conceptual in this section).
An event model shows a business view of the events to which an organization, or its information resources, must respond. An event model is made up of a diagram and supporting documentation. The diagram contains important business events, the before and after "states" of entities that are affected by the events, and business, system or processing activities triggered as a result of the events. A State Transition Diagram (STD) is an example of a modeling convention used for this purpose.
Event model, logical
A logical event model is a transformation of the (business view) event model to include implementation considerations and processing/system events.
Models of technology alternatives
Models of technology alternatives are the result of technology analysis, depicted in model form. There is no specified diagram type for technology models, however diagrams should depict the technologies being considered, their functions, their relationship to other technologies and supporting documentation. Supporting documentation should include feasibility studies, options considered and the comparative analysis between the options.
Physical models (data, event, process, technology)
Physical models are produced in the construction phase and are outside the scope of this guideline.
Plans and requirements for model development
Plans and requirements for model development identify the strategy and steps that an organization will use to create models, along with the organization's modeling requirements if they have been determined. Modeling requirements include, at a minimum: 1) standards for model notation and diagramming conventions, 2) naming standards for model objects, 3) content of supporting documentation (for each type of model), and 4) identification of other (i.e., statewide) standards that apply.
A process model shows an organization's functions / processes and the information (or data) created or used by them. A process model is made up of a diagram and its supporting documentation. Supporting documentation includes complete definitions of processes and documents the data created or used by them. A "data flow diagram" (DFD) is an example of a diagram used to represent a process model. (see process model, current essential; process model, new essential; process model, new logical in this section.)
Process model, current essential
A current essential process model contains only the portion of the current processes and data created or used by them that are essential to the core functions. A current essential process model is usually created by reducing models of the existing processes to their bare essence. This is accomplished by removing such things as policies and rules, implementation constraints and activities that are not essential to the core functions. Supporting documentation for a current essential process model includes complete definitions of processes, the data created or used by them, and complete (separate) documentation of what was removed during the transformation to current essential.
For example, a process that compares invoices to incoming customer payments represents a policy that is not essential to the functions of accounts receivable, and is also a specific implementation of quality control policies. Therefore it would be removed when creating a current essential model, but would be maintained in the supporting documentation.
Process model, new essential
A new essential process model contains both the current and the new processes and information created or used by them that are essential to the core functions. A new essential process model is created by adding new functions or processes to a current essential process model. Like the current essential model, the new essential model still reflects only essential processes without policy or implementation constraints. Supporting documentation for a new essential process model includes complete definitions of processes and the data created or used by them, plus still includes the complete (separate) documentation of what was removed during the transformation to current essential.
For example, if the accounts receivable function is being expanded to include establishing customer accounts, the new essential model would also be enhanced to add the new essential processes and information flows. However policies, non-essential processes and implementation constraints would not be added at the essential level. Therefore processes for approving credit would not be included, nor would a policy that the customer had to have an account representative assigned.
Process model, new logical
A new logical process model, transformed from the new essential process model, contains appropriate new and existing policies and processes. The new logical process model should contain all new mandated and desirable policies and processes, plus any existing policies and processes that were removed during conversion of the model to current essential and that are determined still to be valid. Supporting documentation for a new essential process model includes complete definitions of processes, the data created or used by them, plus documentation of what was removed during the transformation to current essential and not added back.
For example, the accounts receivable function that is expanded to include establishing customer accounts would include, in the new logical model, policy-derived processes for approving credit and requiring that the customer have an account representative assigned.
Project driver events
Project driver events are those events that significantly affect the requirements for the resources being developed. For example, if the legislature mandates a new application to track and report arrests of juveniles carrying weapons, the arrest of juveniles carrying weapons becomes a project driver event for the new application resource.
Year 2000 event horizon
An information resource's "event horizon" is the latest future date that will be processed or handled by an information resource. The Year 2000 Event Horizon is the date by which a resource must be "Year 2000 compliant" before its date processing fails.
For example, if an application calculates expiration dates two years into the future, its "event horizon" is always a date two years from the present date. Its "Year 2000 event horizon" would require the application to be compliant and tested two years before January 1, 2000, or no later than January 1, 1998.
The matrix on the following pages identifies the appropriate model types that are inputs and outputs for four information resource development phases: define and plan project, analyze project requirements, design information resource, and construct information resource.
The matrix is organized to show the four phases as discrete modules. In fact, proposed projects often include more than one of the phases or modules. For example, an organization may propose a project that will include all the phases: define and plan; analyze project requirements; and design and construct information resources. In this case, the organization should identify the inputs necessary for the first development phase and make plans to produce the outputs for subsequent phases. (see definition of plans and requirements for model development in the definition section of this guideline.)
If a project's scope addresses a subset of the models and is aligned with the organization's strategic information resource plan, the project will not necessarily create models in all categories. For example, an organization proposing a project to create an organization-wide data model will not necessarily create a process or event model as part of that project.
Organization-wide models represent strategic directions for information resources and provide an organization-wide view of information resources. Ideally, each new project would build on existing organization-wide models created during strategic business planning. However, if organization-wide models do not exist they should not be created solely for use in a particular project if they would not add value to the project or might serve to delay its completion.
If organization-wide models do exist, project planners determine which models are appropriate for the project and which portions of the models represent resources that will be developed. Here the organization-wide models are used as input to defining project scope. If organization models do not exist, the portions relevant to the project do need to be created before the project scope can be finalized and the project can begin. For example, a project would not need to complete an entire organization wide data model in order to begin, but needs to develop a data context diagram that encompasses the project's scope.
Ideally, opportunities for reengineering business processes are identified in the context of business reengineering efforts carried out in the business units. The results of business process reengineering become input to the "define and plan project" phase.
|Define and plan project||Analyze project requirements||Design information resources||Construct information resources|
|Data Models||Input to this phase:
||Input to this phase:
||Input to this phase:
||Input to this phase:
|Process Models||Input to this phase:
||Input to this phase:
||Input to this phase:
||Input to this phase:
|Event Models||Output of this phase:
||Input to this phase:
||Input to this phase:
|Tech Models||(For technology infrastructure projects)Input to this phase
||(For technology infrastructure projects) Input to this phase:
||(For all projects) Input to this phase:
||Input to this phase:
Resources available within your own organization
Over 100 employees of state government organizations have received training in data, process and event modeling. The expertise you seek may be within your own organization.
Resources available from the Minnesota Office of Technology
The documents listed below relate to information resource modeling, modeling prerequisites, or potentially relevant standards.
"Annotated Reproduction of Minnesota Statutes Chapter 13 - Unofficial" (and other materials related to Minnesota Government Data Practices Act) (available from the Department of Administration, Technology Management Bureau, Public Information Policy Analysis Division) Telephone(612)296-5643, Fax (612)296-5800
Statewide IRM policy #10 related to information resource models Statewide Open Standards for Information Systems Statewide Policy on Technical Standards IRM Guideline 2:Information Resource Models: Creation and Use IRM Guideline 3:CASE Tools: Selection and Use IRM Guideline 9:Data Administration: Data Naming Primer IRM Guideline 10:Data Administration: Data Naming Practitioner's Guide IRM Guideline 11:Data Administration: Entity Relationship Models: Evaluating Content and Quality
Resources available from other state agencies
The following individuals from Minnesota government agencies have experience with modeling projects and have agreed to answer questions about modeling and / or their agency's projects.
|Name||Department/Title||Phone # / E-Mail||Project Details|
|Karl Olmstead||Dept of Transportation, Information Planning Manager||(612)296-9347 firstname.lastname@example.org||Enterprise-wide modeling project: project duration: 15 months. Included Functional Decomposition, Conceptual Data Model, Business Location Model, Technology Statement of Direction, inventory of legacy systems and data, and a long term implementation plan with 120 development projects scoped in terms of the models.|
|Dru Moeding||Department of Economic Security, Project manager||(612) 297-3452 email@example.com||Project-level modeling project: Tax System Redesign project. Included Event Model, Object (Data) Model, Process Model and Location Model, plus a Socio-Political Sketch.|
|Ann Bidwell||Minnesota Pollution Control Agency, Data Administrator||(612) 297-1605 firstname.lastname@example.org||Enterprise-wide master data model: (organizations, sites, etc.) Project DELTA.|
|Karen Buskey||Supreme Court and Criminal Justice Data Group, Research and Technology Office; Systems Services Manager||(612) 297-7638 email@example.com||Enterprise-wide master data model project managed by Criminal Justice Data Group representing wide variety of community perspectives. Project took approximately nine months, resulted in model that is used as a "blueprint" for development of shared information resources.|
Contracting for Modeling Expertise
Organizations may use existing Master ("M") Contracts, including the OET Master Contract for Professional/Technical Services, for help with modeling.
If your organization knows of a specific individual with information resource modeling expertise whose firm is approved under a Master Contract, you may contract directly with the individual and firm. If you do not have a particular individual in mind, a general notice may be sent to approved firms asking them to propose individuals who are available and meet your agency's needs. This approach is coordinated through Barbara Clark, 651-201-1067.
If your organization is unable to find the specific model development skills you need through existing Master Contracts, you may also develop your own requests for proposals for modeling expertise. In either case, you should be as specific as possible about the project requirements, deliverables, time frames and skills needed.
Your organization is more likely to secure the services of an appropriate contractor if the notice or RFP includes:
In addition, the following should be considered for inclusion in the contract or Statement of Work:
Courses and seminars
Courses and seminars that address modeling are also available, and may be advertised by providers under several categories, such as:
Courses and seminars are most often available through private organizations that sponsor continuing professional development education. Specialty conferences in related subject areas often include sessions on modeling as well. Examples include conferences on "Repositories" or "Data Warehousing". Typically colleges and universities that address modeling do so within other course subjects, such as "Systems Analysis", rather than addressing modeling as an area of study.
Other sources for modeling education include professional organizations, such as DAMA, the Data Management Association. The State of Minnesota belongs to DAMA International's local chapter (Minnesota). The chapter's current V.P. of Education is Dawn Michels (612) 223-4067. (see homepage reference below.)
This is the homepage of the Data Management Association, the international not-for-profit affiliation of local and regional chapters consisting of thousands data management professionals. Each chapter holds regular educational seminars and publishes its own chapter newsletter. The site is the location of many useful resources, including a bibliography.
Links to information about standards for data and process models The agenda located at "http://elib.cme.nist.gov/workshop/jtc1-96/jsw-agen.htm" for the "Joint Workshop on Standards for the use of Models that Define the Data and Processes of Information Systems" includes links to the text of several informative papers, including "Fundamentals of Data and Process Modelling" by Dr. T. William Olle, Surrey, England and "Towards Knowledge Representation: The State of Data and Processing Modeling Standards" by Anthony K. Sarris, Ontek Corporation.
Report on software design methods
References to modeling in the context of a comprehensive review of the status of software design, can be found in "A State of the Art Report: Software Design Methods". The report was researched and published by the Data & Analysis Center for Software (DACS). The DACS is a Department of Defense Information Analysis Center (IAC) whose mission is to support the development, testing, validation, distribution and use of software engineering technologies. The DACS is operated by Kaman Sciences Corporation of Utica, New York under the sponsorship of the Defense Technical Information Center (DTIC), Alexandria, Virginia.
An on-line course in object-oriented methods
Sections of "Object-oriented Methods", a copyrighted on-line course by David L. March are still under construction but the material there, including a bibliography, is valuable and easy to navigate. Concepts and themes relevant to modeling information resources are covered along with clear definitions and useful graphics. (Educators and students are welcome to use this material for educational purposes only. Republication or use for commercial purposes is prohibited without the express consent of the author.)
© Copyright 2013 MN.IT Services - State of Minnesota