GC Enterprise Architecture/Framework

Home

EA standards

EARB Endorsements

EA Artifacts

Working Groups

GC EARB

Other References

This is a draft copy of the proposed updates to the GC EA standards

The GC Enterprise Architecture standard is part of the Directive on Management of Information Technology. It is listed as Appendix C - Mandatory Procedures for Enterprise Architecture Assessment in the Directive.

1. Business Architecture Align to the GC Business Capability model Define program services as business capabilities to establish a common vocabulary between business, development, and operation Identify capabilities that are common to the GC enterprise and can be shared and reused Model business processes using Business Process Management Notation (BPMN) to identify common enterprise processes Establish the business architecture early, focusing on business services and capabilities to eliminate technological constraints from transformation designs and roadmaps Translate the business strategy into business capability implications using the GC Business Capability Model. Use these to guide investments. Design for Users First and Deliver with Multidisciplinary Teams Focus on the needs of users, using agile, iterative, and user-centred methods Conform to both accessibility and official languages requirements Include all skillsets required for delivery, including for requirements, design, development, and operations Work across the entire application lifecycle, from development and testing to deployment and operations Ensure quality and security is underpinning the Software Development Lifecycle Total Cost Of Ownership (TCO) should include the cost for design, construction, operation, and maintenance of a system. For example Training, Support, Disaster Recovery, and Retirement Cost Ensure accountability for privacy is clear Encourage and adopt a process (for example: Test Driven Development (TDD)) to improve the trust between Business and IT Ensure that gender diversity and inclusion is considered as part of an intersectional approach to designing for users. Consult the Policy Direction to Modernize the Government of Canada’s Sex and Gender Information Practices and best practices for gender inclusive language. (Would note here that there are likely other examples of best practices that could be included such as positive space exemplars, but nothing else is springing to mind at the moment!) Adopt a client-centric view of business delivery through customer journey maps and end-to-end service decomposition (internal (GC) and external (public)) Design Systems to be Measurable and Accountable Publish performance expectations for each business service and supporting application and technology service(s) Make an audit trail available for all transactions to ensure accountability and non-repudiation Establish business and IT metrics to enable business outcomes Apply oversight and lifecycle management to digital investments through governance Complete an Algorithmic Impact Assessment (AIA) for systems automating decisions as per the Directive on Automated Decision-Making.

2. Information Architecture Data Collection Ensure data is collected in a manner that maximizes use and availability of data Ensure data collected aligns to existing enterprise and international standards Ensure that gender diversity and inclusion is considered according to the Policy Direction to Modernize the Government of Canada’s Sex and Gender Information Practices. The government is moving toward defaulting to gender, sex by exception, and adding a third gender option in a respectful and inclusive manner. This involves making changes in the front end (collection) and the back end (coding, display). For collecting information, the recommended approach is to offer the options “male”, “female” or the third option of “another gender”. If there is a need for more specificity and the capacity for analysis, add a write in option labelled “Please Specify”. Where enterprise or international standards don't exist, develop Standards in the open with key subject matter experts and consultation with Enterprise Data Community of Practice. Ensure collection of data yields high quality data as per data quality guidelines Ensure data is collected through ethical practices supporting appropriate citizen and business-centric use Data should only be purchased once and should align with international standards Where necessary, ensure collaboration with department/agency data stewards/custodians, other levels and jurisdiction of government and indigenous people Reduce the collection of redundant data Ensure provisions are in place for Data access when using third-party contracting services. (may revise section to Business Arch?) Data Management Demonstrate alignment with enterprise and departmental data governance, architecture, strategies, and reference models Where appropriate align data to existing common vocabulary Ensure metadata is captured and defined to maximize discovery and availability Ensure accountability for data roles and responsibilities Design to maximize data use and availability Design data resiliency in accordance with GC policies and standards Use Master Data Management to provide a single point of reference for appropriate stakeholders Data Storage Only handle data which is essential to your service. Do not store all data that you capture unless absolutely necessary Ensure data is stored in a secure manner in accordance with CSE approved cryptographic algorithms and protocols and legislation such as the Privacy Act Retain data for the minimum time necessary. Follow existing retention and disposition schedules Ensure data is stored in a way to facilitate easy data discoverability, accessibility and interoperability Data Use Ensure that data is used in an Ethical and Secure manner Maximize re-usability where appropriate Ensure that combined data does not risk identification or re-identification of sensitive or personal information Ensure the data is fit for the use it is employed for in accordance with data quality guidelines Data Sharing Data should be shared openly by default as per the Directive on Open Government while taking into consideration existing laws and regulations related to the safeguarding of data, while permitting free and open access Ensure government-held data can be combined with data from other sources enabling interoperability and interpretability through for internal and external use Reduce existing data where possible Encourage data sharing and collaboration Validate or transform all external input before processing

