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 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 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 Design Systems to be Measurable and Accountable Publish performance expectations for each IT service 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

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 Where enterprise or international standards don't exist, develop Standards in the open with key subject matter experts 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 Data Management Demonstrate alignment with enterprise and departmental data governance and strategies 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 fro 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 Sharing Data should be shared openly by default as per the Directive on Open Government while taking into consideration existing laws and regulations the safeguarding of security and the privacy 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 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 Expose public data to implement Open Data and Open Information initiatives Maximize Reuse 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 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 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

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. Apply a defense in depth approach to reduce exposure to threats and minimize the degree of compromise. Design services that: i. Prioritize ease of use in security design to make security simple for users; ii. Protected from common security vulnerabilities; iii. Expose and secure only the interfaces necessary to operate the service; iv. Are resilient and can be rebuilt quickly to a known clean state in the event that a compromise is detected; and v. 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