Return to the Integrated Systems Project Home
Integrated System Definition
Last Update: August 6, 1996
This definition of an Integrated System identifies characteristics
arranged in the broad categories of Data Issues, Application
Issues, Presentation Issues, and Operational Issues. A brief
name of the characteristic is given, followed by a paragraph defining
the characteristic. While the degree of integration is likely to vary
from product to product, an ideal integrated system would have all of
the characteristics listed below.
- Common Data Model A single data model and
database support system is used by all components of the system.
For example, the same data model should be used by both the
Student and Human Resource components in the system.
- Common Definitions Every data element should have
a common definition throughout the system. For example,
address information should have common, consistent definitions
throughout all components.
- Single Collection Point Input from a single
component should be reflected throughout the system.
Multiple entries of the same piece of information should be
- Universal Availability Once data is input from a
single component, it should be available throughout the system.
For example, address changes from the Human Resource
component should be available in the Student component if the
student is also an employee.
- Consistent Naming Conventions for Data Elements
Certain information about the data element should be
intuitively obvious from the name of the element, and the name
should be used consistently throughout to reference the data
element. For example, whether an element is a code, a flag,
or a monetary amount should be obvious from the name.
- Common Data Dictionary A single data dictionary
should contain information about the data elements. It
should be readily available to users of the system.
- Derived Values Transfer Between Modules Any
information derived from the base data should be consistent
between application areas. For example, if age is derived
from birthdate, this derivation should be consistent throughout
- Minimum Reconciliation Required to Ensure Data
Integrity The need to reconcile reports from different
components in the system should be minimized. For example,
tuition information based on student registration should be
reliably reflected in the accounts receivable components.
- Consistent Customization Tools and Techniques The
system should provide consistent tools for customization in all
components. For example, if a screen painter is used for
customization in the accounting system, it should also be used in
the registration system. This would also apply to any
tables, code generators, or development languages used to
customize the system.
- Code Shared Among Modules In order to minimize
redundancy, code should be shared to the greatest degree possible
between components. For example, date calculation routines
should be common to all components in the system. This should
facilitate making changes in a single location and propagating
throughout the system.
- Shared Business Rules The system should allow us
to easily define business rules which have an impact throughout
the system. For example, if the year designation for
a student is defined based on the number of hours of study
completed, this rule should be easily stated in a single location
in the system. As much as possible, business rules should be
updateable by non-computer professionals. For example,
tables might be used to store common business rules. Special
administrative "front-end" programs might also be used to allow
specification of business rules.
- Consistent Headings on Screens and Reports Users
of the system should see the same names consistently on screens
and reports. For example, the term "Student ID" should be
consistently defined and used anywhere the user interacts with the
- Consistent Navigation All components should use
consistent navigation features to increase operator efficiency.
For example, if one component uses menu bars and shortcut
icons, all components should use similar menu bars and shortcut
- Consistent Look and Feel for Screens and Reports
Screens and reports should have similar organization in
presentation of the data. For example, headings should be
consistent in identifying the component producing the report and
the location of key data within the heading.
- Single Authentication Components should avoid
multiple requests for a user id and password combination.
Once a session has been authorized, this authorization
should remain in effect regardless of the component used.
- Single Security and Rights Administration User
ids should be administered from a single point. For example,
adding a new user should be performed only once, not once per
- Consistent Interface to External Environment The
system should provide mechanisms to interact with the underlying
operating system of the client machine. For example,
consistent mechanisms to interface with Microsoft Excel or other
spreadsheet packages should be available from within the
- Implementation of New Releases of Components Handled
Consistently If a component has been customized for the
University, the customization should be maintained when a new
release of the component is obtained from the vendor. Updates
should be applied to the smallest component possible. For
example, a routine to determine residency should be replaceable
without replacing the entire registration component.
- Common Job Scheduling A single scheduling
mechanism should be available for all jobs regardless of
components. This would allow an operator to access all
components of the job scheduling system from a single
- Common set of Hardware/Software/Communications
Platforms/Protocols Access to platforms and protocols should
be from a single common source. This would allow us to update
hardware platforms of communications protocols with a minimum of
maintenance effort. All applications should operate on the same
platform. For example, PowerBuilder should not be used in
one application and COBOL in another.
Suitable tests for identifying these characteristics within a
system will depend on the exact implementation used by the vendor.
These tests cannot be defined in advance, but must be adapted
based on initial review of vendor information and discussions with
the vendor during presentations.
Site maintained by email@example.com
Updated January 12, 1999