Governance

Governance Framework

The Governance Framework for Technology Standards at UBC establishes a structured approach to developing, implementing, and managing technology standards across the university. This framework ensures that technology usage aligns with institutional goals, enhances operational efficiency, and mitigates risks associated with non-standard technologies.

Purpose

The purpose of the Governance Framework is to:

  • Provide a clear process for developing and approving technology standards.
  • Ensure consistency and conformance across all technology initiatives.
  • Foster collaboration among stakeholders in defining technology usage.
  • Promote best practices in technology management.

Governance Structure

Group Role Responsibilities
Architecture Review Board (ARB) The ARB serves as the primary governing body for technology standards, ensuring alignment with the university 's strategic objectives
  • Review and approve proposed technology standards.
  • Oversee the implementation and adherence to standards.
  • Provide guidance on strategic technology initiatives.
  • Monitor the overall effectiveness of the Exception Approval Process.
Enterprise Architecture (EA) The Enterprise Architecture team is responsible for managing the Exception Approval Process and acting as the custodian of Exception logs.
  • Facilitate the submission of Exception Request Forms and ensure they are complete.
  • Conduct comprehensive reviews of exception requests, including stakeholder consultations and assessments of justification, security implications, conformance considerations, and alternative solutions.
  • Make determinations regarding the approval or denial of requests and communicate decisions to the relevant parties.
  • Document all approved and denied exceptions, including rationale and conditions for approval.
  • Maintain records for auditing and conformance purposes and periodically share documentation with the ARB for oversight.
Architecture Working Group (AWG) A sub-committee of the ARB, the AWG is responsible for developing and refining technology standards and best practices.
  • Conduct workshops to gather input and feedback from stakeholders.
  • Draft and revise technology standards based on stakeholder input.
  • Present draft standards to the ARB for review and approval.

Task Groups

Specialized teams focusing on specific areas of technology standards, such as Cloud Computing, Identity and Access Management (IAM), and Productivity and Collaboration Tools.

  • Develop detailed standards and guidelines within their areas of expertise, ensuring they account for potential exceptions.
  • Collaborate with the AWG to ensure standards are comprehensive and aligned with institutional goals.
  • Work with the Enterprise Architecture team to evaluate exception requests related to their specific domains.
  • Provide insights and recommendations to the AWG and ARB regarding exceptions and their implications for standards.

Stakeholder Engagement

All relevant stakeholders, including IT security, conformance, and operational departments, play a critical role in the Exception Approval Process

  • Participate in consultations and provide input on exception requests.
  • Ensure that their perspectives on security and conformance are considered during the review process.
  • Collaborate with the Enterprise Architecture team to identify viable alternatives to exceptions where possible.

Applicability Statement

These technology standards are intended for all technology solutions used across the university by UBC faculty, staff, students, and researchers. Departments and units are encouraged to follow these standards when implementing and managing technologies to promote consistency, security, and efficiency.

Maturity Levels

Maturity Level Description Implications
Matured A Matured technology is one that has been widely adopted, tested, and proven in real-world environments within UBC. It is well-established, stable, and has a strong user base.

Matured technologies are dependable and have a low risk of failure, making them suitable for critical applications.
Sustainability – operational model exists

Emerging An Emerging technology is one that is still in early stages of adoption but shows potential to become a key player in the future at UBC. It may be undergoing testing, pilot programs, or limited deployments. Emerging technologies often introduce new capabilities or improvements over existing systems, but they may not yet be widely deployed or fully stable. Emerging technologies offer opportunities for innovation, often leading to competitive advantages if adopted early. Since emerging technologies may not be fully tested or mature, there is often a higher risk of bugs, limited functionality, or performance issues.
Deprecated A Deprecated technology refers to a solution or standard that is no longer actively supported or recommended for use at UBC. While still operational, deprecated technologies are typically replaced by more modern alternatives. They may still be in use in legacy systems but are not recommended for new development or deployments. Over time, deprecated technologies are phased out as new, more efficient, and secure solutions emerge. Deprecated technologies often lack vendor support, security patches, and updates, making them vulnerable to security risks and conformance issues. They may not integrate well with newer systems, leading to compatibility challenges when updating or scaling infrastructure.

 

