Skip to content

06. Technical architecture

Jump to bottom Edit New page
mjrix edited this page Mar 24, 2016 · 32 revisions

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 https://docs.google.com/presentation/d/1d-CqABucobKYKD0YgXZJQJZ5elXh2XfqI_I_SFpwMV8/edit#slide=id.p

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 introducing 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.

Log and Event Monitoring (ELK Stack)

  • Log shipping (application and proxy)
  • Kibana dashboard for monitoring / visualization
  • Proactive alerts triggered on key events.
  • explain the support arrangements they have in place during beta.

  • 24/7 Support with Kainos

    • Application and Infrastructure support
    • Embedded developers that are fully up-to-speed with the code, toolchain and pipelines

  • Customer Service Centre (Serco)

  • explain what decision making they have outsourced
  • Team have been able to take the vast majority of decisions as to the way the service is built ourselves.
  • Areas where we've need to collaborate with other teams that have influenced the architecture include:
    • Back-office integration * Security - Independent assurance recommended a number of minor changes (not really architectural more implementation detail) - for example logging and monitoring around security related events (e.g. failed site and SSH logins).

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)
Add a custom footer
Add a custom sidebar
Clone this wiki locally