Exploratory prototype 3 - 2018-7 Checkbox filtering - Research and finding
6. Use open standards and solutions (draft)
Filter - Prototype 3
Show/Hide content details
Not checked by default, and the associate block of content is tagged by default with the CSS wb-fltr-out2
Table of content
Sub section filtering for section 6.1
(The section heading remain visible because they are marked at such)
Check means it is displayed, uncheck means the content are hidden.
Exclusive filter
The exclusive filter that is toggled is defined by how the tagging is done. An exclusive tag will be prefixed with an asterik *
. Exclusive filter will only hide the sibling.
- Previous - 5. Work in the open by default (draft)
- 1 - Go to 1. Design with users (draft)
- 2 - Go to 2. Build in accessibility from the start (draft)
- 3 - Go to 3. Collaborate widely (draft)
- 4 - Go to 4. Empower staff to deliver better services (draft)
- 5 - Go to 5. Work in the open by default (draft)
- 6 - Go to 6. Use open standards and solutions (draft)
- 7 - Go to 7. Iterate and improve frequently (draft)
- 8 - Go to 8. Design ethical services (draft)
- 9 - Go to 9. Address security and privacy risks (draft)
- 10 - Go to 10. Be good data stewards (draft)
- Next - 7. Iterate and improve frequently (draft)
[TODO: Add/revise introductory text]
Guidelines
- 6.1 Leverage open standards and embrace leading practices, including use of open source software where appropriate
- 6.2 Use and reuse common, proven government solutions, approaches, and platforms
- 6.3 Design for interoperability, allowing services to be discovered and leveraged by the community
- 6.4 Open up the data, transactions, and business rules that underpin a service
Related guidelines
- 1.3 Understand the context in which people are interacting and design appropriate solutions that meet their needs (1. Design with users (draft))
- 3.4 Share and collaborate in the open, link to the work of others, and provide resources that others can reuse (3. Collaborate widely (draft))
- 5.1 Make all non-sensitive data, information and new source code open to the outside world for sharing and reuse under an open licence (5. Work in the open by default (draft))
- 10.3 Ensure that data is collected in a standard way so that it can easily be integrated and reused by others (10. Be good data stewards (draft))
6.1 Leverage open standards and embrace leading practices, including use of open source software where appropriate
[TODO: Add/revise introductory text]
Content details
Build technology that uses open standards to ensure your system works and communicates with other products or systems, and can easily be upgraded and expanded.
Content details
Adopting and using open standards means you can:
Content details
-
move between different technologies when you need to, avoiding vendor lock-in
Content details
-
quickly and easily change your service when you need to
Content details
- increase compatibility with all stakeholders
- open up the range of companies you can purchase from as more of them are likely to use the same standard as you
- access a wider range of both open source and proprietary software vendors
Our choices for hosting infrastructure, databases, software frameworks, programming languages and the rest of the technology stack should seek to avoid vendor lock-in and match what successful modern consumer and enterprise software companies would choose today. In particular, digital services teams should consider using open source software, cloud-based, and commodity solutions across the technology stack, because of their widespread adoption and support by successful consumer and enterprise technology companies in the private sector.
Open source software (OSS) tends to use and help define open standards and publicly available specifications. OSS products are, by their nature, publicly available specifications, and the availability of their source code promotes open, democratic debate around their specifications, making them both more robust and interoperable.
Using open source software means you can benefit from:
- solving common problems with readily available open source technology
- more time and resource for customised solutions to solve the rare or unique problems
- lower implementation and running costs
There are many potential benefits from the greater use of digital services, including greater convenience for users, quicker and more responsive service delivery, increased security and reliability and reduced costs. To maximize these potential benefits and avoid user reliance on less convenient ways of interacting with government, services should be designed to be digital from end-to-end.
Checklist
[TODO: Add/revise checklist items]
Content details
- Use open standards and open source software at every layer of the technology stack
- Factor in the use of open Standards and open source software when calculating total cost of ownership of a solutions including exit or transition costs
- Avoiding lock-in to any proprietary solutions where open source software and/or open standards are available
- Ensure that software can be deployed on a variety of commodity hardware types
- Use open source standards, solutions, components, and leading practices.
- Enforce this order of preference: open source first, then platform-agnostic COTS, then proprietary COTS, and lastly custom-built.
- 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.
- Design, build and test end-to-end digital services
- ensure prototypes incorporate the end-to-end user experience (4. Design the service from start to finish, Digital Service Standard (Ontario))
- design and test your service to work with the devices and browsers your users use - find out the browsers you must test with (Digital Service Standard (UK))
- test the service in an environment that is as similar to the live environment as possible (Digital Service Standard (Ontario))
- have a process for testing changes made to the service (Digital Service Standard (Ontario))
- have a process for monitoring and testing the service frequently even when changes are not being made (Digital Service Standard (Ontario))
- Create automated tests that verify all user-facing functionality (Digital Services Playbook (US))
- Create unit and integration tests to verify modules and components (Digital Services Playbook (US))
- Run tests automatically as part of the build process (Digital Services Playbook (US))
- Perform deployments automatically with deployment scripts, continuous delivery services, or similar techniques (Digital Services Playbook (US))
- Conduct load and performance tests at regular intervals, including before public launch (Digital Services Playbook (US))
- Determine how users would be affected if your service was unavailable for any length of time and how that’s changed since beta (Digital Service Standard (UK))
- Determine the most likely ways the service could go offline and how you plan to stop them (Digital Service Standard (UK))
- Determine your strategy for dealing with outages, including who’s responsible and the decisions they can make (Digital Service Standard (UK))
-
Before going into production, develop the appropriate processes to ensure that training data is tested for unintended biases and other factors that may unfairly impact outcomes.
Content details
- Digital Standard: 6. Use open standards and solutions (draft)
- Guideline: 6.1 Leverage open standards and embrace leading practices, including use of open source software where appropriate
- Tags:
dpgn-automated-decision-deployment-operation, dpgn-automated-decision
- Content source: Section 6.3.1, Directive on Automated Decision-Making (draft) (GC)
Implementation guides
[TODO: Add/revise implementation guide items]
Content details
- Socle Logiciels Libres (France)
- Logiciels libres et ouverts - Guide d’analyse de maturité (Québec)
- Logiciels libres et ouverts - Guide d’analyse du coût total de propriété (Québec)
- Working with open standards (Service Manual (UK))
- Choosing technology: an introduction (Service Manual (UK))
- Australian Government ICT Policy Guides and Procurement (AU)
- Australian Government Open Source Software Policy (AU)
- DoD Open Source Software FAQ (US)
- DoD Memorandum on Guidance Regarding Open Source Software (US)
- W3C Standards (W3C)
- OASIS Standards (oasis-open.org)
- Quality assurance: testing your service regularly (Digital Service Standard (UK))
- Designing for different browsers and devices (Digital Service Standard (UK))
- Test your service’s performance (Digital Service Standard (UK))
- Exploratory testing (Digital Service Standard (UK))
- Deployment environments (Digital Service Standard (UK))
- Vulnerability and penetration testing (Digital Service Standard (UK))
- Performance testing (Digital Service Standard (AU))
- Testing your service (Service Manual (UK)
- Testing Cookbook (18F (US))
- Keeping your service online (Service Manual (UK))
Reusable solutions
[TODO: Add/revise reusable solutions]
Similar resources
- Open Standards (Open First Whitepaper (GC))
- Open Source Software Use (Open First Whitepaper (GC))
- Natural Resources Canada Free and Open Source Software Licensing Primer (GC)
- Logiciels libres et ouverts - Guide de référence (Québec)
- Politique du libre (Montréal)
- 8. Choose a modern technology stack (Digital Services Playbook (US))
- 18F Open Source Policy (US)
- 3. Be open and use open source (Technology Code of Practice (UK))
- 4. Make use of open standards (Technology Code of Practice (UK))
- 9. Use open standards and common platforms (Digital Service Standard (UK))
- 9. Use open standards and common platforms (Digital Service Standard (Ontario))
- 7. Use open standards and common platforms (Digital Service Standard (AU))
- 1. Use Open Standards and Solutions by Default (Digital Architectural Standards (GC))
- 5. Design for Performance, Availability, and Scalability (Digital Architectural Standards (GC))
- 10. Test the end-to-end service (Digital Service Standard (UK))
- 4. Design the service from start to finish (Digital Service Standard (Ontario))
- 6. Test the end-to-end service (Digital Service Standard (Ontario))
- 10. Automate testing and deployments (Digital Services Playbook (US))
- 10. Test the service (Digital Service Standard (AU))
- 11. Make a plan for being offline (Digital Service Standard (UK))
6.2 Use and reuse common, proven government solutions, approaches, and platforms
[TODO: Add/revise introductory text]
In order to limit costs, avoid duplication of effort and provide a consistent client experience when using various services, the reuse and adaptation of existing technological solutions is encouraged. If the development of new solutions is required, consider the ability of others to reuse and adapt your work as this will provide additional value on an organizational level.
Using common, proven government solutions, approaches, and platforms will help the government:
- meet the needs of your users by building with proven solutions
- make users’ experience of government more consistent, which generates trust
- save time and money by reusing things that are already available
Checklist
[TODO: Add/revise checklist items]
-
Use device-agnostic and modular technology. (2. Reuse, improve and share technological solutions where appropriate (Do - Digital Design Playbook (ISED)))
- Use technology that allows your service to function regardless of the device or operating system. Make sure mobile apps can function on all devices.
- Modular technology can be reused, in part or in whole to innovate new solutions and uses for it. It also allows you to add new capabilities and capacities to your technology in response to changing operational environments.
- Follow the Canada.ca Content Style Guide
- Static assets are served through a content delivery network (Digital Services Playbook (US))
- 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.
- Run applications in containers.
- Leverage enterprise digital exchange components such as the GC Service Bus, Digital Exchange Platform, and the API Store, based on fit-for-use.
Cloud services
- 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.
- Cloud services are identified and evaluated as the principal delivery option when initiating IT investments, initiatives, strategies and projects.
- In considering how to manage security risks, departments and agencies must follow the GC Cloud Security Risk Management Approach and Procedures and the Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN).
- Departments and agencies may deploy solutions that have data-categorization requirements that fall outside of a particular cloud security control profile, as described in the Government of Canada Security Control Profile for Cloud-Based GC IT Services, with appropriate risk-mitigation measures that have been developed in consultation with GC security partners.
- To ensure, to the greatest extent possible, the GC’s continuous access to sensitive data, departments and agencies must comply with the Direction for Electronic Data Residency.
- To ensure business continuity and to manage risks, departments and agencies will develop an appropriate exit strategy before using cloud services.
- Departments and agencies should consider portability and interoperability of services when designing cloud-based solutions.
Implementation guides
[TODO: Add/revise implementation guide items]
Cloud services
- Government of Canada Right Cloud Selection Guidance
- Government of Canada Security Control Profile for Cloud-Based GC IT Services
- Government of Canada Cloud Adoption Strategy
- Government of Canada White Paper: Data Sovereignty and Public Cloud
- Government of Canada Cloud Security Risk Management Approach and Procedures
- Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN)
- Direction for Electronic Data Residency
Reusable solutions
[TODO: Add/revise reusable solutions]
Similar resources
- Three-Step Software Solutions Analysis (Federal Source Code Policy (US))
- 1. Comply with Government of Canada acts, policies, standards and directives (Plan - Digital Design Playbook (ISED)) (internal to GC only)
- 2. Reuse, improve and share technological solutions where appropriate (Do - Digital Design Playbook (ISED)) (internal to GC only)
- 2. Maximize Reuse (Digital Architectural Standards (GC))
- 6. Enable Interoperability (Digital Architectural Standards (GC))
- 9. Use Cloud First (Digital Architectural Standards Principles (GC))
- 9. Deploy in a flexible hosting environment (Digital Services Playbook (US))
6.3 Design for interoperability, allowing services to be discovered and leveraged by the community
[TODO: Add/revise introductory text]
Interoperability is a characteristic of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, in either implementation or access, without any restrictions. Interoperability should be ensured, via the use of open standards.
Application Program Interfaces (APIs) are a means by which business functionality is exposed digitally. They are building blocks that are critical to the successful delivery of government online digital services and expanding service delivery to third party providers. They can also enable greater interoperability between services, optimized experiences across devices and can even lead to innovative new services by enabling third party products to work seamlessly with Government of Canada systems.
Checklist
[TODO: Add/revise checklist items]
- Expose all functionality as services.
- Use microservices built around business capabilities. Scope each service to a single purpose.
- Run each service in its own process and have it communicate with other services through a well-defined interface, such as an HTTPS-based application programming interface (API).
- Build services that are API-centric services, which execute most, if not all, functionality through API calls (e.g., connecting frontend to backend through an API)
- Plan out API access from the beginning, designing services to be able to safely and securely expose functionality to other systems and the public.
- Design APIs to be compete but also minimal, ensuring the expected functionality is provided but with as few public members per class and as few classes as possible. This makes it easier to understand, remember, debug and change the API.
- Design APIs to have clear and simple semantics to make common tasks easy. Rare tasks should still be possible but not the focus. Avoid being overly general, optimizing specific use cases.
- Design APIs to be intuitive so that a semi-experienced user can be successful with minimal assistance from the documentation and programmers can easily understand code that uses the API.
- Design APIs to be easy to memorize by implementing a consistent and precise naming convention. Use plain language and recognizable patterns and concepts, avoiding abbreviations where possible.
Implementation guides
[TODO: Add/revise implementation guide items]
Reusable solutions
[TODO: Add/revise reusable solutions]
Similar resources
6.4 Open up the data, transactions, and business rules that underpin a service
[TODO: Add/revise introductory text]
Checklist
[TODO: Add/revise checklist items]
Implementation guides
[TODO: Add/revise implementation guide items]
Reusable solutions
[TODO: Add/revise reusable solutions]
- Give feedback about this page
- View content source on GitHub
- View template source on GitHub
- Show filters
- Previous - 5. Work in the open by default (draft)
- 1 - Go to 1. Design with users (draft)
- 2 - Go to 2. Build in accessibility from the start (draft)
- 3 - Go to 3. Collaborate widely (draft)
- 4 - Go to 4. Empower staff to deliver better services (draft)
- 5 - Go to 5. Work in the open by default (draft)
- 6 - Go to 6. Use open standards and solutions (draft)
- 7 - Go to 7. Iterate and improve frequently (draft)
- 8 - Go to 8. Design ethical services (draft)
- 9 - Go to 9. Address security and privacy risks (draft)
- 10 - Go to 10. Be good data stewards (draft)
- Next - 7. Iterate and improve frequently (draft)