Requirement Levels – Mandatory, Recommended and Not Recommended

Requirement Level Description Implications Exception requirements
Mandatory Standards that are required for conformance. Departments are encouraged to adhere to these standards to ensure consistency and security Advisable to maintain best practices. Departments or individuals seeking to use any alternatives to the matured or emerging standards should request an exception.
Recommended Standards that are encouraged for improved performance and conformance, allowing for some flexibility based on specific circumstances. While not mandatory, adhering to these guidelines can enhance overall effectiveness. Conformance is voluntary, but following these guidelines can enhance overall performance and security. Exceptions are not needed
Not Recommended The standards that are outdated, inefficient, or risky, and continuing to rely on them may hinder progress or cause future challenges. While not immediately harmful, these should be avoided in favor of more current or effective solutions. Conformance is voluntary, but following these guidelines can enhance overall performance and security. Exceptions are not needed

Review Guidelines

  • Technology standards will be reviewed annually by the AWG to ensure they remain relevant and effective.
  • Stakeholders will have the opportunity to provide feedback during the review process, ensuring continuous improvement.
  • Any necessary updates or revisions will be submitted to the ARB for approval.

Exception Approval Process

The Exception Approval Process is established to facilitate departments and individuals in requesting deviations from established technology standards when circumstances warrant. This structured approach ensures that all exceptions are carefully evaluated for their potential impact on security, conformance, and overall effectiveness within UBC's technology ecosystem. Enterprise Architecture will oversee this process and act as the custodian of the Exception logs. This process aims to balance flexibility and innovation with the need to uphold standards that ensure the integrity and security of UBC 's technology environment.

Step Details
Request Submission

Initiating a Request: Departments or individuals wishing to request an exception must complete a formal Exception Request Form and submit it to Enterprise Architecture. This form must clearly articulate:

  • The specific technology standard from which they seek to deviate.
  • A detailed explanation of the reasons for the exception, including any unique circumstances that justify the request.
  • An assessment of potential impacts and risks associated with the exception.
  • Any proposed alternatives that could mitigate the need for deviation from the standard
Review Process Evaluation of Requests: Upon receipt of the request, the Enterprise Architecture team will initiate a review process. This involves:
  • Stakeholder Consultation: The team may reach out to relevant stakeholders, including IT security, conformance, and operational departments, to gather insights and assess the validity of the request.
  • Assessment Criteria: The review will focus on several key aspects:
    • Justification: Evaluating whether the rationale provided sufficiently supports the need for an exception.
    • Security Implications: Analyzing potential vulnerabilities introduced by the deviation and their impact on the overall security posture of the university.
    • Conformance Considerations: Determining whether the exception may lead to non-conformance with regulatory or internal standards.
    • Alternative Solutions: Exploring whether viable alternatives exist that could meet the same objectives without requiring an exception.
Decision

Outcome Determination: After thorough review, the Enterprise Architecture team will make a decision regarding the request. The possible outcomes include:

  • Approval: The exception is granted, allowing the department or individual to proceed with the proposed deviation.
  • Denial: The request is not approved, and the requester is informed of the reasons for the denial.
  • Request for Additional Information: If further clarification is needed, the team may request additional information from the requester before making a final decision.

Communication: The decision, along with any relevant feedback, will be formally communicated to the requester.

Documentation

Record-Keeping: All approved and denied exceptions will be meticulously documented by Enterprise Architecture. This documentation will include:

  • The rationale behind each decision.
  • Any conditions or stipulations that must be adhered to if an exception is granted.

Periodic Review: Documentation will be shared with the Architecture Review Board (ARB) at regular intervals to ensure transparency and facilitate ongoing oversight.
Auditing and Conformance: All records will be maintained for auditing purposes to ensure conformance with internal policies and external regulations.