Difference between revisions of "GC Enterprise Architecture/Framework/ApplicationGuide"
Jump to navigation
Jump to search
m |
m |
||
| (One intermediate revision by one other user not shown) | |||
| Line 5: | Line 5: | ||
== Application architecture == | == Application architecture == | ||
| − | Application architecture practices must evolve significantly for the successful implementation of the GC Enterprise Ecosystem Target Architecture. Transitioning from legacy systems based on monolithic architectures to architectures that oriented | + | Application architecture is defined as the management of software used by a business to solve problems. Application architecture practices must evolve significantly for the successful implementation of the GC Enterprise Ecosystem Target Architecture. Transitioning from legacy systems based on monolithic architectures to architectures that are oriented towards business services and re‑useable components implementing business capabilities, is a major shift. Interoperability becomes a key element, and the number of stakeholders that must be considered increases. |
=== Use open source solutions hosted in public cloud === | === Use open source solutions hosted in public cloud === | ||
* select existing solutions that can be reused over custom built | * select existing solutions that can be reused over custom built | ||
| + | |||
| + | If there is already an existing open-source solution for another project that can be reused for your project, it is recommended to reach out to the owner of that project and try to reuse it for your project. That way you can get the expertise as well as the lessons learned for the existing solution. | ||
| + | |||
<b>How to achieve:</b> | <b>How to achieve:</b> | ||
| − | * Summarize how the architecture | + | * Summarize how the architecture leverages and reuses existing architectural sections including: |
| − | * | + | * Past and/or Present Processes |
| − | * | + | * Past and/or Present Solutions |
| − | * | + | * Past and/or Present Components |
<b>Tools:</b> | <b>Tools:</b> | ||
| Line 32: | Line 35: | ||
* Interim State Architecture | * Interim State Architecture | ||
| − | * register open source software to the Open Resource Exchange | + | * register open source software to the [https://code.open.canada.ca/en/index.html Open Resource Exchange] |
<b>How to achieve:</b> | <b>How to achieve:</b> | ||
* Summarize how the architecture will leverage the Open Resource Exchange. | * Summarize how the architecture will leverage the Open Resource Exchange. | ||
| Line 44: | Line 47: | ||
* choose SaaS that best fit for purpose based on alignment with SaaS capabilities | * choose SaaS that best fit for purpose based on alignment with SaaS capabilities | ||
<b>How to achieve:</b> | <b>How to achieve:</b> | ||
| − | * Summarize how the recommended SaaS is the best fit for purpose based on alignment with SaaS capabilities of | + | * Summarize how the recommended SaaS is the best fit for purpose based on alignment with SaaS capabilities of SaaS provider and Dept/SSC |
<b>Tools:</b> | <b>Tools:</b> | ||
Latest revision as of 12:38, 11 January 2023
Application architecture[edit | edit source]
Application architecture is defined as the management of software used by a business to solve problems. Application architecture practices must evolve significantly for the successful implementation of the GC Enterprise Ecosystem Target Architecture. Transitioning from legacy systems based on monolithic architectures to architectures that are oriented towards business services and re‑useable components implementing business capabilities, is a major shift. Interoperability becomes a key element, and the number of stakeholders that must be considered increases.
Use open source solutions hosted in public cloud[edit | edit source]
- select existing solutions that can be reused over custom built
If there is already an existing open-source solution for another project that can be reused for your project, it is recommended to reach out to the owner of that project and try to reuse it for your project. That way you can get the expertise as well as the lessons learned for the existing solution.
How to achieve:
* Summarize how the architecture leverages and reuses existing architectural sections including:
* Past and/or Present Processes
* Past and/or Present Solutions
* Past and/or Present Components
Tools:
* Target State Architecture
* Interim State Architecture
* EA Assessment
- contribute all improvements back to the communities
How to achieve:
* Summarize how the team will align to the TBS Guidance on Open Source Publishing to support the production of better solutions
* Summarize how the team will leverage/has leverage the Open Source community
Tools:
* Target State Architecture
* Interim State Architecture
- register open source software to the Open Resource Exchange
How to achieve:
* Summarize how the architecture will leverage the Open Resource Exchange.
* Summarize how the architecture will utilize APIs to support Open Data feeds
Tools:
* Target State Architecture
* Interim State Architecture
Use software as a service (SaaS) hosted in public cloud[edit | edit source]
- choose SaaS that best fit for purpose based on alignment with SaaS capabilities
How to achieve:
* Summarize how the recommended SaaS is the best fit for purpose based on alignment with SaaS capabilities of SaaS provider and Dept/SSC
Tools:
* Option analysis
- choose a SaaS solution that is extendable
How to achieve:
* Summarize how the recommended SaaS is extendable
Tools:
* Option analysis
* EA Assessment
- configure SaaS and if customization is necessary extend as open source modules
How to achieve:
* Summarize how the recommended SaaS can be customized through Open Source modules.
Tools:
* Option analysis
* EA Assessment
Design for Interoperability[edit | edit source]
- design systems as highly modular and loosely coupled services
How to achieve:
* Summarize how the architecture supports the implementation through:
* Simple independent functions
* Highly modular
* Loosely coupled
* Deployed into a container that has just a single application with the ability to build the smallest image
Tools:
* Target State Architecture
* Interim State Architecture
- expose services, including existing ones, through APIs
How to achieve:
* Summarize how the architecture exposes functionality as services and these services are accessible through common methodologies
* Summarize how the architectures aligns to the Government of Canada Standards on APIs
Tools:
* Target State Architecture
* Interim State Architecture
- make the APIs discoverable to the appropriate stakeholders
How to achieve:
* Summarize which APIs will be published to the ESDC API store
* Summarize which APIs will be published to the GC API store
* Summarize the rational for not publishing APIs to an API store
Tools:
* Target State Architecture
* Interim State Architecture
Design for Interoperability, Proposed amendment Jan 8, 2021[edit | edit source]
- design systems as highly modular and loosely coupled services
How to achieve:
*
- make all services available through a well-defined interface, such as an application programming interface (API)
How to achieve:
*
- all APIs with potential for cross-departmental, inter-jurisdictional, or public consumption must be published to the GC API Store
How to achieve:
*
- use the Canadian Digital Exchange Platform (CDXP) for data exchange where suitable (e.g., GC Event Broker for asynchronous messaging)