3. Application Architecture Use Open Standards and Solutions by Default Where possible, use open source standards, and open source software first When using Open Source remain at the latest and greatest version Ensure any extension or change to the Open Source item is contributed back to the community If 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 If 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 website and services designated by the Treasury Board of Canada Secretariat All open source code must be released under an appropriate open source software license Ensure valid license and legal requirements are met for use of Open Source items Expose public data to implement Open Data and Open Information initiatives Maximize Reuse Reduce integration Complexity - design systems to be highly modular and loosely coupled to be able to reuse components. Leverage and reuse existing solutions, components, and processes Select enterprise and cluster solutions over department-specific solutions Achieve simplification by minimizing duplication of components and adhering to relevant standards Inform the GC EARB about departmental investments and innovations Share code publicly when appropriate, and when not, share within the Government of Canada Enable Interoperability Expose all functionality as services Use microservices built around business capabilities. Scope each service to a single purpose Run each IT service in its own process and have it communicate with other services through a well-defined interface, such as a HTTPS-based application programming interface (API) Run applications in containers Leverage the GC Digital Exchange Platform for components such as the API Store, Messaging, and the GC Service Bus Develop with Security in mind Applications that store, process, handle, or have network access to sensitive information should be developed with security in mind from the start, and should be audited and assessed before use Ensure sensitive data is protected appropriately when stored and transmitted (Duplicate D3) Minimise the opportunity for accidental data leakage across application boundaries Ensure only authorised parties can access sensitive information Restrict access to sensitive data to those applications designed to handle such material in a secure manner

4. Technology Architecture Use Cloud first Adopt the Use of the GC Accelerators to ensure proper Security and Access Controls - Azure, AWS Enforce this order of preference: Software as a Service (SaaS) first, then Platform as a Service (PaaS), and lastly Infrastructure as a Service (IaaS) Enforce this order of preference: Public cloud first, then Hybrid cloud, then Private cloud, and lastly non-cloud (on-premises) solutions Design for cloud mobility and develop an exit strategy to avoid vendor lock-in Design for Performance, Availability, and Scalability Design for resiliency Ensure response times meet user needs, and critical services are highly available Support zero-downtime deployments for planned and unplanned maintenance Use distributed architectures, assume failure will happen, handle errors gracefully, and monitor actively Establish architectures that supports new technology insertion with minimal disruption to existing programs and services Control Technical Diversity - design systems based on technologies and platforms already in use.

5. Security Architecture and Privacy Design for Security and Privacy Perform security categorization to identify and categorize information based on the degree of injury that could be expected to result from a compromise of its confidentiality, integrity and availability. Build in security from the outset of design, development, and throughout the system life cycle, across all architectural layers. Implement appropriate and cost-effective security measures and privacy protections, proportionate to user and business needs. Apply graduated safeguards that are commensurate with the security category of the information and assets. Protect data while in transit, in use and at rest using appropriate encryption and protocols. (Duplicate D3) Apply a defense in depth approach to reduce exposure to threats and minimize the degree of compromise. Design services that: Prioritize ease of use in security design to make security simple for users; Protected from common security vulnerabilities; Expose and secure only the interfaces necessary to operate the service; Are resilient and can be rebuilt quickly to a known clean state in the event that a compromise is detected; and Fail secure even if the system encounters an error or crashes. Integrate and automate security testing to validate code and address vulnerabilities prior to deployment Reduce human intervention and maximize automation of security tasks and processes. Ensure Secure Access to Systems and Services User access to service interfaces should be constrained to authorised individuals, with clearly defined roles. Identify and authenticate individuals, processes, and/or devices to an appropriate level of assurance before being granted access to information and services. Separate and compartmentalise user responsibilities and privileges. Assign the least set of privileges necessary to complete the job. Use GC-approved multi-factor authentication where possible to protect against unauthorized access. Maintain Secure Operations Design processes to operate and manage services securely in order to impede, detect or prevent attacks. Collect all relevant security events and logs at infrastructure and application levels to support root-cause analysis. Use a trusted time source and protect audit logs from manipulation. Continuously monitor system events and performance, and include a security audit log function in all information systems. Promptly apply security-related patches and updates to reduce exposure to vulnerabilities. Apply a risk-based mitigations when patches can’t be applied. Establish appropriate mechanisms to respond effectively to security incidents. Monitor security advisories and patches. Privacy by Design Perform a privacy impact assessment (PIA) to support risk mitigation activities when personal information is involved Implement security measures to assure the protection of personal information Take into consideration the 7 Foundational Privacy Design Principles when designing services.

Need help? Contact us. ZZCIOBDP@tbs-sct.gc.ca GC Collab GCconnex