Legal Aid Agency (LAA/MoJ)

Legal Aid Agency (LAA) Cloud Infrastructure Development

Incomplete applications

5
Incomplete applications
1 SME, 4 large

Completed applications

10
Completed applications
6 SME, 4 large
Important dates
Opportunity attribute name Opportunity attribute value
Published Wednesday 28 February 2018
Deadline for asking questions Wednesday 7 March 2018 at 11:59pm GMT
Closing date for applications Wednesday 14 March 2018 at 11:59pm GMT

Overview

Overview
Opportunity attribute name Opportunity attribute value
Summary of the work The Ministry of Justice (MoJ) is migrating legacy IT systems used by the Legal Aid Agency (LAA) to new public cloud hosting during 2018. To support these migrated applications, MoJ requires the development of new automated infrastructure to provide services such as SSL termination, software load balancing and log aggregation.
Latest start date Sunday 1 April 2018
Expected contract length 4-6 months (with potential 3 month extension)
Location London
Organisation the work is for Legal Aid Agency (LAA/MoJ)
Budget range

About the work

About the work
Opportunity attribute name Opportunity attribute value
Why the work is being done The Ministry of Justice (MoJ) is migrating legacy IT systems used by the Legal Aid Agency (LAA) to new public cloud hosting as an existing data centre contract is ending in 2018. This phased migration is moving systems into two new hosting providers over the next 6 months. To operate the migrated applications in one of the hosting providers, we require a team to help us develop an automated infrastructure to provide several supporting services.
Problem to be solved The Ministry of Justice (MoJ) requires the development of new infrastructure to support the operation of migrated applications. This supporting infrastructure should be developed using infrastructure-as-code principles, CI/CD and automated deployment, using open source technologies where appropriate. It should provide: SSL termination (with automated certificate creation/renewal), software load balancing, outbound SMTP, in/outbound SFTP, log aggregation and system monitoring. Infrastructure changes should be automated, and deployable across multiple environments.
Who the users are and what they need to do As a user of LAA services (solicitors, barristers & caseworkers), I need to be able to access the migrated applications securely so that LAA system administrators can manage changes to the supporting infrastructure in an automated way; to relay SMTP/SFTP traffic to outbound gateways hosted in other hosting providers; to aggregate and view system and application logs in a central place.
Early market engagement None
Any work that’s already been done Applications are being migrated to the new hosting providers using teams within the Ministry of Justice (MoJ) and Legal Aid Agency (LAA). A high level design and requirements list for the infrastructure has been developed and this will be shared with the shortlisted bidders.
Existing team There is no existing team or supplier for this work - this is expected to form a new team within the wider migration programme. Several other teams exist to undertake the migration of applications to the hosting providers, and these teams will be available to assist with this work. The existing migration teams include software developers, testers, delivery managers, web operations engineers and technical architects.
Current phase Not applicable

Work setup

Work setup
Opportunity attribute name Opportunity attribute value
Address where the work will take place London - Holborn / St James's
Working arrangements Onsite work for a minimum of 3 days a week. Participation in wider programme team show & tells, retrospectives and planning sessions is expected.
Security clearance BPSS (Minimum)

Additional information

Additional information
Opportunity attribute name Opportunity attribute value
Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Skills and experience
Opportunity attribute name Opportunity attribute value
Essential skills and experience
  • Experience using configuration management tools such as Puppet, chef, Ansible, Salt, etc.
  • Experience building and configuring new server platforms and the automated tooling to do so.
  • Experience architecting and developing scalable services using public cloud technologies.
  • Experience of application deployment strategies, continuous integration and version control.
  • Experience producing tooling for other teams to independently build and debug their own services.
  • Experience working in multidisciplinary agile teams.
Nice-to-have skills and experience
  • Familiarity with network protocols - TCP/IP, HTTP(S), TLS, etc.
  • Experience of working with software-defined networks.
  • Experience working with VMWare/VCloud based infrastructure as a hosting cloud providers.

