GC Enterprise Architecture/Standards/Application Architecture

GC Enterprise Architecture	GC Enterprise Architecture Review Board, GC EARB
GC Service & Digital Target Enterprise Architecture	When to come
Enterprise Architecture Framework	Forward Agenda
Business Capability Model (BCM)	Past Sessions
Exemplar and Reference Architectures	10 Things You Need to Know
Enterprise Solutions	Governance for Digital Solutions
Working Groups	EA and GC EARB Overview – Presentation
Other References

Translation to follow

<<Information Architecture

Technology Architecture>>

3. Application Architecture

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.

Use Open Standards and Solutions by Default

The Directive on Management of Information Technology and Digital Standards states that where possible, open source software be used first, The primary driving factors for this are:

1. Aligning with Open Government
2. Supporting the Local Economy and Communities
3. Lowering initial and long term Cost of Solutions
4. Increasing Security
5. Increasing Quality of Solutions
6. Increasing Productivity across Government of Canada by enabling reuse
7. Improving Job Satisfaction
8. Reducing Vendor Lock

• Where possible, use open source standards, and open source software first
  • 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 n 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.

• 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
  • Vendor lock is a real concern in the Development of Applications, and when propietary COTS applications are selected it increases the difficulty of ever moving to a new system, and any integration or interoperability functions.
• 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
  • 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.
  • 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 theTBS 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.
• All open source code must be released under an appropriate open source software license
  • It is important to ensure that the License chosen for OSS protects the rights of Government of Canada and Public Servants while enabling the use and re-use of software. Guidance can be found here.
• Expose public data to implement Open Data and Open Information initiatives
  • 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
  • Development following the Government of Canada Standards on APIs can allow rapid uptake into Open Data feeds.

Maximize Reuse

• Leverage and reuse existing solutions, components, and processes
  • The use of Open Source software can ensure that other Departments reuse components developed, and vice versa.
  • SaaS, PaaS and IaaS solutions can leverage sharing of configurations when no code is involved such as the GC Accelerators (AWS, Amazon)
  • Opening up Communication with other Departments to identify if they've already developed a solution can enable further reuse.
• Select enterprise and cluster solutions over department-specific solutions
  • Focus on solutions that enable sharing with other Departments, do not focus just on individual mandates.
  • Costs can be setup to be shared across multiple departments, agencies etc...
• Achieve simplification by minimizing duplication of components and adhering to relevant standards
  • Focus on Separation of Concern by the development of Microservices, and use and reuse of APIs.
  • Consume APIs from the Government of Canada API Store if it exists, if it does not add it to the API store.
  • Follow the Government of Canada Standards on APIs
• Inform the GC EARB about departmental investments and innovations
  • Communicate with the GC-EARB Team early and frequently, sharing innovations and lessons learned so we can assistance in broadcasting them to others.
• Share code publicly when appropriate, and when not, share within the Government of Canada
  • Code should be shared in Public Repositories as described here.
  • When not able to, instead Code should be shared on GCCode.

Enable Interoperability

• Expose all functionality as services
  • 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.
• Use microservices built around business capabilities. Scope each service to a single purpose
  • Focus on smallest unit of purpose, and developing a single function.
• 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)à
  • Ensure that services are accessible via common methodologies, and follow the Government of Canada Standards on APIs
• Run applications in containers
  • Ensure containers contain a single application, and build the smallest image possible.
  • Ensure containers are properly versioned and tagged.
• Leverage the GC Digital Exchange Platform for components such as the API Store, Messaging, and the GC Service Bus
  • Ensure APIs are discoverable on the API Store.

Need help? Contact us. EA.AE@tbs-sct.gc.ca Enterprise Architecture Community of Practice GC Enterprise Architecture Review Board