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 |
|
Enterprise Architecture (EA) | The Enterprise Architecture team is responsible for managing the Exception Approval Process and acting as the custodian of Exception logs. |
|
Architecture Working Group (AWG) | A sub-committee of the ARB, the AWG is responsible for developing and refining technology standards and best practices. |
|
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. |
|
Stakeholder Engagement |
All relevant stakeholders, including IT security, conformance, and operational departments, play a critical role in the Exception Approval Process |
|
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. |
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:
|
Review Process | Evaluation of Requests: Upon receipt of the request, the Enterprise Architecture team will initiate a review process. This involves:
|
Decision |
Outcome Determination: After thorough review, the Enterprise Architecture team will make a decision regarding the request. The possible outcomes include:
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:
Periodic Review: Documentation will be shared with the Architecture Review Board (ARB) at regular intervals to ensure transparency and facilitate ongoing oversight. |