How suppliers will be evaluated

How suppliers will be evaluated
Opportunity attribute name Opportunity attribute value
How many suppliers to evaluate 5
Proposal criteria
  • High level approach - How you approach delivering a MVP to meet project aims and transition to the team that will operate the service.
  • How you have identified risks and dependencies and offered approaches to manage them.
  • Time frames - estimated time frames for the work to be undertaken.
  • Team structure.
Cultural fit criteria
  • Be transparent and collaborative when making decisions.
  • Have a no-blame culture and encourage people to learn from their mistakes.
  • Work as a team with our organisation and other suppliers.
  • Delivering consistently within an agile environment.
Payment approach Capped time and materials
Assessment methods
  • Written proposal
  • Case study
  • Presentation
Evaluation weighting

Technical competence

50%

Cultural fit

20%

Price

30%

Questions asked by suppliers

Questions asked by suppliers
Supplier question Buyer answer
1. The opportunity states a requirement to work onsite for a minimum of 3 days per week. Do you anticipate the other 2 days per week to be completed offsite (ie supplier premises) or do you see this project as being a part-time (3 day per week) engagement. The supplier will be expected to be on-site a minimum of 3 days per week. The other 2 days per week can either be on-site or off-site. If you feel that you can deliver the work for less than 5 days a week then that is fine but we anticipate that resources will be required 5 days a week.

