514
edits
Changes
GC Enterprise Architecture/Framework/TechnologyGuide (view source)
Revision as of 11:50, 24 February 2021
, 11:50, 24 February 2021no edit summary
=== Use cloud first ===
=== Use cloud first ===
* adopt the use of the GC Accelerators to ensure proper security and access controls
* adopt the use of the GC Accelerators to ensure proper security and access controls
<b>How to achieve:</b>
* Summarize which cloud usage profile does the architecture align to and why
* Summarize which cloud connection pattern does the architecture align to and why
<b>Tools:</b>
* Cloud Reference Architecture
* Cloud Assessment Framework
* Summary of Cloud Access Scenarios and Usage Profiles
* 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: software as a service (SaaS) first, then platform as a service (PaaS), and lastly infrastructure as a service (IaaS)
<b>How to achieve:</b>
* Summarize how the architecture, based on the TBS Right Cloud Assessment Tool, allows for cloud service model of how:
* The architecture can be implemented using a GC SaaS environment, which has been identified as a possible fit, or
* The architecture can be implemented using a Public SaaS environment, which has been identified as a possible fit, or
* The architecture can be implemented using a GC PaaS environment, which has been identified as a possible fit, or:
* The architecture can be implemented using Public PaaS environment, which has been identified as a possible fit.
<b>Tools:</b>
* Cloud Reference Architecture
* Cloud Assessment Framework
* fulfill cloud services through SSC Cloud‑Brokering Services
* fulfill cloud services through SSC Cloud‑Brokering Services
<b>How to achieve:</b>
* Confirm the Team is acquiring cloud services through SSC Cloud Brokering Services. Please include the SSC Request number
<b>Tools:</b>
* Contact Cloud COE
* enforce this order of preference: public cloud first, then hybrid cloud, then private cloud, and lastly non‑cloud (on‑premises) solutions
* enforce this order of preference: public cloud first, then hybrid cloud, then private cloud, and lastly non‑cloud (on‑premises) solutions
<b>How to achieve:</b>
* Summarize how the architecture, based on the TBS Right Cloud Assessment Tool, allows for public cloud, including:
* The data, being managed by the architecture, is PBMM or lower, and stakeholders have not raised concerns about deployment to the public cloud.
* A costing model / budget that is available to support an Operational Expense Model. The costs will rise and fall with the consumption of resources.
* The implementation of application(s), which can operate in a cloud environment and any required virtualized or dedicated hardware, is available in a cloud environment.
* The implementation of application(s) which can operate on the standardized offerings and SLAs of public cloud.
* The implementation of applications are not susceptible to latency issues, which may arise due to traffic moving through an additional circuit.
* The implementation of applications, which do not have voluminous transactions with an on-premises database or application.
<b>Tools:</b>
* Cloud Reference Architecture
* Cloud Assessment Framework
* design for cloud mobility and develop an exit strategy to avoid vendor lock‑in
* design for cloud mobility and develop an exit strategy to avoid vendor lock‑in
<b>How to achieve:</b>
* Summary how the architecture allows for the execution of an exit strategy to off-board from that vendor
<b>Tools:</b>
* Solution Architecture
* Refer YDG GC EARB
=== Design for performance, availability and scalability ===
=== Design for performance, availability and scalability ===
* ensure response times meet user needs, and critical services are highly available
* ensure response times meet user needs, and critical services are highly available
<b>How to achieve:</b>
* Summarize how the architecture is able to meet the user response time requirements, and achieve the user response time objectives, including:
* The ability to trace how the response time requirements and objectives will be met.
* The capacity requirements (e.g. expected normal traffic, peak traffic, expected traffic grow, etc.) that the architecture needs to meet.
* The ability to trace how the availability requirements and objectives will be met.
<b>Tools:</b>
* support zero‑downtime deployments for planned and unplanned maintenance
* support zero‑downtime deployments for planned and unplanned maintenance
<b>How to achieve:</b>
* Summarize how the architecture is able to support zero-downtime deployments for planned and unplanned maintenance, including:
* The planned Windows maintenance for the solution to support backups and length of Windows maintenance.
* The procedure for planning, scheduling and executing the planned downtime.
* The ability to be deployed in a manner that minimizes or limits service disruption, and which is known as zero downtime deployments.
* The acceptable measures for unplanned downtime.
<b>Tools:</b>
* non-functional requirements
* use distributed architectures, assume failure will happen, handle errors gracefully, and monitor performance and behaviour actively
* use distributed architectures, assume failure will happen, handle errors gracefully, and monitor performance and behaviour actively
<b>How to achieve:</b>
* Summarize how the architecture utilizes distributed architectures, which assume that a failure will happen, handle errors gracefully and monitor actively, including:
* The ability to trace how the recoverability requirements and objectives will be met; and,
* The ability to be deployed in a distributed environment.
<b>Tools:</b>
* non-functional requirements
* establish architectures that supports new technology insertion with minimal disruption to existing programs and services
* establish architectures that supports new technology insertion with minimal disruption to existing programs and services
<b>How to achieve:</b>
* Summarize how the architecture allows the insertion of new technology with minimal disruption
<b>Tools:</b>
* non-functional requirements
* control technical diversity; design systems based on modern technologies and platforms already in use
* control technical diversity; design systems based on modern technologies and platforms already in use
<b>How to achieve:</b>
* Summarize the technology standards’ state (emerging, baseline, containment or retirement) of the products required/recommended to implement the architecture. For those products in the containment or retired state please provide rational for selecting those products
* Identify new technology standards required by the architecture
<b>Tools:</b>
* non-functional requirements
=== Follow DevSecOps principles ===
=== Follow DevSecOps principles ===
* use continuous integration and continuous deployments
* use continuous integration and continuous deployments
<b>How to achieve:</b>
* Summarize how the architecture can be deployed following a continuous integration approach
* Summarize how the architecture can be deployed following a continuous deployment approach.
<b>Tools:</b>
* CICP mesh
* ensure automated testing occurs for security and functionality
* ensure automated testing occurs for security and functionality
<b>How to achieve:</b>
* Summarize the automated security and functionality testing that will be/has been executed on the solution.
* include your users and other stakeholders as part of the DevSecOps process, which refers to the concept of making software security a core part of the overall software delivery process
* include your users and other stakeholders as part of the DevSecOps process, which refers to the concept of making software security a core part of the overall software delivery process
<b>How to achieve:</b>
* Summarize the role and responsibilities users and other stakeholders have in DevSecOps processes.
<b>Tools:</b>
* Project Charter