GO-ITS 200PRS Ontario Public Service Enterprise Architecture governance requirements
This standard outlines the Ontario Public Service Enterprise Architecture governance requirements that must be followed for IT projects.
1. Introduction
Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the Information Technology (IT) standards adopted through the Office of the Corporate Chief Information Officer (OCCIO) and the IT Executive Leadership Council (ITELC) for use across the government’s information and information technology (I&IT) infrastructure.
These publications support the responsibilities of the Treasury Board Secretariat for coordinating standardization of I&IT in the Government of Ontario. In particular, GO-ITS describe where the application of an IT standard is mandatory and specify any qualifications governing the implementation of the IT standards.
2. Summary
2.1 GO-ITS 200PRS OPS Enterprise Architecture governance requirements
This standard specifies the minimum set of governance requirements and supporting guidance that must be followed consistently by IT projects to ensure that Enterprise Architecture (EA) deliverables, processes and services deliver value to business needs.
The key intent of the standard is to ensure project or initiative:
- Alignment with Corporate EA goals and direction.
- Alignment of architecture developments and directions with corporate I&IT strategies.
- Alignment with architecture best practices, guidelines, and standards.
- Alignment and reuse of enterprise services, reference architecture and models, blueprints, roadmaps, and patterns.
- Optimum reuse of architectural components for business automation design and implementation.
- Use of common infrastructure, platforms, and services.
- Compliance with OPS security, policies, standards, best practices, and accessibility requirements.
- Compliance with the Archives and Recordkeeping Act (ARA), the Freedom of Information and Protection of Privacy Act (FIPPA), the Personal Health Information and Protection Act (PHIPA), as well as the policies, directives and guidelines that flow from the statutes when assessing risks and developing related mitigation strategies for recordkeeping, access, and privacy (RkAP) requirements.
2.2 Background and rationale
The I&IT Strategy, as approved by Cabinet in February 1998, initiated a project to establish an OPS Enterprise Information and Information Technology Architecture (the EIA Project). It was also to serve as a management tool to coordinate infrastructure initiatives across government and to gauge the impact of emerging technologies.
The EIA Project established an OPS Enterprise Architecture practice (EA practice), as well as review and governance processes. The EA practice and processes have evolved over time through very broad OPS consultation and senior management approval mechanisms — see section 3 Technical Specification: EA Governance Requirements for further information.
As part of the EA practice, I&IT projects generate architectural work products called “artefacts”. Projects might need to use internal EA practitioners, external consultants and/or vendors of IT products and services that need to understand OPS EA requirements.
The purpose of this standard is to:
- enhance OPS EA practice understanding and compliance (including minimum requirements)
- establish EA governance requirements for I&IT projects using waterfall, iterative and agile methodologies
2.3 Target audience
This standard applies to all Government of Ontario Ministries as well as advisory and adjudicative agencies subjected to the Governance and Management of Information Technology Directive.
2.4 Scope
2.4.1 In scope
- EA artefacts.
- EA governance requirements.
- EA support for waterfall, iterative and agile methodologies.
2.4.2 Out of scope
- Development and implementation of IT solutions.
- Operation of IT solutions.
2.5 Applicability statements
2.5.1 Organization
All Ministries and I&IT Clusters are subject to GO-ITS.
All adjudicative and advisory agencies are subject to GO-ITS.
All other agencies that are using OPS I&IT technology products or services are required to comply with GO-ITS standards if they are subject to either the Governance and Management of Information Technology Directive or Government of Ontario IT Standards by memorandum of understanding.
As new GO-IT Standards are approved, they are deemed mandatory on a go-forward basis, meaning at the next available project development or procurement opportunity.
When implementing or adopting any Government of Ontario IT standards or IT standards updates, Ministries, I&IT Clusters and applicable agencies must follow their organization’s pre-approved policies and practices for ensuring that adequate change control, change management, and risk mitigation mechanisms are in place and employed. For the purposes of this document, any reference to Ministries or the Government includes applicable agencies.
2.5.2 Ontario Public Service Enterprise Architecture
In the OPS, EA is a mature approach governed by best practices, methods, standards, and principles to examine key business, information, application, security, and technology strategies and their impact on business functions and processes. The EA is based on the best-practices of various EA frameworks but does not endorse or adopt any specific framework.
Over the past two decades, the EA program has contributed to the success of numerous I&IT projects and has evolved the maturity of the architecture practice.
The EA Modernization initiative was initiated in 2014 and the implementation was approved by the ITELC in January 2018. This was done to enhance Business and I&IT partnerships to support business-aligned solutions as well as reduce complexity and risk while enabling strategic investments. The EA Modernization project has leveraged the lessons learned over the years and optimized the EA practice to be more effective and efficient. The EA program is moving from a project-centric view to a solution-centric view.
The current version of this standard is the result of the EA Modernization initiative addressing the following key priorities as approved by ITELC on January 25, 2018:
- streamlined EA governance
- consistent EA practice with minimum requirements
- rationalized artefacts developed based on I&IT project solution scenarios (known in the OPS as EA scenarios)
- guidance for agile and iterative methodologies
The EA Modernization initiative aims to achieve ongoing governance efficiencies and provide a flexible EA governance approach for different solution implementation methodologies.
2.5.3 Requirement levels
Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:
- Must
- This word, or the terms "required" or "shall", means that the statement is an absolute requirement.
- Should
- This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, cost) must be understood and carefully weighed before choosing a different course.
3. Technical specification: EA governance requirements
The following requirements apply to all I&IT assets and operations within the scope of the Governance and Management of Information Technology Directive.
3.1 Mandatory governance requirements
3.1.1 Each I&IT Cluster must establish a single EA governance function, committee, architecture review board, or equivalent to:
- Conduct architectural reviews and govern appropriate execution of EA practice in the I&IT Cluster.
- Review and ensure that architecture, privacy, and security documents comply with Section 7 of the Governance and Management of Information Technology Directive which supports Gates 1 through 4 of the Policy on the I&IT Project Gateway Process.
- Conduct a technical review of all I&IT Cluster and enterprise-wide projects, common infrastructure projects, projects which have an extensive or unique impact on the business and technology environment, and any other projects as identified by the OCCIO, Management Board of Cabinet Support Branch, Corporate Architecture Governance (CAG), Treasury Board Secretariat, or an I&IT Cluster Chief Information Officer (CIO).
3.1.2 For all I&IT projects, the I&IT Cluster must issue a written statement establishing or selecting a Solution Delivery Methodology. This is intended as a means for structuring, controlling, and guiding the implementation and EA governance of solutions in the OPS.
At Architecture Governance Point (AGP) 0, projects must state the methodology used for the duration of the entire project.
3.1.3 The I&IT Cluster must conduct an EA risk assessment based on the EA Decision Matrix for all I&IT projects at AGP 0. Based on the EA Decision Matrix result, the I&IT project must follow the governance path listed below:
- Projects with high EA risk or enterprise impacts as defined by the Policy on the I&IT Project Gateway Process and EA Decision Matrix will be governed by the Corporate Architecture Review Board (ARB).
- Projects with low or medium EA risk will be governed by the I&IT Cluster EA governance function, committee, architecture review board, or equivalent. For I&IT Clusters to govern projects, they must follow this standard in a consistent manner as per the minimum requirements specified.
- Regardless of EA risk levels, all I&IT projects that are subject to Corporate EA governance as per the Policy on the I&IT Project Gateway Process will be governed by Corporate ARB unless Corporate ARB approves delegation to an I&IT Cluster based on appropriate rationale provided at AGP 0 and prior to the I&IT business case being approved.
3.1.4 The I&IT Cluster and Corporate EA bodies must conduct architectural reviews on project artefact submission and maintain issue/resolution logs for all Architecture Governance Points.
- For corporately governed projects, the I&IT Cluster EA manager must provide an acknowledgement to confirm that a preliminary quality review on the submission material was done and that the material is of acceptable quality to be submitted for Corporate EA review.
- EA manager approval (e.g., email) is needed for the project to proceed to Corporate ARB or equivalent. The main intent is to ensure EA managers are aware of any key issues and are accountable for the quality of project team submissions. This includes an understanding of any critical architecturally significant issues that could impede a project’s overall readiness to proceed to Corporate ARB.
3.1.5 The I&IT Cluster and Corporate EA bodies must document and maintain the governance decisions for all I&IT projects in their respective repositories, including:
- EA decision matrix
- EA approach and rationale
- EA Statement of Work (EASOW)
- AR assessment report (Issue Log)
- Governance decision minutes
Corporate EA may conduct random spot checks to verify the above material is maintained by I&IT Clusters.
The EASOW is a document for I&IT projects to plan enterprise architecture deliverables. Projects must follow the guidance below:
| EA risk | EASOW usage |
|---|---|
| High risk | The EASOW standard template is mandatory for all projects irrespective of $ amount. |
| Medium risk | The EASOW standard template is mandatory for all projects irrespective of $ amount. |
| Low risk >= 2M |
|
| Low risk < 2M |
|
3.1.6 When preparing the above documents, projects are recommended to leverage the EA templates that have been developed by CAG in support of this standard for consistency of architecture documentation. EA groups will accept AR submissions that are reflective of the required architecture content. Projects can use the table of content and guidance in the EA artefacts described in Section 3.2 as a reference to guide the architecture development of the required content. AR submissions can also be in model-driven architecture format (e.g., PowerDesigner).
The project team must document the outputs in accordance with the established core practice requirements and guidelines of this standard as well as the EASOW.
3.1.7 The I&IT Cluster must maintain EA artefacts created and reviewed for all I&IT projects in their respective repository.
3.1.8 When Corporate ARB approves governance delegation to the I&IT Cluster, EA artefacts, and supporting material created and reviewed for all I&IT projects must be submitted to the Corporate EA repository at APG 3.
3.1.9 The I&IT Cluster must provide access to CAG, Enterprise Technology Strategy for the following material:
- EA decision matrix
- EA approach and rationale
- EA Statement of Work (EASOW)
- AR assessment report (Issue Log)
- Governance decision minutes
- Project EA artefacts
Corporate EA may conduct random spot checks to verify the above material is maintained at I&IT Clusters.
3.1.10 The I&IT Cluster must maintain governance records in an enterprise project management tool (such as Planview) for Corporate EA to produce statistical reports on a quarterly basis or as required by Corporate ARB.
3.1.11 A Request-to-Alter (RTA) may be submitted in the event of changes such as project scope, project methodology, EA risk, EA governance path, and/or EA requirements. The IT project must submit a request to the architecture governing body for approval with appropriately documented rationale.
3.1.12 Any deviation from this standard will require a written justification for an exemption. This must be developed by the I&IT Cluster or project team and presented to the Cluster CIO for endorsement. The project team must then formally request endorsement of the exemption from ARB followed by approval of ITELC.
3.2 Standard Enterprise Architecture artefacts
The following artefact requirements apply to I&IT projects of all EA risk levels. These EA artefacts or collaterals must be developed based on EA scenario guidance from CAG, which will specify the required and optional content that is relevant to the EA scenario. Any variations to the above may be proposed by the project using the EASOW and must be approved by the architecture governing body.
- Business Architecture Document (BAD): used to describe the business architecture requirements in terms of the business program, services, functions, processes, and resources.
- Information Architecture Document (IAD): used to describe via use of suitable data/information models the business data requirements and design specifications of both data contents and structures needed to support business data processing, data usage, data exchanges, and data analytics.
- Solution Requirements Document (SRD): used to describe the functional and non-functional requirements for the solution.
- Solution Architecture Document (SAD): used to describe the application and technology architecture considerations including security, privacy, and accessibility requirements for the solution.
3.2.1 Guidance for EA artefact template usage
If a project demonstrates reuse of existing I&IT Cluster or Corporate EA-approved architecture, then a delta update using the original format is acceptable.
If a project demonstrates the reuse of approved baseline architecture of a service or solution, then only a delta update to the architecture specific to the project scope will be required.
Note: If the EA scenario does not match the project requirements, the project must seek specific guidance through consultation with the I&IT Cluster governing body for low or medium EA risk projects, or with Corporate EA for high EA risk or enterprise impact projects.
3.3 EA deliverable guidance
CAG provides the following guidance and support on required EA deliverables pertaining to this standard:
- EA review requirements for Architecture Governance Points.
- EA review artefact requirements.
- EA scenarios.
- Solution delivery methodologies for the development of I&IT solutions in the OPS.
3.4 Further elaboration
The OPS architectural practice is further elaborated in various guidance materials to support this standard, which are revised from time to time with Corporate ARB approval.
4. Related standards and impacted infrastructure
4.1 Impacts to existing standards
| GO-ITS | Impact | Recommended action |
|---|---|---|
|
GO-ITS 54 Application Development Standard |
Not Applicable |
Rescind and archive GO-ITS 54 Version 1.0 |
4.2 Impacts to existing infrastructure
| Impact | Recommended action | |
|---|---|---|
| None | Not Applicable | Not Applicable |
5. Compliance requirements
In order to manage the effectiveness and implementation of this standard, Ministries, I&IT Clusters and applicable agencies are expected to adopt and monitor compliance.
6. Roles and responsibilities
Accountable role (standard owner) definition
The individual or committee ultimately accountable for the effectiveness of a standard and for its full life-cycle, including development, reviews, revisions, updates, evaluations, and rescindment. Where a committee owns the standard, the committee Chair is accountable for the standard. There must be exactly one accountable role identified.
Accountable role
- Title: Senior Manager, Corporate Architecture Governance
- Ministry: Ministry of Public and Business Service Delivery
- Division: Enterprise Technology Strategy
- Branch: Technology Roadmap and Investment Plan
- Section: Corporate Architecture Governance
Responsible role definition
The organization(s) responsible for the development of this standard. There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization(s) provides the resource(s) to develop the standard).
Responsible Organization(s)
- Ministry: Ministry of Public and Business Service Delivery
- Division: Enterprise Technology Strategy
- Branch: Technology Roadmap and Investment Plan
- Section: Corporate Architecture Governance
7. Consultations
Areas consulted as part of the development of this standard. Include individuals and committees, councils and/or working groups:
Organization consulted (Ministry/I&IT Cluster)
- I&IT Clusters and Corporate Areas
Committee/working group consulted
- Enterprise Architecture Management Working Group (EAMWG)
- Solution Architecture Domain Working Group (SADWG)
- Business & Information Architecture Domain Working Group (BIADWG)
8. Document history
| Date | Summary |
|---|---|
| 2009-07-02 | Architecture Review Board endorsed GO-ITS 56 v1.0 |
| 2012-09-06 | I&IT Executive Leadership Council (ITELC) approved GO-ITS 56 v1.7 |
| 2019-03-19 | Corporate and I&IT Cluster subject matter experts across the domain areas of EA, privacy, security, and accessibility provided feedback for GO-ITS 56 version 2.0 |
| 2023-03-01 | GO-ITS 56 OPS Enterprise Architecture v2.0 renamed to GO-ITS 200PRS OPS Enterprise Architecture Governance Requirements |
| 2023-04-05 | Architecture Review Board (ARB) endorsement |
| 2023-04-27 | I&IT Executive Leadership Council (ITELC) approval — version number set to 1.0 (GO-ITS 200PRS v1.0) |
9. Appendices
9.1 Normative references
Governance and Management of Information Technology Directive (for OPS employees/internal users)
Policy on the I&IT Project Gateway Process (for OPS employees/internal users)
Note: a normative reference specifies a supporting document or GO IT Standard (in the case of the Government of Ontario's I&IT infrastructure, often another OPS I&IT authorized publication) that must be read to fully understand or implement the subject matter of the main GO IT Standard. Such authoritative or de facto references may be external and may, or may not be, owned/controlled by the GO IT Standard owner.