On-site will either be at St James's or Holborn (London). This will be confirmed to the successful bidder.
2. Can you please elaborate on your hopes/expectations for this essential skill? Examples would be really appreciated to ensure our answer reflects our abilities properly: "Experience producing tooling for other teams to independently build and debug their own services You should show evidence that you have provided a tool or sets of tools to help users get access to information they need to debug applications running on a hosting platform without input from an infrastructure engineer. This could include, but is not limited to, access to consolidated log files, and/or monitoring systems to help identify where issues might be occurring.
3. We need to know how many VMs and/or apps are being deployed. The number of VMs to be deployed will be variable depending on expected load for each environment. We expect the developed infrastructure to use infrastructure-as-code principles with automated deployment/provisioning to allow MOJ/LAA staff to increase/decrease the number of VMs over time. We expect the infrastructure to provide supporting services such as SSL termination (with automated certificate creation/renewal), software load balancing, outbound SMTP, in/outbound SFTP, log aggregation and system monitoring.
4. How many environments does each app require? We will require the supporting infrastructure to be available on multiple environments including development, test, staging and production. There may also be other, ad-hoc environments created as required. We expect the infrastructure to be developed using infrastructure-as-code principles with automated deployment/provisioning to allow this to quickly and easily evolve over time.
5. Can you tell us whether provision of a Security Operations team is outside the scope of the tender? We do not require the provision of a Security Operations team.
6. Which cloud provider is being used? This automated infrastructure will be deployed to Carrenza.
7. What is the state of existing environments (i.e do you have several environments that have been pulled together already without any automation, or do you have loads that already have automation scripts but require analysis and redesign to use puppet/chef/ansible…or is this greenfield…)? The supporting infrastructure we require (SSL termination, software load balancing, outbound SMTP, in/outbound SFTP, log aggregation and system monitoring) is greenfield. Over time, existing legacy applications will be migrated into these new environments. However, this migration is outside the scope of this outcome.
8. How much capacity do the other teams have, to work with the automation teams or are they already maxed out delivering to a programme plan? The existing teams will be able to provide information and understanding about the legacy applications that will eventually be migrated to the new environments in Carrenza. They will also be able to provide support/knowledge about work being undertaken in the other cloud hosting provider. However, it should be assumed that they are fully committed to the migration work. As such, you should expect to form a new, independent team within the wider programme.
9. Is there an architecture and infrastructure design for the cloud already established with policies, standards etc or does this need to be developed? There is an existing architecture/infrastructure design produced, which will be shared with shortlisted bidders. There are several policies and standards in use throughout the migration programme which can be considered during development.
10. Will the supplier be responsible for the delivery management of the team and the outcomes required? Yes. There will be a Lead Delivery Manager from the programme, supporting all the teams. However, you should expect to form a new, independent team with it's own delivery manager.
11. Will LAA/MOJ fulfil any roles within the team, e.g. Product Owner? The programme will provide a part-time product owner and technical architect to support the work.
12. What hosting providers will be used? The hosting provider is Carrenza.
13. To what extent will the supplier be responsible for, or able to bring their experience to, the infrastructure architecture? The programme will provide a part-time technical architect, and some infrastructure design has been done. However, we expect this architecture to be iterated and improved by everyone involved during the work.
14. Can you provide any guidance on your budget range for the services? £200-300k.
15. Are the LAA able to share who the two new hosting providers are at this stage, especially the hosting provider in which the supporting services are to be implemented by the supplier? If so, who are they/is it? This automated infrastructure will be deployed to Carrenza.
16. Regarding the question “Experience using configuration management tools such as Puppet, chef, Ansible, Salt, etc.” - is the bidder expected to evidence experience in one of these tools or several? If several, are multiple examples permissible? We expect the bidder to provide evidence of using at least one of these tools.
17. Regarding the question “Experience building and configuring new server platforms and the automated tooling to do so” - could LAA expand on the meaning of “server platform”, as this term can be used in multiple ways? We're looking for evidence that a bidder has experience provisioning, building and configuring virtual servers in a cloud hosting provider using automated tooling.
18. Regarding the question “Experience of working with software-defined networks” - does this refer to using high-level SDN constructs exposed by a hosting provider, or implementing the underlying SDN infrastructure itself? We're looking for evidence that a bidder has used the network constructs exposed by a hosting provider to manage software-defined networks.
19. Regarding the question “Experience working with VMWare/VCloud based infrastructure as a hosting cloud providers” - does this refer to working with hosting providers who use VMWare/VCloud based infrastructure, or experience working with these technologies as a hosting provider? The automated infrastructure will be deployed to a cloud hosting provider which uses VMWare/VCloud based infrastructure. As a result, we're looking for evidence that a bidder has experience using this type of infrastructure.
20. What is the scale of the platform for which the team is to develop the infrastructure services? The supporting infrastructure will need to support underlying applications which have around 60,000 users and should handle around 20% users accessing the services concurrently. As previously stated, the infrastructure should be developed using infrastructure-as-code principles to allow us to easily add/remove virtual machines into the estate to support any increase/decrease in users.
21. Can you provide any estimation of budget and/or expected size and roles of the supplied team? See previous answer on budget range. Our initial expectation is for a supplier to provide several Web Operations engineers capable of building automated infrastructure, along with delivery management support. However, if a bidder believes they can achieve the desired outcome with a different team structure, that is acceptable. We'll be evaluating proposed team structure in the written proposal for shortlisted bidders.
22. What are the drivers behind migrating the associated applications to Carrenza rather than a public cloud platform such as Amazon or Azure? Applications migrating to Carrenza are generally legacy applications which are unsuitable for migration to a public cloud platform like AWS or Azure. This may be because of age or licensing restrictions. The infrastructure to be developed for this outcome is to provide supporting services (SSL termination, software load balancing, outbound SMTP, in/outbound SFTP, log aggregation and system monitoring) rather than infrastructure to host the applications themselves.
23. What is the tech stack for the applications? We expect the infrastructure to be developed will make use of standard open-source components including Ubuntu, Apache or Nginx, HA proxy, ELK etc.
24. The opportunity references puppet/chef/salt/ansible - could you please share a list of your preferred and mandated tooling? We do not have a preferred toolset for the infrastructure development, however we expect suppliers to have experience using one or more infrastructure-as-code tooling such as puppet, chef, salt, ansible etc.