Rescinded [2022-05-04] - Directive on Service and Digital - Appendix A: Mandatory Procedures for Enterprise Architecture Assessment

This page has been archived on the Web

Information identified as archived is provided for reference, research or recordkeeping purposes. It is not subject to the Government of Canada Web Standards and has not been altered or updated since it was archived. Please contact us to request a format other than those available.

Archived

This page has been archived on the Web.

Note to reader

The Mandatory Procedures for Enterprise Architecture Assessment has been updated to the Enterprise Architecture Framework which is the criterion used by the Government of Canada enterprise architecture review board and departmental architecture review boards when reviewing digital initiatives to ensure their alignment with enterprise architectures across business, information, application, technology and security domains to support strategic outcomes. The EA framework can be found at Government of Canada Enterprise Architecture Framework - canada.ca.

Appendix A. Mandatory Procedures for Enterprise Architecture Assessment

A.1 Effective date

  • A.1.1These procedures take effect on December 1, 2018.

A.2 Procedures

  • A.2.1These procedures provide details on the requirements set out in section 4.1.1.1 of the Directive on Service and Digital .
  • A.2.2These procedures will be used by departmental enterprise architecture review boards and the Government of Canada enterprise architectural review board as an assessment framework to review digital initiatives to ensure the Government of Canada acts as a single enterprise and to ensure departmental alignment with the Government of Canada digital direction.
  • A.2.3Mandatory procedures are as follows:

    Business Architecture

    • A.2.3.1Align to the GC Business Capability model
      • A.2.3.1.1Define program services as business capabilities to establish a common vocabulary between business, development, and operation
      • A.2.3.1.2Identify capabilities that are common to the GC enterprise and can be shared and reused
      • A.2.3.1.3Model business processes using Business Process Management Notation (BPMN) to identify common enterprise processes
    • A.2.3.2Design for users first and deliver with multidisciplinary teams
      • A.2.3.2.1Focus on the needs of users, using agile, iterative, and user-centred methods
      • A.2.3.2.2Conform to both accessibility and official languages requirements
      • A.2.3.2.3Include all skillsets required for delivery, including for requirements, design, development, and operations
      • A.2.3.2.4Work across the entire application lifecycle, from development and testing to deployment, and operations
      • A.2.3.2.5Ensure quality is considered throughout the software development lifecycle
      • A.2.3.2.6Ensure accountability for privacy is clear
      • A.2.3.2.7Encourage and adopt Test Driven Development (TDD) to improve the trust between business and IT
    • A.2.3.3Design systems to be measurable and accountable
      • A.2.3.3.1Publish performance expectations for each IT service
      • A.2.3.3.2Make an audit trail available for all transactions to ensure accountability and non repudiation
      • A.2.3.3.3stablish business and IT metrics to enable business outcomes
      • A.2.3.3.4Apply oversight and lifecycle management to digital investments through governance

    Information Architecture

    • A.2.3.4Data Collection
      • A.2.3.4.1Ensure data is collected in a manner that maximizes use and availability of data
      • A.2.3.4.2Ensure data collected aligns to existing enterprise and international standards
      • A.2.3.4.3Where enterprise or international standards don't exist, develop standards in the open with key subject matter experts
      • A.2.3.4.4Ensure collection of data yields high quality data as per data quality guideline
      • A.2.3.4.5Ensure data is collected through ethical practices supporting appropriate citizen and business-centric use
      • A.2.3.4.6Data should only be purchased once and should align with international standards
      • A.2.3.4.7Where necessary, ensure collaboration with department/ agency data stewards/ custodians, other levels of government, and Indigenous people
    • A.2.3.5Data Management
      • A.2.3.5.1Demonstrate alignment with enterprise and departmental data governance and strategies
      • A.2.3.5.2Ensure accountability for data roles and responsibilitie
      • A.2.3.5.3Design to maximize data use and availability
    • A.2.3.6Data Storage
      • A.2.3.6.1Ensure data is stored in a secure manner, using appropriate safeguards in accordance with the National Cyber Security Strategy and the Privacy Act
      • A.2.3.6.2Follow existing retention and disposition schedules
      • A.2.3.6.3Ensure data is stored in a way to facilitate easy data discoverability, accessibility, and interoperability
    • A.2.3.7 Data Sharing
      • A.2.3.7.1Data should be shared openly by default as per the Directive on Open Government
      • A.2.3.7.2Ensure government-held data can be combined with data from other sources enabling  interoperability  and interpretability through for internal and external use
      • A.2.3.7.3Reduce the collection of redundant data
      • A.2.3.7.4Reuse existing data where possible
      • A.2.3.7.5Encourage data sharing and collaboration

    Application Architecture

    • A.2.3.8Use Open Standards and Solutions by Default
      • A.2.3.8.1Where possible, use open standards and open source software first
      • A.2.3.8.2If an open source option is not available or does not meet user needs, favour platform-agnostic COTS over proprietary COTS, avoiding technology dependency, allowing for substitutability and  interoperability
      • A.2.3.8.3If a custom-built application is the appropriate option, by default any source code written by the government must be released in an open format via Government of Canada websites and  services designated by the Treasury Board of Canada Secretariat
      • A.2.3.8.4All source code must be released under an appropriate open source software license
      • A.2.3.8.5Expose public data to implement Open Data and Open Information initiatives
    • A.2.3.9Maximize Reuse
      • A.2.3.9.1Leverage and reuse existing solutions, components, and processes
      • A.2.3.9.2Select enterprise and cluster solutions over department-specific solutions
      • A.2.3.9.3Achieve simplification by minimizing duplication of components and adhering to relevant standards
      • A.2.3.9.4Inform the GC EARB about departmental investments and innovations
      • A.2.3.9.5Share code publicly when appropriate, and when not, share within the Government of Canada
    • A.2.3.10Enable  Interoperability
      • A.2.3.10.1Expose all functionality as  services
      • A.2.3.10.2Use microservices built around business capabilities. Scope each  service  to a single purpose
      • A.2.3.10.3Run each IT  service  in its own process and have it communicate with other  IT services through a well-defined interface, such as an HTTPS-based application programming interface (API) as per Appendix B: Mandatory Procedures for Application Programming Interfaces
      • A.2.3.10.4Run  applications  in containers
      • A.2.3.10.5Leverage the GC Digital Exchange Platform for components such as the API Store, Messaging, and the GC  Service  Bus

    Technology Architecture

    • A.2.3.11Use Cloud first
      • A.2.3.11.1 Enforce this order of preference: Software as aService (SaaS) first, then Platform as a  Service(PaaS), and lastly Infrastructure as a  Service(IaaS)
      • A.2.3.11.2Enforce this order of preference: Public cloud first, then Hybrid cloud, then Private cloud, and lastly non-cloud (on-premises) solutions
      • A.2.3.11.3Design for cloud mobility and develop an exit strategy to avoid vendor lock-in
    • A.2.3.12Design for Performance, Availability, and Scalability
      • A.2.3.12.1Design for resiliency
      • A.2.3.12.2Ensure response times meet user needs for availability
      • A.2.3.12.3Support zero-downtime deployments for planned and unplanned maintenance
      • A.2.3.12.4Use distributed architectures, assume failure will happen, handle errors gracefully, and monitor actively

    Security Architecture and Privacy

    • A.2.3.13Design for Security and Privacy
      • A.2.3.13.1Implement security across all architectural layers
      • A.2.3.13.2Categorize data properly to determine appropriate safeguards
      • A.2.3.13.3Perform a privacy impact assessment (PIA) and mitigate all privacy risks when personal information is involved
      • A.2.3.13.4Balance user and business needs with proportionate security measures and adequate privacy protections.