This set of principles address technology components and change management.

Principle 18: Requirements-Based Change

  • Statement:
    • Only in response to academic or administrative needs are changes to applications and technology made.
  • Rationale:
    • This principle will foster an atmosphere where the information environment changes in response to the needs of the institution, rather than having the institution change in response to IT changes. This is to ensure that the purpose of IT – to support and expedite institutional processes – is the basis for any proposed change. Unintended effects on the institution due to IT changes will be minimized. A change in technology may provide an opportunity to improve institutional processes and/or reduce costs, and hence change academic or administrative needs.
  • Implications:
    • We shouldn’t fund a technical improvement or system development unless a documented academic or administrative need exists.
    • Change management processes conforming to this principle will be developed and implemented.
    • This principle may “bump up against” the responsive change principle. We must ensure the requirements documentation process does not hinder responsive change to meet legitimate academic or administrative needs. The purpose of this principle is to keep IT focused on the institution, not technology needs – responsive change is also an institutional need.

Principle 19: Responsive Change Management

  • Statement:
    • Changes to the University’s information environment are implemented in a timely manner.
  • Rationale:
    • If people are to be expected to work within the University’s information environment, that information environment must be responsive to their needs.
  • Implications:
    • We need to develop processes for managing and implementing change that do not create delays.
    • A user who feels a need for change will need to connect with an ITS Client Representative to facilitate explanation and implementation of that need.
    • If we are going to make changes, we must keep the architectures updated.
    • This will conflict with other principles (e.g., maximum University-wide benefit, University-wide applications, etc.).

Principle 20: Control Technical Diversity

  • Statement:
    • Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity between multiple processing environments.
  • Rationale:
    • There is a real, non-trivial cost of infrastructure required to support alternative technologies for processing environments. There are further infrastructure costs incurred to keep multiple processor constructs interconnected and maintained.
    • Limiting the number of supported components will simplify maintainability and reduce costs.
    • The institutional advantages of minimum technical diversity include: standard packaging of components; predictable implementation impact; predictable valuations and returns; redefined testing; utility status; and increased flexibility to accommodate technological advancements. Common technology across the institution brings the benefits of economies of scale to the institution. Technical administration and support costs are better controlled when limited resources can focus on this shared set of technology.
  • Implications:
    • Policies, standards, and procedures that govern acquisition of technology must be tied directly to this principle.
    • Technology choices will be constrained by the choices available within the technology blueprint. Procedures for augmenting the acceptable technology set to meet evolving requirements will have to be developed and applied.
    • We are not freezing our technology baseline. We welcome technology advances and will change the technology blueprint when compatibility with the current infrastructure, improvement in operational efficiency, or a required capability has been demonstrated.

Principle 21: Interoperability

  • Statement:
    • Software and hardware should conform to defined standards that promote interoperability for data, applications, and technology.
  • Rationale:
    • Standards help ensure consistency, thus improving the ability to manage systems and improve user satisfaction, and protect existing IT investments, thus maximizing return on investment and reducing costs. Standards for interoperability additionally help ensure support from multiple vendors for their products, and facilitate supply chain integration.
  • Implications:
    • Interoperability standards and industry standards will be followed unless there is a compelling academic or administrative reason to implement a non-standard solution.
    • A process for setting standards, reviewing and revising them periodically, and granting exceptions must be established.
    • The existing IT platforms must be identified and documented.