06. Technical architecture

6. Evaluate what tools and systems will be used to build, host, operate and measure the service, and how to procure them.

Link to corresponding item in JIRA: https://jira.informed.com:8443/browse/FCOLOI-159

Questions

• How are you managing the constraints that the selection of technology stack places on you?
• How are you managing the constraints that the selected development toolchain places on you?
• What have you bought and how have you ensured you are getting value for money?
• How will you know if the service is healthy?
• What support arrangements have you got in place during beta?
• What decision making have you outsourced?

Evidence

Technical Architecture overview <>

Service Manager able to:

• explain how they are managing the constraints that the selection of technology stack places on the service.

• Internal case management system:

  • Being built in parallel - loosely coupled to avoid dependencies. Resilient message queuing for integration.
  • Fixed country list not in-sync with FCO official country list. Local lookup table with mapping to back-office fixed list

• Constraints with Payment service and security requirements:

  • Flexibility of UI customisation and alignment with GOV.UK elements), particularly when combined with progressive enhancement development.
  • Inability to share customer details across different Smart-Pay services. Worked with FCO staff to refine back-office working practices such that we could deliver improved the benefits of card sharing across services to customers.

• Inconsistency between Addressing formats between SaaS address validation service and case management system. Neither of which met UX expectations and GOV.UK design patterns. Dealt with through business logic to manage mapping between the three systems.

• explain how they are managing the constraints that the selected development toolchain places on the service.

Pipeline diagram on Google Docs

• Main challenges and constraints have been working with the underlying infrastructure services (skyscape). Administration of the environment (e.g. firewall changes, VLAN configuration etc.) has required support from outside the team. This has at times held the team up when provisioning environments etc.

• Chosen open-source technologies for the pipeline that are already used within FCO and for which there are skills in the team that will run and operate the service.

• The CI pipeline has been improved progressively alongside development of the service, which greater automation in build, deploy, test and reporting coming online with each sprint.

Now we have a mature set of applications we plan to look into introduce Docker into the CI pipeline to further assist the team that will run and operate the service.

• explain what they have bought and how they are ensuring they are getting value for money.

• All built-software is open source.

• Consume a number of SaaS services: * GBGroup Addressing * SendGrid Email - already in-use at FCO * Payment service (Barclaycard - SmartPay) - already in use at FCO

• For the selection of the Addressing Service a set of requirements / capabilities were devised and an options assessment of candidate services was undertaken - The assessment included cost based analysis and evaluation of test APIs.

• Hosting service extends existing infrastructure within Skyscape

  • Exists skills and working protocols with FCO.
  • Shared security features and accreditation for other FCO services (e.g. ETD).

• explain or demonstrate how they will know if the service is healthy.

• Health monitoring

<< Link to Kibana dashboard >>ti

• explain the support arrangements they have in place during beta.

• explain what decision making they have outsourced

---

Original alpha answers below

Questions

• Describe the languages, frameworks, and other technical choices you've made in alpha, and how those will affect the decisions you make in beta.
• Describe the development toolchain that you would like to select for beta and why.

Evidence

Service Manager able to:

• describe the languages, frameworks, and other technical choices they’ve made in alpha, and how this will affect the decisions they make in beta.
• describe the development toolchain they would like to select for beta and why.

---

Design Principles:

• adopt open modular architecture allowing components and services to be swapped in or out thus avoiding vendor lock-in
• actively identify opportunities for reuse of code within FCO and wider government
• use open source technologies as standard and release all developed code under the GNU General Public Licence into a publicly visible GitHub repository
• adopt common development, configuration and release pipeline tooling in line with other FCO services where applicable
• develop code using a Progressive Enhancement approach to ensure an appropriate and usable experience for all users of the service

Describe the languages, frameworks, and other technical choices you've made in alpha, and how those will affect the decisions you make in beta.

• continue to use GOV.UK design prototype toolkit throughout Beta to rapidly iterate and test UX features
• Node.js (web application framework written in JavaScript)
• PostgreSQL (relational database provider for Application Service)
• Mocha (a Node.js unit testing framework)
• responsive design using e.g. Twitter Bootstrap to ensure browser and device compatibility

Describe the development toolchain that you would like to select for beta and why.

• Jenkins (open source tool used for continuous integration and deployment)
• GitHub (open source code repository where code is made publicly available)
• Docker (provides containers allowing independent microservices to be created and deployed)