Governance process

An Enterprise architecture governance framework is required to guide and facilitate business and technological decision making to support the University Strategy.   The University is committed to ensuring a sustainable framework exists to achieve the goals of Enterprise Architecture.

In response to its commitment, the University has adopted a framework built on the concept of architectural ownership with clear lines of accountability and responsibility, in addition to a new governance process which ensures any change that meets the Business Design Authority threshold is checked against the University's design principles at suitable gates during the implementation of that change.

Summary

The governance process is invoked if a change initiative is deemed to meet the threshold for review by the Business Design Authority. This threshold includes:

  • Change to capabilities; if the change may have a material affect on the University’s capabilities.
  • Scope and scale of the proposed change: The Business Design Authority should review changes that are significant in terms of their impact on the University’s overall architecture, such as changes to core systems or processes that affect multiple departments.
  • Risk and impact assessment: The Business Design Authority should review changes that have a high potential for risk, such as changes that may impact critical business processes, data security, or compliance requirements.
  • Strategic importance: The Business Design Authority should review changes that are critical to the University’s strategic objectives, such as changes that enable the University to enter new markets or develop new products or services.
  • Interoperability: The Business Design Authority should review changes that impact the University’s ability to integrate with applications, processes or partner organizations. This could include changes to data formats, communication protocols, or other technical standards that affect interoperability.
  • Data Management: The Business Design Authority should review changes that impact the University’s ability to manage data effectively. This could include changes to data storage, access, or security, as well as changes to data models or data governance policies.
  • Compliance: The Business Design Authority should review changes that impact the University’s ability to comply with legal, regulatory, or industry standards. This could include changes to data privacy, security, or auditability requirements, as well as changes to financial or reporting standards.

Not everything the Business Design Authority will review is change-related, the group can advise, clarify or offer guidance on any architecture decision.

Much of the change that already occurs at the University is guided through existing governance structures, such as the Business Transformation Board or Student Administration Governance Board.  The Business Design Authority governance process will be embedded at relevant stages of any approval process within these governance structures to ensure compliance.

The process includes up to three similar phases of review at different stages of a change initiative. It is not expected that change initiatives can align with all design principles from phase one, however as the change initiative progresses through the phases, further detail will be defined, leading to more design principle alignment.  It is also not expected that all change will require multiple stages of approval depending on the size of the change, or the request for review. 

Review phases

Phase 1 - Design principle alignment

  1. Prior to any change initiative beginning, Enterprise Architecture is contacted with details of the proposed change initiative.
  2. Enterprise Architecture works with the change initiative to ensure it aligns with the University principles.
  3. Enterprise Architecture help identify any affected entities (for example applications or services) and roles (for example Service owner) who can then be involved early in this process to ensure strategic input for their areas of interest.
  4. An architecture review is submitted to the subgroups who assess and review against their design principles. If collaboration occurred early with Enterprise Architecture, then the review will often be a formality.
  5. If all architecture subgroups sign-off the architecture review, the change initiative can continue.
  6. If there is an exception, the exception is reported to the Business Design Authority alongside any mitigation and re-alignment strategy for future.
  7. The Business Design Authority will have final architectural sign-off on any exceptions
  8. If the change initiative leads to new entities such as services, data, and applications; relevant owners must be identified as part of the change initiative.
  9. The change initiative can then proceed, with a return visit later once the full solution has been designed in detail for final sign-off.

Phase 2 – Architectural solution

Once phase one signoff has been achieved, the change initiative can begin.   Once the change initiative is at the deliver/implementation stage, a final architectural solution can be presented to the architectural groups and signed off.  This second phase contains further information about how the solution is designed with more details on the impact on the University’s business, data, application, and technological architecture.

Phase 3 – Pre-release signoff

Once the change initiative is ready to release the change will be checked for one final time by the relevant architectural groups for final approval before release.  If the change initiative is IT-related, the change must also be submitted to the Change Advisory Board for release management following architectural signoff.