Appendix A: Sample Planning Principles

Information Technology Principles, The University of Pennsylvania

For each principle, a rationale is stated and specific implications listed. The principles are a link, a bridge, between the business people and the technologists. They attempt to make assumptions explicit, which helps both sides identify points of conflict and perhaps start resolving them. The principles are the foundation on which the architectures, policies, standards, plans, and systems are built. They're a stable base that lets those other components be as flexible as they need to be.

General

1. University assets.
   Information technology infrastructure, business applications, and data must be managed as University assets.

2. Functional requirements.
   University priorities and business functionality determine investments in administrative information technology.

3. Cost-effectiveness.
   Information technology must contribute to the cost-effectiveness of the business functions it supports and must be cost-effective from the perspective of the University as a whole.

4. Policies, standards, and models.
   Policies, standards, models, and methodologies -- based on the principles outlined here -- govern the acquisition and use of data and information technology. Regular update and communication are required.

5. Investment criteria.
   Investment decisions (even those not to take action) must be based on business needs, cost-effectiveness, and consistency with standards and models.

6. Training and support.
   Penn must put sufficient effort into ongoing support of its information technology assets. Skills and experiences from across the University must be leveraged and communication channels opened.

University Data

7. Accuracy.
   University administrative data must be accurate and collected in a timely way.

8. Security and confidentiality.
   University administrative data must be safe from harm and, when confidential, accessible only to those with a "need to know."

9. Ease of access.
   University administrative data must be easy to access for all groups of authorized users regardless of their level of technical expertise.

10. Multiple uses.
    Penn must plan for multiple uses of University administrative data, including operations, management decision-making, planning, and ad hoc reporting.

11. Purposeful collection.
    A given set of data should be collected once, from the source, and only if there is a business need for the data.

12. Common base of data.
    A common base of data must be created to facilitate sharing, control redundancy, and satisfy retention requirements.

13. Documentation.
    Detailed information about University administrative data must be created, maintained, and made available.

Business Applications

14. Ease of use.
    Applications must be easy to use for both novice and expert users. Interfaces should be similar enough to present a reasonably consistent "look and feel."

15. Adaptability.
    Applications must be easily adaptable to changing business and technical requirements.

16. Data sharing.
    Applications must use a common base of well defined University data and reference a common repository.

17. Ensuring data quality.
    Applications must help ensure valid, consistent, and secure data.

Infrastructure

18. Common communications infrastructure.
    Academic functions and administrative systems must share common data, voice, and video communications infrastructures.

19. Connections within the University.
    The communications infrastructure must be standardized to allow reliable, easy interaction among individuals, work groups, departments, schools, and centers.

20. Connections outside the University.
    The communications infrastructure must comply with national and international standards that allow reliable, easy interaction with those communities.

21. Hardware and software choices.
    Hardware and software for administrative use will be limited to a bounded set of alternatives. This applies to desktop computing, application servers, communications components, application development tools, and data management tools.

22. Emerging technologies.
    Penn must devote appropriate, coordinated effort to evaluating and piloting emerging technologies.

Organization

23. Data stewards.
    Data stewards are responsible for ensuring the appropriate documentation, collection, storage, and use of the administrative data within their purview.

24. Process owners.
    Process owners are responsible for developing and maintaining the standards, structures, and business applications that ensure the quality and cost- effectiveness of specific business processes.

25. Information Systems and Computing (ISC).
    Information Systems and Computing provides leadership, infrastructure, standards, services, and coordination that permit Penn to take full advantage of its information technology assets.

26. Schools and administrative centers.
    Schools and administrative centers are responsible for creating data and using information technology to meet the objectives of their organizations.

In addition to these planning principles, Penn has developed three architectures -- information, business systems, and technical infrastructure -- as models, or frameworks, from which will flow policies, standards, plans, and systems. The architectures themselves flow one from the other:

• The information architecture includes an enterprise-wide data model to help Penn understand what data it needs. That's mapped against an enterprise-wide process, or activity, model that helps us understand what the organization is doing. Reconciling the two ensures that actions will be supported by the right data.

• The business systems architecture lays out the comprehensive set of information systems and data stores that are needed to carry out Penn's specific business processes. The systems are identified without regard for what's already in place or how the pie is currently sliced.

• The technical architecture is a blueprint of the hardware, software, and communications components that will be necessary to implement the first two architectures. It's not a buy list, but a model from which standards and products can be derived.

These principles are excerpted from a paper by Linda May, Janet Gordon, Robin Beck, and Noam Arzt, "Architecture and Reengineering: Partnership for Change at the University of Pennsylvania," in Proceedings of the 1993 CAUSE Annual Conference (Boulder, Colo.: CAUSE, 1994), pp. 145-154.

University of Colorado Financial Management System Principles and Assumptions

The University of Colorado has identified eight principles to assist in planning for a new financial management application system. Included as appropriate are assumptions made by CU in conjunction with development of these principles. These principles are subject to change based on further planning of the financial management system and general strategic direction of the University.

Principle: Flexible Systems

Assumptions:

• The financial management application system will have the flexibility required to support the above principle.
• Implementation of a new financial management application system will bring immediate improvement in the University's efficiency and effectiveness.
• The financial management application system will be built on a relational database management system (RDBMS) that will allow for additional flexibility in accessing data and extending the database.

Principle: Client/server Technology

Assumptions:

• Client/server technology is sufficiently developed at this time for the University to implement a major application system.
• The University will train and equip users and technical staff to effectively use and support application systems utilizing client/server architecture.

Principle: IT Standards

Assumption:

• Standards will enhance, not limit, users' ability to do their work by creating efficiencies, especially in the following areas: (1) user training, (2) technical support, (3) systems connectivity, and (4) volume purchasing discounts.

Principle: Integrated Systems

Assumption:

• Currently available financial management application systems have sufficient integration to accomplish the University's objectives.

Principle: Buy Not Build

Assumptions:

• Vendors currently have client/server financial management application systems that are sufficiently developed to meet core University needs.
• Campus-funded staff (whether located at University Management Systems or on the campuses) will create and maintain campus-specific modules according to the University-wide system development standards.

Principle: Match Functional and Data Requirements

Assumption:

• A high-level analysis of functional and data requirements, coupled with vendor presentations, will provide sufficient information about how well an application system fits the University's needs.

Principle: System Changes

Assumptions:

• We will implement the FMS with no modification to the basic code because its flexibility will allow us to meet our essential needs without major change.
• As we implement the new system, we will make sufficient modification to the business processes to enable effective use of the application system.
• The system can be enhanced sufficiently to meet process improvement objectives through the use of configuration features of the application system and through extensions of the system using client/server technology (personal-computer-type software integrated with the application system).

Principle: Data Capture