Project Delivery Process D170

Blog: Biz-Performance, David Brown

D170 – Data Modelling

DEFINITION

Build and/or maintain data dictionary and/or data model.

SUMMARY

A data model may be produced to show the data and the relationships between the various data entities involved in the business solution. This may be at a high summary level, or at a detailed level depending on the wishes of the client organisation and the needs of the project team. Some or all of the model may already exist as a result of:

work done during the requirements and selection segments,
the client organisation’s pre-existing enterprise data models, or
standard models reflecting the structure of the chosen packages.

In general Application Software Implementation Projects do not require that a full data model be created. Most modern packages have internal data dictionaries sufficient for their own needs, and several have published data models electronically or on paper. This process may be required:

to check whether the chosen package will provide the needed coverage of data items to fulfill the client organisation’s needs,
to define which possible amendments have to be made to the standard model for the package,
where there is an external need for a data model or data dictionary, e.g. because the data will be integrated in a corporate database, or
simply because it is normal practice within the organisation.

Normally a formal approach would be used, either using the approach as used within the specific package, or a general approach depending on the organisation’s normal practice.

PATH PLANNING GUIDANCE

Optional – may be used where required by the client, or where the technical solution is part of a larger database, or where an enterprise data model is in use.

DEPENDENCIES

Prerequisites (Finish-Start):

Delivery Approach Definition (DAD) or similar high-level definition of the design.

Prerequisites (Finish-Finish):

all data-related aspects of the design should be completed before the data model can be considered fixed and final.

Dependent procedures (Start-Start):

design of data-related aspects of the system should be performed with the benefit of the provisional data model.

RECEIVABLES

Delivery Approach Definition (DAD) or similar definition of high-level design
Current corporate/enterprise Data Model or Data Dictionary (if any)
Data dictionary, data definitions or data models supplied with the package (if any)

DELIVERABLES

Data Model (DM) – new or updated – as required
Data Dictionary (DD) – new or updated – as required
Updates to the package’s standard data model facility
Statement of differences in standard package model to client organisation’s desired model

TOOLS

Guidelines: Modelling Techniques

DETAILED DESCRIPTION OF TASKS

Using a data model or data dictionary

Data models and data dictionaries are methods used to record the precise nature of data (including its format, use, ownership etc) and the relationship between items of data. They are frequently used in custom-developed systems, particularly where the application uses a database. Having a clear, controlled definition of the corporate data is essential to ensure the coherence and integrity of parts of a system. Where integrated solutions are used, they are of even greater value in ensuring the coherence of all the individual components.

The exact format of a data model or data dictionary will depend on its origin, however, typically, data models are shown in the form of “entities” and “relationships” in an “Entity/Relationship” model otherwise known as a Bachmann diagram after its originator. Most methodologies use a version of this style of diagram, although they will normally show cosmetic differences and be known by different names. A data dictionary is more frequently in the format of a table in alpha-numeric sequence listing all recorded types of data plus the data attributes. It can normally be used to introduce data definitions automatically into programs and other accesses to data.

In a simple package-focused implementation the data design of the application is often fixed at a technical level and straightforward at the business function level. It is often of limited benefit to produce or use data models or data dictionaries in such cases. It is important that the Project Team does not waste time in data modelling where there will be no particular benefit derived from it.

It may be important to check whether “knockout” mandatory and business critical requirements can be fulfilled with a specific package. The needs for specific data should be looked at carefully to ensure that they result from actual business needs and not just from current business practices or arbitrary aspects of data analysis and design.

In some packages the data model used in the application can be customised individually to the client organisation’s needs. The package will then provide an integrated environment to maintain data definitions and specify at which places data will be used. By using a data dictionary, individual amendments can be added to the standard data model provided.

Reasons for using data modelling techniques may include:

required by the client due to internal standards,
the package has to be customised to provide the essential functionality,
where the overall solution will be formed by several integrated components, only some of which are packages,
where the technical solution uses, or is part of, a larger corporate database and overall control must be maintained,
where an enterprise data model is in use to maintain a high-level view of how the organisation is composed in terms of data.

Levels of modelling

There are different levels (ie degrees of detail) at which data modelling may be performed. Different levels serve different purposes.

High-level data models concentrating on key corporate data are used for high-level business process design. They allow an overall view of the organisation to be described in terms of its data.

Detailed data models may show every aspect of every item of data. This is unlikely to be of benefit unless required for the integration of databases or for detailed programming purposes.

Data models can be used to show the current picture, ie the starting point for the project, or to document the designs for the new system.

Data dictionaries normally contain detailed definitions of data format and usage. They allow the precise definition of how data is accessed and used. They can be used both as a design documentation aid and as a development aid as they will normally be used automatically by the software, saving coding time and ensuring consistent definition of the data structures. For example, a data dictionary provides data definitions for:

table structures
single data items like data fields including a separate help text which explains the meaning and technical format of the data item,
domains which contain common characteristics of a group of data items (eg all cost centres have common characteristics).

Method

Where data modelling is to be used, there will normally be some existing techniques already in use – either within the client organisation or as used by the package supplier. Accordingly, the best method will normally be decided by the Project Team based upon the approach most beneficial and/or appropriate for the Project. Such decisions should be agreed with the client organisation, especially the MIS department, preferably before the project starts as part of the Path Planning / Segment Planning processes.

The techniques used will normally be drawn from a recognised systems analysis methodology such as SSADM (the UK’s government standard approach), Merise (the French standard approach), or a package-specific approach.

Typical uses of a data model or data dictionary during the Application Software Implementation Project process might be:

Requirements

as a record of the structure of the existing systems and data
to document how data needs to be structured in the new system (nb – this should be restricted to genuine logical needs and not be used to specify specific physical design approaches)

Selection

to compare the data structures of the proposed solutions against the client organisation’s needs

Implementation Strategy and Delivery Approach Definition (DAD)

High-level definition of existing corporate data model
High-level definition of required data model

During a design and development

Analysis of existing systems
Design of target system(s) including integration / relationships between systems
Documentation of designs / database etc
For use in freestanding enquiry facilities or reporting tools (eg SQL enquiry)