Return to the Integrated Systems Project Home Page

---

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.

Data Issues

• 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 avoided.
• 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.

Application Issues

• 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 the system.
• 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.

Presentation Issues

• 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 system.
• 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 icons.
• 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.

Operational Issues

• 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 component.
• 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 system.
• 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 location.
• 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.