514
edits
Changes
Jump to navigation
Jump to search
Line 21:
Line 21: − + Line 84:
Line 84: − + − + − + − + + + + + + + + + + + + + + + + + + + + + + − + − + − + − + − + − + − + − + − + + + + + + + + + − + − + − + − +
GC Enterprise Architecture/Playbook (view source)
Revision as of 18:00, 8 January 2020
, 18:00, 8 January 2020no edit summary
<span style="font-size: 1.5em;">[[GC_Business_Enterprise_Architecture | 1. Business Architecture]]</span> <br><br>
<span style="font-size: 1.5em;">[[GC_Business_Enterprise_Architecture | 1. Business Architecture]]</span> <br><br>
A Business Architecture is where an organization identifies the various services that it suppose to provide externally, as well as the various functions it owns or needs to own internally to support the external service. In terms of GC Enterprise Business Architecture, this is where the Government of Canada identifies the various departments, the services they provide to Canadians and the functions they owns.
A Business Architecture is where an organization identifies the various services that it suppose to provide externally, as well as the various functions it owns or needs to own internally to support the external service. In terms of GC Enterprise Business Architecture, this is where the Government of Canada identifies the various departments, the services they provide to Canadians and the functions they owns. <br><br>
<b>Fulfill the Government of Canada stakeholder's needs</b>
<b>Fulfill the Government of Canada stakeholder's needs</b>
<span style="font-size: 1.5em;">[[GC_Application_Enterprise_Architecture | 3. Application Architecture]]</span> <br><br>
<span style="font-size: 1.5em;">[[GC_Application_Enterprise_Architecture | 3. Application Architecture]]</span> <br><br>
<b>Use Open Source Solutions hosted in Public Cloud</b>
Application Architecture consists of the interaction of applications with each other and with users. It focuses less on internal mechanics and specific programming and more on overall design on how data is consumed and created by the system. It views the interactions between applications, databases, middleware to ensure scalability, reliability, availability and manageability. <br><br>
* Select existing solutions that can be reused over custom built
* Contribute all improvements back to the communities
<b><u>Use Open Source Solutions hosted in Public Cloud</b></u><br>
* Register Open Source software to the Open Resource Exchange
While OSS is not a silver bullet several common misconceptions are used as arguments against Open Source software: A misconception with security is that with the code out of the eyes of the public that it prevents successful attacks and lowers liability, however in reality Security Best practices state that 'System security should not depend on the secrecy of the implementation or its components', and as Open Source development relies and hardening (or improving the security) of code it is often equal or more secure then proprietary solutions.
A misconception with support is that a support contract or license some how ensures that the proprietary system will receive improvements and patches, but in reality there is no obligation for a vendor to do so, while Open Source software survives by having a vibrant and helpful support community. Average resolution of issues are solved faster then in proprietary software by the very nature of crowd sourcing reducing the barrier of communication with a single entity or individual. <br><br>
*<b><I> Select existing solutions that can be reused over custom built</b></I>
It is important to reduce the duplication of effort that has occurred due to segmented mandates, and increase collaboration and sharing across Departments and Agencies. Crown Corporations, Provincial and Municipal Governments as well as the Public at large who can benefit from new and innovative products and services based off of creations from the Government.<br><br>
*<b><I> Contribute all improvements back to the communities</b></I>
Major benefits can occur not just from publishing the Software, but in developing Guidance the quality of software increases, while publishing Lessons Learned, White Papers and any other technical documentation can assist others in the future by providing templates and baselines.
For assistance in how to do this, you can view the TBS Guidance on Open Source Publishing.
Setting up shared teams for common problems where Developers from multiple departments can produce better solutions. Virtual Teams using open tools can enable rapid development in absence of collocation.<br><br>
*<b><I> Register Open Source software to the Open Resource Exchange</b></I>
Scientific Innovation can occur from exposing Data to interested members of the activists, researchers, students and the public at large.
Define Metadata for your application early in both English and French to support your release to [https://open.canada.ca/en/open-data|Open Data].
Development following the Government of Canada Standards on APIs can allow rapid uptake into Open Data feeds.
<br>
<br>
<b>Use Software as a Service (SaaS) hosted in Public Cloud</b>
<b><u>Use Software as a Service (SaaS) hosted in Public Cloud</b></u>
* Choose SaaS that best fit for purpose based on alignment with SaaS capabilities
* <b><I>Choose SaaS that best fit for purpose based on alignment with SaaS capabilities </b></I><br>
* Choose a SaaS solution that is extendable
* <b><I>Choose a SaaS solution that is extendable </b></I><br>
* Configure SaaS and if customization is necessary extend as Open Source modules
* <b><I>Configure SaaS and if customization is necessary extend as Open Source modules </b></I><br>
<br>
<br>
<b>Design for [https://www.gcpedia.gc.ca/wiki/En/GCinterop Interoperability]</b>
<b><u>Design for [https://www.gcpedia.gc.ca/wiki/En/GCinterop Interoperability]</b></u>
* Design systems as highly modular and loosely coupled services
* <b><I>Design systems as highly modular and loosely coupled services</b></I><br>
* Expose services through APIs
Focus on smallest unit of purpose, and developing a single function. Ensure containers contain a single application, and build the smallest image possible.
* Make the APIs discoverable to the appropriate stakeholders
Ensure containers are properly versioned and tagged.
<br>
<br><br>
* <b><I>Expose services through APIs </b></I>
Do not hide services under assumptions that someone would not find value in a service - often innovation can be bred from exposed services beyond it's original plan.
Follow the 'eat your own dogfood' mantra - in that all functionality should be a service that you consume.
Ensure that services are accessible via common methodologies, and follow the Government of Canada Standards on APIs.
<br><br>
* <b><I>Make the APIs discoverable to the appropriate stakeholders</b></I><br><br>
<b>Follow DevSecOps Principles</b>
<b><u>Follow DevSecOps Principles</b></u>
* Use continuous integration and continuous deployments (CI/CD)
* <b><I>Use continuous integration and continuous deployments (CI/CD)</b></I>
* Ensure automated testing occurs for security and functionality
* <b><I>Ensure automated testing occurs for security and functionality </b></I>
* Include your stakeholders as part of DevSecOps process
* <b><I>Include your stakeholders as part of DevSecOps process</b></I>
